| |
cadaver
Registered: Feb 2002
Posts: 1153 |
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: 465 |
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: 1153 |
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: 465 |
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: 1153 |
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: 465 |
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: 1153 |
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: 2845 |
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: 1153 |
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
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
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?
|
... 4 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
