• Please review our updated Terms and Rules here

XTIDE Universal BIOS v2.0.0 beta testing thread

So the latest version behaves "better" with full mode enabled vs. minimum mode? I would think on a system as "simple" as a Morrow Pivot-vintage box minimum mode would be more appropriate, but perhaps it stomps on some BIOS data era that full mode doesn't?

The docs also mention a "late initialization" option:

Normally expansion card BIOSes are initialized before POST completes. Some (older) systems initialize expansion card BIOSes before they have initialized themselves. This might cause problems since XTIDE Universal BIOS requires some main BIOS functions for drive detection. This problem can be fixed by using late initialization to detect drives on boot loader. Late initialization requires that XTIDE Universal BIOS is the last BIOS that installs INT 19h handler. Make sure that XTIDE ROM is configured to highest address if you have other storage device controllers present.
Click to expand...

I wonder if it might be worth trying that, if you haven't? The bit about "requiring some main bios functions for drive detection" might be relevant?
 
Eudimorphodon said:
...The docs also mention a "late initialization" option:
I wonder if it might be worth trying that, if you haven't? The bit about "requiring some main bios functions for drive detection" might be relevant?
Click to expand...
I posted XUB r601 with Boot Menu and Very late init a while back, See post #512 in this thread, Might be worth a try.
 
Malc said:
I posted XUB r601 with Boot Menu and Very late init a while back, See post #512 in this thread, Might be worth a try.
Click to expand...

Thanks for this modified 601. This is actually my favorite XUB version now, not because it fixed the boot up issue, but because it makes boot up smoother. I'll explain.

Wrt correct detection of the disks, and avoiding the repeated sequence of hard start, soft restart... no luck. Late initialization appears to not affect this issue.

However, R601 is better for me for the following reason.

On the Z171, for all other successful XUB versions (other than this modified 601), the XUB BIOS screen appears after 3 things occur.
1) Z171 does a memory test on power up
2) Z171 displays "Booting....." on screen
3) Z171 momentarily spins up FDD A
---> If there is any floppy in A, XUB quickly appears.
---> if there is no floppy in A, then there is a long timeout before XUB appears

With this modified 601, the sequence is different, and preferable.
1) Z171 does a memory test on power up
2) Z171 displays "Booting....." on screen
---> XUB quickly appears.

So, this is better!

There must be some kind of memory initialization issue here.
* after a power cycle with a short delay, the "table of disks" is very corrupt. XUB reports a very long list of "foreign disks".
* after a power cycle with a long delay, the "table of disks" shows only FDD A and B.
* after a warm restart CNTL ALT DEL,the "table of disks" gets an incremental entry

Just looking at this issue, since the length of time of power cycle influences the outcome, doesnt this mean that there is corrupt data in RAM, that is only cleared out after a long period of no refresh?

I wish I knew more about how this BIOS works.... ;)
 
Eudimorphodon said:
So the latest version behaves "better" with full mode enabled vs. minimum mode? I would think on a system as "simple" as a Morrow Pivot-vintage box minimum mode would be more appropriate, but perhaps it stomps on some BIOS data era that full mode doesn't?
Click to expand...

Not sure; didn't actually test with or without full mode. I would say I saw no difference that I could attribute to R602.
In my last test using R601 with late init, I did not enable full mode.

Think I will just use minimum mode as a rule going forward.
 
Got a weird problem with a boot menu.
If there is a FDC in a system (Sergey's 8-bit FDC+serial or a generic 16-bit HDC+FDC), opening the boot menu hangs the system completely. Other than that everything works fine. I use pre-compiled ide_xtpl bios with XT-IDE v4 and Juko NEST v30 board.
How I can further pinpoint source of this problem?
 
Yep, A few years ago when the old google code site went read only and a bit later shut down for good, Go to the new XUB site http://www.xtideuniversalbios.org/ Click on " Browse source" and then "Repository URL" and you have the URL you seek.
 
Well I have R602 from the repo, and I have the tools installed, and I can compile.

So I suppose the adventure of figuring out what is wrong commences. I hope to end up with a streamlined XUB that is specific to Z171 and addresses this weird defect. At the same time I have new PCBs to try out.

Twospruces said:
Thanks for this modified 601. This is actually my favorite XUB version now, not because it fixed the boot up issue, but because it makes boot up smoother. I'll explain.

Wrt correct detection of the disks, and avoiding the repeated sequence of hard start, soft restart... no luck. Late initialization appears to not affect this issue.

However, R601 is better for me for the following reason.

On the Z171, for all other successful XUB versions (other than this modified 601), the XUB BIOS screen appears after 3 things occur.
1) Z171 does a memory test on power up
2) Z171 displays "Booting....." on screen
3) Z171 momentarily spins up FDD A
---> If there is any floppy in A, XUB quickly appears.
---> if there is no floppy in A, then there is a long timeout before XUB appears

