• Please review our updated Terms and Rules here

XTIDE tech support thread

Krille said:
Tronix, are you benchmarking CF drives or similar fast media?
Click to expand...

No, i use real IDE harddrive Fujitsu M1636TAU (1,28 Gb). He is not very fast, even during normal operation at Pentium-1 board. So, i tried switch to IDE-XT v1 (without Chuck mod) - results are the same: worked with 1.1.5 BIOS and don't work with 2.0.0b3 and latest svn.
 
I'm sorry but I can't reproduce this problem. It must be something specific to certain machines or configurations.
 
Yes, I confirm the existence of the problem. Norton Utilities SysInfo hangs on the disk speed benchmark.

My configuration: Taiwanese "turbo" XT clone XL-7 at 8MHz, Fujitsu 8088-1 CPU.
XT-IDE v2 in chuck mode, latest XT-IDE Universal BIOS from CVS,
Traxdata 1Gb CompactFlash.

CheckIt V.3 HDD benchmark works.

Unfortunately I have no spare time to test a real IDE HDD.

Small note: there are two SysInfo utilities in the NU package.
One is a small CLI version, it works. Another SysInfo is a large menu-driven version, it hangs on XT-IDE HDD test.
 
I've just tested latest XT-IDE Universal BIOS with real IDE hard drive Quantum Fireball 2110 AT
partitioned as single drive C:, MS DOS 6.22 and SYSINFO from the NU 4.50,

It really hangs on the Hard Drive Benchmark Test. No LED activity.

Small "SI.EXE C:" works and determines 1.9 performance index.
 
XTIDE Universal BIOS (current svn) hangs forever in this infinity loop.
I do not exactly understand what does it do and how does NU SYSINFO call this situation.

