[Coco] Glenside IDE problem

[Gene Heskett]

On Wednesday 10 December 2014 23:08:02 Bill Nobel did opine
And Gene did reply:
> > 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.

I am aware of that, however the device table entry for the devices name in 
the defs is only 2 characters.  If one is assembling a device descriptor 
I'd imagine the assembler would allow you to name it /CandiceFudpucker, 
but I'd about bet that in the device table, you could only find the Ca.

But this is a head scratcher, at that address in memory, ONLY the 3 floppy 
entries are there, and I dumped an extra 256 bytes on both sides of that 
$7500.

That leads to : does the rbsuper devices have their own drive table?

Puzzling.  For rbsuper managed stuffs, I have DD, S1, & SH but those don't 
appear to be in _this_ drive table.

> > 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


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS