XT-IDE tech Support

[kb2syd]

I agree with aitotat. I have been working on various configurations to see if any DOS prior to 3.3 would work. I reduced the size of the drive using the HPA down to 20 meg. It gives the same results.

I personally can live with 3.3, although I would prefer 3.2 for the SX.

Now, all we need to address on the Tandy video mode problems. On some of the newer 1000 line you can install an additional 128k of RAM and video will always be allocated from that. I don't think this is available for the SX.

 

[bugman2112]

Sorry, I forgot to set register SI. NOW it should work (I hope..).

I also did some major overhauling to the routine that mannages the baseaddress searching. A lot of that code was "copy-n-paste, and hope for the best"-code, and a lot of it didn't make sense at all. I really don't know what I was thinking when I wrote it.

BTW, I did a minor fix to the Flasher (now you can properly manually select a baseaddress if you don't specify one as a parameter).

Setcard appears to be working nicely. I was able to change the firstboot drive and delay with no trouble. One thing I noticed, if I didn't select a base address as a parameter, the selectable menu does not offer the base address which corresponds with my setup (D000). The workaround is to always select it up front "/o:"

 

[per]

One thing I noticed, if I didn't select a base address as a parameter, the selectable menu does not offer the base address which corresponds with my setup (D000).

I just realized that the data it used to compare signatures to didn't contain signature at the time of the routine being executed.

Now, it should properly work, maybe...

 

[hargle]

A very serious Tandy issue found. Some models, like 1000 SX, shares top of 640k base with video controller. Video controller only takes what it needs and DOS can use the rest. Different video modes requires different amount of memory so memory available for DOS can change while the system is running.

Very bad indeed, but this may be a blessing in disguise; forcing me to move the reserved 1k at the top of memory and tucking things away inside the BDA area instead. Freeing up 1k of memory is always a good thing!

This will be quite an overhaul to the code, but worthwhile. We may end up losing multiple card support, but that was a bit of a luxury that few would be using anyway. (plus it wasn't working 100%)

This will take priority over adding CHS support.

 

[hargle]

I did notice a possible bug in XTIDE bios. I have 5.25” Tandy DOS 3.2 boot disk in drive A and 3.5” DOS 6.22 boot disk in drive B. DOS 6.22 fdisk does not find the ST5850A when i boot from drive B using XTIDE menu. Everything works when i boot from drive B by pressing F3 at startup (Tandy BIOS feature to swap drives).

Fixed!
that was a fun bug to find. The deal here is that you're swapping drive 00 with drive 01. That value is stored in the DL register.

When we drive swap, we simply swap 00 for 01, and vice versa at the start of the XTIDE routines. After we're finished, I swap the value back, so that the software who called my routines doesn't get values changing that are unexpected.

Things work great this way, except for whenever DOS wants to check to see if there's a hard drive, it calls INT 13, function 08, which happens to return the number of hard drives in DL, and in the usual case, that's a 01...

Yep, at the very end of my routines, I try to restore the swapped value back, and I see that it's 01. Low and behold, that's the drive number we're swapped with, so I change it back to 00. Now your system has 0 hard drives!

Luckily, that's the only INT 13 function that returns an actual value in DL, so this was a one time fix. ah, software bugs.


Anyway, version 0.11 is coming soon. I've removed the requirement for the 1k at the top of memory. We've currently lost multi-card support, but so far things are working ok. More details later.

 

[per]

When we drive swap, we simply swap 00 for 01, and vice versa at the start of the XTIDE routines. After we're finished, I swap the value back, so that the software who called my routines doesn't get values changing that are unexpected.

Things work great this way, except for whenever DOS wants to check to see if there's a hard drive, it calls INT 13, function 08, which happens to return the number of hard drives in DL, and in the usual case, that's a 01...

Isn't there one problem in this? What if you try to boot of floppy drive ID 02 or 03, If it only checks and swaps 00 and 01?

I know not may people have more than two floppy drives, but the posibility is there...

 

[aitotat]

I've removed the requirement for the 1k at the top of memory.

Great! I already started working on a temporary fix to relocate XTIDE EBDA when changing video mode (Int 10h/AH=00h). No need to finish it since it won't be needed in next bios version. I hope you release it soon.

 

[hargle]

Isn't there one problem in this? What if you try to boot of floppy drive ID 02 or 03, If it only checks and swaps 00 and 01?

I know not may people have more than two floppy drives, but the posibility is there...

that was only an example for why it was breaking on a 2 drive system.
The swapped drive number itself is dependent on whatever drive you booted to, vs. whatever the drive you selected from the boot menu.
It should work just fine with any number of drives.
IIRC, it's all based off your code!
It was my fault for not realizing that this one stinkin' service routine returns a value in DL.

 

[hargle]

Great! I already started working on a temporary fix to relocate XTIDE EBDA when changing video mode (Int 10h/AH=00h). No need to finish it since it won't be needed in next bios version. I hope you release it soon.

revision 0.11 is ready, however, I'm having problems finding a happy place to store stuff. I need to store, at a minimum, 24 bytes per drive, plus there are an additional 3 or 4 bytes that the controller itself uses to do the drive swapping.

16 of those 24 bytes must be contiguous. That's the Fixed Disk Parameter Table. (see INT 41h/46h)

I'd like to keep the other 8 of those bytes tucked in beside the FDPT, but that's not a requirement. Those 8 bytes are used for ehanced INT13 support to hold the full drive size in LBAs.

On the original XT/PCs, there's some pretty good chunks of memory free at the top of the BDA, 0:4c0-0:4ff, which I originally used. On an AT+ class machine, those areas are by more motherboard devices and/or DOS itself, and thus your hard drive breaks on those machines.

I do a lot of machine swapping, since it's easier to debug on my 486 than it is on my 8088, so I need something that works on both machines.

There are also several unused interrupt vectors. Ralf Brown says that most interrupts from 80-FF are reserved for BASIC. BASIC on the PC/XT is actually something that gets used occasionally, so I was hesitant to use those areas, but then I'm also thinking that it's probably reserved but not actually used. Anyone know? Anyone have a lot of BASIC programs to try while using the XTIDE?

There is also the issue of other cards also trying to utilize the same chunks of memory, but we can't worry about that just yet.

So, do we fork the BIOS tree? Do we detect the machine type and locate differently on different machines? Do we just use INTs D0-E0 and hope that we don't break BASIC?

 

[kb2syd]

I need to store, at a minimum, 24 bytes per drive, plus there are an additional 3 or 4 bytes that the controller itself uses to do the drive swapping.

Without sounding too glib...
How do they do it on other controllers? I didn't have to worry that my WD XTGEN needed RAM anywhere. If I'm missing something obvious, please let me know.

 

[hargle]

Without sounding too glib...
How do they do it on other controllers? I didn't have to worry that my WD XTGEN needed RAM anywhere. If I'm missing something obvious, please let me know.

Depends on the controller.
From what I've seen, most steal 1k off the top of memory. The acculogic 8bit controller as well as all of the modern promise controllers that I've examined do this.

My TMC-850 SCSI controller doesn't do that. Not sure what it's doing, as I have not disassembled that ROM. The sample size of vintage hardware that I have is pretty small, so I'm looking for ideas.

 

[aitotat]

So, do we fork the BIOS tree? Do we detect the machine type and locate differently on different machines? Do we just use INTs D0-E0 and hope that we don't break BASIC?

It would be real nice if fixed disk parameter table and other settings could be written directly to EEPROM.

My 286 has a BIOS that allows user to select whether to use EBDA or top of interrupt vector table (from 30:00h). Something like that would be nice for XTIDE BIOS.

 

[kb2syd]

Depends on the controller.
From what I've seen, most steal 1k off the top of memory. The acculogic 8bit controller as well as all of the modern promise controllers that I've examined do this.

This explains why the acculogic 8bit controller worked in my 1000tx once I upgraded the RAM to 768k! You can search here to see what I tried in order to make it work.

That was the final requirement, upping the RAM to cause the Tandy to always steal its video memory from the upper 128k.

 

[mbbrutman]

The simpler SCSI controllers (like the TMC850 or the Adaptec 1542) usually only support two hard drives using the BIOS support. To support more than two hard drives you have to use device drivers. (ASPI for Adaptec products, CAM for Future Domain.)

My opinion on things:

• Don't steal memory from the BIOS or DOS areas. Those are highly variable between machines and DOS releases, and you never know what you might be stepping on.
• Don't steal memory from the top of DOS. But really the only two machines that have this problem are the PCjr and the Tandy machines that were patterned after the PCjr. This is more of an issue with the Tandy machines than the PCjr, since the PCjr can't use this card directly anyway.
• I don't particularly care about multi-card support. I'm really happy that one card provides the ability to support two modern drives. That is all that any of the machines we are putting these in would have supported under normal circumstances anyway.
• If the card really needs additional storage, we should put it on the card. If we reserve a few K for the BIOS we should be able to share some of the address decode logic and put in a minimal amount of RAM there too.
• Don't fork the BIOS unless absolutely necessary.

In general I am a firm believer in KISS. We have got a great card here that supports up to two modern LBA drives in a pretty wide variety of machines. If getting rid of multi-card support decreases complexity and improves compatibility, then I'm all for that.


Mike

 

[hargle]

It would be real nice if fixed disk parameter table and other settings could be written directly to EEPROM.

They could, but that little jumper we just added to keep our eeproms from getting corrupted now voids that idea. Again, Atmel parts would be our savior for this dilemma, as they have software protection and the SEEQ parts don't.

My 286 has a BIOS that allows user to select whether to use EBDA or top of interrupt vector table (from 30:00h). Something like that would be nice for XTIDE BIOS.

That's pretty cool! Again, user selectable things need to be stored somewhere.

30:00 (or 0:300) is INT C0, which is where I was dabbling before. That's where I'm afraid we may break BASIC functions, but that may be a decent place to start playing with and see if anyone complains.

Ralf says:
"INT C0 - IBM ROM BASIC - used while in interpreter

Notes: called by ROM BASIC, but pointed at IRET by BASIC.COM/BASICA.COM
BASIC.COM/BASICA.COM do not restore vector on termination"

No harm in trying to run a few basic program while the XTIDE is in the system though. If no one complains, that's likely where it'll go.

 

[hargle]

This explains why the acculogic 8bit controller worked in my 1000tx once I upgraded the RAM to 768k! You can search here to see what I tried in order to make it work.

BTW: XTIDE is register compatible with that acculogic card. If you use Per's setup utility to set our XTIDE BIOS to port 360h, then flash the eeprom in the XTIDE, then move the chip to your aculogic card, you'll have an acculogic card that now supports drives >8.4G, and with BIOS 0.11, will work on a machine with less than 768k of memory.

 

[aitotat]

That's pretty cool! Again, user selectable things need to be stored somewhere.

I think that this is something that should be selected before flashing. Create new flag in localVars and check it in reserveMem and point2Base subroutines. If set, return 30h for segment. If not set, do the usual thing.

About the usual thing. Here is a little optimization. Create another flag in localVars to be configured before flashing. That would be flag for single controller mode (no other XTIDE or ANY other hard disk controllers). When set, it would be safe to assume that Interrupt Vector 41h is always used for XTIDE master drive and Interrupt Vector 46h for slave drive. Then point2Base can simply read and return segment from Interrupt Vectors. No need to search for XTIDE signature or anything.

At the moment you don't seem to be using Interrupt Vectors 41h and 46h at all. They are meant for storing pointers to Disk Parameter Tables for Hard Disks 0 and 1.

 

[per]

They could, but that little jumper we just added to keep our eeproms from getting corrupted now voids that idea. Again, Atmel parts would be our savior for this dilemma, as they have software protection and the SEEQ parts don't.

One other problem here. EEPROMs can't be written to more than about 10000 times. If settings are written to it on every boot, this means that you can't turn your computer on more than 10000 times before the EEPROM fails.

 

[hargle]

One other problem here. EEPROMs can't be written to more than about 10000 times. If settings are written to it on every boot, this means that you can't turn your computer on more than 10000 times before the EEPROM fails.

I think we could be a little smart about that though; only write it if the data has changed. If, for example, we were writing the FDPT into the eeprom, we'd just build it in a scratchpad in main memory, then compare it to whatever is already in the eeprom, and only re-write it if it's different, meaning the hard drive changed.

 

[hargle]

Here's a new BIOS to play with.
I'm not going to officially release this one quite yet, as there's a bit more code cleanup I want to do, but I want to see if this one gets any traction with the Tandy users. I also need people to test it in BASIC, to see if overwriting those ISR actually breaks functionality, or if that's just a big ole myth.
It would be even better if you attached 2 drives and then tested BASIC.

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

Keep version 10 handy, just in case. (just change the above 11 to a 10 and you can download it directly) I've done only very, very light testing on this.