If the GPU has geometry fill instructions they wouldn't be that useful, but if not they provide a way to draw on the screen 3-bytes (one character) at a time without having to set the bytes individually.

Regarding the keyboard design, I have a related question. What kind of memory cell you used for storing pixels on screen? RS-NOR latch? Since it's the most simple and compact I can think of. (3x3xn)

Yep, there's an RRS-NOR latch behind each pixel.

And since we can't rely on CPU and using part of the memory as I/O buffer, I think the keyboard itself must have a build-in buffer as well. We certainly don't want the signal to be instantly transfered to CPU and wait 20 seconds+ for a typo. A more complex keyboard-screen design(I/O) is required.

Like the keyboard and screen can shared an intermediate buffer between I/O and CPU. Each cycle the CPU checks buffer for keyboard input or output code sets to the buffer.The screen receives signals from the I/O buffer, and keyboard only send signals to it. The keyboard will be more like typewriters with position keys.

The advantage of this is that you can instantly see what you type, and erase the error before sending it to CPU, which is important for a slow CPU cycle. The problem here will be the size of buffer and synchronization. (I/O interrupt) I think this will be a point to be considered when building the screen. Since the encoding will affect the buffer size, and additional control signals need to be added to determine the timing of screen refresh, whether it's constant refresh or synchronize refresh.

Not sure about all this at the moment, I just want to get the screen stuff all working before I do anything with a keyboard. It shouldn't be too hard to connect the keyboard directly to the screen though, allowing both the CPU and the keyboard to write to it. I'll probably use 7-bit encoding and I'll figure out what to do with the spare bit later.

If the GPU has geometry fill instructions they wouldn't be that useful, but if not they provide a way to draw on the screen 3-bytes (one character) at a time without having to set the bytes individually.

Oh okay. That looks really useful. I suppose that before I settle with any character encoding I should work out exactly what I'll be needing from it.

"Text Box" exactly, these were used to build "Pseudo Windows". Not long ago, they are the only thing closest to what can be called "graphic display" GUI for early Office Program like Lotus. (You may known its descendant Excel), and of course you can adaptive that for gaming purposes.

Quote from GICodeWarrior »

If the GPU has geometry fill instructions they wouldn't be that useful, but if not they provide a way to draw on the screen 3-bytes (one character) at a time without having to set the bytes individually.

What do you mean by 3-bytes? 4x6=24 bits? The encoder should be able to accept 8-bit code(SBCS) and translate them to the BITMAP of 24-bits. Or completely bypass the encoder and draw the pixels 8 at a time. But it will not equal to a pixel by pixel display, since it will be very hard to show 1 dot on screen without interfering it's neighboring pixels. (And a mask of some kind will help, I believe I've talk about this in an early post.)

As for ASCII Pong Game, Actually, I DO. And I believe I have write several small game using Turbo C++. And I still kept some source codes. And I believe you can google some of them as well. like thishttp://cboard.cprogramming.com/game-pro ... eview.html
A little too fancy though. And it used some assembly codes to accelerate timer. But I believe the core are much more simpler.

Quite simple actually, a giant loop with constant keyboard and timer check, and a "bat" reflecting simulation. (Just dx = dx, dy=-dy, vise versa). The only problems I can think of are first the random generator, (if you want a real game but a pseudo random may be enough), and second the timer. Since we can't rely on a "real time" clock, this may cause a lot synchronize troubles. (they are related to the I/O and internal clock counter)

If the GPU has geometry fill instructions they wouldn't be that useful, but if not they provide a way to draw on the screen 3-bytes (one character) at a time without having to set the bytes individually.

What do you mean by 3-bytes? 4x6=24 bits? The encoder should be able to accept 8-bit code(SBCS) and translate them to the BITMAP of 24-bits.

I think that's what he means, it allows you to draw shapes out of 24-bit bitmaps instead of doing it 8 bite at a time.

Or completely bypass the encoder and draw the pixels 8 at a time. But it will not equal to a pixel by pixel display, since it will be very hard to show 1 dot on screen without interfering it's neighboring pixels. (And a mask of some kind will help, I believe I've talk about this in an early post.)

You can show individual dots without interfering with neighboring pixels, thanks to the separate set and reset lines. I should be able to choose whether you overwrite the whole 6x4 area when printing characters or just set the appropriate bits and leave any already on ones as they are.

Also, I tried doubling the screen width and everything slowed down and it crashed randomly as I was walking around. I think that the game is struggling with how big it is. ;S

Having you tried to clear out the blocks around where you build? If I remembered correctly, the blocks within your line of sight, and the blocks within 128 blocks will affect the "simulation speed". Since those blocks have to be "simultaneously" update in order to achieve the effect of a simulated minecraft world, if there are no objects in the "simulation zone", they are inactive. (unless triggered by the neighboring blocks), Thus I think that's why there is some rules like south-west rules, it's simply because they are the blocks been simulated first. Hence if there are many blocks interactively trigger one with another like the giant screen, the less objects that may affect (interactive with) them the better. Like building on the bedrock layers, clearing or filled in caves and water lava blocks near by, remove glass and trees those will be affect by light and spawning creatures, etc) Maybe it will help.

PS. I am working on a demo small screen and a keyboard to test my own mega-build as well, it should be fun!!

Also, I tried doubling the screen width and everything slowed down and it crashed randomly as I was walking around. I think that the game is struggling with how big it is. ;S

Having you tried to clear out the blocks around where you build? If I remembered correctly, the blocks within your line of sight, and the blocks within 128 blocks will affect the "simulation speed". Since those blocks have to be "simultaneously" update in order to achieve the effect of a simulated minecraft world, if there are no objects in the "simulation zone", they are inactive. (unless triggered by the neighboring blocks), Thus I think that's why there is some rules like south-west rules, it's simply because they are the blocks been simulated first. Hence if there are many blocks interactively trigger one with another like the giant screen, the less objects that may affect (interactive with) them the better. Like building on the bedrock layers, clearing or filled in caves and water lava blocks near by, remove glass and trees those will be affect by light and spawning creatures, etc) Maybe it will help.

PS. I am working on a demo small screen and a keyboard to test my own mega-build as well, it should be fun!!

It's reasonably clear, I should probably check for lava and stuff around the edges though. I think I'll leave the screen at this size though, since it'll need to run while connected to the CPU and stuff.