With this modified 601, the sequence is different, and preferable.
1) Z171 does a memory test on power up
2) Z171 displays "Booting....." on screen
---> XUB quickly appears.

So, this is better!

There must be some kind of memory initialization issue here.
* after a power cycle with a short delay, the "table of disks" is very corrupt. XUB reports a very long list of "foreign disks".
* after a power cycle with a long delay, the "table of disks" shows only FDD A and B.
* after a warm restart CNTL ALT DEL,the "table of disks" gets an incremental entry

Just looking at this issue, since the length of time of power cycle influences the outcome, doesnt this mean that there is corrupt data in RAM, that is only cleared out after a long period of no refresh?

I wish I knew more about how this BIOS works.... ;)
Click to expand...
 
regarding the issues I reported with getting XUB to boot up correctly in Z171

I am pleased to report that I have repaired XUB 602 to work with Z-171. Well, specifically I fixed the boot disk detection problem that was making boot up difficult.

Here's the short summary of the issue:

* in Z171, when booting a stock machine, the BIOS BDA entry 0040:0075, which represents # of detected HDD, is set to 0FF.
* (It also seems like it is not initialized on normal boot up, so FF might be what you get when power up)
* XUB assumes this value is correctly set by the BIOS.
* in the case of Z171, it should be set to 00 on every boot

Fix:
* in DetectDrives.asm there is a natural location to initialize the variable BDA..bHDCount which points to 0040:0075
* by initializing to 00 we correct the problem that un-initialized data is messing up the boot
* in the make file you need to add this line to the appropriate area
# Z171_HACK use to fix Z171 boot issue
* and of course, you need to add this to your specific build.

original code

mov cx, [RAMVARS.wDrvCntAndFlopCnt] ; Our count of hard disks
mov al, [es:BDA.bHDCount]
add [es:BDA.bHDCount], cl ; Add our drives to the system count
or al, 80h ; Or in hard disk flag
mov [RAMVARS.bFirstDrv], al ; Store first drive number


modified code


%ifdef Z171_HACK ; INITIALIZE .bHDCount every time
mov BYTE [es:BDA.bHDCount], 0 ; Set hard disk count to zero
%endif ; Z171_HACK

mov cx, [RAMVARS.wDrvCntAndFlopCnt] ; Our count of hard disks
mov al, [es:BDA.bHDCount]
add [es:BDA.bHDCount], cl ; Add our drives to the system count
or al, 80h ; Or in hard disk flag
mov [RAMVARS.bFirstDrv], al ; Store first drive number
 
QQ for those who understand how to compile XUB-

this line appears in the makefile for XUB-
Code: 
	; Included .inc files
	%include "AssemblyLibrary.inc"	; Assembly Library. Must be included first!

Do the routines related to AssemblyLibrary.inc have to be separately compiled? There appears to be a separate makefile specifically for Assembly_Library.

thanks,
Steve
 
Not sure if this is the correct place for this, but I'm having problems trying to use the serial disk server with my XTIDE v2 board. Initially, both sides report they are using 115.2k baud, but by passing the -v debug flag to serialsrv.ext I can see a message from the server that client is announcing 28.8k baud. No data is ever transferred. I realize there's a 4x speed multiplier on the XTIDE, but the software seems confused about what's really going on. Am I missing something basic?
 
shirsch said:
Not sure if this is the correct place for this, but I'm having problems trying to use the serial disk server with my XTIDE v2 board. Initially, both sides report they are using 115.2k baud, but by passing the -v debug flag to serdrive.exe I can see a message from the server that client is announcing 28.8k baud. No data is ever transferred. I realize there's a 4x speed multiplier on the XTIDE, but the software seems confused about what's really going on. Am I missing something basic?
Click to expand...

