TI-99/4A with a Pipistrello FPGA board

[speccery]

On the memory use for the 32K space, since you are splitting it into 4K zones already, you might want to take a look at using the switching scheme used by the SAMS card (you would have to extend the latching scheme of the 74LS612 it uses by two bits to use the entire 64MB space though, as it currently maxes out at 16MB). That will keep you compatible with software designed to see that extra space and it will allow you to take advantage of the memory in a seamless fashion.

 

 

Thanks Ksarul - in fact that is what I have been trying to do. At this point it is very simple, in addresses >5000 to >501F there are sixteen paging registers, 16-bits each, out of which bottom 14 bits are used. To my understanding this is how SAMS works too. I don't have CRU support yet, but I will be adding it shortly, in order to implement the same enable bits as the SAMS card uses (currently mapping is enabled via memory mapped control registers, but that will disappear when I have CRU support done). I have been using Thierry's page at http://www.unige.ch/medecine/nouspikel/ti99/superams.htm as the source of information, is there something else I should be looking at too?

[+Ksarul]

You have the right source--and you are on a really good path! I like this idea. . .

[speccery]

Well that was a bunch of work! I posted on update to hackaday.

https://hackaday.io/project/13119-ti-994a-memory-extension-with-pipistrello-fpga

 

I now have (finally) a pretty cool way to load software onto the TI memory expansion and cartridge memory area. I have a PC application and a whole bunch of stuff in the FPGA which enable the PC to read and write the memory of the TI (both cartridge memory area and memory extension). So I can easily load cartridges or debug software by loading new software versions in seconds. I moved the cartridge ROM storage from the FPGA's block RAMs to external SDRAM and simultaneously expanded banking support so that now it supports 128 pages of 8K in the 6000..7FFF region, switchable using the extended basic method of writing to the cartridge area. So there is now support for 1 megabyte of cartridge ROM. In other areas of memory "regular" 4K memory paging works.

 

