Mike's PCjr Page

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

I think you should at least try it out. Do note, though, that while I do use KiCAD for schematic capture and preliminary component layouts, I've found trace routing on the PCB is best done by exporting a Specctra session file and opening that in Freeroute (freerouting.net), particularly for auto routing. Hand routing can be done well enough from within KiCAD, but Freeroute adds some touches that make things easier, as long as the component positions are finalized beforehand.

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

I used a 44 pin module on an IBM L40SX laptop that had a dead hard drive. It how has the distinction of being the oldest laptop that I know of with an SSD. I'm currently running my XT-IDE with external spinning rust drives on a cable and would like to preserve that function. Making a custom cable is possible - just not fun.

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

So you are certain that most of the IDE drives out there will tolerate a 16 bit operation to the 8 bit registers? I'm worried about how those things were implemented - there were a lot of corners cut. Even if it is allowed on paper it might not work on drives.

alanh wrote: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 see the logic now behind shifting the registers - to make room for the 16 bit data register while preserving the relative ordering of the other registers. The register numbering doesn't bother me at all, but the requirement to change all reads and writes to use 16 bits could cause a lot of damage. I'll have a look at the code tonight. (Hargle is the original source of the code but I made the PCjr changes and did the debug/bringup. I started with the 0.9 version of the code and removed a lot of features that we were not going to use, like multiple card support.)

alanh wrote: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 *good* parts of the BIOS might only be 16K, but there is BASIC and the diagnostics too. The total size is 64K. I think that making the requirement to replace the whole 64K or none of it is fine and is consistent with the way that cartridges can be used to replace the system ROM too. I know that the cartridges have "cartridge select" lines that are used to change the addressing to them; how does this get done with an expansion card?

alanh wrote: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.[/quote]

We need a front panel with blinkenlights.

Brutman wrote:So you are certain that most of the IDE drives out there will tolerate a 16 bit operation to the 8 bit registers? I'm worried about how those things were implemented - there were a lot of corners cut. Even if it is allowed on paper it might not work on drives.

It's not up to the host. All operations are always 16-bit. There is a 16-bit select signal but it originates on the drive signaling to the host. As I mentioned, 8 bit memory reads/writes will also still work, however with the write optimization, if you want to write 8-bits, you must do it with A0=1 and then the upper data lines to the drive will contain junk (which most drives will likely just throw away anyway, but to your point about cutting corners, you never know!) Reads to even addresses, whether 8 or 16 bit, will always trigger the chip select and catch all 16-bits coming from the drive. Then it's up to the firmware to read the high byte from the odd location - either explicitly through a separate fetch or implicitly through the 8088 16 to 8 bit double cycles.

And we're already long down the road of breaking XT-IDE compatibility by memory mapping things. However I suspect this board will be a test bed for another design round of XT-IDE in the future.

Brutman wrote:The *good* parts of the BIOS might only be 16K, but there is BASIC and the diagnostics too. The total size is 64K. I think that making the requirement to replace the whole 64K or none of it is fine and is consistent with the way that cartridges can be used to replace the system ROM too. I know that the cartridges have "cartridge select" lines that are used to change the addressing to them; how does this get done with an expansion card?

I did not realize there was more code in the BIOS than what is printed in the Tech Ref. The Tech Ref only has 16K listed, but it doesn't have BASIC which I thought was only available on a cartridge ROM. And what diagnostics are you referring too?

Cartridges and cartridge selects would still work basically the same. Other than the 16K option ROM window and the optional 64K system ROM remap, the card doesn't map anything else on boot. It's up to the card BIOS to look for any installed cartridges or other option ROMs by polling locations for ROM start signatures and lengths. It has complete discretion after that on if or how RAM or ROM gets remapped. The only thing that will be different from the factory behavior is the ability to disable and replace the system ROM with a cartridge when the system ROM image is served from on-card flash. There's no way to disable it since that override signal is only available on the cartridge edge connector.

Brutman wrote:

alanh wrote:The POST display is also on the verge of getting cut.

I'm uploading a preliminary schematic for review.

We need a front panel with blinkenlights.

I've figured out a creative way to save the POST display circuit w/o adding any components (it even eliminates the reset NPN & Rs). It involves a few schematic changes and a fair bit of route rework. But the IDE data lines are now better described as general purpose lines that have different behavior based on the asserted chip select. This allows me to mux the ROM address rewrite lines with the IDE data - freeing up 5 pins. I can do the POST latching inside the main CPLD and clock out alternating upper/lower nibbles on 4 lines running straight to the 4-bit hex to 7 segment decoder (DDR sync'd to the 32 KHz RCLK). I still think a ATF750 is needed to do the 7-segment decode as some of sums require 12 products! Unless someone knows of a discrete IC that will do 4-bit hex values to 7-segment 0-9,A-F decode and a way to provide enough common drive current w/o adding 3 NPNs and a half dozen resistors.

jmetal88, could you send me your mechanical dimensions for board, drills, and pins? I'd like to cross check them with what I have. I think I'm within about 20 mils accuracy but I'm going to build in some margin on the holes just in case. The 4 main holes are really the only thing that register the board in the case and I'm not 100 confident on those.. Paper is just too damned flexible and I'm lacking a good pair of calipers here.

