810 replies to this topic

[matthew180]

Back in 2007 I started getting into FPGA's and I bought a devboard.  Needless to say, it sat on my workbench until early this year when I started messing with it again in earnest.  Like everyone else, hooking my real 99/4A up to something like a modern VGA monitor has always been very desirable, so I started researching possible solutions.

The first thing I looked at (like a lot of other people) was to use the 9929 which has component output.  But there was still the need to have an external circuit to convert the component video to VGA, and all the circuits I found were *really* complex.  Plus there was the problem of the 9929 not being drop-in replaceable with a 9918A.

The other solution I was kicking around was making a frame buffer of sorts that would decode the composite video coming out of the 99/4A and build up a VGA frame, which would then output to a monitor.  It just did not seem like the thing to do though, so I scratched that idea too.

Another option was to use an FPGA to reproduce the functionality of the 9918A entirely.  Without knowing an HDL (hardware description language) like VHDL or Verilog, or anything about FPGA's, this also seemed like a complex task.  However, I already dropped the cash on the devboard, and I wanted to learn FPGA's and VHDL, so I decided I would give it a shot.

I'm setting up a web site to document the project in detail, so I'll spare the grueling details here.  I made good progress until about April when life put the project on hold.  However, I do have a functional circuit that is currently only missing sprites (and a few other things.)  Let me sum up since I seem to be rambling.

I'm working on an FPGA based video chip that will be a pin compatible drop-in replacement for a real 9918A.  Since I have a ton of power available to me, I'm also taking the opportunity to "fix" a few things, like having all 32 sprites on the same line at the same time, and eliminating the "access window" problem, i.e. you can write to the VDP at full speed all the time.  My initial project entry explains all the features, but I'll reproduce it here to promote feedback and generate excitement. :-)

These are the goals that I think I can manage in the 1.0 version:
    * Be pin compatible with the original TMS9918A VDP, i.e. a direct replacement in any existing computer
    * Be 100% compatible in functionality
    * Support standard VGA monitors (currently 640×480, but the final 1.0 will run at 800×600)
    * Add a 9938 compatible 80-column mode
    * Add a few additional video resolutions to better support remaking arcade games
    * Increase the color palette to 512 colors
    * Remove the “access window” limitations for full-on high speed access to VDP RAM all the time
    * Increase VDP RAM to at least 512K, but probably 1MB in the end
    * Allow all 32 sprites on a single horizontal scan line
    * Add flags to flip sprites horizontally and vertically

Some additional features I’m kicking around are:
    * Support a dedicated hardware mouse and USB/PS2 keyboard
    * Provide a single-cycle 32-bit Mersenne Twister random number generator
    * Dual-screen output (great for 2-player head-to-head games)
    * Add horizontal and vertical scroll registers
    * Provide hardware support for virtual screens with scrollable playfields
    * A true bitmap layer
    * Enhanced tile-map that supports larger pattern tables, colors, flip x and y, etc.

What is Working:
    * Original 256×192 displayed in 2x (512×384) on a 640×480 VGA monitor
    * All 4 video modes: Graphics I, Graphics II, Multicolor, Text
    * 512 color palette
    * Full speed CPU interface (no delays due to access windows)
    * 16K VDP RAM using the FPGA’s block RAM
    * Physical drop-in replacement (via a socket) of the original 9918A

Todo:
    * Implement sprites
    * Add undocumented hybrid graphic modes
    * Add the 9938 compatible 80-column mode
    * Change VRAM to use an external SRAM instead of the FPGA’s block RAM
    * Change to 800×600 base resolution instead of 640×480
    * Design, order, and build the prototype circuit board

Anyway, here is the link to the main project page: FPGA Based 9918A

Matthew

Oh a picture or two (or five) as well. :-)

Attached Files

•  wip1.jpg   110.79K   106 downloads
•  wip2.jpg   134.36K   135 downloads
•  9-bit_color_test.jpg   61.18K   149 downloads
•  9-bit_ToD.jpg   67.86K   141 downloads
•  9-bit_yin-yang.jpg   59.22K   113 downloads

