petSD

[for()]

I'm curious about the features added by installing the USB and ethernet capabilities. What do these permit beyond the basic kit? Is there special client software required to use them?

Software and hardware are kind of related. You all know this: your software has some hardware requirements and as the software grows, it's requirements increases. That's the time, you go and by new more powerful hardware again. At a later time, when software has grown again, you buy new hardware for the third time and so on...
For the petSD I wanted to go the opposite way: make a hardware that fits my needs for years, even if the software won't be able to use the hardware for a very long time. At least, this way you pay only once.

The petSD's USB interface gives you a virtual serial COM port on your PC/Mac. At the moment, it let's you read some debug messages and that's it. You won't need any special client software, any terminal program (like Hyperterminal on Windows) will do the job.
After having solved some other problems, I'd like to add an additional server software acting as a file server, sharing some files over USB hosted on the PC.

Ethernet isn't supported at all and I'm afraid, it will take a long time until we see this. I ported the OpenMCP firmware to the petSD to play around with this, it's an AVR based Web Server. It showed, the hardware is allright, but the software is very unstable. It crashes after delivering a few files from SD card. Still a very long way 'till I'll write my first mail on CBM.

Also, what is connector K14 for? Is that the serial port? If so, what are the various signals?

K14 is a serial port, it's an SPI bus completly incompatible to the Commodore serial IEC bus for floppy drives or RS-232. It's used for in-system-programming of the microcontroller and this microcontroller talks to the SD card and the Ethernet chip over the same SPI bus.

MISO=master in, slave out
MOSI=master out, slave in
SCK=serial clock (provided by master)
RES=/RESET (system reset, same as button S3)

If you google for "spi bus", you'll find whatever you'd like to know. If you'd like to buy a in-system-programmer and can afford, buy an AVR ispmkII, if you own a PC with parallel port and can solder, you'd like to try one of the very cheap STK200-compatible clones.

 

[shirsch]

Success! I built my petSD this morning and it seems to work - at least I can save files to it and list them back. However, not sure where to go from here. The readme is probably helpful to experienced C64 and PET users, but is somewhat incomprehensible to me. Is there anything resembling a "howto" or beginners's guide? For example, I'm not clear on how it maps raw files in the FAT filesystem vs. complete images in the FAT filesystem. Are both supported?

I do not fully understand how to assign a specific device number, etc, etc.

 

[for()]

Sorry, no. There's no HOWTO yet. I'm still struggling with the IEEE-488-bus routines.

FAT filesystem and disk images are both supported. Disk images are handled like a subdirectory, you mount them by sending CD:NAME.D82 to the command channel #15, e.g. with a wedge.
But you can use plain FAT files as well, and if it is important to have some strange characters inside the file name that only commodore has, but ANSI hasn't, you can store your files in a P00/S00/R00-container file on the FAT file system.

Change the device address with:

open 1,<olddeviceaddress>,15,"u0>"+chr$(<newdeviceaddress>):close 1

...and if the petSD shall remember it's new device address after power off, add this:

open 1,<newdeviceaddress>,15,"xw":close 1

 

[shirsch]

Sorry, no. There's no HOWTO yet. I'm still struggling with the IEEE-488-bus routines.
]

Ok, thanks. In the interim, I found some further information on the web regarding the CMD hard disk and downloaded a manual scan. Things are making a little more sense after reading the command structure.

However, I cannot find a shred of information on "P00/S00/R00" file containers. What are these? Where can I find out more?

And finally, you mentioned something about using a second partition on the SD card. I'll accept that it works, but would I be correct in assuming it's utterly undocumented? Couldn't find a mention in the README.

Sorry for the stumbling confusion, but I'm having trouble getting a foothold on the territory.

 

[for()]

However, I cannot find a shred of information on "P00/S00/R00" file containers. What are these? Where can I find out more?

Basically they're a container for Commodore DOS files preserving the original file name encoded in PETSCII and some additional information like file type (PRG/SEQ...) and block size for REL-files. Have a look at:
http://petlibrary.tripod.com/PC64.HTM

And finally, you mentioned something about using a second partition on the SD card. I'll accept that it works, but would I be correct in assuming it's utterly undocumented? Couldn't find a mention in the README.

The README contains a chapter "Partition". You should find everything but examples there.

Sorry for the stumbling confusion, but I'm having trouble getting a foothold on the territory.

It's not your fault. The documentation isn't very newcomer-friendly at all. It should get rewritten, but for months all spare time for petSD went into struggling with the bus routines. Unfortunately, they're still an ugly hack and everything beyond basic tasks like LOAD and SAVE can fail. You can see this in CATALOG aborting sometimes. In combination with CBM-II, things get even worse. I should really fix this first.

 

[carlsson]

