Sounds like a neat idea! I'll let you be the PLD guy since you know what you're doing there. Honestly, I'd rather buy your design than mine. But, we'll have to see how each one works out, I think.
Well, my autorouter has been running all evening and has got the VIA count down to 106 from 130. I'm thinking about stopping it and trying to rearrange the components, now. I'd feel more comfortable if it got closer to 80 vias unoptimized rather than 130.
Need some advice on connectors. I took the solder side shroud off a PCjr parallel port sidecar PCB. The pins didn't have solder on the rings on the top side of the board. So I figured it's on the underside. But without access, there's no way to wick it up with a braid or suck it out with vacuum. So I heated the entire board up to 220C to the point every solder joint on the board was molten. Used a thick pair of work gloves so I could get a firm hold on the board and connector and the thing was like Excalibur in stone. I couldn't separate the two. How do you remove this damned connector?
Alright, a quick update on the PCB routing progress. I've been messing around with the component locations and letting the autorouter run and optimize overnight. My last attempt came out with 103 vias after running overnight (although I didn't let the optimizer actually finish). My current attempt is sitting at 65 vias, which is an acceptable number to me, but I'm going to let the optimizer keep running throughout the day today to see how low it can actually go.
Minor suggestion: Add a 1x2 .1" header for HD activity LED (from the XT-IDE schematic). It would be nice to drill a small hole in the front end of the sidecar enclosure and hot-glue a dome LED with leads in the hole.
Hypothetically, if one were working on a design as a learning experience and it included... again hypothetically...
- a 5V CPLD in a through-hole package
- an extra RAM part
- a 512K flash because of cheaper price and easier to find
- and, via dip switch, allowed using part of the flash to provide the system ROM for those that like to tinker with such things.
Which would be more desirable to have:
System A)
- Allows any extra 16K chunk of flash (432K left after system and IDE BIOS) to be mapped in any 16K upper window via register control so that you could use it as a ROM-Floppy or cartridge emulator (do option ROMs get booted before cart ROMs?)
- Includes a dual 7-segment LED for POST code 0x80 display for various debugging needs.
- Includes a Dallas all-in-one 12887 RTC module to add NVRAM and reduce part count (though NVRAM is a bit pointless w/ flash)
System B)
- Only addressed 48K of the flash (IDE + optional system BIOS)
- No 7-segment POST display
- Used the Epson RTC part w/ battery holder, 3 Rs, and 2 Ds
- Allowed direct bus-mastering from IDE to card RAM (anything above 128K) @ 4.7 MB/s read or write.
Both systems include memory mapped access, the XT-IDE mk.II read enhancement, and a new write enhancement that is similar to the read enhancement. Lower data bytes are latched on even writes and committed on odd. But it does mean every IDE register write must be 16-bit (only applies to status regs).
The choice is drive by pin limitations. I'm at a cross roads... A or B. Again if I were even at a cross roads.. hypothetically speaking of course!
By the way, my 74xx version of the expansion board will definitely end up being manually routed. I have two different auto-routings done right now, but I'm not really happy with how the traces came out on either of them (particularly where some of the vias are placed really close to certain component pads).
cartridge emulation is interesting indeed. there are ~6 games that were released in cart format only. We have dumps of them, but without the cart itself, there isn't really a good way to play them. Seems like a bit of overhead to make 6 games available, but it's a fun option.
Most layout editors will allow you to specify minimum clearance between vias, pads, traces, board edge, etc. The auto router will respect that.
Vias aren't a bad thing. Generally speaking though, manual routing cleans up the board to a degree you can often use larger trace widths with lower impedance. None of this really matters on a 1982 technology design. So it's really just an aesthetic thing. The auto-router can go nuts and things will generally work. Once frequency times number of parallel lanes start going up, a ton of factors come into play.
One thing auto routers generally won't do is pin swapping. eg. swapping around inverters in the hex inverter chip to align traces. Or rearranging address/data lines on a RAM chip.
As far as the CPLD goes, it really is turning into a lot of work to try and cram the DMA engine into a 128 MC device where 100% of the pins are locked. I'm having to manual route quite a lot inside the PLD and the free tools do not offer signal propagation delay computations. I'm having to look at each chain in the pick and place report and add up individual delays from each path for each signal from in to out. Very tedious work to try and eliminate clock skew. I did take the DMA engine out as a test (for option A above) and everything auto-routes and fits just fine in the same device without a lot of the clock domain issues the DMA logic has. I may end up going that route just for simplicity.
I can't figure out what would be sexier, having a DOS program on a flash module insta-load or picking one of a half dozen cart images from the boot menu.
I just need Brutman check if option ROM images sitting in the Cxxxx range load before or after cartridge ROMs. I'm not at home so I can't look at the assembly dump in the tech ref. If option ROMs don't load first, then there isn't anything to program ROM remap registers or shadow the ROM into RAM where cartridges normally would go. Now that I think about it, I'm not even sure the JR BIOS will chain option ROMs at any location other than D0000 or E0000. I assumed that wouldn't be a problem since Brutman said he has a SCSI controller in an IDE->sidecar adapter. But he may have had to change the SCSI ROM location to match the cartridge #1 start (d0000).
If that's the case, I guess I could always remap the IDE BIOS at d0000 or e0000 then let the IDE BIOS code turn on/off all other ROM and RAM mappings - chaining to a cartridge image shadowed into RAM if that's what was selected from the boot menu.
The outcome of this investigation may affect jmetal88's design too. It may be pointless to try and map the IDE BIOS anywhere other than E0000 or D0000.
But, we'll have to see how each one works out, I think.