On Mon, 28 Jan 2008, Jim Leonard wrote: PROBABLY not similar circuitry. The Victor 9000 did almost nothing the same way as PC. That was a normal feature of MDA INT 10h, function 0Fh returns in AL with the numeric value of what video mode is in use. 2 = B&W CGA 3 = color CGA 7 = MDA IFF sufficiently compatible (Toshiba T300 was NOT), then 2,3 mean B800h and 7 means B000h In the early days, it was possible to call BASIC subroutines. But, I don't think that they kept the same addresses for long. The publisher (Vertex) wanted it much more secure than that (paranoid idiots). It was a "special version" that they hoped to peddle to IBM. It clearly stated on the startup screen that it was for IBM PC ONLY, but PC-WORLD used it for their testing. So, I used the BASIC floating point accumulator for passing an argument back from a function. The publisher tested whether it would run on a generic clone with copy of IBM's BIOS (but without BASIC ROMs) By the time that I got rid of the publisher, I used DOS calls, BIOS calls, and VERY little direct hardware access (video RAM, and a little twiddling with the FDC) Unfortunately, the third time that my company moved (in 1988), the two totes with EVERYTHING from that never really finished program disappeared. I hadn't done anything very fancy - checking the processor, whether certain BIOS calls worked, entry locations, the presence (and CRC'd content) of ROMS, and checking a BUNCH of the segment 40h BIOS memory locations. Working with the "NON-PC-compatible" MS-DOS machines, such as DEC Rainbow, TI Proffessional, Toshiba T300, Sanyo 550?, HP 150?, Tandy 2000, Victor 9000, etc. would require major additional work for EACH one that you support. Unless you are willing to fall back to ONLY MS-DOS calls (MOV AH,2 MOV DL, 7 INT 21h to beep), etc. stick with "clones". -- Grumpy Ol' Fred cisin at xenosoft.com

In the early 8088/86 days, manufacturers like DEC, HP, TI and Zenith thought they could compete with IBM by being "better" in some way. Zenith had 640x400 graphics and did the Tandy 2000. The TI had great graphics. HP, with 3.5" floppy drives, didn't even try to be really try to be compabible - but it ran MS DOS! HP was not even consistent within their own model lines! The HP Portable Plus would not always run programs written for (or ported to) the HP150. When I first became interested in collecting (late 80's) my first target was "DOS Incompatibles" like those named above. I had a Wang PC (great text but little IBM compatibility), Zenith, etc. In the early-mid 80's a program was "well behaved" if it did it's I/O thru DOS calls. Those programs would run on just about anything. dBase II (a port from CP/M) would run on most DOS machines of the time without modification. Mitch Kapor ended that with the release of 1-2-3 and new programs like dBase 3 were IBM PC-specific. A few manufacturers (like HP) paid Lotus to port 1-2-3 to their machine to lure customers but that was a loosing game. So to the original question -- the three requirements will limit the program to "true compatibles", meaning a hardware clone. The most incompatible MS-DOS machine ever, the Seattle Gazelle, uses a serial terminal so the only "sound" available would be the terminal bell. Jim Chris M wrote:

