8085 Dissasembly?

[Fred Cisin]

>> OTOH, Micropro had 8080 originated Wordstar running on the 5150 in weeks.
>> It took them longer to edit the manuals than to port the code.
>> Likewise Supercalc, etc.
On Tue, 17 Apr 2018, Warner Losh wrote:
> Part of that too was because MS-DOS provided CP/M programming interfaces,
> so in many ways it was CP/M with a bag on the side...

Certainly.

But, Q-DOS didn't have much of a bag.  It was mostly a rewritten copy of 
CP/M with a different data structure for disk directory.

LATER, starting with MS-DOS 2.00, there was a major bag of sub-directories 
and "unix style" file handling  (file handles V File-Control-Block)

And much later, for "long filenames" (Win95), MICROS~1 used a kludge bag, 
keeping the old 8.3 Directory structure and using "excess" directory 
entries for storage of the long nicknames.  HINT: do NOT use "long 
filenames" for anything in the root directory.

WINDOWS itself started as a bag hanging off of the side.  Originally, 
MS-DOS clearly documented what was needed for a replacement command 
processor.   (Was it 2.11?  or 3.00? when IBM removed the appendix from 
the PC-DOS manual, and started marketing it as "PC-DOS Technical Reference 
Manual" (still with "appendix" page numbering))


I always found it amusing that many programs (even FORMAT!) would fail 
with the wrong error message if their internal DMA buffers happened to 
straddle a 64K block boundary.  THAT was a direct result of failure to 
adequately integrate, or at least ERROR-CHECK!, the segment-offset kludge 
bag.  Different device drivers and TSRs could affect at 16 byte intervals 
where the segment of a program ended up loading.
It was NOT hard to normalize the Segment:Offset address and MOVE 
the buffer to another location if it happened to be straddling.

--
Grumpy Ol' Fred     		cisin at xenosoft.com