Am 13 Nov 2003 18:12 meinte Tom Jennings: YESSSSS! I didn't find a lot of 8080 legacy. Shure, the registers where named in a way to make 8080 people feel comfortable, and things like DAA where added to allow atomatic source translation, but that's it. It didn't come in my way when programming the 8086. :) The segmentation had _nothing_ to do with the bus, which was a straight 20/16 Bit address Bus (20 Bit Memory, 16 Bit I/O) and 16 Bit Data. That's rather a fault of Microsoft than Intel. Now, that is something to blame on dompiler developer. True, it was initiated by Intel, but I can't blame the CPU or the CPU designer for that. In fact, I never understood what these 'models' are good for, since they just define special cases within the only Model the CPU knows. Now, this again is not a foul from Intel, but Rather IBM, I'm still mad about what the PC did to the nice x86 design. Especialy the usage of reserved Interrupts for BIOS and DOS :( That's the other thing I never understood, RISC vs CISC, depending on which argument one uses, the 86 becomes CISC or RISC. I thought so. Ok, now we're getting there... Signetics always had a faible for odd designs (although the 2650 was the first CPU I ever owned), but the 1802 design again is to me also one of the nicest around. Maybe today it would be called a DSP or alike. The whole setup was extreme I/O orientated. One thing I always wanted to design was a dedicated I/O board for the Apple using a 1802 as controler. To me the most important thing when it comes to programm a CPU is to understand and _accept_ it's design. To read opcode-tables to understand the way of operation the designers had in mind is like reading a book and trying to figure oput the motives of the characters and what the author wanted to tell ... And like with such BIG, HEAVY contend loaded books it's often quite trivial. And then programming is not forceing some way (algorythm) onto the CPU, but rather suit it so it fits what the chip is ment to do. I realy dislike it when people want to be each new CPU like the xyz (put in your favorite CPU), and C is nothing else than a way to do exactly the same. The result is the quite unified CPU designs we have today. Everything looks like a bastardized PDP11 (well, except for the 8051 mixup). It's like no CPU designer has any more the guts to come up with something interesting, optimized. Ok, maybe I'm doing the engeneers wrong, and it's the middle management (*1) that, like in the musik industry, fears anything special and trys to be as riskless as possible. The last design which had new ideas (to me) was the C16x series layed out in the mid 80s. It's realy getting boooooooooring. Out of all the modern stuff only USB did catch my full attendace as a first class playfield. Gruss H. (Going back to sleepmode) -- VCF Europa 5.0 am 01./02. Mai 2004 in Muenchen http://www.vcfe.org/

Am 14 Nov 2003 12:08 meinte Tom Jennings: Naa, I'm German, it needs a lot to get me considering a response rude :) Maybe I don't, maybe I just survived 20+ years of x86 programming (including doing a BIU design for an embeded 8086 core) by completly missing the point so, I'd ask you from the deepest of my heart, don't tell it to the programms I wrote, they may just stop working, and I sued to the last penny:) That site I have to bookmark, that's a perfect example how to torture a CPU. As I said before, I can't see why someone want's to interfer with the way a CPU hardware generates a memory address, except of course for the memory manager. Let's just take a step back, the 8086 is a 16 Bit CPU, 16 Bit, nothing else. Address size, as seen from a Programm is 16 Bit. Thus it is able to address a continuous memory of 64K no Byte more. If you need more than 64K, request an additional segment. The stupidity of memory models comes from assuming a certain behaviour of the CPU AT USER PROGRAMM LEVEL - BTW: that's exactly the reason for the ever doomed A20 gate, asuming that Sebents are mapped somewhere onto each others, and accessing an address greater FFFF:0010 results in Addressing 0000:xxxx. What is so hard in seeing the segments as independent from real memory? Who cares (on user level) on what real address your code or data resides? You don't do under any VM system, so why should you do so under an 8086? All a user process has to care about is his _own_ address space, which is given as a set of segment descriptors. Now you're starting to get rude :) Serious, there's only one model, and that's segment:offset, I couldn't find for example some hardware for a 'small' model in all the time I worked with an 8086. the so called small model is just a special case, where an application owns exactly one segment, and CS=DS=ES is assumed (since all are loaded with the same value). Show me where there's a special hardware to support that, or enforce it? You can't find it? Cool, so do you still want to argue that it's a hardware feature? Or isn't it rather something made up by Compiler designers to simplify their work? Gruss H. -- VCF Europa 5.0 am 01./02. Mai 2004 in Muenchen http://www.vcfe.org/

