TI-99/4A with a Pipistrello FPGA board

[speccery]

I'd like to collect input from people here regarding my next board design: I'm finally planning to start PCB design for a board to be connected to the side connector of the TI, to make the work I've done with the Pipistrello accessible to others. Regarding the feature set, I was planning to keep it relatively simple: basically have the FPGA chip (and the level shifters to go with it), a minimum of 1.5M bytes of RAM (1M for SAMS and 0.5M for GROM and/or cartridge - the configuration would be determined by the FPGA and thus flexible). I might go with a DRAM chip, in that case the memory capacity would be a minimum of 16Mbytes).

In addition there would be SD card slot, and a microcontroller for USB support. I could use my existing microcontroller design to keep things simple, in that case the USB would be a device component only. It would enable serial port communication over USB at full speed USB, i.e. 12Mbps. It could also emulate HID devices (and mass memories). The device interface cannot be an USB host. I have tried - but only very briefly - a beefier microcontroller, which would enable also USB host support but that requires probably more software work, and it is a much larger chip so more pins to solder (144 vs 48).

In addition to these there would be an extension connector making some of the FPGA pins available for other purposes.

 

I would probably try to include edge connector pass-through for other devices, but maybe without buffers; I'm not sure about that one. The passthrough, if there, does require some physical design thinking - at least the edge connectors I sourced from China have straight pins (i.e. non-angled). Thus direct use of that connector would probably mean creating two PCBs: one for the actual board, and one to house just the edge connector and another angled connector.

 

Opinions, advice?

[Sinphaltimus]

What about a pass through that mimics M@'s 32k side cart? Too much is always better than not enough (but it's almost just as bad). I like the USB Host option as it will come out of the starting gate with a plethora of potential.

[speccery]

What about a pass through that mimics M@'s 32k side cart? Too much is always better than not enough (but it's almost just as bad).

That's a great point. I need to check those schematics (well first I need to find those from somewhere but that should not be difficult).

 

I like the USB Host option as it will come out of the starting gate with a plethora of potential.

I like it too... Just trying to keep things manageable. Perhaps I will start the design with this feature and if the board becomes too complex I will drop it. It has to be a four layer board anyway (another first for me).

[speccery]

Ok after a quick schematic check having that support (similar to 32k sidecar) only requires 3x LS244 and 1x LS245 chips plus a bunch of 33 ohm series resistors for the control lines, presumably to damp down signal ringing over the flex cable (which is another thing I have never seen...). Adding those should not take too much space on the board. The LS245 probably should have hardwired control logic (data direction and enabling) so that it works regardless whether the FPGA is configured or not. Hmm... Or maybe not, it could be simply disabled with a pull-up resistor until the FPGA begins to drive it actively. This may mean that the startup of the board is a bit funny, since it will take a short while before the FPGA is configured, either by the MCU or an on-board serial flash.

[kl99]

Hi speccery

 

Please help us understand and confirm these 'hardware newbie' assumptions:

The PCB design you already made is TMS99105 CPU based. It does not require nor use a TI-99/4A console. No connection to real hardware like PEB is done. It connects to a FPGA Development Board which allows VGA/Sound/Keyboard output/input.

With that FPGA Development Board it acts as a "high-speed TI-99 clone machine".

 

The PCB design you now want to specify is without a TMS CPU, because the TI-99/4A console is being used as main unit here.

This will be a sidecar peripheral and eliminate the need of some real hardware add-ons like Ram Expansion, SAMS, Disk Controller.

The FPGA in this board interacts with the TMS9900 on the console, with all waitstate dependencies of the original mainboard, because the TI-99 console as such is not changed.

You are able to even simulate the existance of any Cartridge (any Rom/Grom content) with the Cartridge Port being empty.

The Console Rom/Grom is still being used and can not be changed/overridden or taken out.

The board is not compatible with TI-99/4A QI consoles because those lack some Grom lines on the side bus.

The board will work with the 99/4 and the 99/4A, but not with the 50pin bus of the 99/8.

The F18A can be used as VDP on the console.

The computer uses the TI-99 console keyboard as input, joysticks connected to the TI-99 console as input.

The computer uses the TI-99 console video output as there is no Video Out/Sound out on the board.

There is no plan to have a serial/parallel port.

There is no plan to have an Hex-Bus port.

