On 23 Apr 2007 at 18:47, Jules Richardson wrote: That's why we have disassemblers, no? Probably so--but then I said that I was lazy. ;-) Even in the "assemble it from chips" case, I'd rather use a Z180/Z280/64180/EZ80. Less wiring to do. Well, look at this one on our favorite auction site: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260110039855 Quite a bit of stuff in there for $20. CF IDE is easy--it's 8 bit. HD IDE uses a 16-bit data path for sector data transfer, so that makes things a bit more involved. Otherwise, the register set looks pretty much like a WD1003 PC-AT type disk controller. Cheers, Chuck

On 23 Apr 2007 at 20:47, Doc Shipley wrote: Misread the auction. ;( Forget it. --Chuck

On 24 Apr 2007 at 5:16, Ensor wrote: I still routinely disassemble drivers and ROMs--and the tools have gotten hugely better. A good diassembler such as IDA is wonderful. It's safe to say that there hasn't been an IDE drive manufactured within the last 10 years that supports 8 bit data transfer mode. Even many of those that claim to support it don't (probably just vestigal "cut and paste" text). I once went through my stack of 320MB and up 3.5" IDE drives and couldn't find a single one that actually supported 8 bit PIO Mostly, IOCS16- is ignored on most drives. There was a considerable amount of debate in X3T10 when ATA- 2 was being hammered out as to whether IOCS16- should even be included in the list of signals (it was removed when X3T10 defined ATA-3). It was reinstated in ATA-5 on request from the CF group. On CF, IOCS16- is honored--but it's not on any IDE hard drive you're going to buy today. Cheers, Chuck

On Tue, 2007-04-24 at 03:27 -0400, Sridhar Ayengar wrote: I have microdrives, I have CF-to-IDE adaptors, I have copious amounts of junk. I also have way too many other projects I need to spend time on (and yet other projects where I need to take the time to chase up the people I hired in because I don't have time to do them). It sounds too fun not to add to the list though ;-) Gordon

Holger Veit wrote: The reason I thought of Microdrive over regular CF is the canonical reason why people suggest Microdrives: greater write cycle lifetime. Peace... Sridhar

ROTFLMAO! TTFN - Pete.

On 28 Apr 2007 at 5:34, Ensor wrote: Yes--there's a free version (it's down-level 4.3 and is text mode and run on DOS) at: http://www.downloadjunction.com/product/software/69070/index.html ...and then there's the full-blown up-to-date commercial Gooey version: http://www.datarescue.com/ The GUI version is pretty neat, but you can get by with the text version. Supports a number of processors, including PDP-11. Cheers, Chuck

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