Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

123 Excellent

About pnr

  • Rank
    Chopper Commander

Recent Profile Visitors

3,462 profile views
  1. For future readers: I think you mean page 80. When developing the Verilog model for the 99000 I came across this optimisation of MOV. It is not only the DOP fetch, but also the destination WS fetch that is skipped. When debugging the FPGA version of the TI99/2 I disabled this optimisation for a while. Much to my surprise the TI99/2 ran some 10% slower without the optimisation. There is some interesting analysis by Karl Guttag (the 9995 and 99000 chip designer) here (note that the code name for the 99000 was "Alpha"): https://hansotten.file-hunter.com/uploads/files/99000 (Alpha) Misc Documents.pdf It says that MOV is 25% of instructions, together with MOVB even 30%. Throw JMP in the mix and it is 50%. Do you still have the problem for MOVB? On the 9995 interim solution it is not an issue and on the 99105 you can ignore the read-before-write using the BST outputs, as you already described above. What other current scenario is still problematic?
  2. Ehmm.... the above is the total of what I know about them.
  3. No, I did not mean any word length. I meant "general purpose" as opposed to hardwired to be an accounting machine.
  4. By coincidence I was looking a RTC chips a few weeks ago. Looking at some old boards, I arrived at the MM58174 as a chip that was period correct and has direct links to very first RTC chips to appear on the market in the 1970's (the OKI M5832). For an 8 bit variant have a look at the MM58167. A third choice could be an early serial chip, the NEC uPD4990. This can maybe be coerced to act like a CRU interface chip. I think all are still available on eBay, but I have no direct buying experiences for any of the above.
  5. As I understand it, Kienzle got started as a manufacturer of mechanical taximeters in the 1920's and from there expanded into electro-mechanical tabulating/accounting machines in the 1950/60's. From there they moved to electronic accounting machines (what in Germany they used to call "Mittlere Datentechnik", mid-range information technology). This was the 6000 series. Some sources say it used the 9900, but considering is was launched in 1968 that is probably wrong. Perhaps the later models did. Kienzle got stuck in that technology and was late converting to true mini-computers. They launched the 9000 series in 1979 and this used the tms9900 for sure. As they were entering the market late without clear differentiation, it was not a commercial success. I visited the Kienzle factory in 1984 (I think) as a student on a group field trip and came across a 9000 series machine in passing. They mainly wanted to showcase their automobile technologies but I got a few questions in. What I remember of that is that it was based on the tms9900 and that it ran MTOS. They also claimed that it could "run Unix as a sub-system under MTOS". I think what that meant was that it had a C compiler and a C library that worked under MTOS. I've never found any other reference to that, maybe it was a research skunkworks project. I think the main workhorse in the 9000 series was the Kienzle 9066. I am not sure what MTOS was. It could have been an in-house development, it is also possible that it was a translated version of DX10, or something like that. Later on they had the the 9100, 9200 etc. series, which I believe to have been tms99000 based (99105 most likely). In view of the timeline it is possible that the later 9x00 series used Ten-X technology, but I am speculating here. It is quite likely that (Mannesmann-) Kienzle made similar steps as TI in the late 80's, switching to x86 and 68K based unix systems, with software support to run the 990 base of Cobol programs, before giving up altogether. There is a list of Kienzle models here: http://www.computer-archiv.de (go to section K, select Kienzle, for the specific page). As Ksarul already observed, there are also MIPS machines in the list, the 2800 series.
  6. 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.
  7. 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).
  8. Isn't that AmigaDOS? Alan said that he was developing on an Amiga after the TI and Geneve.
  9. 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.
  10. 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.
  11. See here: https://www.crowdsupply.com/radiona/ulx3s
  12. I think the PHP1300 also has the OSO chip?
  13. 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?
  14. 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
  15. 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.
  • Create New...