The Speech Synthesizer has to be connected to the Sidecar before this device (you will have one of those soon).

You may achieve to pass trough the edge connector to connect compatible side cars or the PEB afterwards.

The PCB does not require a FPGA development board because the FPGA is on the PCB.

It requires an external power supply.

Edited December 12, 2016 by kl99

[speccery]

Hi speccery

 

Please help us understand and confirm these 'hardware newbie' assumptions:

The PCB design you already made is TMS99105 CPU based. It does not require nor use a TI-99/4A console. No connection to real hardware like PEB is done. It connects to a FPGA Development Board which allows VGA/Sound/Keyboard output/input.

With that FPGA Development Board it acts as a "high-speed TI-99 clone machine".

Yes thanks for the clarifications - I again jumped into the middle of thought process without an introduction...

What you wrote is exactly true. Personally for me this board (if and when I get it working) will be the fulfillment of something I have wanted to do for a very long time - to rebuild one of the retrocomputers we all love. It is a high speed TI99/4A clone, but it can also be a basis for other computers (Geneve, TI-99/2 or TI-99/8) depending on the FPGA configuration. It could potentially even be a basis of a clone of TI's minicomputers.

 

The PCB design you now want to specify is without a TMS CPU, because the TI-99/4A console is being used as main unit here.

This will be a sidecar peripheral and eliminate the need of some real hardware add-ons like Ram Expansion, SAMS, Disk Controller.

The FPGA in this board interacts with the TMS9900 on the console, with all waitstate dependencies of the original mainboard, because the TI-99 console as such is not changed.

You are able to even simulate the existance of any Cartridge (any Rom/Grom content) with the Cartridge Port being empty.

The Console Rom/Grom is still being used and can not be changed/overridden or taken out.

The board is not compatible with TI-99/4A QI consoles because those lack some Grom lines on the side bus.

The board will work with the 99/4 and the 99/4A, but not with the 50pin bus of the 99/8.

The F18A can be used as VDP on the console.

The computer uses the TI-99 console keyboard as input, joysticks connected to the TI-99 console as input.

The computer uses the TI-99 console video output as there is no Video Out/Sound out on the board.

There is no plan to have a serial/parallel port.

There is no plan to have an Hex-Bus port.

The Speech Synthesizer has to be connected to the Sidecar before this device (you will have one of those soon).

You may achieve to pass trough the edge connector to connect compatible side cars or the PEB afterwards.

The PCB does not require a FPGA development board because the FPGA is on the PCB.

It requires an external power supply.

 

Again thanks for the specific list I don't have any experience with the TI-99/4, TI-99/4A QI and TI-99/8 so thanks for pointing out the differences there. I believe the TI-99/4A QI could be made to work like the TI-99/4A if some patch wires were added to essentially connect the same signals as on the normal TI-99/4A. I knew there was a ROM/GROM difference between the normal and QI model in that the QI would not show in the menu ROM only cartridges, but I did not know some signals were lacking on the edge connector.

 

Your list is correct, except: the console GROMs could be taken out, and driven by the board (on the TI-99/4A - probably also on the TI-99/4A QI (with patch wires) and TI-99/4). Good that you pointed this one out, as that reminds me that some open collector or 3-state drivers are needed for a few signals (READY, EXT INT, NMI).

 

Console ROMs cannot be replaced externally, as they reside on the 16-bit bus that is not visible outside. The same with video: people could use either the standard VDP or F18A.

 

The FPGA will have plenty of space for further logic after the basic feature set (and I mean really a lot of space - enough for soft co-processors and such). That's why I wanted to have an extension connector for further peripherals. That would make it possible to have parallel, serial and hex bus ports with suitable wiring. I know roughly how TI serial and parallel adapters work, implementing them in logic should be quite straightforward. I don't know what the hex bus logic looks like, but that can't be very complex either. It becomes a matter of connectors and potentially some buffers.

 

