One of the outliers in the home computer wars of the early 1980s was the Texas Instruments TI99/4A. It may not have had the games library of its rivals and its TMS9900 processor may not have set the world on fire with its registers-in-RAM architecture, but its range of support chips included one whose derivatives would go on to delight subsequent generations. If you had an MSX or one of the 8 or 16-bit Sega consoles, the TMS9918A graphics chip provided the architecture that sat behind Sonic in his adventures.
A few decades later, there is still significant interest in this classic chip. [J.B. Langston] has an RC2014 retrocomputer, and wishing to play MSX demos upon it, has created a TMS9918A-based graphics card for the RC2014 bus. The success of the board hinges upon a circuit showing how to interface the 9918A to SRAM, and since it is mapped to the same ports as its MSX equivalent it should in theory be compatible with Z80 demos written for that platform. He’s already achieved some success with that aim, as can be demonstrated by the video we’ve placed below the break of the Bold MSX demo running on an RC2014.
The RC2014 has gained a significant following in the retrocomputer scene, and has appeared here many times. We reviewed an early model in 2016. Surprisingly though the TMS9918A has only appeared here once, as part of a homebrew 6809-based system.
I wish there were a modern equivalent, something that could support a decent resolution and a modern display interface (i.e. not VGA or composite) for the kind of projects that show up here. LCDs are great and wonderful, but sometimes you want something that shows “on the big screen”
You can buy/use digital 24-bit-parallel to DVI conversion ICs. You just have to tweak your pixel clock to some integer divisor of 27MHz (or does it have to be a divisor of 13.5MHz?) to get a receiver to decode it as 480i.
But what jockmurphy is saying that he wants a chip with a ram interface and all the pixel clock and parallel to DVI conversion circuits in one. And if possible some hardware acceleration features as well. So you can make a board like this one: one big chip, some ram, a connector, and some buffer logic, and hey presto: 480p on your screen. If I calculated right, you could fit 888×480 pixels with 24-bit RGBi into one 256Kx8 ram. Although I would rather go for less colorspace, in order to have double buffering. I think with 16-bit RGB (665), you could fit one screen in 104K, so two screens in 256K.
However, you would also need some bankswitching scheme, because the Z80 obviously cannot address more than 64K at one time.
And all of that in a handy 40-pin package.
and hardware sprites and/or scrolling. pretty please?
Alright, who ordered the pony?
Maybe something like this from FTDI?
http://www.ftdichip.com/EVE/EVEProducts.htm
Alright, addresses TFT displays only as far as I can see, but apart from that, it gets pretty close…
s_henning: Too bad it’s made by FTDI, so no one in their right mind would use it.
s_hennig: As near as I can tell, standard parallel digital video ports like that one (pixel clock, 24 bit RGB, H/V sync) can usually just be connected to a parallel-to-DVI sender without any particular complexity.
The hard part is coming up with a modeline that the EVE can draw (apparently requiring either an external clock, or is strictly some integer divisor of 60MHz) and that an external HDMI sink will accept.
and refresh/move 1/10 of the contents every 16ms thanks to anemic CPU, brilliant. There is a reason 8/16bit computers stuck to 240p.
Hell, even some Playstation 2 games downgraded to 240p. Look up Genji – Dawn of the Samurai, 2005, 300 MHz, 6 Gflops, and resolution straight from NES.
So use the methods used in the past: tiles, sprites, blitter, hw line drawing.
Yes, if you want to do hires high frame rate applications you are going to need a lot of CPU and Video hardware, why do you assume that is what I mean. I am talking about applications that have graphical UIs, or lower frame rate applications.
@retepv I suspect you mean a 565 color space and not 665 ;)
There’s this http://codehackcreate.com/archives/category/projects/f18a
@s_hennig Yeah the EVE is a very cool chip, but as you point out it is LCD only and I said :
> LCDs are great and wonderful, but sometimes you want something that shows “on the big screen”
The TMS9918 (and successors) were a bit of a revelation. You got an acceptable resolution, text mode, graphics modes, sprites, etc and it was pretty easy to interface with using a variety of of CPUs. There is just nothing like that anymore. The closest you can get is to use an FPGA, which is nowhere near as simple
There are some “more” modern equivalents like the GameDuino that uses a Xilinix Spartan 3 FPGA and outputs VGA but unfortunately it is SPI which isn’t supported with old CPUs.
The problem arises with the bottlenecks you create when making larger resolution outputs.
It’s easy enough to change the timing to something like WXGA which most LCD screens support as long as you don’t increase the actual resolution too much. One pixel to the CPU may be a 4×4 solid block of pixels to the screen.
At the end of the day the CPU has to write updates to the video controller and an old Z80 maxes out at about 1 MIP.
There are faster Z80s now (20 MHz) that get up to about 5 MIPs but they introduce a lot of other constraints that lead to lots of square chips rather than DIP which really takes away the retro aesthetic.
The old computers solved the CPU to Video bottle neck with a number of tactics. The first was programmable characters so that one CPU update write represented an 8×8 block of pixels. Then next was hardware scrolling and even larger tiles of 32×32 pixels. Pallet switching fell into the scheme somewhere to.
Eventually there was hardware sprites but these very limited.
That’s why the older games were mostly tile based strollers. The scrolling was supported in hardware with offset registers and the tiles were programmable characters. That took a lot of CPU load away and left the CPU with mostly doing the action elements in software sprites.
A lot more can be done today but then you have added programming complexity as the complexity of the video interface increases. Retro programmers like to interface to the video either directly to RAM or through registers.
Old Video chips like the 6845 had less than about 30, 8 bit registers. The chip in this example will have many more but still wont be encroaching too much on the available 16 bit address buss width of the CPU.
The real challenge of designing a modern video interface for theses old CPUs it to make something that uses a similar CPU to video interface layout that is a natural extension of the old chips so that programmers are comfortable with it.
If you have a look around you will find that there are many different interface that have been designed to address these challenges.
Some are done as memory mapped pixels using a CPLD and a lot of RAM and hence a lot of address space and low performance due to the CPU load bottleneck.
Some are done with FPGA and have advanced features (like the GamDuino which even has an inbuilt CPU) but they move too far away from what the programmers are familiar with.
The example in this article is perhaps close to the best you can achieve with an old Z80 and old video chip that probably maxes about at about 1 or 2 MHz.
Two quick notes:
1) I called for modern video output, so no VGA
2) MIP is not the singular of MIPS (Millions of Instructions Per Second).
And as a bonus, the 4MHz Z80 operated at something closer to 0.5MIPS han 1.
https://en.wikipedia.org/wiki/Instructions_per_secondThe Z80 runs at 1 MIPS (Millions of Instructions Per Second)
Oops a bit of cut and pasted ended up at the end of that last line :/
So what you’re saying is that you want antique technology, but you want it to meet modern expectations. Good luck with that. There’s a reason we didn’t have multi-megapixel displays with 8-bit computers.
No, I want the modern equivalent. I am not asking for 4K video, but 480p or the like. With the FTDI FT81x I can drive an 800×600 TFT from an Arduino, and it is not the only chipset out there that can do that. Is it so unreasonable to wish for the same kind of thing but over HDMI?
I think you are hyberbolizing without actually thinking it through…
jockmurphy: not hyperbolizing at all – I just couldn’t tell what you meant from your comment – you never mentioned HDMI or DVI, so I thought by “VGA or composite”, you were saying 480i wasn’t sufficient. Now I understand you were referring to the physical interface. Thank you for clearing it up.
But it is worth pointing out that 720p isn’t even a megapixel (0.74). Assuming an FT81x like chip where you can have sprites, maybe tiles, and a rich set of graphics primitives; that doesn’t seem so unreasonable. This is what I mean, you leapt to the assumption that I was talking about 1080p or higher when I said “Reasonable resolution”
jockmurphy: I’m not sure what you mean by “on the big screen”. Aren’t 6′ LCDs big enough for you? I don’t recall having ever seen a CRT larger than 36″, so you can’t be talking about CRTs. So you’re talking about 4K projections, maybe?
On the big screen is (at least here I am from) a euphemism for a TV screen (or movie screen depending on context). I am just talking about 480p (or maybe 800×600) with an HDMI interface. The FTDI FT81x will let me do that with a TFT, I would just like the equivalent for HDMI.
It doesn’t matter what the output format is. That’s just some HDL code in a FPGA.
What matters is how many pixels there are and how fast the CPU can update them.
Put simply, you can’t get a 1 MIPS Z80B to do anything useful with a 800×600 bit-mapped screen, in fact a bit-mapped screen of that size wont even fit into the Z80s entire address space. It’s 480kB at 256 color and the Z80 can only address 64kB. The most address space I have seen allocated to Video RAM is 16kB.
So it all comes back to the problems I first mentioned.
Which is why I want something like the TMS99x8. You aren’t painting the screen and it isn’t coming from the main address space. The chip had it’s own video memory and you wrote commands into the chip.
It also has a lot to do with what you define as “useful”. I suspect your definition and mine may be different
jockmurphy so what you want is essentially Pee Zero receiving draw commands over serial interface
The TI-99/4A Megademo https://www.youtube.com/watch?v=ZhSUhE03XFw
The TI does Bad Apple https://www.youtube.com/watch?v=FsxQ2PyVF9w
Enhanced FPGA drop in compatible version of the TMS99xxA VDP. http://codehackcreate.com/ Since it outputs VGA and doesn’t use the original composite or component output it’ll directly replace the 9918A (NTSC composite) 9928A (PAL composite) and 9928A (PAL component) versions. A 9919A (NTSC component) version was apparently never produced.
The non-A version was used in the TI-99/4. That chip had no lower case text and (IIRC) one less video mode. Unfortunately neither VDP had a true bitmap mode. The Yamaha V9938 and V9958 support most of the 99xxA modes plus add many additional capabilities, including true bitmap modes.
Please people, stop adding to my STDbus wishlist / design queue. JLCPCB is already getting paid weekly by me, with my 4MB memory expansion, NCR53c94 SCSI, and PDP-11 boards… (STDbus is the RC2014 of 1980’s industrial computing)
The ColecoVision console and Coleco ADAM computer used the TMS9928A, a close relative of the 9918A with a Z80 main code processor. The Adam may died unfortunately, but the ColecoVision was the first home console with capabilities that actually resembled arcade consoles of the era.
The brilliant 6809 homebrew isn’t the only build using a TMS9918a on hackaday – my own self-build is based on a 6502 but uses this excellent VDP.
https://hackaday.io/project/5789-6502-homebrew-computer-on-breadboard