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.