Code: 
 21790                              <1> 
 21791                              <1> ;--------------------------------------------------------------------
 21792                              <1> ; IdeWait_PollStatusFlagInBLwithTimeoutInBH
 21793                              <1> ;	Parameters:
 21794                              <1> ;		BH:		Timeout ticks
 21795                              <1> ;		BL:		IDE Status Register bit to poll
 21796                              <1> ;		DS:DI:	Ptr to DPT (in RAMVARS segment)
 21797                              <1> ;	Returns:
 21798                              <1> ;		AH:		INT 13h Error Code
 21799                              <1> ;		CF:		Cleared if success, Set if error
 21800                              <1> ;	Corrupts registers:
 21801                              <1> ;		AL, BX, CX, DX
 21802                              <1> ;--------------------------------------------------------------------
 21803                              <1> IdeWait_PollStatusFlagInBLwithTimeoutInBH:
 21804 00001AE3 88DC                <1> 	mov		ah, bl
 21805 00001AE5 88F9                <1> 	mov		cl, bh
 21806 00001AE7 E865FB              <1> 	call	Timer_InitializeTimeoutWithTicksInCL
 21807 00001AEA E87D00              <1> 	call	IdeIO_InputStatusRegisterToAL		; Discard contents of first read
 21808 00001AED 80E47F              <1> 	and		ah, ~FLG_STATUS_BSY
 21809 00001AF0 7419                <1> 	jz		SHORT PollBsyOnly
 21810                              <1> 	; Fall to PollBsyAndFlgInAH
 21812                              <1> ;--------------------------------------------------------------------
 21813                              <1> ; PollBsyAndFlgInAH
 21814                              <1> ;    Parameters:
 21815                              <1> ;        AH:        Status Register Flag to poll (until set) when device not busy
 21816                              <1> ;        DS: DI:    Ptr to DPT (in RAMVARS segment)
 21817                              <1> ;    Returns:
 21818                              <1> ;        AH:        BIOS Error code
 21819                              <1> ;        CF:        Clear if wait completed successfully (no errors)
 21820                              <1> ;                Set if any error
 21821                              <1> ;    Corrupts registers:
 21822                              <1> ;        AL, BX, CX, DX
 21823                              <1> ;--------------------------------------------------------------------
 21824                              <1> PollBsyAndFlgInAH:
 21825                              <1> [COLOR=#FF0000].PollLoop:[/COLOR]
 21826 00001AF2 E87500              <1>     call    IdeIO_InputStatusRegisterToAL
 21827 00001AF5 A880                <1>     test    al, FLG_STATUS_BSY                    ; Controller busy?
 21828 00001AF7 7504                <1>     jnz        SHORT .UpdateTimeout                ;  If so, jump to timeout update
 21829 00001AF9 84E0                <1>     test    al, ah                                ; Test secondary flag
 21830 00001AFB 751A                <1>     jnz        SHORT IdeError_GetBiosErrorCodeToAHfromPolledStatusRegisterInAL
 21831                              <1> .UpdateTimeout:
 21832 00001AFD E85BFB              <1>     call    Timer_SetCFifTimeout
 21833 00001B00 73F0                <1>     [COLOR=#FF0000]jnc        SHORT .PollLoop[/COLOR]                        ; Loop if time left
 21834 00001B02 E81200              <1>     call    IdeError_GetBiosErrorCodeToAHfromPolledStatusRegisterInAL
 21835 00001B05 7203                <1>     jc        SHORT .ReturnErrorCodeInAH
 21836 00001B07 B480                <1>     mov        ah, RET_HD_TIMEOUT                    ; Expected bit never got set
 21837 00001B09 F9                  <1>     stc
 21838                              <1> .ReturnErrorCodeInAH:
 21839 00001B0A C3                  <1>     ret

Backtrace:
IdeWait_PollStatusFlagInBLwithTimeoutInBH <-- Device_SelectDrive (IdeCommand_SelectDrive) <-- AH10h_HandlerForCheckDriveReady
 
Last edited:
I don't see anything wrong with that timeout loop and it looks pretty much the same all the way back to r70 (XTIDE Universal BIOS version 1.1.5) so I don't think that's the problem. If you are sure that it never returns then something must be continually writing to RAMVARS to corrupt the timer values (RAMVARS.bTimeoutTicksLeft and/or RAMVARS.bLastTimeoutUpdate). This is unlikely in my opinion. Generally speaking, debugging timer dependent code can be very hard.

I very much appreciate the efforts to find this bug (there's no way I could do it on my own since I have no way to even reproduce it).
 
What is your testbench ? Where is your RAMVARS located? My RAMVARS resides in the low memory region (0:300??, hi IRQ numbers? stack ?).
AFAIK there was an option to move RAMVARS on the top of memory between 639 and 640K. I will test this option.

JFYI, NU does not overwrite HDD configuration in RAMVARS nor crash itself. It should be possible to debug NU on "virtual" platform
setting data access breakpoint on RAMVAR region.
 
OK, I've finally managed to reproduce the problem and while I haven't found the actual cause (yet), I have verified that the timeout loop works as intended. The BIOS actually returns from the call to INT 13h AH=10h (AH10h_HandlerForCheckDriveReady as you noted) with a Timeout error (AH=80h) but SI ignores that and keeps calling the same function in its own timeout loop which keeps spinning for 65535 times. Here's the offending loop in SI;
Code: 
<bochs:334> u /18 0xf41f
0000f41f: (                    ): mov cx, 0xffff            ; b9ffff
0000f422: (                    ): push cx                   ; 51
0000f423: (                    ): push ds                   ; 1e
0000f424: (                    ): push bp                   ; 55
0000f425: (                    ): mov dl, byte ptr ss:[bp+6] ; 8a5606
0000f428: (                    ): xor dh, dh                ; 32f6
0000f42a: (                    ): mov cx, 0x0001            ; b90100
0000f42d: (                    ): mov ax, 0x1000            ; b80010
0000f430: (                    ): int 0x13                  ; cd13
0000f432: (                    ): pop bp                    ; 5d
0000f433: (                    ): pop ds                    ; 1f
0000f434: (                    ): pop cx                    ; 59
0000f435: (                    ): jnb .+8                   ; 7308
0000f437: (                    ): cmp ah, 0xff              ; 80fcff
0000f43a: (                    ): jz .+2                    ; 7402
0000f43c: (                    ): loop .-28                 ; e2e4
0000f43e: (                    ): stc                       ; f9
0000f43f: (                    ): ret                       ; c3

This means that the hang actually isn't a hang, it will return after about 7.6 days (only 47.33 hours without MODULE_POWER_MANAGEMENT) if my estimates are correct*. Patience is a virtue! ;)

I don't know why the BIOS fails with a timeout error on calls to AH10h_HandlerForCheckDriveReady but the problem obviously lies in there somewhere.

* The timeout is 10 seconds per call (2.6 seconds without MODULE_POWER_MANAGEMENT) times 65535 calls.
 
Krille said:
I don't know why the BIOS fails with a timeout error on calls to AH10h_HandlerForCheckDriveReady but the problem obviously lies in there somewhere.
Click to expand...

Just to clarify, when calling this same function (with the same parameters) from within DEBUG it will return with no error. There is something specifically with SI.EXE that causes this error, possibly stack corruption of some kind. Or it's some other call that corrupts something somewhere and the problem just happens to manifest itself here.
 
Drive Not Ready ??? IDE and CF are very fast for XT and should be ready in milliseconds. Seems, SYSINFO call sequence cause a Drive Not Ready status.
 
FWIW i downloaded NU v5.0 and v6.01 i found on the net and tried both versions:

IBM XT 5160
640K Mobo
XT-IDE v1 controller ( No Mods )
MS DOS 6.22

Latest XT-IDE universal bios r587 from svn:
With 128 Mb CF card fitted i ran SYSINFO.exe from both versions and got the same "hang" with the disk speed benchmark test, I replaced the CF card with a Fujitsu 2.1 Gb Hard drive and got the same "hang".

I switched to the XTIDE Universal BIOS v1.1.5:
With 128 Mb CF card fitted, I ran SYSINFO from NU v5 and got an error when i ran the disk speed benchmark test:

*** Internal Error: Dialog Too Big.

Same CF card i ran SYSINFO from NU v6.01 and got the following message on screen when i ran the disk speed benchmark test:
An advanced disk controller has been detected!.
The disk controller in this machine has blocked the drive seek timing test. Many advanced controllers will ignore attempts to move the drive heads unless data is actively being transfered.
The performance index shown in the following graph will likely be higher than the actual performance of your disk drive.
Click to expand...
I click OK and the performance index graph is shown and i successfully move on clicking the next button.

I replace the CF Card with the Fujitsu drive and both versions of SYSINFO and the disk speed benchmark test run successfully.
 
Malc said:
Latest XT-IDE universal bios r587 from svn:
With 128 Mb CF card fitted i ran SYSINFO.exe from both versions and got the same "hang" with the disk speed benchmark test, I replaced the CF card with a Fujitsu 2.1 Gb Hard drive and got the same "hang".
Click to expand...

I did a minimal custom build of r587 and both v5 and v6.01 of NU SYSINFO disk speed benchmark tests run successfully, It doesn't like CF cards much but seems to work on a couple of old hard drives i tried, I think Checkit3 is better IIRC.
#1.jpg#2.jpg
 
Malc, was this the Tiny build?

I'm using NU 5.0 that I found somewhere on the net and in my testing only the XT builds hang. The XT+ and AT builds do not. Additionally, only benchmarking "real" harddrives will cause the hangs. Benchmarking a serial drive works. I haven't been able to test the Tiny build though because I can't seem to find a way to disable Bochs' internal harddrive BIOS and that's a real show stopper.
 
Krille said:
Malc, was this the Tiny build?
Click to expand...

With the Tiny build NU 5.0 and 6.01 benchmarking real hard drives results in the "hang". Benchmarking a 128Mb CF card in NU 5.0 results in the error " Internal Error: Dialog Too Big " and the program quits. Benchmarking the same CF card in NU 6.01 results in the message " An advanced disk controller has been detected!. " etc, I click ok and move on.

With the IDE_XT build NU 5.0 and 6.01 benchmarking real hard drives and CF results in the hang.

Custom build with "MODULE_STRINGS_COMPRESSED MODULE_8BIT_IDE MODULE_HOTKEYS MODULE_COMPATIBLE_TABLES MODULE_IRQ " results in a successfull benchmark test of CF and Hard drives in both versions.

Checkit V3 is much better, It works out of the box with default XT bios builds r587 with CF and a real hard drive that i tried.
 
If it of any help, I can confirm that my 2 Lo-tech ISA CompactFlash Adapters throw the same sysinfo errors with CF cards.
Checkit also works for me.
 
I noticed the N8VEM site changed a while back, You got to apply for membership and login now, The Rev 1 cards haven't been available for a long time and Todd was supplying R 2 cards at one time but not sure if he still is so not really surprised considering the other choices available.
 
I've opened a case at pbworks.com Support and got an answer:

==============
From: Support <support@pbwiki.com>
To: me
Subject: Your PBworks Support Inquiry [ ref:_00D708eKn._500701EBTEq:ref ]

Hello! Thanks for contacting PBworks Support and Services.

The workspace has been removed and the contents are no longer hosted by PBworks.

Thanks,

The PBworks Support Team
http://docs.pbworks.com/
http://edumanual.pbworks.com/
===============

Update I've just got approval for "n8vem-sbc" workspace at pbworks.com .
All N8VEM files are there. For XT IDE v2 there are schematic as PDF, a board as PDF
and jumper settings PNG. No Ki-CAD schematic nor Gerber files.
 
Last edited:
hey group, i dunno if this is the right place, but xtide tech support sounded good... i built one of the dangerous prototypes xt-ide v2a boards... i need to program the xilinx cpld and i have a bus pirate, but i have no idea how to make this happen. i've reviewed online documents, and i'm still kinda stuck on stupid. i got one of the sandbox bus pirates off ebay (v3.b). it says firmware: 6.3-beta1 r2088/bootloader: v4.4
 
You must log in or register to reply here.
Back
Top