• Please review our updated Terms and Rules here

8-Bit IDE Controller

hargle said:
Hi all.
b) test more drives and update that spreadsheet + wiki
Click to expand...

I got this one up on google apps, but no one has sent me their details to invite them to add their 2 cents into it.

hargle said:
c) decide if we want to try another small prototype run, or are we confident enough to do the big order. the only hardware change I'd make would be to pull out the CSEL 3-pin jumper and just pull it low. I think andrew might want to test that on his side to see if it breaks anything. I had good luck with it, and it fixed my issues with CS settings on drives.
Click to expand...

I personally think we are ready to seriously consider a second run of the PCB design. Let me know when you go forward with this one and I will pre-order one :D

kb2syd said:
I installed it in one of my MS-DOS test machines last night. This is a PIII with built in USB, Ethernet, SCSI, IDE, Parallel, 2 Serial, 2 PS/2 and Video. I also have and PCMIG backplane with a few other boards plugged in.
Click to expand...

I had a similar issue in my PIII, it went away when I disabled the onboard IDE controller. That was with BIOS .05 I believe, havent re-enabled it since.

I am going to purchase my replacement parts this weekend and see about resurrecting my card and then I will test it with the onboard IDE enabled.
 
lutiana said:
I got this one up on google apps, but no one has sent me their details to invite them to add their 2 cents into it.



I personally think we are ready to seriously consider a second run of the PCB design. Let me know when you go forward with this one and I will pre-order one :D



I had a similar issue in my PIII, it went away when I disabled the onboard IDE controller. That was with BIOS .05 I believe, havent re-enabled it since.

I am going to purchase my replacement parts this weekend and see about resurrecting my card and then I will test it with the onboard IDE enabled.
Click to expand...

I would like to get in on the next pcb test run/build up. I don't have the deep programming background that most of the folks have who've been in on the ground floor of the this project, but - my maintenance experience on mainframes and middies dates back to the Varian 620i 4-bit system days with revolving drum memory, ITT input/output, and high speed mylar tape reader. Also, Digital PDP-8, HP-1, and the 32 bit Data General in the mid 80's. I've been a tech most of my life (41+ years military and government) and can troubleshoot and solder with the best of them. Let me chip-in (pun intended)for the the cost of the parts and see what I can do. My sweetheart machine is a Tandy 1000SX with a VGA (had a Boca EGA but the monitor was very heavy and getting in the way), 10 GB Quantum SCSI, ST225 (23 years and still posting), and a "Harry Swartz" real-time clock card. Also it's "over clocked" if you will, with a NEC V-10 running at 10 MHz and sports a 8087 co-math processor.

Thanx - Agent Orange
 
Timer weirdness

Timer weirdness

My attempts at benchmarking are all over the map. I think I know why now.

You are turning off interrupts before reading a sector, and turning them back on after the 512 bytes are read. On a disk intensive benchmark where the time is spent reading and writing (as opposed to seeking) that causes a lot of missed timer interrupts.

What does this mean? The only way to benchmark this thing is going to be with a stopwatch. The system loses time while it is doing disk I/O. This is one situation where DMA would be an improvement.

(The AT uses a PIO loop to read/write sectors too. I don't know why it isn't affected this badly. Then again, maybe it is ..)


Mike
 
hi gang,

back from my vacation, and I see the wheels fell off while I was gone. ;)

Here's a group catchup post.
bobwatts said:
I have the results of the "new" BIOS chip that was installed into my Acculogic sIDE card with pictures also.(not good )
Click to expand...
Bob, that BIOS installed in your card is really, really old, so any of the results you're seeing are going to be discarded by me because so many changes have happened since I shipped your card back to you.
You should try to locate an eeprom burner and update your card's BIOS. You will need to use Per's setup utility to change the base IO address from the default of 300h to 360h before you flash the new eeprom in.
Alternatively, you could mail the eeprom back to me and I'll flash it for you, but that could get tiresome if we need to do this everytime there's an update.

