Area : CBM

Date : Apr 05 '97, 11:19                                                       
From : David Schmoll                                           1:104/518
To   : Rod Gasson                          
Subj : Ramdos direct access                                                  
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

Hi Rod,
 
I got to thinking about how it might be possible to create files
directly under Ramdos, and so I tried a few experiments along the
way, and here are my results. First we need a little more background on
Ramdos.
 
Bank 0, page 0 is a 256 byte general work buffer for the current file.
 
More important bank 0, page 1 descriptions: Byte 0/1 is the starting
address for the files in Ramdos, which is always $22,$0 (msb/lsb). Byte
2/3 is the one page past the end of the last file in the REU (msb/lsb).
If bytes 0/1 = bytes 2/3 then there are no files - remember this
pointer! Now on to my experiment:
 
First I installed Ramdos as usual. I then opened the file I wanted to
create and printed a single character to actually create the file, and
the Ramdos directory indicated a one block file.
 
For my test I wanted to use the Basic stash command, so I reset the
computer to disable Ramdos, this step would not be needed if I used my
own DMA in ML. I then loaded a Basic program that I knew the ending
address of and directly entered the Basic stash parameters to directly
store the Basic program into REU memory at the address (track and
sector) given in bytes 27/28 of bank 0, page 1 when we created the
file. Remember that the start of a file in Ramdos always starts on
offset 26 of the page (think sector), so I added two for the load
addess to make it 28. I then needed to update a few pointers myself to
make Ramdos happy, so going back to the starting bank and page (think
track and sector) for this file I made the following changes where
needed.
 
Bytes 0/1 are the number of blocks in this file - not counting this
sector. Byte 2 indicates the access character if open (r,w,l,$),
otherwise it should be set to zero. Byte 3 is the file type, which
should already be set, since we opened the file to create it. Byte 4 is
the offset to the last byte in the last sector - you need to calculate
this offset based on how long the file is. Bytes 5/6/7 deal with
relative files, so make sure they are zero. Byte 8 is the start of the
file name, with zero's filling out to byte 25 - it should already be
set. Bytes 26/27 have to be set for the load address, but text files
won't need his step. You could also have written the load address when
you opened the file.
 
Remember where i said bank 0, page 0 is the general buffer for the
current file? Copy this first sector of the file we just stashed and
modified to this sector - this step was important for some reason! Now
we have one more pointer to change for the block count to correct.
Remember the pointer in bank 0, page 1, bytes 2/3? This needs to be
changed to the next free track and sector, (bank and page) after our
program in the REU. Now for the test - the program loaded just fine
from Ramdos, and the directory was correct, including file block counts
and blocks free ! :)
 
You may ask why bother with all of this? It seems to me that combining
direct access with Ramdos, you have the speed of direct access, with
the benefits of Ramdos. For example when downloading a programmer could
open the file under Ramdos, buffer to bank 1, and stash directly to the
REU as needed, and when he was done, modify the pointers just outlined,
and still have the compatability of Ramdos across other programs.
 
dschmoll@nyx.net (David Schmoll)

--- JMail-G 2.80d
 * Origin: The Silver Hammer * Aurora, Co. USA * (303)766-80(FIDONET 1:104/518)