While I shouldn't say I'm happy you're having problems interfacing it to a CBM-II, it confirms what I have found out myself when connecting my Corvus/SSE hard drive system to a CBM 610. I think it has been mentioned on the PET! Alive forum and/or here, and I think someone even came up with a plausible explanation what causes the differences in IEEE-488 bus timing/whatever between the PET line and the CBM-II line. All the genuine Commodore peripherals appear to be compatible, probably including the D90x0 hard drives which suggests they may have a little "slack" in timing requirements compared to what a specification would state.

 

[sjgray]

While I shouldn't say I'm happy you're having problems interfacing it to a CBM-II, it confirms what I have found out myself when connecting my Corvus/SSE hard drive system to a CBM 610. I think it has been mentioned on the PET! Alive forum and/or here, and I think someone even came up with a plausible explanation what causes the differences in IEEE-488 bus timing/whatever between the PET line and the CBM-II line. All the genuine Commodore peripherals appear to be compatible, probably including the D90x0 hard drives which suggests they may have a little "slack" in timing requirements compared to what a specification would state.

The cbm-ii's actually implement the ieee bus correctly, at least on the latest revision roms. Mike Naberezny has been investigating the differences in ieee implementation between the pets and cbm-ii's. I think there is a poke you can do on the cbm-ii to make it act more like a pet. The poke made it possible for me to run softbox on one of my cbm-ii's.

Steve

 

[for()]

Mike Naberezny has been investigating the differences in ieee implementation between the pets and cbm-ii's.

Is that documented somewhere? I'd be very interested in the results!

 

[sjgray]

I don't think he's finished his investigations, but i mentioned to him that you were interested.
Mike gave me this poke for cbm-ii to prevent the softbox from attempting to go into standalone mode. Apparently it releases or sets one of the ieee control lines. Also, this seems to only be needed for newer cbm-ii firmware...

Poke 56832,58

Steve

 

[mnaberez]

You can see this in CATALOG aborting sometimes. In combination with CBM-II, things get even worse.

I've been using PetSD with the 610 for several months now. I have noticed the issue with CATALOG. PetSD does work on the 610 at least for casual use. I primarily use it to load in a short program (around 10 blocks) into the 610. I've probably done this a hundred times now and have not had issues.

Mike Naberezny has been investigating the differences in ieee implementation between the pets and cbm-ii's.

Is that documented somewhere? I'd be very interested in the results!

I did port the SoftBox's IEEE-488 code from PET/CBM to CBM-II. However, the SoftBox does not use the KERNAL routines so this will not help debugging PetSD.

There is commented source code available for the CBM-II KERNAL that I have found to be very useful. You can download it from David Viner's website.

Poke 56832,58

This POKE has to do with the REN line. On PET/CBM, IFC is tied to the system reset and REN is tied low. On CBM-II, both of these lines are programmable. The newer 901244-04 KERNAL programs REN low at startup. The older -03 KERNAL does not.

The SoftBox uses REN to detect if a computer is on the IEEE-488 bus. If it is REN is not low, it will not detect the computer. This is why the POKE is needed on the older KERNAL version. To my knowledge, no CBM peripherals use the REN line.

 

[shirsch]

I have a "D80" image that I'd like to access from a PetSD. Is this not supported? The README does not mention it, but since it's the storage format from an 8050 PET drive I thought I'd at least ask in case the docs weren't up to date. Anyone know for sure?

 

[for()]

I do. I once wrote the D80/D82 support, but it didn't find its way into the sd2iec repository. Meanwhile, IK changed a lot in the disk image code, so it's not that easy to add the lost pieces. I won't touch this again.

The good news: Edilbert Kirk added disk image support to the new XD-2031 firmware. Runs on petSD too. At the moment, I'm testing this, the code came just yesterday.

 

[shirsch]

I do. I once wrote the D80/D82 support, but it didn't find its way into the sd2iec repository. Meanwhile, IK changed a lot in the disk image code, so it's not that easy to add the lost pieces. I won't touch this again.

The good news: Edilbert Kirk added disk image support to the new XD-2031 firmware. Runs on petSD too. At the moment, I'm testing this, the code came just yesterday.

Hmm. A couple of problems with that. My PetSD does not have a USB port and the firmware is apparently too old to support it anyway. What's involved in adding the port and how do I update the firmware?

Sounds like you haven't received much cooperation from the sd2iec folks. That's a shame if so.

 

[for()]

Well, in theory you don't need the USB interface to update the firmware. Simply put the new binary in the root directory of the SD card, the bootloader will find it and flash it -- that's it.

