On Apr 17, 2018, at 8:25 AM, Warner Losh via cctalk <cctalk at classiccmp.org> wrote: ?? weren?t we talking about disasm? Maybe you got spell-checked, Warner?

How many started coding for a machine writing machine code? I recall that the IBM 1620 SPS coding forms had two sides--one for coding assembly (SPS); the other labeled "IBM 1620 Absolute Coding System". Basically a form with the first 5 positions reserved for the address, 2 positions for the opcode and 5 positions each for the P and Q addresses. You could enter the code from the form right into the console typewriter or punch it on a keypunch. If you were a real hard-case, you didn't bother with coding forms, you sat down at the typewriter and did everything from memory, mentally keeping track of storage addresses and what referenced them. Do this for a while and disassembly is easy. After all, you'll have all of the instructions and their opcodes committed to memory. I believe that I can still do this for 8080 code, in spite of my deteriorating wetware.

On 04/17/2018 09:25 AM, Warner Losh via cctalk wrote: Sadism on Intel's part but masochism on the part of those who willingly accepted it. Not sure where that leaves the rest of us.

bill

On Tue, Apr 17, 2018 at 9:12 AM, allison via cctalk <cctalk at classiccmp.org wrote: > Looked at 8086 and decided it was a 8080 with a bag on the side. > It was and still is irrational. With the 386 architecture (32-bit), they actually cleaned it up quite a bit. I won't go nearly so far as to say that 386 is elegant, but when running in 32-bit mode with flat addressing it's nowhere near as awful as 16-bit 8086 and 286. AMD did a pretty good job of further extending that to 64-bit. However, it does keep accumulating ever more bags on the side.

I hope RISC-V eventually drives a stake through it.

On Tue, 17 Apr 2018, allison via cctalk wrote: 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.

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.

from disk and jumped into; in the crash configuration, the overlay code

On Wed, 18 Apr 2018, Charles Anthony wrote: I'm learning a lot these days that would have been handy back then! Segment:Offset hides it until you normalize the resulting address. IIRC, INT13h should return a code of 09h if the DMA straddles a 64K boundary. But, not all code checks for that, or knows what to do when it happens. Looking at the value of ES:BX? can work, or, if it happens, swap your DMA buffer with one that is not used for DMA (and doesn't happen to be 64K away :-)? In my code, I happened to have buffers for several purposes, so that was easy to do. If operating above Int 13H (DOS calls), then you are dependent on DOS error checking.? "Can you trust THAT?" If operating below Int 13h, then be careful where your DMA ends up, work without DMA, or simply watch for occurrence. And, of course, a lot of C code can't tell the difference between end of file and a disk error. #define EOF (-1)??? /* depending on implementation */ while ((ptr2++ = fgetc(fp2)) != EOF); /* does not differentiate between error and end of file */ fgets() returns a null pointer for EITHER end-of-file OR error! and therefore assumes total reliability and any failure to read is assumed to be EOF. IFF available, feof(fp2) is much better. You certainly did the right thing, narrowing it down to load address.? The final conclusion would have been to systematically try many/all load addresses, and see whether it was consistent for given ones, and what the failing ones had in common. Yes, the "solution" for the extraneous FORMAT failure was "add or remove TSRs and device drivers"! When I first hit it, I used a P.O.S.T. card, and put in minimal code to output values until I realized that DS was the key, and that I had mishandled error #9.? Eventually I realized that even for code not my own, I needed to write a TSR intercepting Int 13H calls. (For exampole, the critical error handler in certain early versions of PC-Tools was more concerned with protecting their pretty display than success of writes!) Microsoft's response to error reporting was amusing. I was in the Windows 3.10 Beta, and encountered the SMARTDRV write caching problem.? There was apparently a flaw on one of my drives, that neither SPINRITE nor SSTOR could find.? But, during Windoze installation, a write would fail, and with write caching ON (Windoze installation did NOT give you a choice), there was no way to recover from a write error! (SMARTDRV had already told SETUP that it had been successful, so now, when the error occured, there was no way to (I)gnore the error (figure out which file copy had failed, rename the failed copy "BADSECS", and go back later to copy that one manually).? All you could do was (R)etry which didn't work, or (A)bort, which cancelled the entire setup before it ever wrote the directory entries for the files that had worked. By loading a bunch of space filler files on the disk, I was able to get the installation to be in a working area. Once I finally determined WHERE the bad track was, I put in a filler file to keep it from being used.? (SPINRITE tried to return it to use when I just marked it as BAD!) Microsoft's response was, "YOU have a HARDWARE problem.? NOT OUR PROBLEM." I was unable to either convince them that CORRECT response to a hardware problem was a responsibility of the OS, NOR that SMARTDRV with write-caching was going to cause a lot of data losses that they would get blamed for, inspite of it not be narrowed down to SMARTDRV, and that it would end up costing them a lot. Sho'nuff, COMPRESSION got blamed for the data losses. DOS 6.2x had to be put out for FREE to fix "the problems with compression". The "problems with compression" were fixed by having SMARTDRV NOT default to write caching ON, have SMARTDRV NOT rearrange writes for efficiency (it wasn't writing DIRectory sectors until later), and having SMARTDRV NOT returning a DOS prompt until its buffers were emptied. (One of the common losses was people would save a file, and turn off the computer as soon as the word processor came back to the DOS prompt. SMARTDRV had not finished writing their file!? When my girlfriend went back to school for some classes, she would stand with her coat on, pulling on the paper as her homework printed, then kit ^KD? and turn off the computer.) I was not invited to be in the 3.11, nor WIN95, Betas. They wanted cheerleaders, not testers, anyway. -- Grumpy Ol' Fred???????????? cisin at xenosoft.com

