Jump to content

pnr

Members
  • Content Count

    129
  • Joined

  • Last visited

Community Reputation

113 Excellent

About pnr

  • Rank
    Chopper Commander

Recent Profile Visitors

3,395 profile views
  1. See here: https://www.crowdsupply.com/radiona/ulx3s
  2. I think the PHP1300 also has the OSO chip?
  3. 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?
  4. 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
  5. 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.
  6. 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.
  7. 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).
  8. 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.
  9. 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?
  10. Many thanks for doing that! Without it, the project would have been impossible. Loved your dumping video's on Youtube.
  11. 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.
  12. 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?
  13. 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.
  14. 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?
  15. 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 😁
×
×
  • Create New...