[Opry99er]

Wow... I'm speechless!  I can't wait to see the website.  

[matthew180]

I'm also planning on demoing the F18A at the TI Faire, so anyone who wants to see it first hand before it is actually done (which probably won't be until 2011) will have to make it to the Faire. :-)

Matthew

[Opry99er]

*So you have this thing plugged into the 9918 socket in these photos and you are running the startup screen?  
*How would the new color pallettes be accessed via the programming languages?  
*If I were to send 28 SPRITEs across the screen (inline) in an XB program as it stands now, would they all appear?

This is really quite fascinating. =)

[matthew180]

Opry99er, on Tue Sep 7, 2010 9:00 PM, said:

*So you have this thing plugged into the 9918 socket in these photos and you are running the startup screen?

I removed the 9918A from its socket and plugged in a cable that I made that connects to my FPGA devboard.  I'm running more than the startup screen, I'm running the whole computer just fine, the only thing I can't do is *see* sprites (yet.)

The ribbon cable I made has all the connections necessary to communicate with the computer in the same way as the original 9918A, i.e. the 8-bit data bus, csr, csw, and mode signals, reset, the interrupt output, and the two frequencies generated by the 9918A for the host computer, which consist of a 3.579545MHz CPUCLK and 447.443KHz GROMCLK.  In the 99/4A the CPUCLK signal is not used, but the 99/4 used it to drive the sound chip.  In the 99/4A the 447.443KHz is used to drive the sound chip, so having that frequency accurate is critical to producing the correct sound from the computer.  The rest of the 9918A's pins are for driving the video output and interfacing with the dynamic RAM chips that make up the VRAM, neither of which are needed, so the original DRAM chips just sit idle (and use less power!)

The FPGA is then, essentially, *the* video chip for the computer.  The FPGA is taking over all functionality, producing the VGA output, providing the VRAM, etc.

Opry99er, on Tue Sep 7, 2010 9:00 PM, said:

*How would the new color pallettes be accessed via the programming languages?

The new colors would be an extension that I make up. :-)  Actually I'd really like to work out some of the enhancements at the TI Faire with anyone who wants to talk about it.  Like the 9938 and 9958, the number of VDP registers will be increased and there will probably be some way to set up the palette.  The default will be the stock colors, but you will then be able to programatically change them!  Having more than 16 simultaneous colors will probably only be available in the new graphic modes.  Remember, first and foremost is 100% reproduction of the original 9918A functionality so the F18A can be dropped into any existing computer that uses the 9918A... Think about it, the 99/4A, ColecoVision, MSX1, etc. all able to output VGA. :-)  (I'm also considering HDMI output, but that is a lot more complex than VGA, so that will come later.)

Opry99er, on Tue Sep 7, 2010 9:00 PM, said:

*If I were to send 28 SPRITEs across the screen (inline) in an XB program as it stands now, would they all appear?

Yes. :-)

Again, the FPGA *is* the VDP implemented with real hardware.  As far as the computer is concerned the 9918A is still in the system.  The 4-sprite per line limit is a limitation of the 9918A, not XB or the computer.  The 9918A only runs at 10MHz and takes a few microseconds to access the DRAM, so there is only so much it can do in the 32uS (microseconds) that make up a horizontal scan line.  However, I'm running the FPGA at 100MHz (it can go faster too), and I can access the FPGA's internal block RAM in 1 clock, i.e. 10nS (*nanoseconds*), so basically the FPGA could access memory about 200 times in the same time the 9918A can make 1 VRAM access.

