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.