HEXBUS command codes

[pnr]

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?

 

[wierd_w]

this document--

https://ftp.whtech.com/hexbus_cc40_ti74/Hexbus Drive-Controller (Model 5102) Manual.pdf

 

references a "Disk Manager 3" cartridge.

 

Disassembly of that cartridge might give you what you need.

[pnr]

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.

Edited November 22, 2019 by pnr
added info for OLD

[kl99]

The CC-40, the 99/2 and the 99/8, and even the 99/4 with its PHP1300 Hex-Bus Interface all share the Hex-Bus Protocol. Michael Becker from SNUG, who investigated Hex-Bus a lot, revealed some bug (or bugs) in relation to the SLAVE mode.

mizapf implemented the Hex-Bus so far into the 99/8 and 99/2 in MAME. Afaik the Hex-Bus Disk Drive Emulation in MAME was not connected yet to the CC-40 MAME Emulated Device. The CC-40 Device is not maintained by mizapf, and that device might miss the Hex-Bus Port emulation but I don't know this.

 

Bernhard and me did dump the DSR rom of my PHP1300 Hex-Bus Interface for the 99/4(A) a few years back, if that binary helps you.

rom.BIN

 

Also a real CC-40 might be the easiest device to test connect to your FPGA based 99/2.

And when working on Web99 I discovered one weakness of the Hex-Bus RS232 Interface compared to the DSR in the 99/4 RS232 PEB-Card and the 99/4 Sidecar RS232 Interface is that they discontinued the support to load and save a program via the RS232 device.

So on the 99/4(A) you can say OLD RS232 and receive a program from a connected 99/4(A).

But you can't do that command on a 99/8 using Hex-Bus RS232.

Same situation with SAVE RS232 to save a program to a connected 99/4(A).

(Side note, the Windows Tool Web99 is exploiting this functionality to load any basic program into the memory of the 99/4A via the RS232 port. No Disk Drive, nor memory expansion, nor terminal emulator or any software on the 99/4A required.)

 

Here are some documents, you might have missed one of them:

 

The original commented source code for the 99/8 Hexbus DSR:

http://ftp.whtech.com/datasheets and manuals/99-8 Computer/TI 99-8 Hexbus DSR Source.pdf

 

Also there is the preliminary User Manual for the Hex-Bus Disk Drive:

http://ftp.whtech.com/hexbus_cc40_ti74/Hexbus Drive-Controller (Model 5102) Manual.pdf

 

The Cyc features the preliminary User Manual for the PHP 1300 99/4(A) Hex-Bus Interface:

\vendors\ti\php\php1300\php1300.pdf

 

TI-99/4A Home Computer Hexbus Interface Peripheral Software Functional Spec Version 1.0:

http://ftp.whtech.com/hexbus_cc40_ti74/994a Hexbus Interface/TI-99_4A Home Computer HexBus Interface Peripheral Software Functional Spec V1.0 10-24-1983.pdf

 

Hex-Bus™ Floppy Disk System Product Specification:

http://ftp.whtech.com/hexbus_cc40_ti74/Hebus floppy product specification.pdf

 

Hex-Bus™ RS232/PO Software Functional Specification:

http://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus Specifications.pdf

(page 231 - 258)

 

Cyc features Doc-Bus™ Intelligent Peripheral Bus Structure, Timing, and Protocol Specification 4.0:

\vendors\ti\internal\docbus\docbus.pdf

 

Hexbus™ Intelligent Peripheral Bus Structure, Timing, and Protocol Specification Version 3.7:

http://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus Specifications.pdf

(page 7 - 60)

Intelligent Peripheral Bus Structure, Timing, and Protocol Specification Version 2.8:

http://ftp.whtech.com/hexbus_cc40_ti74/Intelligent Peripheral Bus Structure, Timing, and Protocol Specification V2.8 07-03-1982.pdf

 

Intelligent Peripheral Bus Controller Specification:

http://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus Specifications.pdf

(page 75 - 102 & 103 - 131)

 

Software Specification for the Hex-Bus™ Floppy Disk System:

http://ftp.whtech.com/hexbus_cc40_ti74/Software Specification for the HexBus Floppy Disk System V1.0 08-02-1983.pdf

 

Edit:

One more, the TI-74 Technical Manual features the DOCBUS which is compatible to the Hex-Bus:

http://ftp.whtech.com/hexbus_cc40_ti74/ti-74/TI74 technical data manual.pdf

Edited November 23, 2019 by kl99

[kl99]

On 11/21/2019 at 3:45 PM, pnr said:

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?

 

HEXBUS.10 refers to the printer/plotter device. (compare device number list on page 20 of http://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus Specifications.pdf)

Depending on the device certain commands are not allowed because they don't make any sense.

A printer will never support a SAVE command.

A printer probably only supports OPEN, CLOSE and WRITE. IN 99/2 Basic these translate to OPEN, CLOSE and PRINT.

Maybe that is the misunderstanding!?

 

As suggested in my previous post, I would try connecting your FPGA with a real CC-40 and read the communications.

 

[kl99]

21 hours ago, pnr said:

...

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.

The DSR Source Code for the SAVE OPCODE ROUTINE starts from page 35:

http://ftp.whtech.com/datasheets and manuals/99-8 Computer/TI 99-8 Hexbus DSR Source.pdf

It seems it checks for Verify flag, sets the SAVE attributes and then passes the program size to check if other side is okay with the size.

The code then goes BL @MXMIT which ends us up on page 53, which is about the MASTER MODE COMMUNICATION ROUTINE.

This is probably the transmission you saw.

[pnr]

Hi kl99, many thanks for all those links. These have been very helpful!

 

Quote

As suggested in my previous post, I would try connecting your FPGA with a real CC-40 and read the communications.

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.

 

Quote

HEXBUS.10 refers to the printer/plotter device. (compare device number list on page 20)

 

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.

 

Quote

Bernhard and me did dump the DSR rom of my PHP1300 Hex-Bus Interface for the 99/4(A) a few years back, if that binary helps you.

 

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).

 

 

 

[pnr]

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.

 

[kl99]

wow, impressive! congrats on the success!
Is there any chance you can make some video of the fpga in action?

Edited November 27, 2019 by kl99

[pnr]

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.

 

 

[pnr]

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  

 

 

[+Ksarul]

That sounds like a very interesting idea, @pnr

[wierd_w]

Indeed. It leaves plenty of room to deal with potential file system types instead, or to deal with different kinds of media.

 

EG-- instead of focusing on supporting just SDCard media, support USB instead.  That gives you SDCard (via adapter), USB stick, USB floppy disk drive, USB CDrom, etc.

[pnr]

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?

[wierd_w]

I know you said FPGA, but other than trying to squeeze every ounce of performance out, a reasonably fast micro controller would suffice in most cases.  Many of those have existing host-mode USB stacks that could be leveraged.  The same kind of code that the 99/2 uses would still be damned tiny, leaving plenty of room for the host mode interface stack, and a HID storage class handler.

 

 

But (shrug).

 

I still like the idea of a simple device that can run off a 9v battery, that you put just about any kind of USB storage on, and it just works.