1541 to 2031 Conversion

[TommyE]

Hello

After getting valuable help in the thread https://forum.vcfed.org/index.php?threads/pet-3032-no-video.1254054/ for my recently aquired PET3032 I wanted to convert one of my 1541s to a 2031.
I found details all over the interweb with a custom ROM and adapters to make that happen.

I do wonder, can I copy PET files to a floppy on my Pi1541 equipped Commodore 64, and be sure that the file integrity is there? The reason for asking is that in this document on zimmers https://zimmers.net/anonftp/pub/cbm/firmware/drives/new/1541/Commodore 1541 ROM genealogy.pdf
is says the following:

1541, 901229-03 ROM The third ROM revision for the 1541 only changed the value of gap1 in the sector headers. All changes in ROM code were limited to the ROM for the area $E000-$FFFF (901229-03). The changes that occurred between ROMs 901229-01 and 901229-02 were retained unchanged. Code differences compared to the ROM 901229-02 ROMs involved: 901229-02 and 901229-03 Difference #1: Change gap1. The change makes gap1 (the number of disk bytes between two parts of a sector header) one disk byte (10 bits) longer. The change is required in two places: the code that (re)writes a sector starting at $F586 and the formatting code starting at $FCCD. In both cases only one constant is changed. This change causes disks formatted with all previous ROMs (as well as the 2031(LP) and the 4040) to be no longer write compatible. Because the read routines simply wait during the passing of the gap for the SYNC marker to pass, reading is not affected: the new value for gap1 simply causes the remaining sector parts to pass the head later in time and within the time slot allowed.

Also wanted to show of a half (or so) finished 1541-2031 switchable board I've tried to put together. It works for the most part, giving me switchable 2031, 1541 IEC and 1541 paralell (burst nibbler, speeddos and alikes) support. Will need to refine and make another board with some corrections.
The ROM is an 8way switchable 27512 so I can have a few different ones there, also 1540 for my VICs.



Best regards
TommyE

 

[Hugo Holden]

That seemed like a tall order to me, making the 1541 work with a PET. Though I had good success using it with an AIM 65 with the appropriate adapter board and the INIBAS patch, with ABM's ROM.

@daver2 helped to re-create the missing INIBAS program, to allow the 1541 drive to work with the AIM-65.

Though, fair to say, I am only any good at hardware solutions, not software ones.

The 2031 was specifically designed with a GPIB interface for the PET, the 1541 was not.

I had heard about a custom conversion to enable the 1541 drive to have a GPIB interface. It did not impress me much as Shania Twain might have said, but it may have worked in the right hands, but I'm sure they were not mine.So well done for pulling this off.

I found the easiest solution here was simply to buy the SFD1001 drive, again it looks like the 1541, but it is designed for the GPIB interface directly to the PET.

Even then, it might not be as simple as it seems. The SFD1001 I bought had its motor drive board recapped by an idiot with acid flux and the soldering skills of a 5 year old. Even after that was repaired, I found that they had removed the motor drive board with a method that threw off the radial head alignment, so that the drive could only record and make non-standard discs only suited to it. I had to re-align it after repairing the pcb damage.

Then on top of that the analog regulators ran too hot for my liking, rather than doing something daft as you often see, like replacing them with modern SMPS supplies (that does not provide the same levels of protection) I added mini cooling fans to the enclosure. I have attached a photo of the fans I added. I also added taller rubber feet on the base to lift the unit a little higher off the bench, to improve the air flow through it.

 

[MiaM]

Nice project!

In addition to using the regular 2031(LP) ROMs, the German magazine 64er did a DIY project like this where they listed patches to the regular 1541 ROM. Not sure if they got those "patches" by just doing a diff of a 2031 and a 1541 ROM, or if they actually modified the 1541 code themselves, but still.

Either way, you would be able to read any disks interchangeably. However I would only assume that writing works if they disk is formatted the same way it then gets written.

It would be a good idea to modify the 2031 ROMs to have the same gap as the (later) 1541 ROMs though.

