From: muta...@gmail.com   
      
   On Monday, September 12, 2022 at 4:23:43 AM UTC+8, s_dubrovich@yahoo.com wrote:   
   > On Sunday, September 4, 2022 at 1:55:32 PM UTC-5, muta...@gmail.com wrote:   
   > > On Monday, September 5, 2022 at 1:03:24 AM UTC+8, Scott Lurndal wrote:   
   > > > "muta...@gmail.com"  writes:   
   > > > >On Sunday, September 4, 2022 at 9:25:34 PM UTC+8, wolfgang kern wrote:   
   > > > >> On 04/09/2022 06:32, muta...@gmail.com wrote:   
   > > >   
   > > > >Noone had done segmentation before and it   
   > > > >would take decades of science still to   
   > > > >work through the repercussions.   
   > > > Several very successful systems that predate the   
   > > > 8086 by a full decade used segmentation; examples include the PDP-11,   
   > > > the B6500 et alia.   
   > > They presumably didn't do 4 bit shifts or similar   
   > > so didn't hit the a20 issue nor the flexible shift issue.   
   > >   
   > > The a20 is probably because of cp/m PSP though,   
   > > not segment shift.   
   > They presumably didn't do 4 bit shifts or similar   
   > so didn't hit the a20 issue nor the flexible shift issue.   
   >   
   > The a20 is probably because of cp/m PSP though,   
   > not segment shift.   
   > ~~~   
   >   
   > Gosh, istm you have these concepts jumbled up.   
   >   
   > Sorry for the review but..   
   > The 8080 cpu has 16 address lines A0..A15, we show this as a hexidecimal   
   word..   
   >   
   > Which ranges, 0000h..FFFFh, with each address addressing an 8-bits byte.   
   > This amounts to 65,536 bytes (64k) addressable, for the 8080 cpu.   
   > The Code, Data, and Stack concepts are intermixed in the address range.   
   > Segment logic in not supported in the 8080 hardware.   
   >   
   > The address lines are binary, where each line is conceptually a bit with the   
   > value of either a 0 (clear) or 1 (set).   
   > The address lines together (16 lines are 16 bits) indicate an address value.   
   > The address value is shown _in hex_ with 4 'nibbles' nnnnh, with 2 'nibbles'   
   > forming a 'byte' nnh of 8 bits. Conceptually, a nibble (nh) is 4 bits.   
   > Yet note that the smallest directly addressable element is a BYTE.   
   > Nibbles and bits are indirectly accessable thru processor instructions of   
   > shift, rotate, logic masking etc in the context of a directly addressed byte   
   or   
   > word. IOW you can make a pointer to a byte or word directly but not a pointer   
   > to a bit directly. You can make a pointer to a bit in a bit field indirectly   
   > as a side effect of making a pointer to a byte or word (with extra   
   processing).   
   >   
   > The binary nature of bit values, set (1) or clear (0) lends itself to 'power   
   of   
   > 2' math in the cpu venue. Consequently, a value in the accumulator shifted   
   > left is a 'power of two' multiply. A value shifted right is a 'power of 2'   
   > divide.   
   >   
   > Lets consider a nibble, whose value is 1, is in the low order position of a   
   byte in the accumulater, 01h.   
   > We decide we want to place that nibble in the high order position of the byte   
   > in the accumulater, as 10h, the processor command to left-shift-by-4 gives   
   our   
   > desired result. An 1x2**4 = 16, reflected in hexadecimal as 10h.   
   >   
   > Note that the 8080 does not have multiply and divide instructions.   
   > Those functions were performed in software using the bit shift, logic,   
   compare,   
   > and other primitives. Still, trig and floating-point libraries were developed   
   > for the 8080. You know, when programmers were PROGRAMMERS!   
   >   
   > CP/M, which should be called CP/M-80 to be clear, is an 8080 OS.   
   > 86-DOS was the precursor to PC-DOS & MS-DOS.   
   > 86-DOS took the logic of cpm-80 and tranfigured it for the 8086/88 cpu. Also   
   > it adopted the fat file system.   
   > CP/M-86 was a new OS that adopted the filesystem of cp/m-80 v2.2 and the same   
   > BDOS function numbers plus additions for the 8086, notably, setting the   
   'base'   
   > ie. segment value of a DMA buffer. It adopted a 'loader linkage record'   
   > - my terminology - which told the loader how to set the segments for an   
   > executable .CMD file.   
   >   
   > Segmentation was thought to be helpful in program reliability by computer   
   scientists because the separation of code from data could lesson bugs of   
   > corruption of code or data or both.   
   >   
   > The 8086 has a linear addressing range of 00000h..FFFFFh.   
   > Five nibbles = 20 address lines which are named A0..A19 inclusive.   
   > An increment on an address value of FFFFFh rolls-over to address 00000h.   
   > This is effectively a circular buffer structure but pertaining to code.   
   >   
   > The A20 'thing' was not a 'thing' until subsequent cpu's expanded the address   
   > lines above the 8086 range, that is A20++.   
   >   
   > The 'thing' was that 86-dos, pc-dos, & msdos depended on the 8086 address   
   > roll-over to implement cp/m-80 CALL 0005h operation. As I recall, I saw   
   > 'call 5' was in one of the utilities for 86-DOS src yet CALL 5 is supported   
   in   
   > CMD.EXE .COM programs, up thru XP at least.   
   >   
   > So, no roll-over is bad. So the A20 was made to be toggled either normal or   
   > always clear until the controlling flag is changed. This was done by the OEM   
   > so as to not break those dos's.   
   >   
   > As to 8086 segmentation.. we have a linear address range of 00000h..FFFFFh.   
   > An offset range for code and data, stack and ES of 0000h..FFFFh, 16 bits MAX.   
   > A common data structure is an array. Consider MyArray[0h..Fh].   
   > MyArray is a standin for a segment number, and an offset range of   
   0000h..000Fh.   
   > In this case, we are allowed 64k of array structures of size 16 bytes.   
   >   
   > So, treating 'segment' as a 'base' and the offset as an 'index' makes some   
   > sense. So the 'base' is the high order element and the 'index' is the low   
   > order element in any case. So it make sense to apportion the address range   
   > as:   
   > base as BBBB'X and   
   > index as X'IIII   
   > where X means 'not used'   
   > Some Combination of the two gives   
   > BBBB-h   
   > + -IIIIh   
   > = CCCCIh So from the combination of the two, they cover our addressing range.   
   >   
   > Obviously, in the real world; combinations, compaction, alignments, etc,   
   > are done.   
   >   
   > To operate with greater than 64k offsets requires the leap into 32bit   
   > programming and protected modes.   
   >   
   > Ohh, the variable shift thing..   
   > If you increment a segment value by 1, you are really adding 16 (10h) to the   
   > linear address. Its a nibble shift, 4 bits. This is done in the cpu address   
   > decoder, no changing it.   
   >   
   > You want a 5 bit shift for some reason. A five bit shift for the segment   
   value   
   > yields 20h increment in the linear address, a 32 byte resolution verses a 16   
   > byte resolution for a nibble shift of 4.   
   >   
   > To get an effective 5 bit shift, shift (DS,ES) left by 1 to get your 32 byte   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)