pnr

I was querying a correspondent about the MMU on the Ten-X 7-XP board and the following is what he reported wrt the 99105 Would that correspondent be Daren Appelt by any chance? The TMS99105 had some undocumented macro space (32 bytes) inside the processor. This was 0 wait state memory and I utilized this to implement a variant of the LMF opcode to load the MMU. That might refer to the macro space workspace, 16 registers = 32 bytes. This was located at macro memory address 0. It is the bottom-right square on the die shot here: https://en.wikipedia.org/wiki/Texas_Instruments_TMS9900#/media/File:TI_TMS99105A_die.JPG What Ten-X docs I have are here: ftp://www.dragonsweb.org/pub/ti/docs/Ten-X/ That is interesting; looking at it now. He also tells me the 7-XP stuff was later sold to a German company, but doesn't recall which one. Anyone has any idea I sure would like to know. It could also refer to Kienzle. Kienzle was one of the many German mini-computer companies focussing on business computers for mid-sized businesses. They used the 9900 CPU in the late 70's and the 99000 family in their later models. Like much of the New England computer scene they did not make it through the 80's and ended up being acquired by industrial conglomerate Mannesman. In 1991 it was sold on to Digital Equipment Corp. For German speakers (readers) the full story is here. 990 microcode is of course a different animal than 99K macrocode assembly, but if your aim is to implement the rest of the /12 instruction set, it would be useful to know. I'll post anything I find here. Thanks. It would be interesting. I did a full analysis & commentary on the 99110 ROM a while back.

The source code for TIC appears to be partial - it looks like a few files did not get uploaded. Alan was kind enough to share the sources to TIC with me some 6 years ago, when I first got started on the Unix on 9900 port. These files have been on WHTech ever since: http://ftp.whtech.com/programming/TIC/ That zip file contains a full set of sources and are verified to build. Dave Pitt's assembler can be used as an alternative to TASM (for TIC output) - see the README.txt for details. (The Unix port is long since completed, but I used a port of the PDP11 Unix compiler in the end).

Isn't that AmigaDOS? Alan said that he was developing on an Amiga after the TI and Geneve.

If you have some time some day, a photo of his PHP1300-clone PCB would be nice. Probably the same as the original chips, but still. Great for the HX5102 schematic to have survived. Did the PHP1300 schematic survive as well? I mainly checked the FF and the LS251 inputs; would be cool to have a complete schematic.

If I had to take a wild guess, I'd say that Michael did ROM changes to make use of the 32KB RAM chip in his design (vs 4KB). This would have allowed more efficient disk access and more files being open at the same time (I think the TI version could only have 3 files open at once, or something like that). For the GAL chips, it would seem to me that they just implement the same functionality as is in the schematic. Today you would implement it with just a microcontroller, I would guess.

See here: https://www.crowdsupply.com/radiona/ulx3s

I think the PHP1300 also has the OSO chip?

Perhaps adding a USB bus master is making this too big a project. Just going to USB serial and letting the PC do all the devices is arguably the most practical. At first glance, I think that such a project could work with just the TinyFPGA board, two 74ls125 chips, two 6 element resistor arrays, 6 regular resistors, a strip of solderless breadboard and a handful of breadboard wires. Not for me, but perhaps a nice little project for the Festive Season for someone who actually owns vintage HexBus equipment?

Come to think of it, the Hexbus code for the TI-99/2 is tiny and would fit many times over on a very small FPGA board. Combining a board like this https://www.crowdsupply.com/tinyfpga/tinyfpga-bx with a few 3v-5v level shifters would make for a simple Hexbus<->USB serial interface. This could turn a PC into a Hexbus device (or several of them) and be of real use to CC40 / TI74 users as well as for the few people who have vintage TI-99/.. hardware with a Hexbus interface. I guess it would be the modern equivalent of the old parallel port interface, here: and here: http://ftp.whtech.com/hexbus_cc40_ti74/PC Interface (PCIF) manual.pdf

