• Please review our updated Terms and Rules here

HeadStart Explorer and XT-IDE v1.0

Denniske1976 said:
OK, been able to flash the BIOS at address CC00 with success. After a reboot still no menu but I can see the BIOS again with debug (d CC00:0).

Any ideas? I should think a successful flash at CC00 should mean the BIOS should be available and called at boot?
Click to expand...

That's good news, but sadly not the solution for you. XTIDECFG verified the ROM contents after it was written, so the odds of another corrupt rom here are slim to none. For whatever reason (I keep coming back to ROM timing) your PC is unhappy with the ROM itself. This one is stumping me for sure.

Ideally you would find another machine to try the XTIDE card in. That would eliminate one more variable.

Another experiment would be to take the ROM out of the RLL controller and put it in the XTIDE. (unless the pin count doesn't match) A hardware guy can probably help here, but I'd think this would be harmless. This would tell us that *a* ROM is readable out of the XTIDE.
 
Denniske1976 said:
Removed the JP1 jumper, and put it back on while the machine was on (to erase the ROM??).
Click to expand...
You only need to do that if the contents of the XT-IDE ROM are stopping the computer from booting.

Denniske1976 said:
And at address E000 I find something with "ROMDOS 1.0" in it's description... probably the DOS 3.31 ROM?
Click to expand...
Yes.

Denniske1976 said:
So this probably interferes with flashing?
Click to expand...
I can't see how.
The only implication I can think of is that an XT-IDE starting address of E0000 won't work (due to address conflict).

Denniske1976 said:
Any ideas? I should think a successful flash at CC00 should mean the BIOS should be available
Click to expand...
Depends how the verification is done.
A example. A verification after each block write is susceptible to the following problem.

Step 1. Write "ABCDE" to block 0
Step 2. "ABCDE" read back from block 0 - verification good
Step 3. Write "FGHIJ" to block 1
Step 4. "FGHIJ" read back from block 1 - verification good
Step 5. Write "LMNOP" to block 2
Step 6. "LMNOP" read back from block 2 - verification good
Step 7. Write "QRSTU" to block 3
Step 8. "QRSTU" read back from block 3 - verification good

Verified okay, but it turns out that there is an addressing error - bit 2 stuck low.
So when the data is viewed, what is seen is

Read of block 0: "LMNOP" <---- Bad ("ABCDE" initially written but later overwritten by step 5)
Read of block 1: "QRSTU" <---- Bad ("FGHIJ" initially written but later overwritten by step 7)
Read of block 2: "LMNOP" <---- A read of block 2 is actually reading block 0
Read of block 3: "QRSTU" <---- A read of block 3 is actually reading block 1

hargle said:
XTIDECFG verified the ROM contents after it was written,
Click to expand...
Is that verification done after each block write, or done after the entire file is written?

Denniske1976 said:
and called at boot?
Click to expand...
That's a totally separate issue to ROM content.
I know that the ST11 worked, and that certainly suggests that a ROM at C8000 is called.
You could 'ram that home' by the process I posted at post #34
 
modem7 said:
Is that verification done after each block write, or done after the entire file is written?
Click to expand...

Page Size is set to 1, that's the one verifying after each block is written? I'll have a go with flashing the files of post #34, didn't think it would help since I never see any menu coming up. Could be suppressed by the "HeadStart Explorer" logo of course, because when I switch the computer on/off/on I can see a very familiar "Award 8088/86 BIOS (C) 1988 HeadStart Technologies" on screen briefly before the "HeadStart Explorer" logo comes up. So I guess this suppresses all the on-screen information (something the HeadStart LX-40 doesn't do btw).

So with this, I think that if I flash the file displaying a 3 and pausing I should end up with the HeadStart logo staying on screen... I'll try this tonight when I get home from work.
 
Denniske1976 said:
Page Size is set to 1, that's the one verifying after each block is written?
Click to expand...
the eeprom is byte writable, in other words, you can update 1 single byte at a time, which is fairly unique in all my experience with flash and eeproms. (typically you have to erase a "page" of a certain size, update the data in that page, then move onto the next one) These eeproms work more like DRAM.

I don't know exactly how tomi's xtidecfg program does its job with regard to data validation after writing, but I have a very hard time believing something like a stuck bit would not be caught somewhere along the line.

Could be suppressed by the "HeadStart Explorer" logo of course, because when I switch the computer on/off/on I can see a very familiar "Award 8088/86 BIOS (C) 1988 HeadStart Technologies" on screen briefly before the "HeadStart Explorer" logo comes up.
Click to expand...
this is interesting. is there a way to turn off that logo/feature? is it possible that the xtide rom has been called all along, but this logo is keeping any sign-on messages from showing up? Does the RLL card display any sign-on messages?

this is a bit of a long shot, but what if:
1) boot logo is keeping sign-on messages off the screen, but the XTIDE is actually running just fine.
2) an IO conflict is keeping the XTIDE from detecting a hard drive
3) the boot menu eventually times out and boots to the A: drive. There would be a ~20 second delay before it boots.
 
Last edited:
hargle said:
this is interesting. is there a way to turn off that logo/feature? is it possible that the xtide rom has been called all along, but this logo is keeping any sign-on messages from showing up? Does the RLL card display any sign-on messages?

this is a bit of a long shot, but what if:
1) boot logo is keeping sign-on messages off the screen, but the XTIDE is actually running just fine.
2) an IO conflict is keeping the XTIDE from detecting a hard drive
3) the boot menu eventually times out and boots to the A: drive. There would be a ~20 second delay before it boots.
Click to expand...

