PDA

View Full Version : 8-Bit IDE Controller



Pages : 1 2 [3] 4 5 6

Scott_Christensen
April 21st, 2009, 07:36 PM
Checking back in on the progress, and that board looks awesome!



Originally Posted by hargle
>here's some interesting news:
>
>I received Bob Watts' Acculogic card in the mail the other day, and
>tonight I took the ROM off and put our EEPROM on it, and well, it
>just worked!
>All I had to do was change the base address of where our BIOS is
>looking for the code. (it will auto-detect eventually)

So conversely if you set the XT IDE board at 0x360, does the Acculogic ROM work in our board?

hargle
April 21st, 2009, 07:44 PM
I've got 10 PCBs, and I ordered enough ICs to build up 3 cards. I have enough other parts (sockets, brackets, caps, resistors, etc) to build all 10 cards.

The bracket won't fit on this revision of the PCB. We kinda knew that going in that there would be at least 1 spin of the board, so that's ok.

Some of the ICs are in flux right now, between standard and fast parts which is why I only bought enough of a mix to build 3 cards. (plus we have parts from the 2 wire wrap cards we could scrounge up)
I just didn't want to buy 10 sets of ICs until I really know the hardware is more stable than what I've seen on the wire wrap card. the PCBs should eliminate a lot of variables on the hardware side.

Once we get a good mix of ICs and everything seems like it's pretty solid, I'll order enough parts to complete the rest of the boards and those will then get sent out to testers.

Then we'll do the big one and bang out 100 cards.

Gotta say this is pretty darn cool to see an idea turn into a green PCB.

gerrydoire
April 21st, 2009, 08:09 PM
PCBs are in!

They look great, even fit into an ISA slot! :)

I think these things will be really easy to build up, with probably the most intensive soldering part being the 40 pin connector.

Fantastic job andrew!

Looks super!!! :):):):)

hargle
April 21st, 2009, 08:21 PM
So conversely if you set the XT IDE board at 0x360, does the Acculogic ROM work in our board?

I haven't tried it, but I'm not sure it will work. the acculogic has another IO port used at base+0eh which it is using for an alternate status register (I believe) and a way to drive reset to the HDD. Since we don't have that address decoding on our card, I suspect it'll simply hang waiting for the status to change.

Of course, since I have a working disassembly of that very option rom, I could always remove those bits and see what comes up next! (I'll do this when I get my PCB built up)

Druid6900
April 22nd, 2009, 12:20 PM
Mighty fine work, Jeff and Andrew.

Couldn't have done it better myself.

I'm going to search around for those plastic clips that some boards used to have that went on the top back of the PCB and screwed down to the backplane.

I have a card with one of those on it and, if I can find it, it may have a traceable number on it.

per
April 22nd, 2009, 02:57 PM
I just thought of something crazy...

How much video (8088 Corruption format) can you possibly get into 2Gb?

After a quick calculation, I figured you can catually fit just above 7 hours of 30 fps video with 22KHz sampled sound!

Equation:


(2gb * 1024mb/gb * 1024kb/mb * 1024b/kb) / ((2kb/frame * 1024b/kb + (22kb/sec * 1024b/kb)/(30 frame/sec)) * 30 frame/sec * 60 sec/min * 60 min/hour)

whitch simplifies to:


256^2
---------- Hours = 7.1 Hours
41 * 15^2


How long time would it take to convert a full-motion 2-hour film into 8088 Corruption format? :D

hargle
April 22nd, 2009, 03:57 PM
heh! that would be hilarious to have like "the matrix" on your 8088.

at the moment, I don't think the card is fast enough to sustain the transfer rate required. I'm not even using IRQs yet. There's a lot of optimizations to be done, but I think without DMA, there's little chance it can keep up with the demand. I dunno.

per
April 22nd, 2009, 10:11 PM
heh! that would be hilarious to have like "the matrix" on your 8088.

at the moment, I don't think the card is fast enough to sustain the transfer rate required. I'm not even using IRQs yet. There's a lot of optimizations to be done, but I think without DMA, there's little chance it can keep up with the demand. I dunno.

As long as it can handle at least 82Kb/s, it should be all right... What is the actual transfer capabilities of the card?

NobodyIsHere
April 23rd, 2009, 02:47 AM
As long as it can handle at least 82Kb/s, it should be all right... What is the actual transfer capabilities of the card?

Hi! Given the current developmental state of the XT-IDE board, I think Hargle is right in saying he doesn't know. Any answer now is rather meaningless since the BIOS and hardware are in flux. I wouldn't worry about performance until the basic functionality is fully wrung out and there is a stable hardware baseline to work with. These initial round of testing boards are not the final configuration but should give us a good idea.

Probably a realistic projection of what sort of performance is possible after a lot of development would be to extrapolate based on the Acculogic IDE card. Both XT-IDE and the Acculogic use similar design concepts so it is probably reasonable to expect similar performance.

I can tell you the prototype board I have is not very fast but I can't say what the actual transfer rate as I haven't tested it. However, I did get my XT-IDE test station built last night. A big Thanks! to DreadStorm for selling me some XT parts to make it happen.

Thanks and have a nice day!

Andrew Lynch

per
April 23rd, 2009, 04:17 AM
Hi! Given the current developmental state of the XT-IDE board, I think Hargle is right in saying he doesn't know. Any answer now is rather meaningless since the BIOS and hardware are in flux. I wouldn't worry about performance until the basic functionality is fully wrung out and there is a stable hardware baseline to work with. These initial round of testing boards are not the final configuration but should give us a good idea.

Probably a realistic projection of what sort of performance is possible after a lot of development would be to extrapolate based on the Acculogic IDE card. Both XT-IDE and the Acculogic use similar design concepts so it is probably reasonable to expect similar performance.

I can tell you the prototype board I have is not very fast but I can't say what the actual transfer rate as I haven't tested it. However, I did get my XT-IDE test station built last night. A big Thanks! to DreadStorm for selling me some XT parts to make it happen.

Thanks and have a nice day!

Andrew Lynch

the framerate can be reduced, and you will still be able to get decent ressults with a video of 12fps. That's only 46Kb/s.

hargle
April 23rd, 2009, 06:21 AM
As long as it can handle at least 82Kb/s, it should be all right... What is the actual transfer capabilities of the card?
yeah, I don't know yet.

1) The one program I tried to do xfer rates, coretest, fails to run with my BIOS.
I don't understand why, as all the INT13 routines are returning results back as they should. I suspect coretest may be doing stuff like looking at all the various status bytes stuck in the bios data area, and there may be something wrong there. I'm really only working with 40:75 (drive count) and 40:74 (last operation status).

I do want to get this to work someday.

If there are other benchmarking programs that work on XTs, I'd gladly run them to find out what our current xfer speeds are. Suggestions?

2) there are zero optimizations in the BIOS at this time. My goal was stability and reliability, then we'll switch to getting the performance up. There's lots of fun stuff we can do there to get performance up, and I'd love to start benchmarking to see how things do improve as we move along. I have a list of optimizations that I've thought of so far, and I'd like to implement each one individually and see how the performance changes.

I'm extremely curious to know what kind of improvement we're going to get between now and the end.

hargle
April 26th, 2009, 08:29 PM
minor success...

I built up 2 protocards and tried one of them out. No sparks or smoke, that's a good start.

Can't get the eeprom to decode. I used the one off my wire wrap card and nothing is showing up at d000 segment like it used to.

The IO space is looking as it should, I think. without a ROM, I really don't have a lot of tools to test it out properly, but I did issue an Identify Device out to a drive and saw data that looked reasonable. This test process is exposing some pretty big holes in the test process that I should write some software for.

Not too bad overall though.

The first card took me about 1:45 to assemble. My second card took about 1:00, so it's not too difficult for a novice solderer like myself to put these things together. Took another 20+ minutes to get all the chips inserted.

per
April 26th, 2009, 10:14 PM
I used the one off my wire wrap card and nothing is showing up at d000 segment like it used to.

Have you looked elsewhere?

hargle
April 27th, 2009, 05:52 AM
Have you looked elsewhere?
yeah, I thought of that too.
I started to poke around, but ran out of time and wanted to post my progress before heading off to bed. testing in debug on an XT was painful, but I saw that the D000 segment was full of E7's and it appeared to bleed into other segments as well. This card is the only option ROM I have in the machine, but it really looked like I was trashing the bus.

I then moved over to the 486 so I could test IO functionality easier, verified that worked, then also saw the same E7's on the 486. It's not writable memory either.

Tonight should be a lot more debugging time. I'll populate the other card and see if it's the same story, and only start to panic at that point.

stay tuned...

per
April 27th, 2009, 05:59 AM
yeah, I thought of that too.
I started to poke around, but ran out of time and wanted to post my progress before heading off to bed. testing in debug on an XT was painful, but I saw that the D000 segment was full of E7's and it appeared to bleed into other segments as well. This card is the only option ROM I have in the machine, but it really looked like I was trashing the bus.

I then moved over to the 486 so I could test IO functionality easier, verified that worked, then also saw the same E7's on the 486. It's not writable memory either.

Tonight should be a lot more debugging time. I'll populate the other card and see if it's the same story, and only start to panic at that point.

stay tuned...

Sounds like either a short or some miss-placed trace(s). Where is the schematics?

hargle
April 27th, 2009, 09:56 AM
andrew has a directory of stuff here:
http://n8vem-sbc.pbwiki.com/browse/#view=ViewFolder&param=XT-IDE

per
April 27th, 2009, 12:16 PM
andrew has a directory of stuff here:
http://n8vem-sbc.pbwiki.com/browse/#view=ViewFolder&param=XT-IDE

I found the complete old schematics of the card there, but the new schematics doesn't got the EEPROM logic included. Try to check the Ohm value between the /WE of the ROM Socket and the /MEMW of the ISA conector. Also try to manually drive some of the lines with a 5v source and Ground, and see if the signals get through (make sure to supply VCC and GND to the main power lines too).

I don't know how much you know about hardware, but the way I would have done testing is to manually set up a condition and seen if the rigth signals got through.

NobodyIsHere
April 27th, 2009, 03:32 PM
Hi Hargle! Thanks! The XT-IDE you sent arrived today and all is well. I put it together and it worked the first try. If anything works better than the prototype board does so that's good news.

If your ROM is not showing up did you install J1? J1 is the ROM ENABLE option jumper. If you don't have a 2 pin jumper and a jumper block just make an old school wire jumper.

I'll update the schematics and PCB layout on the wiki. Be sure to look inside the ZIP file for the latest on this version of the XT-IDE board. There will be an update once this test shakes out all the bugs and I position the bracket.

Thanks and have a nice day!

Andrew Lynch

PS, I uploaded some pictures to the wiki for your viewing pleasure. There is one picture of the completed prototype and four pictures of various stages of the boot process. The new board boots straight into Win98 command prompt no problems.

PPS, actually this is goodness. I can see one thing already that needs to be fixed in the production PCB; the position of the indicator LED is just not right. It seemed just fine when I was designing it but in reality it is just plain bad as its buried under the IDE cable. Oh well, I am glad its a prototype.

PPPS, if your board is not working then lets exchange boards. You are the BIOS writer and need the board more than I do. Now the prototype is out I am basically just another tester. I'll send you mine and you send me yours and I'll fix it. By the way, my EPROM burner does not support the SEEQ 28C64 chip so maybe that's the problem. The design was done with the ATMEL 28C64X datasheet in hand so maybe there is an incompatibility with the SEEQ part.

PPPPS, never mind. I just used my other EPROM programmer and it programmed the SEEQ 28C64 no problem. I stuffed into my wire wrap prototype and it works just like the ATMEL 28C64X. Everything boots and it works fine. I am packaging my board and sending it to your address.

hargle
April 27th, 2009, 08:13 PM
my second card worked!

I appreciate the offer andrew, but keep your card. I need to learn how to debug these things if I'm going to build any more of them, and now I have one that works. I'm using the original atmel rom on it, but at least I'm up and running!!

It appears to me that I don't have any issues with timings either. The wire-wrap card seems like it lost some data on ctrl-alt-del vs. a power up condition, but this proto card seems to be working perfectly. That's with a sample size of 1 hard drive though, but it was traditionally one that caused me problems.

So, I'm going to burn through a bunch of different drives now and play some IC swapping to come up with a decent parts list. That'll be this weeks work.

yay!

