1541-MDC
What is it?
"MDC" stands for Multi Data Carrier. In short: it is the combination of the new 1541IDE8: an IDE hard disk drive (HDD) for your 1541 and new 1541LPT and 1541Arduino: No more floppies anymore!. The first project enables you to attach an HDD or CF card to your 1541, the second project uses a PC or an Arduino with SD card as data carrier.I designed a PCB for both projects. But when having to order these PCBs, I know on forehand I will receive five of each. So why not combining the two designs so the result can be used for both projects? Much cheaper in the end :)
CF cards and the Arduino.
HDDs are clumsy compared to CF cards. Another two advantage of CF cards:- You can exchange them with other cards, on the fly if beeded.
- They can work in 8-bit mode (see later).
1541LPT became obselete for a simple reason: modern PCs and laptops don't have a LPT port anymore. So the idea rose to use an Arduino Uno or Mega with a SD card instead. Three advantages compared to a a PC:
- You can exchange the SD card on the fly.
- The Arduino is small enough to be fitted inside the case of a 1541-II.
- One can use an USB cable for special operations.
Remark
If I only mention the HDD, I also mean the CF card. In case of the LPT port I mean the Arduino as well.Schematics
Hardware
First see it as a 1541-II board where all floppy drive related hardware and ICs have been removed. The new board contains a 6502, running on 1 MHz again. I have thought of running it at an higher frequency but I had no idea if that could jeopardise the communication between the 1541 and the C64. Writing these lines I also became aware that another frequency will affect the JiffyDOS communication so I dropped this idea completely.It contains two 6522s to start with, like the original board. But the special IC that handled various signals for the floppy drive is missing of course. This means all I/O pins, except the one serving the LED, are not used anymore. I have thought about dropping this 6522 but, except driving the LED, its timers are used as well. I could live without the LED but not using the timers could lead to compatibilty problems when using other software.
When testing the original 1541IDE8 design, I added a third 6522 with four 7-segments LED displays for debugging. The now not used I/O pins of this 6522 can now be used for that purpose. If other software changes these pins, no harm will be done.
For the LPT / Arduino part, an extra 6522 has been added. This 6522 takes care of the communucation with a PC or Arduino. I added a 20-pin header to the PCB that has been connected to the PZx, PBx, CAx and CBx lines. Two extra pins can provide GND and +5V.
The original board had 16 KB of (EP)ROM on board. By removing the socket I could cut a connection to +5V and by adding address line A14 I was able to handle 32 KB of ROM, like the 27256. Of course this new board can handle 32 KB EPROM. FYI: I will use 27F256 or 27F512 EEPROMs, much faster to re-program.
The original board had 2 KB of RAM on board. By piggybacking another 2 KB SRAM on top of the original SRAM I was able to add another 1 KB of SRAM. That was needed to handle various variables needed to handle hard disk drives. But for this new design I decide to use a 32 KB SRAM. Due to the I/O, not all 32 KB can be used but that shouldn't be a problem I think.
One new idea I had then was adding a RTC to the original board but having these big 28 pins versions in mind, I didn't consider it feasable. But nowadays one can buy complete modules containing a DS1302 with a 5 pins interface for peanuts. Such a module only needs power, a reset, clock and data line. The first idea was to use two unused I/O pins of Floppy Drive 6522 but there is always a risk that a program, handling this 6522 directly for whatever reason, could mess up the RTC. Solution: use any unused CA2 or CB2 line. Risk: almost zero.
There is no specific knowledge of the IDE bus needed to understand how my interface works. The IDE bus is based on the old MFM, RLL and ESDI HDDs. The idea rose to integrate the controller on the board in the PC with the controller of the HDD and to attach the resulting board to the HDD. The only signals needed would be some address lines, data lines and control lines.
The signals we need for our interface are:
- 8 data bits, D0..D7 (D8..D15 are not used and pulled high by a resistor array)
- 3 address lines, A0..A2
- 2 Block select lines: CS0 and CS1
- 2 Read/write lines, IOW and IOR
- the Reset line
There are more lines on the IDE bus but they are only needed for very fast computers. For example: there is an interrupt line that becomes active every time the execution of a command has been finished. This may be very useful with a Pentium 300 MHz but I already found out that handling an interrupt by a C64 would cost much more time then just waiting for the BUSY flag to clear.
There is one other line I use but that is not needed for the correct working of the interface itself: DASP. The function of this line is to blink a LED when the HD is executing a command or reading/writing data. For me it was quite helpful during debugging.
Some HDDs and quite some, if not all, Compact Flash cards are capable of telling the system to use an 8 bits data register. But so far I haven't found any xx GB HDD yet with this feature and having no CF cards in those days, I decided not to pay it any attention anymore.
The original main IC to decode the window for the RAM, ROM and 6522s was a 74LS42, a 4-to-10 decoder. But it is not able to handle the 32 KB of RAM and, to make a long story short, I decided to let a GAL take care of that.
CF card 8-bit mode
As mentioned above, most CF cards can work in 8-bit mode. The first advantage is logical: one can use its complete capacity. It sounds tempting but then I still run into the old time penalty when saving data: I first have to read a complete 512 bytes sector and write it again for just saving a 256 bytes Commodore sector.I can use a multi-media reader to write images to the CF card under FAT32. But that means that the 6502 has to be able to handle FAT32 as well and that will cost even more time. I think I should find out (again) how to write sectors directly to a CF card using a PC so I still can keep my old 256-bytes format.
File system for the HDD / CF part
How are we going to store files? A 1541 floppy can store about 170 KB of data. Extending the used system we can up to 16 MB. 1541-MSD can store gigabytes. It simply means we need a new file system (FS). And a simple one otherwise our 1 MHz 6502 will loose too much time.To make a long story short: the idea is to store only D64 images on the HDD. Or better, extended D64 images. As you know, the original 1541 disk has 35 tracks with a number of sectors ranging from 21 down to 17. Some programs enable you to format a disk up to 40 tracks and these extra sectors each contain 17 sectors as well. The original disk contains 683 sectors. Add these extra 85 sectors and you have 768 sectors. Or hexadecimal, $300 sectors. And using the number $300 will simplify various calculations.
But why images? Main reason: compatibility. Programs handling sectors directly should have no problems. 1541IDE8 already proofed that in the past. Again: only programs trying to control the floppy disk controller 6522 directly in one or another way, like controlling the stepping motor or reading data from or writing data directly to the floppy, suffered problems.
I will need a kind of directory for these images. I think 32 bytes / entry will do, which means eight entries / sector:
* name, 1541-format 16 bytes
* pointer to first sector 4 bytes
* date/timestamp, YYYYMMDDHHMISS 7 bytes
* future use 5 bytes
+ ---
32 bytes
To keep calculations simple, I reserve the first 768 sectors for the directory. 768 sectors cover 24575 entries, good for roughly 1.2 GB of data. When using bigger CF cards or HDDs, a multiple of 768 sectors will be needed. To keep it simple for the 6502, the very first entry of the directory contains drive parameters. They give the 6502 for example the number directory blocks and the number of entries = number of images on the device. In case of a "blank" card or HDD, it has to be prepared first, of course.
If this works out fine, the next step is a 1541 with a file system capable of handling images of the 1571, 1581, my own 16 Megabyte disks and FAT32.
File system for the LPT / Arduino part
In short: none. The PC or Arduino takes care of handling the images. The 1541 only has to order which image it wants to see.Version 2
During soldering the PCB and rewriting the software, I noticed some errors and the need for an extra feature. The errors:- The holes on the PCB for the MAB connectors didn't match with the real connectors I desoldered from old boards.
- I had to move some parts, resistors, capacitors and LEDs, to make them or other parts fit better.
- I used CB2 of the first two 6522s to control the RTC but, although my software won't use them, other software can and that could lead to problems. So I decided to use CA2 and CB2 of the third 6522 only. For this reason I removed them from the 20-pin connector mentioned above.
The extra feature: when writing the combined software, I noticed I didn't have a mean to tell the 1541-MSD what data carrier to use. OK, I can create a ROM for each of the versions but it would be nicer to have a version where a switch or jumper will tell the board what carrier to use as main one.
It means I need inputs for these switches or jumpers. The third 6522 is not the obvious candidate because all PA and PB pins already have been allocated for the LPT part. My idea was to use pin PB4, Write protect sensor, and pin PB7, SYNC detector, of the FDC 6522. These are programmed as inputs in the the original 1541 anyway so should be save to use. The other PB and PA pins can be programmed as outputs by an external program by accident and therefore cannot be used by me.
These pins can tell the system whether LPT, IDE, none or both are available. In case if both are available, I liked to have a third input available to tell the system which one to start up with as main carrier and CA1 or CB1 seemed to be logical candidates. Unfortunately these pins cannot be read as a normal input: they have to be changed to trigger the interrupt register. Then Jeff Laughton came with the idea to connect these pins through a jumper to a changing signal, like the CPU clock. Jumper on and the interrupt register will change, jumper off and nothing will change. I decided to use CB1 of the FDC 6522 as input because it wasn't used in the original 1541 and CB2 of the 3rd 6522 as trigger. This CB2 is also used as data signal for the RTC and changing it, if not in combination with the RTC's clock signal, won't have any effect on the RTC.
Yet another idea: what about using the SD card to exchange data with a PC and using a special command to exchange data between the CF card and HDD/CF? No external access to the CF card needed anymore, just for the SD card and maybe for the USB port.
The software
The software for the 1541-MSD will be based on the software for the original 1541IDE8 and 1541LPT. In the first place I was just revising the original software and, more important, making myself familiar with it again. When thinking about combining both source codes, here the question rose about how to tell the board with what code would be the leading one.When rewriting the pages for the previous projects in 2024, I found out that I hardly mentioned the software. I also found out that my version control sucked: I had a long way to go to find out what I did in the past.
The idea behind the very first versions was simple: remove the parts from the code that are not needed and move the still needed code so that we have one big free area that can be used to insert the new code needed for handling the IDE drive.
That worked out fine until I ran into the trouble with the KCS Power Cartridge I mentioned above. This lead to the idea to keep the original source as intact as possible and only to insert a jump to the new software that was situated in ROM part from $8000 to $BFFF. The trick was to place the new jump at such a place that most probably was not accessed by an external program. So far this idea worked because I hadn't any trouble anymore with the Power Cartridge and some other programs I found in the mean time.
What parts had to be removed? The beginning was simple: remove all parts handling the I/O for the floppy disk controller i.e. handling port A and port B (minus PB3 for the LED) of the second 6522. It is not just only removing the commands but also must be found out what lead to issuing these commands. A lot of I/O commands are issued for finding a certain sector on a track. In case of both 1541IDE8 and 1541LPT it is just a matter of telling "I want to you (PC or HDD) to find me this track" and then just waiting for the result.
For the rest was it going through the complete source and using common sense which part can be simplified or even skipped. An example of the last possibility: the 1541 checks the ID of every header of a sector. Neither 1541IDE8 nor 1541LPT has to deal with headers at all so this check was removed. But this "going through the complete source" was again needed. The best example: for formatting a disk both 1541IDE8 and 1541LPT both used a different method. And none of those was documented why I had done it in this way! The most simple solution: change the "New" command right at the beginning and use a routine not controlled by the interrupt routine. But what to do with the "format a single track" routine then, ignore it or fix it as well in case an external program calls it?
Things had to be added as well and the most important one: handling multiple images. The 1541 has several special commands like Scratch and Initialise. Not all available letters of the alphabet have been used and these are free to use for our own purposes. But that means that the original routine that checks the available commands has to be extended.
Other ideas
A friend asked if I had a cartridge of Roßmöller's Turbo Trans. I don't but it lead two ideas:- I am a JiffyDOS fan and for that reason I never thought about using a parallel communication with the C64/128 to speed up the communication. But what about using the third 6522 for this purpose? But it will mean either to give up the Userport or to create a cartridge to handle the parallel communication at the C64/128 side. But as said, I'm happy enough with JiffyDOS so I'm not going to spend any time at it.
- The Turbo Trans expands the memory of the 1541 with 256 or 512 KB of RAM. This RAM can be used RAM disk. 512 KB supports up to two expanded, read: 40 tracks, 1541 floppy disks or one expanded 1571 disk. Replace the 32 KB SRAM with a 512 KB one and use four pins of the third 6522 for addressing the extra 480 KB of RAM. IMHO not all 512 KB of RAM is needed as RAM disk, I think only max 393.216 bytes, so there is enough left for our own purposes.
You can email me here.