The 8 Bit Guy is making a 6502 based computer for game development and looking for a video chip. It can't be a microcontroller or FPGA and must have VGA output.

Graphics similar to a C64 are desired, so low Res with a few sprites I guess. It must be available (currently manufactured) or at least I guess plenty of NOS.

I couldn't find anything, any ideas?

He is using an FPGA as far as I can tell. Although it's an existing system called the Gameduino. He has someone re-engineering it to give it an 8-bit bus type interface rather than SPI though. I suspect it's going to be a command+data type bus rather than CPU bus though - so same as the old TI99/4A type system. He seems to want a system that has an Arduino style header too, so the gameduino would fit that scheme.

I am somewhat surprised at his choice though - Gameduino isn't cheap - like $50 or more! My next-rev 6502 SBC will use a $5 Raspberry Pi doing more or less the same thing - command+data bus interface to a higher level processor doing the "heavy lifting", or peek/poke the memory directly, but slowly.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

David looked at using the VSLI's 23VS010 chip. These are under $2.00 in quantity of 1K+ and give you 128K of video memory and resolutions from 16x16 to 1024x768, with the depth confined to what will fit within the video memory. I am using these in a project. They are nice because you just fill a buffer and it handles the video output.. that's it. You can blitter copy to/from anywhere within the video memory without having to manually do it. So, offscreen memory can contain data like icons, tiles, etc. You don't need any horsepower to run it. It's quite an amazing chip. I think the Gameduino option is a bad decision. Stefany's Foenix 256 project will be hands down a better and more capable '816 based retro computer. VLSI makes an 8 bit version of this same chip without the video generation hardware (128K SRAM) only that is SPI/QSPI based. It's a REALLY cheap way to get 128K of SRAM and with QSPI it's fast enough for just about everything. The version with the video hardware has both parallel and SPI interface options. I am using the parallel interface myself.

Yeah, we need to find him something better! He didn't want to use an FPGA but there doesn't seem to be anything else.

Best I could find are some NOS Yamaha VDCs, but they only output 15KHz or maybe one 31kHz black and white mode. Most people have a TV that can do 15KHz... I guess he wants it so you can buy a brand new, small monitor and they are all VGA.

Compared to the Gameduino it would be cheaper to use a Yamaha part and include an RGB to VGA adapter I think.

If I were David I would use a microcontroller to generate the VGA and have it also handle the SD card and other things, and leave the '816 strictly for processing.

That would be my approach too, a little ARM that sites on the 6502 bus.

Indeed it is! But you have a minor typo -- it's known as VS23S010D (datasheet attached).

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yeah, its a VS23S010-D now. I helped debug the C version. I have been tinkering with this chip for a number of years now. The "BasicEngine" 2D game system uses the VS23S010-D and a ESP8266 to give you an 8 bit type game system.

I think the 8-bit guy's set himself a rather difficult task. Selling a 65xxx system for less than a Raspberry Pi is almost certainly going to be incredibly hard.

Video generation the way he wants it(memory-mapped, VGA or HDMI output, probably with sprites as well) isn't going to be trivial, though it might not be too hard, given that VGA is fairly well-mapped territory. I do think that the best way for that is an FPGA, though, so he's on the right track with the Gameduino.

The SID is fairly well-emulated at this point, so that's in his favour. I think he's got hold of a SwinSID (although where he got it I have no clue whatever). My concern with that is that it could be too slow for his speed goal, although wait-states might be acceptable, because you don't necessarily need to update the SID at 8MHz. I suspect that such a blistering rate of updates wouldn't even be audible, unless you were pushing a sample.

I do think that his intended development strategy is a good idea. Being able to start from an already-working system and replace bits of it as desired sounds really convenient.

I'm mildly concerned about IO, myself. I would want a nice selection of it(and I imagine a number of other people would, too), and he hasn't mentioned it much at all, so it sounds like it's fairly low on his radar. I hope he doesn't neglect that sector of his design.

I await his next (public) update with mild anticipation, but I will not be surprised if he backs down on some of his goals.

It's a nice little device, but lack of a 6800 bus mode and VGA output kinda rules it out.

I think his requirements are too strict. He will end up with an expensive FPGA, but I think using one of those Yamaha chips (used in the MSX2 among others) plus a VGA converter would be better. Shame there isn't a single chip PAL/NTSC->VGA device.

Yeah, unfortunately using an ARM may be difficult because none of them seem to have a 6800 compatible bus where they can act as a slave device. You could emulate it with interrupts but then timing for VGA output becomes non-deterministic, as in if you generate each line one line ahead you may find you don't have enough time left to render all sprites or something. I suppose you could over-spec it massively so that even with heavy bus I/O you can always draw X tiles and Y sprites per line.

Cheaper than an FPGA and it can handle all I/O including sound and tape, plus it's easy to bootload new firmware and best of all the development tools are all free and open source.

I could witter on for days about the whole video and IO thing - it's a fascinating subject and different people approach it in different ways. I think it's fair to say that I'm really a software person who dabbles in hardware - probably too much as I've found myself designing 6502 systems and many different interfacing stuff over the past 40 years. GPIO is me.

It's interesting to note that GPIO is what sold the Raspberry Pi and the Pi seems to have set a "standard" of SBCs now having (or feeling their need to have) a "40-pin GPIO connector". (Pi compatible-ish, or not).

