Date: 2007-11-29 08:22:05
Hallo allemaal, Busy with several MCSA exams I hadn't much time for my 1541IDE projects. And the fact that the most simple of the two, 1541IDE-S, didn't work at all until recently didn't help either. 1541IDE is a project where I add an IDE harddisk to a 1541, model shouldn't matter. The most simple design is adding only a 40 pins IDE connector, some resistors and a 74LS139. Optional: 1) for more safety you can add two buffers, a 74LS245 and a 74LS244 (or 74LS541), 2) a LED and a resistor to see the activity of the harddisk. So far no extra RAM and/or ROM is needed. Remark: only 8 bits are used! This means waisting 50% of the harddisk but having some 20 GB disks laying around doing nothing at all, 10 GB is better then nothing :) It also solved the 512 bytes sized sector problem: using 256 bytes sized sectors is so deep implemented in various software, even Basic, that IMHO we cannot get around it very easy. Having two C= sectors on one HD sector is a possible solution but the writing a C= sector will cause a problem: we HAVE to write 512 bytes which means we have to read all 512 bytes first, replace the involved 256 and write back all the 512 bytes again. The real problem is: WHERE to store these 512 bytes temporary ??? Having only 256 bytes solved this problem :) The 1541IDE-S version (S for Small) only needs the hardware described above, no change of ROM needed. In this way the 1541 is used as it is: just a floppy drive. But a small Basic program enables you to transfer complete disk images to/from the harddisk. The actual program that does the actual transfer is about 200 bytes big and runs on the 1541 after it has been transferred to the 1541. The size triggered the idea to place it in the unused area of the original ROM, $C000-CFFF. Sources available (as always). What did go wrong you may wonder? Somewhere deep in my sources I give the actual READ and WRITE command to the disk but it went like this: ldx #$20 ; read (#$30 for write) sta IDEcommand No comment needed I think :( But now things look very promising! For 1541IDE the ROM needs to be exchanged. No extra RAM is needed as I found out I can partly use the part of the Stack area freed by not needing the GCR routines anymore. Not needing the original format routine and removing all the stuff pointing to the 2nd, not existing, drive freed up so much memory that I used only 13000 of the original 16K bytes so far. But I must admit I haven't implemented any subdirectory related commands. I used the original sources as base. And the original sources were generated by my self written disassembler. Which means that all labels contain the original address, like "B_C785 bne B_C790". In most cases I replaced the labels for subroutines with more understandable names like "jsr ReadSecFrmDisk". Keeping the addresses in the labels makes it easier to compare the new source with the original one. I can save bytes by incorperating one-time used subroutines in the routines calling them but IMHO the few bytes it saves can not be compared with the work involved and will only make it difficult to compare this and the original source. Yet you'll find some places where I did it and I documented them as so. Being capable of using up to 128 GB disks meant I had to replace the original two-byte track/sector notation by a four-byte LBA one. This involved things like adjusting the side-sector tables, changing the way the system can see it is the last sector of a file etc. etc. But I'm confident that things will work out fine one day. As said only one drive can be used. In fact I removed all code pointing to the 2nd drive but only after finding out that too much of the original software removed by C= to be usefull. But it should be no problem connecting a 2nd harddisk (as slave) and using a similar program as with 1541IDE-S to create an image of the first disk on the second one. Have things been tested yet? No. In fact I haven't burned one EPROM yet. But I can imagine people are interested to know that there is, IMHO, a good and very cheap competitor for the CMD drive on its way. But being alone it will take time to have a finished product. So if people are interested to have a look at the sources, please be my guest! -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| URL: Ruud.C64.org De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. Stichting Pensioenfonds ABP is gevestigd te Heerlen en ingeschreven bij de Kamer van Koophandel Zuid Limburg onder nummer: 41074000 The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. Stichting Pensioenfonds ABP, having its registered office at Heerlen, is registered in the Traderegister of the Chamber of Commerce Zuid Limburg (Maastricht), the Netherlands, registration number: 41074000 Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.