edit: just flashed the seeq eeprom with software. (sorry per, I haven't tried your latest effort yet, but I will)
Edit2: I've now tried 3 of my most troublesome drives: 2 seagates and a maxtor, and all three of them were rock solid through warm and cold starts. I think we have a winner.

Wow, I have so much more testing and exploring that I want to do now, too bad it's time to quit for the night. argh!

per
April 27th, 2009, 10:17 PM
PPS, actually this is goodness. I can see one thing already that needs to be fixed in the production PCB; the position of the indicator LED is just not right. It seemed just fine when I was designing it but in reality it is just plain bad as its buried under the IDE cable. Oh well, I am glad its a prototype.

Great work!

Another thing I would like to be added is a "Dissable Writes" jumper that simply applies +5v on the /WE line of the EEPROM when jumpered. There is several 8Kb * 8 EEPROMS that doesn't support data-protection (in fact, the only one I know of is the Atmel AT28C64B, not the AT28C64X).

I'll get my XT on friday.

NobodyIsHere
April 28th, 2009, 02:56 AM
Hi! I need a list of the latest discoveries on the prototype for the respin. What I have so far is:

1. mounting holes for the bracket
2. move the indicator LED
3. write enable jumper for the EEPROM

There was an other list of items for the respin earlier in this thread which I've already implemented so these are the new and/or remaining issues.

As for the new prototype PCB, I've noticed it seems a bit more responsive than the wire wrap prototype as well. I can't prove it but the new prototype just seems "crisper" and things are moving more quickly. That's not unusual though, I've often noticed that I can get prototypes to work but when moved to a PCB the design just seems to respond better and more reliably.

It may be partially just a perception but there is probably some truth to it. The PCB has much shorter leads and more direct traces that are probably lower impedance. I suspect the wire wrap prototypes add in a bunch of noise due to RLC effects of all the wires. That Hargle noticed that some drives now perform better than before seems pretty compelling that something has changed for the better. That's good.

So things are moving along in a positive direction. I have only one remaining question though... what happened to the first PCB prototype? What I'd do is print off the schematic and PCB layout from the wiki and use the VOM to do a connection by connection wring out, marking each connection as you go. Also, use a bright light and a magnifying glass to inspect each of the solder joints for misses, cold solders, bridges, etc. Go over the board again and remelt all the joints with your soldering iron to wipe out any cold joints and remove any excess solder. Check each IC for bent or wrapped under pins in the socket.

You can also use the VOM to find hidden bridges by inspecting continuity between pins and comparing to the schematic. Failing all of those, leave the working prototype PCB board alone and get some more ICs and do a chip swap to isolate the broken part. If the ROM still does not appear in the memory map, the problem has to be in or near U9, U10, RR2, or SW2 since it is basically a separate subsystem.

If you've got a logic probe check to see if U9 is generating the chip select pulse when you access the ROM in the memory. That'd be U9 pin 19 or U10 pin 20. You can always send it to me and I'll beat on it for while but you're right that you're going to need to debug these things when the project moves to a production phase as issues found in assembly is normal.

Thanks and have a nice day!

Andrew Lynch

per
April 28th, 2009, 04:21 AM
Hi! I need a list of the latest discoveries on the prototype for the respin. What I have so far is:

1. mounting holes for the bracket
2. move the indicator LED
3. write enable jumper for the EEPROM

There was an other list of items for the respin earlier in this thread which I've already implemented so these are the new and/or remaining issues.

As for the new prototype PCB, I've noticed it seems a bit more responsive than the wire wrap prototype as well. I can't prove it but the new prototype just seems "crisper" and things are moving more quickly. That's not unusual though, I've often noticed that I can get prototypes to work but when moved to a PCB the design just seems to respond better and more reliably.

It may be partially just a perception but there is probably some truth to it. The PCB has much shorter leads and more direct traces that are probably lower impedance. I suspect the wire wrap prototypes add in a bunch of noise due to RLC effects of all the wires. That Hargle noticed that some drives now perform better than before seems pretty compelling that something has changed for the better. That's good.

So things are moving along in a positive direction. I have only one remaining question though... what happened to the first PCB prototype? What I'd do is print off the schematic and PCB layout from the wiki and use the VOM to do a connection by connection wring out, marking each connection as you go. Also, use a bright light and a magnifying glass to inspect each of the solder joints for misses, cold solders, bridges, etc. Go over the board again and remelt all the joints with your soldering iron to wipe out any cold joints and remove any excess solder. Check each IC for bent or wrapped under pins in the socket.

You can also use the VOM to find hidden bridges by inspecting continuity between pins and comparing to the schematic. Failing all of those, leave the working prototype PCB board alone and get some more ICs and do a chip swap to isolate the broken part. If the ROM still does not appear in the memory map, the problem has to be in or near U9, U10, RR2, or SW2 since it is basically a separate subsystem.

If you've got a logic probe check to see if U9 is generating the chip select pulse when you access the ROM in the memory. That'd be U9 pin 19 or U10 pin 20. You can always send it to me and I'll beat on it for while but you're right that you're going to need to debug these things when the project moves to a production phase as issues found in assembly is normal.

Thanks and have a nice day!

Andrew Lynch

Awesome stuff you got there. The card itself looks awsome too!

I might try to write a Diagnostic tool that just does a set of standard Int 13h calls and reports/checks what's returned.

I feel like i'm kindof done with the flasher since I don't want to tweak it for optimal write speeds for every single EEPROM in the world. Both the EEPROMS you have been reffering to so far should work with fast-write mode.

Below is the current beta. See the Wiki about how to use it, or just use "/?". It should be WAY easier than taking the EEPROM into an EEPROM burner and then taking it back to the IDE-card.

hargle
April 28th, 2009, 06:10 AM
Hi! I need a list of the latest discoveries on the prototype for the respin. What I have so far is:

1. mounting holes for the bracket
2. move the indicator LED
3. write enable jumper for the EEPROM


An external LED jumper/connection would be nice. I could see people wanting to string an LED over to a faceplate in a drive bay.

As for holes for the bracket, mouser doesn't have enough brackets to do a run of 100 parts. (although they may be able to if I order them now and they can backorder them by the time the next batch arrives)
I'm thinking that you might want to put a small series of holes along the side of the PCB so that other brackets with different mounting holes could be scrounged up and used, just in case. I checked the mouser bracket against the few that I had from other plug-in cards and the mounting holes were in different locations on each. If you have any other brackets, go ahead and make holes so those would fit too.

Can we save some $$ if we remove some of the gold teeth? I count at least a dozen on the B side of the card that aren't connected to anything. I think if we wanted to try for a DMA solution someday, we could use these first protocards and dead bug the hardware on to prove it out.

For silkscreen changes, it would be great to have some documentation along the bottom edge of the ISA slot, where it currently says "BUS1".
Something for the jumper settings at a minimum (not the dipswitches, I think that'll be too hard), and maybe even "XT-IDE www.vintage-computer.com" along the bottom would look good.

I'd also like to see a marking for pin 1 on the IDE connector. I should probably look into getting keyed connectors too, instead of just flat headers.


Should we document these changes in the wiki? I'd hate to lose a good idea here because it's buried in the thread.

NobodyIsHere
April 28th, 2009, 08:01 AM
[snip]
Below is the current beta. See the Wiki about how to use it, or just use "/?". It should be WAY easier than taking the EEPROM into an EEPROM burner and then taking it back to the IDE-card.

Hi Per! Thanks! Excellent work! I agree, swapping chips in and out of a PCB is a bad idea if its more than a couple of times. In circuit reprogramming is very good.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
April 28th, 2009, 08:10 AM
An external LED jumper/connection would be nice. I could see people wanting to string an LED over to a faceplate in a drive bay.



Hi! Thanks! Yes, I think this is in there already.




As for holes for the bracket, mouser doesn't have enough brackets to do a run of 100 parts. (although they may be able to if I order them now and they can backorder them by the time the next batch arrives)
I'm thinking that you might want to put a small series of holes along the side of the PCB so that other brackets with different mounting holes could be scrounged up and used, just in case. I checked the mouser bracket against the few that I had from other plug-in cards and the mounting holes were in different locations on each. If you have any other brackets, go ahead and make holes so those would fit too.



I can put in multiple holes but they need to be for a specific bracket so I can get the exact locations. The prototype board has a set of holes on it. Tonight I will see if the bracket fits on it and if so, I'll replicate the prototype boards bracket mounting holes.




Can we save some $$ if we remove some of the gold teeth? I count at least a dozen on the B side of the card that aren't connected to anything. I think if we wanted to try for a DMA solution someday, we could use these first protocards and dead bug the hardware on to prove it out.



Possibly eliminating gold teeth may save a little bit but not very much. Removing teeth has to be done carefully as you never know when they'll be needed for some unforeseen modification. I suspect on the production PCB there will be fewer unallocated teeth since I added the flexibility for different interrupts. Let me look into this. If its just a small number of teeth its probably not worth it.




For silkscreen changes, it would be great to have some documentation along the bottom edge of the ISA slot, where it currently says "BUS1".
Something for the jumper settings at a minimum (not the dipswitches, I think that'll be too hard), and maybe even "XT-IDE www.vintage-computer.com" along the bottom would look good.

I'd also like to see a marking for pin 1 on the IDE connector. I should probably look into getting keyed connectors too, instead of just flat headers.



Agree. The silkscreen needs some TLC to make it more obvious.

Thanks and have a nice day!

Andrew Lynch




Should we document these changes in the wiki? I'd hate to lose a good idea here because it's buried in the thread.

NobodyIsHere
April 28th, 2009, 04:59 PM
Hi Hargle! OK, I added the write enable jumper to the design.

Worked a bit on the bracket and discovered that bracket is not going to work. I installed my board in the test station and also the bracket. I used a pin to scratch through where the screws would go. Try installing it yourself and see if you can duplicate my results.

It turns out the bracket's holes need to be deeper and higher on the board. This bracket places its lowest hole almost directly in the lower right hand corner of the board. The holes would be centered 5/32" left of right hand edge and the lower hole would only be centered 1/8" above the bottom edge and the higher hole 2 3/8" . The bracket appears to need a 1/8" diameter hole so you can see that leaves almost no margin (~1/16") of PCB material for strength. The bracket would surely break off in normal use.

I'll search around at Mouser to see if they have a different part we can use. However, the more I think about it, I like the idea that Richard brought up about using one of those single hole plastic brackets.

Thanks and have a nice day!

Andrew Lynch

hargle
April 28th, 2009, 06:12 PM
yep. I see exactly what you mean:
http://www.waste.org/~winkles/bracket.jpg
I assume an extra route of PCB to dangle down lower than the connector would cost extra bucks due to the additional cutting the PCB folks would need to do?
What a bummer.


Let's go find those plastic bits. that's our only hope.

The acculogic card has one. It's got a part number that says "63-000332-B" patent number 4745524

http://www.google.com/patents?vid=USPAT4745524

I don't have time to search much, but maybe that'll give us some leads. If we can find them, they're probably cheaper than the $1.89 per metal bracket from mouser!

Edit1: Per, your latest flash utility works great.
Andrew: here's the latest version of the bios: http://www.waste.org/~winkles/xt-ide_003.zip

Edit2: Just finished going through the LS vs. F parts, and none of them seem to matter to the functionality of the card. I swapped out the 245, 32, 04, and 573s and with all F parts at the moment, the card is still working great.

Price wise, the 245F is cheaper than the 74ls245 by about 20 cents each when ordering 100 pieces.
The F32 is more expensive than the LS by 3 cents.
The F04 is the same price
The 573s are significantly cheaper in the F series. The F's are .12 each at 100, where the 74ls573 are a whopping 1.95 each at 100!!

So, my suggested parts list is:

1 * 74LS138 - No substitutions available (0.29 each)
1 * 74LS04 or 74F04 (0.25 each)
1 * 74LS32 (0.22 each)
3 * 74F573 (0.12 each)
2 * 74LS688 - No substitutions available (0.85 each)
1 * 75F245 (0.25 each)
1 * 28C64 eeprom - no substitions (3.25 each)
2 * dipswitch (0.59 each)
2 * sip resistor packs (0.49 each)
1 * 40 pin connector (0.55 each)

So the main components total cost is ~$9 when we buy 100.
Add in the other bits and pieces: LEDs, resistors, caps, sockets, etc for another buck or so, and I think we'll just scoot under $10 for components. If those bracket bits don't break the bank, we're still looking really good for a sub $50 card!

It's too bad those damn eeproms are so expensive. the SOIC's are 1/3 the price.

NobodyIsHere
April 29th, 2009, 03:46 AM
yep. I see exactly what you mean:
http://www.waste.org/~winkles/bracket.jpg
I assume an extra route of PCB to dangle down lower than the connector would cost extra bucks due to the additional cutting the PCB folks would need to do?
What a bummer.



Hi! Yes, I can adjust the outline of the PCB by adding 25 mils to the righthand side and making a little bump out for the lower hole. However, you are right that any adjustments to the PCB outline will increase area and drive costs up. Maybe not by much but some. Also any bump out on the PCB outline protruding down runs the risk of interference with motherboard parts. I don't see it as much of risk but some.





Let's go find those plastic bits. that's our only hope.

The acculogic card has one. It's got a part number that says "63-000332-B" patent number 4745524

http://www.google.com/patents?vid=USPAT4745524



After reviewing this patent there is no doubt in my mind that this is the way to go assuming we can find these plastic or metal clips. They would be ideal for this application. Leave the blank ISA filler bracket in place and drop the board in on top. That is very slick and a great idea. Depending on what we find it may not require any holes at all or maybe just one. I will dig through my ISA boards and see if I can find any part numbers. A quick search didn't reveal any though.





I don't have time to search much, but maybe that'll give us some leads. If we can find them, they're probably cheaper than the $1.89 per metal bracket from mouser!

Edit1: Per, your latest flash utility works great.
Andrew: here's the latest version of the bios: http://www.waste.org/~winkles/xt-ide_003.zip

Edit2: Just finished going through the LS vs. F parts, and none of them seem to matter to the functionality of the card. I swapped out the 245, 32, 04, and 573s and with all F parts at the moment, the card is still working great.

Price wise, the 245F is cheaper than the 74ls245 by about 20 cents each when ordering 100 pieces.
The F32 is more expensive than the LS by 3 cents.
The F04 is the same price
The 573s are significantly cheaper in the F series. The F's are .12 each at 100, where the 74ls573 are a whopping 1.95 each at 100!!

So, my suggested parts list is:

1 * 74LS138 - No substitutions available (0.29 each)
1 * 74LS04 or 74F04 (0.25 each)
1 * 74LS32 (0.22 each)
3 * 74F573 (0.12 each)
2 * 74LS688 - No substitutions available (0.85 each)
1 * 75F245 (0.25 each)
1 * 28C64 eeprom - no substitions (3.25 each)
2 * dipswitch (0.59 each)
2 * sip resistor packs (0.49 each)
1 * 40 pin connector (0.55 each)



Where are you ordering these parts again? Jameco? You can probably substitute 74LS688 with 74HCT688 and those may be cheaper. Also use 27C64 EPROMs and that would be cheaper but not field reprogrammable. Lack of reprogrammability is probably a deal breaker though.





So the main components total cost is ~$9 when we buy 100.
Add in the other bits and pieces: LEDs, resistors, caps, sockets, etc for another buck or so, and I think we'll just scoot under $10 for components. If those bracket bits don't break the bank, we're still looking really good for a sub $50 card!

It's too bad those damn eeproms are so expensive. the SOIC's are 1/3 the price.


SOICs are cheaper but require surface mount techniques to install. That drives assembly labor up and also most hobbyists are not going to touch it. What about PLCC?

Thanks and have a nice day!

Andrew Lynch

dongfeng
April 29th, 2009, 04:57 AM
Why not leave the card without mounting holes - then the user provide their own bracket and can drill holes in suitable places.

I've got loads of old/broken cards I can rob the brackets from. Just a thought :)

hargle
April 29th, 2009, 05:33 AM
Why not leave the card without mounting holes - then the user provide their own bracket and can drill holes in suitable places.

I've got loads of old/broken cards I can rob the brackets from. Just a thought :)

Yep, I agree with this too. Just push all the traces over 1/2" or so and just leave that edge of the card blank. Users can provide their own bracket and drill their own holes if needed. Especially if we can't find the little tab thingies.

hargle
April 29th, 2009, 05:39 AM
You can probably substitute 74LS688 with 74HCT688 and those may be cheaper. Also use 27C64 EPROMs and that would be cheaper but not field reprogrammable. Lack of reprogrammability is probably a deal breaker though.


The 74HCT688's are $0.28 compared to 0.85, so that just saved us over a buck. Nice! I'll order some HCT688's in my next batch and see if those impact performance any.

yeah, gotta have field programmabilty on the eeprom. it's just too cool to do without, and with open source, people are certainly going to want to experiment.

Jorg
April 29th, 2009, 08:02 AM
I lack skills to contribute to this topic but I'm following it with amazement - its like a McGyver episode to me..unbelievable.

Can't believe its already going so far that the main problem to discuss is the bracket :D

I'd be happy to apply my regularly applied fixing solution if it can't be solved:
http://www.nonpaints.com/contents/media/t_straaltapezilver.jpg

You guys are amazing!

NobodyIsHere
April 29th, 2009, 08:16 AM
Yep, I agree with this too. Just push all the traces over 1/2" or so and just leave that edge of the card blank. Users can provide their own bracket and drill their own holes if needed. Especially if we can't find the little tab thingies.

Hi! I think this is the best idea yet by far. Reuse scrap brackets and let the builders use their own (or not). Making a 1/2" trace exclusion zone on the PCB will give the autorouter fits but I can live with that. This is a very appealing solution to me.

To be fair, KiCAD is an EDA tool and not really a CAD program. It does PCB layout well but has fairly crude facilities for the mechanical aspects. It is somewhat ironic that the humble bracket has turned out to be the most complex part of the hardware design yet. :-/

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
April 29th, 2009, 08:27 AM
The 74HCT688's are $0.28 compared to 0.85, so that just saved us over a buck. Nice! I'll order some HCT688's in my next batch and see if those impact performance any.

yeah, gotta have field programmabilty on the eeprom. it's just too cool to do without, and with open source, people are certainly going to want to experiment.

Hi Hargle! Thanks! Substituting 74HCTxxx for 74LSxxx is probably OK to do in general and could be applied to other parts too. Those parts which require sufficient drive capability such as the 74F573s which interface to the IDE device directly probably should remain 74Fxxx parts. The rest could be mixed 74LS, 74F, or 74HCT depending on what's available and the best deal.

I encourage everyone do start their own parts list for the XT-IDE and see who can get the best deal for the parts. Do multiple lists at multiple vendors. If several people can identify some savings it could dramatically reduce the overall cost.

Thanks and have a nice day!

Andrew Lynch

linuxlove
April 29th, 2009, 08:36 AM
wow 54 pages...

anyway, would the XTIDE project support CD-ROM drives or no?

NobodyIsHere
April 29th, 2009, 08:47 AM
Hi! Another thought on brackets... I could just place a couple of holes on the PCB and we could use a couple of these (http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?productId=1581530) so builders could make their own bracket fairly easily. Just drill a couple holes into a blank bracket and fasten to the card with two 4/40 machine screws.

Blank brackets are really inexpensive and the right angle mounting brackets are pretty cheap too.

Thanks and have a nice day!

Andrew Lynch

hargle
April 29th, 2009, 09:17 AM
anyway, would the XTIDE project support CD-ROM drives or no?
yes. eventually anyway.

it'll require a driver to be written though, and that's a lot of work. I haven't found any open source CD-ROM drivers to start with, so the whole thing would need to be written from scratch. I suspect it could easily take a few months of work.

I don't see any hardware limitations that would keep CDs from working, but I haven't explored it too much yet. At the moment, all that the BIOS does is ID them during POST.

NobodyIsHere
April 29th, 2009, 11:08 AM
[snip]

I don't see any hardware limitations that would keep CDs from working, but I haven't explored it too much yet. At the moment, all that the BIOS does is ID them during POST.

Hi! There is an N8VEM builder who is working on ATAPI drivers for the Disk IO board. Apparently he has some of the ATAPI drivers for a Zip drive working to some degree. Check on the N8VEM mailing list for Dan Werner's recent posts. You may want to contact him in case there is some possibility for shared code between N8VEM and this project.

Thanks and have a nice day!

Andrew Lynch

Unknown_K
April 29th, 2009, 12:14 PM
Would be cool if we could make a hardcard out of one (basically mount a HD on the end with some metal brackets). yea, I know thats not going to happen.

hargle
April 29th, 2009, 01:35 PM
Would be cool if we could make a hardcard out of one (basically mount a HD on the end with some metal brackets). yea, I know thats not going to happen.
There's nothing stopping you from mounting an IDE->CF adapter on it though.
Totally lightweight and could be ziptied on to the card with little or no effort.

Terry Yager
April 29th, 2009, 02:41 PM
There's nothing stopping you from mounting an IDE->CF adapter on it though.
Totally lightweight and could be ziptied on to the card with little or no effort.

I'm pretty sure that's my plan at this point...That or a 2.5" mechanical laptop drive.

--T

NobodyIsHere
April 29th, 2009, 06:47 PM
Hi! I posted an updated PCB layout on the wiki.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
April 30th, 2009, 03:34 AM
Would be cool if we could make a hardcard out of one (basically mount a HD on the end with some metal brackets). yea, I know thats not going to happen.

Hi! Whether this is feasible depends on what it means to the design. If its just a matter of adding some holes and minor rearrangement of the existing design it might be possible. If its a major redesign and/or drives an increase in PCB area its probably not feasible.

I really don't know what this means to the PCB layout so I can't really answer. Please post some examples to illustrate the effect on the PCB design. (not just pictures of a hard card as I know what those look like)

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
April 30th, 2009, 04:29 PM
Hi Hargle! Tonight I did some testing with the new PCB prototype on my XT test station. After some reconfiguring, I got the latest BIOS (oprom ver 003) installed. I can boot from the floppy drive and use fdisk and format to install MSDOS 5.0. I can see the controller IO ports and ROM from DEBUG. If I boot with the floppy drive, I can see the C: is present and appears to work. I can even see the BIOS boot screen identify my WDC IDE drive for an instant before it disappears.

The bad news is that when it tries to boot from the IDE drive, the LED flashes a couple of times and the XT goes off to la-la land. Not terribly descriptive but the XT ends up hanging hard with an apparent 40 column mode cursor flashing in the upper right hand corner.

I think there is a problem with the BIOS on my XT. Its a generic clone, made by MCT. I am running at 4.77MHz with a VGA card, one of those JDR multifloppy cards, a serial and parallel board and regular XT keyboard. Everything seemed to be working with the Seagate MFM hard drive & controller. I removed the Seagate MFM controller to preclude a clash between the controllers.

Would it be possible to make a test version of the BIOS with prompts for each stage like the earlier versions had? That was really helpful in debugging. All I can say for sure now is that it crashes on boot but appears to be OK otherwise.

Now I have two controllers working; the wire wrap prototype board version running the earlier version of the BIOS which works great and the new PCB prototype running the latest BIOS with some type of problem.

Suggestions on how to move forward appreciated.

Thanks and have a nice day!

Andrew Lynch

hargle
May 1st, 2009, 06:10 AM
Was this a drive that you fdisk+formatted using an older rev of the BIOS, or was this drive prepped on another machine?
If you used an older bios to do fdisk, you should redo it using the 003 build and see if that helps. I fixed a bug in the parameter table stuff that impacted certain drives at some point before the 003 build came out.


If this drive was prepped in another machine, then there's certainly something wrong. Let me know the model number/size of the drive you're working with and I'll see if I have anything similar in my stockpile.


The best way to test the BIOS compatibility is to build the drive on a different machine using a "normal" IDE controller/BIOS and then move it to the XT and vice-versa. Ideally your "normal" controller and BIOS would be using BIOS that doesn't have any of the barriers at 520MB, or 8.4G.



Would it be possible to make a test version of the BIOS with prompts for each stage like the earlier versions had? That was really helpful in debugging. All I can say for sure now is that it crashes on boot but appears to be OK otherwise.


The current problem is that that during POST, the XT has the keyboard disabled. I tried that prompty version on my machine and I couldn't ever find the "any key" to continue. ;) Your clone may be different though.

I suspect it's just disabled via the interrupt controller, and can certainly be re-enabled at some point, but it may also be disabled for good reason.
You could always move the card to your Pentium machine, and the prompts will work there, but I'd prefer to move to XT only testing if possible.

Do you have VGA in your 8088 machine? My immediate goal is to build up my arsenal of test software for it, but everything I've developed was done under VGA, and doesn't work really well in CGA mode, as I'm trying to use 50 line mode for more display data. Better test software is coming soon.

---------
Ordered more parts from Jameco last night. I'll be building up more of the prototype cards this weekend and then we'll start distributing them to testers and see if we can get the BIOS wrung out this month.

NobodyIsHere
May 1st, 2009, 06:37 AM
Was this a drive that you fdisk+formatted using an older rev of the BIOS, or was this drive prepped on another machine?
If you used an older bios to do fdisk, you should redo it using the 003 build and see if that helps. I fixed a bug in the parameter table stuff that impacted certain drives at some point before the 003 build came out.



Hi! Thanks! That's probably the problem since I just reused the results of the previous fdisk for partition table setup. I used fdisk to verify partition 1 was set up properly and left it alone. Tonight I will delete the partition and rebuild it from scratch to see if that helps.





If this drive was prepped in another machine, then there's certainly something wrong. Let me know the model number/size of the drive you're working with and I'll see if I have anything similar in my stockpile.


The best way to test the BIOS compatibility is to build the drive on a different machine using a "normal" IDE controller/BIOS and then move it to the XT and vice-versa. Ideally your "normal" controller and BIOS would be using BIOS that doesn't have any of the barriers at 520MB, or 8.4G.



The current problem is that that during POST, the XT has the keyboard disabled. I tried that prompty version on my machine and I couldn't ever find the "any key" to continue. ;) Your clone may be different though.

I suspect it's just disabled via the interrupt controller, and can certainly be re-enabled at some point, but it may also be disabled for good reason.
You could always move the card to your Pentium machine, and the prompts will work there, but I'd prefer to move to XT only testing if possible.




Well, even just printing out debug messages as you go and short pauses would be useful. Maybe set them as conditional assembles for a verbose debug version versus a regular version?




Do you have VGA in your 8088 machine? My immediate goal is to build up my arsenal of test software for it, but everything I've developed was done under VGA, and doesn't work really well in CGA mode, as I'm trying to use 50 line mode for more display data. Better test software is coming soon.




Yes, I am using VGA on this system. The current system crashes into what appears to be a 40 column mode but I am not sure exactly what its doing.




---------
Ordered more parts from Jameco last night. I'll be building up more of the prototype cards this weekend and then we'll start distributing them to testers and see if we can get the BIOS wrung out this month.

Excellent! Thanks and have a nice day!

Andrew Lynch

per
May 1st, 2009, 08:25 AM
I suspect it's just disabled via the interrupt controller, and can certainly be re-enabled at some point, but it may also be disabled for good reason.

It is dissabled in the interrupt controller.

Maybe because of laziness, or because they didn't asume that some BIOS Extensions wans user input. The tests done before was the timer test (time critical) and the main memory R/W test (if the KB was enabled here, you could just have skipped the test by pressing Ctrl+Alt+Del). The test done afterwards is the diskette tests (also time critical). After the diskette tests, the keyboard is enabled.

As long as the keyboard is disabled after the initalizion, it should be all rigth.


Do you have VGA in your 8088 machine? My immediate goal is to build up my arsenal of test software for it, but everything I've developed was done under VGA, and doesn't work really well in CGA mode, as I'm trying to use 50 line mode for more display data. Better test software is coming soon.


I've set up my XT for testing. Unformally, the EGA drive I got from the school got a bad power supply (see my other post), so I have to use VGA too. I have a Mono monitor, but only one avalible right now (and I have to use that with my other XT).

My test station:

One Early-model IBM XT with 256Kb RAM.
One DD DS 5.25" floppy disk drive.
One (maybe nonstandard) DD DS 3.5" floppy disk drive with drivers.
200W modded PC/AT PSU.
One IBM Floppy disk adapter.
One SoundBlaster Pro II.
One Trident TVGA graphics card.
DOS 5.0 installation disks.

And of course, A pile of IDE drives ranging from 2 to 40 gb!

NobodyIsHere
May 1st, 2009, 08:25 AM
Hi! Please check out the new PCB layout. If there are any changes or new features needed please let us know. I'd like to start the PCB respin process.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 2nd, 2009, 05:32 AM
Hi Hargle! Thanks for the help. Still no luck getting it to boot though. I tried booting from the MSDOS 5.0 floppy and I deleted all the partitions on the disk. Then I created a 32MB primary DOS partition (#1) and set it active. I rebooted and formatted the disk but still no luck.

I tried again with a maximum size (2047MB) partition but that didn't work either. I will try swapping the BIOS on the XT motherboard and also see if the hard disk works on another controller.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 2nd, 2009, 05:55 AM
Hi Hargle! Here is another update. I swapped the motherboard BIOS with another one and it seemed to work better but still has the same problem.

I also put the drive on the other test station with the wire wrap prototype and it booted normally so I think the drive, partitioning, formatting, etc is good.

When I boot the XT clone with out a boot floppy, I noticed the XT-IDE flashes twice and then beeps to boot. Then it hangs.

I also was able to make it hang differently by doing a "fdisk /mbr" where as before it would switch to 40 column mode, blanks the screen, and hangs, now it just stays in the 80 column mode and silently hangs. At least I can see the boot messages though.

Thanks and have a nice day!

Andrew Lynch

per
May 2nd, 2009, 06:13 AM
Hi Hargle! Here is another update. I swapped the motherboard BIOS with another one and it seemed to work better but still has the same problem.

I also put the drive on the other test station with the wire wrap prototype and it booted normally so I think the drive, partitioning, formatting, etc is good.

When I boot the XT clone with out a boot floppy, I noticed the XT-IDE flashes twice and then beeps to boot. Then it hangs.

I also was able to make it hang differently by doing a "fdisk /mbr" where as before it would switch to 40 column mode, blanks the screen, and hangs, now it just stays in the 80 column mode and silently hangs. At least I can see the boot messages though.

Thanks and have a nice day!

Andrew Lynch

Maybe it's an I/O conflict?

Try the usual "remove-all-other-cards-except-the-absolute-needed-ones" tecnique, if it still doesn't work, try to get the referance for your XT-clone, or get a revision of the BIOS patched for another I/O Port base.

NobodyIsHere
May 2nd, 2009, 06:16 AM
Hi Per! The XT-IDE clearly works. I can boot the system from floppy and see the partition with fdisk. I can format it and see the C: drive as per normal. I just can't boot from it. I suspect there is a BIOS bug but I will remove all the extraneous boards to minimize the chance of a conflict.

My FDC board has a BIOS on it which may be confusing things too. More in a little while.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 2nd, 2009, 06:37 AM
Hi! OK, I think I've found the problem. If I remove the FDC BIOS chip (CE000-CFFFF) then the XT-IDE BIOS boots from the attached drive normally. Apparently there is a conflict between the FDC BIOS and the XT-IDE BIOS.

My test XT contains one of those JDR/MCT high density FDCs with its own BIOS for supporting 1.4M 3.5" and 1.2M 5.25" floppy drives. Without the FDC BIOS, the card appears to be a regular XT floppy controller and I cannot boot from 1.4M 3.5" floppy disks.

Is there some way to update the XT-IDE BIOS to coexist peacefully with the FDC BIOS?

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 2nd, 2009, 07:20 AM
Hi! I just noticed that I can boot from the other motherboard BIOS but not the original one if I remove the FDC BIOS. Apparently whatever the problem is the other motherboard BIOS can work around it but the original motherboard BIOS can't even with the FDC BIOS removed.

Thanks and have a nice day!

Andrew Lynch

hargle
May 2nd, 2009, 07:54 AM
Hi! OK, I think I've found the problem. If I remove the FDC BIOS chip (CE000-CFFFF) then the XT-IDE BIOS boots from the attached drive normally. Apparently there is a conflict between the FDC BIOS and the XT-IDE BIOS.

My test XT contains one of those JDR/MCT high density FDCs with its own BIOS for supporting 1.4M 3.5" and 1.2M 5.25" floppy drives. Without the FDC BIOS, the card appears to be a regular XT floppy controller and I cannot boot from 1.4M 3.5" floppy disks.

Is there some way to update the XT-IDE BIOS to coexist peacefully with the FDC BIOS?


there are 3 things that I can think of:
1) IO conflict.
Our card is hard coded (at the moment) to using ports 300-308.
I know on my XT, if I pull out our card and read in from ports 300 through 308, something is there responding, and I wouldn't be surprised if an upgraded floppy controller may be using some of those too.

What I'd do is load up debug. pick a number, say 400h and issue the following command:
-i 400
and see what value comes back. If it's FF, then no one is there using that IO address. Do the same from 401 through 408. If all 9 ports come back as FF, then we've found a spot we can use. If something exists there, try 410, or 310 or 200 or anything else where we can get 9 consecutive IO ports to all come back as FF. Then change your dipswitches to decode at that address and let me know what address you decided to use. I will have to build you a new bios that uses your new settings. (we'll make this autodetect soon enough)


2) ROM address conflict
It's possible that both the floppy controller and the XT-IDE cards are bumping into each other at D000 segment. Relocating the option rom to a different address may solve the problem. There was some utility released by microsoft (MSD.exe or something?) that shows free memory addresses that you could use to locate where a free 8k of space may be. Changing the option rom address on your dipswitches will not require a new BIOS change.

3) reserved memory conflict.
Our card looks at the top of base memory pointer and then subtracts 1k off the top. so on a 640k machine, the XT-IDE is claiming 639-640k for itself and then changing the top of base memory pointer to claim there's only 639k total. In that 1k of space, I store the drive parameter tables and a few other bits that we need to keep track of. It's possible that other cards in the system may be blindly taking that same address range and stomping over our parameter tables. That would make the option ROM still ID the drive properly, but cause it to hang at boot if someone else changed the tables I was expecting to use to know how to boot.


Now that I've written these up, I realize that none of these explain how it would work if you boot to a floppy drive and then read the drive that way...
Hmmmm.

JohnElliott
May 2nd, 2009, 10:49 AM
Are the floppy controller and the IDE controller both trying to hook INT 19, perhaps? And the FDC wins?

NobodyIsHere
May 2nd, 2009, 11:27 AM
Hi Hargle! I've confirmed that the XT-IDE has clear access to the IO ports at $300-$30F. Also the ROM is present at $D000:0-$D1FF:0

The FDC has a ROM at $CE00:0-$CFFF:0 and the VGA card is at $C000:0-$C7FFF:0. I placed the XT-IDE ROM at $C800:0-$C9FF:0 and it seems to work OK there. At least its recognized and identifies the IDE hard drive but it still does not boot.

Really the lack of IDE drive booting is not a big deal for me. I can boot from the 1.4M floppy just as well. I think there is some competition going on between the FDC BIOS and the XT-IDE BIOS.

Adding some diagnostic messages for each stage of the XT-IDE boot might give us some clues as to what's happening and where things are going wrong.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 2nd, 2009, 11:29 AM
there are 3 things that I can think of:
snip]

3) reserved memory conflict.
Our card looks at the top of base memory pointer and then subtracts 1k off the top. so on a 640k machine, the XT-IDE is claiming 639-640k for itself and then changing the top of base memory pointer to claim there's only 639k total. In that 1k of space, I store the drive parameter tables and a few other bits that we need to keep track of. It's possible that other cards in the system may be blindly taking that same address range and stomping over our parameter tables. That would make the option ROM still ID the drive properly, but cause it to hang at boot if someone else changed the tables I was expecting to use to know how to boot.

[snip]


Item #3 sounds possible. The FDC BIOS may be doing something along those lines and interfering with the XT-IDE BIOS. Would you like a ROM dump of the FDC BIOS?

Thanks and have a nice day!

Andrew Lynch


PS, I uploaded the FDC-BIOS to the wiki if anyone would like to see it. I noticed one other thing. It appears the XT-IDE BIOS is running first after the motherboard BIOS and then the FDC BIOS. Is there anyway to make the XT-IDE BIOS run *after* the FDC BIOS so the sequence would be motherboard BIOS, FDC BIOS, and then XT-IDE BIOS?

per
May 2nd, 2009, 12:41 PM
Is there anyway to make the XT-IDE BIOS run *after* the FDC BIOS so the sequence would be motherboard BIOS, FDC BIOS, and then XT-IDE BIOS?

The IBM XT BIOS will search from C8000h to F4000h in 800h increments, and does far-calls to the code as it finds valid extensions. To make the XT-IDE BIOS the last to be called, you have to put it as high in RAM as possible.

I don't know if this is the cause with your XT clone.

hargle
May 2nd, 2009, 12:52 PM
Is there anyway to make the XT-IDE BIOS run *after* the FDC BIOS so the sequence would be motherboard BIOS, FDC BIOS, and then XT-IDE BIOS?

yep, if you can swap the locations of the ROMs in memory, it should reverse the order in which they get called. So just dipswitch the xtide card as high up as possible, like maybe even at E000.

Terry Yager
May 2nd, 2009, 12:55 PM
Is there anyway to make the XT-IDE BIOS run *after* the FDC BIOS so the sequence would be motherboard BIOS, FDC BIOS, and then XT-IDE BIOS?

Wouldn't that be a matter of just swapping the addresses around? I thought that the system simply loads (and executes) ROMs in the order it finds 'em, from base on up? Or is it not that simple, am I missing sum'n (as usual)?

--T

NobodyIsHere
May 2nd, 2009, 01:03 PM
yep, if you can swap the locations of the ROMs in memory, it should reverse the order in which they get called. So just dipswitch the xtide card as high up as possible, like maybe even at E000.

Hi! Well that didn't work either. It was worth a try. The XT-IDE BIOS was originally at $D000:0 and the FDC BIOS at $CE00:0 so the order was opposite. Now I have the XT-IDE at $C800:0.

I've tried the XT-IDE BIOS above and below the FDC BIOS and no luck. Unfortunately the FDC BIOS is fixed at $CE00:0 and I need it to use the floppy drive.

I am thinking that both the FDC BIOS and the XT-IDE BIOS are using high RAM for configuration data.

Thanks and have a nice day!

Andrew Lynch

hargle
May 2nd, 2009, 01:41 PM
I am thinking that both the FDC BIOS and the XT-IDE BIOS are using high RAM for configuration data.