And yet in conversation with Stefanie of the Foenix project, she's very anti-GPIO (and even more anti-Pi, sadly). There is no GPIO on the Foenix and little provision for it either. There is a full processor bus, but she has expressed disappointment at the thought of anyone connecting a Raspberry Pi to it. Dave is also somewhat anti-Pi (I managed to exchange a couple of emails with him immediately after he posted that video, before his Facebook channel 'exploded') but he wants Arduino style GPIO.

My own "GPIO timeline" was along the lines of the Apple II (plug-in cards with VIAs!) then Northstar horizon (S100 bus), in-house 6502 systems, and then the BBC Micro (User port, abused printer port, 1Mhz BUS, Tube), I suspect I was spoiled somewhat with easy to use computers with easy to use GPIO...

I started my own retro 6502 project a year ago and thought then, hey, video was hard in the 70/80's - it's got to be easier now. It's not. At least not for me. I don't do FPGA/CPLDs. Mostly due to me really not knowing how to use or program them, nor having good Linux based tools either. Also, there's that whole SMT thing - which isn't totally alien to me, but I wanted that retro feel.

My research included revisitng the schematics of the BBC Micro and Apple II. The Beeb had a conventional CRTC and a big blob of ULA. The Apple has a raft of TTL. I looked at the Parallax Propellor, Gameduino, VS23S010D and some FPGA/CPLD solutions. I found Quinn Dunki's Veronica project - a few pages of hand-tuned AVR assembler generating lovely VGA but it didn't quite hit the nail I was after. (resolution was too low - I wanted my 40 column text)

I did (initially) settle on an ATmega video generator though. I used an ATmega 1284P with 16KB on internal RAM to generate a composite video display of 320x240 monochrome pixels, then I set about using it as the "host IO" processor to my 6502. I have since had 2nd thoughts and although the sockets and 2 resistors are still on my PCB, it has issues - it slows down the ATmega to the point where it loses data over the serial port and 6502 interface. It takes an interrupt every 64µS and clocks out 40 bytes at 1 byte per microsecond plus a few more bytes for hsync and vsync when needed. That only leaves at most 15-20µS out of every 64µS to do other stuff and it does make a difference.

Going back to direct (memory mapped) video - the issue now is how much RAM? 320x240 is about 9KB per bit depth. So 4 colours (2 bits), almost 20K. 8 bits per pixel? That's 80KB of RAM - in a 6502... Oops. Going to a 65816, great - we have the addressing, but not the speed of a modern system. clearing that at 7 cycles per byte is half a million cycles, or 0.04 seconds - barely 25fps achievable just on screen clears. That's when you need a plan B - a "graphics chip" like the early "blitters". The Foenix uses a dedicated FPGA to do this and to handle sprites and other graphics functions (AIUI)

So it looks more and more that if you want addressable graphics memory then you need to go into the world of the FPGA/CPLD if you want anything more sophisticated than a simple bit mapped display - and by all accounts, that's what the C64 enthusiasts want - in the Foenix case she has an FPGA with addressable RAM, in the 8-bit Dave case he has (AIUI) a separate graphics processor with .... an FPGA.

So not having the resources/time/energy to dive into the FPGA/CPLD world, my current plans are to be text-only via serial in the current one, then use a modern graphics-pipeline approach in the 2nd one. That will be a $5 ARM based system with on-board HDMI, but running at a retro resolution of 640x480, 8bpp. Graphical output will be mostly one-way - you throw commands down an 8 (or 16) bit channel (rather than a CPU bus) and let the GPU get on with it, but if I wanted to peek & poke pixels, then that facility is there. I'll have a 65816 with a GPU and separate RAM. I'm OK with that.

I still think both the Foenix and Daves projects will be worthwhile though - I've signed up to both, so we'll see what happens.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

If you go "cpu bus" route then you're dealing with what's effectively shared RAM. You might as well stick (expensive) dual-port SRAM and be done with it.

Otherwise - you're making the ARM/FPGA into some sort of memory mapped register device? From what I've read on the PiTubeDirect project that's do-able, but only just at the BBC Micros 2Mhz speed and who wants a 2Mhz 6502 these days...

So if you don't want to directly memory map the video RAM, then you probably need something like a Gameduino FPGA approach - and if that can act as a memory mapped peripheral then you'll save a few clock cycles, or via an 8 or 16-bit bus like using a 6522 VIA with a strobe+ack type data path to de-couple the CPU bus from the graphics card.

The VS23S010D is an interesting approach though - although not directly addressable, you can effectively peek & poke pixels, however, it takes time - you need to send 5 bytes to it to set an 8-bit pixel (as far as I can tell), so if drawing a line from the 6502 it's going to be slower than drawing it into RAM - that's where an FPGA or ARM interface may have an advantage - a similar set of bytes, but that could command it to draw a whole line not just a point.

But everyone has their own preferences and ideas. My own is to lean towards a good retro software platform rather than a retro gaming platform, however we all know that games and bling graphics and sound do excite people...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I think an STM32F407 is the best solution. It can do VGA at 640x480 using DMA to push pixels out of an 8 bit port, so you can get 3:3:2 RGB colour. It could also handle a lot of other functions, like a UART, parallel/GPIO, debug for the 6502, sound, tape, SD card, keyboard/mouse/joystick etc.

You can use cycle stretching to interface a fast CPU with a slow peripheral. I don't think the ARM would be that slow but a simple bit of address decoding and clock stretching using discrete logic would do the trick.