[Oberon] FPGA - Colour Support

Paul Reed paulreed at paddedcell.com
Mon Oct 16 10:23:20 CEST 2017

> With the resolution of 1024x768 currently used by Project Oberon
> 8 BPP needs 768 KB memory
> 16 BPP needs 1.5 MB (more than the whole system uses today..)
> You definitely need more than today’s 1MB RAM :-)
> With this amount of memory to be moved, stealing clock cycles from the CPU
> might get critical. So, if you want to go in this direction, you might
> think of introducing separate RAM for graphics so the HW driver can access
> video memory without stealing CPU cycles.

Part of the stated goal of Project Oberon is to show how much you can do
with self-imposed resource limitations and reduced self-inflicted
complexity, provided you stick to only essential features (which varies
according to taste).  And if you really want to expand the memory
available in order to support colour in the frame buffer, you're also
likely to need a lot more more heap memory in order to support
manipulation of graphics objects, e.g. Tomas' Bitmaps.  Which will slow
down garbage collection, etc. etc.  Hence rather proving the point in my
first sentence.

Having said all that, one way the early micros simplified their dynamic
RAM interface is by realising that due to the row/column nature of DRAM,
they could dispense with hardware refresh, if all the rows could be
guaranteed to be accessed within the refresh period.  This was sometimes
done with a software interrupt handler which just read a word from the
required row - but more often by the video refresh accesses, which
regularly touched memory in a well-understood patten.  So if you had to
build a system based on DRAM, this might be a way to go.

Just my tuppence-worth :)

More information about the Oberon mailing list