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   
   resolution, the natural nibble shift of 4 plus 1 by your adjustment.   
      
   Something nags me that we're not on the same line of thinking tho.   
      
   hth,   
   Steve   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)