> I'm learning a lot these days that would have been handy back then!

Really? 64K boundary issues cropping up in MS-DOS? Egad, that would have been known in DOS 1.0. Certainly, for anyone writing his/her own low-level disk I/O, it was obvious. Now, I'll add that if you wrote your own specialized device driver, DOS did not guarantee handing your driver a buffer that obeyed the 64K boundary rule. I suspect that some DOS errors were reported to MS because of third-party driver bugs. And if you wrote a low-level driver that used 16-bit I/O, the magic number was 128K. But even in the earlies DOS 2.0 device drivers that I wrote, I included code to split the transfer up to get around the 64K problem if needed. --Chuck

So, at the time, looking at the 5150, it was an overpriced primitive implementation using a 1970s CPU. Many people at the time thought it would be less popular than the 5100.

On Apr 19, 2018, at 4:16 PM, Chuck Guzis via cctalk <cctalk at classiccmp.org> wrote: On 04/19/2018 12:14 PM, Fred Cisin via cctalk wrote: It's not so much expertise, but where you start your investigations. Right when I peered into the 5150, I saw the 8237 DMA controller (first cousin to the 8257) and recognized it from my 8-bit (8085) days. It was immediately obvious that IBM had taken a bunch of legacy 8 bit peripheral chips and shoved them into the PC. In fact, the 5150 was surprising in that how primitive the engineering was--something you didn't expect from a high-tech pioneer like IBM. So the DMA address space had to be 16 bits with simple bank select--using a disk controller chip that was design to be used with 8 inch drives.

On Apr 19, 2018, at 8:55 PM, Chuck Guzis via cctalk <cctalk at classiccmp.org> wrote: On 04/19/2018 07:56 PM, Guy Sotomayor Jr wrote: But it wasn't clear at all what IBM intended the PC for. Cassette tape, TV interface and anything but state-of-the-art design The best part of the 5150 IMOHO, was the keyboard.

My general impression is that IBM made the 5150 product, without the faintest idea of how they were going to sell it.

That reminds me of when I phoned IBM here in Ireland looking for software support for their VM mainframe operating system not too many years later, sometime in the early 1990s. I spelled out every variation of the name I could think of but they kept asking me what version of OS/2 I had. I guess by then the circle had turned again.

Did they think that you were saying "P M"? "PM" ("Presentation Manager") was the OS/2 equivalent of "Windows" Tell them that you mean 'V' as in "Venus" :-)

On Tue, Apr 17, 2018 at 7:12 PM, Johnny Eriksson via cctalk < cctalk at classiccmp.org> wrote: > Bill Gunshannon wrote: > >> Many of us think that the advent of the x86 architecture is what led to >> masochism.

> ... or masochism led to the x86 architecture.

I think you are confused maybe. Wasn't it sadism?