Ruud's Commodore Site Home Email

1541LPT: No more floppies anymore!



What is it?

1541LPT is a project where I am going to use a PC as an harddisk for the C64, C128 and VIC-20 and other IEC-computers using a 1541 as an interface. As a small bonus you can use the CD-ROM, 1.44 MB-drive and network-drives of the PC as well!
Products: software, a cable and a modified 1541-board.

State: Version 0.20, Beta version


Incompatibility.

1541LPT is not 100% 1541 compatible. Programs manipulating the second 6522, the one transferring data from/to the floppy disk, simply won't work. More explanation regarding this subject you'll find spread all over this page.


The story.

Marko Makela, Frank Kontros, Andre Fachat and I exchange a lot of ideas and one day I suggested to build a small 6502-machine as an interface between the PC and the C64 to let GEOS think it is dealing with an real 1541 or other drive. Marko (or Andre ?) replied that I should use an old 1541-board instead, it would save me a lot of soldering.
PC-Flop was my first try but failed: the LPT port was too unstable for my needs. But during the tests the idea rose to alter the Kernal of the 1541 as well and to set up my own communication protocol between the 1541 and the PC.


Theory: the basics.

The idea is quite simple: replace all routines handling the transfer of data with the floppy disk by your own ones. It sounds simple and, looking back, it is. But I ran into some problems that really gave me a headache.

Commodore used GCR encoding to write/read data on/from the floppy disk for a technical reason. But for me I there isn't this need. So I skipped all GCR en/decoding and saved quite some processor time on the fly.

I changed the original Kernal at 13 places. I only will describe them, for details see the sources: The last item may need some explanation. The 1541 doesn't look for the actual sector at request but first looks for a sector within a certain range before the wanted one. Understanding what really was going on costed me 90% of all trouble.
I first simulated this process when trying to read a sector but that produced quite a messy program on the PC. And when I found out that the writing process behaved the same but with a different range, I simply dropped the whole process and whiped out the part in the Kernal by altering three bytes.

One of the ideas was only altering the Kernal by replacing original instructions with jumps or subroutines. My routines would be placed in the so far unused address range $8000-$BFFF. The reason for this is that in this way I keep the Kernal as much as original as possible in case programs depend on routines found in the Kernal.
The above means that the original address range of the Kernal has to be expanded in some way. And that is not so simple with the 1540/1541-I boards. The 1541C and 1541-II boards use 27128 EPROMs and with a, IMHO, simple trick a 27256 can be used.
Remark: although I used a 1541-II to test 1541LPT, the Kernal is based on the one of the 1541-I ie, the ROMs 325302-01 and 901229-05.

To avoid even this simple trick I looked for a way to move the 720 bytes of my program somewhere inside the original ROM. To make a long story short: I succeeded and the short version was born: 1541LPTS.


Theory: the PC.

The program running on the PC is just a program that runs and waits for orders coming from the 1541; no menus or whatever. Some parameters at start-up tell the program which device number and LPT port to use and what D64 image to load.

The above remark reveals that my program is using D64 images as source. The advantage for me is that I could use all routines developed for CBM-HD. D64 images won't recognise half-tracks for example and here is anothe reason that 1541LPT is not 100% compatible. For more details see the chapters 'Theory: future expansion' and 'Copy protections'.

I mentioned the use of parameters. But the first design used an INI file. And using a file meant I had no easy way of 'changing the floppy'. So I decided to alter the Initialise instruction by making it possible to add a parameter. For example OPEN1,8,15,"I:WORKDISK" will cause the PC to load the image WORKDISK.D64. Only later I realised that when during a game a change of floppy is needed, the user cannot type in the OPEN command mentioned above. That's why I decided to implement parameters: it gives the user a quicker way to 'change the floppy'. And this 'changing the floppy' is the reason the 1541 must be able to detect that the PC program has been restarted.

I also implemented a command that enables the user to see what images are available on the PC. The syntax is quit simple: LOAD"$$",x or @$$. Only images in the same directory as 1541LPT.EXE are shown.


Theory: speedloaders.

So far so good, but what about speedloaders like JiffyDOS, FC-III, EXOS V3 etc.? Theoretically it should work with all speedloaders that don't access the mechanically drive directly. And the very good news is: JiffyDOS is one of them! I adapted my own JiffyDOS ROM (1541LPTJ) and now I have a system with all JiffyDOS goodies and no more playing disk jockey :)

I tested 1541LPT also with some other speedloaders. In this case I (tried to) load the program '64 DOCTOR', 83 blocks. The number is the needed time in seconds: 
                  1541LPT   1541LPTJ
original C64        50         40 
JiffyDOS 6          49          6
Power Cartridge      9          9
Final Cart.-III     xxx        xxx
EXOS V3             xxx        xxx
As you can see, no result with EXOS and FC-III. But with the remark that both speedloaders had no problem with reading a directory. So IMHO these two manipulate the second 6522 directly.