Wasn't sure anyone wanted to hear rantings. I'm not sure how much I can recollect. It was a painful port. At that time (1981-ish) I was doing MSDOS ports to all sorts of soon-to-be-killed-deader-than-dead MSDOS machines (the steamroller that was IBM as well as the foolishness of some of the ventures). I believe we (Phoenix Software later Phoenix Technologies) were the sole subcontractor for Microsoft, installing MSDOS on various boxen. Typically I'd get raw iron with an empty EPROM socket, and a scribble of I/O port assignments and I'd hack in my canned 8086 debugger, get the console to work, then get the floppy to work, etc. I had a standardized BIOS (IO.SYS) implementation -- the table driven part of MSDOS 1.x and 2.x that DOS called to read console, disk, etc. A device-independent part that did all the block to track:sector:head mappings and deblocking, DMA buffer crap, canonical clocks etc. There were only two floppy chips (WD and NEC), very few DMA controllers, Remex HDs etc those days, so I always had code to reuse, only had to write dumb low-level device drivers, the device-independent part did all the error checking and such. Once the EPROM debugger was up I could do a whole MSDOS install (dma, interrupt serial devices, floppy and hard disk formatters, in 3 - 5 days tops. The Rainbow was in this sort of realm, except DEC and M'soft had some legal battle, something like M'soft suing DEC over not providing it the data needed to port MSDOS to it. That sounds wrong to me now, but there was some legal hassle. Eventually it was 'permitted', and I had to go to DEC (I lived in Mass. at the time) to meet'n'greet. They basically refised to divulge things like IO port assingments and the operation of the thing I called the MHFU (Massive Hardware F**kup Unit, or something) that rebooted (CPM-86!) if you turned interupts off for more than a few tens of milliseconds. Bureaucracy in firmware. I forget, but the DEC Rainbow took months to make go right. I did MSDOS 1.25 or something, someone else, possibly DEC-internal, did MSDOS 2.2. (As an odd aside, one of the DEC bigwigs, I cannot recall his name, who was in on the nonsense, later got interested in Fido/FidoNet on the Rainbow, maybe Dave Mitton can recall his name... I think he was trying to see how it would be good for DEC, or something.) So I arrived with Neil Colvin and David and we get sent to this big meeting room. We were made to wait an obvious interval. Two DEC lackeys came in the room, left, close the door. A few minutes later, two different lackeys, then an engineer, and a bigwig or two, like some Sopranos episode. I forget the details of the meeting, but my peer nerds were of course fine. Basically I got shown some listings and port EQU's and such. I think they were embarrassed by the 100A's architecture: Some BOZO designer had, I assume arrogantly, put all the video interrupts (vert, horiz retrace, etc) starting at 00020h, which everyone knows is where MSDOS has it's software interrupts. They were in a PAL or something, and could not be moved. So the Rainbow is really a Z80-based CPM machine, with a "slave" 8088 in a bag on the side. THey have shared memory, maybe a bit more. There was some communications mechnism between them that was reasonably fast, but the 8086 could not read the floppy, for isntance. I could be way off on the details here. So MSDOS diskettes were really z80-side drivers that performed services for the MSDOS side (one side effect was a small 8088 I/O system and some I/O overlap). Booting was difficult due to the MHFU; I *had* to turn interrupts off for some short period, or it might have been the MSDOS.SYS code, over which I had no control, turned interrupts off. There was a watchdog timer reset by some ROMed routine that killed the boot process. I can't recall his name, but there was a very helpful software person at DEC that was quite helpful. From him I offically got *barely* enough data to disable the MHFU. This was a Big Deal. Everything was like pulling teeth with DEC. If I recall, even Msoft considered a patched MSDOS.SYS that did something to ameliorate the MHFU unit. INT 21h was the worst. It was the vertical retrace interrupt, I think, not many times a second (60) but it's of cuorse the MSDOS system call interrupt. I had to do a bunch of actual analysis and statistical crap to work out a solution, whichw as basically (don't quote me): interrupt_service_routine for 0021h: if (flag set) { # ends up here ONLY push psw; # on re-interrupted ISR longjump saved_vector; } saved_vector= stack[-2]; set flag; enable interrupts; # this is the nop; # heart of the test disable interrupts; # clear flag; enable interrupts; simulate MSDOS 0021h iret; Basically, this code was installed at boot time, and handed CPU interrupt 21h. Its job was to determine if the interrupt just received was a MSDOS system call, or a hardware vertical retrace. You can tell the difference because a HARDWARE interrupt remains asserted until cleared in the interrutp controller; the set flag/reenable interrupts allowed the ISR to be interrupted. (I ended up with a clever (monkeys are "clever") method of executing software interrupts that avoided the un-believeably slow INT/IRET pair, explicitly pushing/popping flags that makes no sense but was faster. I used it in the old FOSSIL drivers later.) There is of course a two-instruction window for a hardware interrupt to occur when servicing a software interrupt. The ratio is something like 60Hz vs. the two instruction execution times, so the 100A was guarenteed to crash every few dozens or hundreds of hours (I forget, and lost all the documentation). Basically the machine sucked. The floppies were stupid ("A" drive, the floppy went in one way, "B" the floppy had to be turned over). THe 100B was the same, I think, EXCEPT there was a way to programmatically move the display interrupts from 002xh to something else that didn't interfere with MSDOS.