• Please review our updated Terms and Rules here

A PET storage option

Great videos!
Please put me on the list for two kits.

Just out of curiosity, have you tried piggybacking two of your units set up as different drive numbers? Not that I want to do this, just wondering if it would work. Don't see why not.

Oh, and to answer your other question about the 'Pet in a suitcase' here is a pic:

Suitcase 2001.jpg

I have about 14mm from the end of the cassete port to the side of the case (or to put it another way, about 25mm from the base of the cassete port to the side of the case)....not much room. However, It's not really an issue as I could always use the cassette port 2 for power, but if I want to load cassette data using cassette leads I'd prefer cassette port 1.

Thanks for a great looking product.
 
Last edited:
Do you know how these commands work on the IEEE-488 bus?

No, I don't, but BASIC 4 commands are just frosting on the cake. The old way with LOAD "$",8 will do. Actually, I would think the Commodore DOS Universal Wedge shortcuts would work if loaded into the PET as I think they are transparent to the IEEE interface. The shortcuts have been incorporated into several EPROM based utilities like BATPRO. Commands like >$ can be used in place of LOAD "$",8. I'll give them a try when I get my PETdisk.
 
Of course the main difference is that LOAD will overwrite whichever Basic program you already have in memory, while DIRECTORY, various wedges and so on just display the directory content on screen. I do think those retrieve one sector at a time from the floppy drive, possibly through the U1 or B-R commands, and keeping track of how the directory structure is supposed to look. While I have mostly studied the 1541 structure, I believe in general all drives look the same. The directory track is located elsewhere on a 8x50, but probably there is a way to M-R the floppy drive to detect which type of drive it is before reading the directory.

Of course this is speculation and I may have forgotten some special way to get a stream of directory content. I made a quick test to OPEN the file $ for reading with GET#, but it doesn't seem to yield anything.
 
It does not at the moment. But I would like to support these in a future revision. Do you know how these commands work on the IEEE-488 bus?
Basically these commands translate into the same bus commands and sequences of BASIC 2. There are two differences I noticed: ds$ does not get the status all the time, only if there has been some new bus action. If not, it's taken from the computers memory, not from the drive. CATALOG does just the same as LOAD"$",8 but the transfer is paused with UNTALK commands and restarted with TALK 8 / DATA secondary address a lot of times.
 
Hello Gubbish,

you can add me on the list of a potential buyer for your great product.

I'm ok to buy a "Fully Assembled & tested: $30"

I will send you a PM and do some advertisement for your product on a forum speaking about Vintage computers.

Congrats and thanks for working with the oldies.

JJP
 
I've finally got a chance to play with my new PETDISK. (I got in on the ground floor, I guess. I traded Gubbish some stuff made by another well-known maker of 6502-based computers for some helpful PET bits that should keep me busy for quite a while. Thank you very much!)

First impressions are is that it seems to function just as advertised. The only gotchyas I'll note:

1: Based on the jumper position visible in the example video my disk came set for device nine. Unfortunately, and I know it's a silly problem to have, the "9" key on the PET I was trying it on doesn't seem to want to work, heck or high water. (I'm sure it's just dirty, as all the keys are a little gummy. It just struck me as amusing that the particular key I needed wasn't behaving at all.) Through trial and error I managed to get it set to device 8. I'm sure the documentation issues will be worked out. (Maybe they already are and I'm missing the link.)

2. Maybe this isn't a general rule, but... don't format your Micro SD card on a Mac. The Mac seemed to insist on formatting flash drives as if they were hard drives, in that it creates a partition table, and I couldn't find an easy way to override that behavior. (You can see this by looking at the mounted devices. A Mac-formatted SD card will show up as "/dev/disk[number]s1", the "s" meaning "slice") The PETDISK doesn't seem to grok partition tables, leading to some weird behavior. Using "dd" to wipe the card clean and formatting it on a Windows machine fixed the problem. (Stick the card in your Mac after that and you'll see it mounted simply as "/dev/disk[number]".) Formatting the root device on a Linux machine would undoubtedly work as well.

Anyway, it seems to be a great simple solution to the file transfer problem. Are you planning to get a Sourceforge or similar page for storing the documentation/driver code? I'd love to be able to track the firmware as it progresses and possibly contribute if I can.
 
Hey there,

Glad it's working for you! Sorry about the confusion with the device number: I haven't had a chance to make proper documentation for it yet, but it will be coming very soon.
For future reference, if you are looking at the PETdisk and the female edge connector is facing you, there are 4 header pins.
On yours, Eud, there are 6 pins. The right two pins are a serial transmit pin that I used for debugging, and ground. At the moment these don't have any jumpering function, and I'm leaving these out in future builds. In any case, let's say pin 1 is the leftmost, and counting up to the right.
jumper settings:
Device 8: no jumper
Device 9: jumper on pin 3&4
Device 10: jumper on pin 1&2
Device 11 (these go up to 11..): jumper on pin 1&2, second jumper on 3&4.

Basically 3&4 is bit 0 and 1&2 is bit 1 of a binary number, where jumper off = 0, jumper on = 1. Add that number to 8 to get your device number.

I would definitely like to get a Sourceforge page up with the code & docs. I'll look into this and try to have it up shortly. It would be great to have collaboration on the firmware. One of the next improvements to the firmware will have to be some optimization to the code to shrink the code size. I'm running right up to the device's 8k code capacity, but I'm sure this can be reduced with some clever code reduction.

I haven't tried formatting on a Mac, as the only computer I have with an SD interface is a WinXP laptop. Even on windows, it's important to select FAT32 instead of just FAT when formatting the card. I don't know the exact differences, but they are sufficient to make it not work properly.
 
Hi,

great, we're getting close to a good number for a second run of boards.
Here's a little question to the group - one small revision I was planning for the new batch was to change the orientation of the USB power connector on the PETdisk board.
The current design has a USB connector on the PETdisk pointing in the direction of the cassette port. I noticed that this would likely block the user port in case someone wanted to use a user port accessory at the same time as the PETdisk. The revision would be to use a vertical USB connector, pointing up, to avoid blocking the userport. Does this sound like a useful modification?
The current design can accomodate a vertical connector with a bit of pin-bending. But it would be easier to assemble with a slight PCB layout change. Of course any change to a PCB makes one a little nervous, especially when ordering a larger number :)
 
CATALOG does just the same as LOAD"$",8 but the transfer is paused with UNTALK commands and restarted with TALK 8 / DATA secondary address a lot of times.

The DIRECTORY command may use the UNTALK and TALK a lot because the user may pause the display with the space bar, and continue with any other key. The 8000 series machines apparently use the colon key and the 3 key.
 
The current design has a USB connector on the PETdisk pointing in the direction of the cassette port. I noticed that this would likely block the user port in case someone wanted to use a user port accessory at the same time as the PETdisk.

I would vote to change to a vertical connector at the next update as some people may use the user port for the prlink cable for the cbmlink software or for a diagnostic connector to bring the PET into the machine language monitor on power up.

In the old days the port was used quite a bit for custom software/hardware applications. I once had a 300 baud MODEM hooked up to the user port.
 
Hi all,
Thanks for the response, sounds like vertical connector is the way to go.

The first few boards are about to be sent off, and it looks like we have enough orders to go ahead with the next batch of boards. Thanks for the interest!
Wanted to let everyone know that I'll be out of town for a few days travelling, so there's still time to get in for the next batch if you're interested.
Will be back home next friday the 26th and will be sending out the orders from the next batch shortly afterward. I'll make the board order a couple of days prior so the PCBs will arrive just as I'm getting home. With the weekend of the 27th/28th to double check the new batch, I'll be aiming to send them out starting August 29th, Monday. I'll contact everyone who ordered by PM within the next few days with more details. More documentation is also coming soon, and I'll be posting the code and schematics.
Thanks again..
 
Don't you give up on yours, though!

Am I right that Mike's deals with individual .PRG files whereas Seth's uses image files?

Oh, I'm not going to give up on mine, don't worry! The one I've built uses the standard sd2iec firmware, so it works both with standard .PRG file storage (the whole card looks like one large filesystem) or with images.

I am however unable to get a new run of boards for the next couple of weeks, since I'll be out of town :( Life has been hectic. I expect to have a batch of kits ready to sell within 30 days. Long lead time, I know, but it can't be helped.

When I get back, I hope to grab one of Gubbish's boards, too. The more the merrier!

-Twylo
 
sounds good, please count me in for one of your boards as well.
It would be great to join forces on a future project, PET or otherwise. Any other ideas for PET add-ons that would be useful?
I'm out of town right now also, but will be back soon to get the batch of PETdisks ready.
 
Hey all,

I just sent out PMs to everyone who ordered one or more PETdisks. If you want one, and did not receive a PM, please PM me and I'll put you on the list. I will be ordering a few extras to accomodate some later orders.

One thing occurred to me which I wanted to share with everyone -
The current firmware of the PETdisk works and has been tested with what are called the "new" PET ROMs in the IEEE-488 book. To my understanding, these are the ROMs which give you
"#### COMMODORE BASIC ####"
as opposed to
"**** COMMODORE BASIC ****".

The "new" ROMs also include BASIC 4.0. At the moment I only have these "new" ROM PETs for testing, although I do have an 8k 2001-8 which I believe has the original ROMs but it needs repair. According to the PET IEEE spec, the old pet roms have a slightly non-standard method of using the IEEE-488 bus and have a slightly different command sequence for the LOAD and SAVE commands, so I do not currently know if the old rom PETs will work with the current PETdisk firmware. This can certainly be added in a later firmware, possibly by someone who has one of the working old rom PETs for testing. The cassette interface, however, will still work with the old rom PETs.

Just wanted to give you this information to avoid any problems in the future. If I can repair the 8k pet I'll do a firmware update to get the PETdisk working with the older ROMs. And if this information affects your order at all, just let me know. Thanks!
 
The current sd2iec firmware definitely won't work with old ROMs aka BASIC 1. The BASIC 1 bus protocol is completly differnent but I think, it's possible to implement it. From what I've read, it seems to be necessary to press RUN/STOP after LOAD because the old ROMs cannot recognize the end - not a great problem. If you program the AVRs with a bootloader like the "newboot" from sd2iec.de, it's easy to update the firmware by simply putting the new version into the root directory of the SD card. So it's easy to update to BASIC 1 compatibility when it's available.
 
And then there are the 'in-between' ROMs, alternately known as BASIC2 or BASIC3 or just the 'upgrade ROMs' which corrected the problems that the original ROMs had with the IEEE routiines; I'd expect those to work OK.
 
User Report

User Report

System: 8032 PET BASIC 4 ROMs

LOAD, SAVE and LOAD"$" work correctly.

Notes:
When saving a PET program file from the PC to PETdisk, the extension .prg had be used in order for the PET LOAD command to find the file on the PETdisk. This is not necessary on a 4040 drive.

The DIRECTORY command results in a "?device not present" error which indicates the PETdisk did not respond to an Attention sequence.

The BATPRO LOAD command "/filename" results in a "?load error", but most of the file is loaded into the PET RAM.
I'll try the Commodore Wedge commands soon. Overall, I'm pleased with the gadget.
-Dave
 
Back
Top