• Please review our updated Terms and Rules here

Is there interest for another SD card disk emulator for IEEE-488 or IEC interfaces?

R

Radix

Experienced Member
Joined
Dec 7, 2022
Messages
304
Location
Midlands, UK
Hi all - new here and great to find the community...
For various reasons, I find myself developing an SD card Disk emulator, currently for PETs with IEEE-488, but it could also do C64 IEC serial...

Are people interested in this? - And if so - what would make it useful compared to the other offerings already out there? - I mean features and compatibility - what features are missing from existing devices that would be of use?

Ideas like being able to connect to a -SK PET with the "proper" connector, and emulating (at least) drives 0 and 1 come to mind - but what else would be useful?

All (polite!) ideas welcome,

Robin
 
Developers/suppliers of gadgets ebb and flow... I think it's always useful to see alternatives... if you build it they will come!
 
Last edited:
One thing from the hardware perspective for the PET, that would help, is to bring the connector right through your SD card unit, so that the PET's IEEE-488 edge connector is not hogged by the presence of the unit. This is an issue with the SD2PET and I had to build a special adapter for that. For example, I use this to have the SD2PET and another real disk drive running at the same time or an adapter for a printer.

The adapter I made rotated the body of the SD2PET 90 degrees if I use that connector, so the SD card faces upwards and that turned out to be quite convenient reaching behind the computer to change the card.

I also have a feeling (but I might be wrong) that in the case of the Commodore disk drives, with two units in the same box, designated drive 0 and drive 1, it was possible to do a disk to disk copy ?, but not possible with two separate single disk drives. Might be wrong about that, but if it was true, that would be a great feature that your unit would act like a dual drive unit, I guess it would then have two SD cards ?

Here is a link to the adapter I made , required because the SD2PET hogged the connector:

 
Last edited:
I've got some of the petdisk max, but always love playing with new toys.

If you do add wifi, maybe a firmware option to allow connecting another cable to the user port and using it as a modem also?

