Yann Guidon / YGDESI would LOVE to provide a decent video output to this system. However modern displays easily exceed the capacity of a 16-bits CPU.
I don't want to limit the display to 320×200px like the mode13h in the ol'PC. I'd like 800×600 or even a decent 1024×768×24bpp. I don't mind if it will be slow :D
There are 800×480 LCD modules with cool prices, which is good for text and pictures display. A 16-bitter could work in R5G6B5 color space for faster updates. And I'm OK with breaking the "TTL rules" and use a FPGA instead of slow HC parts. After all it's just counters and latches and...
No, the real challenge is how to let a 16-bits CPU access a much larger addressing space. In the case of a framebuffer, this might be easier conceptually because the display is 2-dimensional and I have chosen to use 2 different registers to address a single pixel.
This means : a couple of new, special purpose instructions to set and get a pixel value.
pixget rX rY rdest
pixset rX rY rCol
pixset rX rY imCol
The architecture allows 3 register reads per instruction and we can even get a 16-bits immediate version :)
This also saves the user from having to deal with horizontal and vertical resolution. Coordinates will just be clipped, to 10 or 11 lower bits.
Wait.
11 bits means 2K pixels per dimension, or 4M pixels, or 8MBytes. Where will I find that and how will I manage that ?
Internally, there would be a 2K×2K virtual display area and only some of it is scanned to send to the display. The CPU can "scroll" by changing the start address, both X and Y (I told you, it's just counters...).
If I select a 1K×1K resolution, that's nice for a 800×480px display but the scrolling is limited... I hope to make some little games so hardware assistance will be necessary because the CPU can only run at 2 or 3 MIPS...
I could use a 8MB (4M×16) (S)DRAM chip but I hope to avoid this, I don't want to deal with refresh cycles. If I limit the chip count to 4, that makes 2MB SRAM chips and they are not cheap (unlike the 256 and 512KB I have).
The video data can be sent to a LCD module and/or VGA plug, I have some RAMDAC in stock :D But the SRAM seems to be the limit so far. I don't want to artificially limit the resolution and I want to allow smooth scrolling...
PS: I got a few 36Mb chips but they are in BGA119 and "expensive". They run at 225MHz so it's a bit overkill, too...
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
FYI my experiments with SDRAM suggest that you don't actually have to do explicit refreshes *nearly* as often as they claim... or even at all in the case of a framebuffer type system where every page is accessed regularly... (access apparently also results in refresh).
Shameless self-promo on your project-log... I've a project where I've done a *lot* of experimentation on these matters...
Are you sure? yes | no
I guess so, it's a famous Wozniak trick.
I have never used (S)DRAM and I try to avoid it, "because it's complex". For the Discrete YASEP, conceptual simplicity is very important : not only it lets others understand the system but it also decreases development time and other things.
I don't like the idea that I'll have to deal with 2 simultaneous accesses to a multi-banked memory chip, row & col addresses etc., with all the timings idiosynchrasies...
Anyway, I can easily get 1MB with 2 SRAM chips (sync or async, as needed)
(you didn't even put a link to your project, you're being lazy...)
Are you sure? yes | no
I'm not being lazy, I'm being considerate of your project-space ;)
#sdramThing4.5 "Logic Analyzer"
I've never done DRAM, it seemed way too complex to me for way too long, I thought SDRAM would be worse, but was tempted by the fact that 128MB was so easy to come by ;)
It's not so bad, really... In fact, it's pretty durn intuitive, at this point, to me... (yahknow, after a few years and 4.5 versions). DRAM still scares me.
The Row/Col method might lend itself well to your 2x16bit addressing... Can't vouch for the timing of simultaneous-accesses, though... I'd think you'd have the same trouble with most memories, though, thus why so many framebuffers are double-buffered, and/or wait to do updates during the vertical-blanking period...
As far as keeping multiple banks open... unless you *need* that feature, just open a single bank when you need it and close it when you're done... The best use I've found for this is that you can open the "next" bank somewhere midway through reading the first... then close the previous somewhere midway as well... In that way you can use a "burst" and do other things while that bursting is happening.
SDRAM (vs DDR) has the benefit of *full page* bursts (as opposed to 8-column-max bursts), which is *great* for video...
Are you sure? yes | no