TI-99/4A with a Pipistrello FPGA board

[speccery]

Update about sound is here. Retrochallenge has only about a week left, and my weekend was mostly spent on other stuff than coding. Today I decided to time how long it takes to create these things: about two and half hours to add sound. That amounted to a crude implementation of TMS9919 and a sigma-delta DAC, and then cross referencing to classic99 source code, although I think my implementation is somewhat different.

I have only tested it with TI Invaders and that sounds right! Not sure about the white noise generator, I went with this VHDL code:

 

if bump_noise='1' then
  if noise_div_val(2)='1' then
    -- white noise
    k := noise_lfsr(14) xor noise_lfsr(13);
  else
    k := noise_lfsr(14);    -- just feedback
  end if;
  noise_lfsr <= noise_lfsr(14 downto 0) & k;
  if noise_lfsr(14) = '1' then
    noise_out <= not noise_out;
  end if;
end if; 

Obviously I did not get the frequencies right initially. I am no musician so I had to resort to my scope to see why the tones did not sound right. The result was that the output audio came out at about half the desired frequency, 440Hz became about 220Hz. That was easy to fix though.

 

Adding sound motivated me to play more TI Invaders. After I cleared all the invaders, and got to the UFO bouncing thing, I realised that that screen just was impossibly fast to play...

Edited October 23, 2016 by speccery

[speccery]

Yes, all three voltages are routed to it. My concept based on that the module adapter will take the place of the CPU within the console. The original CPU has to removed first, replaced by a socket, so the PCB can be placed onto it. This is my original idea. But when using the board as a stand alone solution (this is a special case), the three voltages has to apply through a separated power supply. Some old AT power supply still got -5 Volts. Or you can take one out of an old console. I think this will not be the problem...

That is a cool board you are creating! And the concept is nice, i.e. to mount the thing on the socket of the TMS9900. I suppose socketing one will be a bit of work though. As a small comment regarding the FPGA chips, the Spartan 3 series is getting a bit old, so for new designs I would recommend the Spartan 6. I have used many Spartan 6 boards, including cheap boards from China. Those can be had for about USD 30 (basic XC6SLX9 boards with pin headers suitable for this kind of application).

[HackMac]

I know the Spartan-3 is a bit older, but I intentionally decided to use the XC3S500E! It is one of the biggest I can probably solder by hand with its QFP208 package (rather than solder a ball grid array where all the pins are underneath). My layout uses all of the 116 available pins the core board delivers me. And additionally the core module was the nicest kit I found last year with the best cost-performance ratio.

So, I think it is not the badest decision.

[TheMole]

My contribution to this thread is going to be rather limited, but I do feel a need to say this: this is an awesome, AWESOME, project! I love reading the updates here.

[speccery]

I know the Spartan-3 is a bit older, but I intentionally decided to use the XC3S500E! It is one of the biggest I can probably solder by hand with its QFP208 package (rather than solder a ball grid array where all the pins are underneath). My layout uses all of the 116 available pins the core board delivers me. And additionally the core module was the nicest kit I found last year with the best cost-performance ratio.

So, I think it is not the badest decision.

 

 

Certainly it is not a bad decision at all. I guess I am just talking about the Spartan 6 since I like it and it is a powerful chip

 

To my understanding the only Spartan 6 in a hobbyist "friendly" TQFP package is the 144 pin version with 102 available I/O pins. The other package options are BGAs, which have plenty of pins but are probably going to be daunting to work with, both in terms of PCB routing and assembly.

 

But I do have a question: I believe many of the signals you are interfacing to are going to be relatively low frequency signals, right? The TMS9900 signals are super slow in terms of what the FPGA can do. So you could multiplex some signals together. It would reduce the number of I/O pins required on the FPGA, although on the other hand you would then have more external latches and buffers, and somewhat more control signals to worry about.

... and with that I would recommend for the first iteration to go with a chip with enough pins, and once things work then think about other options if necessary, so you are doing the right thing

[HackMac]

To my understanding the only Spartan 6 in a hobbyist "friendly" TQFP package is the 144 pin version with 102 available I/O pins. The other package options are BGAs, which have plenty of pins but are probably going to be daunting to work with, both in terms of PCB routing and assembly.

Quite right! :-)

 

