pnr2015

Sorry for the delay in answering, but no, I have never found a copy of that manual. It must have had pretty limited circulation for no copy to survive. Micro-programming was (and is) a highly specialised occupation, I suppose.

Do you have that user guide (or a link)? Did anybody ever come across a copy of the "990/12 Writeable Control Store Assembler and Language" manual?

How is the variant different? Where does it come from?

They were added for compatibility with the Terminal Emulator II module, which has only these names in its code. RS232 and RS232/1 are the same as HEXBUS.20 and RS232/2 is the same as HEXBUS.21

I think this is not a PHP1300, but a HX5102 clone. The 8272 chip is a floppy controller, and overall the components seem to match those on the HX5102 board (see the picture that @mizapf posted earlier in this thread). The ROM and RAM chips are higher capacity, so there is only one of each. Some more TTL logic seems replaced by PAL's. I think MAME has a working emulation of the HX5102, so the contents of the PAL on the original board must be known. I guess somebody must have reverse engineered the schematics. Not sure what the edge connectors on the original HX5102 PCB were for - they are not mentioned in the draft manual. There are some photos of the Michael Becker PHP1300 clone over on WHTech, but no photo of the actual board with components. I think it will have the very same chips as the original board - maybe the hex inverter chip (of which only one inverter is used) is integrated into a larger PAL/GAL. Are the whereabouts of that clone known? Come to think of it, maybe it is a good idea to put the reverse engineered PHP1300 ROM source in that directory on WHTech?

@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

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

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

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

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

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.

I think you are maybe over-analyzing it: connecting CLKOUT to /PHI3 will likely work up to 4MHz. Connecting CLKOUT divided by two to /PHI3 will work up to 6MHz. Use the falling edge of CLKOUT to clock the divider to get phases right. 1. I think that the address lines may not yet be stable at the start of ALATCH, but certainly will be by the end of it, i.e. you may have a CE glitch during ALATCH. Normally this should not matter, as the actual fetch or write happens later in the cycle. 2. I think for the 9901 the PHI3 duty cycle does not matter. PHI3 appears to have only two uses: to drive the internal counter and to synchronize the interrupt circuit. The data sheet only says that the pulse width is *minimum* 45ns, it could be wider. Looking at the 99000 and 9901 data sheets, using CLKOUT for PHI3 should work for both purposes. 3. The 9901 output bits are driven by the falling edge of CRUCLK, not by PHI3; the extra PHI3 cycle does not matter I think. The input bits are read on the rising edge of /RD, again PHI3 does not matter. With the automatic wait state there is plenty access time, even at 6MHz. To be sure, set up a test circuit on Stuart's 99000 board. I've glued a small strip of solder less breadboard in one corner for such experiments, but I don't have a 9901 at hand to verify my above views.

Memories can fade: I looked at the documentation again and indeed the TI990/4 had no mapper at all. The MAP chip in a TI990/10A is a 64 pin package, not 40.

Are you sure? I thought the TMS9900-based TI990/4 had a 74612 mapper. The discrete logic TI990/10 used a MMU with three "base+extent" segments. The TMS99000 based TI990/10A used the same MMU, but integrated into a single custom VLSI chip (referred to as "MAPPER". It is a 40-pin DIP package; I don't think TI ever sold this chip separately).

This was done in the later versions of 16 bit Unix (V7M, 2BSD). It split the 64K area in a base area (say 48K) and up to 15 overlays (say 16KB each). It worked like this: - first you compiled/assembled your code to separate object files. - then you linked it into the final program, specifying which object files went to into the base, and which into each overlay. - the linker worked out when a function call went from base to an overlay or from overlay to a different overlay. - the linker then added little stub subroutines to base, one for each such target function; the calls to the target function were patched up to be calls to the stub - the stub would check if the currently mapped overlay was the correct one and if so jump to the real target subroutine; if not, it would first map in the right overlay and only then make the jump BSD2.11 (released in 1992) managed to run a 250KB kernel in a 64KB address space.