Or, an inexpensive one that actually emulates a disk drive, not file based. There's not a lot of disk image based pet stuff, I can think of Zork as a example. Last time I tried it with a pet disk it didn't work (But that's been awhile)
 
Hugo Holden said:
I also have a feeling (but I might be wrong) that in the case of the Commodore disk drives, with two units in the same box, designated drive 0 and drive 1, it was possible to do a disk to disk copy ?, but not possible with two separate single disk drives. Might be wrong about that, but if it was true, that would be a great feature that your unit would act like a dual drive unit, I guess it would then have two SD cards ?
Click to expand...
The Commodore PETs didn't have a native copy command allowing device to device (strange) - as you pointed out - dual drive devices would allow you to do that since they handled the logic internally.
There might have been one or two copy programs over time for the PET that did facilitate device to device (it's been so long) - Maybe Copyall (Jim Butterfield).
 
NoPizzaTonite said:
The Commodore PETs didn't have a native copy command allowing device to device (strange) - as you pointed out - dual drive devices would allow you to do that since they handled the logic internally.
There might have been one or two copy programs over time for the PET that did facilitate device to device (it's been so long) - Maybe Copyall (Jim Butterfield).
Click to expand...
My feeling is that if a dual SD card equivalent of the dual disk drive units could be fabricated, which had exactly the same performance of the dual Commodore disk drives, with no quirks and no bugs, that would really be something special.

I tried some disk to disk to disk copy utilities for the PET, but they fell on their heads,
 
Radix said:
Hi all - new here and great to find the community...
For various reasons, I find myself developing an SD card Disk emulator, currently for PETs with IEEE-488, but it could also do C64 IEC serial...

Are people interested in this? - And if so - what would make it useful compared to the other offerings already out there? - I mean features and compatibility - what features are missing from existing devices that would be of use?

Ideas like being able to connect to a -SK PET with the "proper" connector, and emulating (at least) drives 0 and 1 come to mind - but what else would be useful?

All (polite!) ideas welcome,

Robin
Click to expand...
Hi Robin, in addition to above, current SD solutions do not handle REL files well - running OS/9 remains a real floppy disk drive only solution
 
Hugo Holden said:
One thing from the hardware perspective for the PET, that would help, is to bring the connector right through your SD card unit, so that the PET's IEEE-488 edge connector is not hogged by the presence of the unit. This is an issue with the SD2PET and I had to build a special adapter for that. For example, I use this to have the SD2PET and another real disk drive running at the same time or an adapter for a printer.

The adapter I made rotated the body of the SD2PET 90 degrees if I use that connector, so the SD card faces upwards and that turned out to be quite convenient reaching behind the computer to change the card.

I also have a feeling (but I might be wrong) that in the case of the Commodore disk drives, with two units in the same box, designated drive 0 and drive 1, it was possible to do a disk to disk copy ?, but not possible with two separate single disk drives. Might be wrong about that, but if it was true, that would be a great feature that your unit would act like a dual drive unit, I guess it would then have two SD cards ?

Here is a link to the adapter I made , required because the SD2PET hogged the connector:

Click to expand...
AndyG said:
Hi Robin, in addition to above, current SD solutions do not handle REL files well - running OS/9 remains a real floppy disk drive only solution
Click to expand...
Hi - Yes, I agree - the prototype boards I'm currently waiting for would allow a replica IEEE port board to be soldered to the back of the connector - I personally like the idea of converting the edge connector to a real IEEE socket on the board, but if people only have an edge connector cable, then it is not so good... I can see different versions being needed!
 
C128 Guy said:
I use PETdisk for the through connector. Inexpensive nice solution: https://bitfixer.com/product/petdisk-max/

I believe it is open source.
Click to expand...
I bought one of those but found that it only supported drive 0 at each address and sequential files didn't work, amongst other things - it also drives the bus high and low, rather than using open collector/open drain drivers as per the spec
 
AndyG said:
Hi Robin, in addition to above, current SD solutions do not handle REL files well - running OS/9 remains a real floppy disk drive only solution
Click to expand...
Hi Andy, yes - REL files do seem to be poorly supported - I have an idea to support them outside of disk image files (so a "drive" is just a folder on the sd card) by storing the record length in the first byte of the file and hiding it from the system, so software using the normal REL commands would work transparently - in a disk image file (not written that yet!) they can have the record length stored in the directory entry as normal...
 
NoPizzaTonite said:
The Commodore PETs didn't have a native copy command allowing device to device (strange) - as you pointed out - dual drive devices would allow you to do that since they handled the logic internally.
There might have been one or two copy programs over time for the PET that did facilitate device to device (it's been so long) - Maybe Copyall (Jim Butterfield).
Click to expand...
Hi Hugo, yes, the real commodore drives allowed disk to disk copies, but there WAS a utility supplied with them called "Unit to Unit" which allowed files to be copied between different disk drives - but I think it used the B-R and B-W commands which are probably not well supported by non-Commodore drives.

BUT - it should be possible to "Tell" the disk drive to save/load a file directly to another IEEE device, not even via the PET - although the PET only supports being a bus master, a different device could be a master to another disk drive and perform a copy between the disk units... It is something I would like to try, if I can get my hands on a real drive and some disks.. or at least between two of my drives
 
I have the SD2PET and the Bitfixer 2.0; agreed with the above - the ability for the Bitfixer to also have a real IEEE cable plugged in makes it better for me.

I also like the Bitfixer's capability to load files from a web site (either internal or out on the www).

Here's what I wrote about them a while back:

Commodore PET - SD card solutions - UK Vintage Radio Repair and Restoration Discussion Forum

Commodore PET - SD card solutions Vintage Computers
www.vintage-radio.net

And again, as above, if anyone can fix the inability to copy files from an SD card reader to a proper floppy drive, I'd be very grateful.

Colin.
 
ScottishColin said:
I have the SD2PET and the Bitfixer 2.0; agreed with the above - the ability for the Bitfixer to also have a real IEEE cable plugged in makes it better for me.

I also like the Bitfixer's capability to load files from a web site (either internal or out on the www).

Here's what I wrote about them a while back:

Commodore PET - SD card solutions - UK Vintage Radio Repair and Restoration Discussion Forum

Commodore PET - SD card solutions Vintage Computers
www.vintage-radio.net

And again, as above, if anyone can fix the inability to copy files from an SD card reader to a proper floppy drive, I'd be very grateful.

Colin.
Click to expand...
Hi Colin, thanks for that - I do see the advantage of the pass-through port for the IEEE bus, but having tried the clippy cable inside the PET for power, I am going with cassette port power at the moment, and of course you can use either cassette port for power...

Initially, I am working with SD card folders as "drives" - allowing drives 0-9 for pre-basic 4 commands as the PET itself blocks anything other than D0/D1 in the basic 4 commands - and looking to get all the standard commands supported, which is pretty close now. Supporting disk images can be done if there is real interest in this, and this is why I am interested to see what features people are interested in early on also what is missing from other solutions so I'm doing something useful!
 
The ability to be able to copy files to it wirelessly would be good if you're considering network access for the device - so I could copy files to it from my PC for example - the Bitfixer is halfway there.

I also found that using cassette port 1 for power upset a few programmes, so I would be providing enough length of the cable to be able to use port 2 if you could.

If you don't have an IEEE pass through, then I couldn't use the floppy drive (or indeed the printer if I ever get one) - just a thought.

Colin.
 
Radix said:
I bought one of those but found that it only supported drive 0 at each address and sequential files didn't work, amongst other things - it also drives the bus high and low, rather than using open collector/open drain drivers as per the spec
Click to expand...

The developer is open to improvements. I will ask if he can support SEQ / REL files.
 
Hello, PETdisk Max developer here.
Definitely open to improvements on the device and firmware.
Supporting different drive numbers on the same unit should be fairly simple. As mentioned here, it does currently default to 0, but adding supporting others would be, as they say, a small matter of programming.
SEQ files have a basic level of support on the device - if you load a program that programmatically reads from a SEQ file, for example, it should work. Other use cases like copying will have to be added. I would very much like to add REL file support, just haven't gotten the time to dig into it. Also like others were saying, it does have a passthrough connector so you can use other IEEE-488 devices, and the MCU used is an ESP32 so it does have wifi capability.
REL file support and drive numbers have been on my update queue for a while, but with young kids and jobs and such thing, feels like I rarely get enough time to dig into these recently. It is open source and I certainly welcome fixes, enhancements, etc from anyone who wants to hack on it. I hope this helps, please let me know how I can help with the effort.
 
bitfixer said:
Hello, PETdisk Max developer here.
Definitely open to improvements on the device and firmware.
Supporting different drive numbers on the same unit should be fairly simple. As mentioned here, it does currently default to 0, but adding supporting others would be, as they say, a small matter of programming.
SEQ files have a basic level of support on the device - if you load a program that programmatically reads from a SEQ file, for example, it should work. Other use cases like copying will have to be added. I would very much like to add REL file support, just haven't gotten the time to dig into it. Also like others were saying, it does have a passthrough connector so you can use other IEEE-488 devices, and the MCU used is an ESP32 so it does have wifi capability.
REL file support and drive numbers have been on my update queue for a while, but with young kids and jobs and such thing, feels like I rarely get enough time to dig into these recently. It is open source and I certainly welcome fixes, enhancements, etc from anyone who wants to hack on it. I hope this helps, please let me know how I can help with the effort.
Click to expand...
Hi there, I did email you back at the start of November with a simple SEQ file problem just reading to EOF, but never heard back... I appreciate you're busy with the family - which is great, of course - so I started looking at re-writing it from scratch, as I was not using Platform.io for my ESP32 development... So I now have it doing the basics with reading and writing to multiple SEQ files at the same time, load, save catalog, scratch, copy and rename all working and support for drives 0-9 for the old style command set as well.. It has been an interesting months development!
 
My apologies for that, not my proudest moment when I fail to get back to someone. It fell into /dev/null apparently.
Great work on the firmware though! I would be very interested in trying it out on the petdisk hardware. Starting from scratch is most likely a good approach - I'm not particularly attached to the current petdisk firmware and it is somewhat burdened by legacy, seeing as it mostly evolved from code I wrote for the original petdisk back in 2011. I also migrated it from avr to esp32 architecture at the point when I could no longer get atmel mcus and tried to make it dual-build, so that's another layer of complexity. Would like to take a look and either find a way to merge in your stuff or offer this as an alternative firmware for the device. I'm sure it could benefit the existing users.
 
You must log in or register to reply here.
Back
Top