| |
cadaver
Registered: Feb 2002
Posts: 1159 |
Is this safe? (diskdrive memory question)
Hi,
I'd be thankful if someone commented whether this is a "safe" memory arrangement with 1541 & compatibles:
$300-$3ff Used as directory cache
$400-$4ff Buffer 1 used for reading data
$500-$6xx Custom drive code
$700-$7ff Used as directory cache
Custom drive code uses buffer 1 jobcodes to read sectors and doesn't call any drive ROM routines. Every time drive code is reuploaded & restarted $300-$3ff & $700-$7ff are assumed to be corrupted and are re-initialized. I guess this should be safe? |
|
| |
Stryyker
Registered: Dec 2001
Posts: 466 |
I guess so but it depends what happens when the drive code is not running. If you need to use buffers for U commands etc or load/save. There are ways around it though which I use for some IFFL highscore saver in a different file so the IFFL drive code and scan tables are not corrupted. |
| |
cadaver
Registered: Feb 2002
Posts: 1159 |
Thanks!
The way the my drive code works, it runs in a loop until it notices ATN go low (for saving files by Kernal routines) Then it exits permanently. Afterwards it is reuploaded & restarted, at which point the first thing it does it to cache the directory again. |
| |
Stryyker
Registered: Dec 2001
Posts: 466 |
I suggest writing test data to memry then save a test file then reread drive memory, AR/RR is good or emulator. For my save which is limited to 1 block I use buffer and drive code. I set which buffer I want like open2,8,2,"#2" if you understand. The drive code isn't really drive code, just M-W commands to write the track/sector ($0006/$0007 for $0300 etc.) then M-W to $00 to write a $90 etc. Sorry if I misled. |
| |
cadaver
Registered: Feb 2002
Posts: 1159 |
Ah yes, now I see better what you mean.
I noticed that the BAM sector appears to be at $700-$7ff, however I noticed no corruption of it on the disk after a couple of <save file>-<reinit drivecode>-<fastload again> -cycles. I guess the drive-ROM re-reads that sector, and doesn't assume it stays uncorrupted in memory? |
| |
Stryyker
Registered: Dec 2001
Posts: 466 |
I have no idea but writing some values to $0700- region can have some funky directories, even screw up some loaders using more standard methods. I guess it is either the ID part or the 2A stored. What do you plan to do with $07xx region? I guess this gets written to the disk after each save. |
| |
cadaver
Registered: Feb 2002
Posts: 1159 |
I'm storing the start track/sectors of files (while their 2 first letters are stored at $0300-$03ff). Done that way, 128 files can be buffered. But maybe I'll try to squeeze the drivecode a bit and then I might get the whole thing into $0300-$06ff range. |
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Howdy dudes...
Of course this is safe. $0000-$02ff is critical, the rest is no prob at all. Guess why they're called *buffers* 0 to 4? ;)
I got used to mess with $0000-$07ff in the floppy RAM, a configuration like yours is a dream, since those 2kb are always too little memory for my purposes.
Cadaver: Had a look at my loaders? I checked yours out, btw. |
| |
cadaver
Registered: Feb 2002
Posts: 1159 |
Thanks, then I'll mercilessly use all of that area :)
Yeah, I've looked at your loaders, really nice work, though I must admit most of the stuff beyond the transfer-protocols goes over the top of my head :(
Guess I should sometimes study more advanced loaders like yours with the drive-ROM memory map & disassembly at hand :) |
| |
Zagon
Account closed
Registered: Apr 2002
Posts: 14 |
hm, I'm not so sure. The drive caches the bam in the last buffer and segments of if at $02a1-$02b0. Prehaps the DOS rereads these areas automagically because it doesn't trust itself? Just to make sure I would like to do the following:
ldx #0
stx $029d
stx $029e
dex
stx $b4
just to evict these caches. (this is for a 1541)
Comments anyone?
|
| |
Zagon
Account closed
Registered: Apr 2002
Posts: 14 |
Hm, I'll comment myself :) the above stx:s evicts the caches but don't free the bam buffer the drive has allocated for itself. Just to be safe I would like to add this code as well:
lda $024f
and #$EF
sta $024f
This just clears the bam buffer's allocation bit.
A perhaps more elegent but totally different approach is to trick the drive into thinking that the disk has been changed. I think the following code will achieve this:
lda #$01
sta $1c
Comments Anyone?
|
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Thanks, Cadaver. I think the ROM disassembly won't be very useful, as the only things I use the ROM for is some gcr encoding/decoding tables. Well i never comment anything in my sources, sorry.
There'll be some new versions of the loader, being even faster (a speed similar to interleave 3.5 or something) and easier to use (no specific interleave needed any more to gain maximum performance). I also found a way to change the VIC bank while loading without masking anything (LDA #%00-%11, STA $DD00 is enough, no probs with irqs between the lda and sta with masking) and also to write anything to $dd00 while the loader is idling (so DriveLok can be forgotten).
Zagon: Can't comment on it, don't even have a ROM disassembly. Seems useful, though. Not using the ROM anyways... Once my disk system/calculation progs are enabled, i have control over 2k, afterwards JMP ($FFFC) ;) ... |
| |
cadaver
Registered: Feb 2002
Posts: 1159 |
From comp.sys.cbm I got a suggestion to do a JSR $d005 (Initialize) before exiting the drivecode. The initialize routine does JSR $d042 (Load BAM) in turn. This might do the trick as well? |
| |
Zagon
Account closed
Registered: Apr 2002
Posts: 14 |
I expect jmp $(FFFC) or jsr $d005 will work to that effect too :)
But doesn't these routines reset the devicenumber? What if you have software-renumbered your drive? One way to do this is action replay command @8=9 so it's easy to test.
Back in the old days I used to renumber my internal 128D drive to 9, because it was broken, and use an external 1541 as 8 instead as many programs were hardwired to use 8.
This setup also made me hate loaders using the ATN line for transfers :)
By the way, there's a great htmlized dissassembly of the 1541 at http://www.ffd2.com/fridge/ .
|
| |
cadaver
Registered: Feb 2002
Posts: 1159 |
Good point! I tested and the drive number reprogramming survived $d005 call. |
