Commander X16

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?

 

 

The simplest video output would be a dumb terminal, but nobody makes them anymore. Barring that, there are several terminal-like devices available. There is an ESP32 based terminal out there, along with the GeoffG terminal. And the new ARM based Maximite could also be used as a front end (although it's likely faster than the Commander.) 

However, with much of the functionality being dependent on VERA, you might as well just build an Apple I if you just want a headless 6502 computer. 

 

We are very familiar with this. It’s not something we want. Technically the statement isn’t exactly true either. CPLDs and FPGA have technical differences but those differences have little effect on end results. There are CPLDs that are more powerful and complex than some FPGAs. Both implement programmable logic and the difference is really just how the result is achieved.   Sent from my iPhone using Tapatalk

As Lorin said, X16 team want more capable video chip in spirit of VIC chip with sprites and other stuff. But I like simple things, so I vote for Yamazaki's design as an addon card for X16. I'm ready to support. And I may be even will build one, if nobody else does.  

On 8/26/2020 at 4:45 AM, Lorin Millsap said:

We are very familiar with this. It’s not something we want.

Of course, a simple 20-chip or CPLD framebuffer is not in line with the original vision of the X16, but the design of the X16 had been finalized a long time ago anyway.

I appreciate this discussion for

• 
  the experimentation
  


• 
  its potential as a solution to attach several monitors!
  

@Yamazaki, you are familiar with the Gigatron TTL?

On 8/27/2020 at 5:10 PM, Michael Steil said:

@Yamazaki, you are familiar with the Gigatron TTL?

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.

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

 

Dual ported RAM is great, but these days pins seem to be more expensive than silicon, and dual ported RAM is really pricey for the amount of RAM you are looking at ... over US$2/KB. for 8Kx16bit, over $10/KB for 1Kx8bit. Of course, most of those are very fast RAM, so you are paying for speed as well as pins, but still ... pricey.

They say the test of the pudding is in the eating ... as far as pins being more expensive than silicon, the least inexpensive dual ported RAM I see on the front page at Mouser ...

... is dual ported Serial RAM, so only 8 pins.

______________________________

Edit: I'll note another more reasonable dual ported RAM is 256 byte dual ported RAM with overlaid ADDRESS/DATA, so there is write address and read/write data modes (coded into two pins) plus eight A0/D0 ... A7/D7 pins, for 11 pins per port (including clock), plus power and ground. One interesting application for this is the Z80 UserPort box I was looking at ... you need a circuit to convert a Z80 read or write to the ADDRESS/DATA format, but the Z80 has wait state lines for both RAM and IO to make that a reasonable circuit to work out, and the UserPort could easily just bit bang the ADDRESS and DATA modes in PortB while connecting Port A to it's address/data port.