Or as johnelliot said, there may be a conflict with INT 19. In fact now that I think about it, that could be a good lead, and an issue I need to look into.

I'm setting up a new test station at the moment, so I will hopefully be back on the BIOS bus and getting some better diagnostics to you soon.

--------
I flashed a new eeprom with the base address set up for the acculogic card, and put the eeprom in bob's card, and it booted my hard drive just fine. I'll be shipping that off early next week.
--------

I managed to find a VGA card that works in an 8 bit slot, but it does not work in my XT. Works great in my zenith 8088 though, so that's become my new test bed. With VGA enabled, I can send you some diagnostics to play with. You may also need a mouse driver installed on your 8088. Do you have one?

NobodyIsHere
May 2nd, 2009, 01:52 PM
Or as johnelliot said, there may be a conflict with INT 19. In fact now that I think about it, that could be a good lead, and an issue I need to look into.



Hi! That sounds like a promising lead too.





I'm setting up a new test station at the moment, so I will hopefully be back on the BIOS bus and getting some better diagnostics to you soon.

--------
I flashed a new eeprom with the base address set up for the acculogic card, and put the eeprom in bob's card, and it booted my hard drive just fine. I'll be shipping that off early next week.
--------



Maybe we should just move the default IO ports to be compatible with the Acculogic board? It doesn't matter to me. 0x300 was just a random range I pulled out of the air during testing. Its the range reserved for prototyping boards, I think.



I managed to find a VGA card that works in an 8 bit slot, but it does not work in my XT. Works great in my zenith 8088 though, so that's become my new test bed. With VGA enabled, I can send you some diagnostics to play with. You may also need a mouse driver installed on your 8088. Do you have one?


I have a VGA and can install a mouse+driver no problem.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 3rd, 2009, 05:26 PM
Hi! I've been testing more on my XT station and the XT-IDE board. Except for the boot issue, it seems to be working fine. I've added a serial mouse and driver so that's ready to go for the new software.

I've added an old EPROM burner to the XT test station. That way I can burn the updated BIOS images to 2764 EPROMs and install them in the XT-IDE board rather than using the EEPROM in circuit reprogramming during testing. I've had a couple of instances where it appears the board is broken or no longer working that have traced back to EEPROM corruption. Using an "old school" 2764 will ensure that never happens again. I don't know if there is an issue with it or not. Its probably due to all the problems in configuring this XT clone. We'll see how it goes in more testing. The updated XT-IDE PCB layout includes a write protect jumper.

Thanks and have a nice day!

Andrew Lynch

hargle
May 3rd, 2009, 07:40 PM
here's test #1
http://www.waste.org/~winkles/hdtest.zip

*** this is a destructive test ***

This uses eINT13 calls to write pseudo random data to a chunk of LBAs and then read it back and compares the data.

the first 4 bytes of the LBA data written is the LBA number itself, which could be useful in debugging.

It's sloooowwwww. Be patient. I'm letting mine run all night and see if anything fails in the morning. This should pretty well run the hardware latching and decoding through its paces.

hargle
May 4th, 2009, 06:55 AM
ran the hdtest overnight. it read/wrote some 400,000 sectors without a single error. :)

there will be another version of this program released soon which allows the user to do write, verify or both phases of the test. since the data is pseudo-random, you could do the write phase on a different machine, then come back and just verify the data on the xt-ide for example. I think that'll be a good test bench for verifying that we're talking to the drive the same way as other controllers are.

yet another version of this test will be generated that uses CHS instead of LBA to access the drive. Run that on a new machine to write and then read the data back on our card. That would verify that a new machine using CHS to write to the drive can be read back on our card via LBA, meaning the math for converting the two is working properly.

I've also got another program to test the drive without using INT13 at all.
It's a scriptable GUI type program, but my hangups currently are converting a bunch of code from 386 to 8086 as I used a lot of 32bit values in the code.

finally, a test program to simply print out to the screen the contents of ID data, INT 13 fn 8, and INT13 fn 48 would be handy. I can bang out that program pretty quick, as I've got the bits elsewhere already.

-------
built prototype cards #3 and 4 over the weekend. #3 works fine, #4 I forgot to add 1 single, stinkin' decoupling cap, so I didn't try it. It's back here at work today for a quick soldering job. duhr.

Went over a few bad solder joints on card #1, but it still didn't help the eeprom decoding issue. i'm learning quickly the best way to build these cards up. it still takes just over an hour per card, but the quality is going up, as are my soldering skills.

---------
while I was in over the weekend, I programmed up all the eeproms i had with the burner at work, and one of them failed to program. I'd had troubles with it before with software, which is why I decided to bulk program them all at once at work, but this one part is bad. I'll send it to per (along with a good one!) so he can play with the error reporting features of the flash program. For the big run, I'll program all 100 parts on the burner, since it's significantly quicker and pretty easy task to do. That way people ordering a kit should get some instant gratification when they power it up for the first time...

per
May 4th, 2009, 07:38 AM
ran the hdtest overnight. it read/wrote some 400,000 sectors without a single error. :)

there will be another version of this program released soon which allows the user to do write, verify or both phases of the test. since the data is pseudo-random, you could do the write phase on a different machine, then come back and just verify the data on the xt-ide for example. I think that'll be a good test bench for verifying that we're talking to the drive the same way as other controllers are.

yet another version of this test will be generated that uses CHS instead of LBA to access the drive. Run that on a new machine to write and then read the data back on our card. That would verify that a new machine using CHS to write to the drive can be read back on our card via LBA, meaning the math for converting the two is working properly.

I've also got another program to test the drive without using INT13 at all.
It's a scriptable GUI type program, but my hangups currently are converting a bunch of code from 386 to 8086 as I used a lot of 32bit values in the code.

finally, a test program to simply print out to the screen the contents of ID data, INT 13 fn 8, and INT13 fn 48 would be handy. I can bang out that program pretty quick, as I've got the bits elsewhere already.

-------
built prototype cards #3 and 4 over the weekend. #3 works fine, #4 I forgot to add 1 single, stinkin' decoupling cap, so I didn't try it. It's back here at work today for a quick soldering job. duhr.

Went over a few bad solder joints on card #1, but it still didn't help the eeprom decoding issue. i'm learning quickly the best way to build these cards up. it still takes just over an hour per card, but the quality is going up, as are my soldering skills.

---------
while I was in over the weekend, I programmed up all the eeproms i had with the burner at work, and one of them failed to program. I'd had troubles with it before with software, which is why I decided to bulk program them all at once at work, but this one part is bad. I'll send it to per (along with a good one!) so he can play with the error reporting features of the flash program. For the big run, I'll program all 100 parts on the burner, since it's significantly quicker and pretty easy task to do. That way people ordering a kit should get some instant gratification when they power it up for the first time...

Great to hear.

I hope my mouse driver works with DOS 3.3...

NobodyIsHere
May 4th, 2009, 09:06 AM
ran the hdtest overnight. it read/wrote some 400,000 sectors without a single error. :)

[snip]



Hi! I'll run the hdtest program on my station tonight. Hopefully it gives the same results!




-------
built prototype cards #3 and 4 over the weekend. #3 works fine, #4 I forgot to add 1 single, stinkin' decoupling cap, so I didn't try it. It's back here at work today for a quick soldering job. duhr.



Missing one decoupling capacitor is not going to matter. I add one capacitor per chip since a fair percentage of those capacitors do nothing at all. A little redundancy can be a good thing and gives you some margin for missing/non-functional parts.





Went over a few bad solder joints on card #1, but it still didn't help the eeprom decoding issue. i'm learning quickly the best way to build these cards up. it still takes just over an hour per card, but the quality is going up, as are my soldering skills.



Write a small program that accesses the ROM memory addresses in a loop and then check if the ROM chip select signal is cycling. I use a logic probe or an oscilloscope. It almost has to be the 74LS688 or the 2864. There are only those two parts plus a DIP switch.

If you want you can send it to me and I'll beat on it for a while. I can send my board to another tester and you send me the broken one?




---------
while I was in over the weekend, I programmed up all the eeproms i had with the burner at work, and one of them failed to program. I'd had troubles with it before with software, which is why I decided to bulk program them all at once at work, but this one part is bad. I'll send it to per (along with a good one!) so he can play with the error reporting features of the flash program. For the big run, I'll program all 100 parts on the burner, since it's significantly quicker and pretty easy task to do. That way people ordering a kit should get some instant gratification when they power it up for the first time...

Yes, I think the 2864s maybe aren't as reliable as I had hoped. I gather you have a defective part rather than something corrupting it. When it doubt, throw it out. Marginal parts can introduce sneaky failure modes.

I am using 2764 EPROMs since they are absolutely not reprogrammable in circuit. I recall the 2864X had some sort of data protection mode? Maybe that could be enabled?

Thanks and have a nice day!

Andrew Lynch

JT64
May 4th, 2009, 09:29 AM
What is the status on cdrom and ATAPI support?
"The thread getting big you need a thread controller status, what is supported and what is not supported."

JT

per
May 4th, 2009, 09:30 AM
I recall the 2864X had some sort of data protection mode? Maybe that could be enabled?
The only one I could find with data protection was the AT28C64B from Atmel. All the other ones I have seen does only protect if the voltage level fall below 3v.

The Atmel-write mode activates protection, IF an AT28C64B is used of course. Else, it'll just corrupt the contnents of the EEPROM.



Anyways, If a customer wanted an EPROM in addition to the EEPROM, couldn't we make it avalible for customers paying $5 extra?

per
May 4th, 2009, 09:44 AM
What is the status on cdrom and ATAPI support?
"The thread getting big you need a thread controller status, what is supported and what is not supported."

JT

We're not done anything there yet. Currently, only the IDE is in focus. I don't think ATAPI will be prioritized before after the board is released. Be patient...

to see what's currently supported or not, see the wiki.

hargle
May 4th, 2009, 11:21 AM
Hi! I posted an updated PCB layout on the wiki.

This:
Printing XT-IDE-brd-new.pdf
on your wiki page looks fantastic.

Should there be a + on the external LED pin to denote which is which?

Can you post the latest schematics too?

NobodyIsHere
May 4th, 2009, 11:29 AM
Hi! OK. I will add the "+" on the LED jumper to make that clear. Changes to the silkscreen don't effect the trace routing and I'd like to get going since it will be quite a while before it completes. We can wait until more testing is done if you want but the respin will take at least 3 weeks.

Are you OK with the bracket scheme? The current approach is to make holes and use the Keystone #621 brackets & 4-40 machine screws to allow builders to drill holes in a blank and make their own. I tried the pushing all the components over 0.5" to leave a trace routing exclusion zone to allow builders to drill their own holes but there is not enough room on the PCB. I'd have to a lot to the PCB and that drives up cost.

If this is acceptable then I can start the respin whenever you're ready. Please let me know.

Thanks and have a nice day!

Andrew Lynch

hargle
May 4th, 2009, 12:02 PM
More comments, now that i think about it some more.
Can the IRQ jumper block be ganged up with the ROM jumpers? I'm just thinking that a single header block is easier for soldering than single jumper pins.

You'd have to redo the silkscreen there to say "JP1 = rom enable" and "JP2 = write enable" over on the side, since there isn't enough room underneath/next to the actual jumper itself. Labeling the IRQs #'s under each jumper pin would be handy too.

------

As long as there is physically room to drill a hole or two in the card along those edges, we should be fine with the bracket mounting. I don't think lengthening the card itself 0.5" is going to drive prices up that much, or are we then bumping into requirements for Tandy owners? I'd be happy to see if a 0.5" increase would alter pricing, and we can decide from there.

------

Is the CSEL thing a 3 position jumper? Can we try and just pull that signal low and see if it has any effect on drives, and just tie it low if it works?
Speaking of which, I tried a single drive with cable select jumper on, and the drive showed up as a slave. I was using a 40 pin cable though, and that may be why, but I thought you could use 40's with CS settings... I totally forgot to mention that until just now.

Terry Yager
May 4th, 2009, 01:49 PM
Are you OK with the bracket scheme?

Thanks and have a nice day!

Andrew Lynch

I meant to comment on this the other day, but I forgot. In the XT era, many expansion boards came with 'skirts', either the long ones at the rear, or the short one at the front (or both). By the time the '386 MBs began to appear, the makers were cramped for real estate, so they began placing components in that area, which sometimes made it impossible to insert a skirted card into the slot. Since this project is aimed at the PC/XT boards, the front skirt shouldn't be a problem for most users. As for cost of the board, it involves less cutting, so it shouldn't cost more, and possibly even a few pence less. (The board already extends down to the correct depth, but the skirt portion is being cut away).

--T

NobodyIsHere
May 4th, 2009, 02:54 PM
More comments, now that i think about it some more.
Can the IRQ jumper block be ganged up with the ROM jumpers? I'm just thinking that a single header block is easier for soldering than single jumper pins.

You'd have to redo the silkscreen there to say "JP1 = rom enable" and "JP2 = write enable" over on the side, since there isn't enough room underneath/next to the actual jumper itself. Labeling the IRQs #'s under each jumper pin would be handy too.



Hi! OK. Done.





------

As long as there is physically room to drill a hole or two in the card along those edges, we should be fine with the bracket mounting. I don't think lengthening the card itself 0.5" is going to drive prices up that much, or are we then bumping into requirements for Tandy owners? I'd be happy to see if a 0.5" increase would alter pricing, and we can decide from there.



OK. Please check on effect to the price by adding about 2 square inches to the area of the PCB. If its acceptable, I'll pick up the current component layer and move it over 1/2"





------

Is the CSEL thing a 3 position jumper? Can we try and just pull that signal low and see if it has any effect on drives, and just tie it low if it works?
Speaking of which, I tried a single drive with cable select jumper on, and the drive showed up as a slave. I was using a 40 pin cable though, and that may be why, but I thought you could use 40's with CS settings... I totally forgot to mention that until just now.

Yes, the CSEL jumper is a 3 position jumper. CSEL can be either GND or pulled high. I've found it works fine pulled high on my systems but that's just me. It may vary with other testers. I can pull it high or low whatever you want -- either way is fine by me. Leaving the jumper gives us a little more flexibility though.

Thanks and have a nice day!

PS, I've uploaded new PCB layout and schematics on the wiki for review. Please post your comments. Thanks in advance.

Andrew Lynch

hargle
May 5th, 2009, 06:10 AM
Pricing:
ok, with the current size of 4.55x4.25", 100 PCBs will run us $643 + shipping.

changing it to 5.05x4.25", the price goes up to $663.

I think 20 cents per board is acceptable for the luxury of being able to attach pretty much any slot bracket known to human kind onto it. We may not even really need a full 0.5" either, maybe even 0.30 would be enough? Do you happen to have a selection of ISA cards with appropriate brackets that you can experiment with? I know I have a few and I can find a couple of them and send you the measurements at the very least.

I wonder if extending the tab below the ISA slot teeth is expensive? I don't know exactly how to enter that information into the quote form on pcbcart.com.
-------------------
while playing around with the quote machine, I dropped the # of gold teeth down to 52 and the price (with the expanded size) dropped down to $613! I guess teeth are really expensive. I know it's risky, but if it's possible to dump some teeth that we absolutely won't need, that would certainly help the bottom line.
-------------------
Added my missing decoupling cap to board #4, and it works. It's a little weird though. The ID string during POST says "sT31104a" (or similar) with the 1st and last letters in lower case. That's not the way it should look.
Running the hdtest to read/write sectors worked just fine, but the ID is always goofy. I didn't have much time to investigate, but I'll dig into this more when I get my next batch of ICs. I'm currently swapping my 1 set of working ICs for every board I work on, so that can introduce weirdness. I've got another set of ICs at the post office today that I'm picking up, so as of tonight I can build actual boards and test them by just swapping the card out instead of playing the IC shuffle. Hopefully that will help out with my goofy errors. The extra ICs also mean that I will be shipping boards to our beta testers this week!

Druid6900
May 5th, 2009, 06:21 AM
A lot of cards used to have the jumper settings silk-screened on the solder side of the board if there wasn't sufficient space on the component side for them.

hargle
May 5th, 2009, 07:35 AM
A lot of cards used to have the jumper settings silk-screened on the solder side of the board if there wasn't sufficient space on the component side for them.

The $613 quote above went to a whopping $614 when I changed the silkscreen to 2 sides. :)
I find that really pretty amazing, and we should certainly consider this as a great way to document the card.

Terry Yager
May 5th, 2009, 11:00 AM
I wonder if extending the tab below the ISA slot teeth is expensive? I don't know exactly how to enter that information into the quote form on pcbcart.com.
-------------------


It's called a 'skirt', and as I mentioned above, it's sum'n that has to be cut away from the board when it's manufactured, so leaving it on shouldn't cost much more. Less waste = very 'green friendly' (or whatever they call it). If some folks don't want it there, they can hacksaw it off later.

--T

hargle
May 5th, 2009, 12:14 PM
ah, that's what you were talking about. ;)

either way, there's no option for that on the quote from pcbcart, so I dunno how to check to see if there is a price difference for it. We could just spec it into the design and see if they balk at it. Either way they would need to do some cutting to allow for the isa connector edge to fit between the skirt and the gold teeth, so they're not doing any less work by leaving that on.

speaking of that, are we paying for that little chunk of PCB anyway? I assume the height of 4.5" is from the edge of the gold teeth to the top of the board, so in effect, we are already paying for that missing land mass that gets cut off. so by rights, we should get to keep it. :)

barythrin
May 5th, 2009, 01:07 PM
Eh.. I was gonna PM someone but I figure it's quicker just to post. I know you all have your folks/contacts already on doing the PCB work but if you want to query Andre at nurve.net (ceo (at)nurve.net) I've heard he has some contacts overseas that are very cheap for pcb development. I'm not clear if it's his own company that does it over there or if it's a company he goes through but I know a few things we designed at the robot group we found it to be a good deal cheaper and they didn't seem to care about us cramming all we could on a PCB vs others who you'd pay for the space you use.

Anyway if it saves you some development money it could be something to ask about, but obviously you all have your process down. I'm looking forward to the release! :-)

- John

NobodyIsHere
May 5th, 2009, 03:25 PM
Hi Hargle! I updated the PCB layout and posted new PDF on the wiki. I added 1/2" on the left hand side of the PCB and moved all the components accordingly.

I also moved the right hand side out 25 mils to enhance PCB strength around any hole. Please check your PCB prototype to ensure there is about 1mm of clearance between the right hand side of the PCB and a blank bracket.

The right hand side also now has a "skirt" bump out on the PCB to accommodate low holes. Hopefully that won't cause interference. If people would check their motherboards for components in that region that might interfere I would appreciate it.

There are also a few silkscreen updates. Please check out the new PDF and post any comments.

Thanks and have a nice day!

Andrew Lynch

PS, I also removed several gold teeth from the PCB edge connector. I think I just eliminated those with out any connection. I sure hope that's right or this is going to get unpleasant. Feel free to double check...

NobodyIsHere
May 5th, 2009, 03:41 PM
The $613 quote above went to a whopping $614 when I changed the silkscreen to 2 sides. :)
I find that really pretty amazing, and we should certainly consider this as a great way to document the card.

Hi! We can add a bunch of text on the reverse side if you want but I would rather get all the information the builder needs on the front side if possible. If you see things on the PDF PCB layouts that aren't obvious, I can add labels etc to help clarify. All the jumpers are labeled AFAIK.

Thanks and have a nice day!

Andrew Lynch

lutiana
May 5th, 2009, 03:53 PM
Hi! We can add a bunch of text on the reverse side if you want but I would rather get all the information the builder needs on the front side if possible. If you see things on the PDF PCB layouts that aren't obvious, I can add labels etc to help clarify. All the jumpers are labeled AFAIK.



The layout looks Awesome.

Putting a text table (or a few) on the back detailing the switch positions and jumper settings would be great. I always like it when I find cards that do this type of labeling as it makes the configuration so much easier, especially for people that are new to hardware.

In fact if you want to send me the info on the switch and INT settings I'll make the tables (and make a table in the Wiki to match). A small contribution I know, but I figure it will free up your time to focus on refinement and testing.

The way you have done JP1 and JP2 is very nice and clear. Would be possible to put the values for the INT select settings underneath the pins (like you've done with JP1 and JP2)?

This card is designed for use in XT, but it sounds like it would work on some earlier AT (286, 386) thus enabling larger (10gb+) drives. Is this right?

NobodyIsHere
May 5th, 2009, 04:25 PM
here's test #1
http://www.waste.org/~winkles/hdtest.zip

*** this is a destructive test ***

This uses eINT13 calls to write pseudo random data to a chunk of LBAs and then read it back and compares the data.

the first 4 bytes of the LBA data written is the LBA number itself, which could be useful in debugging.

It's sloooowwwww. Be patient. I'm letting mine run all night and see if anything fails in the morning. This should pretty well run the hardware latching and decoding through its paces.

Hi Hargle! I am running hdtest on my XT station and it is working. It is slower than molasses and I think it will take about two weeks to finish. I am using an 8GB hard drive with about 00FBxxxx sectors. I started yesterday about 24 hours ago and its now up to 0011xxxx.

I'll keep you posted on its progress.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 5th, 2009, 04:44 PM
[snip]

The way you have done JP1 and JP2 is very nice and clear. Would be possible to put the values for the INT select settings underneath the pins (like you've done with JP1 and JP2)?

This card is designed for use in XT, but it sounds like it would work on some earlier AT (286, 386) thus enabling larger (10gb+) drives. Is this right?

Hi! Check out this new version. The wiki was serving an old version of the PDF file. http://n8vem-sbc.pbworks.com/f/Printing%20XT-IDE-brd-new.pdf

The XT-IDE should work in any computer with an ISA slot. I am using it with an 8GB IDE hard drive and recall testing a 40GB on my other PIII test station with an earlier version of the XT-IDE. I suppose larger sizes are possible but you need to check with Hargle. He is the BIOS author and ultimately determines what the board is compatible with.

There will be some compatibility tradeoffs because not every IDE device known to mankind is supportable with a single IDE interface. The most likely to be not supported are the old IDE devices especially the pre-LBA ones. ATAPI devices may or may not be supported. The most likely to work are the fairly recent (within the last ten years) IDE hard drives.

Thanks and have a nice day!

Andrew Lynch

hargle
May 5th, 2009, 07:18 PM
In fact if you want to send me the info on the switch and INT settings I'll make the tables (and make a table in the Wiki to match). A small contribution I know, but I figure it will free up your time to focus on refinement and testing.

that would be very nice of you. any help, and any updates to the wiki are highly encouraged. Especially by us who are time constrained.



This card is designed for use in XT, but it sounds like it would work on some earlier AT (286, 386) thus enabling larger (10gb+) drives. Is this right?

This card will let you put up to a 2TB drive in your XT. :)
(ok, at the moment, there is currently a 137G barrier, but it's all software to get beyond that point, and an update is only ever an eeprom flash away)

The deal is that you don't want to use this card in anything bigger (ie, 16 bit) than an XT, because a 16bit card is going to be faster than this one.
You would gain the large drive capability, but the card is really quite pokey compared to a true 16 bit card.

lutiana
May 5th, 2009, 10:58 PM
Hi! Check out this new version. The wiki was serving an old version of the PDF file. http://n8vem-sbc.pbworks.com/f/Printing%20XT-IDE-brd-new.pdf


Its a thing of beauty man. Damn near brought a tear to my eye. Seriously though the revision is very nice



that would be very nice of you. any help, and any updates to the wiki are highly encouraged. Especially by us who are time constrained.


Okay, I will see what info I can pull from sifting through all these posts, and try to keep the Wiki up to date, especially the current progress.



This card will let you put up to a 2TB drive in your XT. :)


*blinks* I just know someone is going to do it, for no other reason that to say that they have a 1983 XT running with 2tb of storage space (but only 8gb usable).

I am thinking 'bout nothing much bigger than a 1 or 2gb drive or CF card. But I am thinking that it be great in my pre-pentium machines, or any board I might come across that does not have a built in controller.

This is very cool guys. Keep up the great work. O and Andrew, I hope that your day is really nice! ;D

Unknown_K
May 5th, 2009, 11:33 PM
Cool, wondering where the price is going to end up at when all is said and done.

Anybody recall when LBA started on IDE HDs? I asume we need 500MB or larger IDE drives to work with this card (not a problem)?

hargle
May 6th, 2009, 06:35 AM
Cool, wondering where the price is going to end up at when all is said and done.

I'm not sure I want to get into a pricing discussion again at this time, as I tend to be too optimistic about things. I think we're sitting pretty good at the moment though, with about $10 in parts and another $7-8 for the PCB. There are some costs like the initial prototype PCB costs that need to be recouped, but that'll only add an extra couple bucks per order if we do 100 of them, which is what I was planning on doing. If you assemble it yourself, I think you will easily get away with paying less than $40 total. (I still wanna say about $25-30). If you're going to make me assemble it, then you're going to pay for my soldering and testing time, which at the moment, is not worth it! ;)



Anybody recall when LBA started on IDE HDs? I asume we need 500MB or larger IDE drives to work with this card (not a problem)?

~1994, or whenever drives went bigger than 528MB.
I *strongly* suggest using drives no more than 10 years old, since things have standardized a lot in that time frame, both electrically and software spec wise.

hargle
May 6th, 2009, 06:49 AM
ok, cards #2 and #3 will be making their way off to testers Mike and Per tomorrow.
They are rock solid from what I've seen.
Card #5 is blank. Terry is going to solder his own and report back.

Card #1 is still having issues reading the ROM. I have spent approximately 4 minutes debugging it, so I'm not worried or even stumped yet.

Card #4 is lower casing 2 characters during the POST ID. I have swapped out every IC on the card and it's still doing it. It is totally bizarre, considering all other data transfers are working just fine. (runs HDtest without errors). Aside from the parts swap, I have spent 0 minutes debugging it. Not worried or stumped yet there either.

The rest of my week is fairly tied up, but starting early next week I will solder up a couple more cards and testing those out and sending them out to other debuggers.

Things I want to check:
1) CS on the drive. Why does a single drive with CS jumper show up as a slave? Does tying CSEL on the controller low change this? Can you run CS on a drive with a 40 pin cable or do you need an 80?

