Jump to content

Photo

TMS9900 CPU core creation attempt


136 replies to this topic

#126 Sinphaltimus OFFLINE  

Sinphaltimus

    River Patroller

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

Posted Thu Feb 1, 2018 12:52 PM

We are all very excited about all of your projects. I for one would love to be able to reproduce your FPGA TI-99/4a as a stand-alone unit. I have an empty console case and keyboard just waiting for it. :) And am following ET-PEB with bated breath....



#127 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 346 posts

Posted Sat May 19, 2018 12:27 PM

I'll also note in this thread that if you're interested in FPGA based TMS9900 stuff, there is an update in pnr's TMS9902 VHDL thread. I've setup a repository with a little explanation at: https://github.com/Speccery/breadboard



#128 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 346 posts

Posted Sat Sep 22, 2018 2:26 PM

Wow its been a long time without updates! The TI Treff is on-going in Germany, I did not have the time to go there, but inspired by the event - and also by the fact that after my house move my work room is beginning to be in good shape - I booted both version of my FPGA TI-99/4A. I was happy to see that both FPGA boards still work. The other one had the TMS99105 daughterboard plugged in, while the other was running my VHDL TMS9900 core. I spent some time working on the latter, fixing a couple of reset related problems - and discovering a bug. Apparently even from BASIC my CPU claims the 1*-1 equals 1. Well whatever, the negative numbers are just a nuisance :)

 

https://hackaday.io/...pu-core-in-vhdl



#129 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 346 posts

Posted Mon Sep 24, 2018 1:47 PM

Yesterday and today I fixed in total four bugs in the FPGA CPU, these are documented in two blog postings, here is a link to the latter one. Three bugs with flag handling and one major bug in the hardware divider fixed.

 

https://hackaday.io/...a-cpu-bug-fixes



#130 TheMole ONLINE  

TheMole

    Dragonstomper

  • 807 posts
  • Location:Belgium

Posted Mon Sep 24, 2018 3:23 PM

Always love reading about your progress.



#131 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 346 posts

Posted Wed Oct 3, 2018 1:48 PM

Had today a little time to tinker my TI-99/4A FPGA clone. Strictly speaking I was now working on the TMS99105 version, but since this design shares most of the VHDL code with the full FPGA implementation, I can work on either for as long as I am not working on the FPGA CPU core itself.

 

Anyway what I have decided to try to do is to improve compatibility and fix all the bugs I know about. The Megademo has been very useful in this regard, I found two bugs in the design, both on my TMS9918 implementation. I had already once decided not to complete my TMS9918 VDP since Matthew's F18A is already a feature complete version (with many additional features as I am sure people here would know), but had to revisit that decision since as long as the FPGA system is not correctly running all the software I throw at it I cannot know if something not working is due to the CPU or the VDP or something else.

 

One of the missing features is the multicolor mode (providing 64x48 resolution with 15 colors per pixel). The rotozoom portion of the demo uses this mode, and was displaying garbage. But no more - now it is fixed. I remain amazed how very small changes to the VHDL code create new features. Adding the multicolor mode amounted to only minor changes to pattern fetch address generation, and the pixel shifter. Overall perhaps 10 lines of code were added/changed.

 

And now the rotozoom runs - and it runs fast on the TMS99105! Overall the whole demo runs very nicely, that is - until it encounters the "sine wave split screen" where the system just halts. Now that I have found the Megademo source code and located finally the root cause for the halt: my VDP implementation does not yet generate the COINC status, I had completely forgotten that I did not built it. The COINC flag is set whenever two sprites have overlapping pixels and reset every time the VDP status register is read. 

 

On a real TMS9918 silicon the generation of this flag is easy since it has dedicated hardware to support drawing four sprites per scanline and it is easy to set the flag if any two sprite shifters are active simultaneously (or this is how I assume it works). My TMS9918 implementation is different, I have only one sprite generator which renders to a scanline buffer. The hardware is run in a loop and can render all 32 sprites on a single scanline. In fact I think I could support many more sprites, probably at least 128 per scanline. Here is the problem: due to the hardware being reused it needs special additional support to detect sprite overlap. Currently when it is writing pixels to the line buffer it is doing just that - writing. It does not care what is already in the buffer, the pixels overlaid by sprites just get overwritten. Sprites are rendered from lowest priority to highest, so that the highest priority sprites are rendered last and will be visible on top of any other sprites or characters. Alas, this "writing only" cannot work when you need to know if a pixel has been written to the linebuffer by character data or a previous sprite. So I will need to revise the state machine so that there will be an additional per pixel flag memory that is read when a sprite is rendered to detect the scenario when there are two sprite writes to the same pixel. This in turn means that in the state machine now will need additional states to perform the reads prior to writes. According to the TMS9918 data sheet the COINC flag is set even for transparent sprites, so the flags will need to be read from and written to even if the actual pixels are not visible. What a pain, and has to wait for another day and more time.

 