scheefj at netscape.net writes: Were there similar problems in the CP/M world? That is, was it commonplace for there to be CP/M programs that bypassed CP/M BDOS calls and wrote directly to a specific machine's hardware? Seems like CP/M developers were more disciplined in this fashion, but maybe it's just because in the CP/M arena there were so many different pieces of hardware it was the only way to do it? (Whereas with IBM, the PC was seen as more of a reference standard, even if it wasn't really that way in the beginning?) I'd be interested to hear opinions from people who were there at the time, since it was a little before my time. Josh

Joshua Alexander Dersch schrieb: MS-DOS and CP/M were suffering from similar problems. For CP/M, namely the 1.x and 2.x versions, the difficulty was that the BIOS was not sufficient to abstract all hardware that was available. Typically, floppy low level formatters had to be written to directly talk to the FDC rather than having an available call "format the floppy in drive A:" as there were so many different FDC boards. The interrupt and DMA handling was also lousy thanks to DR abusing some 8080 and even worse Z80 RST vector locations for the BDOS and CCP buffers and FCBs. Finally, there was no portable way of abstracting additional serial or parallel ports that did not fit into the IOBYTE scheme. The whole improved somewhat with CPM+, but still was not good enough to allow writing portable code. MSDOS was much better in abstracting hardware, because it had a loadable driver concept. Difficulty was again the BIOS which required to be "IBM compatible". For the original IBM PC and XT BIOS, Microsoft made some hacks of not calling the official entry points but also silently jumping into unofficial locations which forced them to be fixed and supported in later AT and AT386 and particularly clone BIOS. Unfortunately, IBM hardware developers didn't define reasonable interfaces to the hardware interrupts in the BIOS already, but left this task to the OS. While it was possible to access serial lines through BIOS software interrupts, these were (compatibility to old CP/M?) polling interfaces, that didn't use the available interrupt controllers. Effect was that some hardware vendors implemented such interfaces differently, and provided some loadable drivers, but prominently, software vendors who made serial communications software, like Procomm, pc-terminal etc. again wrote their own, less portable interrupt-driven,direct-I/O software because I/O through BIOS was unusable except for 110 Baud TTYs. When 640K was found to be insufficient, numerous unportable solutions came up to increase memory, from EMS to XMS, filling the gaps between video memory and extension ROMs, and reusing the wraparound bug of the 286 that allowed to access 64K beyond 1M without protected mode. The A20 gate came from there, but when I once disassembled and analyzed HIMEM.SYS, I found about a dozen different ways to switch this bit - through KBD controller, certain chipset ports, through some reserved memory cells, by issuing some obscure interrupt. Intels LOADALL also was played out there - everything done to circumvent the deficiency of the original design. Point is there in both cases: the hardware designers did not foresee how their hardware could or should be used by software, so they basically implanted the bare chips, not even respecting IRQ and DMA requirements; the OS developers did not foresee usable and extensible interfaces to access and abstract various hardware and just hacked something that it would somehow work; and finally the application designers found the whole base OS functions where plain unusable and reinvented, each one differently, the wheel, leaving burnt ground for others that somehow required similar functions - "thou shall not use the printer port for your dongle, I have it already." -- Holger

On Jan 29, 2008, at 4:33 PM, Joshua Alexander Dersch wrote: I was there; I was a CP/M weenie for many years. I still use it The CP/M BIOS definition doesn't provide for all the things a user might want his/her hardware to do. Accessing serial ports efficiently is one thing...Some popular CP/M communications programs, such as the MODEM7 family, used the concept of "overlays" (not the kind that we use in the PDP-11 world!), which are assembly language modules which are written for your specific hardware that present a unified (BIOS-like!) interface to the rest of the MODEM7 code. It was intended that end users would write these routines for their specific hardware. (in a day when end users were typically highly technical people) Formatting floppy disks is another example. The CP/M BIOS has no provision for floppy disk formatting, so a formatter program had to be written for each floppy controller, and it accessed the controller's registers directly to perform the formatting (and sometimes verification) function. Other than specialized hardware (lab I/O, speech synthesizers, real-time clocks) there weren't many instances of programs directly accessing I/O in my experience. -Dave -- Dave McGuire Port Charlotte, FL

On Tuesday 29 January 2008 16:33, Joshua Alexander Dersch wrote: There was stuff written for specific hardware (floppy formatting code for one fairly typical example), and then there was stuff that got patched for a specific machine, which more often tended to address things like video attributes and similar stuff -- I know that the copy of WordStar I used to use on my Osborne Exec was patched all to hell. :-) So was the directory listing program I used, "sd". Other code that often needed to be modified for specific hardware or machines were comm stuff, which more often seemed to have a bunch of "overlays" available for each machine, so that things could address the serial port (or the PMMI S-100 bus modem) properly. I probably have piles of this stuff in my old bbs files area, if there's much interest in it. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, ?a critter that can be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On Sunday 03 February 2008 23:36, Dave McGuire wrote: I just put the file "tans_cpm.zip" at http://www.classiccmp.org/rtellason , let me know if there's anything specific in there that you want and we'll work it out from there. Or if the file isn't accessible for some reason. A lot of what I've got is from the old Simtel CP/M archives, some of it cleaned up a bit and repackaged, some other bits added from here and there. I've had the idle thought lately of putting a bunch of what used to be in the bbs files sections online, or at least portions of it, but time is tight these days, so it'll have to wait for a while, though I don't mind passing files along to what folks want 'em. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, ?a critter that can be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On Tuesday 29 January 2008 14:54, scheefj at netscape.net wrote: I used to work with a dealer that sold those, and I recall a board that you could add to them to make them somewhat more compatible, though I don't remember now what was on it. The last time I had boards and other parts for one of those I couldn't find *any* interest in them at all. Might've been before I found this list, though. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, ?a critter that can be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On Sunday 03 February 2008 13:52, Chris M wrote: Why, if you don't have that system? It was pretty oddball, for sure. The one thing I do recall about that card was that you plugged your monitor into it rather than into the usual place. But that monitor was totally non-standard, too -- it used a couple of different DIN connectors one of which was for supplying power to the monitor, which had no AC cord. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, ?a critter that can be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On Tuesday 05 February 2008 18:39, Chris M wrote: Ok, well if I should ever happen to run across one I'll definitely keep you in mind... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, ?a critter that can be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

The Victor 9000 (Sirius over here) does have a speaker. But it's not driven by an 8253 (or 8354), in fact there is no such chip in the machine. It's driven from a PCM codec chip. The bitstream for that comes from a 6852 (synchronous serial chip), the clock comes from one of the counter/timers (line PB7???) of the 'User' VIA. Yes, the input side is connected up as well, there's a pin header on the mainboard that can be used to feed audio into the codec, and the bitstream from that goes to the 6852. Please don't ask me how to program that to make beeps ;-) That, IIRC, is what a real _MDA_ card does. -tony