But unfortunately, this will not turn a sd2iec petSD into a XD-2031 petSD. The reason are the AVR fuses. These fuses control things like e.g. how the clock is generated: whether a crystal is used, internal rc oscillator etc. The bootloader can not change the fuses. It can only update the flash.
When porting sd2iec to petSD, I always used the serial port over USB for debug purposes. Everything was fine, so it shipped. Later then, when I was porting XD-2031 to petSD, I had a bad surprise: it crashed all the time and it took me quite a while to find out why -- and it sounds kind of crazy but it was clearly reproducible: the fuses settings controlling the crystal oscillator don't work stable with the XD-2031 firmware. No reported problem for the old sd2iec though. The bad news: to update the fuses, an AVR ISP programmer is required.

If you get such a programmer ($34, much cheaper if you build one by yourself for a PC with LPT port, say: STK200 clone), updating the firmware is very easy and controlled by a script. Hard to do it wrong.

Updating the parts for USB requires to solder a SMD chip: the FT232RL. For a complete list of the required parts, please have a look at the configurable parts list and set everything to zero, except "Optional parts for USB" equal one.

If you are interested, I can do all the re-fusing and solder works for you for the costs of the required parts and postage to/from Germany.

This upgrade is free of risks: you can get back to sd2iec at any time.

I'm thankful to IK: without his sd2iec firmware, the petSD would have never existed. He's an excellent programmer and I learned a lot by studying his code. Of course, it took and takes time to switch to another firmware, but XD-2031 has a wonderful architecture made by André Fachat that does not limit the device to SD cards. We have a mailing list now, and developing in a team is much more fun.

 

[shirsch]

The bad news: to update the fuses, an AVR ISP programmer is required.

If you get such a programmer ($34, much cheaper if you build one by yourself for a PC with LPT port, say: STK200 clone), updating the firmware is very easy and controlled by a script. Hard to do it wrong.

Updating the parts for USB requires to solder a SMD chip: the FT232RL. For a complete list of the required parts, please have a look at the configurable parts list and set everything to zero, except "Optional parts for USB" equal one.

If you are interested, I can do all the re-fusing and solder works for you for the costs of the required parts and postage to/from Germany.

Wow, thanks for the thorough writeup! Much appreciated. This programmer is not a JTAG unit, then? I have a couple of JTAG pods that I've used with Xilinx FPGAs. If it comes to that, $34 is not a big deal and I wouldn't mind buying one of those. Just want to be sure I don't already have something that can do the job.

(Update) Found this one: http://www.pololu.com/catalog/product/1300

SMD soldering is not my favorite way to spend an afternoon, but I have a nice reflow tool and the necessary materials. I think I can tackle this myself (maybe famous last words ).

 

[shirsch]

I have a question about the XD firmware. Is it capable of emulating a two-drive disk unit such as a 4040 or 8050? I believe this was not fully supported with the old firmware (it could show two drives, but didn't automatically search the other drive).

 

[for()]

The pololu programmer seems to be compatible with AVRDUDE, so you could use it. Of course you'd have to edit the flash script (just a text file) to reflect the type of programmer, but that's easy. You're right: the ISP is not JTAG. It's an AVR protocol using the SPI bus.

sd2iec uses the Commodore drive:filename scheme to access several partitions on a SD-card, giving actually a partition:filename scheme.

XD-2031 is rather a ten-drive disk unit than a two-drive one. There are a number of so called "providers" you can assign to a specific drive (PC filesystem over USB, SD card, disk image, FTP etc). But the way filenames without drive numbers are handled is still different to CBM drives, breaking at least the PETSPEED compiler.

On a CBM drive, a LOAD"FILENAME",8 would search both drives. If it isn't on 0:, it would load from drive 1. A SAVE"FILENAME",8 would save at drive 1 if there is no floppy in drive 0.

XD-2031 uses a "last drive" at the moment. It remembers the last drive number given and makes this a "current" drive. So, if you LOAD"$1:*",8 // LIST followed by a LOAD"PRG",8 this file PRG would load from drive 1.

Having a "current" drive is quite handy if you're working with multiple drives, but as I mentioned already, it's incompatible and may break a program that relies on the CBM behavior. But we've got that issue on our list and will implement a compatible solution as well.

 

[shirsch]

Having a "current" drive is quite handy if you're working with multiple drives, but as I mentioned already, it's incompatible and may break a program that relies on the CBM behavior. But we've got that issue on our list and will implement a compatible solution as well.

Depending upon the complexity of the server software and the platform on which it's intended to run, I may be able to help with this. In my secret identity (when not hacking classic computers) I'm a software engineer with some years of experience. My primary issue is - wait for it - finding the time .

 

[shirsch]

It works! I have installed the USB port and updated fuses and firmware. I'm able to list directories and load files from the SuperPET .

You had mentioned that disk image support was just added, but I cannot find any examples of how to specify this as a channel source. Can you tell me how to get that going?

 

[for()]

André explained this via mailing list. If that doesn't work for you, please let me know.