Interestingly the source code of megademo (splitscreen3_demo.a99) has bogus comments - the comments lead one to believe that scanline position detection is done with the 5th sprite flag in the VDP, but in reality the code is reading the COINC flag. I already support the 5th sprite flag, so this would not have been a problem, and I initially thought the bug on my FPGA hardware the Megademo freezing was due to something outside the VDP, but now I know that the CPU is polling the COINC flag in busy loop. As it never gets raised in my FPGA design the demo just freezes...


Edited by speccery, Wed Oct 3, 2018 1:52 PM.


#132 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,943 posts
  • Location:Denmark

Posted Thu Oct 4, 2018 9:10 AM

Sorry for the bogus comments. I was trying various techniques, and I found that using coinc to detect the scan line was slightly faster than using 5th sprite, but I seem to remember that it was not as reliable.

 

Regarding the sprites, I think you need a scanline buffer for the sprites alone. You need to initialize the buffer with a value like >ff that is not one of the 16 colors, and then write the sprites in order of the highest priority sprite first. When you get a collision you have the coinc bit and when/if you draw the 5th sprite you have that bit and you stop. The 9918A draws the buffer to the screen in the following line cycle, which accounts for the y coordinate being off by one.



#133 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 346 posts

Posted Fri Oct 5, 2018 6:56 AM

Thanks @asmusr. No problem with the comment being old - this happens to the best of us. And thanks for putting in the time and energy to create such an amazing demo in the first place!

I probably did not write very clearly - I have had the scan line buffer in there from day 1 of my TMS9918 implementation. You’re right that’s needed for sprites, but it is even more importantly required for scanline doubling for VGA output. In fact my scanline buffer is has double the horizontal resolution - when TI graphics output is written to it each pixel is processed twice to have a 512x192 resolution, which is scanline doubled to 512x384 fitted into a 640x480 VGA screen.

The y-coordinate off by one feature I incorporated when I built the sprite engine... already in 2016 :)

#134 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,943 posts
  • Location:Denmark

Posted Fri Oct 5, 2018 9:17 AM

I wasn't very clear either.  :) My suggestion was to have two scanline buffers: one for the sprites alone and another combined buffer where you write the character data first and then write the data from the sprite buffer.


Edited by Asmusr, Fri Oct 5, 2018 9:18 AM.


#135 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 346 posts

Posted Sun Oct 7, 2018 5:26 AM

I uploaded two videos, the latter one is still uploading as a write this, demonstrating the Megademo running on the FPGA system using TMS99105 CPU and then with my FPGA CPU core. The FPGA CPU video goes through the demo twice, once at running with a lot of wait states, bringing execution speed close to the original TI-99/4A, and then running at zero wait states, or around 23x the CPU speed.
 
Here is a link to the TMS99105 version. This is a special compilation of the megademo, there are no actual code changes but I edited the controller.a99 file so that the video starts with the multicolour demo, I had problems running this phase of the demo for obvious reasons - the multicolour mode was not implemented...

 

What is new here is that I now added to my TMS9918 code the ability to detect sprite coincidence, so the demo no longer gets stuck in the splitscreen3_demo.a99 phase. Timing behaviour is different though, as can be seen in the video.

 

I guess one of the next challenges for me then would be to make a new demo phase, which would take advantage of the increased processing speed.



#136 speccery OFFLINE  

speccery

    Moonsweeper

  • Topic Starter
  • 346 posts

Posted Sun Oct 7, 2018 5:50 AM

FPGA CPU version of the video got uploaded. This is the original version of the demo, not some custom one.

 

updated:

After a break I continued to tweak the VHDL, in an attempt to get the splitscreen3_demo.a99 working more smoothly. I just added registers so that the COINC and 5TH sprite flags are set pending and actually flagged at the end of a scanline, as opposed to immediately when they occur. This way there would be some CPU time between two consecutive settings of the flags. The changes maybe helped a little, but the sine curves still are jerky.


Edited by speccery, Sun Oct 7, 2018 10:17 AM.


#137 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sun Oct 7, 2018 11:48 AM

Awesome. Wahnsinn. Congrats to the Progress. I can report about some progress as well, at least I was creating some Unit Tests for TIcode99 on the weekend.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users