In fact regardless of the microcontroller choice (I am tempted to go with the higher end device) it makes sense to have some of the microcontroller I/O ports available and connected to header pins for further expansion. I want to use a microcontroller I am somewhat familiar with and for which I know there are good software stacks to start with, so I am planning to go with NXP LPC1343 or LPC4330. These chips use very fast ARM cores and are firmware upgradeable over USB. The price delta between those chips is something like USD 5. As far as cost goes I am not trying to hit a minimum price point, as this is a hobby project I want it to be fun to design. Still the parts will not be that expensive, the most expensive component will be the FPGA chip which is about USD 18. I guess the raw material costs would overall be about $45 (I haven't done any calculations though, and even at four layers the PCB will require a certain size to accommodate everything).

 

[+retroclouds]

Would you be able to trigger the load interrupt via software on the board, thinking about a timer that programmatically could trigger the load interrupt. We had a discussion about that in one of the forum threads. Thinking about a task scheduler.

[+mizapf]

Dreaming of using the LREX command?

[kl99]

Your answers make me very happy already. Again, in 2001 i already dreamed about virtualizing the PEB:

https://de.groups.yahoo.com/neo/groups/texasinstruments/conversations/messages/51

And now finally it's happening.

 

Could the DSR for the "virtual" devices be done in a way that it is actual 9900 assembler code? Or is it solely controlled via FPGA?
I wonder how flexible it would be if the DSR rom/ram is stored and read in from SD Card during power up.

 

Do you plan to have people store the Cartridges or Disks or both on the SD card?

[Sinphaltimus]

Hard disk controller and drive emulation ftw.

[speccery]

Would you be able to trigger the load interrupt via software on the board, thinking about a timer that programmatically could trigger the load interrupt. We had a discussion about that in one of the forum threads. Thinking about a task scheduler.

 

 

Yes, that would be very easy to do. There could be a programmable count down timer, that software could load and the interrupt and auto-reload could be triggered when the count hits zero. Something like that.

[speccery]

Your answers make me very happy already. Again, in 2001 i already dreamed about virtualizing the PEB:

https://de.groups.yahoo.com/neo/groups/texasinstruments/conversations/messages/51

And now finally it's happening.

 

Could the DSR for the "virtual" devices be done in a way that it is actual 9900 assembler code? Or is it solely controlled via FPGA?

I wonder how flexible it would be if the DSR rom/ram is stored and read in from SD Card during power up.

 

Do you plan to have people store the Cartridges or Disks or both on the SD card?

 

Yahoo groups seem to require a sign in... I need to check that out later.

 

The nice thing with the FPGA design, and having the FPGA do memory mapping, is that we can flexibly set things up the way we want. Certainly we could have multiple DSRs supported, for example CRU areas >1100, >1200, >1300 etc could all have their own enable bits, which would page in to the DSR address space >4000 a 8K chunk of RAM which would be preloaded with something. So you could have 9900 assembler code DSRs as normal. We just need some memory that's reserved for that purpose. The TMS99105 circuit already does this.

 

The SD card will contain ROMs, GROMs, DSRs, and disk images or just contents of disks as FAT (MSDOS) files.

For example: upon boot up the FPGA would get configured either by the microcontroller or using a simple configuration flash memory. That configuration load could for example include one 8K DSR boot ROM for the 9900, implemented by the FPGA, and this boot ROM could then load from the SD card files which would be used to populate memories for cartridge ROMs, GROMs and further DSRs. Alternatively development could be easier and faster by having the microcontroller do the SD card control using existing FAT32 libraries, so it might be better to have the microcontroller bootstrap the whole thing. I.e. on boot up the microcontroller starts first, reads stuff from the SD card and writes that to the memory of the 9900 through the FPGA. The microcontroller could take care of SD card traffic, making the DSR work simpler.

 

It would also be possible to implement in the FPGA emulation of the floppy controller, so that standard DSR code could be used. The way that would work would be such that the FPGA would present to the 9900 the normal disk controller registers in the addresses expected by the standard DSRs. However, those registers would not really drive any logic, instead they would be accessible by the microcontroller, which could then emulate the disk controller chip. I think that would be easier than emulating the controller in VHDL. Software for the microcontroller would be normal 32-bit C-code compiled with GCC. Hardware wise this is a simple setup: you have the TI-99/4A expansion bus going to the FPGA, the FPGA has it's internal memory and a larger external memory, and then you would have a simple bus going from the microcontroller to the FPGA. The FPGA then just glues all of this together and handles all the fast bus interface activities, such as memory paging. Microcontroller software can manage more complex activities, such as SD card access.

 

In a similar fashion serial ports and other peripherals can be realised, by having the FPGA present a register compatible interface, and behind that interface you either have an implementation done by the FPGA or by the micocontroller.

Edited December 12, 2016 by speccery

[speccery]

could this be something as simple as the sprite count starting from 0 as opposed to 1? or inversely ending 1 too short?

 

 

After some debugging I finally was able to fix the problem. https://hackaday.io/project/15430-rc201699-ti-994a-clone-using-tms99105-cpu/log/50414-sticky-graphics-mode-2-bug-fixed explains the details (well to an extent).

It was not a sprite problem like I suspected, rather graphics mode 2 problem with its support for 768 unique characters on the screen simultaneously - I managed to screw up the last cell in each band of 256 characters due to an increment happening too early.

[Sinphaltimus]

" due to an increment happening too early."

So it was off by one?

[speccery]

So it was off by one?

 

 

Yes I guess you could say that, off by one on bits 8 and 9 of character number.

[Sinphaltimus]

I could very well be a mental case but I like to keep track of my "guesses" so to speak. Or gut feelings. I don't always know how to articulate it. Especially when I have no idea about the underlying tech and am simply relying on the observable.
Or I could very well be a mental case.

[speccery]

I could very well be a mental case but I like to keep track of my "guesses" so to speak. Or gut feelings. I don't always know how to articulate it. Especially when I have no idea about the underlying tech and am simply relying on the observable.

Or I could very well be a mental case.

 

 

I think that is a good practice, I too try to track my guesses I think that is part of the learning process.

In a similar spirit I also from time to time spent quite a bit of time reading what I've written. Maybe that's a bit mental but at least it helps me remembering things. Or it could just be a habit I've adopted at work when there are very many sensitive messages to be sent...

[speccery]

Got a message from the PCB manufacturer that the boards are on their way from Hong Kong to me. It will be interesting to see if they reach me before the holidays start, I'm planning to take some days off so there should be a bit of time to work on the boards.

[speccery]

The boards arrived and look fine, I also posted an update to hack-a-day. The arrival of boards is always a kind of magical moment, nice to see something physical coming out of a design

I haven't had time to do more than just solder in the connectors, to my delight alignment was perfect and the boards sits nicely on top of the Pepino. This time even the mounting holes are aligned well (I screwed that up on my previous PCB project, the holes were off by about a millimeter).

I posted some more pictures to AtariAge gallery, but here are a few.

[speccery]

Christmas vacation has gone fast, but I've been able to work a little on the debugging and bring up of the board. I got this morning the board working stably, or at least so it seems. Need to do further validation, but I was able to run TI Invaders for a long time. It seems the three way multiplexing scheme I put in place actually works, but it is pretty picky about timing.

 

To give a little more detail, the Pepino board does not have enough free I/O pins to handle all the signals in a simple way. Thus I built a multiplexing scheme, where timing is mostly based on the address latch signal. With a 20 MHz clock the machine cycles are 200ns. Address latch is active for about one quarter, the first 50ns. During that time the FPGA latches the address (about 30 ns into the cycle). After that time - and this is specific to my board - the FPGA disables the address/data bus drivers for a moment and uses that time read and write control signals. It enables the control signal driver on one half of the 16 bit bus (enabling the FPGA to read signals like #MEM, #WR, and BST1-3). Simultaneously the FPGA itself drives on the other half of the 16-bit bus, and provides a clock pulse to an external 74HCT574 8-bit flip flop to capture a bunch of control signals (including reset, interrupt, nmi, etc). This control signal read/write cycles takes about 30ns at the moment. Once that is done the normal address/data drivers are re-enabled and the normal data transfer is completed (read or write). Timing has to be pretty precise for all of this to work, and now that seems to start to be the case.

[speccery]

My new job has worked well in consuming almost all of my time. I did make a small VHDL update (available at github) to drive the two status LEDs. One of them shows when CRU bit 1100 is set, i.e. when disk DSR is active, while the other status LED toggles on and off based on calculating address latch pulses from the TMS99105, allowing one to see that the CPU is alive.

 

Working board - on its way to kl99 (w/o the CPU).

Logic analyser picture of the timing, all driven from the address latch signal, top most row. This is sampled at 100 MHz and used to generate the other signals.

Edited January 9, 2017 by speccery

[Manic1975]

Is there anybody who can try to put TI99/4a on MIST? Please someone!!!!! Please!!!!!!!

[kl99]

Working board - on its way to kl99 (w/o the CPU).

 

 

Many thanks for allowing me to test this. I hope to get it to work and I am able to demo it in Birkenau in April, unless you show up there yourself

Michael Becker (SNUG) mentioned incompatiblities between TMS99105 and the TMS9900 Cpu here:

http://snug.blogdrive.eu/snug/sgcpu/sgcpu_e.pdf

And the preferal of the TI-99/5 rom/groms if they would have opted for the TMS9995 as CPU for the SGCPU card instead.

Is the TMS9995 more close to the TMS99105 than to the TMS9900?

We are lucky to have the TI-99/5 rom/groms dumped a few months ago. Could this be the better operating system for this unit?

BR Klaus

[speccery]

 

Many thanks for allowing me to test this. I hope to get it to work and I am able to demo it in Birkenau in April, unless you show up there yourself

Michael Becker (SNUG) mentioned incompatiblities between TMS99105 and the TMS9900 Cpu here:

http://snug.blogdrive.eu/snug/sgcpu/sgcpu_e.pdf

And the preferal of the TI-99/5 rom/groms if they would have opted for the TMS9995 as CPU for the SGCPU card instead.

Is the TMS9995 more close to the TMS99105 than to the TMS9900?

We are lucky to have the TI-99/5 rom/groms dumped a few months ago. Could this be the better operating system for this unit?

BR Klaus

 

 

I am only happy that you will be testing it! I still haven't had the time to write instructions, but basically here are the steps to get started. It may seem the list below is long, but actually this should be straightforward:

1. connect everything

1.1 the CPU into the socket on the shield

1.2 the shield to Pepino

1.3 the one wire from a connector to the PS2 mouse port (write signal, I did not have the time to get it working through the connectors)

1.4 VGA, audio to the display, USB to your windows PC (which is a prerequisite)

2. Download & install some software:

2.1 some FTDI USB drivers need to get installed, see Saanlima's web page.

2.2 Also download the fpgaprog.exe program, also from Saanlima

2.3 Make a clone of the contents of my github repository to get all the stuff https://github.com/Speccery/EP994A

2.4 Install CYGWIN, 64-bit version. This is not strictly needed, but the initialisation script init.sh (which just calls the memloader.exe program repeatedly) runs under the bash shell.

2.5 Get in touch with me to get a precompiled version of the above memloader.exe program - in fact I should just make a zip file with everything in it for you

2.6 Create a directory that has all the ROMs and GROMs you intend to load (see the init.sh script)

 

Once you have done the above, there are two steps which you need to run every time the board is powered on:

3. Run fpgaprog.exe to load the FPGA with the file ep994a.bit. You can also do this so that the bit file is loaded onto the onboard flash memory, saving you this step.

4. Run init.sh to load all the ROMs and GROMs. The script will end by running memloader.exe with a special command line parameter, where it stops and starts to forward button presses from the PC keyboard to the TMS99105 system. From this point on it is more or less the "usual" TI-99/4A experience.

 

Regaring this last step (4) my intention is to create a small boot program, which would load the ROM files from the SD card, making this a nicer experience. PS2 keyboard support should also be implemented at that point. With those changes the system would become standalone. Currently the PC USB connection is needed for ROM loading, PC keyboard forwarding and filesystem access (DSK1, DSK2, etc).

Edited January 13, 2017 by speccery

[speccery]

Regarding your comments about using TI-99/5 ROMs and GROMs, that would be interesting. I can change the FPGA so that the memory map matches the TI-99/5, in case there are differences. The TMS99105 is probably more different from the TMS9995 than the TMS9995 is from the TMS9900. On the other hand the TMS99105 does not have the timer or on-chip RAM that the TMS9995 has, potentially making it more compatible.

 

The PDF document you linked to mentions the TMS320C25 DSP. Incidentally I have also built a board with this DSP - that project actually landed me my first summer job in the industry. This job eventually turned into a full-time job and is how I got started while still doing my university studies. Back in the day I have done software for the TMS320C25 (16-bit fixed point DSP), TMS320C30 (32-bit floating point DSP) and the TMS32C542 (another 16-bit DSP) processors.

Edited January 13, 2017 by speccery