The TMS9900 signals are super slow in terms of what the FPGA can do. So you could multiplex some signals together. It would reduce the number of I/O pins required on the FPGA, although on the other hand you would then have more external latches and buffers, and somewhat more control signals to worry about.

... and with that I would recommend for the first iteration to go with a chip with enough pins, and once things work then think about other options if necessary, so you are doing the right thing

Yes, you are right. I also tought in the same direction like you did. But...

The more on additional devices like latches, the more you have to bear in mind and you have to consider while using the FPGA adapter. I didn't wanted to define interfaces and things like protocols, special timings and so on (all needed to be documented also). My adapter hardware should be transparent as possible (to the side of TI-99/4A, between CPU and the rest of the console). I wanted to keep things simple as possible and as chep as possible. (Why obstructing things you can realize in VHDL?)

But I want to make some exceptions. Additional devices I want to attach to the FPGA (like LCD, key pad, SRAM, USB or what else), which aren't referring direct to the TI, should share some I/O pins. There will be an internal bus and dedicated device addressing signals. I also thougt if I really need that the internal bus is 16 bit width (multiplexed 8 bit data is sufficient or multiplexing addresses with data lines, etc.). But I decided to use a fast memory device with 10 ns access timing, so I can rely on most power when needed. I don't want to imitate TI by castrating powerfull hardware components.

 

By the way... We do not need to discuss my issues here on this thread. It is 'your' thread relating to the pipistrello FPGA board and your fpga99...

Edited October 24, 2016 by HackMac

[speccery]

Latest update video from last night.
Mostly this is about trying out a few games with sound, it seems the TMS9919 implementation code is working okay, although I'm pretty sure there are cases not supported by the hardware yet properly.

The other change is that I had only support for 16x16 sized sprites. It turned out it was easy to update that to support 8x8 sprites too, in the video the miner 2049er game uses that size for sprites. There are also other games, such as Star trek, which also go with the small sprites.

I tried to play Star trek, but it runs so fast on the TMS99105 that it is hard to understand what is supposed to get done before the game is over. I suppose it is rotate and shoot , but I'm not sure about which keys to use.

[Manic1975]

Do you plan to implement support for F19A?

[speccery]

Do you plan to implement support for F19A?

 

 

I guess you are asking F18A? The short answer is yes. I am in touch with Matthew180 about that. We need to bear in mind that F18A intellectual property is his. It is a great product, that has taken a lot of effort to create. I certainly don't want to erode the value of his work.

 

It is not my intention to replicate the F18A functionality, as far as the VDP development is concerned my interest initially was just to have a single video mode to be able to get some output and get Basic running. What I created for now is already more advanced than what I initially planned, as there are two graphics modes and sprites supported, albeit not perfectly.

 

Having said the above I have a couple of things that I will probably add to my VDP design, as these are easy to do:

• The ability to map the VDP memory to the address space of the CPU via a full speed 16-bit bus
• The ability to read back VDP registers (already done but untested)
• A raster interrupt and a register to read the current scanline of the VDP
• Some kind of 80 column mode, maybe just an extension of graphics mode 1 to 80 columns
• I am interested in trying out some sort of video playback. The hardware has a 256 color output support (RGB 332) so I was thinking of making a special video mode which would enable direct output of pixels from VDP memory. This could for example be done so that there was a table in VDP memory for each scan line (192 entries). Each table entry would be a pointer for 256 bytes of video data for that scan line. The FPGA still has quite a bit of internal memory available, so I could extend the VDP memory to 48K or even beyond that.

Edited October 28, 2016 by speccery

[speccery]

I decided that the retrochallenge competition is done for me. I am very happy with the results. I reached far more than I expected for, there is more functionality here than I expected, basically a full TI-99/4A. The retrochallenge lasts the month of October and with only one day left I don't think I will get much further than where I am now.

As I wrote in my hackaday "final summary" I want to say a big thank you to everyone here who has helped, commented, inspired and encouraged me with the project!

I hope this is just a starting point for something useful to the community.

 

And with that, I released the current version of the VHDL, C, and assembler code at Github:

https://github.com/Speccery/EP994A

[Stuart]

Well done Erik! Quite amazing what you've done there in just a month!

[Gary from OPA]

Just had to promote this amazing project on my gaming website, we have a small retro community, but since I have some experience with TMS99105 back in the hey-day of TI99 development, i just had to write-up about it:

