TMS9900 CPU core creation attempt

[Omega-TI]

Ya know, since almost anything is possible in FPGA, I'm surprised no one has created a true 16 bit quad-core TI-99/4A in emulation with the ability to access more memory in a, "what could have been" scenario. Something like that would make TI BASIC move faster for sure!

[+TheBF]

Ya know, since almost anything is possible in FPGA, I'm surprised no one has created a true 16 bit quad-core TI-99/4A in emulation with the ability to access more memory in a, "what could have been" scenario. Something like that would make TI BASIC move faster for sure!

 

 

Multi-core would be a big stretch from what is and not trivial to implement.

Speccery's faster CPU would already make TI BASIC run 23X faster :-)

 

A 32 bit version of the 9900 would be nice to have, but it would mean a re-write of everything unless one could think of how to make it backwards compatible.

 

It goes without saying that TI-BASIC could be much faster if it had been written differently.

If you ever played with Commodore 64 BASIC you are shocked at how much faster it is than TI BASIC.

[Omega-TI]

 

If you ever played with Commodore 64 BASIC you are shocked at how much faster it is than TI BASIC.

 

Is comparing against TI BASIC really fair?

 

I wonder... if you had two similar programs on the C64 & TI with Extended BASIC, and both systems loading a 20K program from disc at the same time, which would execute first?

[+mizapf]

 

If you ever played with Commodore 64 BASIC you are shocked at how much faster it is than TI BASIC.

 

If you ever got to know C64 BASIC, you are shocked how spartan a BASIC can be. Everything comes at a cost, and we have our subprograms. OK, there is much more, like the GPL-based BASIC interpreter.

[+TheBF]

 

If you ever got to know C64 BASIC, you are shocked how spartan a BASIC can be. Everything comes at a cost, and we have our subprograms. OK, there is much more, like the GPL-based BASIC interpreter.

 

Yes GPL and 8 byte floating point numbers when you only need a native 16 bit integer much of the time.

 

Yes C64 was pretty bare bones, but it performs faster than our BASIC even with a 1MHz 8 bit processor. It was embarrassing back in the 80's when I showed my friends.

[Willsy]

Yep. And if you think Commodore Basic is fast try BBC BASIC on the BBC Model B.

 

Wow!

[Willsy]

(BBC Model B is also a 6502)

[+mizapf]

 

It was embarrassing back in the 80's when I showed my friends.

 

I usually embarrassed them back when we talked about floppy speeds. (OK, unless they were using a turbo floppy.)

Edited December 21, 2017 by mizapf

[+OLD CS1]

For the talk about a quad-core 9900 in FPGA, how about implementing a GPL CPU in FPGA. Figure a way to tie that into the system and BOOM, no more interpreted GPL.

[JamesD]

...

 

A 32 bit version of the 9900 would be nice to have, but it would mean a re-write of everything unless one could think of how to make it backwards compatible.

...

Actually, 32 bit extensions wouldn't be that difficult if there is at least 1 unused opcode available.

Then that could be the prefix for 32 bit opcodes, any other unused opcodes could be used for the most common 32 bit opcodes if there are any.

[Willsy]

I was thinking... For a 32-bit TMS9900, what to do with the upper 16 bits of the registers. It seems to me that the best thing to do, at least in terms of maintaining 16-bit compatibility is to put the upper 16 bits of each register at workspace pointer + 32 bytes. So, if WS=0xA000 then bits 0 to 15 of R0 are at 0xA000, bits 0 to 15 of R1 are at 0xA002, as normal. Upper bits of R0 are at 0xA020 and upper 16 bits of R1 are at 0xA022 and so on.

 

That way, the original 16-bit workspace register layout is maintained in *both* 16 and 32-bit modes, potentially opening up the possibility of being able to change between 16 and 32-bit mode on the fly with a machine code instruction.

 

Put THAT in yer pipe and smoke it

[JamesD]