Remark: I have no real good explanation for the difference in speed between the original C64 Kernal using 1541LPT or 1541LPTJ.

I already mentioned that I made a JiffyDOS version: 1541LPTJ. I also made one that fits within 16 KB: 1541LPJS. But the problem of this one is: I cannot distribute the binaries or sources as they are, so how can I get them to you in a legal way?


Theory: future expansion.

It would be great to emulate drives like the 1571 or 8250 or being able to handle DOS files directly ie. having a xxx GB harddisk at your disposal. Unfortunately this is not so simple. I can make the 1541 format a disk with 255 tracks and 256 sectors on each track but then what about the BAM needed for this 16 MB 'only' sized disk? The 1541 is only capable of handling the 1541 specific one-sector-BAM located at track 18, sector 0. The only idea I have at this moment is to trap all commands sent to the 1541 and send them to the PC which will handle and process them. The 1541 will be nothing more then an hardware interface between the PC and the Commodore computer.

I'm using D64 images at the moment but this means we have to deal with a certain incompatibility like having no half tracks. Using G64 images could solve this problem and some others.


Realisation: the 1541.

Theoretically 1541LPT should work with all known 1541 models. But for practical reasons I adapted a 1541-II. There has to be some soldering done.

The first change is removing the mechanical drive.

The second change is connecting the pins together that lead to the write-protect detector of the drive. In case of the 1541-II I used a jumper placed over pin 3 and 4 of connector CN4. Until so far this worked fine but I'm thinking about replacing it with a switch.

The third change is adding a 6522. I piggybacked mine on top of U6. I connected all pins except PAx, PBx, CAx, CBx and CS2 (pin 23). I connected CS2 with a wire to Q5, pin 6, of U2, a 74LS42. In this way the 6522 shows up in the memory map at address $1400.

Then a 25 pin male D-connector is connected to the 6522: 
  
3BC,378,278 = Printerdata
3BD,379,279 = Printerstatus
bit 0 = not used
bit 1 = not used
bit 2 = not used
bit 3 = error (15)
bit 4 = select (13)
bit 5 = paper end (12)
bit 6 = acknowledge (10)
bit 7 = busy (11)
  
3BE,37A,27A = Printercontrol
bit 0 = strobe (1)
bit 1 = autofeed (14)
bit 2 = Initialise (16)
bit 3 = select out (17)
bit 4 = enable IRQ7
bit 5 = dataport direction
bit 6 = not used
bit 7 = not used
  
Control after reset:  $CC
As you can see, the CAx and CBx pins are not used. Future expansion?


Realisation: the PC.

The software is written in Turbo Pascal 7.0 (but should run under 5.0 as well IMHO) and was tested on a 80486 80 MHz running DOS 6.22 NL. And I'm sorry, it does not run in a DOS box under Windows; for one or another reason Windows messes up the LPT signals during a transfer. This was my first project I tried to test in a Windows DOS box and it took me two days to find out :(


Realisation: testing.

As said before, the Pascal part is using the same unit I use for CBM-HD and that software is running stable for the last two years.
I tested the whole by saving and loading some own made files but the main test is performed by utilities like 'CHANGE DISK' and 'PERFORMANCE TEST' found on 1541 Demo disk. What struck me most in apositive way was that 1541LPT even passed the mechanical test performed by 'PERFORMANCE TEST'!


The software

This ZIP file contains everything, ROMs, DOS executable and sources except the ones of the JiffyDOS version. The reason for this is obvious, I think.
But there is solution for the JiffyDOS owners. The 1541LPTJ version needs a 32 KB EPROM or equivalent. Unfortunately there is a connection at both sides between pin 28 and 27 of U4, the place for the ROM. This means we are restricted to 27128 EPROMs and we need to place a 27256.
I solved the problem by de-soldering pin 27 and by placing another socket on top of the original one. But before placing it, I soldered a line to pin 27 and lead that one through the hole of the removed pin. The free end of the wire was soldered to pin 24, A14, of U3, the 6502.
Unfortunately this solution only covers the 1541-II. I only have one (not tested) idea for placing a 27256 in an original 1541: use a 24 -> 28 pins convertor socket, connect all address lines and connect /CS and /OE to an invertor which on its turn is connected to Address line A15.

The places in the source that have been changed, are marked with '&&&xx' where xx is a number. Find these markings in 1541LPT.LST and the remarks let you see what actually has been changed. 37 bytes have to be changed, 13 more if you want another start up text, and that is a number that can be done by hand. So now you have to read out the original ROM, make the needed changes, add the first 16 KB of 1541LPT.BIN and burn the result into a 27256.


Copy protections

At this moment I only can think of six types of copy protection that can be used on a disk:

Schematics

1541lpt.png




Having questions or comment? You want more Info?
You can email me here.