ruud.baltissen_at_abp.nl
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.