• Please review our updated Terms and Rules here

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

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.
Ah no problem - it happens - it's taken 5 days to get an email verification from here! (and a different email address) - Unfortunately my code won't work at all on your hardware due to different pin assignments to reduce the byte read to 4 instructions and no buffer or level shifters, the ESP32 works well in open drain mode straight onto the bus! - Although I have provided for proper termination packs, in case they are needed for longer cables. I think the rel file support is the next thing to tackle and to start making it into a testable package for some real-world testing...
 
Sounds good. If you have your pin assignments and/or schematics available, would be interested in trying that out sometime. Hope you decide to open source your code, will help others to learn from it. Good work.
 
Just my opinion here, some things I could add, because I do hardware mainly, a lot of the time (programming is not my strong point), is that often all the thought on the project gets put into the electronics & software/firmware development and the mechanical engineering, industrial design, artwork etc gets ignored. Projects get released as bare boards etc. I was impressed with the SD2PET, that they had at least crafted a reasonable enclosure for it.

For me something that makes a machine desirable and beautiful, and attractive, it the integration of excellent mechanical and electronics engineering.

Therefore, if I was doing a project like this (though this one is outside my skill set with the firmware) what I would probably do is start with a small extruded aluminium enclosure, such as one made by Takachi, make it up to look like a baby or miniature Commodore dual disk drive unit.

Perhaps even with similar artwork and front panel graphics, with both the SD cards on the front panel for drive 0 and drive 1 analogous to where the disk slots are on the full size Commodore dual drives and even LED's in the same relative places.

Put a standard IEEE-488 connector on the rear panel and another one or two there which allows another device to be connected to the bus, along with a DC jack (to power the unit from a wall wart). Then have a cable with the IEEE-488 connector on one end and the edge connector for the PET on the other (this cable already exists). And the functional goal would be to match the performance and features of the original drives in every respect, but of course much higher storage capacity and much less bench space. And also be a kind of show piece, as a miniature working dual disk drive replica.

Buying one of these units then , would be sort of like buying an original dual drive unit, only everything miniaturized and more reliable, rather than just a bare pcb that hides on the rear of the PET.

A while back I won a design competition for an unbeatable Tic Tac Toe computer. Part of the reason was not so much that my electronic design might have been more clever than any of the other entries, in fact it was somewhat retro with logic gates, but I think because of the industrial design, artwork, presentation, enclosure, ergonomics etc to make an attractive machine. I would always encourage extra work in these areas for an electronic project. Some of the other competition entries were merely masses of wires on proto boards and bare pcb's begging to be shorted out on the nearest conductor:

 
Last edited:
Just my opinion here, some things I could add, because I do hardware mainly, a lot of the time (programming is not my strong point), is that often all the thought on the project gets put into the electronics & software/firmware development and the mechanical engineering, industrial design, artwork etc gets ignored. Projects get released as bare boards etc. I was impressed with the SD2PET, that they had at least crafted a reasonable enclosure for it.

For me something that makes a machine desirable and beautiful, and attractive, it the integration of excellent mechanical and electronics engineering.

Therefore, if I was doing a project like this (though this one is outside my skill set with the firmware) what I would probably do is start with a small extruded aluminium enclosure, such as one made by Takachi, make it up to look like a baby or miniature Commodore dual disk drive unit.

Perhaps even with similar artwork and front panel graphics, with both the SD cards on the front panel for drive 0 and drive 1 analogous to where the disk slots are on the full size Commodore dual drives and even LED's in the same relative places.

Put a standard IEEE-488 connector on the rear panel and another one or two there which allows another device to be connected to the bus, along with a DC jack (to power the unit from a wall wart). Then have a cable with the IEEE-488 connector on one end and the edge connector for the PET on the other (this cable already exists). And the functional goal would be to match the performance and features of the original drives in every respect, but of course much higher storage capacity and much less bench space. And also be a kind of show piece, as a miniature working dual disk drive replica.

Buying one of these units then , would be sort of like buying an original dual drive unit, only everything miniaturized and more reliable, rather than just a bare pcb that hides on the rear of the PET.

