Hexbus JediMatt compatible sidecar

[+acadiel]

I know Ksarul has a lot of the /4A Hexbus prototypes (and I have the ROM for one of them).  But, has anyone thought about seeing if we can maybe put one of these in a sidecar for the JediMatt board?  It would be kinda cool to use these to use Hexbus peripherals, connect to a CC-40 or TI-74, etc.

 

I'd be willing to partner with someone on it - but we'd need hires pics of the Hexbus sidecars in existence.  

 

 

[brain]

Isn't there a HexBus Adapter for the 4/A That could be copied to do this?

[+acadiel]

39 minutes ago, brain said:

Isn't there a HexBus Adapter for the 4/A That could be copied to do this?

Yeppers!  That's what I was referring to above.  Ksarul has most of the copies of the /4A interface.  We also have schematics for the Hexbus drive controller.

 

Edit:  These are the only pictures I have of the interface.  Ksarul will need to provide any higher resolution ones we need.  He also has tons of the Hexbus interface chips he got as surplus.  I do see a PAL.  I do have the ROM dumped (attached).

 

hexbus_interface.BIN

[+mizapf]

The custom Hexbus chip (above the EPROM with the yellow sticker) looks like the one on the HX5102 (hexbus floppy drive). This would be great, because it would make it simpler for me to write an emulation for this Hexbus interface.

 

(The Hexbus chip on this board is the one slightly above the big black capacitor in the right half of the board, left from the socket on the right edge.)

 

Edited May 7, 2020 by mizapf

[+OLD CS1]

Might be kind-a cool to use my CC-40 peripherals with my 4A.

[+acadiel]

50 minutes ago, mizapf said:

The custom Hexbus chip (above the EPROM with the yellow sticker) looks like the one on the HX5102 (hexbus floppy drive). This would be great, because it would make it simpler for me to write an emulation for this Hexbus interface.

 

Ksarul bought hundreds of the Hexbus chips.  I forgot the exact number.

 

[pnr2015]

On 5/7/2020 at 9:19 PM, acadiel said:

Yeppers!  That's what I was referring to above.  Ksarul has most of the copies of the /4A interface.  We also have schematics for the Hexbus drive controller.

 

Edit:  These are the only pictures I have of the interface.  Ksarul will need to provide any higher resolution ones we need.  He also has tons of the Hexbus interface chips he got as surplus.  I do see a PAL.  I do have the ROM dumped (attached).

hexbus_interface.BIN 4 kB · 9 downloads

 

Did somebody ever do disassembly / reverse engineering on this DSR? Is it very similar to the TI99/8 DSR source that is up on WHTECH?

The community around the ULX3S FPGA board are looking into emulating a PHP1300 for Speccery's TI99/4A implementation.

[+mizapf]

I did not yet have a look, but I guess it will be a bit different from the 99/8's version because the 99/8 had the "Oso" Hexbus adapter chip, which is definitely more complex than the other hardware solutions in the HX5102 or the 99/2. The latter two had very simple chips, that is, more logic in the DSR code.

[+Ksarul]

I have about 25 tubes of the 1052911-X HexBus chips, as I wanted to make sure they didn't disappear into the ether. The surplus house that had them had no idea what they could be used for. I was actually looking at them yesterday, as I was digging through my wall of chips looking for some other parts to restock my active project supplies.

[pnr]

25 minutes ago, mizapf said:

I did not yet have a look, but I guess it will be a bit different from the 99/8's version because the 99/8 had the "Oso" Hexbus adapter chip, which is definitely more complex than the other hardware solutions in the HX5102 or the 99/2. The latter two had very simple chips, that is, more logic in the DSR code.

I think the PHP1300 also has the OSO chip?

[+mizapf]

No, according to the photographs from above, it is the Hexbus chip of the HX5102.

[wierd_w]

Wouldnt a card-edge passthrough "shoe" (In the form-factor of the speech unit), with the hexbus port routed out the back (Or, perhaps hidden under a lid, like the early model speech units did for the upgraded sample chip package?) be both more aesthetically pleasing AND more versatile as an option, than a jedi-matt connector? 

 

(Since we have much more compact electronics packages these days, it should be possible to produce much less "busy" circuit cards, and to produce such a unit in such a form-factor with modern ICs. Hell, you could throw in a big fat FPGA in there, and do it all that way even.  Being card-edge pass-through, you could put it before a PEB firehose for instance, allowing a single model unit to service all 3 major upgrades without modification-- You could slap a jedimatt 32k on, then a TIPI sidecar-- Or you could throw on a nanoPEB right after it-- or, as stated, put the firehose after it, and use a PEB version TIPI with it.)

 

Jeeze.. Edit AGAIN--

 

It would be amusing to throw that TI-95 hexbus -> C64 cassette module on, and have a file-indexed cassette on the 99/4A as well! 

Edited June 21, 2020 by wierd_w

[kl99]

I think The Cyc features the 99/4A source code of the Hex Bus Interface Php1300 in the Vendors/TI/internals

[pnr2015]

@mizapf: thanks for pointing this out. I now understand the difference between this chip and the OSO chip in the 99/8.

@kl99: thank you for this reference. Do I understand correctly that this source is behind a pay wall then?

For a 4K DSR ROM I would expect that it is something like 1500 lines of assembler source, not an unsurmountable amount of work.

Edited June 21, 2020 by pnr2015

[pnr2015]

@acadiel: I think the ROM image you attached is for the RS232 card, not the PHP1300.

 

Does anyone have a dump of the PHP1300 ROM at hand?

 

Thx in advance.

 

===

 

Never mind - I was a fool. The Hexbus DSR header begins with two entries for RS232, but HEXBUS comes after that. It is the right ROM.

 

Edited June 21, 2020 by pnr2015
mistake

[pnr2015]