2) Two drives. Haven't really messed with any master/slave things.

3) auto detecting the IO base address.

4) figuring out why andrew can't boot

5) figuring out why coretest.exe won't run on our BIOS

6) use IRQs. Currently there is no IRQ usage at all.

Then it's just a matter of adding features, fixing problems that creep in, and starting to optimize it.

I think we should make a debugging log and "things to remember to check" on the wiki, as well as a troubleshooting guide and probably a "tips on assembling your card" section, maybe even with some pictures.

NobodyIsHere
May 6th, 2009, 08:15 AM
I'm not sure I want to get into a pricing discussion again at this time, as I tend to be too optimistic about things. I think we're sitting pretty good at the moment though, with about $10 in parts and another $7-8 for the PCB.



Hi Hargle! Thanks! Your sunny optimism makes me happy. However part of my job as "Cmdr Buzzkill" is to reign in unrealistic expectations with generous application of buckets of cold water. :-)

I believe it to be too early to discuss final unit price as well. While working on the updated PCB layout last night I noticed that there have been *many* changes to the production unit compared to the prototype. I've lost exact count but its more than ten changes for sure. Since we've barely begun initial testing and already racked up so many changes it may be prudent to consider another round of PCB prototypes before making the big order. Probably after we've strained out the really big bugs with the initial round of testing the second round could be broader and go for more depth and variety.

Why another round? I am very concerned about parts interference and with all the changes to the PCB outline pushing the boundaries outward that eventually we are going to hit something. I've done some measurements and I *believe* we had about 1mm clearance on the right hand side of the PCB before it contacted the bracket. That 1mm clearance is now gone to allow the Keystone 9202 brackets to actually contact some PCB material. Some independent confirmation would be good so that we get PCBs that really fit in the target computer. That there don't appear to be any defined standards for the outline of an ISA PCB makes this is all sort of hit or miss.

The bracket skirt issues make me worry too. What are the physical tolerances of the 62 pin edge connector? Is there enough clearance between the edge and skirt? How would we know? The original design was extremely conservative and basically trimmed off all the interference danger zones. I can see why now and it was a wise approach. The semi random layout of an XT/AT motherboard is a witches brew of pieces and parts strewn all over. Who knows what sort of crap is going to get in the way? I have no idea.

On top of that, just for fun, I tried an early initial respin of the PCB just to see what the effect of all the changes are on the trace routing. Well, I can tell you it ain't pretty. The default router could not make a solution in ~45 passes and that's not good. I manually interceded and did the last few trace by hand. When the optimizer started there were 195 vias and >429 inches of overall trace length. In other words, the PCB looks like a plate of spaghetti (traces) with a half a bottle of parmesan cheese on it (vias). Its going to take some serious time to get the optimizer to straighten the mess out and even then is going to be more complex than the initial prototypes. I started the optimizer yesterday evening and when I checked it this morning (0530) it was almost 50% complete *on the first pass*. Ugh.




There are some costs like the initial prototype PCB costs that need to be recouped, but that'll only add an extra couple bucks per order if we do 100 of them, which is what I was planning on doing. If you assemble it yourself, I think you will easily get away with paying less than $40 total. (I still wanna say about $25-30). If you're going to make me assemble it, then you're going to pay for my soldering and testing time, which at the moment, is not worth it! ;)



~1994, or whenever drives went bigger than 528MB.
I *strongly* suggest using drives no more than 10 years old, since things have standardized a lot in that time frame, both electrically and software spec wise.

Agree. $40-$50 is probably the reasonable zone, IMO. IDE hard drives that are LBA and <10 years old is certainly reasonable device support.

You are certainly entitled to recoup your expenses and then some. You've already shown more patience, fortitude, and persistence than most. Good on you.

Thanks and have a nice day!

Andrew Lynch

PS, BTW, I also checked the hdtest run on the XT test station. Its up to 0018xxxx of 00FBxxxx sectors. Does this need to go all the way to the end or can it be aborted part way through and still provide meaningful results? If it were encountering errors would it have printed them already or do I wait until its done? I hope the power stays up for the next two weeks!

NobodyIsHere
May 6th, 2009, 08:31 AM
ok, cards #2 and #3 will be making their way off to testers Mike and Per tomorrow.
They are rock solid from what I've seen.
Card #5 is blank. Terry is going to solder his own and report back.



Hi! Excellent news! Please let me know what I can do to get more working test assets out to our brave group of human test subjects ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hvolunteers.





Card #1 is still having issues reading the ROM. I have spent approximately 4 minutes debugging it, so I'm not worried or even stumped yet.

Card #4 is lower casing 2 characters during the POST ID. I have swapped out every IC on the card and it's still doing it. It is totally bizarre, considering all other data transfers are working just fine. (runs HDtest without errors). Aside from the parts swap, I have spent 0 minutes debugging it. Not worried or stumped yet there either.



If you've swapped all the components and the problem persists on either #1 or #4 the problem is most likely a soldering joint or bridge. Possibly a bad PCB but unlikely. Watch to make sure the joints are not leaking over and touching vias, etc. Use a brush or toothpick to scrape away and residual solder bits, etc.

If PCB #4 is consistently showing lower case in an upper case only field, trace bit #5 through the system. Probably there is something suspicious on that trace. I am betting cold joints or bridging. Also look for bent pins on chips going into sockets.

My offer to swap my board for a partial/broken one stands.




The rest of my week is fairly tied up, but starting early next week I will solder up a couple more cards and testing those out and sending them out to other debuggers.

Things I want to check:
1) CS on the drive. Why does a single drive with CS jumper show up as a slave? Does tying CSEL on the controller low change this? Can you run CS on a drive with a 40 pin cable or do you need an 80?



That's easy enough to check; just wire the pull up resistor on CSEL to ground. The 10K resistor will limit current flow to 0.5 mA so it won't hurt anything. I could check it but hdtest is running right now. Want me to canx hdtest?





2) Two drives. Haven't really messed with any master/slave things.



me neither. I recall a test where it worked with the wire wrap prototype on the PIII test station though. Of course that was weeks ago so its probably not helpful anymore.






3) auto detecting the IO base address.

4) figuring out why andrew can't boot



I think the Int 19 vector hook is the prime suspect. I think this is more likely than not a general problem that will flush out when more testers start beating on the system.





5) figuring out why coretest.exe won't run on our BIOS

6) use IRQs. Currently there is no IRQ usage at all.




I'd back burner the IRQ support issue. Polling is way more predictable and works better anyway IMO. The performance gain of using IRQs is probably not worth the pain especially now.




Then it's just a matter of adding features, fixing problems that creep in, and starting to optimize it.

I think we should make a debugging log and "things to remember to check" on the wiki, as well as a troubleshooting guide and probably a "tips on assembling your card" section, maybe even with some pictures.

You can move/copy stuff from the N8VEM wiki to the VCF wiki if you'd like.

Thanks and have a nice day!

Andrew Lynch

lutiana
May 6th, 2009, 08:36 AM
Since we've barely begun initial testing and already racked up so many changes it may be prudent to consider another round of PCB prototypes before making the big order.

This would be very prudent and all in all not a bad idea. Andrew did you consider adding a revision number to the board for print?



Who knows what sort of crap is going to get in the way? I have no idea.


Though I do think this is a very good point, it however will ultimatly rest on the actual end user to work out which slot it will fit in, you simply cannot plan for every computer out there that someone may want to install this card into. Terry's point about hacksawing the skirt off as needed was not a bad one.

Could you not cut the design out of a stiff piece of cardboard, keeping the dimensions as close as possible and trying it for fit in a slot?

NobodyIsHere
May 6th, 2009, 08:46 AM
This would be very prudent and all in all not a bad idea. Andrew did you consider adding a revision number to the board for print?



Hi! Excellent suggestion. I will do that.




Though I do think this is a very good point, it however will ultimatly rest on the actual end user to work out which slot it will fit in, you simply cannot plan for every computer out there that someone may want to install this card into. Terry's point about hacksawing the skirt off as needed was not a bad one.



Agree. However I can see situations where particular systems have limited selections on what slots are available. Dropping the PCB outline into the skirt region with the bump out is a risky manuever. However, I can see its probably necessary overall. My fear is the 62 pin connector though. I will do some measurements at home but one data point does not make a trend...





Could you not cut the design out of a stiff piece of cardboard, keeping the dimensions as close as possible and trying it for fit in a slot?

Yes, I did this already for the initial PCB prototype and also with the PCB itself. I will try again with the new outline and see what shakes out. Hopefully nothing will happen but we don't want to find out we have a problem *after* taking delivery of 100 PCBs.

Thanks and have a nice day!

Andrew Lynch

linuxlove
May 6th, 2009, 08:47 AM
now another question I have: would an XTIDE card work in more modern systems, i.e. Pentium - Pentium III class?

NobodyIsHere
May 6th, 2009, 08:49 AM
Yes, as long as it has an ISA slot.

Thanks and have a nice day!

Andrew Lynch

lutiana
May 6th, 2009, 09:03 AM
Hi! Excellent news! Please let me know what I can do to get more working test assets out to our brave group of human test subjects ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hvolunteers.


I can test a completed card. I have a prethora of 20+ gb hard drives, and an XT system that needs a new drive. I'll head down the the recycle store and get some <10gb hard drives from them (they had quite a few).

I'll run it through its paces, and be able to compile data (pictures etc) for the wiki. I'd need it assembled as my soldering skills are most likely worse than that of a blind donkey (but I'm working on this). I also do not have an Eprom programmer (yet).

lutiana
May 6th, 2009, 09:18 AM
My fear is the 62 pin connector though.

I am not sure I understand what it that you fear about the connector.




Hopefully nothing will happen but we don't want to find out we have a problem *after* taking delivery of 100 PCBs.


I completely agree. Best to take it slow, and do some small runs first, till you're 100% sure of end result. In fact I'd recommend running at least 3 - 5 small runs. Sell them to people to play with and give you feed back before a large run. Lots of small runs would allow for minor changes in the PCB as you go along, and the more people that get their hands on these early revision boards the better.

And then once the design is complete, you can sell them on Ebay and eventually amass enough money to rule the world... Well okay, not really, but hopefully enough to recoup your time and costs.

hargle
May 6th, 2009, 09:46 AM
PS, BTW, I also checked the hdtest run on the XT test station. Its up to 0018xxxx of 00FBxxxx sectors. Does this need to go all the way to the end or can it be aborted part way through and still provide meaningful results? If it were encountering errors would it have printed them already or do I wait until its done? I hope the power stays up for the next two weeks!

yeah, go ahead and shut it down, it doesn't need to go through the entire drive to make sure it's working. If there were any errors, it would have displayed a dump of expected/found data and then quit. I'm confident that your card is working as expected.

hargle
May 6th, 2009, 09:50 AM
now another question I have: would an XTIDE card work in more modern systems, i.e. Pentium - Pentium III class?

Don't bother. the card is slow, partly because it doesn't use IRQs or DMA, and partly because it is converting 8bit data to 16bit data and vice versa. On any machine with an actual 16bit data bus (that is, a 286 or better), a regular IDE controller with a boot sector INT13 overlay like Drive Manager would smoke the performance of our card and offer you every benefit that ours has, aside from the warm fuzzy of helping out our project.

lutiana
May 6th, 2009, 10:43 AM
I have updated and tweaked the Wiki a little bit. I intend to do more.

Can you guys post the settings for those 2 dip banks, so I can get that up there.

Thanks

-Jarrod

NobodyIsHere
May 6th, 2009, 03:15 PM
yeah, go ahead and shut it down, it doesn't need to go through the entire drive to make sure it's working. If there were any errors, it would have displayed a dump of expected/found data and then quit. I'm confident that your card is working as expected.

Hi! OK, the XT test station has gotten up to 0018xxxx sectors with no errors. I think its working so lets move on to other testing.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 6th, 2009, 03:31 PM
I have updated and tweaked the Wiki a little bit. I intend to do more.

Can you guys post the settings for those 2 dip banks, so I can get that up there.

Thanks

-Jarrod

Hi! That information you can pull directly off the schematic. SW1 sets the IO address of for the IDE interface. The switches correspond to A4-A9 with the last two switches must be closed. Closed corresponds to 0 and open corresponds to 1 in the address so all closed would be 0x000, the first switch open would be 0x010, and so forth. The only IO address that matters right now is 0x300 which is all closed except switches 5 and 6 open. SW1 addresses bits are "flipped" compared to normally read binary numbers. That is fixed in the updated PCB.

SW2 follows similar logic for the ROM address but follows the normal binary order. The ROM can be placed at any memory addresses starting at the 8K boundary from $00000 through $FE000.

Thanks and have a nice day!

Andrew Lynch

bobwatts
May 7th, 2009, 04:10 AM
Hi Gang !

Just dropping a public note of thanks to Druid and Jeff for the safe return of my Acculogic sIDE card. It was packaged in a magnificent manner, and looks like new. Thanks Jeff !

Although I haven't tried it out yet, I anticipate great results with the new BIOS ROM that Mr. Leyda has provided. Even if there are conflicts with the loaded devices in my particular machine, I'm confident they can be worked out. Besides, I have the original ROM to re-install should that be necessary.

I will of course have a fire extinguisher handy to keep the smoke and flames to a minimum during initial testing. Hopefully there WILL be some excitement, and not a mundane boring test involving nothing more than bits and bytes performing as they should. What would be the fun in that ?

Once again, my sincere respect to Jeff, Andrew, and others for their efforts in this endeavor.

bobwatts
EartH

Druid6900
May 7th, 2009, 11:29 AM
Hi Gang !

Just dropping a public note of thanks to Druid and Jeff for the safe return of my Acculogic sIDE card. It was packaged in a magnificent manner, and looks like new. Thanks Jeff !

Although I haven't tried it out yet, I anticipate great results with the new BIOS ROM that Mr. Leyda has provided. Even if there are conflicts with the loaded devices in my particular machine, I'm confident they can be worked out. Besides, I have the original ROM to re-install should that be necessary.

I will of course have a fire extinguisher handy to keep the smoke and flames to a minimum during initial testing. Hopefully there WILL be some excitement, and not a mundane boring test involving nothing more than bits and bytes performing as they should. What would be the fun in that ?

Once again, my sincere respect to Jeff, Andrew, and others for their efforts in this endeavor.

bobwatts
EartH

Better watch what you wish for, you're liable to get it :)

lutiana
May 7th, 2009, 05:50 PM
SW1 sets the IO address of for the IDE interface. /snip

SW2 follows similar logic for the ROM address /snip


Hi guys,

Please check the attached XLS spread sheet to see if my tables are right.

Thanks

-Jarrod

NobodyIsHere
May 7th, 2009, 06:23 PM
Hi! Well the good news is that the trace router optimizer is doing a wonderful job in the trial run. The PCB is down to 94 vias and less than 400" overall trace length. That is really good it was able to clear up the mess so quickly.

However, that was just a trial run to shake out the normal PCB layout issues. I've rolled in a couple of updates to the layout since starting the trial trace routing. Does anyone have any more comments and/or changes to the design, requirements, PCB layout, etc? Now is the time to get them in and start the discussion! Please take another look and let me know!

Thanks and have a nice day!

Andrew Lynch

mbbrutman
May 7th, 2009, 06:56 PM
Andrew ..

Might want to wait a few days for comments. I'm going to be examining one of Hargle's board fairly shortly, but probably won't have anything to say about it until mid next week.


Mike

NobodyIsHere
May 8th, 2009, 03:03 AM
Hi Mike! Yes, the PCB respin can wait. I suspect there will be more changes required once the initial test group gets their boards and really starts hammering on the design. I have a couple more ideas on how to improve the layout for better trace routing which may help some but will require a restart.

Please let me know if there is anything I can do to help push this along. Its exciting to see this project get closer to something real and I am "champing at the bit" to get this out. Still, another round of testing may be warranted as we already have many changes to the design and probably more are on the way.

What we need are changes to make the HIGH and LOW IO ports adjacent so DMA would work but everytime I look at the design I see that it is absolutely dependent on sequential byte wide reads to get the latching mechanism to work. Does anyone have any bright ideas on how to make this DMA compatible? I had a brief thought of swapping A3 with A0 but I fear it would have such a dire effect on the register compability it would break things. I think it would interleave the registers like this R0, R8, R2, RA, R4, RC, ... etc. I am sure after trying to write and debug a BIOS with a register set like that Hargle would be drinking out of the Windex bottle...

Since this is an Intel machine it may have to be LOW to HIGH adjacent like this R8, R0, RA, R2, RC, R4, etc for the DMA to work but that just adds even more to the confusion. That'd be a simple tweak of flipping A0 with a single transistor inverter. Register level backward compatibility would be gone completely but DMA might work.

Hey Hargle; do you still have your wire wrap prototype? If you've scrapped it and moved on maybe its time for some experimenting. It never worked all that great to begin with so it'd be the ideal candidate for tweaking. I surely hate to break mine as it "works" and I am truly reluctant to "break" working units exploring goofy ideas. We could do this "cutting and jumpering" a broken or unbuilt PCB as well but that's almost a criminal waste of a test asset.

Thanks and have a nice day!

Andrew Lynch

PS, I've been mulling this over a bit more and IIRC there is an unused inverter on U5. If that's still true then the second scenario (R8, R0, RA, R2, RC, R4, etc) could be implemented completely with cuts and jumpers on PCB or prototype board without any "dead bugs"

PPS, never mind... I am thinking 16 bit DMA and we only have 8 bit DMA on a PC/XT. What are the characteristics needed to get 8 bit DMA working? Would replacing A3 with a T flip flop attached to the IO port chip select work? That way you get alternating register set access; on the first IO access you get R0-R7 and on the next you get R8-RF and so on and so forth. That could be done with a new 74LS74 "dead bug" on the circuit board. It would still effect register level backward compatibility though. Also the IDE /DMACK, DMARQ, /CS0, and /CS1 lines are all effected and would have to be qualified for proper operation. Its either an OR or AND gate but its another chip (74LS32?) at least. Also, I assume just hooking the IDE /DMACK and DMARQ lines to the ISA bus would be sufficient but it may have other effects.

hargle
May 8th, 2009, 06:04 AM
I think it would interleave the registers like this R0, R8, R2, RA, R4, RC, ... etc. I am sure after trying to write and debug a BIOS with a register set like that Hargle would be drinking out of the Windex bottle...

yeah, that would make things really difficult. We'd then be DMAing the data in, and then having to double back through the data to flip all the bits in the right order. It would probably be slower than PIO by the time we were finished.



transistor inverter. Register level backward compatibility would be gone completely but DMA might work.

Ah, here's another issue I think. We still need to do PIO for certain tasks, like the POST Identify Device data. Only sector read/writes use DMA, so we still need the ability to do PIO data in/out. The byte ordering of the PIO data doesn't matter-I'll flip stuff around any way it needs to be, but we must have the ability to do both.



Hey Hargle; do you still have your wire wrap prototype? If you've scrapped it and moved on maybe its time for some experimenting.

Yep. I've pulled a few parts off it, but now that I have a fresh stock of ICs, I can put it all back together, no sweat. I'd be happy to mail it to you if you want to play with it w/o breaking yours.



work? That way you get alternating register set access; on the first IO access you get R0-R7 and on the next you get R8-RF and so on and so forth.

I'm a little DMA dumb, especially on an 8bit machine, but I'd think for 8bit DMA, it's pretty much a requirement that all the data comes in through the same IO port. If you can stack the data up like you just described, I think that would work. That byte ordering would also be excellent for PIO too.
I think that's how that tilmann reh design worked. The schematics were back in the thread somewhere.



That could be done with a new 74LS74 "dead bug" on the circuit board. It would still effect register level backward compatibility though. Also the IDE /DMACK, DMARQ, /CS0, and /CS1 lines are all effected and would have to be qualified for proper operation.

I have no idea what other hardware would need to be used for actual DMA transfers to do the handshaking and actual transfers. Someone way back in the thread mentioned some stuff, but I don't remember who.
I also assume that the DMA lines were some that you didn't remove the gold teeth from? :)

I'm really happy to explore this some more. I think Mike coming on board will help a lot too. Cards are shipping today.

hargle
May 8th, 2009, 07:34 AM
Hi! That information you can pull directly off the schematic. SW1 sets the IO address of for the IDE interface. The switches correspond to A4-A9 with the last two switches must be closed. Closed corresponds to 0 and open corresponds to 1 in the address so all closed would be 0x000, the first switch open would be 0x010, and so forth. The only IO address that matters right now is 0x300 which is all closed except switches 5 and 6 open. SW1 addresses bits are "flipped" compared to normally read binary numbers. That is fixed in the updated PCB.

SW2 follows similar logic for the ROM address but follows the normal binary order. The ROM can be placed at any memory addresses starting at the 8K boundary from $00000 through $FE000.


Would it be too bold of me to suggest that we merge the 2 dipswitches together and use 4 bits for each IO space and 4 bits for ROM address? That would give us 16 possible addresses per resource, which should still be more than enough. Most adapter cards only give us about 4 choices each, and no one seems to complain.

The reason I'm thinking this is several-fold:
1) there is no reason to decode IO below 100h. The motherboard resources pretty much keep this area as a no-go zone. My reference material says that ranges between 100 and 3ff are the primary spots for adapter card IO usage.

2) during POST, the option rom is going to need to scan IO to locate the card. With 256 possible current locations, this is going to be time consuming and error prone.

3) likewise with the option rom, we only have C800-EE00 segments to work in, that's only 20 possible locations for an 8k ROM to exist. cutting that down to 16 possible locations through 4 dipswitches is a good enough fix.

4) a little cost savings without another dipswitch.

I'm trying to work out how to wire this up, and can post back with more details, but I don't want to do that work if something like that is going to be more of a headache than it's worth.

Alternately, instead of ganging up the decodes to 2 sets of dips, we could tie a few of the unused address lines off, and route the jumpers over to the dipswitches instead to remove those from the design.

per
May 8th, 2009, 07:44 AM
I'm a little DMA dumb, especially on an 8bit machine, but I'd think for 8bit DMA, it's pretty much a requirement that all the data comes in through the same IO port. If you can stack the data up like you just described, I think that would work. That byte ordering would also be excellent for PIO too.

DMA on an 8-bit machine just moves data between one 8-bit I/O port to memory. A total of 64 Kbytes can be moved at a time, and each transfer takes 3 clock cycles.

I don't think it can toggle between two ports, but I'll investigate the posibilities.

lutiana
May 8th, 2009, 08:24 AM
The reason I'm thinking this is several-fold:
/snip


5. A much smaller table on the two addresses (and easier to print on the back of the card).

Why not remove the dip switches all together and go with a classic set of jumper blocks? I am not sure if this would cut costs a bit or not, but it seems to be there must be a reason why most cards don't have DIP switch banks on them.

NobodyIsHere
May 8th, 2009, 09:42 AM
5. A much smaller table on the two addresses (and easier to print on the back of the card).

Why not remove the dip switches all together and go with a classic set of jumper blocks? I am not sure if this would cut costs a bit or not, but it seems to be there must be a reason why most cards don't have DIP switch banks on them.

Hi! Yes, we could shrink the address ranges on both the IO port and the ROM address to fit on a single DIP switch but the idea of using jumpers is even better because they are cheaper and more reliable. Here is the deal though, with only 16 possibilities each we need to carefully specify the ranges.

For the IO port, there are only 10 bits to work with. The XT-IDE need 16 IO port registers so the lower four bits have to be free. If those below 0x100 are reserved then the upper two bits are basically fixed at A9=0 and A8=1. If we put the four jumpers for bits A7, A6, A5, and A4 the XT-IDE can start at
0x100-0x10F
0x110-0x11F
0x120-0x12F
.
.
.
0x1F0-0x1FF

Is that going two work?

Similiarly with the ROM if we assume address has 20 bits to work with. It needs a memory address window of 13 bits so the lower 13 bits have to be free. If the lowest useful address is $C0000 the upper two bits are fixed at A19=1 and A18=1. If we fix A13=0 then the ROM could appear at

0xC0000-0xC1FFF
0xC4000-0xC5FFF
0xC8000-0xC9FFF
.
.
.
0xFC000-0xFDFFF

If you're happy with these modifications I can roll them into the new design. I will simplify things somewhat and improve trace routing. We can replace two 8 position DIP switches and sockets with a single 2x8 dual row header. I don't think it will reduce the need for pull up resistors on the 74LS688 decoders though.

Thanks and have a nice day!

Andrew Lynch

PS;

IO address map http://www.pcguide.com/ref/mbsys/res/ioSummary-c.html
UMA address map http://www.pcguide.com/ref/ram/logic_UMA.htm

NobodyIsHere
May 8th, 2009, 10:13 AM
Hi Hargle! I was looking at the IO address map and now am starting to wonder if accessing both drives on a dual drive IDE cable is even possible. Have you tried it? Now I am not sure if I've ever seen it work with two drives or not.