But, even at 100MHz, it will still be somewhat of a challenge to get all 32 on the same scan line, but it is possible and I will do it (I have not implemented the sprites yet, so I'm talking in the future tense.)

I will be documenting all this on the CHC (code hack create) site in the near future for anyone wanting grueling details.

Matthew

[retroclouds]

Very, very cool sir! I knew you had something cooking, just didn't know what  

Looking forward seeing how this further develops.  

[sometimes99er]

Very cool.

Edited by sometimes99er, Sun Nov 7, 2010 3:25 PM.

[retroclouds]

Just remembered that in the MSX scene someone tried to design a new enhanced VDP as a FGPA for the MSX.
It seems the project has stalled, but it still makes an interesting read.

You can read about it here.

[humeur]

Very very good work.


Jean Louis

[matthew180]

retroclouds, on Wed Sep 8, 2010 4:35 AM, said:

Just remembered that in the MSX scene someone tried to design a new enhanced VDP as a FGPA for the MSX.
It seems the project has stalled, but it still makes an interesting read.

You can read about it here.

Nope, I didn't see that thread.  I did find a lot of other similar projects on the MSX forum, but none ever seemed to actually get to a production phase.  A lot of people want to do it, but no one ever finishes.  It is not a trivial project, but you don't really realize that until you get into it.  I was the same way, I had a very ambitious feature list at first, but I scaled way back and decided to just replace the original chip first, with a few enhancements.  Even a product that does get produced is no guarantee, like the 1Chip MSX.  They had hundreds of pre-orders for their second batch (at $250 each), but it never happened.

I have been reluctant to announce for the same reasons, i.e. I didn't want to bring it up and then not finish.  But the chip is functional, so it is more than vapor-ware, and I wanted to get some feedback and thoughts from people.

Matthew

[matthew180]

sometimes99er, on Wed Sep 8, 2010 12:38 AM, said:

Yes, this is very cool.

Will it initially (at power up) be doing stuff like
1) A maximum of 4 sprites per horizontal scanline.

Well...  I was not going to limit the sprites per horizontal line.  I didn't see that as not being compatible.  Is there a reason you would want that limitation?  Everyone always complains about only having 4 sprites per line, I never heard of anyone embracing it.

Matthew

[Opry99er]

I like the idea of no limits....but some software may rely on that limitation.  

This is a TERRIBLE example, but it's the only one I can think of--- In Pac-Man, the manual says something like (and I'm paraphrasing) "if all 5 ghosts are inline, they get a 'magic power' and one will disappear!!". This is, of course, turning a hardware limitation into a "feature" of the game--- and won't make much difference--- but it gets me wondering if some software relies on the limitation for program execution.  

All things considered, I would LOVE to eliminate the 4 SPRITE per scanline limitation. Can't wait to see this thing develop!!!

[sometimes99er]

matthew180, on Wed Sep 8, 2010 7:40 AM, said:

Well...  I was not going to limit the sprites per horizontal line.  I didn't see that as not being compatible.  Is there a reason you would want that limitation?  Everyone always complains about only having 4 sprites per line, I never heard of anyone embracing it.

No big deal. I think I love the TI-99/4A as is (was) - with all its limitations, challenges and possibilities. If I developed something, I'd like to know that it runs on most machines - and that includes a 4 sprite per scanline limitation.

Some games uses sprites to mask out other sprites - that would be both XB and assembler ones. The latest demo from Retroclouds uses the first 12 sprites to mask out incoming sprites.

Edited by sometimes99er, Wed Sep 8, 2010 12:04 PM.

[djpubba]

I'd definitely buy four of these. One for my TI994a, one for my ColecoVision, one for my Coleco Adam and one for my MSX.

If you market it to Coleco and MSX users as well, you could probably triple your sales.

FWIW, there are some arcade games that use this chip as well - Baby Pac-Man and Cliffhanger (laserdisc).

Edited by djpubba, Wed Sep 8, 2010 11:53 AM.

[matthew180]

sometimes99er, on Wed Sep 8, 2010 11:32 AM, said:

matthew180, on Wed Sep 8, 2010 7:40 AM, said:

Well...  I was not going to limit the sprites per horizontal line.  I didn't see that as not being compatible.  Is there a reason you would want that limitation?  Everyone always complains about only having 4 sprites per line, I never heard of anyone embracing it.

No big deal. I think I love the TI-99/4A as is (was) - with all its limitations, challenges and possibilities. If I developed something, I'd like to know that it runs on most machines - and that includes a 4 sprite per scanline limitation.

I totally agree.  One of the biggest decisions to make is how far to take the "upgrades" and such, since we have so much power available to us now.  For example, the choice of how much to expand the color palette.  We *could* do 24-bit color, that is not a problem for the FPGA, however that is *way* beyond anything that matches with the 99/4A and its capability.  I chose 9-bit color because 3-bits per pixel rounded out nicely, and I needed enough color space to get close to the original colors.

There will be enhancements, however they will not interfere with the original functionality.  I promise that any software you write for a real 99/4A will run the same with a F18A plugged in.

As for the 4-sprite per line limit, I would like the default to be that there is no limit.  Then if you really wanted to limit the sprites, I could provide a register where you could set the limit per line...  Does that sound like an acceptable solution?  I think most software would benefit from not having the limit vs. finding it an advantage.  But, that's why I'm asking, I would like to get the thoughts of others on decisions like this.

Matthew

[matthew180]

djpubba, on Wed Sep 8, 2010 11:50 AM, said:

I'd definitely buy four of these. One for my TI994a, one for my ColecoVision, one for my Coleco Adam and one for my MSX.

Sweet.  Now that's some good motivation. :-)  *Sales* are not my ultimate goal, but selling the product provides the means to make more projects (a necessary evil I suppose.)  I didn't know the Adam used the 9918A too!  I already tested the F18A in my MSX1 and it worked great.  I actually used the MSX to test the video modes since MSX BASIC gives you access to all 4 modes very easily.  I wish the 99/4A had a BASIC like the MSX.

djpubba, on Wed Sep 8, 2010 11:50 AM, said:

If you market it to Coleco and MSX users as well, you could probably triple your sales.

FWIW, there are some arcade games that use this chip as well - Baby Pac-Man and Cliffhanger (laserdisc).

I'm absolutely keeping the Coleco and MSX users in mind too.  But they have been made the promise of a new video chip so many times that I figured I'd wait until I was closer to production before announcing it to those communities.  Interesting that some coin-ops used the 9918A, I didn't know that.

Matthew

[retroclouds]

matthew180, on Wed Sep 8, 2010 12:08 PM, said:

...
As for the 4-sprite per line limit, I would like the default to be that there is no limit.  Then if you really wanted to limit the sprites, I could provide a register where you could set the limit per line...  Does that sound like an acceptable solution?  I think most software would benefit from not having the limit vs. finding it an advantage.  But, that's why I'm asking, I would like to get the thoughts of others on decisions like this.

Matthew

You could add a (hardware-)switch for controlling the F18A behaviour. I mean something like pure TMS9918 mode or enhanced mode.
That way the TI-99/4A user can decide how he wants it. The question is how far would one go to emulate the original TMS9918 ?
Like for example the PAL version, where you have a 50 instead of 60 sync.

[GroovyBee]

matthew180, on Wed Sep 8, 2010 12:08 PM, said:

As for the 4-sprite per line limit, I would like the default to be that there is no limit.  Then if you really wanted to limit the sprites, I could provide a register where you could set the limit per line...  Does that sound like an acceptable solution?

I think that starting in backwards compatible "legacy mode" is the best solution. If the game/application writes an unlocking sequence to a particular register then the chip goes into enhanced mode. I'd opt for a sequence of writes to rule out spurious writes to the video chip by legacy software. If an unlocking byte is written out of sequence the chip stays in legacy mode.

[matthew180]

retroclouds, on Wed Sep 8, 2010 12:18 PM, said:

The question is how far would one go to emulate the original TMS9918 ?
Like for example the PAL version, where you have a 50 instead of 60 sync.

Well, I already planned on having support for both. :-)  The only difference between the PAL and NTSC chips is the interrupt period and the video output.  The 9918 and 9929 have the same 256x192 resolution, and I don't have to worry about the output side of things since it is all standard VGA.  I was thinking about having one of the new registers control the interrupt period, so you could select 50 or 60.  Now that I think about it, I could easily expand this to offer other interrupt periods as well.

Matthew

[matthew180]

GroovyBee, on Wed Sep 8, 2010 12:33 PM, said:

I think that starting in backwards compatible "legacy mode" is the best solution. If the game/application writes an unlocking sequence to a particular register then the chip goes into enhanced mode. I'd opt for a sequence of writes to rule out spurious writes to the video chip by legacy software. If an unlocking byte is written out of sequence the chip stays in legacy mode.

But then only new programs written in assembly would benefit, where as having the default set to no sprite limit means legacy games like MunchMan and such are improved.  Plus, in XB you would not be able to set the enhanced mode, so Owen would be out of luck.

I know what your are saying though, and I don't think the final solution will be cut and dry.  To support the 9938 80-column mode means I'm already going to have enhancements in place without activating them.

Matthew

[GroovyBee]

matthew180, on Wed Sep 8, 2010 1:22 PM, said:

But then only new programs written in assembly would benefit, where as having the default set to no sprite limit means legacy games like MunchMan and such are improved.  Plus, in XB you would not be able to set the enhanced mode, so Owen would be out of luck.

I suspect that legacy games that used flicker or didn't allow more than 4 sprites per line will still operate the same as they always did with the new video chip. Some might crash or behave unexpectedly too.

I'm not familiar with XB but does it have a POKE command? If so, you could still activate the enhanced mode using that (I'm assuming POKE has free reign over the memory map). Failing that a small assembly language routine could be called.

Quote

I know what your are saying though, and I don't think the final solution will be cut and dry.  To support the 9938 80-column mode means I'm already going to have enhancements in place without activating them.

In my mind, if it starts up in legacy mode you'll save yourself a ton of tech support headaches.

[marc.hull]

matthew180, on Tue Sep 7, 2010 6:50 PM, said:

Back in 2007 I started getting into FPGA's and I bought a devboard.  Needless to say, it sat on my workbench until early this year when I started messing with it again in earnest.  Like everyone else, hooking my real 99/4A up to something like a modern VGA monitor has always been very desirable, so I started researching possible solutions.

The first thing I looked at (like a lot of other people) was to use the 9929 which has component output.  But there was still the need to have an external circuit to convert the component video to VGA, and all the circuits I found were *really* complex.  Plus there was the problem of the 9929 not being drop-in replaceable with a 9918A.

The other solution I was kicking around was making a frame buffer of sorts that would decode the composite video coming out of the 99/4A and build up a VGA frame, which would then output to a monitor.  It just did not seem like the thing to do though, so I scratched that idea too.

Another option was to use an FPGA to reproduce the functionality of the 9918A entirely.  Without knowing an HDL (hardware description language) like VHDL or Verilog, or anything about FPGA's, this also seemed like a complex task.  However, I already dropped the cash on the devboard, and I wanted to learn FPGA's and VHDL, so I decided I would give it a shot.

I'm setting up a web site to document the project in detail, so I'll spare the grueling details here.  I made good progress until about April when life put the project on hold.  However, I do have a functional circuit that is currently only missing sprites (and a few other things.)  Let me sum up since I seem to be rambling.

I'm working on an FPGA based video chip that will be a pin compatible drop-in replacement for a real 9918A.  Since I have a ton of power available to me, I'm also taking the opportunity to "fix" a few things, like having all 32 sprites on the same line at the same time, and eliminating the "access window" problem, i.e. you can write to the VDP at full speed all the time.  My initial project entry explains all the features, but I'll reproduce it here to promote feedback and generate excitement. :-)

These are the goals that I think I can manage in the 1.0 version:
    * Be pin compatible with the original TMS9918A VDP, i.e. a direct replacement in any existing computer
    * Be 100% compatible in functionality
    * Support standard VGA monitors (currently 640×480, but the final 1.0 will run at 800×600)
    * Add a 9938 compatible 80-column mode
    * Add a few additional video resolutions to better support remaking arcade games
    * Increase the color palette to 512 colors
    * Remove the “access window” limitations for full-on high speed access to VDP RAM all the time
    * Increase VDP RAM to at least 512K, but probably 1MB in the end
    * Allow all 32 sprites on a single horizontal scan line
    * Add flags to flip sprites horizontally and vertically

