Jump to content

Yamazaki

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

3 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Guys, I have just realized that ROM chip is not really needed. Logic 1s that represent sync impulses are stored in different data words than data wordes used for storage of colour data. And all bytes with colour data ALWAYS have 0s for two last bits. You initialize the device once and just don't touch sync bytes, 'cause there is no colour data at all
  2. I've only seen the review and got the basic principles: no CPU, restricted number of machine instructions ran by separate logic ICs, additional instructions have to be emuladed, which makes it in fact not so simple. Must be a lot of fun to play with.
  3. Hello there! Having an VERA video core is great in terms of performance and graphic capabilities, but it doesn't meet the initial concept of using no FPGA or MCU. So let me come up with an extremely simplistic video output schematic. I was quite impressed with Ben Eater's "world's worst video card" https://youtu.be/l7rce6IQDWs https://youtu.be/uqY3FMuMuRo It can output a a nice low-resolution 64 colour image, using a memory chip and a handful of logic ICs. But keeping in mind that this is only a demonstration-of-concept hardware, we could make some quite a substancial enhancements: First of all it, is not really simple! It uses 20 additional chips just to generate Hsync and Vsync pulses! So my first key idea is that we don't need most of that ICs. We could use a CLPD to replace all these chips, but that brings us back to what we have started from so there must be another way. Just think of it: Hsync and Vsync signals are just logical 1s, given away exactly at an expected time, according to VGA timing diagram. Just the same thing is done with pixel color data. Memory chip outputs logical 1s and 0s in with every tick of a clock signal. So why can't it do the same with a sync signals? Ben's schematic uses only 6 lines of data bus for colors (and only 6 bits in every byte!), so we can use 2 remaining data lines for sync lines. Now all we have to do is store these 1s (for sync signals) in a corresponding data bits in a memory chip! That can be done by software. This is an interesting design already, but one problem occurs would we try to write some new data into a memory chip. We can not just rewrite 6 bits of colour data (out of 8 in a word) and keep 2 remaining sync bits intact. So we can not write them once during initialization and just forget about them! We have to regenerate sync data in in every writing procedure, and that is a pain in the downriver. So my next suggestion is to use a separate PROM chip hanging on the same address bus just to generate Hsync and Vsync signals, and a counter restart singnal for every frame. That takes an additional chip, but it's still much better than 20 smaller ICs. Ok, at his point we have 3 2 chips and we yet have no circuitry to help us write something into the memory buffer. Aaaand... The last idea vas given to me by the most recent 8BitGuy's video https://www.youtube.com/watch?v=zHAIuE5BQWk I didn't know until today that there are RAM chips with two data ports! It really makes things simple! Two ports can be written and read simultaneously and asyncronously. Now we can just write some graphic data into corresponding bits and see changes on a display! What i forgot to mention is that 8 adress lines shown on my schematic are insufficient for this device. 8 lines were shown for simplicity. If we stick to Ben's design with 264 ticks per line and 628 vertical ticks per frame , we need 264*628=165792 bytes of ram and the same size of ROM. It would use 16-bit address line and would require 16-bit binary counter. Anyway, bigger dual port SRAM chips are still obtainable. Hope that these ideas could be useful. Questiuons? Opinions?
×
×
  • Create New...

Important Information

Please review our Terms of Use