Just looked at the jade “Big-Z” schematic. I don’t see anything major that stands out as different, however on a quick glance it looks like the DMA transfer circuit is pre IEEE-696. The handshaking should have an intermediate step clocked by the bus Phi signal going from XFER state I to II. That board seems to switch control immediately with pHLDA. Not sure it is critical however. But it’s issues like that that caused so much early frustration with S-100 users and DMA – and why even Jade went with Block IO ports.
On the S100Computrers/N8VEM board, double check all jumpers. Make sure Phi , Clock, MWRT are active after the DMA transfer. If you have our SMB you can easily single step the bus and see where things are going wrong.
To close the loop on this…
I dug out my spare Jade Z80 card and replaced it in the test system with everything *exactly* the same (same memory, floppy drive, Disk 1 controller and cable, and ROM) and it works fine — the drive operates normally and performs all operations that it didn’t with the Z80 Master card. So, there has to be something about the Z80 Master card that the Disk 1 doesn’t like. Very odd.
Has anyone tried this CPU board with “legacy” peripherals? Maybe I have a jumper messed up somewhere.
Thanks for the help!
Rich there are too many moving parts to really be of much help with the limited information you have there. All I can say is to be of any help it’s best to sequentially add boards to the system. Test them extensively, check and list ports one at a time by outputting/inputting data. Checking you get the same results with different board combinations. The CompuPro Disk 1 uses DMA to bring in data (as opposed to block I/O) so bus configuration/timing is very critical/difficult. Can you even read/write to the FDC chip ports on the board? Can you get a head restore command to work. If not, something drastic is wrong, probably port addressing. Use a logic probe with a small program to repeatidely input/output to a port.
Thanks. I guess my description was more late-night short hand than I had intended. The “test” system consists of the following: SSM serial card, CompuPro RAM17, CompuPro Disk 1 and the S100-Computers Z80 Master card. The floppy drives are YE-Data YD380 (from the IBM-PC/AT) which can be used in place of 8” drives in these systems (with the proper modifications to two signals). These drives work well and are reliable, plus you get something like 800k of storage.
The CPU is running at 4MHz with the 2MHz bus clock enabled. This is the same general configuration as my IMSAI (same speeds) but my IMSAI uses a TDL Z80 card.
The ROM code and all hardware is identical between the systems. The only thing different is the CPU card. I’ve even swapped things around to eliminate the memory board, floppy controller, or floppy drive, as being the problem. That’s how I arrived at something on the Z80 Master card as being the issue.
I just thought about this — I have wait states enabled on the Z80 card. I have to try disabling them. I didn’t have time to do that last night.
I’m using the Z80 Master board with a custom EEPROM for a “test” system for my IMSAI — I try a bunch of stuff out on it first before putting it in my IMSAI. It works pretty well for prototyping. Anyway, I’m putting a floppy disk system together to match my IMSAI — a CompuPro Disk 1 and two 5.25” HD drives (which emulate 8” drives) — so that I can do some other testing.
Is there any trick to getting old boards to work properly with the Z80 board? Everything is configured identically between the systems (the same console, memory, disk cards and identical floppy drives). I’ve swapped everything around, including the drives, and proven that the hardware works, so it has to be the Z80 card interacting with the Disk 1. The Z80 is set for 4MHz and all of the jumpers match the pictures. I have 1WS for memory and ROM and 2WS for I/O.
The actual symptom is that the floppy drive isn’t track stepping. Everything else is fine (memory access, console I/O, booting, etc.) and it does respond to certain commands such as RECAL. I checked the cable for signal continuity and it’s fine, too.
Any pointers, hints, tips or clues would be appreciated. Thanks!
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator