Slashdot Mirror
TMS9918A Retro Video Chip Reimplemented In FPGA, With VGA Out
acadiel writes "Matthew H from the AtariAge.com TI-99/4A forum has finalized a design of a TMS 9918A replacement (with VGA out) for classic computer systems such as the ColecoVision, TI-99/4A, SpectraVision, MSX1, SpectraVision 128, and Tomy Tutor Home computers. This hardware project replaces the native video controller on these classic systems and enables them to have VGA output for the first time." (It's just under $100 to order one.)
there's actually quite a community for these old systems, and a lot of people who don't enjoy playing on emulators, or who want to recapture the original experience.
it's pretty cool that they've managed to do this, though I might prefer a different connection type... my current TV does have a VGA input, but I doubt my next one will.
Except that you're still upconverting a signal from 240p to 480p. By going directly to VGA you're at least getting a crisp 480p image (ie: 640x480). And no, doing this after the signal has been produced at the composite outputs is not going to be as pretty.
Except HDMI is a closed standard and buying HDMI chips requires signing over your first-born to Satan.
As someone who used to worship Satan as a kid (yeah, stupid), I resent that remark. Please do not insult Satan by comparing him to a vile media consortium.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
But this is not a big problem -- there's dead-simple passive analog circuits (e.g.) to do a passable conversion, and if you want to fix the dark-yellow/brown issue, that's not hard either.
RGBI signals in CGA are TTL, so converting to analog RGB is as simple as connecting them to the address lines of a suitable 8-bit PROM (or SRAM, in which case you'll want a battery to retain memory) programmed with appropriate RGB values, and three 2-bit ADCs on the output (0=0v, 3=0.7v for VGA).
You want to program the ROM/RAM as follows, assuming I as MSB (note color 6, brown, deviates from the expected 220):
N | RGB | xxRRGGBB
--+-----+---------
0 | 000 | 00000000
1 | 002 | 00000010
2 | 020 | 00001000
3 | 022 | 00001010
4 | 200 | 00100000
5 | 202 | 00100010
6 | 210 | 00100110
7 | 222 | 00101010
8 | 111 | 00010101
9 | 113 | 00010111
A | 131 | 00011101
B | 133 | 00011111
C | 311 | 00110101
D | 313 | 00110111
E | 331 | 00111101
F | 333 | 00111111
Or use a 16-bit ROM and wider DACs, and you could customize each color to exactly match your old 1902.
Seems a PCB with a preprogrammed ROM, DACs (could be as simple as R-2R ladder), and a scan doubler IC, should be much cheaper than a $100 replacement video chip.
Better, perhaps, to ask "for whom?"
Please consider that just thirty-odd years ago, one could own a computer that wasn't the university's or corporation's. Whether one came fresh to it or from mainframe milieu, there was an immediacy, a power, a whole new realm of discovery. One no longer had to submit their deck of cards to an acolyte to the high priests of a Burroughs or CDC Behemoth only to get back a core dump due to an errant comma. Some, even now, for reasons of nostalgia or fun, continue their interest and enthusiasm - vibrant 8-bit micro communities are but a search away.
The TI-99/4A offered, amongst other things, 16 sprites with built-in collision detection. At the time this was nigh magical. Sprites were effectively independent of screen - they were a 'floating' layer above it and allowed for some interesting game and simulation possibilities. SCREEN itself was a defined device; one could PEEK and POKE 'most anywhere, and PUT and GET to any device. An entire screen could be represented with a string in memory, its contents readily changed on the fly. One could read data for a string from a DATA statement in program code or from (eventually) floppy; with several strings screen-swapping, almost animation, could be done. Graphics could accompany text adventures. Add sprites? Oh, my. And now with VGA?
You may have to ask "what for?" - others will not.
Actually, it was 32 sprites, with a limit of 4 to a line. It had collision detection but it was rarely useful. It had a single bit to tell you that any sprite hit any other sprite. To figure out what hit what, you'd have to walk the descriptor list and do the actual computation yourself. (Or, in the case of TI Extended BASIC, the interpreter had to do it for you.)
On the TI-99/4A, that meant actually accessing VDP memory, since there wasn't much other RAM in the system. That itself was pretty slow, because it wasn't memory mapped for the CPU. You have to write to the VDP's address register, and then do repeated reads after it fetched the byte. Depending on the display mode, that could be as long as 8us during active display (Graphics II mode -- everybody's favorite "bitmap" mode.). Fortunately, the address pointer auto-incremented, so if you were accessing a contiguous structure like the sprite descriptor list, at least you didn't have to keep reloading the address.
Not that TI Extended BASIC was necessarily able to do that, of course. (Read up on the abomination that was GPL. Not the license, but the interpreted language that much TI software was written in, including TI BASIC.) But if you wrote your own assembly code, you could make that optimization, which is probably how Parsec was able to do its soft-scrolling in the time allotted.
(Actually, VDP RAM isn't memory mapped on any platform that I know of. But other systems have CPU-addressable memory that you could store a shadow copy of data in at least. The paltry 256 bytes on the TI-99/4A, though, are far from enough in many cases.)
Program Intellivision!