pnr

Hi, Many thanks for that link! It explains why sometimes TI marketing documents refer to the 99120 as having the "Rx kernel" in macro rom and sometimes as having Pascal support instructions in it. In TI's vision for Microprocessor Pascal the two are closely linked topics. This would be the manual "990/12 Writeable Control Store Assembler and Language". It describes the details of microprogramming a TI990/12, I understand. As the 990/12 was released in 1979, I would assume that this manual also dates from 1979, possibly with later revisions.

Perhaps it is a good idea to test with prototyping mode first. This mode is enabled by keeping /app grounded during reset and releasing it after that. To set up a simple prototype test do: - place >0880 at macro location >0800; this is the first entry in the jump table and used for macro opcode >0000 - at macro location >0880 place some test code, for instance to normal memory location >6000 to >5A5A: LI R0,>5A5A LI R3,>6000 MOV R0,*R3 RTWP - set normal memory location >6000 to >0000, set the next instruction to return to the monitor (e.g. to EVMBUG or EASYBUG). - start execution at location >6000; this will execute opcode >0000, which traps into macro store via the jump address at macro location >0800; the macro code changes the >0000 at location >6000 to >5A5A and returns for the next normal instruction (i.e. returns to the monitor).

Many thanks! - Directing macro code execution to location >1000 is indeed achieved by executing an opcode that is not defined in the built-in macro rom on a 99110. Opcode >0000 would be a good choice. This is documented in section 7.3.6 of the data manual. As the chip will be running in standard mode, there is no need to set up the jump table at external location >0800: the internal macro rom already has the required settings. If the chip would be running in prototyping mode, with a user supplied jump table at location >0800, the macro rom would be entirely switched off and inaccessible. - Yes, macro store accesses are defined by bus status code 000 and 001 combined with MEM# being high. I at first also thought that this was rather odd, but if you think of MEM# and BST1-3 as being a 4 bit bus status code it makes sense somewhat. The manual does not say what the address bus will be during internal ALU cycles that share their status codes with macro store accesses. At worst the external macro store chips will be selected (I mean have their CS# low), but with no WR# or RD# pulse occurring. The only ill effect I can see would be to drive up power consumption a bit, but I don't think they were worrying about such things in 1981. You would have to be careful with generating wait states though: if you drive READY low during an ALU cycle it, too, will be extended. I did test prototyping mode on my modified experimentation PCB and it all seemed to work as described in the manual.

I'm aware of only one (publicly available) design that incorporates the TMS9911 DMA controller, and that is the Powertran Cortex. In particular I was wondering about its clock input. In the Cortex design this is hooked up to the *inverted* CLKOUT signal of the 9995 CPU. From studying the data sheet, I see no particular reason for this inversion. The datasheet does refer to this input as inverted ø, but that is probably because it refers to the inverted ø1 output of the TIM9904 or the inverted ø3 output of the TMS9980/9981 as possible sources for this signal. Does anybody know of other (public) designs using that chip, or have experience with it?

In several 99xxx designs (for example this one: http://www.itech.net.au/tms9900/downloads/tms99105a_sbc.pdf) I see the interrupt lines being latched on the rising edge of CLKOUT. I wonder if this is necessary. Neither the 9900 or the 99xxx data manuals specify that interrupt sources must be synchronised. The 9900 manual says that the interrupt inputs are monitored continuously (but presumably in particular during clock phase 4) and the example external circuit does not have a synchronising latch. The 99xxx manual says that the interrupt inputs are sampled on the falling edge of CLKOUT; here there is no example circuit. However, the design handbook "The 99000 microprocessor - Architecture, software and interface techniques" does claim that inputs must be latched at the rising edge of CLKOUT before being fed into the priority encoder (74LS148 etc.), and the example circuits all have such synchronisation. The only reason I can see for such synchronisation is that it avoids a bad interrupt level being read if the priority encoder is changing state just at the time of the falling CLKOUT edge (e.g. interrupt #2 being out-prioritised by interrupt #1 and the encoder giving a transient result suggesting a #3 interrupt was present). This condition is more simply (and cheaply) handled in software, imho. Does anybody see another reason?

Those are very interesting results! Either that, or the package contains 99000 silicon. Luckily, this can be tested. In the case of 99000 silicon, trying the CIR instruction will leave R0,R1 unchanged, but generate an illegal opcode interrupt (#2) and set the ILLOP flag in the error register (CRU bit >1FDA, see manual section 4.4). A faulty ROM would not necessarily do that. The other test is to try the LMF instruction (opcode >0320) and see if that is illegal. If it is not, the chances of getting those two results just because of an error in the macro rom are not that high, imho. The markings on that chip are actually very similar to the markings on the chip that JH is using on his board - it would be interesting to see if that chip has 99110 silicon as well (and I suspect it will be). Out of five 99105 chips tested, we now have 3 that appear to be 99110's inside, and two that appear to be 99000's (or faulty, to be determined). I hesitate to ask, but will anyway: how hard would it be to modify the FPGA to emulate a little bit of macro ram at macro address >1000? That would enable testing the extension feature on the chip with 99110 silicon (my 'new' chip will not arrive for another week or so - and may turn out not to have 99110 silicon anyway ) If the extension interface of manual section 7.3.6 is present and working, one could add the following macro code (starting at macro address >1000). This would copy out the 1KB of macro rom to normal RAM address >6000 (indirect addressing using R0 references macro space, using R3 references 'normal' space). >1000 DATA >AAAA >1002 LI R0,>0800 LI R3,>6000 LOOP: MOV *R0+,*R3+ CI R0,>0C00 JLT LOOP RWTP (By the way, if this would work on the other 99105 you have, it would offer another way to see if it is a 99110 with a faulty rom or something else).

Your understanding is basically correct, but the design purpose of macro code was not just speed. It was basically a follow-on to the complex instruction set of the TI990/12 mini computer and its user writable micro code. It was also a way to customize interaction with a MMU and a way station when developing co-processors. For a quick description of the 990/12 see the attachement. For a description of the full 990/12 instruction set, see here http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/990/assembler/2270509-9701A_AsmRef_Nov82.pdf It would seem that the micro-code user guide is lost, unfortunately. With external macro rom and ram, it is possible to implement the full 990/12 instruction set on a 99000 CPU and to provide an alternative to user writable micro-code, using normal assembler code (plus a few extra instructions, like 'EVAD'). According to the contemporary materials there were 3 versions of the 99xxx: the 99000 with just LDD, LDS and LMF in internal macro rom (for the 990/10A mini), the 99105 without internal macro rom and the 99110 with the 990/12 single precision floating point instructions and LDD/LDS in the internal macro rom. There is a lot of mention of a planned 99120 with parts of the "Rx" micro-kernel of TI's "Microprocessor Pascal" in its internal rom, but this was most likely never produced. In reality it would seem that only 99000 and 99110 silicon was produced and that chips marked "99105" have either 99000 or 99110 silicon inside. We still need to test more 99105 chips to understand this better. I've modified Stuart's 99110 experimentation PCB (see http://www.stuartconner.me.uk/tms99110_breadboard.htm) to handle external macro ram and to see if we can access the internal macro rom to see what is there. The 99110 offers an extension feature which seems to make this possible. My current 99105 seems to have 99000 silicon and does not appear to have this extension feature. Another 99105 is on its way from China and I hope this will have 99110 silicon (chips marked 99110 seem to be very, very rare). According to contemporary documents, the last 16 words of internal macro rom contain code for factory testing the macro rom. My hope is that this code can be accessed on any 99xxx, which may provide a backdoor to get access to the macro rom as well (so that chips without the extension interface can be read out). Paul ti990_12.pdf

I think read-modify-write has a back story of its own, although somewhat related. There are three drivers for this: 1. In TI990/PDP11 style machines ("2-operand machines") the MOV instruction is typically in a group with arithmetic instructions (add, sub, and, or, etc.). The arithmetic instructions require the 2nd operand to be fetched, modified and written. To keep the microcode simple MOV followed the same set of steps, even though the fetch was redundant. 2. Core memory has destructive read (read erases the word) and requires write-back. Write could only set bits (and not clear them), so for writing a word it was first erased. As core memory dictated a read-write cycle anyway, making MOV a read-modify-write operation was not an additional cost. High performance machines used interleaved core memory banks, so that the next word could be read, whilst the previous one was being rewritten. 3. The TILINE bus could only operate on full words (unlike DEC's unibus that had signals to write a half-word). With the mini computer industry's thinking moving from word addressed machines to byte addressed machines around 1970 this was arguably an understandable mistake. As a result, byte instructions on a TI990 needed read before write in any case (and as under 1. above, byte instructions shared microcode with their word counterparts). All in all, in the early 70's designing machines with a fixed read-modify-write cycle was an understandable and common performance vs. cost trade off. Running much faster than 5MHz was hard. Yes, the individual TTL components can be clocked at 20+ MHz, but a more complicated system could not. Remember that these CPU's would draw several amp's of power, making the environment 'noisy'. For a signal to propagate and settle from a register latch, through a multiplexer, through a 74181 CPU, through a shifter, through a buffer and back to a register latch (the "datapath") would easily take 100ns. For the microinstruction to be decoded and control signals to settle would also take some 100ns; in a high end design the two things could be somewhat overlapped. Even a high end mini (like the 1973 PDP11/45) would have a cycle time of about 120ns. However, it seems that the original TI990 was intended as a machine with the programming convenience of a PDP11 but with the cost structure of a Nova and it used a relatively straightforward datapath design. As to the third point, that RAM and registers would be equally affected: yes, that is exactly what Daren Appelt's thinking was. There is one area where the equal speed argument was wrong, even in a 1973 context. Hardware registers can be dual or triple ported, i.e. one register could be read simultaneously with another being read or written (think 74170 or 74172 TTL). In a more complex (i.e expensive) data path design this can substantially reduce the number of micro-cycles needed to complete an instruction. This advantage cannot be achieved with the registers in core or semiconductor memory. The later 990/12 brings the registers into the CPU, acting as a cache, and exploits this opportunity (see attached paper). You may want to read about the PISC1 demo CPU (or even build one): it is very simple (22 TTL chips) and demonstrates all these design trade offs: http://www.bradrodriguez.com/papers/piscedu2.htm 990_12_article.pdf

I think I can answer this: Daren Appelt, the engineer that designed the TI960, TI980 and TI990 mini computers. First of all, think of the context of the time: most of the 16-bit mini's were designed in the late 60's using the then new TTL logic chips and core memory. The CPU's were split over 5-20 boards in a rack, and typically clocked at between 3 and 10 Mhz (the maximum speed that such a context would allow) leading to say a typlcal data path cycle time of 200-350 ns. The core memory had a typical cycle time of 800 to 1200 ns. Often the designs would use an analog delay line to measure out the access time of the core memory and stall the CPU as it waited for data from memory. The PDP-11, the Nova, the HP2100, the 316, etc. all shared these characteristics. Things like caches were too expensive to implement and did not appear on this class of computer until the mid/late 70's. In the 1960's having registers in memory was not unusual in mini computers, due to the cost of building registers from individual flip-flops: adding 16 registers of 16 bits each would have taken an entire board full of 7475 TTL chips. For example, the PDP-8 (which pre-dates the TTL era) had its registers in memory. Often only a few H/W registers existed, augmented by a bank of easily addressed memory locations (e.g. on the Nova, and the 6502 "page 0" is an echo of this.). Then came semiconductor memory in the early 70's (and Daren had some involvement in that within TI, holding a few patents etc.). This soon had the potential to build main memory with a cycle time of 250-500 ns, the same as the cycle time of the 5-20 board CPU's of the era. Now, suddenly, it became possible to have registers in memory and not pay a hefty price in performance. In this context, the maxim "memory is as fast as CPU registers" was true, and the 990 was proposed and designed in 1973. The novelty in the TI990 design was the idea of a workspace pointer and placing the register bank anywhere in memory. This was mostly useful in the context of the main production computer languages of the era, Cobol and Fortran. In these languages there was no recursion and each subroutine could be allocated its own block of registers. This was on optimisation over what happened on e.g. an IBM360, where each subroutine started with an instruction to save the registers to a block of memory, and ended with an instruction to reload them from that memory block. The TI990 was successful as a Cobol office machine, with some 100,000 units sold (incl. the desktop System 200/300/etc.). Daren was also the person who noticed that the TI990 CPU could fit on a single chip with the then current technology, and it came to be in 1975. This was also the undoing of the design: with the CPU shrunk from several boards in a rack to a single chip, adding CPU-based registers became almost zero cost and again had a speed advantage. The TI990 design hence had a very short window in computer history where it made sense. In the 80's several designs were tried that had multiple register banks integrated in the CPU, notably in the RISC world (e.g. the Sun Sparc). As time progressed, it turned out that having a smallish block of registers at the traditional instruction set level, an optimising compiler and microcode with advanced pipeline techniques (register renaming etc.) is the best route to performance for our current software base and it squeezed out all other designs.

That's a good point on interrupts. I think doing a tcp/ip stack for the Cortex is a feasible summer project. If you are interested in tcp/ip on the Geneve, I'm happy to share.

ElectricLab, on 06 Feb 2016 - 9:08 PM, said: That's interesting! In the past few weeks I've spent considerable time looking at the 1985-ish BSD tcp/ip stack as implemented for the PDP11 (2.9 BSD, 2.11 BSD and Ultrix11). The Ultrix version of the code looks the most interesting as it was adapted to run on a PDP11 without seperate I/D space (we would need a tms99105 for that). I've so far found that to support 5-10 simultaneous sockets one needs ~5KB of heap and ~30KB of buffer space. Not sure how much code is needed, my current estimate would be around 25KB. A Geneve can support that, as can a Cortex. Possibly it could work on a ti99/4a with a sams memory card. My idea is similar to yours: build a tcp/ip stack with a serial line driver (SLIP, CSLIP, PPP,etc.) and use a PC as a virtual ISP. If this was still the 90's it would work dialing in to the ISP over a modem. IP fragment reassembly is indeed one of the more involved bits of code, about 700 lines of C code. For a walkthrough of the code I can recommend "TCP/IP Illustrated, volume 2" by Stevens. According to a contemporary usenet post it really did work on a 1970's PDP11/40 in a two user Ultrix setup. A tms9995 has about the same processing power so should be fast enough (but back then we were over the moon with response times of several seconds).

As far as I understand the Geneve had software to run GPL code and emulate a a 99/4A to a large extent. Was this purely a GPL interpreter or did the Geneve include hardware emulation of GROM's?

You may have been thinking about this board: http://ruizendp.websites.xs4all.nl/IMAG0266.jpg It is a Cortex on a eurocard. It runs Cortex software, and my port of version 6 Unix. It supports the F18A. It does not have a joystick interface and is not primarily designed for gaming, so I always assumed that it was not interesting to this thread. However, it supports a good C compiler, so writing games for it should not be too difficult. I'm planning to do a version 2 of this board early in the next year. I'm also thinking about a 99105 system on a double eurocard (20x16cm), but that is something for 2017. No promises though. Paul

Many thanks, that was most helpful. I found the following two links also useful: http://www.computer-engineering.org/ps2protocol/ and https://www.cs.cmu.edu/~jmcm/info/key2.txt Taking it all together made me understand how the Geneve keyboard interface works. With hindsight it is a petty they included the shift register. Had they done a software 'bit banging' driver (which really would not have loaded the CPU very much) conversion of the Geneve to AT and PS/2, even USB keyboards would have been feasible by merely upgrading the driver. I might try doing a PS/2 keyboard interface on a breadboard, just to see if it works.

As far as I can tell from the schematics, the Geneve uses a software driver to interface with the XT keyboard: the hardware interface is nothing more than two output cru lines connected to pull-down transistors, an input cru line for data and the clock line connected to an interrupt. Does anybody have a copy of the MDOS keyboard driver code for this handy? I know MDOS650 is on whtech, but it is all ark'ed up and perhaps a forum member has plain text source code handy (and knows where to look for the keyboard driver code). Many thanks for help with this.

Hi Fabrice, Did you have time to do those little tests on the 99/5? I'd be really interested to know whether there is a prototype 9500 chip in there, or a plain 9995 as a placeholder... Many thanks in advance! Paul

Welcome back, and best wishes for your health!

AMI were a leading manufacturer of RAM chips in the 70's. In 1977 they entered into a second sourcing deal with TI and started producing some of the 9900 series. See here for the 1979 and 1985 databooks: http://bitsavers.informatik.uni-stuttgart.de/pdf/ami/_dataBooks/ I don't think AMI ever did a S9914 or a S9995. I saw a post in an old newsnet group that AMI S9900's were used in some TI99/4a's when its production was at full throttle (82/83). All my TI chips (other than those in my 99/4a) are from China and work just fine. I think they are nicely refurbished pulls, not new manufacture.

I found this thread: http://www.cpu-world.com/forum/viewtopic.php?p=150371 Apparently, a TMP99000 chip existed. Now take a good look at the last chip pictured in the above thread and then look again at that French TI990/10A cpu board: http://img11.hostingpics.net/pics/890850tm990_10a.jpg (the cpu is the ceramic chip on the left). See how the markings are very similar, with the triangle and the little square next to pin 1? I think I can even make out the letters "TMP" in the top line of the marking. Until I find other material saying something different, I'll go with the belief that TMP99000B chips powered the TI990/10A mini's. The question that remains is in which ways the TMP99000B was different from the TMS99105 and TMS99110. Another intriguing thing is why TI stuck with the "TMP" coding (i.e. engineering sample). The date code on the chips pictured in the CPU-World thread are for late '83, whereas the TMS99105 and TMS99110 chips were released in late '82, as was the 990/10A mini. Karl Guttag once mentioned that the 99000 worked "on first silicon"; perhaps the reason was that it just worked and TI never saw a reason to change the coding.

I think that is not so easy. Originally, CP/M was written in a higher level language ("PL/M"). This is '76-'77, CP/M 1.3. Only a small part was written in 8080 assembler. PL/M is a simple compiler, written in Fortran-66. It should not be too difficult to modify the PL/M compiler to output 9900 code (using Fortran on a PC). This can then be used to compile CP/M 1.3 to 9900 code, thus creating CP/M-9900. However, this is an early CP/M. For performance reasons later versions of CP/M were coded in 8080 assembler. It is these later versions of CP/M (let's say 2.2 from 1979 and beyond) that conquered the micro computing world back then. Porting this would be a major effort beyond hobby time budgets I think. Of the many thousands of CP/M software packages many were coded in assembler, often using 8080 instructions only to maximize compatibility. I think that only after 1980 did that change and of course by 1982 all CP/M software companies were shifting to PC-DOS and the 8086 en masse, often using semi-automatic conversion of 8080 CP/M code. Porting those CP/M apps (even if the source code would be available) would again be a major effort. A possible exception could all sorts of business applications that existed for CP/M, that were written in CBASIC. CBASIC compiled to an intermediate byte code that was then interpreted. Software makers liked this because it meant they could protect their source (unlike MS Basic at the time). Once CBASIC was ported to CP/M-9900 all those programs would run. As an aside: this CBASIC market disappeared once dBase got traction. However, not all is gloom. There already exists something that is very CP/M-9900 like (besides Geneve MDOS): an OS called "MDEX" written by John Walker (who later was the driving force behind Autodesk and AutoCAD). MDEX is a similar to CP/M and comes with a suite of application software: http://www.powertrancortex.com/documentation.html MDEX was originally written for a 9900 based S100 system: http://www.s100computers.com/Hardware%20Folder/Marinchip/9900%20CPU%20board/9900%20CPU.htm Sufficient source has survived to port MDEX to other 9900 systems: http://ruizendp.websites.xs4all.nl/screenshot.png

Thanks all! In the 990/10A documentation I was not sure wether "TMS99000" should be taken literally, or as meaning TMS99xxx (as it does on for instance on the cover of the 105/110 data book). Now that Ksarul has confirmed that a chip marked "TMS99000" really does exist I think it should be read litterally. I still hope to find confirmation on an actual 990/10A board though. Perhaps some day documentation for this chip will creep out of the woodwork.

Yes, the 990/10 was a TTL implementation. I think it was spread over 3 boards. It dates from 1975. The 990/10A was a cost reduced version dating from 1982. See here for details: http://www.textfiles.com/bitsavers/pdf/ti/990/990-10/2302633_990-10A_GenDescr_Sep82.pdf That manual actually has a picture of the board in it too (page 1-2), but again the chip markings are impossible to make out completely (but it seems to start with "99"). I think the 990/10 and the 9900 (used in the 990/4 and 990/5 minis) have a common ancestor in the prototype 990/9 dating back to 1973-74.

Apologies for being off topic, but this forum is where I know I can reach Fabrice. For some time I have been trying to find out which chip powered the TI990/10A mini. It certainly is a chip from the TMS99XXX series, but whether it is the 99110 or a version that was only used in TI minis (and if so probably numbered TMS99000) remains a mystery to me. Via a google image search I came across a forum thread from 5 years ago in which Fabrice participated: http://forum.system-cfg.com/viewtopic.php?f=10&t=2385 It has an image of a 990/10A system board (http://img11.hostingpics.net/pics/890850tm990_10a.jpg), but the image of the CPU chip is blurred: perhaps the markings have faded, perhaps it is just glare in the photo. Fabrice, are you familiar with the owner of that 990/10A system board and can he be reached to inspect the markings on the CPU chip?

Fabrice, Did you find the time to perform this test? I'd be very interested to hear confirmed that indeed a modified 9995 was created for the ti99/5.

With the memos in hand it should be easy to test which of the proposed changes were adopted (if any): - "Move of internal CRU bits from >1EE0 to >FEE0". From that base address CRU bits >5 through >F are user bits that can be freely (re)set and read back. This is the easiest test. - "Move internal RAM from >F000 to >FF00". As code in the internal RAM runs much faster than code in regular RAM this should be easy to test: run a 1,000,000 times loop (assembly) at both addresses and see which one is the fastest of the two. - "Lengthen /DBIN to match /MEMEN". This can be tested with putting the CPU in a tight loop ('LOOP JMP LOOP') and looking at /DBIN and /MEMEN with a logic analyser or two channel scope. If the negative flank of both signals occurs at the same time, the modification was made. Is it possible to perform those tests? I think the first two might have been done, the third seems more unlikely to me.