• Please review our updated Terms and Rules here

A PET storage option

This morning I did my first PET-ing after a week of vacation. Here's some possibly relevant things I discovered regarding IEEE compatibility:

I finally got around to trying the two disk drives I picked up from the Albany PET dump that passed internal diagnostics; an 8050 and an MSD SD-1. Oddly enough considering how lousy my luck was with PETs both drives appear to work perfectly so far. (NEW-ing a disk works, as do, SAVE, LOAD, and VERIFY. I do wonder if a capacitor might be going in the 8050's power supply as I can hear a slight buzzing/whining out of it.) I did my testing on an 9" 4032 with the PETdisk inline. And here's what I found:

PETdisk+8050: Seems to work perfectly. LOAD-ed several downloaded programs off the PETdisk (jumpered as #9) and saved them back to the 8050 (#8,0/1). No issues at all.

PETdisk+MSD SD-1: Not happy. I don't know if the PETdisk or the SD-1 is at fault, but in my limited testing I'd find that the SD-1 would seem to work fine until I did something with the PETdisk, after which sadness and confusion would set in. Sometimes a LOAD "$",9 works on the PETdisk, sometimes it doesn't, loading software from it is likewise hit-and-miss, and there's also a good chance the SD-1 will go off the air at some point. (Power cycling it sometimes brings it back, but it screws up again as soon as the PETdisk gets invoked.)

PETdisk+MSD SD-1+8050: With the SD-1 and PETdisk chained up I entered a BASIC program from the SD-1's manual to change its bus ID to #10, and once changed I wired up the 8050 with a stacking daisy chain cable and powered it up. This configuration again seems to work perfectly, as I'm able to LOAD/SAVE/VERIFY on any drive. I wasn't playing with it for that long but everything seemed fine the whole time. So...

I have no idea what's up with the PETdisk not getting along with the SD-1 and why the problem seems to go away when the 8050's in the mix. It could well be a problem with the SD-1 but it is curious. By any chance does anyone know if the same BASIC program to change drive IDs on the SD-1 will work on an 8050, or have a link to a program that will? (It appears the SD-1's program is the same as that in the 1541's documentation but I can't seem to find the 8050's user manual anywhere. The service manual only covers the hardware method.) I'm sort of curious if the problem would occur if they were daisy chained with the 8050 "closest" to the PET instead of the SD-1.
 
Thanks very much for the report. Strange that the PETdisk would work if attached to an SD-1 and an 8050 but not if attached to an SD-1 alone. It sounds like the PETdisk is getting stuck in a waiting state and is holding one or more of the lines where they should have been released. Could be something about the timing of the SD-1 vs the 8050, but I'm not sure. Will look more into this..
 
Great, please let me know how it works.
I received another report from another PETdisk user which might be useful to others here:
assuming the PETdisk is set to device #9:
LOAD "$",9, LOAD "exactname",9, and SAVE "exactname",9 work, but
LOAD "*",9 or LOAD "something*",9 do not work as they do in commodore DOS. Wildcards are not implemented in this version of the firmware, but I've added it to the queue for things for the next revision.

Still meaning to post the full code and schematics for the PETdisk, so if you want to get down into the bits and bytes, you can. Will let you know as soon as these are up. Sorry on the delay on these, non vintage computer obligations have been taking up too much time recently. :)
 
I assembled my petdisk last night and cannot get it to work. I've checked all the solder connections, and verified voltage to the atmel.
I get no device found on 8,9,10 or 11.

I've only got 1 sd card to try, Kingston 1gb formatted as fat and as fat32, no luck.

I'll have to build a isp programmer to check the atmel, as my gq-4x doesn't allow me to just plug it in the unit.

Later,
dabone
 
Hi dabone,

I'm sorry to hear it's not working for you,
I'll send you a PM and will try to walk through the troubleshooting process.
One thing is just to doublecheck that the atmel chip is facing the right direction, pin 1 toward the top of the board. Also just please confirm that the zener diodes all have the black stripe going to the square pads on the board.
If possible, please send me some photos of the assembled board, and I'll see if I can identify any problems visually. I'm sure we can get it sorted out. If not I'll be happy to exchange it for an assembled unit. Sorry for the difficulty!
 
One additional thing to try if these fail. To the right of the 28-pin socket on the petdisk board, you will see two holes on the board. Add a wire jumper between these holes, this will directly tie pin 1 of the atmel (reset) to +5v, ensuring that the chip is not held in a reset state. Also, please double check that no pins have been bent when inserting the atmel chip, this happened to me several times.
 
Also, could you tell me what type of PET you have, and what type of BASIC ROM is in the pet. If you have an IEEE drive, also please confirm that the IEEE functionality of the PET is working properly with that drive alone.
 
Hi there,

Just wanted to let you know that I did some research into how to make a very simple serial port programmer to load new code onto the Atmel chip on the PETdisk.
I followed this schematic:
http://avrprogrammers.com/bld-dasa.php

This design requires only a few parts: a 9-pin female serial connector, 3 4.7k resistors, and 3 5.1v zener diodes.
Wired it up, and attempted first to read the code from one of the existing PETdisk atmel chips.
Tried to do this with a USB to serial adapter connected to a Mac, and no success. I did read on the schematic site that USB serial adapters might not work because of timing issues, so I was not thoroughly surprised.
Then I tried again using an old PC laptop with a serial port, running Ubuntu. Using avrdude, an avr programmer (there is a package for it in ubuntu) and was able to read the contents of the chip with no errors.

So I can recommend this simple design for people with access to a real serial port. There may be a way to make it work with a usb-serial adapter but I had no luck. I will post a slightly modified version of this up on http://bitfixer.com, along with exact instructions on how to connect to your PETdisk to update the firmware.

I am hoping to include a bootloader in a future revision of the code which will allow software update directly from the SD card without needing to go through the serial programming process, but I'm not quite there yet.
Stay tuned for updates and please send any questions you have.
Thanks and hope this is useful.
 
Also, could you tell me what type of PET you have, and what type of BASIC ROM is in the pet. If you have an IEEE drive, also please confirm that the IEEE functionality of the PET is working properly with that drive alone.

Pet is a 2001-8 with a 320008 motherboard, equipped with Nicholas Welte's ram/rom board. I have basic 4 selected along with 32k of ram.
The Pet works fine with a MSD-2 disk drive. For my tests I don't have anything but the petdisk connected. The only strange thing I have noticed is that I'm getting 4.8 volts to the atmel, I'm wondering if I need to track down a shorter usb cable. (I only have a couple of 6' ones, they work fine with my eprom programmer)
But when I used to play around with the atmels from my sat days, they weren't very picky on the voltage.

