Mike's PCjr Page

alanh wrote: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.

Yup, all true. It's a good thing I did start manually routing though, as it allowed me to find a misnumbered pin on my Epson RTC module. Now that I have the net list fixed, I might try your suggestion about setting larger via clearances for the autorouter, though.

Checked the BIOS when I got home. It does check every address between C0000 -> EE000 in 2K increments. However the cartridge ranges (D0000 -> EE000) use a CRC where the option ROM addresses (C0000 -> CE000) use a checksum. So I'm not sure how much value there would be in adding configurable range support for the IDE BIOS above D0000. And they appear to be called in ascending address order.

What do you think about a 2.5" HD sticking out the back of the sidecar about an inch?

Here's a representation

The long dash line around the edge of the image (except on the right) is the rough outline of the sidecar plastic profile. The short dash line is how far the HD would extend.

Just a thought. I'm getting more comfortable with the CPLD design as this point. I might order a 3 board run this weekend once I clean up a few things. Would only be $67 total for the three. The parts kit would be ~$35 per board. Together that's cheap enough for me to throw one together and see if the CPLD approach is feasible. Would also validate a few things I've been learning on the bench for the last few days. That's worth it for me at least.

Hmm, that's an interesting thought. I'd be a little concerned about the amount of power a 2.5" drive connected straight into the sidecar would draw - although I've been running my PCjr with an extra 3.5" floppy connected off the internal power supply for months without any trouble, so maybe my concerns there are unwarranted. And, of course, using the CPLD would cut down on a lot of power use from the 74xx series chips anyway.

I gotta say, that board does look a whole lot better than what I've got so far. I think I'll wait to hear your results with this before I proceed with anything else.

jmetal88 wrote:I gotta say, that board does look a whole lot better than what I've got so far. I think I'll wait to hear your results with this before I proceed with anything else.

Don't let me stop you. The CPLD approach was just an experiment. But for what little it will cost vs the time I already invested, I kinda want to see if it will work now. Your 74xx design is way more authentic to the period. I know a lot of people care more about that than I. I'm currently planning on using an Atmel ATF1508 CPLD, though a 1504 may work and pin compatible. I also added a smaller PLD to do dual 7-segment latching/decoding/PWM driving. I couldn't find a suitable replacement that would do all of that for even a single digit as well as hex numbers in addition to BCD (the POST numbers on PCjr start at 0xFF and count down). So the ATF750 combined all of that into one chip - and that will probably be replaced with a 22V10 in the final changes (also pin compatible). It's functionality is simple enough, that it should never need changing and it can easily be left out of the BOM for people who don't want POST display (most people I would imagine). And most EEPROM programmers will also write it if one didn't want to buy it pre-burned.

My tentative plans are: Tonight clean-up and post the schematic to get a couple more pairs of eyes on it to check for any glaring problems. By Tuesday night, put together a final BOM, recheck all the data sheets and mechanicals, and order a parts kit from Digikey 2-day. By Thursday night, write up a short design doc on the basic board design and CPLD functionality (using what I already have as a basis). By the weekend, check actual parts vs print outs, integrate any changes/suggestions, perform a final check of the board, place order. I also plan on ordering the same number of DB-25M to 6 pin JTAG PCBs as there is a '245 and a resistor network and array in the middle of the two. It will take 2-3 weeks for boards to come in after order. A weekend to solder one up and do basic testing before sending out the extras to anyone else.

Lastly I just what to throw out my design as it stands today and see if anyone has anything they would like to add or would like changed.

- 44-pin 2mm IDE header - female / right angle flush mount to the board. There are two holes on the board near the connector that line up with a drive footprint. The idea was two mounting options. A) slip an actual drive into the connector and screw it down through the bottom of the PCB. It would protrude through the opening in the back of the sidecar about .8". But it would be an all-in-one 'hardcard' solution. B) Stuff a vertical 44 pin male connector instead and run a ribbon cable out through the back of the sidecar to a drive. I'm hitting the limits of my current version of Eagle. So unless I upgrade just for this project, I'm not sure if I have real-estate to co-layout a .1" 40 pin header along side the 2mm 44 pin holes. I'll check tonight.

- Card serves up a 16 KB option ROM image at one of 4 configurable locations via dip switches (C0000, C4000, C8000, CC000). The upper 128 bytes of the ROM window contains 16 bytes for IDE registers separated on word boundaries, 4 bytes for the RTC (more on that later), 2 internal registers for ROM/RAM remapping, and 106 bytes of scratch RAM.

