• Please review our updated Terms and Rules here

Device driver as a replacement for XTIDE BIOS?

J

Jimbob81

New Member
Joined
Jul 6, 2023
Messages
8
Hello,

Has built the XTIDE BIOS as a device driver or standalone executable for use in the development stage?

I have a sum what PC compatible computer (Sanyo MBC 550) that cannot and will not search for BIOS extensions such as the XTIDE BIOS due to the nature of how it boots (loads a software BIOS from boot disc at startup).
This leaves me the only option of using device drivers or application programs to access extra hardware.
So far I have had good success with a range of different hardware in this "marginal clone" and now I have my sights set on trying an XTIDE board.

The rudimentary testing I have done so far is checking access to the hardware port required by the XTIDE board and scanning for the ROM BIOS in the memory map - success so far.
So before I try and reinvent work that may have already been done, I thought I'd put the question out there...

Thanks
Steve.
 
It shouldn't be too difficult taking an older XTIDE source without the bells and whistles and turning it into a device driver. Of course, this means that you'll have to always boot from floppy.
If might also be possible to merge the code into the MBC 550 loadable BIOS, but I don't know if any source code exists for that BIOS, so it might be difficult.

A less ambitious move might be to use the Gotek floppy emulator.
 
modem7 said:
Hello Steve. Welcome to these forums.


Is optromloader of use to you? See [here].
Click to expand...
Thank you for the welcome and your suggestion of using 'optromloader'. It was a very good thought.

I've experimented using optromloader with another XT clone and works well bringing up XTIDE BIOS on that system. The issue is that 1.) It requires a call to INT19h which doesn't exist because the software BIOS hasn't been loaded on the Sanyo yet and 2.) If I was able to re-write optromloader to forcefully load a XTIDE BIOS image, XTIDE re-writes INT13h routines (or the jump location) which also haven't been loaded into the Sanyo yet... If DOS was to load after this step, It would write over the new XTIDE INT13h call. The process of bootstrapping the Sanyo from floppy first must take place as per usual hence using a device driver or standalone program to install XTIDE in the correct locations.
 
Chuck(G) said:
It shouldn't be too difficult taking an older XTIDE source without the bells and whistles and turning it into a device driver. Of course, this means that you'll have to always boot from floppy.
If might also be possible to merge the code into the MBC 550 loadable BIOS, but I don't know if any source code exists for that BIOS, so it might be difficult.

A less ambitious move might be to use the Gotek floppy emulator.
Click to expand...
Thanks for your suggestions.

Yes, my plan is to modify version 1.1.1 (as I've used it before with success on other PC's and is a smaller source package) as you have suggested without the bells and whistles. I just wanted to check if someone may have done this already...
I have the Sanyo bootloader source and a somewhat reverse engineered MSDOS 2.11 IO.SYS BIOS but haven't found a way to add code without a boot failure (must be something i'm missing - checksum maybe).
I'm using a Gotek as my main boot drive already - makes life so much easier but lacks the storage space like a hdd or compact flash. I'm content with being forced to boot from a floppy (gotek image) for this PC provided I can access a larger storage medium once booted.
 
Jimbob81 said:
Has built the XTIDE BIOS as a device driver or standalone executable for use in the development stage?
Click to expand...
Darn, a grammar error in my first post and I can't edit it. What a nob 🤭

Correction:
Has anyone built the XTIDE BIOS as a device driver or standalone executable for use in the development stage?
 
Jimbob81 said:
Correction:
Has anyone built the XTIDE BIOS as a device driver or standalone executable for use in the development stage?
Click to expand...
:) In this day and age, should that be, "Has anyone, or any AI engine, built the XTIDE BIOS as a device driver or standalone executable for use in the development stage?"
 
A follow up on this thread...

After seeing a post from a forum member on another thread suggesting calling extension ROMs with a far jump (after correctly setting registers), I decided to write a small program to do just this and call the XTIDE BIOS ROM. Actually the program scans the extension ROM area and far jumps to the first entry point it finds. If it exits cleanly from the ROM it will search for the next ROM and repeat...

