Jump to content

Photo

TMS9900 CPU core creation attempt


171 replies to this topic

#101 --- Ω --- OFFLINE  

--- Ω ---

    Hexacorerunner

  • 13,924 posts
  • Location:82.102.25.76

Posted Tue Dec 19, 2017 5:58 PM

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!



#102 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 988 posts
  • Location:The Great White North

Posted Wed Dec 20, 2017 8:57 AM

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.



#103 --- Ω --- OFFLINE  

--- Ω ---

    Hexacorerunner

  • 13,924 posts
  • Location:82.102.25.76

Posted Wed Dec 20, 2017 9:47 AM

 

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?  :?



#104 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,612 posts
  • Location:Germany

Posted Wed Dec 20, 2017 1:12 PM

 

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.



#105 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 988 posts
  • Location:The Great White North

Posted Wed Dec 20, 2017 10:04 PM

 

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.



#106 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,100 posts
  • Location:Uzbekistan (no, really!)

Posted Thu Dec 21, 2017 7:36 AM

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

Wow!

#107 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,100 posts
  • Location:Uzbekistan (no, really!)

Posted Thu Dec 21, 2017 7:37 AM

(BBC Model B is also a 6502)

#108 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,612 posts
  • Location:Germany

Posted Thu Dec 21, 2017 7:58 AM

 

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

 

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


Edited by mizapf, Thu Dec 21, 2017 7:58 AM.


#109 OLD CS1 OFFLINE  

OLD CS1

    >OLD CS1█

  • 6,097 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Thu Dec 21, 2017 11:32 PM

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.



#110 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,461 posts
  • Location:Flyover State

Posted Fri Dec 22, 2017 2:56 AM

...

 

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.



#111 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,100 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Dec 22, 2017 4:24 AM

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  :-D



#112 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,461 posts
  • Location:Flyover State

Posted Fri Dec 22, 2017 10:03 AM

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  :-D

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.
 



#113 JamesD OFFLINE  

JamesD

    Quadrunner

  • 8,461 posts
  • Location:Flyover State

Posted Fri Dec 22, 2017 10:22 AM

 

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.



#114 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 359 posts

Posted Sat Dec 30, 2017 1:15 PM

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/...ting-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.   :grin:


Edited by speccery, Sat Dec 30, 2017 1:16 PM.


#115 Ksarul ONLINE  

Ksarul

    Quadrunner

  • 5,271 posts

Posted Sat Dec 30, 2017 1:48 PM

Nice! This is a wonderful project you have going!



#116 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 359 posts

Posted Sun Dec 31, 2017 12:13 AM

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 by speccery, Sun Dec 31, 2017 12:19 AM.


#117 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 3,113 posts
  • Location:Denmark

Posted Sun Dec 31, 2017 6:04 AM

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.



#118 Tornadoboy OFFLINE  

Tornadoboy

    Star Raider

  • 72 posts

Posted Sun Dec 31, 2017 8:08 AM

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 by Tornadoboy, Sun Dec 31, 2017 8:13 AM.


#119 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 359 posts

Posted Sun Dec 31, 2017 11:12 AM

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 :)

#120 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 359 posts

Posted Sun Dec 31, 2017 11:24 AM

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.

#121 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,626 posts
  • Location:Castaic, California

Posted Sun Dec 31, 2017 6:27 PM

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.



#122 RXB OFFLINE  

RXB

    River Patroller

  • 3,583 posts
  • Location:Vancouver, Washington, USA

Posted Sun Dec 31, 2017 11:52 PM

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 by RXB, Sun Dec 31, 2017 11:53 PM.


#123 Manic1975 OFFLINE  

Manic1975

    Chopper Commander

  • 156 posts
  • Location:Croatia

Posted Wed Jan 31, 2018 11:51 AM

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



#124 Sinphaltimus OFFLINE  

Sinphaltimus

    River Patroller

  • 2,521 posts
  • Distracted at the Keyboard
  • Location:Poconos, PA

Posted Wed Jan 31, 2018 12:24 PM

This is the last known update - https://hackaday.io/...ting-capability



#125 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 359 posts

Posted Thu Feb 1, 2018 12:07 PM

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...






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users