- All IDE register access must be done through 16-bit memory store/load instructions. On reads from even addresses, A3..1 will be shifted down to A2..0, the appropriate IDE CS will go active, the lower byte will be returned and the upper byte latched. Reads from odd addresses will return the latched contents only. Writes to even addresses will only latch the written byte. Writes to odd addresses will perform the address shift, present the latched byte as the lower IDE byte, steer the bus data lines to the upper IDE byte, and assert the appropriate IDE CS.

- Via register bits, the option BIOS can turn on RAM back-fill for 8 regions depending on the results of a ROM signature check or other method of probing. The regions as of now are: 64->128 range, 16K at C0000, 16K at C4000, 16K at C8000, 16K at CC000, 32+32K at D0000 & E0000 (cartridge #1 ROM area), 32+32K at E0000 & E8000 (cartridge #2 ROM area), and 32K at F0000 (see below). 128K->736K RAM fill is always on. Areas occupied by on-card flash windows (also see below) implicitly disable RAM fill (by CS strobe XOR).

- Up to 512K on-card flash organized in 16K pages. A14..18 on the flash part are rewritten by the CPLD. The Microchip/SST parts come in 128K, 256K, and 512Kbyte densities in the same pin/package footprint. It's not CFI, but it's an early version of it. It doesn't have ID, but it is NOR, sectored, and supports page erase (4K) and burst programming. The IDE BIOS would always be served up into the configured address window from a fixed page number (probably 5 - +64K). Optionally addresses F8000 - FFFFF (32K) can be served up from pages 0 & 1 or 2 & 3 depending on DIP switch settings (also optionally turning off IDE BIOS). This allows adventurous people to replace their system ROMs with on-card flash that allows software upgrading/patching while still keeping a golden image you can revert to with a flip of a switch (vs re-inserting the original ROM chips). I know there are a few patches that people have made for JR ROM. And since the original ROM was less than 16KB, there's plenty of room to combine the IDE and system BIOS if you want even more UMB/RAM.

- A 16KB flash/ROM remap window can be enabled at anytime at C0000, C4000, C8000, or CC000. This window can be panned around in the on-card flash by setting a 5-bit target page number in a register. This allows the BIOS design to get creative in future possibilities. E.g. a boot menu with cartridge ROM images or a virtual A & B ROM floppy image / diskless boot.

- There are HD activity LED pads on board (for diagnostics) and a header so that one could run the LED out to a hole drilled in the front of the sidecar and glued in-place.

- Uses standard Dallas/Maxim all-in-one RTC module which allows for 190-something bytes of battery backed NVRAM - though I have no idea what it could be used for since there's up to 512K of flash on-card.

- Master/slave IDE cable select via dip-switch

- Bridging of IDE & PCjr bus READY signals via dip switch.

- Configurable routing of IRQs from IDE & RTC to IRQ 1, 2, or 7 via dip switches.

- All dip switch settings printed on board silkscreen

- All connector pin-outs on back of PCB silkscreen for reference.

- CPLD is JTAG in-circuit programmable with parallel port cable and free WinXP software from Atmel so that most of the above functionality can be changed or tweaked.

- Most of the board traces are 16 mil or larger with many being 24mil. The only exceptions being address line feeds to the CPLD (12 mil) and necking around the IDE header (10 mil). 10 mil global clearance / isolation. Most power traces are 32 mil (some 24). I have no clue on a power estimate at this point. TBD. All vias are .6mm drill w/ 8mil ring. All board drills are .6mm (vias), .7mm (IDE conn), .8mm (most everything else) and 1mm (JTAG & LED headers).

- Everything is through hole for the joy of those who have masochistic tendencies (pads, stencils, and paste = win imo).

- Only 4 signal VIAs. About 8 GND coupling VIAs (probably more later).

Any other input welcome!

Also I'd like any thoughts on maybe a repository where we can start aggregating design files.

In my opinion, I think you'd find it more worthwhile to learn KiCAD than upgrade Eagle.

The only thing I had trouble coming to grips with originally with KiCAD was the fact that drawing a bus on the schematic is meaningless to the program. Net names just connect to the same net names no matter where you put them - attaching them to a bus is pointless. The other 'feature' I haven't figured out yet (so I just ignore it) is hierarchical schematics. You should be able to create nice multi-page schematics with that, but so far I've just stuck to increasing the page size to keep the whole design in front of me.

Both of those are easy in Eagle. While I haven't used KiCAD, I can't imagine a GPL package is more or even equally capable to commercial software ranging into the thousands of dollars and is already way under-featured for my needs (eg. anything to help impedance matched trace routing would be a god-send). We use a variety of tools here where I work ranging up to 5 figures a seat. I just have to figure out a way to justify to my boss I need a separate license!

That's not really a problem though. My current CPLD design fits into the constraints of the non-commercial use paid license (only $125). I personally would not have a use for the 40 pin .1" header as I plan on either mounting a 2.5" HD or using a 44-pin industrial flash module. You had it on your design and while it costs nothing to add to mine (other than the CAD license), I'm just wondering how much it will be missed if I can't fit it. That's all.

Alan,

I think a Wiki is ideal for this kind of activity - I will check to see if I can add that. If not, there is always Google docs.

Comments on the design:

I'd prefer to see a 40 pin header if possible. That leaves the option open for normal IDE drives or industrial flash modules. I can get adapters to go from the 44 pin header to a 40 pin header (laptop drive on an IDE cable), but going the other way is more difficult.

I'm confused on the address line shifting on reads and writes. If I read it literally then a 16 bit read from an address ending in 0x0E (1110) will look like a 16 read of 0x7 from the IDE register set. The BIOS will see the low byte returned in 0x0E and the high byte returned in 0x0F. Have I got that right?

If so, then the first question is what happens on an IDE drive if you do a 16 bit register access to the non-data registers? I think that nearly all of the non-data registers are only defined to be 8 bits. (I just checked the ATA-4 spec to confirm this.) Only the data register needs to be 16 bit.

Requiring 16 bit reads and writes to all registers is going to cause a lot of rip-up in the code. And unless the main XT-IDE controller goes with this route, it pretty much guarantees that we are not going to share any code.

I like the ability to patch the system ROM - there are some BIOS bugs with keyboard handling, scanning for extra floppy drives, and counting beyond 640KB of RAM that we can fix with that facility.

I like that the CPLD is programmable .. it sounds like we can fix problems as we need to, as long as they are not trace related.


Mike

The 40 pin may be a problem then. And I'm not entirely sure what to do about it. Your points are valid except that I would like to point out the industrial flash modules also come in 44 pin self contained form. Which is pretty nice since they don't have an extra power cable.

Your summary of the IDE operation is accurate. All IDE operations are fundamentally 16-bit though only the data transfer register returns or accepts anything useful on the upper data lines. I went back a forth on this a while. The way things currently are, you could perform single byte reads from even addresses and it would fetch the lower byte and leave the latched data from the upper lines abandoned. You could also perform single byte writes, however you must do it to the odd address offset. In that case what gets enabled on to the upper data lines is whatever is hanging around in the shift latch. It might be best practice to always perform a word write, even if the high byte is 0xff, so that the upper data lines contents are always deterministic.

Existing compatibility with XT-IDE code is already broken for two reasons. The first could be reverted, the second I think I can make a case for. When Chuck[G] made his performance mod, it was less work to switch two address traces than to shift them all up. Shifting them up preserves natural IDE register order. It would have been the solution of choice if a soldering iron wasn't involved. I have no objection to changing that back for XT-IDE.mkII compatibility; even though it's less intuitive what's going on. The second thing that breaks compatibility is the write change. With the CPLD, it's possible to make the read and write data lane steering non-symmetrical without causing a mess of component to be dumped on the board. While it breaks compatibility, it applies Chuck[G]'s read performance improvement to the write direction as well. Ultimately it's up to whomever is maintaining the XT-IDE BIOS (Hargle?), but I think the change would be worth it and will probably be eventually integrated in a mk.III XT-IDE if that every comes along. This probably needs more discussion though the second change can be programmed either way in the PLD.

I'm revisiting the way ROM is remapped. I'm going remap all-or-nothing the whole 64K range from F0000 to FFFFF using the dip switch option from two 64K offsets in ROM. Even though the JR BIOS is less than 16K total size, only allowing a 32K remap of system BIOS area means people can't just perform a simple swap using the factory code w/o at least reassembling it w/ different origins. I'm also leaning against providing a switch choice to let the option ROM BIOS be completely disabled (eg. if you combined a modified system BIOS + IDE BIOS into F8000 -> FFFFF). It leaves the question of what to do with the IDE/RTC/internal register window. Of course both of these changes are reversible with CPLD code even though it means the silkscreen will no longer match. The only benefit to the prior schemes are more UMB area. And considering the JR has none atm, anything will be better than it is now.

The POST display is also on the verge of getting cut. I attempted to code up the 7-segment decoder logic today and just couldn't fit the combinatorial logic and the 8-bit latch in the same device; even a ATF750C. Each of the 14 LED segments require an independent summary cell and there are only 20 sum cells and flip-flops. And the only way to feed a FF is through a product sum; leaving only 6 for a 8-bit latch! The only other option is a larger PLD. I might lay it out on the prototype boards, but only stuff it on a few to gauge it's usefulness. Could drop it from a final design as it would only be useful to BIOS developers.

I'm uploading a preliminary schematic for review.