It seems on a modern system the primary IDE controller master drive is at 0x1F0-0x1FF and the slave drive is at 0x3F0-0x3FF. How is the slave drive accessed on the XT-IDE? I don't see any mechanism that ties an address line to CSEL. CSEL is connected to a pull up resistor so its always high.

What is your BIOS code doing to distinguish between master and slave drives?

Thanks and have a nice day!

Andrew Lynch

PS, nevermind... drive selection is done with one of the IDE registers

per
May 8th, 2009, 10:24 AM
There is one way we could make DMA possible. That is if we add one I/O port that preforms either a xx0 I/O or a xx8h I/O each other or even time it's used. (that is, tie the active line of port xx0 to a counter/1-bit demultiplexer, and drive the once-xx0/xx8 port each other I/O. See the upcoming attachement.)

per
May 8th, 2009, 10:29 AM
There is one way we could make DMA possible. That is if we add one I/O port that preforms either a xx0 I/O or a xx8h I/O each other or even time it's used. (that is, tie the active line of port xx0 to a counter/1-bit demultiplexer, and drive the once-xx0/xx8 port each other I/O. See the upcoming attachement.)

In other words, two writes/reads from one certain port will ressult in one R/W from/to port xx0 and one R/W from/to port xx8. This sequence repeats each 2 R/W's.

hargle
May 11th, 2009, 06:53 AM
hi! back to work here, after taking a couple days off over the weekend.



If those below 0x100 are reserved then the upper two bits are basically fixed at A9=0 and A8=1. If we put the four jumpers for bits A7, A6, A5, and A4 the XT-IDE can start at
0x100-0x10F
0x110-0x11F
0x120-0x12F
.
.
.
0x1F0-0x1FF

Is that going two work?


Last night, I checked my 100h-1ffh range on my zenith 8088, and it looked to me that the entire range was full of other things decoding in that address range. The entire 200h range appeared to be empty. The 300h range had some stuff in it too (video at a minimum), but certainly our favorite 300-30f is free.

I should (or Per will likely beat me to it) check to see how the 1xx range is being used on a true XT and PC, and also see what's being decoded in the 2xx range.

Right now, I'm leaning toward having you tie bit 9 high, 4:0 low, and let the switches be bits 8:5. That'll put us at either 2xx or 3xx and it'll increment in steps of 20h.
Like such:


98 7654 3210
10 0000 0000 = 200h
10 0010 0000 = 220h
10 0100 0000 = 240h
10 0110 0000 = 260h
10 1000 0000 = 280h
10 1010 0000 = 2A0h
10 1100 0000 = 2C0h
10 1110 0000 = 2E0h
11 0000 0000 = 300h
11 0010 0000 = 320h
11 0100 0000 = 340h
11 0110 0000 = 360h
11 1000 0000 = 380h
11 1010 0000 = 3A0h
11 1100 0000 = 3C0h
11 1110 0000 = 3E0h





Similiarly with the ROM if we assume address has 20 bits to work with. It needs a memory address window of 13 bits so the lower 13 bits have to be free. If the lowest useful address is $C0000 the upper two bits are fixed at A19=1 and A18=1. If we fix A13=0 then the ROM could appear at

0xC0000-0xC1FFF
0xC4000-0xC5FFF
0xC8000-0xC9FFF
.
.
.
0xFC000-0xFDFFF

If you're happy with these modifications I can roll them into the new design.

I think that's perfect. Plenty of room. Heck, even moving it around using only 3 bits and having the 4th be a ROM enable/disable would be fine.


I think we (per?) could write a little utility that scans IO space looking for unused IO in the above ranges, and then also scans for an 8k chunk of ROM space to use, and then prints out to the screen a good dip switch setting display. Users could run that software before putting the card in.





It will simplify things somewhat and improve trace routing. We can replace two 8 position DIP switches and sockets with a single 2x8 dual row header. I don't think it will reduce the need for pull up resistors on the 74LS688 decoders though.


This really is a win-win. costs go down, simplicity goes up. I personally prefer dipswitches to jumpers for something like this though.
So I'm visualizing an 8 dipswitch to control all the addresses, and then a jumper block to control the enable/disables and IRQ selections. Sound right?

NobodyIsHere
May 11th, 2009, 07:14 AM
Hi! Its OK with me. I'll cut in the changes tonight and repost the schematic and PCB layout.

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 11th, 2009, 04:24 PM
Hi! OK done. Please check out and review the schematic and PCB layout on the N8VEM wiki. Thanks and have a nice day!

Andrew Lynch

mbbrutman
May 11th, 2009, 05:13 PM
I am running one of the Hargle cards now. It is, in a word, magnificent.

Right now it is running in an original XT with a 40GB Western Digital drive. The drive had DOS 7 installed. I nearly died when it booted to DOS 7 on the first attempt.

A simple I/O benchmark that I wrote shows 80KB/sec writing an 87KB/sec reading. No, it is not a speed demon. But this PIO based code has a quite a few things going for it:


No IRQs required - nice for our target systems, which are short on IRQs anyway. Also simplifies setup.
No DMA required, which is also night
The code should be pretty portable to other machines (like the PCjr) that don't have DMA


I'm going to burn this drive in nice and hard .. and I have a few more to test against too.


Once again fellas, magnificent. I will buy beer when I see you in person. (For Jeff that is a very real threat.)


Mike

Unknown_K
May 11th, 2009, 06:21 PM
How does the speed compare to an XT era MFM drive and controller?

NobodyIsHere
May 12th, 2009, 02:55 AM
I am running one of the Hargle cards now. It is, in a word, magnificent.



Thanks Mike!




Right now it is running in an original XT with a 40GB Western Digital drive. The drive had DOS 7 installed. I nearly died when it booted to DOS 7 on the first attempt.

A simple I/O benchmark that I wrote shows 80KB/sec writing an 87KB/sec reading. No, it is not a speed demon. But this PIO based code has a quite a few things going for it:


No IRQs required - nice for our target systems, which are short on IRQs anyway. Also simplifies setup.
No DMA required, which is also night
The code should be pretty portable to other machines (like the PCjr) that don't have DMA




Yes, the plain PIO approach has its benefits! The production board will support a range of IRQs (see the N8VEM wiki) so when the time comes for software support of IRQs the board can do it.

I've looked into DMA but so far no luck. That really raises the bar on complexity. Having a working example of a simple DMA device would help but I think it would drive pretty massive changes to the design.

Regarding performance, almost all the development so far has been on just basic functionality. I believe that once the design settles and everything works that the transfer speed will improve somewhat. There are things like loop unrolling, etc which can boost transfer rates. However its premature to deal with that now. Hargle's done a great job on the BIOS but there is a lot of complexity in supporting a variety of IDE devices and PC machines.

If you would, see if you can get the XT-IDE to share the PC with a MFM/RLL style ST-412/ST-506 controller preferrably with its own BIOS. In my testing there seems to be a problem someplace regarding the XT-IDE and my other XT disk controllers with BIOS (FDC and MFM HD).





I'm going to burn this drive in nice and hard .. and I have a few more to test against too.


Once again fellas, magnificent. I will buy beer when I see you in person. (For Jeff that is a very real threat.)


Mike


Great! Please experiment with the XT-IDE and drives. When you get a chance please check out the latest schematics and PCB layout for any considerations for the production unit.

Thanks and have a nice day!

Andrew Lynch

per
May 12th, 2009, 03:55 AM
I've looked into DMA but so far no luck. That really raises the bar on complexity. Having a working example of a simple DMA device would help but I think it would drive pretty massive changes to the design.

DMA-capabilities migth be availible just by adding 3 ICs (2 if we can get a 2-in-1 counter). I've not checked if we need to add any NOT gates to make it work, but it should.

What the logic I've come up with does is that it toggles between triggering one of two output-lines each time one input line is triggered. Because of this, you don't need to do "In base+0" and "In base+8" to read a word, it is enough with two "in base+0".

If I'm right about DMA, this will actually work.

I'll post more of it tomorow (as I don't got time now).

bobwatts
May 12th, 2009, 04:23 AM
Hi Gang !

As I mentioned previously, I got the Acculogic sIDE card back the other day, but unfortunately, haven't gotten a spare second to install it, and try out the new "hargle" BIOS.

I can't find the thread message now, but I was curious if the card will still support two IDE drives. I seem to recall that there was/is maybe an issue with this. I have two IDE drives installed, and the sIDE card worked fine with 'em previously.

My XT is really packed away, and just not easy to get to, but I will soon to test it out.

bobwatts
EartH

NobodyIsHere
May 12th, 2009, 05:20 AM
DMA-capabilities migth be availible just by adding 3 ICs (2 if we can get a 2-in-1 counter). I've not checked if we need to add any NOT gates to make it work, but it should.

What the logic I've come up with does is that it toggles between triggering one of two output-lines each time one input line is triggered. Because of this, you don't need to do "In base+0" and "In base+8" to read a word, it is enough with two "in base+0".

If I'm right about DMA, this will actually work.

I'll post more of it tomorow (as I don't got time now).

Hi Per! I was thinking that to get the interleaved HIGH/LOW reading from a single IO port that was to use a 74LS74 flip flop on the latches chip select line for the latches. A reset signal would clear the flip flop, then the first read would give HIGH, the next LOW, the next HIGH again, and so forth. Eliminate the use of the A3 line and just use the flip flop output to toggle back and forth. (74LS74 configured as JK FF with direct clear)

What complicates matters is that the IDE chip select signals cannot be asserted during the DMA transactions. So they would have to be qualified (with 74LS32 and probably a 74LS04 inverter) with the DMA status lines. This gets complicated since there are two separate IDE chip selects.

Here is some information from the IDE "standard":



6.3.8 DMACK- (DMA acknowledge) (Optional)
This signal shall be used by the host in response to DMARQ to either
acknowledge that data has been accepted, or that data is available.

6.3.9 DMARQ (DMA request) (Optional)
This signal, used for DMA data transfers between host and drive, shall be
asserted by the drive when it is ready to transfer data to or from the host.
The direction of data transfer is controlled by DIOR- and DIOW-. This signal
is used in a handshake manner with DMACK- i.e., the drive shall wait until the
host asserts DMACK- before negating DMARQ, and re-asserting DMARQ if there is
more data to transfer.
When a DMA operation is enabled, IOCS16-, CS1FX-, and CS3FX- shall not be
asserted and transfers shall be 16-bits wide.
NOTE 2 - ATA products with DMA capability require a pull-down resistor on this
signal to prevent spurious data transfers. This resistor may affect driver
requirements for drives sharing this signal in systems with unbuffered ATA
signals.


http://www.ele.uri.edu/courses/ele408/s2001/projects/roland_ide/IDE.pdf

I am fuzzy on the whole DMA implementation to begin with so whatever design does finally surface would require some test with a prototype board to ensure it really works. I see this easily adding several chips to the design which is why I believe the GIDE developers ended up using GALs to keep part count reasonable. If adding DMA capability comes at the price of doubling part count I do not think its worth it as it would dramatically increase unit cost due to additional parts, larger PCB required, etc. There are benefits to keeping this simple and cheap!

Thanks and have a nice day!

Andrew Lynch

geneb
May 12th, 2009, 06:06 AM
Have you guys thought about checking Rolf Brown's Interrupt List to see what can use the port and memory addresses you guys are using? It might help avoid conflicts...

Oh, and I WANT ONE! :D

g.

gerrydoire
May 12th, 2009, 11:58 AM
Does the Acculogic IDE 8 Bit Card support DMA?

hargle
May 12th, 2009, 12:32 PM
Have you guys thought about checking Rolf Brown's Interrupt List to see what can use the port and memory addresses you guys are using? It might help avoid conflicts...
g.

of course. ralf is bookmarked on every machine i have.
that doesn't help with other option roms from other hardware vendors though. like our card, they may be configured to decode over a wide range of locations in memory and IO, and there's no way of knowing what's free without first examining the system and looking. This is entirely why Plug-n-Play was introduced.

It'll be really easy to create a quick-n-dirty program to scan through IO and memory and find an appropriate location for our card to be, and then display on the screen in high-definition ASCII characters how to configure the dip switches on our card before you actually plug the card in.

Advanced users may skip this step, but then you're on your own. I'm not giving out my number for tech support, despite what mike brutman may believe. :)

hargle
May 12th, 2009, 12:33 PM
Does the Acculogic IDE 8 Bit Card support DMA?
No. I can't actually even see where it's supporting an IRQ, even though it claims it does.

I don't know of any 8bit DMA capable cards other than a soundblaster.
Maybe a SCSI controller?

hargle
May 12th, 2009, 12:38 PM
Regarding performance, almost all the development so far has been on just basic functionality. I believe that once the design settles and everything works that the transfer speed will improve somewhat. There are things like loop unrolling, etc which can boost transfer rates. However its premature to deal with that now.

indeed.
compatibility and stability over performance right now. I've documented a half dozen things in the BIOS source that we can do to improve performance all around, and I really look forward to putting some of these improvements to work once the main testing is done and the BIOS is stable. (which I think it pretty much is already)

Mike, please post your quick-n-dirty benchmark, and shortly we'll look into implementing some improvements and we'll see where we can get it.

I'd also love to see some comparisons between us and MFM and even SCSI.

geneb
May 12th, 2009, 12:40 PM
Thanks for the clarification Hargle. I'm dying to get one of those cards. :) I've already got my 5170 running off of a 1GB CF card as well as my Amiga 2000. I'd love to be able to use the 5160 the same way. The original 10MB MFM drive ain't gonna last forever. :)

Awesome work guys!

g.

hargle
May 12th, 2009, 01:32 PM
well, I just happen to be about to start the build process on 2 more of them in about 30 minutes time....

We had 10 cards, and only half as many tester volunteers who could help out with the debug work. The other cards could certainly go up on the auction block to help pay for the development costs of the whole project.

These early proto cards aren't going to be as sexy as the final product, but it could be your chance to own a signed and numbered, extremely limited edition, first edition piece of computer history.

operators are standing by... :)

(I'm serious, I think I will have 3 or 4 cards that could go up for sale. PM me)

NobodyIsHere
May 12th, 2009, 03:15 PM
Hi! I agree. With the latest test results I think we are probably past the big hump on the PCB prototype. We need some testers who are going to beat on this design and drive out the bugs. I mean some ruthless beat down testing. If there are people willing to test lets have a go at it and get as much value out of these initial test units as possible.

Thanks and have a nice day!

Andrew Lynch

lutiana
May 12th, 2009, 03:26 PM
Andrew, I notice your latest circuit design your description for JP1 and JP2 is not as clear as before (looks like some text was removed).




I think that's perfect. Plenty of room. Heck, even moving it around using only 3 bits and having the 4th be a ROM enable/disable would be fine.


I think this is a great idea. You'd have a 8 switch dip, switch 1 to 4 are for IO address, switch 5 is BIOS on/off and switches 6 - 9 are for BIOS memory address. This simplifies the table of values quite a bit, and give plenty of options for the BIOS memory range (7). It also cuts out a jumper (JP1?), but leaves the IRQ selection and write enabled settings in jumper form.



I think we (per?) could write a little utility that scans IO space looking for unused IO in the above ranges, and then also scans for an 8k chunk of ROM space to use, and then prints out to the screen a good dip switch setting display. Users could run that software before putting the card in.


I think this is a great piece of software to have in general for non-plug and play systems.



Yes, the plain PIO approach has its benefits! The production board will support a range of IRQs (see the N8VEM wiki) so when the time comes for software support of IRQs the board can do it.

I've looked into DMA but so far no luck. That really raises the bar on complexity. Having a working example of a simple DMA device would help but I think it would drive pretty massive changes to the design.


Why do you need DMA support or IRQ support? Would these merely improve performance and throughput or are there are capabilities these bring to the table?



If you would, see if you can get the XT-IDE to share the PC with a MFM/RLL style ST-412/ST-506 controller preferrably with its own BIOS. In my testing there seems to be a problem someplace regarding the XT-IDE and my other XT disk controllers with BIOS (FDC and MFM HD).


What would be a great add to this card would be a FDC Bios, to allow for high density 5.25 and 3.5 disk drives. But lets save that for Revision 3 of the final card (if it is even possible) :D

This is coming along nicely, the design is definitely getting ironed out well, though it looks to be pretty stable for how early on in the project it is. Great job guys.

geneb
May 12th, 2009, 04:39 PM
Unfortunately, I don't have the time to really do a debug process justice. :(

g.

mbbrutman
May 12th, 2009, 05:30 PM
Hi! I agree. With the latest test results I think we are probably past the big hump on the PCB prototype. We need some testers who are going to beat on this design and drive out the bugs. I mean some ruthless beat down testing. If there are people willing to test lets have a go at it and get as much value out of these initial test units as possible.

Thanks and have a nice day!

Andrew Lynch

The burning has already begun. :-) My smaller drives (2GB and 6GB) are problematic - Hargle and I are debugging.


Mike

hargle
May 12th, 2009, 05:44 PM
Here's a utility that will help with this debug.
It has already shown me an error on my system too.

http://www.waste.org/~winkles/int13test.zip

This dumps out the drive parameter table(s) as well as what int 13 fn 48 and 8 report back.
What I need folks to do is take a drive, preferably 10G or less and put it in a modern machine. Run this program and redirect the results to a file.
Do the same on your XT. If the results are different, send them to me.

I've already seen a bug on my end with this tool, and that could very easily be what is causing your problems too. hopefully I can dig in shortly.

---------------------------

Good news!
I've finished card #5 and it worked right out of the shoot.
I also gave a workover to cards #1 and it is now working as expected.
Card #4, the one that was dropping case on the ID string worked at least 1 time tonight (I swear!), but is now back to dropping the characters again. It's really weird indeed.
So I have two cards at the moment that appear to be as good as all the others, and one that works, but works a little wonky.
---------------------------

Bad News!
I have 2 more bad eeproms. Either these SEEQ parts are just really horrible, or I've managed to wreck 3 parts now, possibly due to card #1 being troublesome.
That makes 3 bad eeproms out of 11 that I purchased for this project. (1 went to bob watts)

So, if we get any programming failures in the immediate future from BIOS upgrades, I suggest we dump these SEEQ parts and find something else, like the atmel's that were working just fine from the wire wrap cards.

that's it for me tonight.

Druid6900
May 12th, 2009, 07:42 PM
Hi! I agree. With the latest test results I think we are probably past the big hump on the PCB prototype. We need some testers who are going to beat on this design and drive out the bugs. I mean some ruthless beat down testing. If there are people willing to test lets have a go at it and get as much value out of these initial test units as possible.

Thanks and have a nice day!

Andrew Lynch

Ok, I think I might squeak by as a qualified tester and, since I've set up an XT testbed to run all the 8-bit cards I have to still test through, I can give it a real world shakedown with a LOT of strange cards to see if it fouls up somewhere and put a good number of miles on it.

per
May 13th, 2009, 02:22 AM
Hi Per! I was thinking that to get the interleaved HIGH/LOW reading from a single IO port that was to use a 74LS74 flip flop on the latches chip select line for the latches. A reset signal would clear the flip flop, then the first read would give HIGH, the next LOW, the next HIGH again, and so forth. Eliminate the use of the A3 line and just use the flip flop output to toggle back and forth. (74LS74 configured as JK FF with direct clear)

What complicates matters is that the IDE chip select signals cannot be asserted during the DMA transactions. So they would have to be qualified (with 74LS32 and probably a 74LS04 inverter) with the DMA status lines. This gets complicated since there are two separate IDE chip selects.

Here is some information from the IDE "standard":



http://www.ele.uri.edu/courses/ele408/s2001/projects/roland_ide/IDE.pdf

I am fuzzy on the whole DMA implementation to begin with so whatever design does finally surface would require some test with a prototype board to ensure it really works. I see this easily adding several chips to the design which is why I believe the GIDE developers ended up using GALs to keep part count reasonable. If adding DMA capability comes at the price of doubling part count I do not think its worth it as it would dramatically increase unit cost due to additional parts, larger PCB required, etc. There are benefits to keeping this simple and cheap!

Thanks and have a nice day!

Andrew Lynch

I've made some schematics. I've using the more flexible 74LS161 counter, but if a flip-flop will do, it'll problably be better. Currently, it just adds 4 IC's to the design.

About the not-assert-thing, we can invert the AEN signal and AND it with the lines we need to hold low when DMA is being active. If it need to be held high, an "OR" with a non-inverted AEN signal is enough.

Anyway, take a look at the schematics for my solution about how to read it all from one port (one is how it is now, the other one is my idea).

per
May 13th, 2009, 07:15 AM
please, Please, PLEASE make a posts-in-progress-to-be-temporarely-saved-on-posting-failure function! This is the third time I write this post :mad:

sorry for yelling...

---

I suggest you put a pull-up resistor on the line after J2. Else, we can't guarantee that the /WE goes high.

Writing a program to search for free memory in the upper areas is easy, but doing the same for I/O addresses might cause troubble. If you read from a write-only port, weird stuff may happen. You also have ports that returns 00h by purpose. I would suggest setting the card to the settings reserved for the fixed disk controller (according to the tech-ref: I/O port 320h, Base addres for ROM at C800:0000, and IRQ 5) and just assume the user reads the manual.

Adding DMA-compability problably adds something between $5 and $10 to the total costs. I've already replaced the counters with flip-flops (with /Q tied to D, see the updated schematics) so that reduces the chip-count by one. This means that the additional chip-count is 3 plus what-we-need-to-ajust-CS (one or two extra ICs), hence the total additional chip-count won't be more than 5 ICs.

In addition, we need somebody that's able to add DMA capabilities to the BIOS as of neither me or Hargle really knows how to program with DMA.

per
May 13th, 2009, 11:04 AM
After reading this ( http://www.google.no/patents?id=Oht9AAAAEBAJ&dq=7146440+IDE&printsec=frontcover&source=bl&ots=BaQkNxcUvY&sig=yL2dleuQl98aofuqNEIBiwt-oS8&hl=no&ei=RRgLSrDSMNKD-Qb_msC9CA&sa=X&oi=book_result&ct=result&resnum=9#PPA4,M1 ) , it turns out for me that DMA might be a little complex. If anybody here knew anything about DMA, it would be great, but it seems right now that it's a lot of guessing and stuff.

I'm confused at least. I can say that for sure.

hargle
May 13th, 2009, 11:23 AM
Writing a program to search for free memory in the upper areas is easy, but doing the same for I/O addresses might cause troubble. If you read from a write-only port, weird stuff may happen. You also have ports that returns 00h by purpose.

Unused ports return FF, just like unused memory, so if you see 00, you should skip it. There shouldn't be too much in the 200-300 range to cause us problems (just add on cards), and the idea is that you run this program and then power off to insert our card, so even if we put the machine in a bad state, we're power cycling anyway.
Unless it completely locks up the machine to read from a write only port, the program should be able to do what it needs to do. Either way, this is only a helpful program for inexperienced users to mess with.



In addition, we need somebody that's able to add DMA capabilities to the BIOS as of neither me or Hargle really knows how to program with DMA.

The only DMA work I've done is on a soundblaster 1.0 card.
http://www.waste.org/~winkles/hardware/soundblaster/sb.asm

I do twiddle the DMA controllers directly to do the transfer, but how it actually operates in the hardware is beyond me.
I should see if that code works on an XT. I've only ever tried it on a 386 or better, but it is using 8086 friendly code.

I plan on using some of the routines from that code for the IRQ detection, and if we play with DMA, that code should also come in handy.

--------
I've got this book called "the undocumented PC" and it describes in pretty good detail how a DMA transfer is done from an adapter card into memory.
Should I type it up?

per
May 13th, 2009, 11:39 AM
What needs to be done in the BIOS to add DMA support?

I really don't know, but I think we have to make the drive aware that we're doing DMA transfers.

I don't know really well how DMA works (neither software or hardware), but I know it has something to do with doing multipile IO port reads from one port with a piece of memory as the destination.

If I only knew how the chip select signals are used... Should they be held high or low when DMA is active?

hargle
May 13th, 2009, 12:14 PM
I really don't know, but I think we have to make the drive aware that we're doing DMA transfers.

I was thinking you were referring to the mainboard BIOS, hence my confusion and my edit later. (my bad)
I should reiterate that I've done DMA transfers on other hardware. If you guys get the hardware to work, I will absolutely get it working in the bios! :)

Here's the writeup from undoc PC:

A typical I/O to memory transfer:
This shows the sequence of events when a DMA is initiated, performing a data transfer from an adapter card's IO directly into memory. This is considered a DMA write. DMA channel 3 is used in this example, (hargle: which is good, cuz that's the DMA channel for HDD!) and no other DMA transfers are in progress.

The complete processing of this transfer occurs in the following sequence:

1) a device driver (BIOS) initialization routine programs the DMA chip, setting up the following information:
Base address in memory where the 1st write should begin. The lower 16-bits are programmed in the DMA controller, channel 3. The upper address bits are programmed into the page register 3.
Count of bytes to transfer on the request, less 1, is placed into the DMA controller channel 3.
The transfer mode is selected as "demand mode"
The direction count is set to increment.
The transfer type is set to "write"
the DMA mask is updated to allow DMA Request 3 (DREQ 3)

2) The adapter card requests DMA service by asserting a high on the DMA request line (DREQ 3)

3) The DMA controller verifies that DREQ 3 is allowed, and then asks the CPU to go into a hold mode by asserting the hold request line (HRQ)

