From: Baltissen, GJPAA (Ruud) (ruud.baltissen_at_abp.nl)
Date: 2004-08-05 10:13:38
Hallo allemaal,
The last time I told you about the success of the HW interface but I must
admit that I still was cheating a bit when sending the data for the
directory to my 8032-SK. Considering that as unfair I switched to the simple
routine, 'keep sending data untill an ATN is found', but then I still got
errors. You must know that during a DIRECTORY the data is sent with one or
two bytes a time before the 8032 sends an ATN. In my case the PC sometimes
sent up to three bytes and then received an ATN. The problem was that this
third byte was not used ie. the 8032 considered the 4th byte as the 3rd one
with all errorous results. My output routines has several built-in checking
routines so I'm 100% sure that the byte was send going through the complete
handshake protocol and thus was actively received by the 8032. But being
lazy I switched back to the cheating routine.
I was at such a point that I thought that my emeulator was good enought that
some real programs would accept it as a real 4040. So I choose the C= file
copier 'UNIT2UNIT' as my first real testcase. I first thought that all went
right but then discovered that two files were missing. After quite some
research I found the following: UNIT2UNIT didn't copy files that:
- had a name of only ONE character long
or
- files that had a space somewhere.
Don't ask me why but something said to me that it had to do with the above
timingproblem. So once again I started playing with my routine and
introduced a Tbb value for the Xth time (but never tried with the
interface). And with Tbb = 20 uSec. things worked! And guess what, UNIT2UNIT
worked as well! But I'm still puzzled what this timingproblem has to do with
the two problems mentioned above.....
So I started to used other programs provided by Commodore to test things. So
far I ran into one problem: The program 'DISK ADDR CHANGE' enables one to
change the device address on the fly. It uses 'M-R' to read the ROM to
identify the drive. This is how I learned there isn't an universal way to do
it. So the question rose: should I support this feature? For several reasons
I decided to skip it. But if someone can give me some good arguments, I
still can add it.
I did only a few tests but the support for REL-files seems to work as well,
that is, the 180 KB version. So far I only supported the 4040/1541 and
yesterday evening I started with the support of the 8250. Being able to
handle this drive, I can introduce the extended version for the REL-files.
Reading the description, I got puzzled. The manual says this version can
support up to 23 MB long REL-files. But the T/S mechanism that all drives
use, can only support a drive as big as 16 MB (255 * 256 * 256 to be
precise). Did I miss something?
Having a 8250 available, I'm also going to support subdirectories. But not
the way the 1581 does. Here you have to reserve an amount of diskspace and
that's it. If you don't need all, the rest is lost. Do you need more then
the original planned space, bad luck for you. (it is quite some time ago
that I studied it, so I could be wrong)
My idea is simple: a subdirectory is just another file but its content is
shaped like the original directory.
The next step is supporting my own D16 format: a 8250 disk but with 255
tracks and 256 sectors/track. I have thought about using other drives as
base but all have their own disadvantages:
- 1541, 4040 etc. have only one BAM sector, I need an unlimited number.
- the 1581 supports more BAM-sectors but there is still a built-in
limitation (AFAIK).
- the 90x0 has no limitation but is less wellknown as the 8250
Any ideas about this subject are welcome.
But having a xxx GB HD at your disposal, 16 MB seems to be way out of time.
So I'm also going to support plain DOS. But then one can forget about
commands like 'B-R' and 'B-W' of course. I also made plans for a complete
new filesystem using two bytes for the track and sector each, good for 1
TB, but then 'old' programs still could forget about the 'B-x' commands.
--
___
/ __|__
/ / |_/ 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.