Nope, I have no idea how to turn it off... no keystroke works (ESC, CTRL+Break, etc).

Also, I don't think I have anywhere near a 20 second delay at all. That HeadStart logo is gone in about 5 seconds and then it either boots directly to DOS ROM 3.31 or, if present, a boot floppy. So I guess the the XTIDE card isn't called. I'm going to try and see if I can remove the DOS ROM from the mainboard, to see if that makes a difference. It would either end up that the ROM fits (if the 8K can't be loaded completely) or it will just boot to floppy (or without a floppy give me a "no boot disk" error).

THe ST11 shows nothing on screen, the card has two (I think) BIOS chips as can be seen in the pictures in my previous posts, and just two undocumented jumpers, can't find what they do. But somehow the card and the attached ST-238R work out of the box, it boots without a hassle from the HDD. So of course I could just put in the ST11 and try to find a 3.5" drive that works off that controller, but that would just "dismiss" the whole point of trying to get the XT-IDE card to work so the previous owner can use it with any compact flash card or modern harddisk... we'd still be dependant from what's out there as working "80ies" harddisks in RLL and 3.5" format (and then there's still the heat problem in the drive bay of the Explorer, so any other harddisk installed would also have a limited run because of this).
 
Hmm, revising my longshot idea.
What if the ROM is being called and is working (but obscured by the logo) and then since this machine has built-in DOS on ROM, the mainboard BIOS isn't calling (or letting the XTIDE BIOS hook) INT 19h, which is where the boot menu would be coming up. Thus no timeout in a menu that can't be seen anyway.

I think modem7's lockup BIOS might be helpful to determine this. If the machine is calling ROMs, his ROM will hang the machine forever.
 
hargle said:
If the machine is calling ROMs, his ROM will hang the machine forever.
Click to expand...

Yep.... :-) Indeed, flashed the S file into the ROM of the card (and that took longer than flashing the XT-IDE BIOS 1.1.5 actually, also very weird). And after reboot the HeadStart Explorer logo screen just stayed there.... for ages until I switched it off. I have the case and mainboard open now, There's 3 socketed IC's (next to the CPU/NPU of course), one is labeled Award XT BIOS with a silver sticker, the other two are not labeled with a sticker, just printer EX1701A1 and EX1701A2. Pop these two out to see if the DOS ROM is devided over two EEPROMs??
 
What about if the ROM is being called (seems likely) but no DEVICE is detected. Can I ask what is connected to the XTIDE controller?
 
Well, took those two chips out (labeled EX107A1 and EX107A2), no difference. Or I mean, it doesn't go to DOS anymore if no floppy is in the drive, it just gives a blank screen with blinking cursor. So I guess I got DOS out (although debug still gives me some ROM DOS V1.0 at address E000).

I flashed the BIOS 1.1.5 again and it took way longer now than before, before it took about 3 seconds and now about 25-35 seconds. It says EEPROM flashing succesful and reboots... but FDISK says "no fixed disk present" :-( With debug I can see the BIOS at 300h/CC00 (that's where I flashed it too). I've tried a Compact Flash card (2GB) on some adapter, and I also tried an IBM DALA-3540 IDE drive. Both are not detected and of course the XT-IDE menu isn't showing (probably because there's that Explorer logo masking it).
 
ok, this is some goodish news. the HS machine is actually calling the ROM on the XTIDE. We don't know why it can't display something to the screen, but this proves that the the host machine is doing what it should be doing.

Now the problem is why there are no hard drives detected. Most likely candidate is an IO space conflict. are you sure the dipswitches for IO space have not been moved from their default location of 300h? Next we can use debug to see if something else is at 300h.

remove the XTIDE completely
boot to DOS, start debug
-i 300
xx
-i 301
xx
-i 302
xx
...etc up to...
-i 307
xx

the xx values returned can hopefully tell us if something is responding there or not. Ideally the returned values would all be FF, but this machine is weird enough that it might be some other value. Ideally all 8 values will be the same. if they are all the same, then it is likely that that IO space is unused.
 
I'd be suspicious of those two drives. The IBM is ATA-2, and all the drives that gave me problems with the DP XTIDE varieties were ATA-2. The CF card may well not work because of the CSEL error on the XTIDE board.
 
I'll have a go at this tonight when I get home from work... d*mn job takes up most of my spare time :-( I haven't moved the jumpers for base addy yet, dunno what the previous owner did though. He's also been tinkering around with the settings I guess.
 
The BIOS needs to be reconfigured (and hence re-flashed) to change the port addresses.
 
OK, just found the JP settings at stason.org (stupid me, that I hadn't thought of that)...

Since there are two JP jumpers and both are closed, according to stason.org (ST11M or R controller) the controller is at O/I Port 32C-32Fh and BIOS address E000h (XT only). So I guess it would be best to use these settings and reflash the BIOS in the XT-IDE card?
 
pearce_jj said:
The BIOS needs to be reconfigured (and hence re-flashed) to change the port addresses.
Click to expand...
Expanding on that, changing the I/O address range is a two step thing:

1. Change switches for new I/O address range.
2. Flash XT-IDE with BIOS code that has been reconfigured to suit the new I/O address range.

Regarding step 2, there is an area within IDECFG where the I/O address range is specified.
There are two settings there.
In the photo below, you can see that IDECFG will use the range that starts at 300h - made up of two settings: "0300h" and "0308h" (0300 + 8).

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