On Thu, Nov 9, 2023 at 4:02 AM Scott McDonnell <[email protected]> wrote:
> > 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? > > As far as I know, very little. Compatibility with DVI is more about leveraging the existing DVI hooks since the BASIC ROM was built by Microsoft to integrate with the DVI out of the box. > 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. > It's actually not that bad. There are memory variables to set text screen dimensions and software interrupt/hooks you can plug into that all programs use to "print". And all programs basically use VT52 codes for cursor positioning and whatnot. As to graphics... that's a horse of a different color. There are text block graphics codes. For pixel graphics... you may be able to subclass the PSET/ LINE commands but I don't know. Maybe someone working on the MVT100 thingy can speak to that. https://bitchin100.com/wiki/index.php?title=VT100 I guess most if not all the software you'd have to write would be on the embedded display side. -- John.