kb2syd said:
I did not see a boot menu on this machine either. I started debug and dumped D000:0 and saw the code from the bios 0.9 that I downloaded. I then tried to re-flash the ROM. NOTHING. I got 30 minutes of D000 scrolling down the screen and nothing else. I tried server different options on the flash routine. Next step is to try this in a simpler machine. I have plenty to choose from.
Click to expand...

I'm sorry to hear you're having such a troublesome time with this card.
Obviously it worked at one time, but sounds like something has corrupted the ROM on it. Even if 1 bit is wrong in the ROM, the computer will skip calling the option rom altogether, which is what I suspect is happening.

The scrolling D000 from flash doesn't make any sense either, so there's something weird with the flash program too. I've been using an older version of flash, and haven't been having any issues with it, so it's possible (sorry per) that something was introduced in the newer builds that caused this to happen.

Since I just got back from vacation, things are a little hectic for me at the moment, but sometime this week I will be able to try out the newest flash program, and if I can duplicate your results, can try to fix that, and I can also make available the flash version that I've been using. Worst case is that the eeprom itself has gone out to lunch, but it sounds to me like the flash program isn't even able to get itself into a position to try and re-flash it, so we don't know yet. You got double wammied by unrelated issues.
AFAIK, you're also the first to put this into a Tandy, so there may be all sorts of things going on that we're unprepared for.


lutiana said:
I personally think we are ready to seriously consider a second run of the PCB design. Let me know when you go forward with this one and I will pre-order one :D
Click to expand...

I am thinking the same thing. Better to spend 300 bucks and be safe than to spend 2k and have a bunch of hand re-working to do.
Especially if folks continue to buy them at prototype costs, then I don't get sunk too much, plus there is a possibility that if there are no changes between this next prototype and the real production run, they may waive the setup fees, since this is just another order of an existing product.



lutiana said:
I had a similar issue in my PIII, it went away when I disabled the onboard IDE controller. That was with BIOS .05 I believe, havent re-enabled it since.

I am going to purchase my replacement parts this weekend and see about resurrecting my card and then I will test it with the onboard IDE enabled.
Click to expand...
Good. I was just going to suggest that with 009 BIOS, you should be able to co-exist with the onboard IDE controller just fine. I should really test that with my 486 as well. In fact, on my 486, I would be using an onboard controller, plus the XTIDE, and the drive installed in the 486 is using an INT13 overlay. That should be really interesting to see if when booting to the XTIDE drive, if I can properly access the overlay driven 486 drive. wow, that could get scary.


mbbrutman said:
My attempts at benchmarking are all over the map. I think I know why now.

You are turning off interrupts before reading a sector, and turning them back on after the 512 bytes are read. On a disk intensive benchmark where the time is spent reading and writing (as opposed to seeking) that causes a lot of missed timer interrupts.
Click to expand...

Ah! that explains why coretest runs for several minutes, claiming only a few seconds worth of benchmarking results. It did that on the acculogic card too, so I assumed it isn't us.

I do wonder if turning off interrupts while reading that data is really required.
Obviously for safety it makes sense, but really, who else would be poking around at our IO addresses in the middle of a disk read? Certainly a quick experiment to keep interrupts enabled there and see what happens.

mbbrutman said:
I've been doing a bit of testing - all of it was good. I've posted the results here:
http://wiki.vintage-computer.com/index.php?title=XTIDE_TestResults
Click to expand...

Great results! Odd how 1 drive, that is pretty much in between your other IBM drives in size and likely manufacturing date, fails to read/write.

I'd love to get my paws on that drive and dig into it.
If you could, in debug, after issuing a read command which fails, then do IN port reads of 301 and 307 and lemme know the numbers there.
307 is probably just 51h, but 301 is error register, which may have some more details. Heck, dump all 300-308 registers if you'd please.