I was thinking... For a 32-bit TMS9900, what to do with the upper 16 bits of the registers. It seems to me that the best thing to do, at least in terms of maintaining 16-bit compatibility is to put the upper 16 bits of each register at workspace pointer + 32 bytes. So, if WS=0xA000 then bits 0 to 15 of R0 are at 0xA000, bits 0 to 15 of R1 are at 0xA002, as normal. Upper bits of R0 are at 0xA020 and upper 16 bits of R1 are at 0xA022 and so on.

 

That way, the original 16-bit workspace register layout is maintained in *both* 16 and 32-bit modes, potentially opening up the possibility of being able to change between 16 and 32-bit mode on the fly with a machine code instruction.

 

Put THAT in yer pipe and smoke it

The one problem I see with putting the upper 16 bits at a 32 byte offset, is when you go to a 32 bit RAM interface,

A mode switch might be in order.

Boot in compatibility more and have a 32 bit mode switch.

 

[JamesD]

 

Yes GPL and 8 byte floating point numbers when you only need a native 16 bit integer much of the time.

 

Yes C64 was pretty bare bones, but it performs faster than our BASIC even with a 1MHz 8 bit processor. It was embarrassing back in the 80's when I showed my friends.

8 bytes was definitely overkill when other machines were using 4 or 5 bytes.

They could have dropped to 6 without anyone complaining about accuracy.

Maybe a 4 byte mantissa with sign, and 2 bytes for exponent just for speed of calculation.

I know that's overkill for exponent, but I think you'd want to avoid byte accesses.

 

The C64 uses a Microsoft BASIC, which isn't really that fast.

It was written more with the memory footprint and ease of implementation in mind than speed.

[speccery]

I'm delighted to see updates from other people in this thread too! Thanks guys, will take the time to read. But right now I want to provide the link to hack a day where there is an update and a link to a youtube video:

 

https://hackaday.io/project/20826-tms9900-compatible-cpu-core-in-vhdl/log/72139-stand-alone-booting-capability

 

I'm on my way on making my FPGA based TI-99/4A capable of operating without a host computer. So far I've used the host computer to load the ROMs and GROMs to the memory space of the system. But no more! Now the FPGA has the ability to after reset read a 256K block of memory from its serial configuration flash memory (which is a whopping 16 megabytes in size), enabling my FPGA system to boot without support from host PC.

Edited December 30, 2017 by speccery

[+Ksarul]

Nice! This is a wonderful project you have going!

[speccery]

Multi-core would be a big stretch from what is and not trivial to implement.

Speccery's faster CPU would already make TI BASIC run 23X faster :-)

 

A 32 bit version of the 9900 would be nice to have, but it would mean a re-write of everything unless one could think of how to make it backwards compatible.

 

It goes without saying that TI-BASIC could be much faster if it had been written differently.

If you ever played with Commodore 64 BASIC you are shocked at how much faster it is than TI BASIC.

I was thinking about the TI Basic discussion yesterday, and also about the idea of making a GPL co-processor to speed up Basic execution. I kind of went full circle in my thought process. Ive been (also in this thread) thinking about building a GPL processor to really speed up Basic execution to whole new level. But then I started to think that is that actually necessary, if the CPU speed can be pushed higher wed get a reasonably fast Basic with higher CPU throughput alone? I also started to think how much GPL software there is, and would it be worthwhile to spend the time to create a GPL co-processor. What if we just rewrote the Basic completely in assembler (or even C) and used things like the wonderful FinalGROM99 to give us enough memory space for the code of the Basic interpreter? I know that it would be a non-trivial task to write, but then efficiency would be fixed for good and overhead gone.

 

Around this point in the thought process two things came to mind: although there is probably not that much GPL software [that needs to run faster], it is true the that the Basic interpreter is a core component of the TI-99/4A experience. Same goes for extended Basic [and derivatives] in particular. Im not sure that there are other major programs running in GPL that would benefit from a boost in speed - please let me know what you think The other side is the point of efficiency, I just like things to run optimally, and having the TMS9900 to push through the GPL interpreter to run Basic just is not efficient.

 