Related tangent: It would also be interesting to modify the 1541 ROMs to have the same gaps as the 2040/3040/4040 PET dual disk drives (that afaik aren't fully write compatible even with the 2031, and even less with the 1541).

Bonus: If your add-on board connects to all CPU signals, maybe also add expansion RAM for those C64 disk fast loaders that need that? Like DolphinDOS and whatever the other similar one is called?

 

[TommyE]

That seemed like a tall order to me, making the 1541 work with a PET. Though I had good success using it with an AIM 65 with the appropriate adapter board and the INIBAS patch, with ABM's ROM.

@daver2 helped to re-create the missing INIBAS program, to allow the 1541 drive to work with the AIM-65.

Though, fair to say, I am only any good at hardware solutions, not software ones.

The 2031 was specifically designed with a GPIB interface for the PET, the 1541 was not.

I had heard about a custom conversion to enable the 1541 drive to have a GPIB interface. It did not impress me much as Shania Twain might have said, but it may have worked in the right hands, but I'm sure they were not mine.So well done for pulling this off.

I found the easiest solution here was simply to buy the SFD1001 drive, again it looks like the 1541, but it is designed for the GPIB interface directly to the PET.

Even then, it might not be as simple as it seems. The SFD1001 I bought had its motor drive board recapped by an idiot with acid flux and the soldering skills of a 5 year old. Even after that was repaired, I found that they had removed the motor drive board with a method that threw off the radial head alignment, so that the drive could only record and make non-standard discs only suited to it. I had to re-align it after repairing the pcb damage.

Then on top of that the analog regulators ran too hot for my liking, rather than doing something daft as you often see, like replacing them with modern SMPS supplies (that does not provide the same levels of protection) I added mini cooling fans to the enclosure. I have attached a photo of the fans I added. I also added taller rubber feet on the base to lift the unit a little higher off the bench, to improve the air flow through it.

I didn't know about that adapter for the AIM65, will be reading about that. Would have loved to have a good SFD1001 myself, but the budget is not there.

Must say, thats a one of a kind fan install you got there

Thanks for sharing.

/Tommy

 

[TommyE]

Nice project!

In addition to using the regular 2031(LP) ROMs, the German magazine 64er did a DIY project like this where they listed patches to the regular 1541 ROM. Not sure if they got those "patches" by just doing a diff of a 2031 and a 1541 ROM, or if they actually modified the 1541 code themselves, but still.

Either way, you would be able to read any disks interchangeably. However I would only assume that writing works if they disk is formatted the same way it then gets written.

It would be a good idea to modify the 2031 ROMs to have the same gap as the (later) 1541 ROMs though.

Related tangent: It would also be interesting to modify the 1541 ROMs to have the same gaps as the 2040/3040/4040 PET dual disk drives (that afaik aren't fully write compatible even with the 2031, and even less with the 1541).

Bonus: If your add-on board connects to all CPU signals, maybe also add expansion RAM for those C64 disk fast loaders that need that? Like DolphinDOS and whatever the other similar one is called?

Thanks

I'm using the patched ROM, keeping one ROM original. Makes it easy to swap in the ROM I want.

I guess I will be trying to format/write/read a bit back and forth with the ROM.

Not sure if you have read the whole doc on zimmers, but as I read it I guess there will be incompatibilities between older 1541 with the -01 and -02 ROMS and the ones that have -03 and higher? Strange that Commodore made such a mod.
Guess I will need to use the -02 ROM in the 1541 when preparing PET disks on the Commodore 64.

Oh well, not the biggest problem, but something to think about...

As for adding RAM for eg. Dolphin and such, maybe I'll look into how those boards worked more in detail. Cool idea. Would have been nice to have a drive with all options. I thought about putting an Pi1541 inside it as well... but thats maybe for another day.

/Tommy

 

[MiaM]

I haven't read that document recently; can't remember if I've read it a long time ago and forgotten half of it
However I remember reading various sources about the compatibility problems.
Are the changes in the 1541 ROM versions in the ROM that 64er patched, or in the ROM that are the same in 1541 mode as in 2031 mode? If the change is in the ROM that you don't switch out, then you would likely get disks that are fully like newer 1541 disks.

I think there are at least two different versions of the Dolphin DOS, but I can't remember the details.

Semi related tangent: 64er had a hardware project to add RAM/ROM in general to a 1541, kind of for tinkerers, kind of for adding different (pirated) speed loaders.

 

[Ruud]

In addition to using the regular 2031(LP) ROMs, the German magazine 64er did a DIY project like this where they listed patches to the regular 1541 ROM.

1986, #1, page 144, 4 pages. I can provide the article plus D64. Just email me.

Related tangent: It would also be interesting to modify the 1541 ROMs to have the same gaps as the 2040/3040/4040 PET dual disk drives (that afaik aren't fully write compatible even with the 2031, and even less with the 1541).

There is another problem: the 2040 and 3040 had an extra sector on the tracks 18..24. If you only have a 2031, then I would prefer the other way around, just as you suggested above. I also have a 4040 and happy with "just write to a disk with the drive that formatted it".

Bonus: If your add-on board connects to all CPU signals, maybe also add expansion RAM for those C64 disk fast loaders that need that? Like DolphinDOS and whatever the other similar one is called?

These fast loaders were created to make use of the faster parallel communication. And IEEE is parallel communication. So speed was not the problem. The CBMs were business computers, the C64 home/game computer. The CBM owners were not people really willing to hack their computer for fun, C64 owners, that's another story.

I did some hacking for the CBMs, but that was around 2000: CBM-HD.

 

[fachat]

The 2031 and the 1541 are basically the very same drive, except for the IEC vs IEEE488 interface. I believe the 2031 was actually first. See the high profile 2031 drives

CBM2031

Explore this photo album by afachat on Flickr!

flickr.com

 

[Ruud]

Correct. Compare the board of the 1540 and the 2031, the layout is almost the same. The 1541 is "the same" as the 1540, the difference is that one 2 KB SRAM replaced the original four 1K*4 SRAMs and a custom IC replaced a lot of logic.

 

[fachat]

Correct. Compare the board of the 1540 and the 2031, the layout is almost the same. The 1541 is "the same" as the 1540, the difference is that one 2 KB SRAM replaced the original four 1K*4 SRAMs and a custom IC replaced a lot of logic.

Where I really learned a lot about the floppy disk recording format when I discovered the schematics of the early drives without the custom IC.

 

[MiaM]

There is another problem: the 2040 and 3040 had an extra sector on the tracks 18..24. If you only have a 2031, then I would prefer the other way around, just as you suggested above. I also have a 4040 and happy with "just write to a disk with the drive that formatted it".

Yeah, with the 2040/3040/4040 it's also really fast and easy to just do a full disk copy of any disk that you might have created using a 1541.

These fast loaders were created to make use of the faster parallel communication. And IEEE is parallel communication. So speed was not the problem. The CBMs were business computers, the C64 home/game computer. The CBM owners were not people really willing to hack their computer for fun, C64 owners, that's another story.

Well, my suggestion here was to add this as a use case when using the switchable 1541/2031 add-on board in the 1541 mode.

I did some hacking for the CBMs, but that was around 2000: CBM-HD.

Cool!
I did a tiny attempt/start at a similar project back in the days in the late 90's or so, at the time it wasn't that easy to find documentation. I made a cable connecting the IEEE488 bus to two bidirectional PC parallel ports and wrote a simple program capturing the IEEE 488 bus, and thus I were able to determine what the PET and the drive actually sent to each other while executing simple commands. I never got around to actually using the bidirectional feature of the PC parallel ports and write software that would talk IEEE488 with the PET though.
(Fun fact, or whatnot: With software written using IIRC Turbo Pascal or Turbo C a tired 12MHz 286 (zero wait state though!) were able to capture the IEEE-488 communication as long as it didn't have to write the results on screen while capturing. I.E. I ran the capture, then pressed a key on the PC to stop the capture and then displayed the captured result.
I had documentation on the IEEE488 bus itself, but not what Commodore did with it, thus the need to capture the communications.

Maybe I'll have a go at trying your program! After all I have a working 8296 but both drives I have (and also my other two PETs, an original 2001 but with a 8k dynamic ram board, and an 8032, are also broken). It gets boring really fast to use datasettes with a PET

I've been toying with the idea of using an Arduino to do IEEE-488 but IIRC the regular Uno has too few free I/O pins (at least if it's also to communicate with a host PC and/or some external storage. Not that much fun to just be able to use the small built in storage). Wouldn't be that hard to do some kind of I/O expansion muxing a few signals, but still).

 

[Ruud]

Where I really learned a lot about the floppy disk recording format when I discovered the schematics of the early drives without the custom IC.

I don't think that I have to tell you this but others could be interested:
- look for "Inside Commodore DOS", a very interesting book about the ins and outs of the various C= drives.
- my page about the 1541 tells more about the hardware of the 1541 around processing disks. Gideon Zweijtzer used this info to create the "1541 Ultimate".

 

[Ruud]

Maybe I'll have a go at trying your program!

Contact me for the latest version. But it is a long ago that I used it because....

I've been toying with the idea of using an Arduino to do IEEE-488....

Have a look at the PetSD. And this is not the only SD project. Let's be honest: if you have to choose between using this little box or a "huge" PC, what would you choose? And it needs a PC running MS-DOS. I use an older Dell laptop running dual boot W98-DOS and XP. XP is maily for exchanging files over the network with my W7 main hobby PC.

 

[CommodoreZ]

Wow, this is super cool! Kudos for even attempting this!

I've seen PET user port adapters for the IEC serial bus before, but this level of all-up interface conversion is way more impressive.

 

[MiaM]

Contact me for the latest version. But it is a long ago that I used it because....


Have a look at the PetSD. And this is not the only SD project. Let's be honest: if you have to choose between using this little box or a "huge" PC, what would you choose? And it needs a PC running MS-DOS. I use an older Dell laptop running dual boot W98-DOS and XP. XP is maily for exchanging files over the network with my W7 main hobby PC.

Re PetSD or whatnot: I'm kind of a bit too cheap to get one of those. I have a Final Expansion 3 for my VIC 20 (an IEC2SD + ram/rom expansion on a single PCB that fits the cart port). In general these devices seems great for running existing software, or for that sake tinkering using things directly on the vintage computer. But it seems like a better idea to run a storage emulator on a modern computer for either trying out loads of software found online (I.E. say testing out things found on CSDB for the C64; I would think that everything that can be found for PET would fit on a single SD card though...) or develop new software.

Or for that sake something like your PETHD could also be modified to emulate the 8010 IEEE488 modem (although I have to admit that I have still not fully understood if it's possible to use it in a fully arbitrary full duplex way or not?) to use the PET as a terminal or whatnot.

Also I like the idea of building stuff using things I already have among all my junk

 

[TommyE]

Hello again.
I had do some disassembling of the 2031 original rom, 2031 patched rom, 1541-02 and 1541-05, and also the 1540 for the fun of it.

I found that the 1540, 2031 original, and 1541-02 all use the GAP value of 08, the 2031 patched ROM and the 1541-03 and higher uses a GAP value of 9.

So I guess this means that there are some possible write incompatibilities between the various ROMS versions as exptected. The strangest thing (for me a least) are that if you happen to have a real old 1541 ROM -01 or -02 you could have problems writing to a disk created on a newer version 1541. I didn't know that.

 

[TommyE]

Wow, this is super cool! Kudos for even attempting this!

I've seen PET user port adapters for the IEC serial bus before, but this level of all-up interface conversion is way more impressive.

Thanks

I thought it would be nice to a drive that covers them all

 

[TommyE]

- look for "Inside Commodore DOS", a very interesting book about the ins and outs of the various C= drives.
- my page about the 1541 tells more about the hardware of the 1541 around processing disks. Gideon Zweijtzer used this info to create the "1541 Ultimate".

Nice , will look into that.

 

[fachat]

Yeah, with the 2040/3040/4040 it's also really fast and easy to just do a full disk copy of any disk that you might have created using a 1541.


Well, my suggestion here was to add this as a use case when using the switchable 1541/2031 add-on board in the 1541 mode.

Cool!
I did a tiny attempt/start at a similar project back in the days in the late 90's or so, at the time it wasn't that easy to find documentation. I made a cable connecting the IEEE488 bus to two bidirectional PC parallel ports and wrote a simple program capturing the IEEE 488 bus, and thus I were able to determine what the PET and the drive actually sent to each other while executing simple commands. I never got around to actually using the bidirectional feature of the PC parallel ports and write software that would talk IEEE488 with the PET though.
(Fun fact, or whatnot: With software written using IIRC Turbo Pascal or Turbo C a tired 12MHz 286 (zero wait state though!) were able to capture the IEEE-488 communication as long as it didn't have to write the results on screen while capturing. I.E. I ran the capture, then pressed a key on the PC to stop the capture and then displayed the captured result.
I had documentation on the IEEE488 bus itself, but not what Commodore did with it, thus the need to capture the communications.

Maybe I'll have a go at trying your program! After all I have a working 8296 but both drives I have (and also my other two PETs, an original 2001 but with a 8k dynamic ram board, and an 8032, are also broken). It gets boring really fast to use datasettes with a PET

I've been toying with the idea of using an Arduino to do IEEE-488 but IIRC the regular Uno has too few free I/O pins (at least if it's also to communicate with a host PC and/or some external storage. Not that much fun to just be able to use the small built in storage). Wouldn't be that hard to do some kind of I/O expansion muxing a few signals, but still).

You can do IEEE488 with an arduino: https://github.com/fachat/nano488

Not enough pins for anything else, but can use the usb serial to load files from a PC.

André

 

[Hugo Holden]

You can also do GPIB/IEEE488 to RS-232, in that direction. Taylor-Wilson did this very well with their PET printer interafce, no CPU needed, just logic IC's. It is very handy to dump from the PET to a Terminal, even if not used for printing, it also handles PETSCII. I reverse engineered the whole thing because there was no data on it:

https://worldphaco.com/uploads/THE%20TAYLOR-WILSON%20PET%20PRINTER%20INTERFACE.pdf