Samuel A. Falvo IIIt has occurred to me that I need to implement the video interface before I implement the CPU. I'm still quite used to the architecture of the Kestrel-2, which used internal block RAMs, and so I could easily afford to just focus on the CPU first. However, there are two important reasons to focus on the video interface first:
- First and foremost, the CPU must go through a RAM controller of some kind, and with the video controller needing to know not only how much video bandwidth exists but also the organization of the bus in order to maintain accurate timing, it makes sense that the video interface be responsible for interfacing a higher-level bus to the nitty-gritty details of video RAM.
- Second, the video interface serves as a kind of replacement for your typical front-panel. Getting the video interface working first means that testing basic "hello world" tests like ld x0, negative1 ; sd x0, framebufferAddr ; jal x0, * will be much easier to get working.
From the RAM's perspective, there will be (at least) four or so bus masters:
- Sprite Y coordinate fetch,
- Sprite X coordinate, color, and data fetch,
- Background video fetch, and perhaps not least,
- the host processor bus itself.
Each of these would appear, to the RAM, as 16-bit wide bus masters. Most of the video circuitry will continue to use this data width; however, the host bus will be bridged with something that groks 64-bit data widths and sequences wide loads and stores accordingly. Only when this logic is in place can I even consider putting a CPU on the host bus.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Well, that's not cool. My reply to K.C. Lee has disappeared in the process of trying to reply to his reply. *sigh* Really disliking this commenting interface. Hackaday, seriously, this UI/UX desperately needs to be repaired.
Are you sure? yes | no
It is far easier to store the sprite in small two port memory R/W or Write only from the processor and R from the overlay circuits. On a X, Y coordinate match, they are overlay directly to your video output with a MUX ignoring whatever data fetched from frame buffer.
Are you sure? yes | no
I am assuming that you are using some kind of synchronous DRAM where you want to take advantage of burst access as long as possible to get much better utilization. Some of the Amiga's assumption might not work too well as they use DRAM, so they have lower incentive for doing big bursts.
You would then still need to latch the sprite data some how as it can get messy to grab data JIT from external memory. So either you use the DFF in your CLB or use the LUT as dual port memory and fill them on more convenient time slots to not disturb the memory bursts. I like RAM as you can index them and store more than one thing at a time.
Are you sure? yes | no
Actually, I was planning on using the memory as asynchronous memory to start with; but you raise a good point. Eventually, I would like to advance to using SDRAM, and I hadn't thought of the video fetch implications that'd bring. I'd basically need to add a cache to the video circuitry to continue to using the scatter-gather approach. This will need some more thought. I have ideas, but need some time to put them into a cogent form I can write about.Thanks for the tip about RAM vs SDRAM!
Are you sure? yes | no
FYI: You might find this blog interesting http://retroramblings.net/?page_id=770
[AMR] is trying implement 68000 CPU core along with video in FPGA.
Are you sure? yes | no