A while back I won a design competition for an unbeatable Tic Tac Toe computer. Part of the reason was not so much that my electronic design might have been more clever than any of the other entries, in fact it was somewhat retro with logic gates, but I think because of the industrial design, artwork, presentation, enclosure, ergonomics etc to make an attractive machine. I would always encourage extra work in these areas for an electronic project. Some of the other competition entries were merely masses of wires on proto boards and bare pcb's begging to be shorted out on the nearest conductor:

Hi Hugo, Congratulations on the Tic-Tac-Toe computer!
It would be great to put together a complete solution like you suggest - and for a current or industrial market, it would certainly be required - but I think people would appreciate the option to try out this sort of product and see how well it works for them first - and maybe add extras like a aluminium case and so on, if they feel it warrants the extra cost - this is not to be negative, but rather it provides an opportunity for makers with different skill sets to compliment each other...

I already had the idea that it would be neat to have the SD card in a remote (at the front of the PET) little 3D printed model of a PET disk drive, like an 8050, complete with activity light, to save on the messing around at the back of the system where the board naturally mounts most easily - but as a starting point, and lowest cost option, I envisage a board flat to the rear of the PET with a replica of the IEEE Port for additional devices and a cassette port edge connector for power as the starting point...

Naturally - other versions of the board can be made with different connectors and options if there is interest to do this and an option for the 8032/96-SK systems with a real IEEE connector would be useful as well.

So I would be happy to work with others who can provide extras to compliment what I do - and then we can do what we are good at and enjoy...
 
"So I would be happy to work with others who can provide extras to compliment what I do"

I can see your point of course, to involve others in the testing and let them add as they see fit to some basic core design. But then you create a messy patchwork quilt. It is not the good idea that you think it might be.

Because you probably could make something much more impressive. And you should take responsibility for the entire design.

I think it would be much better to create a well defined finished product with all the hardware, enclosure and artwork attended to.

This way your creation will be a solid defined machine, which (if works properly) will go down in history and in the future, will create part of the legacy that is the PET Computer.

And you also should make a comprehensive manual for it, both an operating manual and a service manual with schematics and provide the source code for the programmable devices. Also, if you don't plan to build and supply the units yourself, a comprehensive BOM.

