From: Baltissen, GJPAA (Ruud) (ruud.baltissen_at_abp.nl)
Date: 2005-02-18 12:03:45
Hallo Spiro, > You did not loose track. The problem is that it works other than you > expect. :-) > .... Ah, big relief :) The reason why I wanted to know that is I'm still working on my 1541HD projects. Yes, with a 's'. 1) IDE-HD, true 16 bits interface. Fast but requires extra PCB. 2) IDE-HD, two extra 6522s provide interface, extra (2 KB) RAM needed. Relative easy but dirty: needed electronics can be piggybaked on top of others IC's. 3) CompactFlash, extra (2KB) RAM needed. Unfortunately no experience with CF at all, have to find out how to work with it in 8-bit mode. 4) LPT-port of PC. Extra 6522 needed. Disadvantage: PC plus extra program required. Advantage: program at the 1541 can be quite simple as the PC does the majority of the job. This is NOT the my project where the PC emulates the electronics and drive. This has been canceled; the PC wasn't able to deliver or read a steady stream of bytes due to interrupts, refreshes or what ever (same problem as with my CBM-HD project). Bonus for all 4 projects: IMHO both the floppydrive and 'HD' can be used. I decided that adding (an) extra 6522(s) is easier then cutting all kind of lines between the original 6522's and the not needed elctronics. Another advantage: speedloaders manipulating the original 6522's directly, cannot mess up the 'HD' by accident. FYI: handling a IDE-HD/CF sector means you HAVE to read or write 512 bytes in one go. And I cannot use the original RAM to store the extra 256 bytes. There are 5 buffers available for storing data. So one could store up to five 1541 sectors, edit them and save them to disk without any problem. Now try to do the same with a IDE-HD/CF; I only can save those 5 sectors if I have the other original 5*256 bytes as well. So extra RAM is needed. A HD outputs its data in words. I have thought about using only 8 bits of it. Advantages: no extra RAM needed and a much, much simpler interface, less programming. Disadvantage: 50% of the storage capacity is gone. I really would appreciate some comment on this idea; would you mind loosing 50% of your HD in return for a very simple interface? To be able to handle the 'HD', I have to replace the original ROM. The idea is to keep the original data as original as possible. This is done by replacing some instructions with a 'JMP $xxxx' where $xxxx can be found in the so far unused $8000-$BFFF area. Where do I have to cut in? The idea was quite simple: I have to cut in the moment the 1541 starts to use a routine where port A and/or port B of the 6522-diskcontroller is addressed. Where did I cut in: - Read the header of a sector - Read a sector - Find a sector - Write a sector - Verify a sector - Step the head - Format a track I also had to add some extra routines: - Initialise the extra 6522(s) (if installed) - Check the extra RAM (if installed) I changed the routine that checks the ROMs (or better, I disabled it for the moment). The last thing I did was disabling the timer interrupt at some place to avoid unwanted 'time out' errors. I hope the above wasn't boring, I just wanted to keep you informed with what I'm still busy with on the hardware front. -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| URL: Ruud.C64.org =====DISCLAIMER================================================================= 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. 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. Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.