http://www.maxconsole.com/threads/ti-99-4a-clone-using-tms99105-cpu.43052/

 

Hope, you like the article, any updates, corrections, please let me know.

 

Thanks again!

Edited October 31, 2016 by Gary from OPA

[speccery]

Just had to promote this amazing project on my gaming website, we have a small retro community, but since I have some experience with TMS99105 back in the hey-day of TI99 development, i just had to write-up about it:

http://www.maxconsole.com/threads/ti-99-4a-clone-using-tms99105-cpu.43052/

 

Hope, you like the article, any updates, corrections, please let me know.

 

Thanks again!

 

 

Thanks Gary, that is a very nice article. For me it was informative regarding your past work, It would be interesting to know more, both in terms of the software/OS development and the hardware projects. I suppose there is more information available somewhere? Just to make it blatantly obvious I have not even tried to look for additional material myself yet...

[speccery]

Well done Erik! Quite amazing what you've done there in just a month!

 

Thanks Stuart. It is your website and your very interesting projects described there that probably motivated me to start working on the TMS9900 stuff in the first place

[+jedimatt42]

Congratulations!

That is a phenomenal outcome! I am envious of your skills. I managed to program a gal16v8 this weekend... That (your board) is plenty faster than the Geneve as well... I love the way you describe it:

I believe I now have the world's fastest TI-99/4A compatible computer, running at 7 times the speed of the original while using a CPU from 1982[/size]

I hope that after you breath a little bit, you pick this back up and continue to explore the possibilities!

-M@

[Shift838]

Congrats.

[speccery]

Congratulations!

 

That is a phenomenal outcome! I am envious of your skills. I managed to program a gal16v8 this weekend... That (your board) is plenty faster than the Geneve as well... I love the way you describe it:

 

 

I hope that after you breath a little bit, you pick this back up and continue to explore the possibilities!

 

-M@

 

 

Thank you!

 

I think my next course of activity will be to attempt to get SD card support more functional, for both of my FPGA projects. Spent last night some time reading about the DSR interface and the way PABs should work. I have now direct access from PC to the memory of the TMS99105 and TI-99/4A memory extension, but I am still not able to save or load programs from Basic or anything else on the TI side for that matter. I haven't quite made yet my plan of attack, but I think I will write a super simple DSR first, which will just copy the PAB block from VDP RAM to a RAM block where the PC can access it, and then do the file I/O on the PC, then have the DSR write any results back to the VDP RAM, something like that to get started.

Edited November 2, 2016 by speccery

[+mizapf]

Will you be able to run test programs on your 99105, e.g. to check processing speed? This will be helpful once I start implementing the 99xxx emulation; I could send you some programs by mail that need to be loaded and run by your system.

[speccery]

Will you be able to run test programs on your 99105, e.g. to check processing speed? This will be helpful once I start implementing the 99xxx emulation; I could send you some programs by mail that need to be loaded and run by your system.

 

 

It is very easy for me to load programs to the cartridge memory. Flash ROM 99 images work too. If you send something that looks like cartridge, that is probably the easiest thing to run for me. I'd be happy to try out if you have something.

[speccery]

A brief update:

In case people here are into listening podcasts, my retro challenge project was discussed in the last episode of Retrocomputing Roundtable (which happens to be my favorite Podcast, been listening to it for the last couple of years).

http://rcrpodcast.com episode 140, around the 44 minute mark in the show.

 

Other than that I haven't had much time to work on the project, but I was able to advance on a few things:

- I now have what I call "transparent memory accesses" working, which means that the host PC can read and write the memory of the TMS99105 CPU without the CPU noticing. I have had this support from the start, but timing was not properly synchronized. So what I tended to do was to just keep the TMS99105 in reset while the RAM was loaded. Even with this I cannot directly access VDP memory currently from the PC, but I am not sure if that is actually needed. Basically the contents of the external SRAM are accessible, and that does include the scratchpad RAM too.

 

- I started to build the support for disk support device driver ROMs, so I implemented a new CRU space bit at >1100. When that bit is set, the FPGA maps a portion of the external RAM to >4000 (from 384K i.e. outside the area the CPU can normally access). This should enable DSR development for disk subsystem support. From the PC I can load code to 384K, which should enable rapid development. I have not tested this functionality yet, but the VHDL code is written. This work is applicable to my other FPGA design too, so if I get some kind of disk support working on one project I can directly copy it over to the other project too.

 

