Hello! Frank Kontros wrote: > I disagree with 99.9% compatibility. As most fasloaders directly reads/writes > $1c01 and decodes GCR bytes bypassing DOS routines, the above mentioned thing > simply wouldn't work. With specialized hw GCR coders/decoders or without you > need an extra (micro)controller to drive HDD, convert data into GCR and transfer > to $1c01 register. And not to mention head stepping :-))) Mbah, sh*t. Could you explain, what is happening when reading a file to the 1541's buffers? ...I mean, how does the OS program the low-level part, I mean, that big ASIC or gate array found in the 1541. How does the data flow when reading a block from the disk? ...Or rather, how to make the low level part to read a sector, and how to catch the data on the 1c01 port? How many databits arrive at the port? (Since GCR is 5 bits long, it must be either one nybble, or two nybbles with the addition of 2 portbits somewhere). Have you fiddled with Gigaload, or the Warp25 (the fastloader of the MK7)? I seem to remember they transfer GCR nybbles directly and decode them in the C64. > Levente> Or you can decide with the CBM like scheme, to allocate a big > Levente> bitmap on the first blocks of the HDD as BAM and use daisy-chain linked > Levente> file blocks. > > It is much reliable even if BAM would crash somewhere. Seem to have sense, because with a FAT crash you lose links either; with a BAM crash, you just lose the block allocation, but the files are still valid. > Disk images *must* be supported and no way as 64NET system does (extracting > files from disk). 64net s*cks. I mean, it's useless for me. I run cracker oriented programs, demos, games and utils quite frequently. These don't really like to accept anything but their loved 1541 or at least a serial device. > Levente> even low-level things like GCR codes. > > With some extra hw will do. I'm interested, how it is done; please explain it. > Ruud>The way to program it: > Ruud>- it must be in assembler. > Ruud>- I'm thinking of using a "jump"-table. If we have to break in the original > Ruud> OS, we first jump to this jump-table and from there to the new routine. > Ruud> I think the advantages of a jump-table ore obvious. > > In the original ROM there are some jump table (in 1581 even more). I see, the problem is, the 1541 DOS is like a haystack. It's full of absolute jumps. So I guess, the 1541 DOS must be hacked inside, even if the existing jump table entries could be redirected. But from the other hand, organizing the new HDD OS to support jumptable functions may help to keep the code alive (and maybe, to link it to another DOS rom, like JD or speeddos). > Don't forget guys, that I having deal with 1541 near every day expanding and > implementing new commands into my own 15xx emulator (I still work on it). Are you gonna write a cycle exact (realtime) 15xx emulator? (I seem to think that you have or had some similar problems with emulating original 1541 drives like Ruud's controller will. Neither I would have thought that these fastloaders don't use the system for the block-read task.) Levente - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.