All,

 

Worked my way (partly) through the ROM disassembly and squinted at the board shots a lot. I think I got a long way in figuring this out. The reverse engineered source is attached for reference.

 

It turns out that the Hexbus chip (PDF on WHTech) is not connected to the TI99/4A bus directly, but accessed via CRU bits (i.e. via the LS259 and LS251 on the board). The Hexbus chip is used in Mode 7. The wiring is as follows:

; CRU output bits                             After INCT R!2
;   0     - ROM enable
;   1-4   - data out                          0-3   - data out
;   5     - RS (0 = data, 1 = control)        4     - RS
;   6     - E (0 = write strobe)              5     - E
;   7     - INT enable                        6     - INT enable

; CRU input bits
;   0     - INT asserted (from FF)
;   1-4   - data in
;   5-6   - n/c
;   7     - INT enable

The IRQ output from the Hexbus chip is latched into a flip-flop (half of the LS74) on its falling edge. The output of the goes back to the LS251 and via a transistor (i.e. open collector) to the /EXTINT line of the TI bus. The INT enable line from Q7 of the LS259 is attached to the /CLR line of the flip-flop, so setting it low both clears the latch and disables interrupts until it is set high again.

 

From the ROM source, it would seem that the interrupt logic is not used for disk operations, only for serial/modem operations (i.e. to listen for new data coming in). Disk operations appear to be synchronous (as they are on the TI99/2).

 

The Hexbus chip does not appear to do all that much: it is basically a line buffer, combined with a little logic for dis/enable and for latching the HSK line. That is about the same as what the Hexbus corner of the I/O chip in a 99/2 does. Still, if you had to replace it with TTL, it would take 4-5 packages (and a few software tweaks). In terms of Verilog, I think it will take a good 100 lines or so.

 

I have not really looked at the PAL, I think it is only there for address decoding. Not sure what CRU range it responds to. Also not sure what the switch on the left does (maybe pick from two CRU range options?)

 

In the ROM I have focussed on how it interacts with the Hexbus chip. All the Hexbus interaction is really done in software, but it is straightforward. Most of the ROM seems to be about dealing with connection strings, as detailed in the draft software specification (PDF on WHTech). I'm not too interested in this, but if someone wants to have a go, the community would have a full ROM source.

 

If anybody has more info or corrections to the above, please let me know.

 

hexbus_romdis.txt

[+mizapf]

This document contains details about the HX5102 Hexbus controller chip (pages 25ff.). I used it for the emulation in MAME.

 

In addition, this is my interpretation of the specs in terms of code: https://github.com/mamedev/mame/blob/master/src/devices/bus/hexbus/tp0370.cpp

 

 

Hexbus Specification.pdf

Edited June 22, 2020 by mizapf

[pnr2015]

That MAME encoding of the chip is helpful. thanks! The logic matches with my understanding of how it works.

[+acadiel]

On 6/22/2020 at 6:31 AM, pnr2015 said:

In the ROM I have focussed on how it interacts with the Hexbus chip. All the Hexbus interaction is really done in software, but it is straightforward. Most of the ROM seems to be about dealing with connection strings, as detailed in the draft software specification (PDF on WHTech). I'm not too interested in this, but if someone wants to have a go, the community would have a full ROM source.

 

If anybody has more info or corrections to the above, please let me know.

 

hexbus_romdis.txt 84.32 kB · 11 downloads

Amazing job!  I really appreciate the hard work disassembling this and examining the pics to figure it out!

[+acadiel]

HX5102M.pdf

 

hx5102m.zip

 

I'll drop these here in case they help any.  They're most of the dumps that I could do of the HX5102 prototype that I had.  Ksarul has the original piece of equipment now and would have to dump any remaining chips.

 

[pnr2015]

@acadiel, @kl99, @mizapf, @Ksarul, @speccery

 

I've now fully analyzed the DSR rom of the PHP1300. This should help with MAME, cloned PHP1300 devices and FPGA work.

 

There is a bug in the "slave mode" code: a typo makes the DSR always return an error instead of working as planned. Fixing this byte will enable some interesting experiments (search for word "BUG" in source analysis).

 

In a few places the code could be cleaned up a bit, but this is not strange in what is beta version code.

 

 

hexbus_romdis.txt

[Omega-TI]

On 5/7/2020 at 11:44 AM, acadiel said:

But, has anyone thought about seeing if we can maybe put one of these in a sidecar for the JediMatt board?

 

There is a lot of space in that box!  We could probably have the "Ultimate Expansion" in that thing.  I imagine a TIPI/1024K with speech included and support for the HexBus and a pass through for P-Box users.  The case is long enough and in some parts even tall enough to stack circuit boards if necessary.

 

 

The only thing about re-doing a black 3D printed design, would be to have some recessed areas for the application of "brushed aluminum look" vinyl application... and of course a raised line to match the top of the TI between applications.  Dimensions could even be widened a little if necessary.  Of course something like this would take a lot of interaction between the TI gods here on the board and probably take a couple of years, but it would probably be the last upgrade anyone would ever need.

 

[+OLD CS1]

2 hours ago, Omega-TI said:

"brushed aluminum look" vinyl

Vinyl.  Pfft.  You come legit, or you a poser.

[Omega-TI]

39 minutes ago, OLD CS1 said:

Vinyl.  Pfft.  You come legit, or you a poser.

Normally I'd agree but what are the odds of ever getting the real thing?

[wierd_w]

Get 1/16th inch aluminum sheeting.  Cut working blanks with bandsaw/dremel tool. (Clamp appropriately)

Create wooden forms. (both positive and negative to the bends)

Put the aluminum sheet blanks in, and hammer it down (by beating on the top form with a hammer).

Remove aluminum sheet. Gently polish with wire brush, then light acid wash.