• Please review our updated Terms and Rules here

A PET storage option

But now you have to share those disk images with the rest of us! ;-)

with great pleasure...

Here's 2 files : a T64 and a D64. Not tested and i found them on the web (often german websites) ;)

the second one is more interesting : a pascal interpetrer (compiler ?) and a word processor.

I've 5 more D80 files (games in German) but VintageComputers said that the size of the ZIP files exceed the max limit of 97 kB (and that's true !)


Edit : here's the link to spx.zip including 5 images (d80 d82) of german games for 4032, 8032
http://dl.free.fr/getfile.pl?file=/5DweKjkS
 

Attachments

  • CBMSOFT.zip
    95.9 KB · Views: 1
  • PASCWORD.zip
    93.6 KB · Views: 1
Last edited:
Hi again,

I wanted to ask for some quick assistance with how some things worked with Commodore DOS, to make sure I'm getting it right.
I'm in the process of updating the firmware, and plan to add wildcard support and at least support for the DLOAD command, and possibly other BASIC 4 commands.

This is my understanding, please correct me if I'm wrong or if I am missing something.
LOAD"*",9 - load the first file on the disk
LOAD"*PART",9 - load the first file on the disk that has the suffix PART
LOAD"PART*",9 - load the first file that has the prefix PART

And with DLOAD, a command like
DLOAD"NAME",9

would look for a file called 0:NAME on the disk..

Just wanted to check if this looked correct.
Also if you have any links to documentation on BASIC 4 commands, please send them my way.
Thanks very much!
 
The second issue is loading games with long filenames seems to fail and this could be because DOS filenames are automatically saved with a short filename to be 8.3 format compatible, so "LONGFILENAME.PRG" becomes "LONGFI~1.PRG" and you must be trying to load that. Unfortunately the PET has no "~" character....

This report from Steve helped me to track down a bug. The behavior described here, where loading files with long filenames is failing, is happening because there is an accidental case sensitivity in the filename extension. For example,
load "this is a test",9
will succeed if the filename on the card is
this is a test.prg
but will fail if the name is
this is a test.PRG

Looking at the collection of games from sjgray, these all have .PRG extensions, so only the ones with fewer than 8 characters before the extension are loading correctly. This is because these end up being found by their short filename, where there is no upper and lowercase.
The short term workaround is to rename files to have .prg instead of .PRG extensions. I listed this bug on the petdisk technical page at
http://www.bitfixer.com/bf/petdisk-technical
and intend to fix this in the next firmware.
Wanted to let everyone know so you can work around it for now.
Thanks for helping to find this one.
 
Hm, I'm unsure if LOAD"*" would get the first or the last used file on the disk. I have seen claims of both. LOAD"PART*" will load the first (or last used?) file that starts with PART. However I believe the third syntax LOAD"*PART" is bogus, once the asterisk wildcard has been used, all characters following it would be discarded so it would be identical to LOAD"*" as far as I'm concerned.
 
Hi again is this why I had trouble earlier in this thread?

I tried to load a program but had trouble loading files but noticed the files needed to be ".PRG"

I had some files that were PRG files but only read "space invaders" on the memory card.
these would not load until I renamed them as "space invaders.prg" on the memory card.
Hope that makes sense!
 
I believe so. If you had a file called
'space invaders.PRG'
then it would not find it, since it is specifically looking for lowercase '.prg' in the extension. It would work with 'space invaders.prg'.
But if the filename is
'spaceinv.PRG'
then it would work, because the FAT short file entry for this becomes
'SPACEINV.PRG' regardless of the case in the long file entry - and the PETdisk would find the file by its short file entry.

Hope this makes sense.

A few words about a firmware upgrade, coming very soon -
I think that the best approach to make upgrades easier for everyone is to create a bootloader for the Atmel device which will look for new firmware revisions on the SD card, and will automatically upgrade itself when new versions are found.
This way after the bootloader is loaded onto the chip, you will not need any kind of cable or programmer to load firmware upgrades. Basically if a new firmware version comes out, you would copy a file like 'firmware.bin' onto your SD card, then put it into the PETdisk. The next time it turns on, the PETdisk bootloader would find the file and program the chip with the contents of the file, then would delete the file from the SD card.

For those who have PETdisks already, there will be two options for getting the bootloader upgrade.
If you already have access to an AVR programmer, or if you want to build the simple DASA programmer here:
http://avrprogrammers.com/bld-dasa.php
(Note that this programmer requires a true serial port, USB-Serial adapters will not work)

then you can just directly flash the device and load the new bootloader onto it.
If programming the device yourself is not a convenient option, I will send you a replacement Atmel chip with the bootloader onboard for no charge.

I think this is the best way to handle upgrades, and I wanted to get this done before too many PETdisks were out there. Please let me know if you have any thoughts on this.. thanks!
- Mike
 
I think that the best approach to make upgrades easier for everyone is to create a bootloader for the Atmel device which will look for new firmware revisions on the SD card, and will automatically upgrade itself when new versions are found.
This way after the bootloader is loaded onto the chip, you will not need any kind of cable or programmer to load firmware upgrades. Basically if a new firmware version comes out, you would copy a file like 'firmware.bin' onto your SD card, then put it into the PETdisk. The next time it turns on, the PETdisk bootloader would find the file and program the chip with the contents of the file, then would delete the file from the SD card.

