AndrewP wrote:
So... one of the things I'm trying to do is use no programmable hardware. Why?
Because I like a challenge. But more seriously it's because I feel that CPLDs and FPGAs are a bit of a black box when it comes to figuring out what a circuit is doing. I've managed to reduce my programmable logic devices down to a single 32KB ROM (and SD cards). Everything else is 74 series ICs or at least ASICs. Looking at the VERA from the X16 or the Vicky from the Foenix it seems like they become too complicated (to easily drive from an MPU with address lines) and too tailored to their host machine. What I really want is something that I can access as a simple IO mapped device and that will do something as simple as drawing a single line of pixels**. The 65C816 becomes a part of the graphics device.
And I like that.
It also means I need more than one 65C816. And I like that too
** That needs 16 4bit presettable counters per blitter. Simple is not always that simple.it's not that you have to use Programmable logic, but as drogon said, with goals ever moving forward (higher resolutions, more colors, clearer audio, etc), the hardware has to move as well otherwise it will just become unusably slow.
also you're kinda making it sound like Programmable logic is some kind of black magic that just works once soldered, but you still need to put a lot of effort into the logic that runs on it. pretty much the same thought process when you design a logic circuit for discrete 74' ICs.
anyways, since the main bottleneck of Graphics is just moving data around (which is why modern GPUs have like 512-bit wide memory buses), you'd want to avoid the main system doing that. so the only way i see higher resolutions being a thing is to have a seperate system specifically for the graphics, controlled via some set of commands.
the idea of using a second 65xx CPU for graphics work is of course not new, but still pretty good!
a 65816 running at 10 or 20MHz (based of the pixel clock for 800x600) with fast SRAM would give you some decent performance.
but even that will only get you so far.
AndrewP wrote:
a separate CPU and video RAM - how to implement it - a high speed parallel interface (Pair of VIAs?) or alternate phases of the clock on a shared memory system? Dual-port RAM (expensive!)
Dual Port RAM is one option, and not as expensive as you might think! the 32kB of DP-RAM on my current video card cost around as much as the 65816 running my SBC.
the problem with DP-RAM is that it's slow, bulky, and while you can use it to communicate between 2 CPUs, it's not ideal.
i'd say something like the
IDT7201 would be a better fit. it's a unidirectional FIFO, 2 of those allow for fast bidirectional communication. with a status byte to read out the flags of the FIFOs it would take up 2 addresses on both sides.
on a side note i have been kinda fantasizing about a little cluster project with these FIFOs to create a ring network of multiple 65xx Computers that would directly plug into eachother. but so far it's nothing but a
block diagram.
sort-of-EDIT? (sorry if this is getting too off topic!)
while writing this i thought more about the network idea, and how modern GPUs have so many cores that each of them can take care of a small set of pixels.
so, what if you had more than 2 CPUs? 4x 65C02's for example that all share the same fast single port SRAM with a video circuit. a lot of graphic operations can be split into multiple smaller pieces (like scrolling or drawing shapes).
my idea of connecting them was to have all CPUs run on the same clock with the same phase. but then use extra logic to restrict their time on the bus when PHI2 is high.
Attachment:
gimp-2.10_woQn9hkGhn.png [ 45.81 KiB | Viewed 23894 times ]
using bus tranceivers and latches (latches because data is only read on the falling edge of PHI2, so the data needs to be stored), each CPU could get a small part of PHI2=High time without having the CPUs themself run at extreme speeds. but of course the more there is on the bus the faster the support logic needs to run, which comes dangerously close to FPGA territory.
anyways, overall i still think that for these kinds of graphical goals you likely won't get something useable without either progammable logic, a crazy setup like the multicore bus sharing, or both!
i still wish you luck with whatever you might have planned, and i'm eager to see it work!
Login
Register
FAQ
Search
alright TI ...). Same video signal. Just without the extra bolt-ons that HDMI blessed us with (for a fee), which are really only protocol extensions over the same wires ... For more 'prototyping convenience' you may want to start with this (as I did) : 
