The 6502 game console project:

Rockwell 6502 4MHz
128KB memory + 64KB for Graphics + 2KB Color Palette & possibly memory for audio as well
320x240 16 color palette VGA output
Gamepad input as idea, might be something else entirely
74xx series logic for as many things as possible, for understanding of the functionality as well as being able to teach my GF the workings of a computer by building this with her.

The current idea so far is to make the graphics card with 74xx logic chips only, making two counters as well as halving the clock for the visible part of the frame to get from 640x480 to 320x240. Then divide the clock by half and let it drive an address counter and just blast the pixels from RAM to the color palette and DAC.

We will be watching with interest. Do keep posting updates. My first question is how you plan to bank the memory to get that much in the 64K memory map afforded by the 6502. The 65816 is much better suited for that and has a lot of extra capabilities, but for some reason banking on a 6502 kind of fascinates me too.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I am curious how to generate the VGA signal. An average MCU of todays can do it for you, simple enough, from its own SRAM. The problem: MCU's SRAM is quite limited (more suitable for text-only mode with character set in the flash of the MCU, so you only need eg ~1K for 40*25 without colours, for bitmap modes it's more limited, and the "worst": you can't access the video RAM directly but only simple commands can be sent to the MCU). For a "hobby user" (like me) some can use the well-known existing video hardware for typical home computers like VIC-II or C128's VDC but then timing is not so simple (not with VDC, but the the same problem as with MCU: you can't access the video RAM directly by the 6502) and also they're not so designed to generate VGA signal, but baseband PAL/NTSC ...

I'm actually also planning to create my own SBC using memory mapping. I actually already purchased some 74LS612 memory mappers for that purpose. Not the best option as you need an external Latch, but the moment I bought them, there were no 74LS610 available, but now there is a seller in Germany on ebay that seems to have quit a bunch of them. However propagation delay could make it difficult to use it in a 4MHz design or you have to use a W65C02S-14 running at 4MHz.

Nice to see (finally ) someone else is using the 7461x memory mappers besides me
http://www.6502.org/users/andre/csa/index.html

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Ruud Baltissen has a page about the 74LS612 and also a replacement circuit with more features.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

In my experience, the most important part of design is to define your end goals.
If you don't have clearly defined end goals, then it becomes impossible to decide whether a particular change is good or bad, because you can't tell whether it brings the design closer to or farther from the end goal.

Your present design has a 4 Mhz 6502 pushing around 64k of video memory.
An Apple II runs at 1 Mhz and has 8k of video memory (in high-res mode).
So thsi design has 8x the video memory with a CPU that's only 4x faster.

If you're trying to support games which don't do full scrolling, such as Pitfall/Aztec-style games, this may not be a problem. If you want to do full-screen scrolling games such as River Raid or Zaxxon or smoething, it will be a huge problem because the Apple II doesn't do it well anyway, and this is 2x slower for full-screen scrolling.

Since you have not clearly articulated your design goals, I can't tell if this design will meet those design goals.

Toshi

If it's tiles + sprites, then 4MHz should be plenty for that resolution, but I agree that doing a simple frame buffer for the screen isn't a great idea.

Plus, I think jumping to 8bpp (or at least one pixel per byte) would simplify the hardware further and avoid all the annoying 4-bit shifting and masking at sprite & line edges in software. It's already memory-hungry and not going to be running high-speed action games, so why not?

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Tiles and sprites are the way to go for 8-bit systems, as I did here:

viewtopic.php?f=10&t=2799

Alternatively, you CAN use frame-buffers but you'll need to have some additional hardware to do the grunt work. That said, old arcade boards like Defender did all the rendering in software. I'm guessing that the scan-conversion cleared the screen at the same time though. Either that or they did a selective restore for sprites. Robotron had a custom blitter as there were WAY more objects. Ditto for Juno First and a handful of other Konami boards.

-Yvo