4) The CPU responds by asserting the Hold Acknowledge (HLDA) and goes into a bus hold state.

5) An address generated by the DMA system is passed onto the bus. The memory write and IO read control lines are also activated. The DMA acknowledge (DACK 3) signal is activated, so the adapter card is aware the transfer is now in progress.

6) The data is transferred directly from the adapter card to memory without passing through the DMA controller. The cpu interweaves normal cycles and bus holds cycles as the transfer proceeds, under control of the DMA controller.

7) The transfer completes when the DMA controller's count completes, or if the transfers are going too fast for the adapter, the adapter can temporarily hold the transfer by dropping the DREQ 3 line.

8) At completion, the DMA controller asserts the Terminal Count (TC) line to signal the adapter card that the transfer is complete. The Hold Request (HRQ) and the DMA acknowledge line (DACK 3) are deactivated.

9) the adapter turns off the request (DREQ 3)

10) The cpu resumes normal operation

--------------------------

#1 is all BIOS. No sweat on any of that.
#2 probably comes from the drive itself, asserting dreq when data is ready
#3 no concern for us
#4 no concern for us
#5 ?
#6 I'm assuming that if you can get 512 IO reads from a single port to transfer 1 sector of data, we're set here.
#7 driven from the drive, signals that the data is finished
#8-10 no concern for us.

So I think a big huge step toward DMA is getting all the data to appear via a single IO read. That would help speed up PIO as well, so that would be useful even if we go no further.

NobodyIsHere
May 13th, 2009, 12:44 PM
Hi! Based on the discussions I am starting to think we should just "snap a baseline" for the existing XT-IDE design with PIO+IRQ+BIOS. Then start a new development for a "Version II" model that supports DMA. I think we could spend a lot of time exploring DMA and not getting anything out. What we have is pretty good and is a >90% solution for most people.

Concentrate on getting the production XT-IDE board out "as is" and then focus on another iteration that supports DMA or other advanced features *if there is a need for it*. I know some people would like DMA and so would I which is why I looked into it but there appears to be so many unknowns associated with it that I believe it would interfere with releasing the good stuff we've already gotten. Besides, I think any design with DMA would need another round of wire wrap prototypes, new BIOS versions, etc.

Thanks and have a nice day!

Andrew Lynch

geneb
May 13th, 2009, 01:06 PM
How does the data rate on the current card compare to a typical 8 bit MFM hd controller?

g.

per
May 13th, 2009, 01:10 PM
Hi! Based on the discussions I am starting to think we should just "snap a baseline" for the existing XT-IDE design with PIO+IRQ+BIOS. Then start a new development for a "Version II" model that supports DMA. I think we could spend a lot of time exploring DMA and not getting anything out. What we have is pretty good and is a >90% solution for most people.

Concentrate on getting the production XT-IDE board out "as is" and then focus on another iteration that supports DMA or other advanced features *if there is a need for it*. I know some people would like DMA and so would I which is why I looked into it but there appears to be so many unknowns associated with it that I believe it would interfere with releasing the good stuff we've already gotten. Besides, I think any design with DMA would need another round of wire wrap prototypes, new BIOS versions, etc.

Thanks and have a nice day!

Andrew Lynch

What is the transfer boost gained by DMA?

I have researched the document you linked to, and we actually only need to add one additional 74LS32 chip.

So in order to support DMA, 1 resistor, 4x 2-header jumper blocks, 4 capacitors, and 4 ICs have to be added (one 74LS74, one 74LS139, one 74LS08 and one 74LS32). This will also fix some issues that might appear since /IOCS16 is not connected to anything (since there is no problems yet, most drives problably got a pull-down resistor on this line).

Anyways, we could make a poll, where we ask if people would like to wait to see if the DMA version get successfull. About the wire-wrap prototype, you already got most of it already done since only some lines are redirected/altered/added. See below for the last changes that has to be made according to the document.

per
May 13th, 2009, 01:42 PM
I might have posted stuff in a little too fragnemted way. Anyways, if DMA should be considered in the future, here is my solution to how to make the card compatible. It should theoretically work, so if there is any interest, I would recomend to try it.

Nothing of the existing schematics have to be removed, it's just additions.

gerrydoire
May 13th, 2009, 01:43 PM
I wish I could help you guys out with this card, unfortunetly, this stuff is way beyond me, if you need a beta tester I have give it a whirl though.


:D

NobodyIsHere
May 13th, 2009, 01:44 PM
Hi Per! I don't know the speed gains from DMA. They could be significant or they might be very little. DMA is a big deal on faster CPUs but on the older PC/XT systems it was less of an issue.

I like the idea of DMA it is just how to do it. I am sure that I don't want to further delay the project by chasing ever greater features while not ever getting anything out to the people who want it.

At a minimum, we need to resolve the unknowns about DMA and do some prototyping before making any decisions on DMA capability. We'll need working hardware and Hargle has to be able to use it to write a BIOS.

Probably a good approach would be to continue on the path we are on to a summer release of the current design and I modify Hargle's semi-working wire wrap prototype with the new DMA features. Once that's in place, Hargle could send me some test code to see if it works and if it does I'll send the prototype back to him for more BIOS tweaks.

I suggest this be done in parallel with the current design as there may be some surprises resulting in delays, etc.

Thanks and have a nice day!

Andrew Lynch

per
May 13th, 2009, 01:58 PM
I suggest this be done in parallel with the current design as there may be some surprises resulting in delays, etc.

Thanks and have a nice day!

Andrew Lynch

That's a good idea.

Just make sure to keep us notified if you get my schematics to work ;) .

---

About DMA speeds, one transfer takes 5 clock cycles. Each clock cycle takes 210nS, so each byte-transfer takes 1.05uS

So teoretically, with DMA, you can transfer 1 000 000 / 1.05 bytes per second. That's just a little less than 1Mb/s.

However, the DMA controller of the XT can't transfer more than 64 Kb at a time, so this will have an effect on the transfer rate. There are other stuff affecting the rate too (like DRAM refresh), but rates up to 300kb/s should be possible after my guess.

lutiana
May 13th, 2009, 02:17 PM
Probably a good approach would be to continue on the path we are on to a summer release of the current design

Ahh, the voice of reason :D

I agree with Andrew that DMA is something that can be implemented in version 2 of the card.

With that being said, how hard would it be to incorporate a Floppy controller into this design so that they were on one card? Not saying you should, I am just curious about its feasibility.

NobodyIsHere
May 13th, 2009, 05:16 PM
please, Please, PLEASE make a posts-in-progress-to-be-temporarely-saved-on-posting-failure function! This is the third time I write this post :mad:

sorry for yelling...

---

I suggest you put a pull-up resistor on the line after J2. Else, we can't guarantee that the /WE goes high.

[snip]




Hi Per! Thanks! Great catch!

Thanks and have a nice day!

Andrew Lynch

hargle
May 14th, 2009, 12:07 PM
I concur with the thought of cutting the development of DMA for now and getting this new board made up. Less risk, and will certainly work good enough for most people. Since the 1st round of 10 PCBs and parts weighed in at about $40 per card to build, I think if we pursued DMA and then did a tiny run of 25 cards or so, we could still get some buyers. Probably not 100 like we have for this design, or there's crazier people out there than I thought! :)

That said, do you think we can do a big run with the existing design, or should we do another run of 10 cards (or less), to make sure we're good to go?

I do want to see if pulling csel low causes any changes to functionality. if it doesn't, I'd like to get rid of that option altogether. that'll simplify the design and build process even more. I think we may want to wait til the last minute to pull that feature out, just so we don't confuse functional changes with any BIOS bugs that we're now discovering...

barythrin
May 14th, 2009, 12:41 PM
I'm sure it's a dumb question but is the intent that we (users of the cards) use an additional/external power supply for the hard drive? (ie for systems that can't handle that load)

per
May 14th, 2009, 12:51 PM
I'm sure it's a dumb question but is the intent that we (users of the cards) use an additional/external power supply for the hard drive? (ie for systems that can't handle that load)

If you replace a fixed-disk with this card and an IDE drive, the load will acutally be a lot less than with the original MFM drive.

Reasons for this is mainly because of a smaller chip-count on the interface card, and that the IDE drives are smaller than the noisy full-height drives.

hargle
May 14th, 2009, 12:52 PM
I'm sure it's a dumb question but is the intent that we (users of the cards) use an additional/external power supply for the hard drive? (ie for systems that can't handle that load)

Certainly if you're replacing an MFM/RLL card+drive with this setup, you should have all the power you need. It appears that modern IDE HDDs take up about 7-10 watts each when reading/writing. If you don't think your supply can give you that much, I'd suggest getting a compact flash to IDE adapter and using a couple gig CF card. That should be really low power.

edit: yeah, what per said. :)

Terry Yager
May 14th, 2009, 03:14 PM
These early proto cards aren't going to be as sexy as the final product, but it could be your chance to own a signed and numbered, extremely limited edition, first edition piece of computer history.

operators are standing by... :)


You forgot to autograph mine, and as for numbering, lessee, I assembled it on Monday night between 8 and 9 p.m. What's that make it, #4 or so?

Really, anybody interested in learning/doing kit-building should look at one of these boards in unassembled state. Very simple buildup, took about 45 minutes. I'd call it a beginner-to-intermediate level kit, FWIW.

--T

NobodyIsHere
May 15th, 2009, 02:52 AM
[snip]
With that being said, how hard would it be to incorporate a Floppy controller into this design so that they were on one card? Not saying you should, I am just curious about its feasibility.

Hi! I made a floppy disk/IDE controller on the N8VEM home brew computer and it was probably the toughest project yet. Floppy drive controllers are definitely non-trivial. However, in this case we could probably "clone" an FDC circuit since it is a relatively common device. I would significantly add to the part count though. Probably the simplest circuit would be based on a SMC FDC9266 and a latch. Add in IO port decoding and interface buffers and it will at least double the part count of the XT-IDE.

Check out the Disk IO board schematic and PCB layout on the N8VEM project to see what I mean.

Thanks and have a nice day!

Andrew Lynch

hargle
May 15th, 2009, 06:11 AM
Hi! I made a floppy disk/IDE controller on the N8VEM home brew computer and it was probably the toughest project yet. Floppy drive controllers are definitely non-trivial. However, in this case we could probably "clone" an FDC circuit since it is a relatively common device. I would significantly add to the part count though. Probably the simplest circuit would be based on a SMC FDC9266 and a latch. Add in IO port decoding and interface buffers and it will at least double the part count of the XT-IDE.


I'm always up for more BIOS projects, and I'm certain I can handle the demands of a floppy drive. (I know they are not exactly easy to work with, but with a controller like the 9266, it should make my job a lot easier)

I've done a lot of work with SMC superIOs on previous projects at work, and their parts are really great to work with. I wonder how far we could push the envelope and do up some kind of I/O card: LPT, COM, HD floppy+IDE...

Are there later models of SMC parts after the 9266 where they added COM or LPT ports, but were still available in a workable package? Heck, even a lower pin count SOIC package might not be *that* hard to solder down.

Just thinkin, and volunteering for more work, but we're getting WAY ahead of ourselves here!

geneb
May 15th, 2009, 06:13 AM
For me, I'd be happy with just the IDE card. :D

I'd like to get one of the ones from the upcoming production batch. :)

g.

per
May 15th, 2009, 06:42 AM
I want to make a statement about signal noise. Everybody with some knowledge of electronics know that moving electrons generates a magnetic field. The strength of this magnetic field depends on how the electorns move. The most imporiant thing is that changes in this magnetic field affects other electrons close to it. Because of this, stuff like signal-noise may happen.

I have had some issues when testing. Sometimes, the card just fail to read the signature/the partion table/a sector. The rate of the failures varied if I moved the drive or the cable a little (like tilting or flipping it), but I really couldn't figure out what caused the problems until pretty recently.

When I was testing, the drive was put on top of the 3.5" floppy disk drive (on a plastic sheet to make sure nothing shorted), next to the 5.25" FD drive. Everybody that has opened an XT know that there is very little opening between the rear of the drive-bays and the PSU. It's barley enough space for the floppy/fixed drive interface cables.

So when I tested one of my IDE drives, the interface cable was forced inbetween the floppy drive cable and the 200W powersupply. If you read the first paragraph, you'll see that this might cause problems. I recently moved the drive out of the computer, but still connected, and I haven't gotten any errors yet.

So is it just me, or is the IDE interface sensitive for signal-noise?

NobodyIsHere
May 15th, 2009, 07:01 AM
Hi Per! Yes, the IDE interface is somewhat susceptible to EMI. Make sure you:

1. have a good IDE cable. Ensure the IDC connectors are cinched down tightly and making solid connections.

2. The IDE drive is grounded properly to frame ground. You may need to mount it on the frame or wire it so that it is not floating.

3. Are you using 74LS374 or 74HCT374 latches? If so consider switching to 74F374s for improved drive performance.

If you have an long IDE cable too close to the SMPSU it could easily be picking up switching noise and coupling that onto the signal. It doesn't take much to generate some false transitions and screw everything up.

Make sure your solder joints are all good. As a habit, I inspect all soldering after I am done and then remelt each joint to ensure no hidden cold joints and wick away any extra solder.

Thanks and good luck!

Andrew Lynch

per
May 15th, 2009, 07:23 AM
Hi Per! Yes, the IDE interface is somewhat susceptible to EMI. Make sure you:

1. have a good IDE cable. Ensure the IDC connectors are cinched down tightly and making solid connections.

2. The IDE drive is grounded properly to frame ground. You may need to mount it on the frame or wire it so that it is not floating.

3. Are you using 74LS374 or 74HCT374 latches? If so consider switching to 74F374s for improved drive performance.

If you have an long IDE cable too close to the SMPSU it could easily be picking up switching noise and coupling that onto the signal. It doesn't take much to generate some false transitions and screw everything up.

Make sure your solder joints are all good. As a habit, I inspect all soldering after I am done and then remelt each joint to ensure no hidden cold joints and wick away any extra solder.

Thanks and good luck!

Andrew Lynch

1. Yes, the connectors are properly set up and attached.
2. Eeeh... What ground It was laying on top of a sheet of plastic, didn't find any drivebays to connect it to. In addition, there isn't really any grounded wall-connectors around in this house.
3. Only F and LS parts.

About the solder joints, Hargle seems to be really echonomic in how much lead there is on each of them. My soldering skills/equipment are limmited, so I don't know if it is safe for me to do something with it.

mbbrutman
May 15th, 2009, 07:37 AM
The big ribbon cable is definitely a problem. That is why the higher-spec IDE drives used the newer cabling with the additional grounds. You might try a shorter cable, or a better quality cable if that problem happens again.

It looks like the card has the decoupling capacitors needed to remove AC ripple from the DC voltage lines - that is a good thing. Other things to check would be to make sure the signal ground planes are connected to avoid having them at different levels. Lastly, it might not be a bad idea to use some capacitors for voltage smoothing.

I'm not a EE - I know of these things in general terms. To me the card looks great, and I'm sure that Andrew has covered these issues.

NobodyIsHere
May 15th, 2009, 07:40 AM
Hi Per! The chips most affected by lack of drive current are the latches since they are the ones most directly interfacing the XT-IDE to the IDE drive through the cable. If those are 74F374s then you should be good.

Regarding the cable though, I was not referring to making sure the cable was firmly attached to the card but that the IDC connectors were firmly attached to the ribbon cable. There are many varieties of IDE cable and some are clearly better than others. Try substituting cables and see if that makes a difference. Some use heavier gauge wire, better IDC connectors, etc.

Please give these a try and let us know what happens! Thanks!

Andrew Lynch

barythrin
May 15th, 2009, 08:05 AM
Not sure but you could try one of the high density IDE cables that has more insulation between the pins. Alternatively if it's external interference you could maybe try a serial (round) IDE cable which seems to have more insulation from external EFI but to me always seemed stupid since really that's the reason the cables were flat in the first place was to keep EFI from the cable from interfering with itself.

Anyway, if you're bored and have the cables it may be worth checking out.

per
May 15th, 2009, 09:21 AM
Bad news for me.

I tried to uncoil the cable wetween the floppy drives a little, and when I re-connected the cable to the 3.5" drive, I got it servely wrong. As soon as I flipped the power switch, the drive made some very loud "GrjnGrjnGrjn" noises, and I turned the power off. I then conneced the cable correctly, and I got it to boot. Then I tried to read data from the floppy disk drive. Apparently, the disk is pretty useless, I can do a dir but as soon as I try to read any files, I get loads of errors. I then tried to sys the disk in the B: drive, and I realized that I forgot to extract "sys.com". I got my dos disk, did "expand sys.co_ c:\dos\sys.com", but nothing happened. I then tried to copy sys.co_ to the C: drive, and I verifyed with a dir that it was there. To make sure it was all right, I tried to do a "type sys.co_", but then suddenly I got a "File or Command not found" error. I did a dir again, and for some reason, my C: drive is empty!

I don't know what happened, but it seems like the "copy" command either totally wiped out the directory table or did something with the partion table. May it be a possible bug?

---

I've now gotten my drive up running again. Luckilly, the floppy drive itself seems to have suvived.

Ec1564
May 15th, 2009, 03:29 PM
I had a issue with signal noise on my Tandy 1000TL HDD once, Found a quick way to fix that problem, Use that silverfoil duct tape and "sandwich'the IDE cable and ground it to the case. That foil tape comes in rolls almost the right size of the IDE cables. Took care of my problem, till the HDD failed.

Looking forward to getting one or two of your cards to install in my 1000TL's once it's relased.

NobodyIsHere
May 15th, 2009, 04:17 PM
Hi Per! Good news that you fixed your system. It sounds like you needed to repartition/reformat the IDE hard drive? I've had problems like that occasionally when messing with the hardware and a reinstall does wonders.

If you find you are having EEPROM corruption problems you can replace the 2864 with a 2764 and that will prevent any inadvertent writes.

Thanks and have a nice day!

Andrew Lynch

per
May 16th, 2009, 12:38 AM
Hi Per! Good news that you fixed your system. It sounds like you needed to repartition/reformat the IDE hard drive? I've had problems like that occasionally when messing with the hardware and a reinstall does wonders.

If you find you are having EEPROM corruption problems you can replace the 2864 with a 2764 and that will prevent any inadvertent writes.

Thanks and have a nice day!

Andrew Lynch

A reformat was enough.

There was nothing wrong with the EEPROM, but just in cause, I store a copy of the flasher utility and the most recent binary file on a floppy disk.

per
May 17th, 2009, 10:28 AM
I'm currently working on a program that'll let you poke any values into "int 13h", and read the outputs. I thougth something like that might be usefull in debugging any bugs that mignt appear.

Availible inputs: AX, BX, CX, DX, 64Kb Buffer at segment BS (a window shows 512 bytes at a time, offset specified by, of course, BX)

Availible outputs: AX, BX, CX, DX, Carry Flag, 64Kb buffer at segment BS.

I'll post more when I get some code written down.

hargle
May 17th, 2009, 12:49 PM
Stuff I'm learning:

1) 80 pin cables work fine.

2) any data value written to any IO address from 301-307 shows up at the data port (300).
This is unusual behavior, but probably doesn't effect anything, since on writes, the data is written separately, and on reads, the data comes in after writing all the other registers. The upshot of this is that it gives us a really, really good method of auto-detecting the base address of our card in the BIOS. Just write a known value or two out to base+3 and base+4 and read the same values back at base+0. easy!

3) There's fishy stuff going on with the drive parameters. Some of it may be happening if the BIOS is unable to read the Device Identification data properly. that makes sense (garbage in, garbage out) but there's at least a little stuff going on with the translation itself, and I'm investigating that. For now, use a drive bigger than 8.4G. heck, use a drive bigger than 137G and you'll really avoid the issue. (big drives have all the internal parameters maxed out, so there's no calculations or rounding to be done)

4) Drives set to cable select don't work. Single drives show up on the secondary position, 2 drives won't ID at all during POST. Setting drives as master and slave properly fixes all that. This is not a BIOS issue.

5) I've got 2 old WD drives that return status error and error code of simply "abort" when trying to do PIO reads and writes. On my modern VIA machine, doing the exact same transfer doesn't cause the error to occur. the drives are WD 21200 and 21000, circa 1995-1998. (~2Gig in size) At first I thought it was a timing issue, since the error returned via INT 13 is timeout, but increasing the timeout made no difference. It's the abort flag that is causing int 13 to bail. It's not the above mentioned drive parameter bugs that are causing this. About the only thing I can figure is that the VIA BIOS is issuing a "set features" or similar command to the drive to setup the PIO transfer rates, which modern drives must be defaulting to. Need to investigate more, but I suspect this might be causing other people problems too. The symptoms are INT 13 read or write commands returning immediately with CY set and Ah=80h. Running FDISK results in an "error reading fixed disk" error.

6) using debug on my zenith8088 machine and tracing through INT13 into the BIOS code causes the eeprom to corrupt. I suspect debug is writing something in memory whereever it is running, and since our eeproms act like dram, something is getting written. Dunno, but that's a real pain. Looking forward to write protected eeproms!

7) and two more cards were built late last week. Both seem to be working well. I have 1 more card which needs to be built up, but I've run out of eeproms, since 3 of the SEEQ parts are now bad. Must find a better solution than SEEQ.


And here's 2 new utilities:
http://www.waste.org/~winkles/id_dump.zip

this program displays the device ID data out to the screen. Works only on this card. Probably only works on the C: drive.

This will eventually be rolled into the int13 test program I wrote earlier to help discover differences in parameters between us and them.


http://www.waste.org/~winkles/ATA.zip
this one requires vga and a mouse driver to be installed. Only works on our card. This is a program written for another application at work, but it allows us to issue any ATA based command out to any drive attached to the machine.
It can do a lot of stuff (scripts, log files, etc) and will be useful for a lot of things going forward, so keep this one in your back pocket.

Druid6900
May 17th, 2009, 09:02 PM
Ok, I have my XT (clone) test bed set up and I'm keeping a slot warm for one of the test cards.

It's a Datatrain DPC-1000 (which, if you need the specs on, are very close to the Packard Bell PB500 board (without the Turbo stuff) that you can find on TH99 sites)) with 640KB running a Seagate 225 on a WD1002A-WX1 controller.

I'm going to be running a number of Mono, Mono Graphic, CGA, EGA, network (Ethernet, Token Ring and ArcNet) and other 8-bit cards through the testbed over the next while using QA Plus XT to test them with.

Probably cover most of the possible configurations that the IDE might encounter out there.

per
May 18th, 2009, 05:29 AM
7) and two more cards were built late last week. Both seem to be working well. I have 1 more card which needs to be built up, but I've run out of eeproms, since 3 of the SEEQ parts are now bad. Must find a better solution than SEEQ.
I suggest this (http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?jameco_page=42&langId=-1&productId=762831&catalogId=10001&freeText=AT28HC64B&storeId=10001&search_type=all&ddkey=http:ParametricSearchResultsView) as it is the fastest option (no the write side).

It also got software protection, which is nice, and it costs about the same as the SEEQ ones.

hargle
May 19th, 2009, 06:05 AM
Went to the store yesterday and picked up 3 of the atmel eeprom parts. They are the same ones we used on the wire-wrap boards. Interestingly enough, the sticker was scraped off the bin they were in, so I asked the guy behind the counter how much they were. Next to the parts I selected were other speeds of the same part, and they were $8.49 and $11.49 respectively. The guy quoted me $2.49. hehe. If there were a whole tube of 100 I would have picked them up, but there's only 2 left.

Built up card #10 last night too. Works a treat and has one of the new atmel flash parts in it.

Didn't get much farther than that unfortunately.

I've just added a downloads section to our wiki:
http://wiki.vintage-computer.com/index.php/XTIDE_project

There are links to the latest flash binaries, some of the tests we've generated, and the flash utility. (per, wanna check to make sure that's the latest link?)

I think our wiki page may be getting a little long, and breaking some of these things out into separate pages might be in order.

per
May 19th, 2009, 06:16 AM
Went to the store yesterday and picked up 3 of the atmel eeprom parts. They are the same ones we used on the wire-wrap boards. Interestingly enough, the sticker was scraped off the bin they were in, so I asked the guy behind the counter how much they were. Next to the parts I selected were other speeds of the same part, and they were $8.49 and $11.49 respectively. The guy quoted me $2.49. hehe. If there were a whole tube of 100 I would have picked them up, but there's only 2 left.

Built up card #10 last night too. Works a treat and has one of the new atmel flash parts in it.

Didn't get much farther than that unfortunately.

I've just added a downloads section to our wiki:
http://wiki.vintage-computer.com/index.php/XTIDE_project

There are links to the latest flash binaries, some of the tests we've generated, and the flash utility. (per, wanna check to make sure that's the latest link?)

I think our wiki page may be getting a little long, and breaking some of these things out into separate pages might be in order.

I'll upload the latest version right away.

In addition, my Int 13h monitor is done. it can be used to take full controll over int 13h, and I've figured that's a usefull feature when debugging. It is a little more stable than the version I sent you.

I also sent you the latest version of the boot menu, but I think it got trapped in your spam-filter again... I'll upload it.

geneb
May 19th, 2009, 06:20 AM
Hargle, Unicorn Electronics has 28C64 EEPROMs for $3.79 each, less for quantities 25+.
http://198.170.117.30/IC/EEPROM.html

I've purchased parts from them in the past and they've always been courteous and quick to ship.

g.

hargle
May 22nd, 2009, 06:26 AM
Hargle, Unicorn Electronics has 28C64 EEPROMs for $3.79 each, less for quantities 25+.
http://198.170.117.30/IC/EEPROM.html