So this works for booting XTIDE but up to a point. The system crashes after it has detected the hdd's or CF cards etc and around calling DOS to bootstrap itself.
My assumption is that because DOS is already loaded, I'm crashing the system by loading it on top of itself again.
This (in my case) isn't an issue as I don't want to boot drives but just have access to the storage medium via DOS (INT 13h calls) which means I need to focus on a custom program which installs XTIDE BIOS functionality into DOS (aka device driver) instead of using the extension ROM.

So what I've learnt trawling through XTIDE BIOS source code v1.1.0 so far (possibly incorrect ;)):
On computer startup the extension BIOS is loaded as two stages.​
The first stage finds the extension ROM, installs the new INT 13h + INT 40h routines for improved hdd support and installs a new INT 18 + INT 19h boot routines suitable for calling XTIDE then returns to the BIOS startup sequence.​
The second stage is a called once the BIOS startup sequence is finished with a far jump to the new INT 19h routine that XTIDE installed.​
==> XTIDE then displays its sign on banner, location address in ROM etc, initializes some stuff/itself and searches for installed disks while also checking for keyboard input... last is a jump to the boot sector of the selected boot media.​

There are a few things in the extension ROM code that make it not suitable to compile as a COM file and run it as is for my scenario... The second stage calling, late hdd detection(prob not really an issue), boot menu selection and jumping to OS boot sector. So it's going to be a re-write/re-structure. Good part is I have a working source that is assembling correctly with all code removed not related to an 8088 and minor tweaks to XTIDE hardware variables used in my system (became constants). Time to reinvent the wheel.

One interesting note is there is a reference to an include file called "prntdos.asm" which I quote the source "; Include to use DOS printing functions" but this is impossible until DOS is loaded so maybe there is a version of the code for development. This file isn't included with the source copy I have so I can only speculate what it contains. All screen printing is done with BIOS calls, in fact there is quite a library of screen functionality available to use (an overkill in my case).
 
Back when I had my 64K 5150, I wanted to add a hard disk. I picked up a 4MB Shugart SA1000 and a WD1001 disk controller and cobbled up an interface card. It was accessed via PCDOS 2.0 device driver. So it can be done, but you have to take into consideration your system's peculiarities.
 
This isn't exactly what you're looking for @Jimbob81, but there might be some helpful bits for you. There's a shell to an empty device driver for openwatcom here: https://github.com/eduardocasino/dos-device-driver. I cobled together some code that @Chuck(G) (thank-you!) had posted a while ago for accessing an SD card over a parallel port with that openwatcom device driver shell. I then ported the parallel port code to work with the 6522 inside a Victor 9000 to create a block device driver for the Victor's parallel port. You can see my code here: https://github.com/pauldevine/victor9k-sd-device-driver

While it's not anything related to xtide it does have all the device driver bits working. Though the Victor 9000 is not particularly IBM compatible so I made a bunch of adjustments to match the DOS version that it runs. Some of the calls have slight adjustments to a word here instead of a byte there.

​

 
Another follow up to this thread...
I have had some success writing a standalone application to call and initiate the XTIDE ROM from the DOS command line. XTIDE initializes, installs the new INT13h driver and detects the hard drives/CF cards.
Down side is something must be overwriting a DOS location. Working from the A:\ drive, on program exit I get a "Sector not found error. Abort Retry Fail". I'm then stuck in an endless loop... It will not 'Fail' out and select another drive.
Things I've tried so far:​
Reset the disk controller (Int 13h) - no change​
Reset disk (flush buffers) (Int 21h) - no change​
Select disk and check disks still detected (Int 21h) - no change but correct number of disks detected​
More step by step debugging is required! Thinking as I was writing what I've done above, I can see I'm looking at the error wrong. Think I've overwritten the call location of my application...

For this application to work, XTIDE needs to be configured as early initialize and simple menu option.
Also the extension ROM cannot be called by the BIOS on boot so I change the 55 AA signature at the start of the ROM to something else like 00 AA.
At the moment all testing is done on a 8088 XT class computer and in Mame emulation. I've focused on V1.1.0 but other versions should work - I haven't needed to customize the ROM yet.
​
 
You must log in or register to reply here.
Back
Top