5

I am trying to build a 16 bit single board computer based around the 68000 and am wondering if there are any non proprietary 16 bit graphics chips like the Yamaha V9958 with readily available datasheets.

Thanks

Doihead
  • 59
  • 2

2 Answers2

5

Well, one obvious choice would be to use the chip that the Yamaha devices you mention were extended clones of, the TMS9918. They're not manufactured any more but can be acquired with relative ease if you look in the right places, so are definitely a plausible choice. The TMS9918 was used in the first 16-bit personal computer, the TI-99/4, so you'd be in good company there. You'd lose a bit of resolution versus the MSX, but it's still a pretty reasonable system.

Another choice would be the Motorola 6845, which was somewhat less advanced but a lot more versatile -- it ended being used as the basis for the IBM PC graphics cards up to and including EGA (and is present in backwards-compatible form in the VGA too), so is capable enough for real work.

Edited to add:

The NEC uPD7220 is another good candidate, or more particularly its 16-bit successor the uPD72120. Unlike the 6845 this implements a command-based system where you tell the chip what to draw and it updates the video memory for you. Like the 99x8 chips, it is designed to have its own memory that it manages access to (whereas the 6845 is agnostic about whether the memory it's connected to is its own or managed by the host CPU: it only generates addresses and expects external circuitry to perform the actual memory access) and provides a way of requesting changes to the memory from the CPU along with general drawing primitives (but unlike the 99x8 it provides a bus request/acknowledge protocol that allows direct access to it too, and is able to use a standard DMA protocol to perform block transfers to and from system memory).

Like the others above, it's an obsolete part no longer manufactured, but can be purchased on ebay and similar sites.

Jules
  • 2,026
  • 13
  • 21
  • 1
    Or something slightly more modern like the [SSD1963](http://www.solomon-systech.com/en/product/display-system-solutions/display-controller/ssd1962/). – Ignacio Vazquez-Abrams May 26 '18 at 17:46
  • Or something modern and low-pin-count like [FT800 or FT81x](http://www.ftdichip.com/EVE.htm). Manages touchscreens and provides audio, too. Requires SPI or I2C, though, so it may not be that easy to interface with oldschool MC68000 with only a parallel memory bus available. – dim May 26 '18 at 18:47
  • 1
    @dim - yes... for a project like this, you definitely want something with a traditional parallel memory bus, because that's the only thing the 68000 will interface to without a lot of jumping through hoops. Also, I should point out that the suggestions in the comments here are pure framebuffers, but the V9958 that OP was looking for something similar to is based around a text display with modifiable characters and overlaid sprites, which is substantially different ... and with the bus performance of the 68000 (which wasn't exactly great: 4 bus cycles per memory access, max 25MHz clock rate... – Jules May 26 '18 at 20:29
  • ...and a 16 bit bus => max 12MB/s data transfer, but more realistically 3-6 is the most you'll actually get) you're going to want the bandwidth benefits provided by using that kind of interface. – Jules May 26 '18 at 20:30
  • 2
    The MC6845 is only half a video chip though. It generates timing and addresses, but doesn't actually fetch or display pixels. The original IBM PC CGA and MDA cards were full length ISA cards because of all the additional components required. You're probably better off implementing a complete video chip on a FPGA these days. – Ross Ridge May 26 '18 at 23:05
  • @RossRidge - the CGA & MDA cards were so large mostly because they contained a large number of DRAM chips and the circuitry required to access data in DRAM, plus interfacing with the ISA bus in such a way that the CPU could directly access the same RAM (along with generating WAIT states when it tries to do so while the memory is being used for display purposes). Using a 6845 in the more common configuration (i.e. sharing access to the main memory) and taking advantage of the fact that the 68000 can only access memory in 4 bus cycles out of every 8 is much simpler than what those cards did. – Jules May 29 '18 at 07:19
2

I had a look at Xilinx FPGA's. I made an VGA/SVGA/XGA table with various bits per pixel: 3,9,12.. Some results:

  • VGA 3 bits: 900KBits, 9 bits:2.7 Mbits, 18 bits: 5.4Mbits
  • SVGA 3 bits: 1.4Mbits, 9 bits:4.2 Mbits, 18 bits: 8.4Mbits
  • XVGA 3 bits: 2.3Mbits, 9 bits:6.9 Mbits, 18 bits: 11.5Mbits

Then I tried to map that on an FPGA. The limiting factor is the internal memory. ~$25 gives you 1.6Mbits. ~$57 gives you 2.7Mbits

Next I looked at using external SRAM. Much cheaper! A 100 pin FPGA is about $8, an 16Mbit SRAM is ~$7 (LQFP package) That gives you theoretical XGA with 262K colours per pixel.

Then you can add a DAC or use a resistor network.

What I could not check is if the selected FPGA is big enough for XGA code. The code is very simple, just a series of counters but you have to add a CPU interface and may be a character ROM mode.

If I am very bored I might try to write one tomorrow.

Question is currently on hold but I give an update anyway.

Started with a 100 pin XC3S50. I to had reduce the video interface to 12 bits and the CPU data bus to 8 bits to remain within the pin count. (This is for XVGA) The design fits easily. I added a 256x54 bit RAM to work as character "ROM" (Use-able as 9x6 or 10x5). By that time, with the FIFO, I ran out of internal memory.

Then I tried a 144 pin XC6SL4. I chose a bigger device because experience has shown you always need a bit more then you expected. It costs $2 more. This time I had spare internal memory blocks and multipliers. Struggling with the pin count, I managed to go up to 18bit/pixel with 16 bit CPU data bus, or 15bits/pixel with 32 bit CPU data bus.

In both cases the memory bandwidth is not enough to read & write at the same time so in both designs there is a FIFO which catches the CPU writes and executes them in the blanking period. With 256 entries the 68000 CPU is not fast enough to fill the FIFO in a line time.

Both designs can work in graphics or character mode. All the video timing is programmable (Like the 6845 but bigger and faster) thus it can do many video modes up to 1024x768. I have not added colours to the graphics mode but that is just a matter of a bit more time. (e.g. 16 foreground and 16 background colours). As there were some spare gates the graphics mode can be joined or separated. (In separated mode the hardware adds blanking pixels around the characters so they stand out.)

I have no hardware which means none of this could be tested in real life.

Oldfart
  • 14,212
  • 2
  • 15
  • 41
  • 1
    The MC68000 will need its own RAM anyway. Traditionally video accesses were interleaved with CPU accesses. – TEMLIB May 26 '18 at 19:26
  • FWIW I've written code that fits in the smallest Cyclone IV device and which reads an incoming LVDS signal originally intended for a standard 640x480 LCD panel, stores the image in DRAM, and then pulls it back in in a different order to feed it into a shift buffer into an LED digital sign, all @50Hz refresh. I don't imagine implementing a standard XGA adapter in the devices you're looking at would be a problem at all. – Jules May 26 '18 at 20:36
  • What you *really* need, though, in order to make it comparable to the 99x8 chips, is graphics acceleration functions: block copy, line drawing, sprites. That *might* tax a small FPGA. I'm not really sure. – Jules May 26 '18 at 20:37
  • @TEMLIB - that's definitely the way I'd do it, but it's worth noting OP asks about the V9958 and the 99x8 display processors had their own memory which was only accessible to the host processor by writing the address they wanted to access into one register, then reading/writing from another to perform the access (... and this is the reason why the TI-99/4A was so slow in its base configuration: it has 16KB of RAM attached via its TMS9918 and only 512 bytes actually directly attached to the processor, so its BASIC and games cartridges all ran using display memory...) – Jules May 26 '18 at 20:44
  • @Jules Anything they could do on a (digital) chip in the 80s and 90s can probably be done on an FPGA today, maybe unless you go for the low end of FPGAs. – user253751 Jul 30 '18 at 00:20