Wow, that is a good price. Over a buck cheaper in 100+ quantities than jameco. I'll have to inquire what brand they are. SEEQ parts are not worth it.
thanks!


----------------------

I've created a debug log on the wiki:

http://wiki.vintage-computer.com/index.php/XTIDE_project_debug_log

Please use it to keep track of what we're testing so we don't duplicate a lot of effort, and if you find something new that needs to be checked, please make a new entry and we can all comment on it.

I plan on putting a LOT of hours in over the 3 day weekend to get the BIOS up to the next stage of life.

lutiana
May 24th, 2009, 12:58 AM
Okay, so I got my card (lucky number 9) from hargle this last week. First thing I did was to update the BIOS to 0.05. The update procedure was flawless and easy.

After some initial testing I have some feedback, that may not be too relevant to the project as this is from my PIII-550 machine (on an ASUS P3V4X mobo).

I worked with 4 different typed of Mass Storage Devices w/ an 80 conductor cable and I did not use cable select.


Toshiba MK6014MAP 6gb 2.5" Drive
Was not detected at all. I assume this is the <8.7gb issue that hargle mentioned.


Western Digital Caviar 205BA 20Gb 3.5" Drive
This drive was detected just fine, I was able to fdisk it and format it. The 20gb FAT32 partition took a while to format but completed just fine. I transferred the system files to it and tried to boot from it. I get "General Error Reading disk Drive" after POST, but it boots from the drive.


IDE to CF Apater w/ 1gb Generic Compact Flash Card
After some toil I was able to get it to partition and format (but I had to use alternatives to the DOS 7 format and Fdisk). After the POST I get "General Error Reading disk Drive", but it does finish the boot. I also notice that the first "dir" command takes longer than normal to complete (ie to list the free space).


IBM Travelstar 40Gb 2.5" Drive
Detected fine, did not try to format or FDisk it. Merely wanted to know if the detection issue with the 6gb drive was a 2.5" drive issue. There was an existing partition on the drive, at it booted just fine.


Am I correct in assuming the General Error Reading disk Drive pertains to the floppy drive? If so I think it could be rephrased for better understanding.

I did notice that the detection phase takes quite a long time (about 60s) if there is no slave drive hooked up - this appears to be erratic.

It would be great to see a rudimentary BIOS Setup interface giving some user configurable options. Initially I think these would be great:

Option Name (Options)
Number of Devices (1/2)
Auto Detection (On/Off)
If 2 is set to off then manual entry of the drive parameters
Boot Menu Delay (0/1/2/3/4 seconds)
First Boot Device (Floppy/Hard Drive 0)


This could be expanded into some very useful tools (perhaps built in FDISK and format). But I realize this suggestion comes from someone who has no idea on the difficulty of adding these things to the BIOS.

In fact it could probably also be done physically with jumpers (except the manual entry of drive parameters), or even a command line utility that merely changes these flags.

What is the function of the jumper on the card again?

My next step is to try this card in my 5160, with the CF card, the 20gb HDD and both at the same time. I will then run the tests and benchmarks listed on the wiki.

per
May 24th, 2009, 01:45 AM
Am I correct in assuming the General Error Reading disk Drive pertains to the floppy drive? If so I think it could be rephrased for better understanding.


Yes. The reason is because the boot routine reports the error. This routine was originally designed to be called from the menu, and it will automaticly report errors. Maybe I should add the drive letter to the message?

per
May 24th, 2009, 01:53 AM
It would be great to see a rudimentary BIOS Setup interface giving some user configurable options. Initially I think these would be great:

Option Name (Options)
Number of Devices (1/2)
Auto Detection (On/Off)
If 2 is set to off then manual entry of the drive parameters
Boot Menu Delay (0/1/2/3/4 seconds)
First Boot Device (Floppy/Hard Drive 0)


This could be expanded into some very useful tools (perhaps built in FDISK and format). But I realize this suggestion comes from someone who has no idea on the difficulty of adding these things to the BIOS.

I've got a sligly modified version of the flasher that can be altered to do that (currently, it just asks for the IRQ number and I/O port base). However, in order to do make that work, the BIOS have to contain some fixed variables at fixed offsets. There is currently no such fixed variables, except the signature, and the only person that has the ability to add therse variables is Hargle.

hargle
May 24th, 2009, 08:31 AM
[LIST=1]
Toshiba MK6014MAP 6gb 2.5" Drive
Was not detected at all. I assume this is the <8.7gb issue that hargle mentioned.

unfortunately, no. All drives should at a minimum detect during POST and display the model number. The <8.4G issue is after getting the data from the drive, I have to set up some internal tables so that FDISK and the like can talk to the entire drive. that's where the issue comes in.
I don't have any toshiba drives to test with-this is an interesting error.
I've tested with Seagate, WD, Maxtor, Conner, and Sandisk CF, and all of them can at a minimum ID properly.

any chance it's not jumpered correctly, or perhaps set to cable select and not master?



IDE to CF Apater w/ 1gb Generic Compact Flash Card
After some toil I was able to get it to partition and format (but I had to use alternatives to the DOS 7 format and Fdisk).

why is that I wonder? the drive should be transparent to whatever O/S you're using...



I also notice that the first "dir" command takes longer than normal to complete (ie to list the free space).

I think you'll get this with any drive+controller. DOS 6 takes forever to calculate the free space, but then once it has it, it's speedy.



I did notice that the detection phase takes quite a long time (about 60s) if there is no slave drive hooked up - this appears to be erratic.

that's weird indeed. On my z8088 it takes no more than about 2 seconds.
I've moved over to my 486 though, and it seems to take longer there. It's like the faster the CPU the longer it takes, which is rather counter-intuitive!



What is the function of the jumper on the card again?

ROM enable. Leave it jumpered.



My next step is to try this card in my 5160, with the CF card, the 20gb HDD and both at the same time. I will then run the tests and benchmarks listed on the wiki.

I'll have a new (better!) BIOS released tomorrow, so hang out a little bit and let me see what else I can do today+tomorrow on it.

that's the unfortunate thing with new BIOS releases. Everything you just tested needs to be tested again to make sure we're making forward progress.

hargle
May 24th, 2009, 11:06 AM
New BIOS released. v0.06

I was going to wait and get more done over the weekend, but it seems there are enough people testing, and this stuff that I've fixed should have an impact on a lot of that testing.

Get it here:
http://wiki.vintage-computer.com/index.php/XTIDE_project

0.06 - 24 may 2009
* added "initialize parameters" command after IDing a drive during post.
Certain ATA-1 drives require this to be set before any media access.
* rework of INT13 parameter settings. Should help with <8.4G drive issues.
* bugfix with verify command not selecting the correct drive number. oops!

There will likely be another release tomorrow as I continue to investigate a couple straggling drive format issues. See the debug wiki for information as to the drives I've tested with. I ran through every drive I have in the house.

lutiana
May 24th, 2009, 02:48 PM
I don't have any toshiba drives to test with-this is an interesting error.
I've tested with Seagate, WD, Maxtor, Conner, and Sandisk CF, and all of them can at a minimum ID properly.

any chance it's not jumpered correctly, or perhaps set to cable select and not master?