(some professionals do all this and it makes for a much better project, have a look at Martin Eberhard's ME5204 UV eprom programmer)

My feeling is that this will be much better than a bare pcb, put out there for beta testing by multiple parties, which seems to be the M/O these days for multiple projects that you see on places like Github. These are what I call skeleton projects. It is like making a Grand Piano and not bothering to put on the 21 coats of varnish and think that the end user might be able to do it with a tin of varnish and a brush.
 
Last edited:
PET cases already exist - the one on the right here is from Thingiverse and holds a Pi for a web server for my Bitfixer device.

As I said earlier, if you could find a way of enabling access to your device to be able to copy files to it, that would be a useful addition.
 

Attachments

  • PXL_20220708_152730460 (1).jpg
    PXL_20220708_152730460 (1).jpg
    3.1 MB · Views: 12
PET cases already exist - the one on the right here is from Thingiverse and holds a Pi for a web server for my Bitfixer device.

As I said earlier, if you could find a way of enabling access to your device to be able to copy files to it, that would be a useful addition.
Hi Colin - that does look cute! - Have you looked into the Commodore "Unit to unit" program to copy files between different IEEE device numbers? - I suspect that it won't work with most SD card solutions though, at present - but I am going to see how this could be done with my solution...

What would be useful would be input from everyone as to what programs (real or test programs) for the PET have issues with SD card based devices, using SEQ and REL files and the standard CBM DOS commands, rather than the B-R , B-W,M-R and M-W commands... I would like to be able to try out other peoples code or tests sooner rather than later so I can check beyond what my own tests are doing...

At present I am working with SD folders rather than disk images, until I am happy that the standard commands are working properly...
 
Last edited:
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
Hi Andy - I am just working on the REL file support at the moment, for SD card folders, rather than disk image files... Can you tell me if OS/9 includes (many) REL files in its distribution, or do OS/9 programs create and use REL files - or both?

I am currently checking behaviour between the various Commodore docs and other sources, as well as with how VICE works, so any info or good links would be greatly appreciated!
 
...and emulating (at least) drives 0 and 1 come to mind ...
Some PET programs like VisiCalc and those for the SuperPet work best with access to dual devices with drive 0 and drive 1. This emulation is much needed. Files could be located in the same SD folder/subdirectory, that should not be an issue as long as LOAD "0:name", 8 and LOAD "1:name2", 8 find the files called "name" and "name2" on the SD.
 
I'd like the different drive emulators come to a standard for directory changing and disk mounting, that way a program like filebrowse could support them easily.
 
Hi Andy - I am just working on the REL file support at the moment, for SD card folders, rather than disk image files... Can you tell me if OS/9 includes (many) REL files in its distribution, or do OS/9 programs create and use REL files - or both?

I am currently checking behaviour between the various Commodore docs and other sources, as well as with how VICE works, so any info or good links would be greatly appreciated!
OS/9 is run from a REL file. Drive D1 for example will be one REL file. You create the REL files from a program run in native BASIC mode. I can point you to the floppy images where you can see examples if you like. They can find them on Zimmers.NET
 
IMO an edge connector pass-through would be more flexible (and also cheaper) than an IEEE version.

If connecting another device or devices is an issue then presumably the user already has a PET to IEEE cable for that; if your pass-through were IEEE out then they'd probably need to also buy an IEEE-IEEE cable as I'm not aware of any IEEE to edge adapters.

On the other hand, PET to IEEE adapters *are* available, e.g.:


You could even supply one as an option.

Just my 5 cents' (adjusting for inflation) worth.

An IEC serial option would be quite useful for folks who also have a C64 or VIC with an IEC drive. The electrical interface is trivial, just a driver and the jack, and interfaces with the firmware in a PET ROM are already available.

m
 
Last edited:
Some PET programs like VisiCalc and those for the SuperPet work best with access to dual devices with drive 0 and drive 1. This emulation is much needed. Files could be located in the same SD folder/subdirectory, that should not be an issue as long as LOAD "0:name", 8 and LOAD "1:name2", 8 find the files called "name" and "name2" on the SD.
Hi Dave
Yes - I totally agree, the DTL PET Basic compiler needs drives 0 and 1 - that is already working with my version, as I mentioned in another post, I actually allow drives 0 - 9 using the older format commands, which map to folders "Drive0" to "Drive9" by default - I envisage being able to re-assign them to different folders or eventually to disk image files on demand
 
I'd like the different drive emulators come to a standard for directory changing and disk mounting, that way a program like filebrowse could support them easily.
Yes! - It would be great if there was already a preferred way to specify a folder or disk image name.. For changing folders, I have drive numbers (0,1...9) map by default to folders like "Drive0" - but allow them to be re-mapped to folders DriveA - DriveZ (for example) so games, utilities, and so on could have their own folder and it would be easy to choose which appear as drive 0 and 1 (up to 9)... Mapping disk image files does of course require filenames, so if there are already any neat ways to do that, that people prefer - I am open to ideas and suggestions!
 
OS/9 is run from a REL file. Drive D1 for example will be one REL file. You create the REL files from a program run in native BASIC mode. I can point you to the floppy images where you can see examples if you like. They can find them on Zimmers.NET
Hi Andy, I had a dig and a quick look at the OS9 files - I have never seen a real SuperPet, but I used to repair the 8000 series systems and disk drives mostly, back when they were new... It's not clear to me at the moment if OS9 will need disk image support - rather than just REL file support, but I am looking to add image file support as well, once the basics are working... I'm in the Midlands in the UK, so if you and/or and others you know using OS9 are local-ish, we might be able to help each other to get it working?
 
IMO an edge connector pass-through would be more flexible (and also cheaper) than an IEEE version.

If connecting another device or devices is an issue then presumably the user already has a PET to IEEE cable for that; if your pass-through were IEEE out then they'd probably need to also buy an IEEE-IEEE cable as I'm not aware of any IEEE to edge adapters.

On the other hand, PET to IEEE adapters *are* available, e.g.:


You could even supply one as an option.

Just my 5 cents' (adjusting for inflation) worth.

An IEC serial option would be quite useful for folks who also have a C64 or VIC with an IEC drive. The electrical interface is trivial, just a driver and the jack, and interfaces with the firmware in a PET ROM are already available.

m
Hi Mike
Yes - I agree the pass through Edge connector is the obvious solution for the majority of users, - but the connectors are a really tight fit when they are new - and I am bolting them to the board to reduce the strain on the solder connections at present. Back in the day, when they were new, we had no end of clients with broken connectors on the PET end and almost all the real cables I have seen recently have cracks in the edge connectors, making them loose and unreliable.

I also do want a solution for the systems with "real" IEEE connectors and that will most likely be a different board layout There seem to be quite a lot of the -SK systems in use still, so it would be great to have something that works for them as well.

C64 / IEC is also on the cards - again, it will be a different board to suit the IEC interface - but the commands and operation would otherwise be identical to the IEEE version
 
Hi Andy, I had a dig and a quick look at the OS9 files - I have never seen a real SuperPet, but I used to repair the 8000 series systems and disk drives mostly, back when they were new... It's not clear to me at the moment if OS9 will need disk image support - rather than just REL file support, but I am looking to add image file support as well, once the basics are working... I'm in the Midlands in the UK, so if you and/or and others you know using OS9 are local-ish, we might be able to help each other to get it working?
Hi, I am happy to help where I can … I am in East Anglia

Andy
 
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...
This is how sd2iec works, exactly (disclaimer: I wrote the REL file support in sd2iec). REL files are indeed not supported in disk images in sd2iec, though the support was not a big deal, it was just additional code that didn't seem wanted by the community in enough quantity to commit to testing.

But, REL file support in native mode was and is supported. I hear all the time about lack of or broken REL file support, but I've yet to receive a bug report on REL file support, so I could fix said bug.

Personally, I think SD IEC support is in good shape with the sd2iec firmware, and it has a ton of bells and whistles. But, IEEE is a different story.

Jim
 
Yes! - It would be great if there was already a preferred way to specify a folder or disk image name.. For changing folders, I have drive numbers (0,1...9) map by default to folders like "Drive0" - but allow them to be re-mapped to folders DriveA - DriveZ (for example) so games, utilities, and so on could have their own folder and it would be easy to choose which appear as drive 0 and 1 (up to 9)... Mapping disk image files does of course require filenames, so if there are already any neat ways to do that, that people prefer - I am open to ideas and suggestions!
I can't take much credit for the state of SD card support for the Commodore, but I will take credit for pushing Ingo Korb (author of sd2iec) to use CMD style commands for directory changes and partition changes, and so on.

In my opinion, the standard for mapping partitions should be to leverage the idea of partitions, ala the cp command in CMD DOS. cp1 would change the default partition to 1, etc. Since partitions were concrete things in a CMD FD and HD, there was no "mp" or "rp" commands, but there could and should. 'M'ake'P'artition could easily be created as "mpX=/path/to/image_or_dir". 'R'emove'P'artition would simply scrub that number and free it up. MP could also be called Mount Partition, but I think continuing to call is "make" is better, as there might be a later use case to extend the command to actually create a partition on some media or block/stream device. Support for this could also be added to sd2iec without much trouble.

This would provide support for 255 partitions/drives.
 
I'd like the different drive emulators come to a standard for directory changing and disk mounting, that way a program like filebrowse could support them easily.
There is a standard and it has been in place since the '80s. CMD used "cd[X]/path/to/dir/:dir_name" //path/to/dir was absolute, while /path/to/dir was relative. If various systems are not using this convention, I'd push the developers to grab a CMD FDD or HDD manual to get the syntax. It's supported by most later '80s apps that needed complex drive support (BBSes, most often), and obviously was only supported on IEC devices, but the standard is in place and should be used instead of creating new standards, especially since the DOS in IEC devices and IEEE devices is very similar and uses the same command structure. What other methods are in use?
 
Back
Top