This actually is the first time ever that I have way to load and save software on the TI using something else than a cassette (which I used as a kid - I don't have even that anymore)....

 

Now that this works, I will probably want to also move GROM contents next to SDRAM. And then implement ROM in SDRAM to the 4000..5FFF region to be able to write DSRs / device drivers to get support for the SD card going. I wait for the moment I could save something to "DSK1" and load it back...

[+mizapf]

Just as a side note - is it only me who finds the name "Pipistrello" somewhat hilarious?

[Sinphaltimus]

*THUD*

[speccery]

Just as a side note - is it only me who finds the name "Pipistrello" somewhat hilarious?

 

 

I live in Finland. In Finnish the word "Pipi" means sick or ill and I found it very amusing in the beginning - I suppose I got used to that since...

[+mizapf]

German "Pipi" - English "wee-wee"

 

To make things worse:

 

German (dialectal) "strullen / strullern" - English "to take a leak"

 

---

 

There's always a risk that a name may be or sound like something else in another language in the most funny way. Mitsubishi once had a brand name "Pajero" that translated to something embarrassing in Spanish. Currently, Mazda commercials use the words "zoom-zoom", which at first outright puzzled me, because in a German-dubbed commercial, having a child whisper "zoom-zoom" is likely to be heard as "summ-summ", which is the beginning of a children's song "Summ, summ, summ, Bienchen summ herum" (hum, hum, hum, little bee hum around) - and why should I think of bees when I see a Mazda?

Edited September 5, 2016 by mizapf

[+Lee Stewart]

Everyone but I probably knew that “Pipistrello” is bat (the flying mammal) in Italian.

 

...lee

[speccery]

Everyone but I probably knew that “Pipistrello” is bat (the flying mammal) in Italian.

 

...lee

 

 

I had to look it up back in the day...

[Sinphaltimus]

You can call it poopstrello for all I care. This is shaping up to be an amazing upgrade.

 

All the reading on this and I have one question.

 

Does this increase program memory in any way beyond 32k?

 

It seems to me the 64MB is being used for roms and groms etc..

 

Which is amazing and great don't get me wrong, just wondering about program ram as well.

[speccery]

I guess there is a hardware and software answer to your question about program RAM.

 

This may be obvious: On the hardware side the TMS9900 microprocessor has a 16-bit address space. As such it can directly only access 64K memory at any one time. The way to go beyond 64K is to use memory paging. The 64K address space is divided into 4K pages, and the programmer can choose where in the 64 megabyte RAM space each 4K page actually is. So the program can change what the processor sees in each 4k page slot. However, the TI-99/4A is designed in such a way that 32K i.e. half of the address space is already reserved and not available for memory expansion. To be more precise the hardware in the console already occupies 16K which is not available to be reused or paged with external hardware. Of the remaining 48K address space the design convention is that 32K is for memory expansion, 8K for cartridge port and 8K for device driver ROMs. The cartridge address space and device driver ROM space is actually visible on the expansion bus and those areas could be paged, but that would work somewhat against the usual conventions and would not work well with existing software.

 

Which brings us to software: in order to use any memory beyond the regular 32K, one has to resort to some sort of paging, which means dedicated software support for a given paging system. That's why I am trying to follow the SAMS spec, in order to have something that would be recognised by existing software.

 

Thus with my FPGA setup a program can use 64 megs as program RAM, but the program(s) needs to be aware of that setup and use the paging unit accordingly to gain access to that memory.

 

In practice the 64 megs is so much compared to the TI's speed, that even with the maximum theoretical speed it would take a long time for the CPU to just touch each memory location. The external bus accesses memory at 1MHz, so in ideal conditions it would take about one minute to touch the memory just once. In practice the CPU would need to do a lot other things too, so we would be talking about many minutes.

 

I hope that makes sense - and answers your question...

[Sinphaltimus]

I hope that makes sense - and answers your question...

 

Absolutely it does. Thank you. And your answer is better than I anticipated. I'll have more things to learn when I have one of these for sure. I also understand that programs written in this manner would have a very limited audience. However; it gives a programmer so much more power to code for themselves. My plan to actually use the TI along with other audio gear for a stage performance could benefit from more ram as long as I know what I'm doing when I code the programs I need. And I don't, but I will.

 

Thanks for being another amazing 99er.

[speccery]

 

My plan to actually use the TI along with other audio gear for a stage performance could benefit from more ram as long as I know what I'm doing when I code the programs I need. And I don't, but I will.

 

Thanks for being another amazing 99er.

 

 

Thanks. I am curious - what would be the role of the TI in your planned setup?

 

As it so happens, the Pipistrello board does have a stereo output jack. It is a very simple setup hardware wise, relying on the FPGA on doing very high speed sigma delta modulation for digital to analog conversion. That's a fancy way of saying there is a capacitor and resistor connected to a pin of the FPGA and the audio output jack. By toggling the output pin in a suitable way a DA conversion can be done, at a quality that is probably very nice at least on retrocomputer standards. It would be straightforward to setup some memory aside for audio sample buffers, and have the FGPA pull out samples and output them autonomously. The TI could write the waveforms to the sample buffers and control the whole thing. I don't know if this is something of interest to you in your application.

 

A quick general comment about the possibilities here: the FPGA on the Pipistrello board is pretty huge in terms of its logic and memory capacity. My rough estimate is that it could implement all of the circuitry in the console probably four to five times, maybe more. I implemented earlier an enhanced ZX Spectrum on a LX9 FPGA (which is maybe one quarter of the capacity of the LX45 FGPA on the Pipistrello). That implementation took about 40% of the capacity of that FPGA (including the Z80 CPU as a soft core). I also ran on the same board the Scramble coin op game (the circuit has two Z80 cores and a whole bunch of other circuitry, occupying something like 75% of the FPGA if I remember properly). Right now all the circuitry I've so far coded takes about 3% of the capacity of the FPGA on the Pipistrello. So there is a LOT of room for logic and circuitry here. Having said that, my intention is to keep the circuitry within the realm of what would fit on the LX9 chip, since that chip is available in a more "home builder" friendly 144 pin quad flat pack package, and it would not be that hard to make a custom expansion board based on that chip.

Edited September 6, 2016 by speccery

[RickyDean]

 

 

Thanks. I am curious - what would be the role of the TI in your planned setup?

 

As it so happens, the Pipistrello board does have a stereo output jack. It is a very simple setup hardware wise, relying on the FPGA on doing very high speed sigma delta modulation for digital to analog conversion. That's a fancy way of saying there is a capacitor and resistor connected to a pin of the FPGA and the audio output jack. By toggling the output pin in a suitable way a DA conversion can be done, at a quality that is probably very nice at least on retrocomputer standards. It would be straightforward to setup some memory aside for audio sample buffers, and have the FGPA pull out samples and output them autonomously. The TI could write the waveforms to the sample buffers and control the whole thing. I don't know if this is something of interest to you in your application.

 

A quick general comment about the possibilities here: the FPGA on the Pipistrello board is pretty huge in terms of its logic and memory capacity. My rough estimate is that it could implement all of the circuitry in the console probably four to five times, maybe more. I implemented earlier an enhanced ZX Spectrum on a LX9 FPGA (which is maybe one quarter of the capacity of the LX45 FGPA on the Pipistrello). That implementation took about 40% of the capacity of that FPGA (including the Z80 CPU as a soft core). I also ran on the same board the Scramble coin op game (the circuit has two Z80 cores and a whole bunch of other circuitry, occupying something like 75% of the FPGA if I remember properly). Right now all the circuitry I've so far coded takes about 3% of the capacity of the FPGA on the Pipistrello. So there is a LOT of room for logic and circuitry here. Having said that, my intention is to keep the circuitry within the realm of what would fit on the LX9 chip, since that chip is available in a more "home builder" friendly 144 pin quad flat pack package, and it would not be that hard to make a custom expansion board based on that chip.

Could you implement a Geneve?

[Sinphaltimus]

 

 

Thanks. I am curious - what would be the role of the TI in your planned setup?

 

I wrote a Musick program, it runs the sounds too slow but I plan to rewrite it optimized when I'm done with ny game Zombi.

 

The TI is going to produce the sounds and music I will feed in to effect peddals. This will be the background noise/fill for larger performance. July 5th 1998, ehem, I meant 2017.

Edited September 6, 2016 by Sinphaltimus

[+acadiel]

:thumb:

[speccery]

Could you implement a Geneve?

 

 

I haven't checked the specs of the Geneve closely, but the short answer is yes. Once somebody builds the standard TI-99/4A into an FPGA, going to a Geneve from there would not be hard

[speccery]

 

I wrote a Musick program, it runs the sounds too slow but I plan to rewrite it optimized when I'm done with ny game Zombi.

 

The TI is going to produce the sounds and music I will feed in to effect peddals. This will be the background noise/fill for larger performance. July 5th 1998, ehem, I meant 2017.

 

Sounds cool! What development environment are you using? Assembly?

[+Lee Stewart]

It might be nice to fully implement the >8000 – >83FF region on the 16-bit bus (instead of the current >8300 – >83FF).

 

...lee

[RickyDean]

 

 

I haven't checked the specs of the Geneve closely, but the short answer is yes. Once somebody builds the standard TI-99/4A into an FPGA, going to a Geneve from there would not be hard

Well would those specs be most likely covered by the Mess/Mame emulation, can those files and detailed information be incorporated into a FPGA package, as I progress in my knowledge, I was wanting to start delving, but at my age, it might not come to fruition near as fast as what you already have established, I going to sign up on your project.

[+mizapf]

Well would those specs be most likely covered by the Mess/Mame emulation...

 

One of the notable differences between FPGA and software is that you have a serial processing in a program, while an FPGA can exploit hardware parallelism ... as far as I know, I don't know much about HDL. Thus, there is a considerable way to go between C++ and HDL (see also https://en.wikipedia.org/wiki/Hardware_description_language). The source codes may be useful to understand the basic behavior, of course.

 

BTW, a Geneve is a very different beast than the TI-99/4A, with the advanced 9995 processor, mapped memory etc.

[Sinphaltimus]

 

Sounds cool! What development environment are you using? Assembly?

I wish. Extended basic. I just started reading the fundamentals of ti994a assembly language. I got up to the chapter about the mini memory module and had to stop because I was afk. I'll pick it back up shortly but for now I want to finish my Zombi game first, also XB. Edited September 6, 2016 by Sinphaltimus

[speccery]

It might be nice to fully implement the >8000 – >83FF region on the 16-bit bus (instead of the current >8300 – >83FF).

 

...lee

 

 

Yes, so true. Unfortunately not possible except by modding the console itself or by moving the whole thing to an FPGA or by redesigning otherwise the motherboard. In an FPGA implementation all memory would probably would be of full speed and accessed as the 16-bit memory. And at much higher clock speed.

[Tursi]

 

 

I haven't checked the specs of the Geneve closely, but the short answer is yes. Once somebody builds the standard TI-99/4A into an FPGA, going to a Geneve from there would not be hard

 

Exactly, like Mizapf points out, they are very different machines. The Geneve has a different CPU, different memory architecture, different VDP. They are compatible machines, but one is not a small update of the architecture.

[Sinphaltimus]

"or by moving the whole thing to an FPGA"

 

Ooooooo...