Junkbox CP/M system?

Jules Richardson schrieb: Depends on what LCD you have. There are "intelligent" ones with an own controller and row/column multiplexers which simply look like an 8bit I/O port to the system. They already have a character rom built in, so you just send them cursor positioning and ASCII codes. Making a terminal out of it is a matter of some afternoon coding. There are other intelligent "graphical" LCDs which provide >= quarter VGA resolution or alike, that feed bit maps through the same 8 bit I/O port; these are more flexible but require more CPU horse power. I made the experience that a plain Z80 with 4MHz is well occupied with controlling the screen I/O, so better make such a graphic terminal a separate subsystem to a real CP/M box. Then there are the "VGA" LCDs which have RGB inputs - you need a normal CRT controller for that. You can scrap one from a Hercules or EGA/VGA card; both are connectable to a Z80 bus with a few TTLs, or even take one of the numerous 6845 designes but I wonder if this is worth the effort nowadays. And finally, you can obtain dumb LCD displays with hundreds of row/column pins that allow individual addressing of each pixel directly. Not for the faint-hearted, particularly for the PCB design and the connectors. I won't recommend those, as you end up rebuilding the logic that all the "intelligent" displays already provide. You might infact look for embedded systems with a Z180 or better Z280 CPU (PLCC84) they have most of the stuff like MMU and DMA already built in which one needs to make a system with more than 64k. There are already SRAMs with 128kByte available, so no longer needs to build complex DRAM refresh schemes. Effectively, the software logic is the same. You have some registers where you put in head/track/sector information, wait for some ready status flag and read the data out or feed a block of data in. Differences exist between the layout of the registers, but are actually no stumbling block for any Z80 programmer. IDE is a little bit more comfortable as you don't have to deal with low-level disk formatting and bad-block handling. Blocking/beblocking to convert between 128 byte sectors and 512 byte disk sectors is still required, unless you leave this to CP/M+ (CP/M 2.2 IIRC didn't have this directly). OTOH, one could program an FDC to use 128 byte blocks on disk easily; which then will cause trouble with data exchange to a PC, however. OTTH, the logic for an FDC is typically more complex than for an IDE interface, usually because of some monoflop-based data separator, including some adjustment of resistors/capacitors. Personally, I tend to use CF<->IDE adapters and build the common three circuit TTL-IDE interface. -- Holger