It is jumpered correctly (as per its manual (http://sdd.toshiba.com/techdocs/MK6014MAPuserguide.pdf))

I went back and did some further experimentation on this. The BIOS detects it as the slave drive, position on the cable does not seem to effect this. The reason why I thought it was not detected at all was because with this machine the screen is cleared immediately after the detection phase. Jumpering it as slave has no effect on this behavior either.




why is that I wonder? the drive should be transparent to whatever O/S you're using...


I am not sure if this is an issue with the BIOS or an issue with the card itself. The DOS format basically generated tons of bad sectors when I attempted to use it. I will dig up some other cards and try them out to see if I get the same issue.



I think you'll get this with any drive+controller. DOS 6 takes forever to calculate the free space, but then once it has it, it's speedy.

This is a DOS7 (Win98 ) boot disk I am using. But I did notice this behavior with it.



that's weird indeed. On my z8088 it takes no more than about 2 seconds.
I've moved over to my 486 though, and it seems to take longer there. It's like the faster the CPU the longer it takes, which is rather counter-intuitive!


With the WD drive configured as the only drive, the detection delay is 0s, all the others it is 60 or so seconds.




I'll have a new (better!) BIOS released tomorrow, so hang out a little bit and let me see what else I can do today+tomorrow on it.


Can you please add a small (1 or 2s) delay after the drives are detected. This will help debug the card a bit better (especially in newer machines).

I will grab the latest BIOS and start all over again. This is actually fun :D

lutiana
May 24th, 2009, 11:49 PM
What tools do you guys use to partition and format the drives on the XT machine itself?

I am having the issue that a DOS 7 (win98 ) boot disk won't work in my XT, and the FDISK for DOS 6.22 won't see drives larger than 8gb (even though the BIOS detects it as the 20gb it is).

Also, hargle when I went to flash the BIOS to 0.06 it failed the parity check at the end. I did it again to make sure with the same results. The BIOS seems to work ok though.

per
May 25th, 2009, 12:26 AM
What tools do you guys use to partition and format the drives on the XT machine itself?
FDISK and FORMAT


I am having the issue that a DOS 7 (win98 ) boot disk won't work in my XT, and the FDISK for DOS 6.22 won't see drives larger than 8gb (even though the BIOS detects it as the 20gb it is).
Are you sure the boot disk is 720Kb? an XT with the early BIOS doesn't support more than 720Kb disks (NOT 1.44Mb disks).

DOS 6.22 can't see more than 8Gb because it doesn't support eINT 13h.


Also, hargle when I went to flash the BIOS to 0.06 it failed the parity check at the end. I did it again to make sure with the same results. The BIOS seems to work ok though.
Make sure to not use any parameters when flashing the ROM. Those SEEQ parts can't even handle med-write mode!

If you got one of the ATMEL chips, use the /A (AT28C64B) or /F (AT28C64X) switch.

However, make sure to store the flasher and a copy of the Oprom.bin on a bootable floppy (just in cause).

per
May 25th, 2009, 04:25 AM
I would like to notify that I've uploaded a new set of BIOS "utility" programs. It is simply the most recent flasher and a setup utility to change some boot settings.

However, you need version 0.07 of the BIOS flashed into the EEPROM before you can use therse programs. This version of the BIOS isn't released yet, but it will problably be released sometime durning the upcomeing week. Anyway make sure to use the old flasher to flash BIOS version 0.07 before replacing the flasher with the new one.


The new thing with the flasher is that it patches the current settings into the BIOS image in the input file before writing it to the EEPROM. Of course it also alters the byte at offset 1FFFh so that the checksum will return 00h.

The setup program will simply take a snapshot of the contnents of the EEPROM, and asks the user to select some options for certain settings. It will then patch the answers into the snapshot and write it back to the EEPROM. It is in fact based on the flasher.


Right now, I've also included the old version of the flasher, but with no source-code. The two other programs does include source-code. Just note that some of the comments haven't really been updated as the program has changed, so don't trust them too much.

lutiana
May 25th, 2009, 04:18 PM
FDISK and FORMAT

Are you sure the boot disk is 720Kb? an XT with the early BIOS doesn't support more than 720Kb disks (NOT 1.44Mb disks).


Actually, it is a 360k floppy with nothing on it but fdisk and format. I had to remove DRVSPACE.BIN to make it all fit. The XT freezes on boot with this disk.



DOS 6.22 can't see more than 8Gb because it doesn't support eINT 13h.


Yes, I am aware of that, I was merely trying to do this once the stripped down Win98 boot disk failed. I also tried copying DOS 7's FDisk onto my 6.22 boot disk. But the XT seems to freeze when I run it.



Make sure to not use any parameters when flashing the ROM. Those SEEQ parts can't even handle med-write mode!

If you got one of the ATMEL chips, use the /A (AT28C64B) or /F (AT28C64X) switch.

However, make sure to store the flasher and a copy of the Oprom.bin on a bootable floppy (just in cause).

Unfortunatly it is a SEEQ chip.

Here is how I flashed the card. I used a bare DOS 7 bootdisk, with nothing on it but FDISK, FORMAT and the flash stuff. I then ran the flash utility as such:


FLASH /I:OPROM.BIN


It worked perfectly for 0.04 -> 0.05, but the check at the end of the 0.06 gave some errors.

It looks like it is checking for certain bits in certain locations after the flash, but it finding the wrong values. Here is the output:



Verify failed, unexpected byte found at the following addresses:
D000:0005 01<>FF
D000:0004 03<>FF
D000:0003 E9<>FF
D000:0002 10<>FF
D000:0001 AA<>FF
D000:0000 55<>FF

Press any key to reboot your system.

per
May 25th, 2009, 10:12 PM
Actually, it is a 360k floppy with nothing on it but fdisk and format. I had to remove DRVSPACE.BIN to make it all fit. The XT freezes on boot with this disk.



Yes, I am aware of that, I was merely trying to do this once the stripped down Win98 boot disk failed. I also tried copying DOS 7's FDisk onto my 6.22 boot disk. But the XT seems to freeze when I run it.



Unfortunatly it is a SEEQ chip.

Here is how I flashed the card. I used a bare DOS 7 bootdisk, with nothing on it but FDISK, FORMAT and the flash stuff. I then ran the flash utility as such:


FLASH /I:OPROM.BIN


It worked perfectly for 0.04 -> 0.05, but the check at the end of the 0.06 gave some errors.

It looks like it is checking for certain bits in certain locations after the flash, but it finding the wrong values. Here is the output:



Verify failed, unexpected byte found at the following addresses:
D000:0005 01<>FF
D000:0004 03<>FF
D000:0003 E9<>FF
D000:0002 10<>FF
D000:0001 AA<>FF
D000:0000 55<>FF

Press any key to reboot your system.


Do you still mannage to boot?

Open Debug and type:
d D000:0000

If you get lot's of FFs, there might be a problem with the EEPROM.

lutiana
May 25th, 2009, 11:42 PM
Do you still mannage to boot?

Open Debug and type:
d D000:0000

If you get lot's of FFs, there might be a problem with the EEPROM.

It does boot in my PIII550, but not in the XT (although that seems to be more because the XT won't boot DOS 7)



Verify failed, unexpected byte found at the following addresses:
D000:0005 01<>FF
D000:0004 03<>FF
D000:0003 E9<>FF
D000:0002 10<>FF
D000:0001 AA<>FF
D000:0000 55<>FF

Press any key to reboot your system.


Debug looks fine when I look at those addresses. The 01, 03, E9, 10, AA, 55 is what is there, so it looks like the flash program is wrong.

per
May 26th, 2009, 12:02 AM
It does boot in my PIII550, but not in the XT (although that seems to be more because the XT won't boot DOS 7)



Verify failed, unexpected byte found at the following addresses:
D000:0005 01<>FF
D000:0004 03<>FF
D000:0003 E9<>FF
D000:0002 10<>FF
D000:0001 AA<>FF
D000:0000 55<>FF

Press any key to reboot your system.


Debug looks fine when I look at those addresses. The 01, 03, E9, 10, AA, 55 is what is there, so it looks like the flash program is wrong.
Strange... Shouldn't do that.

You are using the old version of the flasher?

lutiana
May 26th, 2009, 12:34 AM
Is there a new version released with every BIOS? I downloaded this one when I downloaded bios ver 0.05 late last week.

QuantumII
May 26th, 2009, 12:43 AM
AFAIK everything after and including Win95's DOS requires at least a 386 to run.

per
May 26th, 2009, 12:57 AM
Is there a new version released with every BIOS? I downloaded this one when I downloaded bios ver 0.05 late last week.

Yesterday, I released a new version designed for upgrading from versions after (including) 0.07. This version of the flasher can't be used unless version 0.07 (or later) is already flashed.

Version 0.07 will problably be up sometimes durning later this week.

Maybe therse SEEQ EEPROMS require some extra long delay between write and reads. Have you tried to flash it more than one time with BIOS ver 0.06?

hargle
May 26th, 2009, 06:52 AM
AFAIK everything after and including Win95's DOS requires at least a 386 to run.

I was just going to say the same thing...
Lutania, I don't think that DOS 7 boot disk of yours will work on the XT.
There's a thread here:http://www.vintage-computer.com/vcforum/showthread.php?t=15703
that is discussing the very matter of what the best DOS for the XT is.

I've got a 0.07 BIOS, but it's not quite available for prime time yet. I fixed a bug that was introduced in 0.06 that impacts drives less than 512mb. (at least I'm improving the buggyness, prior to 0.06, drives less than 8.4G were troublesome!)

0.07 will have support for changing the IO base address and using the other options that Per's flash utility can utilize. coming real soon now I promise.

lutiana
May 26th, 2009, 08:40 AM
Have you tried to flash it more than one time with BIOS ver 0.06?

Yep, flashed it at least 4 times. The first time I got the error I flashed it again just in case, then last night in order to get the error message for posting I flashed it again. My cat decided that after the first flash it was a great time to walk across the keyboard, so I missed the message and had to flash it a 4th time in order to get the message.

It looks like it works just fine.

With regards to DOS 7 on the XT, I am not too worried about it not working, plus this does not surprise me. So I will stick with DOS 5 or 6 to fdisk and format the test drives.

The one question I have in my mind is if DOS 6 only sees the drive as a 8gb drive (instead of 20) and I create a 2gb partition, would this partition be readable in other systems? I am thinking yes, but this was my hesitation on FDISKin the drive on the XT.

The thing that I have realized is I think that most people will likely prep their hard drives on newer (and faster) machines, and move the drive to the XT once it is setup. The FDISK and format procedure take a very long time on the XT, but they do seem to work just fine otherwise.

I eagerly wait for 0.07.

hargle
May 26th, 2009, 09:48 AM
The one question I have in my mind is if DOS 6 only sees the drive as a 8gb drive (instead of 20) and I create a 2gb partition, would this partition be readable in other systems? I am thinking yes, but this was my hesitation on FDISKin the drive on the XT.


DOS 6 will top out at 8.4G. 8033MB IIRC is what FDISK says. You can create a series of 2g partitions, and your XT will see all 4 of them (or 5 if there's a little leftover there).



The thing that I have realized is I think that most people will likely prep their hard drives on newer (and faster) machines, and move the drive to the XT once it is setup.

yep, that's exactly the way it's supposed to work. The drive, whether prepped on the XT or a Xeon, should be interoperable between the two, as long as you're using the same DOS version on both machines.

I for one have been using my modern VIA board to fdisk and format the drive, then I copy a bunch of stuff over to it, then move the drive to the XT and make sure everything is readable as one of my tests.

lutiana
May 26th, 2009, 09:55 AM
DOS 6 will top out at 8.4G. 8033MB IIRC is what FDISK says. You can create a series of 2g partitions, and your XT will see all 4 of them (or 5 if there's a little leftover there).


So the obvious question on this one is, if I use DOS7 and make, say, 10 2gb partitions, would DOS 6 see partitions 5 - 10 (ie the ones above 8gb)?



I for one have been using my modern VIA board to fdisk and format the drive, then I copy a bunch of stuff over to it, then move the drive to the XT and make sure everything is readable as one of my tests.

I will adjust my test procedure to closer model this. I am using an Intel based board for this. I am glad to see my findings and reasonings are the same as the creators of this card.

Other than the weird glitch with my Toshiba 6gb hard drive (no matter how it is jumpered it ALWAYS comes up as slave, more testing is needed on my side with this drive though) the card seems to work fine.

Thanks

-Jarrod

hargle
May 26th, 2009, 11:42 AM
So the obvious question on this one is, if I use DOS7 and make, say, 10 2gb partitions, would DOS 6 see partitions 5 - 10 (ie the ones above 8gb)?

now that's an interesting question. and certainly one I don't have an answer to at all. let us know ok? :)

DOS7 fdisk asks you if this large hard drive should be treated as large when start it. it may be at that point when it would switch between being able to see the entire drive or 8.4G of it just like DOS6. interesting though.

per
May 26th, 2009, 11:54 AM
now that's an interesting question. and certainly one I don't have an answer to at all. let us know ok? :)

DOS7 fdisk asks you if this large hard drive should be treated as large when start it. it may be at that point when it would switch between being able to see the entire drive or 8.4G of it just like DOS6. interesting though.

It saw mine partioned 40Gb drive as an appromaxly -357Mb drive.

lutiana
May 26th, 2009, 12:49 PM
DOS7 fdisk asks you if this large hard drive should be treated as large when start it.

Yes, by large it is basically asking you if you want to create a FAT32 partition, it is badly worded. Even if you select no, it sees the entire drive, it just won't let you create a partition greater than 2gb (the FAT16 limit).

I will have to try this out and report back.

hargle
May 26th, 2009, 08:49 PM
0.07 bios posted to the wiki.

i was hoping that this one would have all my drive parameter issues fixed, but I have still have a couple troublesome 1g drives that I can't boot to after formatting, and give me bad sectors, even though no verify commands are failing. it's weird.

i wrote a program today to write via CHS to the drive and read back via LBA.
the idea was that i'd write a bunch of data on another machine, move the drive over and read it back, just to verify the data landed where the other machine put it. Looks like it's working as expected, but I should prolly do an extensive test to make sure things don't break down at the higher parts of the drive.

hopefully i'll be back on this in a day or two, gotta take a break for a bit.

lutiana
May 26th, 2009, 09:35 PM
So the obvious question on this one is, if I use DOS7 and make, say, 10 2gb partitions, would DOS 6 see partitions 5 - 10 (ie the ones above 8gb)?


Well after some extensive trial and error followed by some research I have realized that the 8gb limit imposed by DOS 6.22 is a very hard limit, here are my 2 major findings:


You can have a maximum of 4 primary partitions (actually its 4 partitions of any kind) on any given hard drive, and with FAT16 maxing out at 2Gb ea. that totals 8gb

When you create an extended partition that takes you over the 8gb barrier DOS 6.22 see it as a non-dos partition, and the data is inaccessible.


So the bottom line is putting anything into you XT with this card bigger than 8gb will most likely result in a ton of unused space, unless you use a file system other than FAT16.

hargle
May 27th, 2009, 05:54 AM
thanks for the information.

Certainly, I think an 8gig (or 10 with a little waste) drive is a perfect amount for an XT. It's obviously more than you'll ever really need, even if you install every game that runs on an 8088 on it, which is exactly what I plan on doing. :)
4 partitions will force me to keep things mildly organized too.

I'm using old xbox 1 hard drives for my machines, because they are either 8 or 10 gig, depending on which brand you pull out of the box, and I have a lot of them. They're relatively new, stable, quiet, and run cool.

For what it's worth, I think giving freedos a shot would be interesting on an XT. I know there are a few users here who swear by it, and it has eINT13 support, so now we're talking 1TB+ drives. The BIOS actually tops out at 137G at the moment, but adding 48bit LBA support is possible if someone really needed it.

per
May 27th, 2009, 06:15 AM
thanks for the information.

Certainly, I think an 8gig (or 10 with a little waste) drive is a perfect amount for an XT. It's obviously more than you'll ever really need, even if you install every game that runs on an 8088 on it, which is exactly what I plan on doing. :)
4 partitions will force me to keep things mildly organized too.

I'm using old xbox 1 hard drives for my machines, because they are either 8 or 10 gig, depending on which brand you pull out of the box, and I have a lot of them. They're relatively new, stable, quiet, and run cool.

For what it's worth, I think giving freedos a shot would be interesting on an XT. I know there are a few users here who swear by it, and it has eINT13 support, so now we're talking 1TB+ drives. The BIOS actually tops out at 137G at the moment, but adding 48bit LBA support is possible if someone really needed it.
It's like; if you are used to dive in a smaller swimming pool, you don't have to swim over the ocean if you get the oppurtinity to dive there.

I'm estimating the current transfer rate is about 60Kb/sec. I tested 8088 corruption, and at 30fps, it seems to play 16 seconds, then stop 8 seconds to buffer. If the speed could pass 90Kb/sec, 8088 corruption would have run without buffering at 30fps.

lutiana
May 27th, 2009, 07:58 AM
I'm estimating the current transfer rate is about 60Kb/sec. I tested 8088 corruption, and at 30fps, it seems to play 16 seconds, then stop 8 seconds to buffer. If the speed could pass 90Kb/sec, 8088 corruption would have run without buffering at 30fps.

I have noticed that initially access to the drive on the card is very slow, but then it its fine. If I copy say 20 files to the drive, it takes 10 or so seconds to copy the first file, but the other copy immediately after. This is more obvious on a newer machine, but I doubt it will be an issue on the XT itself.

hargle
May 27th, 2009, 09:24 AM
I haven't done any real benchmarking-more concerned with functionality at the moment. there's several places where I can see some speed improvements.

One of them is that every single time you do any transfer to the device, I call the routine that selects the master/slave device. It really should remember what the last drive accessed was and skip that routine if it's still accessing the same device. (or skip it altogether if only 1 device exists) There's lots of little niggly things like that which should help transfer speeds. Getting another 1/3 performance might be a bit tough though. I think we're going to need DMA for that.

geneb
May 27th, 2009, 06:24 PM
Is performance comparable to a PC/XT using a MFM drive with an optimized interleave? If so, there really isn't much reason to make it better than that. :)

g.

per
May 27th, 2009, 10:45 PM
I will just make a small note on something.

Right now, the BIOS correctly detects if there is no drive attached (didn't do that before). However, if no drives are connected, the boot menu won't come up.

The reason is problably because the code taking over Int 19h is older than the boot menu. But since there is a boot menu now, I would suggest that Int 19h sould be taken over anyways if there is drives attached or not. The boot menu is flexible and will work with MFM/SCSI hard drives too, so I see no reasons why this should be a problem.

per
May 28th, 2009, 01:41 AM
Yep, flashed it at least 4 times. The first time I got the error I flashed it again just in case, then last night in order to get the error message for posting I flashed it again. My cat decided that after the first flash it was a great time to walk across the keyboard, so I missed the message and had to flash it a 4th time in order to get the message.

It looks like it works just fine.

With regards to DOS 7 on the XT, I am not too worried about it not working, plus this does not surprise me. So I will stick with DOS 5 or 6 to fdisk and format the test drives.

The one question I have in my mind is if DOS 6 only sees the drive as a 8gb drive (instead of 20) and I create a 2gb partition, would this partition be readable in other systems? I am thinking yes, but this was my hesitation on FDISKin the drive on the XT.

The thing that I have realized is I think that most people will likely prep their hard drives on newer (and faster) machines, and move the drive to the XT once it is setup. The FDISK and format procedure take a very long time on the XT, but they do seem to work just fine otherwise.

I eagerly wait for 0.07.

I was not able to reproduce the errors you got. It must either be a minor failure in your EEPROM, or a bad soldering joint. Since you can read it fine after a reset, it's problably not a bad joint.

As Hargle already said, those SEEQ parts are Cr*p.

hargle
May 28th, 2009, 07:01 AM
I will just make a small note on something.

Right now, the BIOS correctly detects if there is no drive attached (didn't do that before). However, if no drives are connected, the boot menu won't come up.

The reason is problably because the code taking over Int 19h is older than the boot menu. But since there is a boot menu now, I would suggest that Int 19h sould be taken over anyways if there is drives attached or not. The boot menu is flexible and will work with MFM/SCSI hard drives too, so I see no reasons why this should be a problem.

you're correct-if there are no devices attached, the BIOS doesn't install/hook any interrupts, and thus no INT 19 boot menu. I can certainly change that to hook always, especially since our boot menu is pretty cool and offers some nice features. We will need to carefully test this to make sure there are no conflicts, and it's quite possible that some other controllers will hook int 19 and not ever give control to us.

I can make the "always int 19" change in the next release.

hargle
May 28th, 2009, 07:12 AM
I was not able to reproduce the errors you got. It must either be a minor failure in your EEPROM, or a bad soldering joint. Since you can read it fine after a reset, it's problably not a bad joint.

As Hargle already said, those SEEQ parts are Cr*p.

I've seen flash verify errors too, but after a reset, it all works. I didn't really pay much attention to it, because, well, it worked and I don't need to be distracted chasing down other issues right now. I have enough to do! ;)

Obviously, the correct data was written into the part, since it worked after a reset. The flaw is likely then, that the part was still in its funky write mode when the verify phase began. Maybe just a big delay between the last write and the verify phase, so that the part is sure to fall back into its read mode?

We may not be seeing this happen often because the values in a lot of the bytes aren't changing between writes. A good test would be to make an oprom.bin file that has nothing but 00's or FF's in it and flash that in, then flash in the real rom code and see if it can be duplicated.

When I saw this error, it was on my XT, and very likely with the seeq part.

I've not had any problems flashing the atmel parts on my 486, using the /f parameter. It works really well.
I'm absolutely going to be sourcing atmel parts for the real production run, so this is one of those issues that isn't really an issue, so I'm not concerned with it personally.

per
May 28th, 2009, 07:14 AM
you're correct-if there are no devices attached, the BIOS doesn't install/hook any interrupts, and thus no INT 19 boot menu. I can certainly change that to hook always, especially since our boot menu is pretty cool and offers some nice features. We will need to carefully test this to make sure there are no conflicts, and it's quite possible that some other controllers will hook int 19 and not ever give control to us.

I can make the "always int 19" change in the next release.

There will not be any conficts, I can guarantee that. That's because the Int 19h doesn't do any low-level stuff. It's only using the BIOS, and the only problem migth be that another card got buggy Int 13h routines.

To make sure Int 19h is the one suppied by our card, the user can just place it as hight as possible in the memory map. Most disk controllers use C8000, and that's the lowest possible address for BIOS extensions.

per
May 28th, 2009, 07:20 AM
I've seen flash verify errors too, but after a reset, it all works. I didn't really pay much attention to it, because, well, it worked and I don't need to be distracted chasing down other issues right now. I have enough to do! ;)

Obviously, the correct data was written into the part, since it worked after a reset. The flaw is likely then, that the part was still in its funky write mode when the verify phase began. Maybe just a big delay between the last write and the verify phase, so that the part is sure to fall back into its read mode?

We may not be seeing this happen often because the values in a lot of the bytes aren't changing between writes. A good test would be to make an oprom.bin file that has nothing but 00's or FF's in it and flash that in, then flash in the real rom code and see if it can be duplicated.

When I saw this error, it was on my XT, and very likely with the seeq part.

I've not had any problems flashing the atmel parts on my 486, using the /f parameter. It works really well.
I'm absolutely going to be sourcing atmel parts for the real production run, so this is one of those issues that isn't really an issue, so I'm not concerned with it personally.

There is already a big delay. More than 10mS!

What I think therse SEEQ parts need to get all-right reads are a power reset after a write. I absolutely recomend Atmel (they're a lot more stable).

---

On a side-note, the flasher automaticly calculates the checksum byte now, so you really don't need to include it in the ROM file in later versions.

hargle
May 28th, 2009, 07:58 AM
There will not be any conficts, I can guarantee that. That's because the Int 19h doesn't do any low-level stuff. It's only using the BIOS, and the only problem migth be that another card got buggy Int 13h routines.

i wouldn't be so sure just yet. andrew has issues booting with his floppy controller card installed with our card already, changing the address to make us last didn't help.

i can easily see some device requiring some additional work to be performed at INT 19 to do a proper boot to that device. Probably not too many oddball cards on the XT, but stuff like PXE booting most certainly requires some INT 19 work to be done to boot.

I have an MFM card and my future domain SCSI controller that I will be testing boot features and multiple card compatibility with, so I can give this a good testing. I should probably get my format issue worked out first though! :)

worst case, I will be saving the prior vector for INT 19 before I hook it, so we could also add a menu option to call the old INT 19 as a fallback choice.

per
May 28th, 2009, 08:26 AM
i wouldn't be so sure just yet. andrew has issues booting with his floppy controller card installed with our card already, changing the address to make us last didn't help.

i can easily see some device requiring some additional work to be performed at INT 19 to do a proper boot to that device. Probably not too many oddball cards on the XT, but stuff like PXE booting most certainly requires some INT 19 work to be done to boot.

I have an MFM card and my future domain SCSI controller that I will be testing boot features and multiple card compatibility with, so I can give this a good testing. I should probably get my format issue worked out first though! :)

worst case, I will be saving the prior vector for INT 19 before I hook it, so we could also add a menu option to call the old INT 19 as a fallback choice.

The only difference in the boot procedure of IBM's BIOS and this BIOS is that the ones in the IBM bios resets the parameters. I don't know if that is needed...

I really don't think the problems Andrew had with booting was because of Int 19h. I think it is rather a memory conflict or something. There is one way to find out; make Andrew try to use our Int 19h to boot from a floppy.

hargle
May 28th, 2009, 11:03 AM
The only difference in the boot procedure of IBM's BIOS and this BIOS is that the ones in the IBM bios resets the parameters. I don't know if that is needed...


Sure, that's all good. what I'm saying is that some oddball card may have a bunch of code in INT 19 that it needs run before it's able to boot.
(say perhaps a SCSI controller needs to initialize something before it can read any sector off the hard drive for example)

If our card comes along and replaces the INT 19 vector with our menu, then even if you select boot to C: (the scsi drive) without that scsi INT 19 code that the oddball card was expected to execute, the system wouldn't be bootable to that device.

It's just an example. I'm not saying that there are any cards like that (especially on the XT) that put their own boot code into INT 19, but our card would be removing that code altogether if we steal INT 19 away from another device which has already hooked it. That's the part we need to be careful about. That's why I'm thinking we can always add a "boot int 19" option to the menu to allow us to call their code, which then lets the system boot to that oddball drive.

This is exactly why modern BIOSes have a boot menu. You pick in setup which device order you want to boot to, and the mainboard bios calls that device's boot code. Modern machines don't actually hook INT 19 anymore.
It's a pretty good thing that there are significantly less bootable items available on an XT class machine.

lutiana
May 28th, 2009, 11:10 AM
It's a pretty good thing that there are significantly less bootable items available on an XT class machine.

You mean to say I cannot boot from my high end adaptec raid 5 controller in my XT, or my USB thumb drive.... *gasp* I want my money back....

per
May 28th, 2009, 11:10 AM
Sure, that's all good. what I'm saying is that some oddball card may have a bunch of code in INT 19 that it needs run before it's able to boot.
(say perhaps a SCSI controller needs to initialize something before it can read any sector off the hard drive for example)

If our card comes along and replaces the INT 19 vector with our menu, then even if you select boot to C: (the scsi drive) without that scsi INT 19 code that the oddball card was expected to execute, the system wouldn't be bootable to that device.

It's just an example. I'm not saying that there are any cards like that (especially on the XT) that put their own boot code into INT 19, but our card would be removing that code altogether if we steal INT 19 away from another device which has already hooked it. That's the part we need to be careful about. That's why I'm thinking we can always add a "boot int 19" option to the menu to allow us to call their code, which then lets the system boot to that oddball drive.

This is exactly why modern BIOSes have a boot menu. You pick in setup which device order you want to boot to, and the mainboard bios calls that device's boot code. Modern machines don't actually hook INT 19 anymore.
It's a pretty good thing that there are significantly less bootable items available on an XT class machine.

That's a good idea, but I can't add that function to the BIOS since I don't got that part of the code. If you add that variable, make sure to tell me how it works so I can add it to the setup program.

lutiana
May 28th, 2009, 11:02 PM
I thought I would post this just before I went to bed. I managed to boot into Windows 98 SE (safe mode) with the hard drive running on Hargle and Andrew's card in my test machine (PIII-550 w/ 512Mb or RAM). It took a VERY long time (about 2 hours) but it came up.

I had to go into safe mode because this install was from another machine.

Very impressive guys, you'r on the way to a nice functional product.

hargle
May 29th, 2009, 05:44 AM
I thought I would post this just before I went to bed. I managed to boot into Windows 98 SE (safe mode) with the hard drive running on Hargle and Andrew's card in my test machine (PIII-550 w/ 512Mb or RAM). It took a VERY long time (about 2 hours) but it came up.

wtf?!? heheheh.
that is absolutely hilarious.

however, that is an interesting situation. If you installed this O/S off another machine, meaning another IDE controller, that means that our controller is properly reading sectors off the drive where another controller put them down, meaning that our LBA translation layer is working as expected. That's really good news, although I was slightly hoping for a bug there to explain why I can't format a couple drives that I have without the entire drive being labeled as bad sectors.

Either way, that's an accomplishment. And certainly an experiment that I never would have considered attempting. You've made my day.

lutiana
May 29th, 2009, 07:51 AM
If you installed this O/S off another machine, meaning another IDE controller, that means that our controller is properly reading sectors off the drive where another controller put them down, meaning that our LBA translation layer is working as expected.

It was actually a 40gb laptop drive from an old Sony laptop. Partitioned into one 40gb partition and had Windows 98 installed on it. So yeah the translation seems to be working just fine.

hargle
May 30th, 2009, 02:26 PM
come get it!
http://wiki.vintage-computer.com/index.php/XTIDE_project

v0.08 BIOS

fixed the format issue finally. wow, that took up almost a week of my time. the deal is that on older drives (1995ish) on newer machines (486ish), doing multi-sector reads/writes could cause the data to not be available fast enough from the drive for the host. So data would get lost/corrupt after reading a couple sectors in a row. The fix was to insert a "check for data ready" between each read of a sector.

It was really tough to find, since single sector reads always worked fine, so I couldn't see any issues with the data when using single sector tools like norton disk edit, or even my own CHS->LBA test which i wrote just to find this bug.

Oddly enough, this likely would have never been an issue, had I not been playing around on the 486 lately.

I don't have a single drive in my collection (or CF card) that I am unable to format and boot to.


Fixed a boot menu bug too. It was losing track of where to find the next boot device to try when booting to the A: drive failed.


Do not use anything less than 0.08 BIOS please.

per
May 31st, 2009, 03:15 AM
come get it!
http://wiki.vintage-computer.com/index.php/XTIDE_project

v0.08 BIOS

fixed the format issue finally. wow, that took up almost a week of my time. the deal is that on older drives (1995ish) on newer machines (486ish), doing multi-sector reads/writes could cause the data to not be available fast enough from the drive for the host. So data would get lost/corrupt after reading a couple sectors in a row. The fix was to insert a "check for data ready" between each read of a sector.

It was really tough to find, since single sector reads always worked fine, so I couldn't see any issues with the data when using single sector tools like norton disk edit, or even my own CHS->LBA test which i wrote just to find this bug.

Oddly enough, this likely would have never been an issue, had I not been playing around on the 486 lately.

I don't have a single drive in my collection (or CF card) that I am unable to format and boot to.


Fixed a boot menu bug too. It was losing track of where to find the next boot device to try when booting to the A: drive failed.


Do not use anything less than 0.08 BIOS please.

That's fantastic. Does that mean that my Segate drive will work now, and that the DOS 5.0 installation will be able to complete?

Maybe I should use segment-overrides (CS:[variable]) on all variable-reads in the future... I don't like to shuffle a register between something and some other thing as it may become pretty confusing after a while.

By the way, you forgot to add the code from the new menu on my site; the error message in the boot menu are still missing that 'space'.

NobodyIsHere
May 31st, 2009, 09:09 AM
come get it!
http://wiki.vintage-computer.com/index.php/XTIDE_project

v0.08 BIOS

[snip]

Do not use anything less than 0.08 BIOS please.

Hi Hargle! I burned a 2764 EPROM with the new OPROM-008 BIOS. Unfortunately I seem to be missing the "ANY" key... ;-)

I can see the BIOS ROM is executing since it detects my hard drive and prints the boot message. Then it says "press any key to for boot menu..." and hangs the XT clone up hard.

I reverted back to the OPROM-005 version and it works. Apparently something introduced in the 006, 007, or 008 version doesn't like my XT clone. Am I doing something wrong?

I'll get the 006 and 007 versions and burn EPROMs of those and let you know if they work. While I am testing is there any of the test utilities you'd like run on my system?

Thanks and have a nice day!

Andrew Lynch

NobodyIsHere
May 31st, 2009, 10:37 AM
Hi! I downloaded versions 006 and 007 and burned EPROMs for them. Apparently the menu hang glitch was introduced with 006 and the "press any key for boot menu..." prompt. Bummer!

So I am sticking with 005 for now. It seems to me we ran into this problem before when I was testing the first wire wrap prototype on my PIII test station? There must be something about the XT keyboard that is causing fits.

Thanks and have a nice day!

Andrew Lynch

per
May 31st, 2009, 11:25 AM
Hi! I downloaded versions 006 and 007 and burned EPROMs for them. Apparently the menu hang glitch was introduced with 006 and the "press any key for boot menu..." prompt. Bummer!

So I am sticking with 005 for now. It seems to me we ran into this problem before when I was testing the first wire wrap prototype on my PIII test station? There must be something about the XT keyboard that is causing fits.

Thanks and have a nice day!

Andrew Lynch

It should pause for about 5 seconds before booting by defaut... If any key is pressed durning this delay, the menu should appear.

Of course I can make the menu disabled by default (so you need to "activate" it with the setup program).

NobodyIsHere
June 1st, 2009, 08:06 AM
Hi! No luck with any BIOS version later than OPROM-005. When the BIOS boots and prints "Press any key for boot menu..." the XT clone locks up hard and it does not respond after waiting. Even the NUMLOCK LED no longer responds and neither does CTRL-ALT-DEL. Only a power cycle restores the machine since I don't have a reset button on this poor old thing. I haven't tried it on the PIII yet but since the XT clone is closer to target hardware that's where I do most of my testing.

I've been off doing other things lately while the XT-IDE BIOS development settles down. Are there any changes identified for the hardware? I haven't started the respin yet since we never settled on a final configuration.

Thanks and have a nice day!

Andrew Lynch

per
June 1st, 2009, 08:16 AM
Hi! No luck with any BIOS version later than OPROM-005. When the BIOS boots and prints "Press any key for boot menu..." the XT clone locks up hard and it does not respond after waiting. Even the NUMLOCK LED no longer responds and neither does CTRL-ALT-DEL. Only a power cycle restores the machine since I don't have a reset button on this poor old thing. I haven't tried it on the PIII yet but since the XT clone is closer to target hardware that's where I do most of my testing.

I've been off doing other things lately while the XT-IDE BIOS development settles down. Are there any changes identified for the hardware? I haven't started the respin yet since we never settled on a final configuration.

Thanks and have a nice day!

Andrew Lynch


You may try to press a key when the message apprars. If the boot menu doesn't appear, try the following:

Burn an EPROM of version 0.08 where you change the byte at offset 001Ch to 00h. Make sure to change the checksum byte at 0FFF or 1FFF accordingly (doesn't matter which of them, any unused byte within the 8k range will work). If it still doesn't boot... Then there must be some problems with either Int 13h function 00h or function 02h.

mbbrutman
June 2nd, 2009, 07:27 AM
Jeff and I have been having a running conversation on these cards. One of the key observations is that testing is a very important part of what we are doing:


We need to understand what has been tested and what has not
We need to ensure the testing is somewhat well defined and methodical
We need to chase down any weirdness, from drives not reporting in, systems not getting through POST, data corruption, performance variations
We need to chase down perceived problems with component quality



I would like to start gathering this data to get a broader picture of what works and what doesn't so that we know where to apply focus. But this thread is probably not a good place to do that - it's too unwieldy.

I'd like to start gathering individual experiences with the card to get an idea of what you have tried it with, what tests you have run against it, etc. I'll try to get the data points organized and most results the Wiki periodically so that people can see what we are doing. Please drop me a private message here so that we can exchange email addresses. Hopefully we can get a little bit more organized - the card has great promise, but we're not coordinated enough.


Regards,
Mike

hargle
June 2nd, 2009, 12:37 PM
All of my debugging is being logged here:
http://wiki.vintage-computer.com/index.php/XTIDE_project_debug_log

I've exhausted my collection of hard drives, and have verified that all of them available to me match drive parameters the same as a modern motherboard with phoenix BIOS, and that all of them that I was willing to format (some had data that I didn't want to lose) were fdisk+format+bootable. From my card and drive collection's point of view, there are no outstanding issues for drive compatibility/usability.

It seems that almost everyone else has a straggling drive that just doesn't quite work right though. These are the ones that we need to bring to the forefront and decide where the faults lie.

Andrew's system is just weird, so let's ignore him. :p

Andrew, do you have a POST card available? I can build you a 008 version with a bunch of post codes in various spots and you can tell me where it's locking up at.

per
June 2nd, 2009, 12:42 PM
It seems that almost everyone else has a straggling drive that just doesn't quite work right though.

Except me :( . My "faulty" drive started to work with the 0.08 version of the BIOS.

bobwatts
June 3rd, 2009, 04:11 AM
Hi GAng !

Looks like things are progressing. Anyone know why my notifications stopped? I thought that everyone was asleep for the past couple of weeks.

By the way, just noticed that the Legendary Mr. Lynch is just down the road from me. ( Dayton Ohio. )

bobwatts
EartH

NobodyIsHere
June 3rd, 2009, 04:58 AM
All of my debugging is being logged here:
http://wiki.vintage-computer.com/index.php/XTIDE_project_debug_log

I've exhausted my collection of hard drives, and have verified that all of them available to me match drive parameters the same as a modern motherboard with phoenix BIOS, and that all of them that I was willing to format (some had data that I didn't want to lose) were fdisk+format+bootable. From my card and drive collection's point of view, there are no outstanding issues for drive compatibility/usability.

It seems that almost everyone else has a straggling drive that just doesn't quite work right though. These are the ones that we need to bring to the forefront and decide where the faults lie.

Andrew's system is just weird, so let's ignore him. :p

Andrew, do you have a POST card available? I can build you a 008 version with a bunch of post codes in various spots and you can tell me where it's locking up at.


Hi! Yes, I've a POST card in the basement someplace. There are different ones for different machines. I believe the XT's used port 60 and the AT's and later used port 80. The ISA post card which is most readily accessible is one of the port 80 units for ATs if that'll help. It works fine on the PIII machine but I've not tested it on the XT clone. I have an XT POST card but its buried someplace. It doesn't matter though since you can write diagnostic codes to any IO port you choose.

My system XT IDE card won't boot if either the FDC with BIOS has its ROM chip installed or the Seagate MFM with BIOS is installed. I suspect there is something flakey going on with the boot code determining boot order or something. Int19 hook maybe? Who knows?

I am working on a couple of N8VEM projects right now so my time on this is pretty limited. I am about half way through the construction of the N8VEM video display unit board and some S-100 related stuff. So if there is something specific I can help with please let me know.

Thanks and have a nice day!

Andrew Lynch

hargle
June 3rd, 2009, 05:52 AM
Hi! Yes, I've a POST card in the basement someplace. There are different ones for different machines. I believe the XT's used port 60 and the AT's and later used port 80. The ISA post card which is most readily accessible is one of the port 80 units for ATs if that'll help.

that's perfect. I'll draw up a BIOS for you tonight with a ton of port 80 codes, and you can let me know where it's hanging.



My system XT IDE card won't boot if either the FDC with BIOS has its ROM chip installed or the Seagate MFM with BIOS is installed. I suspect there is something flakey going on with the boot code determining boot order or something. Int19 hook maybe? Who knows?

yep, that's 100% untested at the moment. I need to dig out my MFM card and see if I can duplicate any of these issues so they can be clobbered.

Does that mean it actually does boot if you remove those devices?

Mike Chambers
June 3rd, 2009, 11:52 AM
my #10 limited edition prototype is on the way, and then i'll help testing when i get it! :mrgreen::mrgreen::mrgreen:

thanks, hargle. i wonder what sort of speed i'd see using it as a web server with a new-ish 40 GB drive.

NobodyIsHere
June 3rd, 2009, 02:30 PM
[snip]

Does that mean it actually does boot if you remove those devices?

Hi! I seem to recall getting it to boot if I left the FDC board in but removed its BIOS ROM so the native motherboard BIOS could manipulate the bare FDC chip. The problem with that approach is then I don't have a boot floppy. I suppose I could switch to a 720K 3.5" rather than 1.4M but that limits connectivity with my main computers. It's kind of a catch 22.

Thanks and have a nice day!

Andrew Lynch

hargle
June 4th, 2009, 05:54 AM
Per may have just figured out the lockup problem that you're seeing.

On the PC/XT, port 80 is a DMA page register. There are at least 2 port 80 writes in the ROM that I'd left in for debugging purposes. While it should have no effect on our usage, since we're not using DMA to transfer data, it very well may have some impact on say, a floppy controller.

Oddly enough, i was going to send you a version of the ROM with all kinds of port 80 writes to see if we could figure out where the fault was, and that in itself may be exactly what is causing it to fail!

This weekend I'll send you a version of our latest work that has no stray port 80 writes in it, and maybe that will help. If it doesn't, then maybe we will do the port 80 write version anyway.

Mike Chambers
June 4th, 2009, 12:14 PM
http://irc.rubbermallet.org/personal/ideprototype.jpg

:p

hargle
June 4th, 2009, 01:15 PM
that doesn't mean it's locked up there does it? ;)

Mike Chambers
June 4th, 2009, 01:23 PM
hehe.. no, it's just fine. that got here very fast, too. 2 days! anyway, i've tried a few drives. they all work, but the smallest was 10 GB. from what i read, smaller drives don't seem to work right? what types of sizes have problems? i'll give em a whirl on my card.

let me know some of the common issues you guys are having, and i'll see what happens when i try to recreate.

per
June 4th, 2009, 01:46 PM
hehe.. no, it's just fine. that got here very fast, too. 2 days! anyway, i've tried a few drives. they all work, but the smallest was 10 GB. from what i read, smaller drives don't seem to work right? what types of sizes have problems? i'll give em a whirl on my card.

let me know some of the common issues you guys are having, and i'll see what happens when i try to recreate.

As of I recall, all those issues should have been fixed by now.

Mike Chambers
June 4th, 2009, 01:50 PM
As of I recall, all those issues should have been fixed by now.

well, i have a 3.2 GB WD drive here. i'll try installing DR-DOS on it with the card and report back.

Mike Chambers
June 4th, 2009, 02:37 PM
ok yeah it works, i fdisk'd, formatted, and installed... and it boots right up.

Mike Chambers
June 4th, 2009, 02:59 PM
is there any version of DOS that'll work on an 8088 that makes/sees partitions larger than 2 GB? DR-DOS uses FAT32 but it's still limited to making 2 GB partitions. i know DOS 7 will do it, but is it able to load on an 8088?



EDIT: there actually seem to be some issues. a couple times after executing a program the system has either started blinking strangely on the screen, or started spewing garbage data to the monitor. the only solution in either case is to reboot. also, i just tried installing arachne from ARCHN170.EXE (a known working copy a FTP'd over to the XT) and after a few minutes of extracting files okay, it came up with a CRC errors in archive dialog box and locked. i suppose i'll try on a larger drive and see if the problems continue.