Thanks! I'm not really set up to do a video. However, I have posted my work-in-progress code for your review: the hexbus module on the FPGA and the device emulation in micro-python. For the benefit of @FarmerPotato the "Hexbus core" you asked for is here (just some 70 lines inside of the Hexbus module). I think I have solved my timing issue. It may perhaps also solve the issues that @mizapf saw with the TI-99/2 on MAME. The code in the TI-99/2 ROM to read bytes from the device is this: // read two nibbles 5e1a 0206 li r6, >0002 // two nibbles 5e1c 0002 5e1e 0207 li r7, >8000 // timeout ~300ms 5e20 8000 5e22 0607 dec r7 5e24 13f5 jeq >5e10 // -> timeout 5e26 1f04 tb 4 // hsk_in low? 5e28 13fc jeq >5e22 // -> no 5e2a 1f06 tb 6 // bit 6 high ? 5e2c 16f8 jne >5e1e // -> no, more time allowed 5e2e 1e04 sbz 4 // set hsk_out to 0 5e30 3508 stcr r8, r4 // load nibble 5e32 0b48 src r8, 4 // shift for next nibble 5e34 1d04 sbo 4 // set hsk_out to 1 5e36 1f04 tb 4 // hsk_in back high? 5e38 1302 jeq >5e3e // -> yes 5e3a 1f06 tb 6 // bit 6 high ? 5e3c 16fc jne >5e36 // -> no, keep waiting 5e3e 0606 dec r6 // all nibbles done? 5e40 16ee jne >5e1e // -> no 5e42 06c8 swpb r8 // put byte in R8H 5e44 045b rt As you will see, it tests bit 6 of the CRU byte, which the documentation says is not used. My conclusion is that this line is connected to the (inverted) HSK_LATCH. This avoids the TI missing a nibble when the CPU is delayed by the VDP. It also allows the "stretching out" of the last command nibble until the device is ready to respond (a trick that the hexbus<->serial bridge on the FPGA now uses). Maybe the original Hexbus drive is also using this mechanism.

My experimental setup can now save and load a program to/from the SD card using the hexbus bridge. Listing a program to the card also works. I can print data records to a file, but reading them back is a little unreliable due to a timing issue in the design (it relies on the micro-controller responding quickly). Files are stored in a directory on the card, which has standard FAT formatting.

Hi kl99, many thanks for all those links. These have been very helpful! I currently have an experimental setup, where the (FPGA) HexBus interface of the TI-99/2 talks to a bridge module that converts the HexBus traffic to messages over a fast serial link. I can test this with a Verilog simulator and see the actual signals going over the bus. This is how I read the low level communications. The serial link talks to a micro-controller (the on-board ESP32 wifi module running micropython) that pretends to be one or more devices. This is now mostly working, and messages are flowing back and forth between the TI-99/2 and the micro-controller. No actual emulated devices as yet, just code to show the messages and send correct responses. Yes. In my above setup this doesn't matter much - the device number is just a number. As far as I can tell, the TI-99/2 does not do any interpretation on the device number and just sends the HexBus commands. If a device cannot handle a certain command the TI-99/2 finds out because of the device error response. That is good to have, many thanks. However, if it takes reverse engineering of a ROM, I think that time would be best spent working with the TI-99/2 ROM. For now I'm trying to avoid any disassembly. The TI-99/8 HexBus source that you highlighted is already a full example of what is expected. Note that the TI-99/2 does not use a Hexbus chip: its Hexbus interface can essentially be built from a '259 + '151 as an 8-bit CRU register, a flip-flop and a a few open collector drivers (e.g. '367).

A bit of experimentation has helped me further along: When doing a save the 99/2 first sends a SAVE INQUIRE command. If the device responds with status >0D ("command not supported"), the 99/2 will fall back to do a file open (OUTPUT,VARIABLE,SEQUENTIAL,INTERNAL) and write records with the program in tokenized format, using the regular and documented Hexbus commands. If the device responds with status >00 ("ok") to SAVE INQUIRE, a SAVE command follows. Here there is a short (~10 ms) wait after the command header and then it appears to send the (tokenised) program in one long transmission. Responding with status >00 ("ok") appears to be sufficient. Come to think of it, there are no checksums in the Hexbus protocol. I guess Hexbus was sufficiently reliable not to need check sums. For the OLD statement, the 99/2 first tries the Hexbus LOAD command (>19), sending just the file name with the command. It then expects the device to send the program as one long response transmission. If the status response to the LOAD command is >0D ("not supported"), OLD also falls back to using the documented OPEN/READ/CLOSE HexBus commands.

I'm making some progress with adding Hexbus support to the TI-99/2 project - basically got the low level protocol working now. Next is the high level protocol, I mean the commands and replies that travel over the Hexbus. Most of them appear to be documented here: http://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus Specifications.pdf I have the LIST "HEXBUS.10" statement working. In effect it translates into an OPEN, WRITE(s) and CLOSE sequence on the Hexbus, and these commands are documented. However, SAVE HEXBUS.10.A translates into Hexbus command >1B (SAVE INQUIRE) followed by >1A (SAVE). These commands appear to be undocumented, so I'm not quite sure what a device should reply to those commands. Does anybody know?

Many thanks for doing that! Without it, the project would have been impossible. Loved your dumping video's on Youtube.

When you get around to looking at that, let me know. I may try to implement the HEXBUS part of the I/O chip in the 99/2 in Verilog at that time.

Yup, I wrote that code. The HDMI interface is a derivative of the example at fpga4fun.com, and the keyboard code is a derivative of Grant Searle's work. The rest is all new. I'm not into gaming (also not BITD) and I'm not even sure what a Collectorvision Phoenix is. As to the TI99/4A, speccery has had that running on an FPGA for quite a while. I believe there is also a port to the Mister system of that code. Does that help with your question?

I understand where you are coming from. Doing FPGA code is more like programming than it is like soldering a PCB. However, it is an excellent way to prototype a system and making sure it all works as expected before committing to a PCB. That is also why I did the 99/2: I needed a simple system to put the CPU code through its paces. Now that I know that it works I can move on to prototyping my next 99xx Unix system (as a follow-on to the mini-Cortex). As you are aware, I've done a 9902 in both VHDL and Verilog that you could use as a building block. I think speccery may have a 9901 available. I believe (but maybe I'm mistaken) that adding HEXBUS to a working computer is a minimal amount of hardware / HDL code; maybe 100-200 lines of code -- not much of a "core". Most of the work is in the driver software on both ends.