Some additional features I’m kicking around are:
    * Support a dedicated hardware mouse and USB/PS2 keyboard
    * Provide a single-cycle 32-bit Mersenne Twister random number generator
    * Dual-screen output (great for 2-player head-to-head games)
    * Add horizontal and vertical scroll registers
    * Provide hardware support for virtual screens with scrollable playfields
    * A true bitmap layer
    * Enhanced tile-map that supports larger pattern tables, colors, flip x and y, etc.

What is Working:
    * Original 256×192 displayed in 2x (512×384) on a 640×480 VGA monitor
    * All 4 video modes: Graphics I, Graphics II, Multicolor, Text
    * 512 color palette
    * Full speed CPU interface (no delays due to access windows)
    * 16K VDP RAM using the FPGA’s block RAM
    * Physical drop-in replacement (via a socket) of the original 9918A

Todo:
    * Implement sprites
    * Add undocumented hybrid graphic modes
    * Add the 9938 compatible 80-column mode
    * Change VRAM to use an external SRAM instead of the FPGA’s block RAM
    * Change to 800×600 base resolution instead of 640×480
    * Design, order, and build the prototype circuit board

Anyway, here is the link to the main project page: FPGA Based 9918A

Matthew

Oh a picture or two (or five) as well. :-)

Now that is wicked awesome   You say your board is going to be drop in compatible with just a VGA connection out ?  Excellent, I have been trying to get my hands on a TIM and this seems to be an updated version.  Are you going to implement the full 9938/58 or just the text mode?  If doing more would you mind explaining the VDP addressing/paging for the extra memory ?  Thanks and sign me up for one.

[Tursi]

Great to see you announce this!!

If I had a choice, I'd like to see the 4-sprite on a line limit active by default if it's there at all, but I only have one project that used it deliberately (to mask out sprites on certain lines), Classic99 survived for a very long time not supporting the limit without any real issues, too. I think that only software which expects the limit will be written for it, so a switch to enable it probably is not very useful.

That said, enhancing existing titles that flicker when you don't want them to is nice, too. Perhaps we could release a hacked GROM that lets you select certain VDP modes from the master title page?

[Willsy]

He he! This kicks so much butt it's just not funny! Put me down for some!

Mark

[matthew180]

marc.hull, on Wed Sep 8, 2010 5:41 PM, said:

Now that is wicked awesome   You say your board is going to be drop in compatible with just a VGA connection out ?  Excellent, I have been trying to get my hands on a TIM and this seems to be an updated version.  Are you going to implement the full 9938/58 or just the text mode?  If doing more would you mind explaining the VDP addressing/paging for the extra memory ?  Thanks and sign me up for one.

I'm not sure what a "TIM" is, but I'm not basing my design on anything other than the original 9918A.  I'm not sure if I'm going to expand it to the 9938/58 for a few reasons, the main on being I don't like the way Yamaha implemented some things, and they left out other features (like vertical scroll registers.)

I was planning on supporting the 9938's 80-column mode based on a conversation with Tursi about useful enhancements.  I just wanted to do things my own way, but he pointed out that since the Geneve uses the 9938, and the 80-column mode would let the 99/4A use a lot of the tools designed for 80 columns, that at least implementing the 9938's 80-column mode would be the most important.

Addressing of larger VDP RAM would be in the form of an expansion of the VDP address register.  This is how the 9938/58 do it as well (I think.)  Currently the address register is 14-bits and takes two writes (1-byte each) to set up.  I was initially thinking I would simply add another "page" register that is 8-bits and it would default to 0, thus maintain original functionality.  You could then change the page register for a total of 256 16K-pages of VRAM, or about 4MB of addressable linear memory.  However, I don't think I will ever have more than 1MB, and 512K would be more realistic.  I'm not sure though, I'll have to go see what the super MSX video boards could do.

Matthew