I’ll have to get past my current (for pay) hardware design task first. Then I’ll brush off my 9900 cobwebs and put something together.
A great story. One that I’m sure makes you one of the founders of the PC revolution. I had a part to play many years ago, too. I was the PC product manager for Olivetti and the M1. This machine was the same machine as the AT&T 6300. AT&T had a facility in Italy managed by Olivetti making PCs. The 6300/M1 machine was 8086 based instead of 8080 like the XT.
Good times going to the conventions, negotiating with Microsoft, promoting Digital Research’s CPM which was king then, and trying to make the world believe the Italians built PCs. Neither the 6300 nor the M1 were ever a big hit, but I got to know a lot of the major players in the PC business
Remember when Gates said, " 640K of memory ought to be enough for anybody?" I know the authenticity is debated but I still think the statement is a bit funny. Isn’t it a good thing Al Gore created the internet? 
I love this thread because it reminds me of the many good times in the computer business.
2 Likes
I have one of those rare TI 99/4 computers here. Last one I had I sold for $250 for just the computer, A/V cable, and power transformer - 7 years ago. 
A little clarification: The IBM XT was 8088, which is identical to the 8086 other than the data bus width. It took more cycles to fetch instructions, so programs would run ever-so-slightly faster on the 8086.
I had one up until 2008 when I had run out of time vacating my apartment and it got left behind.
I still have a Compaq and an IBM luggable… a Kaypro, and an Osborne too (with internal modem and an amber screen cover!)
And IBM made an XT/286, but those are hard to find.
1 Like
My favorite was the XT/370. In addition to DOS it ran IBM mainframe code. Allowed me to run UTPS faster then I could on the mainframe and the cost of the computer was less then I was charged for three months access to the mainframe.
I have an S-100 bus machine with Godbout CPU, memory, disk controller, and I/O boards, as well as some prototyping boards and S-100 extender card. Also have several 8" drives, but I’ve yet to get them to be reliable. The biggest issue is with the 8" media instead of the drives themselves, as the oxide flakes off and coats the heads necessitating frequent head cleaning. I got a few boxes of NOS 8" diskettes still in shrink wrap. Just haven’t been able to find time to get back to it.
I was considering making a case out of 1/2" or thicker acrylic so one could see inside of the motherboard unit and the disk drives. The motherboard power supply is a linear and it is H-E-A-V-Y. Does anyone have a supply of 48 hour days that I can have?
1 Like
Sounds like a candidate for a floppy disk emulator.
I have a friend with an original TRS 80 Model I, and he might be willing to put it on semi-permanent display at DMS.
Just a reminder that there is limited space on the shelves, and limited power. Also, no camera on the equipment, so if any schenanagans we have no way to identify who.
1 Like
An ancient piece of hardware caught my eye on the donation shelf tonight. By ancient, I mean it was implemented with only DIP packages - not one surface mount in sight. It turns out that the processor on the board is an NEC V20.
For those who do not know or remember, the V20 is a pin-compatible replacement for the Intel 8088. Many of us performed a brain transplant on our PCs or clones to get a small performance boost. As slow as that machine was, every little bit helped.
But the greatest feature of the V20 was what NEC called the “emulation mode.” Several instructions enabled running code written for the 8080. Yep, you read that right - the 8080. There were several utility programs which allowed running CP/M programs (only those which did not require a Z80) at full speed.
I think it may be possible to write a program to let us actually boot up CP/M on a PC/XT class machine with a V20 transplant.
1 Like
I have acquired a couple of sets of XT/370 or AT/370 boards, but have never gotten the software so I never got it to run.
The board set used a couple of custom 68000 processors and an 8087.
Today, you can have a much faster mainframe in your PC using the Hercules emulator. You can even get official copies of MVS from Big Blue, along with many of the compilers.
Here is the story from a different viewpoint:
In 1980, business microcomputers were either an Apple ][, a TRS-80 or some kind of CP/M box. CP/M was favored because it hosted SuperCalc, WordStar and dBase, the leading business applications at the time.
Xerox Corporation wanted a microcomputer offering so that their sales staff can go into an office and sell a complete bundle: copiers, typewriters, fax machines, dedicated word processors, printers and computers. They licensed the Big Board from a small company in Garland and built their 820 CP/M computer around it. The computer board was built into the base of the monitor enclosure. Internal improvements led to the 820-II with an optional hard drive.
With the debut of the IBM PC in 1981, Xerox did not immediately feel the fear. After all, there was “no software” for the IBM machine. At the time, CP/M was where the action was. Xerox did recognize the better ergonomics and expandability of the IBM design so they came out with a low profile keyboard and an expansion cabinet.
As more software became available for the IBM PC, Xerox developed an add-on board for the 820-II with an 8086 coprocessor and its own RAM; it used the original peripherals. Hence, the 16/8. It could boot either CP/M-80, CP/M-86 or MS-DOS.
But its Achilles’ heel was that it was nowhere near hardware compatible with the IBM PC. As more software resorted to direct access to hardware for better performance and capability, Xerox knew it was going to have to change.
A deal was made with Toshiba to manufacture a line of PC compatibles. About a month or two before it was to ship, IBM dropped the other shoe - the PC/AT. It was substantially faster than the PC or XT partly because of a faster clock (6 MHz vs 4.77 MHz) and partly because the 80286 was a more efficient processor than the 8088.
For several months, no managers can be found; they were all in meetings trying to figure out what to do. The decision was to license the M24 from Olivetti since no one else had an AT compatible yet - it was not quite AT fast, but twice that of the PC/XT.
An internal joke was “we shall leave no clone unturned.”
3 Likes
The workspace pointer was an unusual concept (for a microprocessor) which allowed for quick context switches.
Fast context switches were the biggest benefit of having the register banks in memory. When the 9900 was introduced around 1976, the speed difference between the CPU and external memory was much less than it is today (or has been for quite a number of years). Therefore the penalty paid by having all of the registers in external memory wasn’t so bad.
For those not familiar with the 9900 architecture, it has only 3 registers,
- program counter
- status
- workspace pointer (or WP)
The first two registers are standard fare in all processors, but the workspace pointer is unique to the 9900, although some of the RISC chips had this but with a large bank of switchable internal registers. The 9900 has 16 registers available to the programmer. But these aren’t really registers at all - they are 16 contiguous 16-bit words in memory, aligned on a word boundary. The address of the beginning of this memory block is what is stored in the workspace pointer register. Thus, the workspace pointer holds the address of register 0 (or R0 in 9900 assembly language).
One side effect/benefit of this is that the registers could also be accessed as memory (since they were!) if one knew the value of the workspace pointer. All of the memory addressing modes - indirect, absolute, indexed - could be then used to access the registers. This turned out to be quite useful when writing assembly language code.
The performance hit of having all registers in external memory was exacerbated by the inefficient 9900 memory access microcode, as mentioned in an earlier post. Any 16-bit memory write to a (16-bit) word-aligned memory location also caused an unneeded dummy read (needing extra clock cycles). This was a result of saving microcode space to keep die size small(er), as mentioned in a prior post.
This dummy read-on-word-write impacted the hardware design also, mainly when connecting memory mapped peripherals. Normally peripherals will have a small number of (register) addresses that are read/write. But due to the dummy read on write, any peripheral where reads have artifacts must be connected to the 9900 so that reads and writes to the same peripheral address must be mapped to disjoint 9900 addresses that are at least one word apart. This required disjointed addressing is a result of the 9900 having a 16-bit bus and no byte enables. Thus adjacent byte accesses in the same word both cause an (indistinguishable) access to the same word.
The memory map of 99/4A mapped devices (VDP, GROM, sound) reflect this, as shown in the following directives for the VDP read/write data registers.
VDPRD EQU >8800 VDP READ DATA WINDOW ADDRESS
VDPWD EQU >8C00 VDP WRITE DATA WINDOW ADDRESS
The TMS9985 (see prior post) was never released, but instead a TMS9995 was introduced. Like the 9985, this was a 9900 CPU with an 8-bit data bus (think 8088 vs 8086) with much faster instruction execution times and 256 bytes of internal RAM (for fast workspaces). The dummy reads were eliminated on 16-bit writes, a byte access only affected that byte address, and lots of internal CPU cycles were eliminated. Even with the 8-bit bus and the same clock speed, the 9995 was much faster (2x-ish) than the 9900.
The 9995 was used in the 99/8 (code name Armadillo), which was the 99/4A followup product that was never introduced. The 99/8 actually included a wait-state inducing slowdown circuit that was designed to match the speed of the 99/4A when legacy 99/4A programs or cartridges were run. This was needed because much of the 99/4A software implemented delays using software loops - a direct result of the brain-dead way that the TMS9901 timer interrupt routine was dedicated to the cassette bit timing code and thus unavailable to implement interrupt-driven delays. 
While composing my post on 9900 context switching, I found the following set of 9900 cross-assembly tools created for 99/4A program development and emulator use.
This appears to be an awesome and very complete set of tools. They are written in python and open source, and would be perfect for use in a 99/4A assembly language programming class.
1 Like
Fortunately, I no longer need to run UTPS models. Now the models run on PC’s or on the cloud and take even longer to run then the UTPS models on a system 370… And produce less reliable results…
But at least no JCL…
The TI 9900 was a single chip implementation of the architecture of their 990 family of microcomputers (which was built from bit slice components.) The inefficient memory accessing was probably the result of reusing much of the microcode from the mini. I had looked into the “writeable control store;” it is extremely tedious, much worse than assembly language - sort of like conducting an orchestra versus inserting a CD and pushing “Play.” I quickly lost any desire to experiment with it, though my cohorts who were into computer architecture were drooling all over themselves.
The 990 had another unusual feature in that some terminals were “memory mapped.” The terminal controller plugged into the card cage with a video cable going to the terminal instead of a serial connection. Screen updates were lightning fast.
What I find interesting is that the registers in many of our current microcontrollers are also mapped as memory locations, though we cannot switch them like with the 9900.
The 911 terminal was the one with the video controller at the CPU, with interface via CRU.
The 914 emulated an IBM 3270.
For a stroll down TI legacy computing memory lane…
http://terminals.classiccmp.org/wiki/index.php/Category:TI