I'm running a bit behind my schedule, but I'm fairly confident in the layout atm (changed a bit since last posting). And I am putting together a BOM tonight as well as laying out the little parallel port dongle board that has some resistors and a '244 for JTAG'ing the PLD. There is a new panel order going out Monday I should make.

Here's what I have on my board layout. I initially placed the holes and connector in mm, so some conversion may be in order. All dimensions are to the center of where the module was placed. Note that this is only as accurate as my paper was as well, I also lack a pair of calipers.

Sidecar connector: 94.5mm from left, 66mm from top
Left connector drill hole: 49mm from left, 66mm from top, 0.12in drill
Right connector drill hole: 140mm from left, 66mm from top, 0.12in drill
Upper left screwpost hole: 24mm from left, 9mm from top, 7mm drill
Lower left screwpost hole: 24mm from left, 66mm from top, 7mm drill
Upper right screwpost hole: 175mm from left, 9mm from top, 7mm drill
Lower right screwpost hole: 175mm from left, 66mm from top, 7mm drill
Board dimensions: 246mm x 76mm
Pin holes: .04in drill (I believe I just left this at the KiCAD default).
IDE 44 pin holes: .0315in drill, .0472in pad (this was just an estimate on my part, IIRC)

I hope that helps! At the very least you'll know if we're both in the ballpark or if one of us screwed something up.

Mine are a little different. Trying to figure out which is more accurate. My lower and left screw post holes line up with yours. However I have the uppers 9.5mm down from the top edge. And I originally had my drills at 6mm instead of 7. I recently made them 6.2 for margin. There are plastic grommets on the inner plastic case plate that are supposed to be the exact size of the hole so that the board snugly fits over them. I suppose once the connector is plugged in and the long screws started, things will line up. But until then, there isn't anything preventing the board from sliding around in the case a bit except for the tolerance of those holes. Going to take a case to work today and accurately measure those. Though the centers have to be just as accurate.

The pin holes on the connector I think need to be smaller than 1mm too unless people plan on soldering the pin tails in. The connector on the parallel card I salvaged simply had the pin tails friction locked in the annular ring. I have a few finished boards from the fab I'm using with 32mil drills I can test fit a few pins in tonight.

I have the connector drills at 48.6 x 66mm for the left and 139.5 x 66 for the right with a 3.2 drill. I might split the difference on those.

My pin A1 starts at 57.2 x 64.8 mm and of course spaced on a .1" grid.

Thanks for checking. We're not too far off - less than a mm is most cases. I hate trusting a cheap P1006 printer for this sort of stuff.

I measured the hole spacing today with a really good caliper. The horizontal separation is 151.0mm and the vertical separation is 56.3mm from center to center. The PCB drill size is 6.2mm. I couldn't take relative measurements of anything else as I only brought the back plastic shell piece with me. I was within 5 and 8 mils respectively on those offsets from my print measurements. So I think I'll input those relative offsets into my layout and then recalibrate the edges of the board and the position of the connector through printing. There should be enough tolerance in both to allow for a mm or two either way.

It was also a very good thing you posted your measures. I tried inserting the pin tails from the connector I pulled apart in a board with 32mil drills and sure enough - too small. Going to expand that to 1mm or more. That would have been a disaster to order them that way! I think I'm going to up the pad drills on all of the components to 1mm as well. Can't hurt and I've run into some resistors with some pretty fat leads before. And the register mark on the LED lead might cause a problem at only 32mil. It's just odd that is the size of most of the standard through hole library parts.

First spin PCB order is in. Depending on panel space in this run, I'll either get 3 or 6 boards in roughly 2 weeks. I've also posted the design files for the P1 spin here. The design has changed a little. Instead of dropping the POST display, I kept the PLD doing the decoding and used it to generated the quirky ALE timing necessary for the Maxim clock chip. Hopefully my understanding is correct and the code I've written will work. The second PLD is a smaller version of the main PLD and also in-circuit programmable. I also ordered 6 of the parallel port JTAG dongle boards. You will find the Bill of Materials for both in the side car design files, but don't order anything yet. The price is a bit expensive but $11 of the $48 in parts is the Maxim clock module. I want to get the boards in and build one up to make sure I can at least program it with the JTAG cable and run some basic access tests before anyone else commits to parts. There will be plenty of time to order parts while I send out the PCBs to people.

I also multiplexed the ROM page address lines with the IDE data lines dependent on the chip select active. This free'd up 5 lines to drive the IDE address and strobes directly. Also changing the second PLD to a larger package allowed the addition of the IOR/IOW strobes to the main PLD. Which means the IDE registers can be ordered any way at any IO or memory base with or without Chuck[G]'s optimization applied to reads or writes - all by changing PLD code. By condensing the board down to just the RAM/ROM/RTC chips and PLDs (only 6 ICs), it significantly minimizes the need for trace routing changes to significantly alter the behavior of the board.

With my current design size constraints in Eagle, I couldn't fit in the .1" pitch IDE header. Maybe we can get it in on the next spin once everything else is validated to this point. I'm going to start progressively adding information to the wiki page as I have time.

Awesome! I am really looking forward to seeing how this turns out.

Let me know what you need in terms of the BIOS. I'd like to get my hands on one to test and code for.


Mike