Later,
dabone
 
Thanks for the info,

4.8 volts sounds reasonable. The chip can run on 3.3v without complaint so 4.8 would not be a problem.
This should be at pin 7 on the atmel, and pin 8 is ground, this would be good to confirm.
Basic 4 is fine..
Here's something simple to try to check for a bridged connection -
Remove the Atmel, the jumper, and the SD card adapter, and connect the empty board to your PET. Connect the MSD-2 to the passthrough connector. Then turn on the pet and try doing something with the MSD-2.
If everything is ok, then we'll have to look a little harder for the problem. If things don't work normally, then there is probably a solder bridge somewhere. Each pin on the edge connector should have continuity with the corresponding pad on the passthrough connector, that would be a good thing to check. And also each pin should not connect to any other pad (except for the grounds, which are all connected).

If you have a second PET to test with, that would also be useful to check.
Also whenever you get a chance, if you could take some pictures of the board, that would be useful. I'll see if I can visually identify any problems.
 
Ok passthru doesn't work until the atmel is removed or pin 7 lifted. Then passthru works just fine. So I'm wondering if this is a software issue.
The atmel reads fine with my programmer and gives a code checksum of 000F68CA.
This is with the chip installed in the petdisk board and using usb power and then running the isp programming lines over to my GQ-4x programmer.
I don't have the firmware to compare it to so I'm not sure if this is a valid checksum.
The 512 byte eeprom area of the chip is blank. There is only data in the 8k flash.

Alas, I only have my one pet.

Later,
dabone
 
Hi dabone,

Just put the hex file for the firmware up, it is at:
http://bitfixer.com/data/PETDisk_m8.hex

You can check what you read against this file. Intel hex format I believe.
It is sounding like a software issue. If you get a chance, please try tying pin 1 on the atmel to +5v. Sounds like there is a possibility the chip is not resetting properly.
 
Last edited:
Sounds good. I will put together some test hex files when I can, which can individually test functions of the board. First something that just responds to a directory command on any device number with some dummy information, to confirm that the IEEE-488 handshaking is happening. Then we can work from there.
 
Found a different sd card this morning, and it worked first try.


All better now.

Non working card is labeled.

Kingston 1GB MicroSD 0713U89430U SD-C01G Japan

Working card is

Kingston 2GB Microsd SD-C02G Japan SDC/2GB 35


I will say this to everyone, gubbish PMed me and offered to send me a pre assembled unit, so he is really putting the effort into these things.
Keep up the good work, but PLEASE PLEASE PLEASE PLEASE, get wildcard support working. I really use that function.

Later,
dabone
 
Hey dabone,

Very happy things are working with the new SD card. I will see if I can find out what was happening with the first card, so I can fix it and avoid others running into the same issue.

Wildcard support should be a relatively simple addition to the firmware, so I'm thinking I will try to get that working first. Look for version 1.1 of the firmware including that feature in a few days.

Thanks very much for the debug effort and happy computing..
 
Hi gubbish

Spent yesterday building the Pet Disk kit, good instructions on the website, had a bit of a sweat on
cutting the board but apart from that it all went well.

After checking all the tracks for bridges all looked ok!

Upon powering on all went well it would recognise the pet disk but would not read it or write to it.
It turned out I needed to put a label for the memory card (used "storage") as it was blank at first.
Once I did that it worked and i could read the directories.

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!

Once renamed and put back into the Pet Disk, Happy Days!! :D A brilliant solution for pet file transfers!!

I would just like to say what a great piece of kit that brings life back into using the Pet!!
Hats off to you my friend!! Well Done!!

PS I'm using a 2gb Sandisk.
 
Back
Top