[Coco] Glenside IDE problem

[Bill Nobel]

> On Dec 10, 2014, at 1:09 PM, Gene Heskett <gheskett at wdtv.com> wrote:
> 
> <snip>

> Next question, whats the rbf.d definition for the length of the device 
> name? No.  In os9.d M$NAME reservation is only 2 bytes, but since that 
> included alphabetical chars, one could us iA to iG, with suitable offsets 

Actually Gene the M$NAME in the module header is just a pointer to the actual name in the module.  The name itself can be of any length as it is High bit terminated on the last character.

> filled in for 8 partitions.  But at some point, the drive device table 
> would overflow too.  That FWIW, is 22 byte or more for the 1st DD.SIZ 
> bytes of each entry in the device table, plus 18 more bytes for the rest 
> of that drives table entry for $1E bytes per table entry.
> 
> D.DevTbl is stored at $80 in the direct page, which on my L2 machine says 
> it is located at $7500. That would be in the 4th dat slot and makes -0 
> sense.  It had better be in block 0 not block 1($2000-3FFF) or block 
> 2($4000-5FFF) but in block 3($6000-7FFF).   
> 
> But I have not found an entry limitation yet.
> 
> But that right there blows what I know about Level 3 right out of the 
> water.  Bill Nobel, is my tracing correct?
> 
> From a dmem dump of my L2 DAT record in the DP:
> {t2|08}/DD/NITROS9/3.3.0/6309L2/MODULES/RBF:dmem 0 90 10|dump
> 
> Address   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0 2 4 6 8 A C E
> -------- ---- ---- ---- ---- ---- ---- ---- ----  ----------------
> 00000000 6C00 0900 0900 0000 0315 1203 00FC 0000  l............|..
> 
> I yam confused.  Can someone clarify?
> 
> Besides, my wood arrived about an hour ago so I've other things to do the 
> rest of the day.
> 

Your tracing is pretty darn close Gene. DP and block 0 are core data needed for OS9 core operation.  Data pointers like D.DevTbl and such can point to another block in the System map. Remember the System gets it’s own 64k workspace. All the data pointers are created during the boot process using system memory requests which allocate memory in the system map, and those pointers are stored in DP. D.DevTbl on my 3.3.0 is $6B00.  IOMAN allocates this memory based on the DevCnt and PollCnt from the INIT module.

L3 on the other hand from what I am beginning to understand is using blocks 1 & 2 of the System map to swap in the memory blocks for SCF/RBF modules and pulling them out of the System memory itself. Nitros9 module at boot moves them out of System map and IOMAN manages swapping them in/out as needed.  Alan is using block 0 in the area of $0642-$064f(?) as his data pointer area for L3 (block #’s and pointers)

Bill Nobel