- My current setup hardware wise is not very pretty, since already early in the project I ran out of the header pins available on the FPGA development board. Due to that I have had wires running from the protoboard to the FPGA board's PS2 mouse and keyboard connectors, to gain access to four more FGPA pins. I have now been started to think and build a small alteration of the circuit, which would potentially enable to me to get rid of those 4 extra pins. That requires me to cut wires on the buffer board (connected to the pin headers) and solder some new wires in, but the idea here is that I will try to get this thing working without modifying the FPGA board itself or using the signals on the PS2 ports, thus only relying on the limited number of pins available on the pin headers. If that works I will design a simple board to plug directly into the pin headers, replacing the buffer board completely. And that would make this design repeatable by others, as you'd only need the FPGA board and this new board housing the TMS99105 and a bunch of buffers and other simple components.

Edited November 7, 2016 by speccery

[Sinphaltimus]

It is my hope that someday this project will be published with a parts list, files download and step by step instructions on setup and use.

Because I want one. LOL

The possibilities seem endless. Even if not a practical TI replacement, I think it could really shape up to be a supercharged development platform.

Like the "BIOS" feature discussed earlier, imagine being able to monitor and manipulate variables in your code in real time while the actual code is running on this project and seeing the changes take effect in real time without interrupting the processes. A super debugger for the ti. The ability to truly step through the native code on the TI (whether it'c BASIC, Extended BASIC, EA, Forth, RXB, etc......) as the program is running.


Ah... to dream. And wish. I should have been here 30 years ago..

[speccery]

I wrote a brief update at hack-a-day about my first adventures in the land of DSRs i.e. device service routines for disk support.

 

The ability of the FPGA system to provide direct access to the memory of the TI-99/4A clone is incredibly powerful when writing software. I wrote a short DSR in assembler (less than 200 lines at this point) but that already allows me to read the contents of PABs (peripheral access blocks) on the side of PC. My plan is to write a simple disk subsystem for my TMS99105 computer just by having the PC do all the heavy lifting, simply by having the DSR relay all the commands and data to the PC. I guess this would be similar to the HXD (not sure if that was the right acronym), except that my serial port runs at 230kbps and also relays other traffic (i.e. the PC keyboard button signals). When I have this working I should have a good understanding on how the disk subsystem works, and that should enable me to write the assembler code to deal with the SD card. At this early point I think I will probably keep the SD card FAT formatted, and I will have the DSR translate stuff between FAT files and the "way the TI handles files" - once I understand what the "way the TI handles files" actually means

[Sinphaltimus]

This is fascinating. It seems to me you are dissecting the TI-99/4a at a level (speed, performance, real time feedback, etc...) never before enjoyed by anyone. And we're watching unfold before our eyes. I subscribe.

I feel like, as soon as you get SD working, someone is going to take that, strip away the rest of the fpga board and create a simpler circuit design based on your DSR. This is incredibly huge if I'm following this correctly.

Edited November 8, 2016 by Sinphaltimus

[Tursi]

At this early point I think I will probably keep the SD card FAT formatted, and I will have the DSR translate stuff between FAT files and the "way the TI handles files" - once I understand what the "way the TI handles files" actually means

 

I've spent a ton of time on this, so feel free to look in Classic99's source, particularly the "FIADDisk" class to see how I dealt with various issues. Maybe good for inspiration, maybe good for a laugh, either way enjoy!

[speccery]

 

I've spent a ton of time on this, so feel free to look in Classic99's source, particularly the "FIADDisk" class to see how I dealt with various issues. Maybe good for inspiration, maybe good for a laugh, either way enjoy!

 

 

That's a great source of information, thanks! I took a look at the code last evening, and I start to understand some of the issues. What I gather is that the TI disk controller stores some metadata in addition to the actual file data, and in the emulator space that metadata is reflected in the TIFILES headers. FiadDisk.cpp is a great source indeed! The file system seems to make a distinction between "raw" files and files constructed from records, as opposed to the way for instance Unix style file systems work, where the application can manage records etc and the file system just deals with flat files.

 

I got the first PABs moving from TI to PC, but I was pretty tired last night (while waiting for a late night conference call) and I did not make much progress as I was creating way too many bugs in very straightforward DSR code...