MaxCoderz

LCD Module

I found this one on eBay, and I think it's the closest yet. This one actually lists the controller, so that's set. My next concern would be it's portrait orientation. Can it be hooked up to act as a landscape 320x240 screen?

Looks terrifying to solder. The controller looks pretty decent (I haven't read the datasheet fully, but it seems to support a number of different interfaces including the basic 8-bit direct transfer suitable for the Z80). Either way, does it matter that it's 240x320 instead of 320x240?

Ok, again, I'll keep looking, but this looks like the choice I may go with.

It only matters if I end up getting something like this:

Turn it on its side and change up your graphics routines?

Thats pretty cheap tho, i might just get one .

Well, you'll need to write the LCD driver yourself in any case. The LCD I'm using has bytes arranged vertically, like this:
instead of this, on the TI:
...which took a bit of getting used to!

Did you already mention the raycasting advantage that presents?

Maybe I did.

Well, you'll need to write the LCD driver yourself in any case.

What would that entail?

As in, when you draw something within the OS (be it text, a line, a bitmap or what have you) those graphics commands will have to end up affecting the output on the screen. Different LCD modules will have different methods of communication and different commands. For example, on the TI-83+ you have a single memory for the entire screen, can control the number of bits written to memory on each data write (6 or 8 ) and you can control how the "cursor" controlling where data is written to moves after each write (up, down, left or right). My LCD has two subregions (each 64x64 pixels) and you can write to the left one, the right one, or both on each command. Both versions of BBC BASIC (the one for the TI-83+ and for my own computer) share similar drawing code but have very different code to handle outputting data from the graphics buffer to the LCD.

So will this driver be inherent in the wiring? Or will it be software?

Software. You send commands to the controller chip to change what it displays on the LCD. What your software driver does depends on the format of these commands as documented in the datasheet.

Wouldn't that interfere with SymbOS / whatever I manage to get on there?

I don't know how SymbOS talks to the hardware, sorry. You may have to source a clone of the video chip used in the MSX2/CPC/whatever hardware SymbOS targets if you can't write your own video driver.

BBC BASIC makes high-level calls to the host interface (eg PLOT, CLS, CLG, OSWRCH) to output graphics and text. I'm not sure how SymbOS operates but it may do something similar. I can't really tell you what to do - if SymbOS is closed source and designed for particular hardware, about the best you can do is build a direct clone of that hardware and hope for the best.

You may have to source a clone of the video chip used in the MSX2/CPC/whatever hardware SymbOS targets if you can't write your own video driver.

Hmm... but I wonder how that would interface with the LCD?

This seems like it's getting harder every minute. Maybe I'll try and just get a linux shell running instead, or that other OS you linked me to.

That depends on the output of the particular video chip in use.

Unfortunately you do rather complicate issues if you have a piece of closed software designed specifically to run on a very small number of platforms, as the only way to run it is to replicate those platforms.