=========================================================================== John R. Hogerhuisjhoger at pobox.com <mailto:m100%40lists.bitchin100.com?Subject=Re%3A%20%5BM100%5D%2010.4%22%20LCD%20with%20the%20Model%20100&In-Reply-To=%3CCACutKUg_WATxG%3DfVPQE6mWcbSsp8eANThWJFhtw6KiM5NOvj8Q%40mail.gmail.com%3E> wrote: "The TRS-80 Model 100 has its system bus expansion port on the bottom. The
Tandy 102, the successor to the TRS-80 Model 100 has its expansion port on
the back of the unit. The connector looks like a parallel port, but is not a parallel port. The Model 100 and Tandy 102 have a parallel port but the connector looks and is compatible with the internal parallel port to motherboard cable used in PCs." ===========================================================================
Ahh! That makes perfect sense to what I was seeing now. Thank you. ========================================================================== Mike Steinmhs.stein at gmail.com <mailto:m100%40lists.bitchin100.com?Subject=Re%3A%20%5BM100%5D%2010.4%22%20LCD%20with%20the%20Model%20100&In-Reply-To=%3CCAHHfo1sURCQacqEdbuxuXe%3DFMXrCvjjxYhnqE%3D-AR5ZbdH%3D3OA%40mail.gmail.com%3E> wrote: "Sounds like an ambitious project ;-) You can send the display data out to a display via the com port and, if you need the port for something else, even the bar code port; there is also a terminal driver that is compatible with the M100's screen codes. Have a look here: https://bitchin100.com/wiki/index.php?title=VT100 " ========================================================================= So, there is no real "compatibility" issues to be concerned about as in there is no software really which relied on the specific hardware of the DVI? Using a COM port would leave my LCD driver pretty universal. My only concern with doing it that way is that it wouldn't support the bitmap graphics commands. It may be completely naive at this stage of research for me, but the most ideal would probably be to hijack the interrupt for the display output and override the kernel routine to move the video memory to another location that would be outside of the M100 through the expansion port. Then have my controller just scanning the video and attribute memories and painting the LCD. Pretty much just parallel to serial shift registers. It is probably something I could implement with a CPLD. But to do this, I will need to study the M100 kernel code. My naivete is probably going to get a rude awakening when thinking about how to deal with the screen size differences. Text is one thing as once you send the text, it can just live in the memory until pushed off the screen. Bitmap would mean being able to randomly address pixels in the memory. I will have to figure out how to handle that when the bitmap memory would be larger than the built in screen. In the end, I may just support text only. Or at least start there since it would be easier and provide some sort of early success to keep motivation.