UPDATE: Burned by software versioning... I found a copy of serdrive.exe in a relatively recent build of XUB that seems to work fine. But, I cannot convince XUB to boot from that drive - it always chooses the primary IDE device. Once booted, the serial drive is mapped to drive D.

There are way too many out-of-date pieces of software and firmware floating around.
 
Still struggling a bit with serdrive. After losing a full day to what turned out to be a bad 16C550 UART, I have discovered that 460k baud link works only if I use a -v debug option on the server end. It simply never works without it. With -v, I get reliable connection about 80% of the time.
 
Malc said:
Never used it myself as i have no need for it but what version are you using ?, Krille posted a fixed version of serdrive here: http://www.vcfed.org/forum/showthread.php?17986-XTIDE-Universal-BIOS&p=566298&highlight=#post566298 I believe it's the latest version from r602,
Click to expand...

If anything that copy is slightly worse. I'm starting to think the PC portable I'm using just isn't fast enough to keep up with 460k baud. If I drop back to 230, it connects 100% of the time even without debug. Throughput falls from 10.7k bytes / sec to about 9.4k bytes / sec, which sort of bolsters the argument that baud rate itself is not the limiting factor. Having a 16C550 drop dead after less than a day's use is a bit irritating to boot. I swapped in an NMOS 16550 pulled from an old serial card and it seems to work fine.
 
I wonder if it's worth trying a separate serial card if you got one ?, Just to rule out problems with the serial on the xtide.
 
Malc said:
I wonder if it's worth trying a separate serial card if you got one ?, Just to rule out problems with the serial on the xtide.
Click to expand...

A good idea, but I have none capable of 460k baud besides the XTIDE. And at 230k baud it's working properly with only about 10% throughput penalty. I can live with that.
 
Hello guys, I just was trying to build the blobs under linux and it went mostly good. However, I had to fix something to make it work. Where can I submit the patch/suggestions? Thanks in advance.
 
Posting bugs in this thread is the norm, There's no where else, However updates are few and far between these days, I always use windows xp.
 
Hello,

I am unable to have my 5.25 1.2M floppy drive properly recognized with ide_xt and ide_xtp. The drive is considered by the OS as a 360K one when such a bios is present. The drive works fine with ide_tiny, but then, no CF.

My setup is:
- PC Epson Equity II (NEC V30, 640 KB RAM, one 5.25 HD floppy, no extension board)
- XT-CF Lite V4.1 (Address C800h, port 320h)
- MS-DOS 6.2
- Transcend CompactFlash Industrial CF300 128MB (TS128MCF300)
- XTIDE bios r602 and previous (r528 customized from Sergey, r588...)

Tests performed, without success:
- Many changes of address and port on the XT-CF-Lite card, flashing both ide_xt and ide_xtp accordingly to port after running auto-configure in xtidecfg.
- Build r602 on Linux with minimum DEFINES_COMMON in the makefile (progressively down to the options of DEFINES_XT_TINY). The floppy drive doesn't work as soon as MODULE_8BIT_IDE_ADVANCED is included, which is mandatory for CF support.

When the drive is wrongly recognized, the same error as Drew noticed in #528 appears (unable to format the floppy).
The functions 08h and 15h of int13 seem to be involved in floppy drives detection, so I tried calling them with debug utility. I'm not sure whether these functions are the only ones.

Code I used for calling function 15h:

xor ax, ax
mov es, ax
mov di, ax
mov ah, 15
mov dl, 00
int 13
int 3

Function 15h result with drive recognized as HD (ide_tiny in ROM or ROM disabled):
AX=0200 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=16AD ES=16AD SS=16AD CS=16AD IP=0108 NV UP EI PL NZ NA PE NC

Result with ide_xt or ide_xtp in ROM:
AX=0200 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=166E ES=166E SS=166E CS=166E IP=0109 NV UP EI NG NZ AC PE CY

3 flags are different. I understand that the carry flag here means an error occurred in the function call.

Function 08h with drive recognized as HD:
AX=0140 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=16AD ES=16AD SS=16AD CS=16AD IP=0108 NV UP EI NG NZ AC PO CY

Function 08h with drive recognized as 360K:
AX=0100 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=166E ES=166E SS=166E CS=166E IP=0108 NV UP EI NG NZ AC PO CY

AX contains 0140 when the drive is fine, 0100 when ide_xt or ide_xtp is in the ROM.

Thanks for your help!
Freddy
 
You must log in or register to reply here.
Back
Top