5 Oct
2006
5 Oct
'06
10:34 a.m.
der Mouse wrote:
I don't think it's that big a deal either, but in this situation I'm trying to
keep things as simple as possible.
My gut feeling for Sudoku was that:
- each display cell needs 5 bits of data; 4 to encode the digit (or blank)
and one to dictate whether the user could change the contents of the cell
during gameplay.
- 'address' is basically formed from the XY position of the cursor
(possibly via some form of lookup table so that 'holes' aren't needed in
memory).
- n starting grids exist in some form of ROM; one of these should be
selected at random and copied to 'game memory' at game start.
In other words, there's not really any kind of CPU or usual buses in any kind
of classic sense. However, using a SBC of some form would certainly speed up
development, so I've not ruled it out.
I've not sat down and seriously thought about a CPU-less design yet, though -
I'm more concerned at present with whether the display side of it can be done
(cheaply).
--
A. Because it destroys the natural flow of conversation.
Q. What's wrong with top posting ?
I was thinking
of individual LEDs and 8x8 matrix LEDs but the driver
Ics for matrix LEDs are expensive and usually only drive 2 8x8 or, 4
5x7 matrix displays and they're not cheap,
I can't see why they'd be expensive. One 8-bit-wide PROM, eight driver
transistors, and an 8-to-1 demux would give you the ability to display
lots of symbols (as many as you can fit into the PROM, which depends on
how many address lines it has - eg, 12 address lines would support
2^(12-3)=512 different symbols).