If you could, also send me a dump of the IDentify device data. I believe I've posted a utility to do that on the wiki, and if not, I've got one that will dump it out to a text file that I should make available. I'm wondering if the drive might be locked/frozen via some security settings? I can tell from the ID data if it is in a locked state.
 
I think you need to keep the interrupts disabled. All of the code that I have read keeps them off. The keyboard or the timer interrupt firing could be pretty inconvenient.

On the AT the read loop uses the INSW instruction with a REP prefix. That instruction is 5 cycles on an 80286, so reading a sector takes a grand total of 1280 cycles. (0.213ms) At 6Mhz that is far shorter than the 55ms timer tick, so that is why the AT (and better) machines can use PIO and not worry too much about missing the timer tick. (I'll bet they still miss on occasionall)

Under perfect conditions your code is taking 70 clock cycles per word, not 5. (We don't have that fancy instruction.) I'm estimating that it takes between 4 and 6ms to read a single sector. Given that benchmarks do continuous reads we are often disabled for interrupts when the timer tick goes off, hence the time loss.

Now we know why PCs use DMA for disk I/O and ATs use polling. With a 80286 able to bring in a word ever 5 cycles it is running at the same speed as DMA could, with no setup for the DMA controller.

The PCjr BIOS is interesting - there is no DMA on those. They use a polling loop for the floppy drive controller, which is really slow and nasty. They were aware of the timer interrupt problem so they go through the effort to setup a private timer and check it when they are done with the I/O. If the private timer exceeds a certain time, they assume a timer tick would have gone off and they adjust the time of day accordingly.

I'm willing to live with the time loss on XTIDE. It keeps the code simple and it's just not a big issue. If anybody ever turns an XT into a database server then we'll have to think about charging them for an upgrade.
 
Great results! Odd how 1 drive, that is pretty much in between your other IBM drives in size and likely manufacturing date, fails to read/write.

I'd love to get my paws on that drive and dig into it.
If you could, in debug, after issuing a read command which fails, then do IN port reads of 301 and 307 and lemme know the numbers there.
307 is probably just 51h, but 301 is error register, which may have some more details. Heck, dump all 300-308 registers if you'd please.

If you could, also send me a dump of the IDentify device data. I believe I've posted a utility to do that on the wiki, and if not, I've got one that will dump it out to a text file that I should make available. I'm wondering if the drive might be locked/frozen via some security settings? I can tell from the ID data if it is in a locked state.
Click to expand...

I'll collect some data for you. If it is inconclusive I can easily get the drive up there for an advanced debug session.

The drive is not locked though .. it booted on my Athlon 2000 box just fine. It had an old version of SuSE on it, and luckily I remembered the root password. :)
 
OK, I started up a plain vanilla Compaq 486 this evening. I think the Amtel EEPROM is hosed. What should I get in place of that? Anyone have a ROM already flashed. That's one thing I don't have available (an eprom programmer).

What is the layout of the two switches. I can't seem to find it right now. I also can't download the utilities at the moment.

Kelly
 
Last edited:
kb2syd said:
I think the Amtel EEPROM is hosed. What should I get in place of that? Anyone have a ROM already flashed. That's one thing I don't have available (an eprom programmer).
Click to expand...
I doubt it's fried, likely just corrupted and a proper flashing should do the trick.
I'll email you later today with links to the flash program that I'm using and the proper command switches to throw. i'm pretty confident we can resurrect your board with just software.

What is the layout of the two switches. I can't seem to find it right now. I also can't download the utilities at the moment.
Click to expand...

I don't have my card in front of me at the moment, but I think it should go like this:

Left switch = IO decode
switches 5+6 should be OFF. All others ON. That's 300h.

Right switch = ROM address
switches 1,2,4 should be ON, all others OFF. That's D000h.

It would be best to not change the IO or the ROM addresses from where all of our cards are located. If you change the IO, you have to use the setup utility to modify the ROM and re-flash it, and those are variables we don't want to introduce just yet.
 
When I ran the setcard program again last night, it reported that it was flashing the card. I thought "flash" actually flashed the card, and setcard just set up the romimage for the card.

Anyway, when it (setcard) completed, it reported a mismatch in the first 3 bits. I then went in to debug and dumped the contents of the rom. They matched the rom flash file (at least the first few bits). The setcard program said the first bits were all 1e (when they shouldn't have been).

I didn't want to change the address or the IO decode. Just wanted to make sure I didn't flick them when moving things around.

Findcard reports that the card is installed.
Setup reports that no suitable address could be found.

This was under DOS 7 (win95 without the GUI boot), and then later under DOS 6.22.

I eagerly await futher directions. In the mean time, I'm going to remove all cards from this machine (compaq prolinea 486) and replace the CMOS battery. It currently has a sound card and network card installed. I want to reduce the variables.

update:
I just removed all cards and replaced the CMOS battery. Now, when I do:
flash i:eek:prom.bin b:300
the flash program runs throuhg. However it still reports that the first 4 byres are stuck at E3 not 1e like I stated before. I'm going to re-download the utilities and ROM image.

Update 2:
These cards do NOT like Tandy 1000 computers. After 3 boots the ROM needs to be reflashed. It always hangs at boot menu (for the first 3 boots).
One thing to consider is that the Tandy machines initially boot in CO40 then switch to CO80 making the ROM message hard to read. Another thing to consider is that the 1000 series machines do not use standard keyboards.

Flashing STILL reports an error every time too.
 
Last edited:
I have a really basic question about the design of the board.

Right now when we read from the magic data port on the IDE drive it dumps 16 bits into two byte sized latches. The first byte sized latch is at the IO port address and we read a byte from it. (Presumably after the drive has put something in it.) The second byte sized latch is at an I/O address 8 greater than the first address, and we do a second explicit IN to read that byte. The controller doesn't respond to that port address, so it doesn't try to set the contents of that latch, leaving the original contents there for us to read.

The inner loop that reads two bytes from two different ports to make a word is limiting the speed of the card. Is it possible to have a design where we use an IN instruction that reads a full word? (The 8088 supports word transfers from ports.)

The 8088 would go through two full bus cycles to read the word from the bus, and it would handle all of that for us automatically. The first bus cycle would read the first byte, as expected. The second bus cycle would try to read the second byte. From what I can tell the same port address is on the bus for both bus cycles, so there is no way to explicitly tell if we are reading the first byte or the second byte. So the card would have to keep toggle between the two bytes, toggling each time the port is read. The toggle determines if the IDE drive is allowed to set all 16 bits (on the first read) or if the IDE drive is idle, and it also sets which 8 bits get fed back to the 8088.

If this is workable it would be much faster that what we have now.

(And forgive me if this was brought up before too ...)
 
Rats - answered my own question.

This link (http://bitchin100.com/files/hardware/) was discussed early in the thread, and it describes the technique.

Next question - why didn't we do this? Was it just a matter that we had something in hand that we knew worked well and were cloning it?

What we have so far is great. But the engineer in me says 'do better' :) The performance could be at least 2x faster compared to what we have now.


Mike
 
Last edited:
whoops, I totally missed this posting here somehow. I thought we were still waiting on your results. sorry.

kb2syd said:
When I ran the setcard program again last night, it reported that it was flashing the card. I thought "flash" actually flashed the card, and setcard just set up the romimage for the card.
Click to expand...
i'm speaking for per, and i certainly shouldn't be.
Flash does program the part-that's the only thing I have ever used.
If you aren't moving the IO space, then flash is all you need.

If setcard can flash the part as well, then the 2 programs should be merged together so you just load up the binary image, then tweak IO address as required, and flash it all is one swell foop.

I'll leave the rest of these flash program issues for per to answer.
update:
I just removed all cards and replaced the CMOS battery. Now, when I do:
flash i:eek:prom.bin b:300
the flash program runs throuhg. However it still reports that the first 4 byres are stuck at E3 not 1e like I stated before. I'm going to re-download the utilities and ROM image.
Update 2:
These cards do NOT like Tandy 1000 computers. After 3 boots the ROM needs to be reflashed. It always hangs at boot menu (for the first 3 boots).
One thing to consider is that the Tandy machines initially boot in CO40 then switch to CO80 making the ROM message hard to read. Another thing to consider is that the 1000 series machines do not use standard keyboards.

Flashing STILL reports an error every time too.
Click to expand...

well, it looks as though the re-programming is successful, as the option rom is getting called by the mainboard BIOS, even though the flash program is reporting a byte mismatch. Let's just let that be for now, and see what the tandy is trying to do to us.

You say that after 3 reboots the ROM needs to be reprogrammed. Does that mean that the main BIOS just ignores/skips the option rom after the 3rd boot and the card is "dead" from there? If that's the case, then something is corrupting the ROM itself, and it would be interesting to know what that is.

I'd do this:
Flash the card.
Use mike's ROM dump utility:
http://www.brutman.com/PCjr/pcjr_downloads.html -> pcjrcart.zip
and dump the ROM out.

Put the card in the tandy, reboot it 3 times or until the ROM is corrupt.
Dump the rom again. That'll let us compare the 2 rom images before and after and allow us to see what is getting corrupt. It might not tell us anything, but it would be interesting to know what it's doing. The next card does have a write protect on the eeprom, so that should certainly help with this, but I'm mostly curious to see what it's doing.

After that, I think we will also need to move your testing off the tandy for the time being and use it on another platform. I'd like you to get a better warm-fuzzy about the normal operations of the card rather than fighting whatever demons are inside the tandy. we'll have to concentrate on those later, like when I can get my hands on one of these machines.

Anyone have a tandy that they wouldn't mind selling/loaning me?
 
hargle said:
Anyone have a tandy that they wouldn't mind selling/loaning me?
Click to expand...

If you can't find one closer, I can mail you a bog standard Tandy 1000sx and keyboard. The SX boots from both Tandy and pc compatible HD cards depending on a switch setting.

Or, I could send an HX or EX (one of the all in ones) with the added memory so it has DMA. This would be much lighter, but the card would have to plug into a (homemade) adapter. I can include an 8 bit AT IDE card that does work with the Tandy lines for reference.

Do you have a CGA Monitor? I can send the 1000 and keyboard, but I would like them back. I would not want to box up a monitor.

Shipping would be from NJ. Anyone closer to Hargle have a 1000 he can use?

I will report back on the other requests later this week (probably Wednesday).
 
Hi! What I would do is burn a 2764 EPROM. Regardless of what the Tandy is doing, it is not going to corrupt an EPROM. From what you are describing though, it doesn't sound like the EEPROM is the problem.

I think there is most likely something damaged or broken on your card. If not, the Tandy is doing some *very* strange things.

It may be cheaper/easier to try a 2764 EPROM and/or swap cards rather than ship machines. As the Tandy is an early IBM PC "clone" it may be only semi-compatible. Its possible there are differences in its ISA bus implementation causing the anomalies.

Thanks and have a nice day!

Andrew Lynch
 
The Tandy's anomalies on the ISA bus fall into three categories, the possible lack of a -5v line, differences in the bus controller compared to the IBM PC and differences in the BIOS interface.

Of course, if Hargle has no CGA or EGA monitor, he can always use the composite output and squint at its 80-column output.
 
yeah, it was mostly the keyboard issues and the 40 column screen stuff that I wanted to fix as well as trying to figure out why some stray writes are hitting our EEPROM. There's likely not much we can about that, short of removing the write enable line to the ROM, which will be on the next board anyway, so this is more of a curiosity over anything else.

I do have a couple CGA monitors; true blue 1535's in fact, so all I'd need is a machine and the ability to plug our card in and see what happens.

It would be great to find one closer, but shipping is not a problem if you're willing to loan one out.
 
mbbrutman said:
Rats - answered my own question.

This link (http://bitchin100.com/files/hardware/) was discussed early in the thread, and it describes the technique.

Next question - why didn't we do this? Was it just a matter that we had something in hand that we knew worked well and were cloning it?

What we have so far is great. But the engineer in me says 'do better' :) The performance could be at least 2x faster compared to what we have now.


Mike
Click to expand...

Hi Mike,
Are you referring to this?

If so, that circuit is great for Z80 ECB bus systems but won't work on ISA without some major adaptation. I believe it is the basis of GIDE by Tilmann Reh.

The major issue with design is that it is much more complex than a quick look at the schematic may indicate. It uses a PAL so it would either require some design engineering with the equations to either build from common components or converting to and accepting unique programmable hardware into the design (GAL or CPLD). That presents a major buildability issue and long term support problem. Using common 74LSxxx TTL is much easier to build and support but replacing that PAL would require several additional chips since it contains a lot of interface logic.

Probably with enough additional logic, one could make the LO and HI port read from the same IO port but it would significantly add to the complexity of the board. More parts -> more PCB area -> higher cost -> less affordable -> less demand, etc. I recall discussing this subject with per (?) a while back and looked into some alternatives but nothing really gelled.

Whatever solution there is out there will probably require some prototyping and possibly a redesign. The problem is more complex than it appears because the IDE interface requires 16 contiguous IO ports. Also, sometimes the data port $x0 must be accessed sequentially so just flipping the port between LO and HI introduces its own problems.

Feel free to make a new design and prototype it if you'd like. My plate is full with other N8VEM projects at the moment (VDU PCB, PropIO prototyping, etc) so I am kind of at the periphery of this project until the BIOS settles and the hardware design is finalized.

I still have not started the next version PCB respin as I recall there were still open issues with the hardware design although I don't recall what they are at the moment. I think we've learned a lot with the initial PCB prototypes but they are definitely getting old and its time for another rev of hardware, IMO.

For all its faults, the current design does have the benefit of a relatively low part count and small PCB area. That keeps the costs low and is essential for this project to be viable, IMO.

Thanks and have a nice day!

Andrew Lynch
 
Last edited:
Hi Andrew,

Yes, that is the project I'm referring to.

I was looking at the code that does the read and write loops trying to find a way to make it faster. We are reading and writing about 85KB/sec now and I know it can be much faster. I figured out a way to shave four cycles without loop unrolling but it is still a big loop - we have the two different port addresses to deal with and a shortage of registers. I know the 8088 is capable of 16 bit transfers - using them would make the loop simpler and much faster.

The Z80 (being influenced by Intel designs) handles 16 bit port reads in a way similar to the 8088. The Tilmann Reh design, although for a different bus, shows that the technique of flip flopping between two latches can work. His solution is more complex because he is paranoid about managing the state of the flip flop, ensuring that it always gets reset if another register is touched. (A bit over overkill, but commendable.)

I don't think the current design has a lot of faults. Functionally it is very good - most of my drives are working with it. The performance is a minor issue; there is a lot of potential to fix it. I understand that if I want to make it faster I'll have to do the work. ;-0

Another idea that I have in the back of my head is to memory map the latches instead of addressing them as I/O ports. The IDE card can continue to read or write 16 bits at a time to the latches. The PC would continue to read or write 8 bits at a time. The advantage of memory mapping is that the PC will generate a different address on the bus for the second byte - the lowest address line can be used to differentiate between the two latches. I haven't worked it out on paper, but memory mapping the registers should be transparent to the device - the read and write bus cycles are so similar for memory and I/O.

So just an idea for now but what do you think of memory mapping?


Mike
 
You must log in or register to reply here.
Back
Top