And here we have it - it again started to make more sense to me to have a GPL co-processor in hardware. It would be cool if it could be implemented one GPL opcode at a time, so that the system would fallback to standard TMS9900 software interpretation if the opcode is not yet implemented yet.

 

Comparing GPL co-processor and Basic rewrite also comes back to compatibility and effort - I believe making a [partial] GPL co-processor is not that much work, rewriting the entire Basic would invariably lead to compatibility problems and is probably MUCH more work than doing a GPL co-processor. At least for me

 

I did not know that the TI Basic uses 8 byte representation for floating point math. Seems indeed like another way to maximize computational load... Well I guess that with a hardware GPL co-processor that would not matter much, the GPL execution speed would probably be at least 100x faster than with a standard console.

Edited December 31, 2017 by speccery

[Asmusr]

I have been wondering if the F18A GPU could be used as a GPL co-processor? Operations on VDP RAM, like scrolling, could certainly run much faster.

[Tornadoboy]

Would it be a big task to also add RGB output to it of the type compatible with arcade monitors? I've often thought about using a 994/a as a hardware platform for making a custom coin operated arcade game, which in theory shouldn't be too tough since things like the coin input switches and stuff could just be wired to keyboard keys, and given the speed of this upcoming FPGA it would work all the better for games akin to the ones of the 80's. Also while it wouldn't be coin operated I've always thought Microsurgeon would be great to play in a Robotron-style cabinet with two joysticks.

Edited December 31, 2017 by Tornadoboy

[speccery]

Would it be a big task to also add RGB output to it of the type compatible with arcade monitors? I've often thought about using a 994/a as a hardware platform for making a custom coin operated arcade game, which in theory shouldn't be too tough since things like the coin input switches and stuff could just be wired to keyboard keys, and given the speed of this upcoming FPGA it would work all the better for games akin to the ones of the 80's. Also while it wouldn't be coin operated I've always thought Microsurgeon would be great to play in a Robotron-style cabinet with two joysticks.

 

The FPGA is easy to setup to drive many types of signals, so driving RGB would be easy, at least for as long as it not an interlaced display. I guess for an arcade display there would be no need for it to be interlaced. The FPGA is currently driving VGA so it’s already driving RGB signals out. A TI based cabinet would be cool

[speccery]

I have been wondering if the F18A GPU could be used as a GPL co-processor? Operations on VDP RAM, like scrolling, could certainly run much faster.

I guess you could use the F18A GPU for GPL acceleration, but in that case there probably would be some issues: the GPU cannot access the CPU’s memory space, so the CPU would need to be heavily involved. As I understand it the results of GPL instructions would be stored in VDP memory, scratchpad and potentially extended memory. The other issue is that to my understanding the GPU has only 2K of dedicated memory outside the standard 16K VDP memory (correct me if I’m wrong there), so there probably would not be enough space for a full GPL interpreter.

[matthew180]

Correct, the F18A currently has 2K of GPU RAM aside from the 16K of VRAM. A future firmware update *might* increase that by another 2K to 4K.

[RXB]

Correct, the F18A currently has 2K of GPU RAM aside from the 16K of VRAM. A future firmware update *might* increase that by another 2K to 4K.

GROM 0 has the GPL Interpreter and also the other OS Menu system along with IO for CRU and DSR interface.

 

GROM 0 is 6K that runs from >0000 to >17FF

 

Personally I like the SOB by Gary Bowser that added a better Menu system and fixed some bugs in GROM 0.

 

Also the SOB GROM 0 was 8K not 6K in size.

Edited January 1, 2018 by RXB

[Manic1975]

Is there anything new about TI99/4a FPGA core?

[Sinphaltimus]

This is the last known update - https://hackaday.io/project/20826-tms9900-compatible-cpu-core-in-vhdl/log/72139-stand-alone-booting-capability

[speccery]

Yep that is the last update. For better or worse I am multitasking between multiple hardware and software projects, right now mostly on the ET-PEB, but also testing the icestorm open source FPGA development toolchain... The ET-PEB is related to this project in many ways, including getting my head around designing boards that actually can be manufactured...