This is a great idea!.

If programming the device yourself is not a convenient option, I will send you a replacement Atmel chip with the bootloader onboard for no charge

As my programmer doesn't seem to support the necessary AVR (at least not the chip that's used), I might take up this offer Mike.

I've received my unit but have yet to try it out. Just too much else going on in my life at the moment. Maybe this weekend...

Tez
 
It seems like many of the microcontroller-based projects/products out there are using bootloaders, so I thought it would greatly increase the usability of the PETdisk.

After cranking away on this today, I have a simple bootloader working which reads from a file on the SD card, and flashes the program memory if a new version is detected. I'm including some extra information in the firmware file besides the code itself, including a version number. Now I just have to get the application code to fit into the remaining memory. I may just replace the ATmega8 with another Atmel with more memory to make things simpler and to allow for expansion of the firmware in the future.

This should all be working shortly and I'll be sending messages to the PETdisk'ers out there to coordinate the upgrade. Thanks..
- Mike
 
This is great news. It's always hard to determine what capacity chip to use in these types of designs. It's a tradeoff between expandability and cost. If a larger Atmel chip could be programmed and sent to current owners at a nominal cost that would be great. With in-place firmware upgrades the PETdisk becomes much more attractive. Thanks!

Steve
 
Now I just have to get the application code to fit into the remaining memory. I may just replace the ATmega8 with another Atmel with more memory to make things simpler and to allow for expansion of the firmware in the future.

Would the ATmega328 be a pin-compatible swap? (It sort of looks like it is based on some Arduino documentation, but I don't know enough to say.) Looks like they're only about $5 for 8 times the flash memory...

I've been way too busy with, shall we say, RL things to futz much with my PETs the last few weeks, but I'm looking forward to seeing what the developments are with the PETdisk. (I think I've hit that same mixed-case bug myself, along with possibly another I need to investigate more thoroughly.) Thanks for the hard work on this.
 
Thankfully Atmel has fairly consistent pinouts between its parts with the same package. The ATmega328 is indeed compatible, and it has a whopping 32k in flash. Pretty funny that the SD reader would have as much memory as the PET itself..
After looking through the possible replacements, I think the ATmega168 would probably be the best suited. It has 16k of flash as opposed to the Atmega8's 8k, and costs the same as the Atmega8 from digi-key - which has me wishing I had gotten it in the first place. Live and learn.
After digging into the code, while I think it would be possible to pare down everything to barely fit onto the mega8's flash with the bootloader, it would make further upgrades more difficult as you would have to crazily optimize for code space to fit in anything else. So I think the best route is to go for the chip replacement of the ATmega8 with the ATmega168.
I have some of those on order, and will get ready to send out the replacements as soon as they arrive. I'm aiming for early next week to send out the replacement MCU which will have an SD-card bootloader, wildcard support, and partial BASIC4 command support. After that point firmware upgrades will be simple, just copy a file onto your card and it will upgrade when next powered on.
 
...I have some of those on order, and will get ready to send out the replacements as soon as they arrive. I'm aiming for early next week to send out the replacement MCU which will have an SD-card bootloader, wildcard support, and partial BASIC4 command support. After that point firmware upgrades will be simple, just copy a file onto your card and it will upgrade when next powered on.
Excellent! You can combine Steve's and mine to save postage.

Kudos and thanks for the effort you're putting into this, BTW; It's one thing to come up with a clever device like this, but often the developer quickly loses interest when it comes to documentation, support and upgrades... - thanks again!
 
Someone on the CBM hackers list was whinging that he'd prefer a full-size SD card; for anyone who feels the same, here's a clever almost-free DIY adapter that would let you use a full-size card (and a uSD with adapter of course) in the PETdisk:

http://www.instructables.com/id/Chea...dboard-socket/
This is great! I like it.

Excellent! You can combine Steve's and mine to save postage.
Will do, thanks. Luckily when I ordered a bunch of the uSD adapters they all came with individual plastic cases, and I had been wondering what to do with all of them - I can use them to protect the upgraded chips when sending them out.

Kudos and thanks for the effort you're putting into this, BTW; It's one thing to come up with a clever device like this, but often the developer quickly loses interest when it comes to documentation, support and upgrades... - thanks again!
You're very welcome, thanks for bearing with me through this process. It has been fun to work on it so far, and with a few additional upgrades it could be a much better device.
 
I know I have that slightly off-spec prototype, but do I qualify for a free chip upgrade? ;^)
Definitely. I can also swap out your PETdisk for a newer one if you want.. or who knows, it might be a great eBay item in the future. :)
 
Definitely. I can also swap out your PETdisk for a newer one if you want.. or who knows, it might be a great eBay item in the future. :)

*snicker* I can just see it now... VINTAGE! **RARE PROTOTYPE** @@@BLAWBLAWBLAW@@@ ;^)

I was actually thinking of getting a second one if you still have boards. The guy I gave the chicklet 2001-8 to could use one.
 
Back
Top