[Coco] Glenside IDE problem

[Bill Nobel]

Ah I think I know why you might be confused, the device table (D.DevTbl) doesn’t hold the entire descriptor at all. it holds just a set of pointers to each of the device descriptors in memory that have active open paths, whether they are SCF or RBF. IOMAN goes through this table when a IO call happens (whether RBF or SCF) to find out what path to take for the process making a IO call. Drive tables are held in a separate area for RBF

Bill Nobel

> On Dec 10, 2014, at 10:55 PM, Gene Heskett <gheskett at wdtv.com> wrote:
> 
> 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 <mailto: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 <http://geneslinuxbox.net:6309/gene>>
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com <mailto:Coco at maltedmedia.com>
> https://pairlist5.pair.net/mailman/listinfo/coco <https://pairlist5.pair.net/mailman/listinfo/coco>