The other reason is that there was never really a simple way to do it. Even when I found out what CPU was actually inside (incredibly a 16-bit TMS 9995, an evolved version of the TMS 9900 in the Texas Instruments 99/4 and 99/4A), there was never a Tomy assembler, and other than its small amount of scratchpad RAM (256 bytes) the entirety of the Tutor's 16K of memory is tied up in the 9918ANL VDP video chip. That sort of architecture was typical for the family, but that also means that almost everything is stored in non-executable VDP RAM, so short of burning your own cartridge EPROMs there's no way to actually create and run a machine language program on the Tutor. The first flashcart for the Tutor didn't exist until around 2016 and it was still all ROM; furthermore, while the 99/4A could have its CPU-addressable RAM expanded (as well as the 99/8, its unreleased successor to which the Tomy Tutor is closely related), there wasn't ever a Tutor RAM expansion cartridge either until very recently. But now there are multiple homebrew options even for obscure home computers like this one, and at last I've got my own assembly language program finally running on it.
Texas Instruments' home computer series, including the famous TI 99/4A, was the logical consequence of TI's "one company, one computer architecture" policy. Indeed, the 1976 TMS 9900 CPU was basically their 16-bit 990 minicomputer architecture in an ungainly 64-pin DIP chip package and quite possibly (the only alternative is the General Instrument CP1600) the first single chip 16-bit microprocessor commercially available. It was fabbed in NMOS on a 4.5 micron process with about 8,000 transistors and initially topped out at a respectable 3MHz, though its pervasively microcoded architecture required sometimes large cycle counts per instruction. The 9918 video display processor in the original 99/4 evolved with a new bitmap mode to become the 9918A in the 99/4A, and, outlasting its originator, was one of the most common video chips of the early home computer era (Sord, MSX, CreatiVision/Dick Smith Wizzard, ColecoVision/Coleco ADAM, and many, many more). The original 99/4 was the winning design of three internal home system efforts in 1979, but was derided for its "calculator" keyboard, lack of lower case and a high MSRP; the upgraded 99/4A débuted in 1981 with an improved keyboard, better video, more expansion options and a lower price.
But TI was first and foremost in the chip business, and at the time was the largest semiconductor manufacturer on the planet. TI realized that the physical size of the CPU was harming its commercial viability — though TI's dubious management decisions were just as big a factor — and developed more conventional 40-pin versions, first as microcontrollers with on-board RAM and ROM, then with more typical 8-bit data buses. The most advanced of these was the TMS 9995 which had a few extra opcodes, a primitive pre-fetch facility, 256 bytes of on-chip RAM (we'll get to why this is notable when we discuss assembly language programming) and an internal decrementer for timing and event counting. It was noticeably faster than the 9900 and TI planned to implement it in its next generation of home computers, the low-end black and white 99/2 intended to compete against systems like the ZX-81 and Timex Sinclair 1000, and the high-end 99/8 with more memory, built-in peripherals and a larger keyboard.
Before that could happen, however, TI got deep in the weeds against their old nemesis Commodore under Jack Tramiel and ended up cancelling both the 99/2 and 99/8 in 1983 (exiting the home computer market completely in 1984), though not before there were spinoffs. It's not clear how Japanese toy manufacturer Tomy got involved but in 1982 Tomy adapted the in-development 99/8 architecture using the same 9995 CPU and 9918A VDP into their own home computer in Japan, manufactured by Matsushita (Panasonic) under contract. This computer was called the Tomy Pyuuta (ぴゅう太, also variously romanized as the Tomy Pyuta or Tomy Pyūta).
The Pyuuta was a reasonable success in Japan and Tomy decided to export it to other markets by translating the OS and G-BASIC to English. However, British importer Adam Imports sent this first prototype back, finding G-BASIC too limited to be commercially viable. As an upgrade TI must have provided (unwittingly or otherwise) the code for TI Extended BASIC to Tomy to port, since Tomy BASIC has similar to nearly identical tokens, memory usage and syntax. This updated version was imported more or less directly by Adam Imports as the Grandstand Tutor, and its dual-BASIC system was released as an add-on device for the Pyuuta and then built-in as well to the next generation system Tomy themselves intended to sell in the United States. This was the Tomy Tutor in 1983.
Like the Pyuuta, Tomy prominently touted the Tutor's 16-bit processor, but provided no way to directly access it. A couple years earlier the Tutor might have been a compelling system and one of the "real" kids on the box even wrote me a few years back to mention he rather enjoyed the games, but the video game crash was in full swing by then and Tomy's intentional toy aesthetic quickly became the kiss of death. No wonder Fred R. Rated was trying to get rid of them.
Unlike the TI 99/4A which used serially addressed "GROMs" for BASIC and much other software (which on top of that can't contain native code and are necessarily written in an interpreted bytecode called GPL), all of the Tutor ROMs and cartridges are directly connected to the bus and therefore tremendously faster. Although Tomy BASIC is also based on GPL, Tomy's GPL dialect is a stripped-down variant specialized for this task, and the program text is directly accessible like any other data in ROM. All of this, plus the 9995's prefetch, are why the Tutor's (and Pyuuta's) slightly slower clocked CPU runs so much more swiftly in practice than the 99/4A's.
Still, the "sandbox" concept ended up being unsuccessful because a number of Tomy BASIC commands don't bounds-check properly, and I remember very clearly crashing it multiple times one day trying to figure out how the COLOR keyword worked. (Alas, I was too young at the time to realize the significance of what I'd done.) Such bugs even facilitated a clever hack to enable sprites, though this hack unsurprisingly has notable limitations, and there was no way to directly access VDP registers for other features like high resolution or 40-column mode. BASIC was as much as you could do on a stock Tutor and other than a small user group in the Los Angeles area I didn't know anyone else who had one. It wasn't until several years later that I got the Tutor back, and by then I was knee-deep in Commodore programming, including handcoding 6502 machine language opcodes in the Epyx FastLoad monitor. The Tutor had been fun but I could do more with the Commodore 64 and the 128 we got after that.
It took five more years for the first true Tomy Tutor emulator, namely Ian Gledhill's 2003 TutorEm with functional 9995 and 9918A emulation; it was very slow, very buggy, incomplete and Windows-only, but it really did work and finally opened the floodgates. Later that year MESS added a driver written by Raphael Nabet in 0.70 that I helped beta-test and it is still part of modern MAME. While I have since updated TutorEm and made many fixes for my tape-enabled Tutti II emulator, we'll use MAME for debugging this entry because it is currently the only Tutor emulator that handles cartridge ROMs.
Tutti didn't emulate the CPU because I didn't know how its I/O worked and it would have been impossible to execute code in any performant fashion on the C64; even the relatively lightweight 6502-on-6502 emulator I maintain for the KIM-1 KIMplement emulator runs about 30 times slower or so than actual. I had done a little playing around with TMS9900 assembly on the 99/4A using the Editor/Assembler cartridge ("module") on a friend's machine, and I even had a basic 9900 programming book, so the 9995 wasn't really an alien architecture to me — which makes a good transition into talking about the CPU itself.
For the TI 99/4 in 1979 (and later the 99/4A), TI determined that designing a full 16-bit system around the 9900 would have required new chips for its exclusively 16-bit bus, making the effort too expensive for a home computer. TI solved this problem by devising two buses. The most directly connected 16-bit bus hosted the lowest level system ROM with the GPL interpreter plus 256 bytes of "scratchpad RAM" which could store eight complete sets of registers, composed of two 128-byte 8-bit static RAMs wired as low and high bytes (the 9900 is big-endian) which the CPU could access in parallel. SRAM was expensive, however, so the remainder of the machine's RAM was 16K of dynamic RAM given to the VDP, which has its own DRAM refresh circuitry. Unfortunately, although the VDP was on this 16-bit bus also, the VDP only supported byte accesses and ignores the lower half of the word, slowing DRAM reads further. Worse, everything else was behind the second "multiplexed" 8-bit bus, where a small circuit stalled out the CPU on reads until two 8-bit fetches could assemble the full 16 bits. While this meant less expensive 8-bit parts could be used, the cost reduction also cost a significant amount of performance.
The use of SRAM suggests that the 99/4 was originally intended to use a different chip that had RAM on-die, where refresh circuitry wouldn't have been needed, but cost and market considerations apparently prevailed. The intended CPU may have been something like the 1979 TMS9940 with an on-chip CRU, 2K of ROM, a decrementer and 128 bytes of SRAM, or the later TMS9985 with 8K of ROM and 256 bytes of scratchpad, though neither would have been ready in time for the 99/4. As mentioned earlier, after the disadvantages of the 9900's strict 16-bit data bus became more acute TI moved the multiplex circuitry on-chip and exposed only an 8-bit bus starting with the TMS9980 — but this also doubled access time to its external scratchpad RAM, condemning it to lower-performance applications like TI's Silent 700 teletypes. TI's first attempt was to turn the 9940 into the 9985 by adding the same multiplexer and bumping up the ROM and scratchpad RAM, which were both internal and thus avoided the bus problem. There was reportedly no market appetite for the 9985, so TI removed the ROM and reduced instruction latency further by using prefetch steps in the microcode which could be parallel with a preceding ALU operation. This is the 9995, released in 1981.
(A digression: how do you use the 9900 to implement a language like C? The simplest method is to just implement a stack, which is facilitated on the 990/9900 by its support for post-increment addressing. This is in fact the approach taken by the GCC port for the TMS9900, which treats the CPU more or less like a modern CPU with a link register [usually R11], defines an ABI for arguments and volatile/non-volatile registers, and reserves one of the registers as the stack pointer, in this case R10. R10 is a 16-bit register like all the others, so the stack can be as large as the addressing space, a significant improvement over C-hostile architectures like the 6502. Another way is to go "full Berkeley" and treat the WP as a means to implement register windows, a la SPARC: the WP can be moved to any word-aligned address, so a caller can move the WP down a few notches, set up its arguments, call the routine, capture the return value and set it back. However, the 9995 — and for that matter the stock 99/4(A) — doesn't have CPU-addressable RAM other than the scratchpad, so in the base configuration neither system would have much capacity for function calls no matter how they were implemented. The Tomy BIOS gets around this by simply moving the WP or individual registers around by hand, which is space efficient, but also makes some individual routines or subsections more difficult to use because there is no standard calling convention.)
For our purposes, although the 9995 has a few extra instructions, we can treat it in practical terms as a faster 9900. The main difference at the assembly level is where the scratchpad RAM lives: since it's external to the 9900, its location is wherever it gets decoded (e.g., in the $8000 range in the 99/4A), but in the 9995 the internal RAM always occupies $f000-$f0fb (for compatibility with the 9900 the last four bytes are seen at $fffc to $ffff and serve as the NMI vector). The 9995 also has an internal decrementer at $fffa but we won't need to deal with that right now for this particular project. The only other concern is that the prefetch in the 9995 will affect self-modifying code if it changes the very next instruction which our example doesn't do either. Otherwise, programming it is almost completely the same.
The Tomy BIOS obviously has support routines for displaying text and reading the keyboard, but we're not going to use them for several reasons: first, I'm not particularly conversant in them, second, we can probably do it faster and more flexibly ourselves, third, it's good education, and fourth, they kind of suck. For input, while we can't do anything about the Tutor's mushy Chiclets or its single SHIFT key, we certainly can improve upon the BIOS' terrible key rollover. Additionally, the Tutor's default character set is inconveniently organized for modern applications: wile you can apparently use the SCELL() (the Tomy equivalent of TI CALL HCHAR) command to store characters by their ASCII value directly into VDP screen memory, this is in fact an artifact of BASIC and not actually how the glyphs are laid out in VDP RAM. We would like to organize our character set to be exactly the same as true ASCII so that no translation is needed, as well as support the 9918A's 40 column text mode which the Tutor BIOS never did. To do all of these things, we'll devise our own library.
For the cross-assembler, we'll use the AS macroassembler, which is multi-architecture, cross-platform, open-source and has specific support for the 9995. It builds just fine on any modern OS, including Linux and macOS. The macroassembler will create an intermediate object which we then link with an included tool into the final executable.
The Tomy machines place their VDP ports at $e000 and $e002 in the 9995's regular addressing space, while the keyboard and joy controllers (which share keyboard lines) are on the CRU bus at $ec00 through $ec70 with each group of eight lines separated by 16. The "little" 8K and "medium" 16K cartridges both are mapped to $8000-$bfff, where the Tutor expects to see two $55 bytes at $8000. If these two $55 bytes are present, the CARTRIDGE option is enabled in the menu, which triggers a jump to $8002. (There are other ways to signal its presence, but this method is the simplest and the one used by the majority of official Tomy cartridges.) So we'll start off with this:
padding off
; vdp ports on the tutor
vdpwd equ 0e000h
vdpwr equ 0e002h
; CRU address for reading the keyboard
keycru equ 0ec00h
org 08000h
; cartridge signature word
word 05555h
The leading zeroes for these particular 16-bit values are a required quirk of AS. Since we're using all our own routines, we don't want any interference from the BIOS, so we'll turn off all interrupts by setting the interrupt mask to zero and load the WP with the lowest address of the 9995's built-in scratchpad RAM. (We'll have more to say about interrupts later.)
limi 0
lwpi 0f000h ; don't even trust the Tomy OS here
The Tomy Tutor BIOS gives us literally nothing to work with anyway: before the cartridge is started, the registers are set to default values and the entire VDP RAM is cleared. That means there's no screen matrix nor a character set, and we'll have to write them to VDP RAM ourselves. (The expectation is that you'd call the BIOS' own utility routines to set those up, and that's indeed what regular Tomy cartridges do, but we're not going to do that here.) To make working with the VDP a bit more convenient, we'll construct a little utility subroutine.
vdpr ; write to VDP registers
; MSB of r0: command nybble + value (8r = register,
; 4x = MSB VDP RAM for write, 0x = for read)
; LSB of r0: new register value (xx) or LSB of VDP RAM address
; the swapping around gives enough time for the VDP to operate,
; and we have no IRQs on, so nothing will interfere
swpb r0
movb r0, @vdpwr
swpb r0
movb r0, @vdpwr
b *r11
Recall that the 9918A only has an eight-bit data bus, so we must communicate with it through byte-sized operations. This subroutine takes a single 16-bit argument in r0 that either encodes an absolute VDP RAM address for reading or writing, or encodes one of the eight VDP registers and the byte to store in it. (Because of the way these addresses are represented, i.e., either $4xxx to write or $0xxx to read, a "super 9918A" would need to implement some sort of bankswitching register to handle more than 16K. The only other supported RAM size for the 9918A is 4K.) The LSB goes out on the bus first and the 9995 is big-endian, so for each byte we swap them before sending it to the 9918A's control register, exiting back to the caller through r11 as our link register. As a happy convenience the swap operation takes just long enough for the 9918A to handle the bus transaction and be ready for the next. With that, we can set the following:
; register 0 turn off bitmap and external video
li r0,08000h
bl @vdpr
; register 1
; - 16K mode
; screen off
; no IRQs
; no 40 column text mode (except if we asked for it?)
; no multicolour
; no bit 5
; normal 8x8 sprites
; normal sized sprites
li r0,08180h
bl @vdpr
; register 2: put screen table at 0800h
li r0,08202h
bl @vdpr
; register 3: put colour table at 0c00h
li r0,08330h
bl @vdpr
; register 4: put character set at 0000h
li r0,08400h
bl @vdpr
; register 5: put sprite attributes at 0000h
li r0,08500h
bl @vdpr
; register 6: put sprite pattern table at 1000h
li r0,08602h
bl @vdpr
; register 7: white text on green background
; (the only colours available for 40-column)
li r0,087f2h
bl @vdpr
The locations for the screen table, colour table, character set, sprites and so forth are encoded as multiples of particular alignments. For our character set, we'll reorganize the Tutti one to match ASCII order (I told you we'd be coming back to that), add that to our binary and copy it in. We're only using positions 32-127, so there is plenty of space for expansion if we want to add graphics characters or an alternate font weight (for this purpose I just added a reverse/inverse set). Once we set the VDP memory address, we can just keep sending data to the data port as the VDP's address internally autoincrements with each write or read.
; load our font to >0000
li r0,04000h
bl @vdpr
li r1,fontt
lup movb *r1+,@vdpwd
ci r1,fontt+00800h
jne lup
We go on to clear our screen in the same way (by storing the appropriate number of space characters starting from the top left of screen memory), then set the colour matrix (if 32 columns), print our character set and display a welcome message in similar fashion.
Next, we want to accept keyboard input and echo it to the user. Despite the rubbery nature of the keycaps themselves and their non-standard layout, the keyboard matrix proper is actually pretty good quality: each key independently sets a particular bit in the matrix and some quick tests show there's little to no shorting or ghosting. Reading it is a simple matter of requesting every key bit in groups of eight from the CRU at their specific addresses. However, like any keyboard handler, we'll need to properly debounce the keys, and this is where the Tomy BIOS is particularly bad: if you type too quickly and multiple keys are down as you transition from one keys to the next, the keyscan routine will fail to make a match and the new key will be dropped. This makes the Tutor's already somewhat mushy keyboard even worse to type on, an absolutely needless situation since the Tomy keyboard has all the hardware requirements to implement N-key rollover and is only let down by its software. The solution is to track each individual key bit using the debounce matrix to filter out key bits we already know were previously down. This is made a bit easier by the fact there's only one modifier key to watch (i.e., SHIFT), but the principles are the same.
; scan keyboard
; needs 16 bytes of scratchpad RAM
keyzone equ 0f020h
keezc clr r0 ; clear debounce
mov r0,@keyzone+8
mov r0,@keyzone+10
mov r0,@keyzone+12
mov r0,@keyzone+14
keez clr r9 ; clear test
li r2,keyzone
li r12,keycru-16
keezl ai r12,00010h
clr r0
stcr r0,8
movb r0,*r2+
socb r0,r9 ; bitwise or
ci r2,keyzone+8
jne keezl
ci r9,0
jeq keezc ; clear debounce if nothing pressed
The "keyzone" block is our current matrix followed by the debounce matrix we'll use to filter it. This section can be entered either from keezc to blank the debounce matrix, falling through to keez to read it. Reading from the CRU requires placing the CRU address (a parallel addressing space) into R12 and asking for the needed number of bits. We fetch in groups of eight bits which are in eight locations stored 16 CRU bytes apart, keeping a running logical-OR (which the 9900/9995 atypically calls soc/socb "Set Ones Corresponding" for non-immediate arguments). If the value of the running logical-OR was zero, then no key was pressed, we branch back to clear the debounce, and go scan the matrix again.
The simplest case is where the current state of the matrix exactly equals the last time (modulo the state of the SHIFT key). This can be checked for by exclusive-ORing with the debounce matrix, masking off the SHIFT bit. We then logical-OR all the resulting bits together and if it's zero again, we go back to scanning — but leave the debounce matrix alone.
mov @keyzone,r2
mov @keyzone+2,r3
mov @keyzone+4,r4
mov @keyzone+6,r5
xor @keyzone+8,r2 ; xor current bits with last set
xor @keyzone+10,r3
xor @keyzone+12,r4
; clear shift bit (prevent "eeking" characters when releasing)
andi r5,0fbffh
xor @keyzone+14,r5
; if exactly equal (i.e., all zeroes), go back
soc r3,r2
soc r4,r2
soc r5,r2
jeq keez ; don't clear debounce
This is the block of code we'd use to set up key repeat, which as currently written this routine doesn't support yet (an exercise for the future). Otherwise, we need to filter the debounce to remove any keys that are now up, filter the new matrix to remove any keys already present in the debounce (which may give us another zero matrix again, but our keyscan table doesn't match an all zeroes matrix, so it's "fine"), and update the debounce matrix with the new bits that are down while clearing the SHIFT flag. This heavily uses the oddball szc instruction, which is an inverted logical-AND (though, like soc and ori, there is a regular immediate andi that is not inverted, a curious non-orthogonality in the instruction set). I won't show every store here but I'll give the overall flavour — there's probably a more efficient way to do it than I've done, but this is also pretty easy to follow conceptually:
; remove any bits in the debounce that aren't set currently
mov @keyzone,r0
inv r0
szc r0,@keyzone+8 ; inverted and
mov @keyzone+2,r0
inv r0
szc r0,@keyzone+10
[...]
; remove any bits in the new keyscan that were still set in debounce
; if we end up with a cleared keyscan, it doesn't matter since we
; won't be able to decode it anyway
mov @keyzone,r0
szc @keyzone+8,r0 ; inverted and
mov r0,@keyzone
mov @keyzone+2,r0
szc @keyzone+10,r0
mov r0,@keyzone+2
[...]
; update debounce, clearing shift
; add any new bits to debounce so they get masked off too
[...]
mov @keyzone+4,r0
soc @keyzone+12,r0
mov r0,@keyzone+12
mov @keyzone+6,r0
soc @keyzone+14,r0
andi r0,0fbffh
mov r0,@keyzone+14
Now with a clean set of keybits, we need to match them against a table. I organized a table of four words representing the eight matrix bytes in ASCII order so once you've found a matching set, the index into the table is the result. This table is stored at label keytab and looks like this:
[...]
; symbols and numbers, 32-64
; SPACE
word 00000h, 00000h, 00000h, 08000h
; !
word 00100h, 00000h, 00000h, 00400h
; "
word 00200h, 00000h, 00000h, 00400h
; #
word 00001h, 00000h, 00000h, 00400h
; $
word 00002h, 00000h, 00000h, 00400h
[...]
The Tutor does not have CONTROL or ALT keys, just SHIFT, nor does it have a backspace or delete. This lets us redefine our special keys (the cursor keys, MON and MOD) to generate indices in the control character range. Our table turns MOD into ^C (consistent with its use in Tomy BASIC as break), LEFT/UP/DOWN/RIGHT as ^H ^K ^M/CR ^L, RT (RETURN) as ^J/LF, and MOD as ^[/ESC. To round out other common ASCII points the default keyboard doesn't generate, ^I/TAB is encoded as SHIFT-SPACE, backtick as SHIFT-UP, tilde as SHIFT-DOWN and ^?/DEL as SHIFT-LEFT. The pipe and backslash characters remain represented by flat and degree/handaku, which have the same ASCII value. The only key our matrix table does not handle is LOCK, which would be word 00000h, 00000h, 00000h, 00200h. I'd probably implement this as a conventional CAPS LOCK defaulting to up but we'll exclude that from the logic for now. Anything not matched in the table gets a result of 0.
; decode key
; each table entry corresponds to CRUs >EC00-EC70
; use a custom table to generate a standard ASCII value
clr r6
li r1,keytab
dekodl mov *r1+,r2
mov *r1+,r3
mov *r1+,r4
mov *r1+,r5
ci r2,0ffffh ; no key here
jeq dekodn
; if the key matrix is an exact match, should be all zeroes
xor @keyzone,r2
xor @keyzone+2,r3
xor @keyzone+4,r4
xor @keyzone+6,r5
soc r3,r2
soc r4,r2
soc r5,r2
jeq dekodo
dekodn inc r6
ci r6,128
jne dekodl
b @keez
dekodo mov r6,r0 ; got a good key
Like the debounce comparator, this code XORs the current matrix value against the current table entry; if it gets all zeroes, we have a match. At the end the resulting character code is in R6 and R0. Parenthetically, the 9900 has a inct instruction that increments by two instead of just one with regular inc, useful for skipping words (you can also use an instruction like c *r1+,*r1+ to increment by four in one word).
Because we left the VDP memory pointer at the end of our "hello world" blurb, to print the character to the screen we could simply do swpb r0 to get it in the upper byte followed by movb r0,@vdpwd. This doesn't scroll at the end as there's no bounds-checking, and remember the Tutor doesn't have a backspace (control characters are simply printed as blanks anyway), but it's really really fast. However, we also want to display a cursor for we'll use our reversed space character, so we'll keep a rolling screen pointer in R7. We'll additionally have RT clear the screen and as a convenience use MON to bail out to the Tomy title.
; check for mon - implemented as escape
ci r0,001bh
jeq bye
; check for RT - implemented as line feed
ci r0,000ah
jne putc
bl @clrscr
b @cursor
; otherwise print character using a cursor
; overwrite previous cursor character with new character
putc swpb r7
movb r7, @vdpwr
swpb r7
movb r7, @vdpwr
swpb r0
; MAME will actually allow a mov here but not the real machine
movb r0, @vdpwd
inc r7
; and print cursor
cursor li r0,0a000h
movb r0, @vdpwd
b @keez
The simplest way to go back to the title screen is to call the Tutor's reset vector, but paradoxically the 9900's built-in rset instruction is not what we want for this. There are a handful of TI-990 holdovers called external instructions which were used for special context switching operations, such as lrex to jump into front panel code. However, on the 9900/9995, most of the instructions with the possible exception of idle do nothing useful and in some cases could be potentially harmful depending on what's listening on the bus.
Instead, we'll use the low memory vectors. 9900 vectors consist of a pair of WP and PC words, with interrupt vectors starting at $0000. When an interrupt is triggered, or a vector is branched to using the blwp instruction, the WP and PC are loaded in order from those words (instantly saving the previous code's registers, assuming there is no conflict) and the previous values of WP, PC and ST are placed in the new R13, R14 and R15 respectively. The rtwp instruction then reverses everything using those registers and thus returns to the prior execution context. Theoretically the TMS9900 can support up to 16 levels of interrupt, starting at $0000 with level 0 for resets through $003c for level 15, though the 99/4 and 99/4A just wire everything to interrupt level 1. In the 9900 memory map these vectors are followed by XOP vectors for up to 16 software-defined opcodes via the xop family of instructions.
However, the 9995 only implements seven distinct interrupt levels, two of which are actually software interrupts (and one of those doesn't even work properly according to the manual errata). The highest level is level 0, connected to the reset pin, followed by the mid interrupt used for software opcodes, then NMIs, and then four numbered interrupts consisting of an external interrupt (1) on the INT1 pin, a not-reliably-functional arithmetic overflow interrupt (2), the on-chip decrementer (3) and another external interrupt (4) on INT2. These have their own vectors except for the MID interrupt and interrupt level 2 which share the same vector, and other than the NMI vector at $fffc all the rest come from low memory as well.
In this particular regard, the Tutor is no different from the 99/4A: a blwp 0 will jump into the reset vector at $0000, just as if you'd powered the machine on and allowing you to go back to the menu. While the Tutor also uses the same reset vector values for levels 1 and 2, level 3 (the decrementer) runs normally to service its regular tasks and the level 4 (external INT2 triggered) interrupt is used for triggering on tape reads. On the other hand, the Tutor uses the entire XOP vector range as part of a jump table, so it isn't possible to use any XOP instructions on the Tutor with the standard ROMs (the 99/4A at least has a couple useful values there). Anyway, all this is to say that a simple blwp 0 will be sufficient.
That's pretty much it, and we're ready to assemble our first draft. I'll get to the code in a minute, but let's test it in MAME with mame tutor -skip_gameinfo -cart tello.rom. Our character set and welcome message appear beautifully though typing is a bit ... messy.
I used minipro to dump the current contents of the multicart ROM and wrote up a little Perl script to do an inplace overwrite on the resulting file with our new binaries. We generate two ROM files called tello.rom (32 column) and tello40.rom (40 column), which we splice in at locations 0x70000 and 0x74000 and then burn it to flash.
% make burn perl splice /home/censored/tutor.bin 0x70000 tello.rom 0x2000 successfully replaced 8192 bytes at offset 458752 in /home/censored/tutor.bin with tello.rom perl splice /home/censored/tutor.bin 0x74000 tello40.rom 0x2000 successfully replaced 8192 bytes at offset 475136 in /home/censored/tutor.bin with tello40.rom minipro -p SST39SF040 -z Found TL866II+ 04.2.131 (0x283) Pin test passed. minipro -p SST39SF040 -w /home/censored/tutor.bin Found TL866II+ 04.2.131 (0x283) Chip ID OK: 0xBFB7 Erasing... 0.40Sec OK Writing Code... 30.12Sec OK Reading Code... 4.30Sec OK Verification OK
The multicart DIP settings for the 32-column version are (1=on) 00011 if you use those addresses. The first time I tried, the hello message appeared but typing generated no output. This was because I had a mov r0,@vdpwd instead of movb r0,@vdpwd; MAME will accept either instruction but not a real Tutor. With that corrected, we're in business!
Now, what things could you do with better keyboard support, true ASCII and fast character display? Well, obviously this whole proof of concept is the start of doing something more practical with the Tutor. I'll answer that question in a couple months once all the parts arrive. The first order of business will be installing a PLCC adapter in the multicart so I don't have to pull the flash chip out repeatedly for testing.
As for the 9995, in the end it was only ever implemented in three systems: the Tutor/Pyuuta family, a PEB upgrade called the Myarc Geneve 9640 which was basically a new TI-compatible computer on a card, and the Powertran Cortex, a home and business computer first built at TI in the United Kingdom that never got released due to internal squabbles. Instead, its plans were published in the Electronics Today International magazine and a company called Powertran Cybernetics sold kits and fully assembled machines. The Cortex ran at a full 3MHz, had 64K of chip RAM (with a memory mapper supporting up to 1MB) and used a 16K PAL equivalent 9928/29 VDP for graphics, though the more advanced Yamaha/Maplin V9938 could also be substituted with up to 128K of VRAM. Floppy, serial and DMA were all supported along with a built-in BASIC and multiple operating system options, even a small v6 UNIX port called LSX. Although popular with enthusiasts, it was an obscure system then and now, and relatively few examples remain in operation.
While the 9995 was a much more tractable chip than its ancestors, the reliance of the 9900 series on RAM was what eventually stunted its technological evolution. In the days when it was taped out, CPU die space was expensive, so shifting register space onto cheaper RAM which often ran at a similar speed was a logical alternative. Indeed, tricks like 6502/6800 zero page are the same basic idea, using a special expanse of memory with faster access and special addressing as if it were CPU registers itself. As CPUs became substantially faster than memory, however, this architectural quirk became more of a liability and contemporary 16-bit CPUs like the Motorola 68000 and the Intel 8086 and 80286 eclipsed it. A chip like the 6502 only got away with it for as long as it did because it was incredibly cheap and incredibly common and even today still sells in quantity, neither advantage being one the 9900 or 9995 ever possessed. Today, modern CPUs have comparatively massive register files and caches as proof that the 9900 idea was a dead end. After the 99000 family, an upgraded 9900 with segmented memory only used in TI's last range of minicomputers, TI abandoned further development of the architecture in 1983 for the TMS320 DSP series and the exceptionally swift TMS32010, a much more popular (and, especially for a DSP, more conventional) processor.
The source code for our demonstration project along with a Makefile, the character set binaries and the keyscan table are available on Github under a 3-clause BSD license.
No comments:
Post a Comment
Comments are subject to moderation. Be nice.