XT-IDE on PCjr

[Hargle]

Given the frequency of writes for me, I am not concerned about flash lifefime. For anyone who is concerned, it's a simple task to occasionally pull the CF card and create a back-up!

A write back disk cache would also help with this. I don't know how much/any wear leveling CF devices have- I'm guessing almost none, considering it is a very complex thing to manage.

When I build up a CF device for use in an old machine, I copy over a ton of files, but do it on a windows machine which should be caching all the individual writes to the FAT, which is where you're going to 1st fall into a block wear out condition.

A worn out CF device would likely just end up going into write protect mode instead of a total failure though, so you shouldn't lose any/much data, nothing that a norton disk doctor wouldn't be able to repair after cloning the data onto another drive anyway. Please note I said "likely".

[alanh]

A disk cache doesn't help much the way things are designed. Since the Int 13h caller supplies their own target far pointer for the desired block, 512 bytes have to be memcpy'd regardless. Given the memory mapped nature of the current transfer mechanism and slow cycle times of the Jr bus, it would only save the disk fetch time. For modern CF devices, that's negligible. Early on I was toying with a DMA design that would perform 16-bit transfers from IDE direct to on-card RAM with an independent clock, but the routing was getting a bit harry. That really would have been the king of all kings of IDE boards - upwards of 25 MB/s on a Jr!

I also regret now not routing the upper address lines going to the flash to the RAM parts as well. That way it would have been possible to remap the card RAM that is shadowing the first 128K physical, 192K cartridge and BIOS regions, and 32K upper video area (352K in all) into a page frame. A sort of poor mans EMS. It would be a relatively easy board change too. That way it could be used for a RAM disk. The plan at the time however was to fill the cartridge regions with card RAM for UMB support. However it was before I confirmed the data bus going to the side car connector was hard gated off by a ROM that is soldered directly on the MB.

Two places the functionality could still be expanded is the Cxxxx region can be filled with card RAM in independent 16K regions. The support is already present and I've tested it and it works. One of the four regions is always occupied with the option BIOS and register file. However the remaining three could provide 48KB of UMB. Possibly enough to load some things high if there were driver support. It also seems the existence of an entire 512K of flash with an second controllable paging window (both enable and panning page) seems to be a little known fact. The idea was to either turn this into a ROM disk or a set of persistent cartridge images that could be selected from the boot menu. Both features just need BIOS enhancements to work.

Early on I had toyed with the idea allowing the system BIOS to be replaced by an A/B copy in flash - select-able through a dip switch. However the side car bus is gated off for the Fxxxx segments in the same fashion as the Dxxxx and Exxxx segments - via a hard soldered ROM. So the idea lost momentum.

[Brutman]

three solutions for the lack of CHS support:

1) add CHS support to the BIOS. Lots of work for Mike and/or me. Lots of bugs, corrupt drives, time taken up that could be used for other things.
2) port a version of the XTIDE universal BIOS over to the jr. Only slightly less work for Mike, Me, and/or Tomi, but would be awesome to have this platform supported in that code base. Would make for the highest compatibility of drives on this platform. The XTIDE universal BIOS is way overkill for this platform.
3) use a modern drive/CF/DOM. No work at all, and if you really can't find a modern drive to use, you are not looking very hard. you should be able to 8 gig drives on craigslist at 50 cents per bushel!

I have at least 10 of these deficient WD drives that are 6GB in capacity, but do not support LBA addressing. It irritates me to no end. So there will be a CHS BIOS. It might not be compatible with other CHS mapping schemes, but it will let me use these @#$@ drives.

(I also have more than enough modern drives that support LBA addressing for when I get back to my senses.)

[Hargle]

A disk cache doesn't help much the way things are designed. Since the Int 13h caller supplies their own target far pointer for the desired block, 512 bytes have to be memcpy'd regardless.

I'm not referring to a performance gain.

What I'm saying that a write cache (when set in write back mode) will accumulate all the updates to the FAT in system memory when writing a bunch of files on a DOS partition. Then, when the traffic dies down, it will update the FAT on the drive as a single write. For spinning disks, this isn't that big of a deal. For CF devices, all those hits to the FAT can burn through your erase counts pretty quickly. Since CF devices have little or no wear leveling to spread out hits to specific flash blocks, a write back cache will help reduce the number of writes done to the physical media.

[Hargle]

does anyone with a rev A board have a picture of their finished design?
http://www.retrotronics.org/svn/jride/trunk/hardware/

Or, can we get the eagle schematics exported out to a pdf file so they are viewable to us non-design engineers?
I'm trying to find out which caps go where. the rev A boards have a slightly different number of caps than my prototype board (3 blue ones instead of 2, IIRC) and there appears to be no description of where they go and I don't want to guess.

thanks!

[Brutman]

Have you looked at the Bill of Materials? Every component has a location name that is printed on the PCB.

http://www.retrotronics.org/svn/jride/t ... _Rev_A.pdf


Mike

[alanh]

I checked in a PDF schematic in that same folder.

[Hargle]

perfect! thanks a ton for that.
my shipment of DOMs will hopefully be here next week so I can finally get my last cards built up and distributed in time for xmas...

[Brutman]

I've been looking for DOMs but not quite sure what to get. I have a 512MB one for use in an L40SX laptop. For the PCjr I was thinking of something closer to 1GB. MLC is probably adequate for our uses. But I have no idea which manufacturers are good vs. bottom of the barrel.

Can you share your source and what model you bought?

(My prototype jrIDE has the IDE pins sticking straight out - that made for a tight fit when I put an IDE cable on and enclosed it in a sidecar. The right angle version of the IDE connector is a significant improvement.)

[Hargle]

This is my latest find:
http://www.waste.org/~winkles/idejr_dom.jpg

I picked it up from here:
http://www.ebay.com/itm/Kingspec-8GB-DO ... 43af1bb5ef for $23
It's an 8GB module, which is way overkill for what we need to do, but the 8G DOMs are cheaper than the 4G, so why not!

Note this only works on the prototype boards that has the 44pin header.

The other module I have which works is the Kingspec 8G "industrial" variety:
http://www.ebay.com/itm/Kingspec-Flash- ... 0961889090
This module hangs off the back of the card and fits inside the shell easily. On the prototype PCBs, you need to add a wire to supply 5v on the key pin. Rev A boards just use the jumper to supply the voltage.

For total insanity, I did actually hook up BOTH the 40pin and the 44pin DOM's onto the same card, and yes, it worked exactly like you'd hope!

In the BIOS, they identify as such:
44pin DOM=KDM-44HS.4
40pin DOM=KDM-40VS.2

The upside is that the 44pin DOM lies perfectly on top of the PCB as pictured.
The downside is that the orientation and 44pin female connector means that there is absolutely nothing else in my computer collection which I can use to copy files to this DOM in bulk, which is exactly why I hooked up the 40pin DOM to the other connector and could bulk copy from there!

There was one other snafu:
I have a DOS 5.0 disk, with the PCjr patch applied to the boot sector. I boot to this disk, fdisk the DOM and then format /s it. The DOM would not boot. I could see it blip 1 time on the LEDs and then hang. Next thing I did was fdisk /MBR the drive, and after attempting to reboot again, I saw it blip 3-4 times on the LED and then drop me into BASIC. It turns out that I had to apply the same patch to my boot sector (located on cylinder 0, side 1, sector 1) before the machine would boot to it. that stumped me for a bit, as I thought that we only had to be done to the floppy disk you use to first boot to, not the HDD too.

Anyway it appears kingspec DOMs work great. I have a spare 44pin one if you'd like it.
They also have Micron flash on 'em, so they have to be good.