Hi Guillaume, Excellent questions! The 99/2 does not have disk directly -- it has a HEXBUS interface. The current Verilog does not contain the HEXBUS circuit, but that would not be all that hard to add. It is just a few CRU bits and latches. I have not looked at the details of this, but I think MAME has it working so mizapf has probably figured out these details. The harder bit would be creating a HEXBUS drive, as the drive would need its own processor. One way to do it would be to use the ESP32 card on the Radiona board. The ESP32 also has access to the SD card and already has FAT file system code. Adding some HEXBUS code to that would be doable, I think. Are you interested in that project? I'm not aware of joysticks for the 99/2. Did they exist? Same for speech support: did that exist for the 99/2?

Yes, the ECP5 is much bigger. My board has the small 12F version of the series on it, and that is already much bigger than the ICE40. Hopefully this material will help you in getting the new Geneve done ?

Announcing a TI-99/2 on a FPGA. It uses an open source FPGA board, the Radiona ULX3S: The board has a GPDI connector that can be used to send video to an HDMI display and this is used by the TI-99/2 implementation. The USB2 connector is used to hook up a PS/2 keyboard. The TI-99/2 uses only a fraction of the board's capacity. It could easily hold a TI-99/4A, or a Geneve or TI-99/8. In fact, it can run a Minimig Amiga or a simple Linux. Unfortunately, the board is currently sold out, but a new production run is planned: https://www.crowdsupply.com/radiona/ulx3s The TI-99/2 code is written in Verilog and can be synthesised using the open source Yosys/NextPNR/Trellis tool chain. The full source code is here: https://gitlab.com/pnru/ti99/tree/master/ti99_2 Output is to the GDPI port and sends an HDMI compatible video stream in VGA resolution (the 256x192 pixel output area is doubled both horizontally and vertically, so each TI-99/2 pixel is 4 VGA pixels). Input is through a PS/2 keyboard (or a PS/2 capable USB keyboard) hooked up to the USB2 port. Cassette I/O and the HEXBUS interface are not implemented. The implementation is of the 32KB ROM version of TI-99/2. The system has been set up with 32KB RAM. All code is plain Verilog and should be easy to port to other FPGA boards. A standard (black&white) VGA signal is generated internally, so it should not be too difficult to run it on a board with a VGA connector. Many thanks to @mizapf and @speccery for their kind help in getting this done. Enjoy!

Never mind: I found the MAME source files (https://github.com/mamedev/mame/blob/master/src/mame/drivers/ti99_2.cpp and https://github.com/mamedev/mame/blob/master/src/devices/bus/ti99/internal/992board.cpp) and that documents quite a bit. I do wonder, though, why so much ROM space was needed. Standard 1980 MS Basic fitted in 8KB, maybe 12KB once you added a BIOS.

Thanks for that. I re-read the Byte article on WHTECH and there is a sentence that I missed earlier. It says they went from 16KB ROM to 32KB ROM in order to be able to include a full file system. The storage required for that also caused the RAM to be increased from 2K to 4K. As you say, the first design docs actually planned for 12K ROM and 2K RAM, so there was definitely some feature creep there. The Byte article also says the the last 8K are bank switched. Did you figure out how the bank switching works? From a quick glance at the schematics I get the impression that the bank switch is a hack using one of the keyboard lines... On the other hand, the schematics appear to use a single 32KB ROM, which does not appear to match with the actual (pre-production) hardware. Any insights about this would be welcome

I was reading up on the 99/2 and wondering what the difference is between the 24K en the 32K versions of the ROMs. What added functionality is in the extra 8KB? (all the documents on whtech in the 99/2 directory seem to refer to the 24KB version only).

Two more uses of the 9900 chip range: - In Germany, mini computer company "Kienzle" produced the MCS9000 range of mini computers based on the 9900 and the 99105. - The Fluke 1722A "Instrument Controller" was effectively a 99105 based desktop computer.