XTIDE Universal BIOS v2.0.0 beta testing thread

[Malc]

This smacks of CF IDE adapter compatibility to me, grab one of these and retest - I've had 100% success with these adapters used with an IDE extension cable.

It does to me in a way, It's pot luck with those cheap chinese adapters, They either don't work or work and die after some use, The one you linked to, I've thrown more of those in the bin than any other but like i said it's pot luck, I've found the most reliable of the cheapo adapters are the ones that PePe-fr is using, I have a few of those and had no problems, I've found the adapters from E-Engines are pretty good, I have another i've had for several years but can't think of the manufaturer but they were a tad more expensive.

 

[dJOS]

It does to me in a way, It's pot luck with those cheap chinese adapters, They either don't work or work and die after some use, The one you linked to, I've thrown more of those in the bin than any other but like i said it's pot luck, I've found the most reliable of the cheapo adapters are the ones that PePe-fr is using, I have a few of those and had no problems, I've found the adapters from E-Engines are pretty good, I have another i've had for several years but can't think of the manufaturer but they were a tad more expensive.

Bizarre, I've bought a dozen of those and had zero failures, they also work with even the cheapest Chinese CF cards.

 

[Malc]

Bizarre, I've bought a dozen of those and had zero failures, they also work with even the cheapest Chinese CF cards.

I don't think i've had a years use out of any of the cheap chinese adapters and i've tried a variety of them over the years, The exception being the cheap ones that are accessible from the rear and a couple of others i have which were more expensive, I still have a couple of the rear accessible ones left and now have a use for them so last week i ordered 6 more just to keep for future use, If i want an internal and external i just remove the bracket and use those plastic standoffs with the sticky tape on the bottom and secure the adapter some place internally, I have also used a variety of CF cards over the years from well known manufactures to cheap chinese no-name CF cards and all worked well with them, From the smallest up to 4Gb CF cards.

 

[PePe-fr]

Hi,

I thought of a gadget which would be very very fun on xtide boards :
Would it be possible to use the activity LED signal to generate sound to simulate hard drive reading/writing ?

I was thinking out loud but... that would be fun.

 

[Malc]

Something along those lines has been discussed before, Simulating the sound of the chirps / disk read / write, I think it'll be a lot of work for little / no gain, Personally as long as i can see an LED i'm happy, I like the silence.

 

[PePe-fr]

Well, there seems to be no problem anywhere.

The strange thing is that 1 card works out of 3. I managed to make a 128Mb Sandisk work perfectly, and still have the same FAT corruption for every write attempt I do on the two other ones (Sandisk 32Gb and Transcend 256Mb).

At this point, I will consider that there is some kind of incompatibility between my particular machine (it's a clone... a very undocumented one) and larger than 128Mb storages. The seller of the IDE board was able to test it with large cards, and I managed to partition, format and copy files on my biggest card using a Pentium 1.

I'll consider the case as solved for now, sell my 2 big cards and buy a second Sandisk 128Mb just in case !

Thanks for your help, this allowed me to conduct good tests and understand how all this works as I'm a newbie with retro-computing even if I used this particular XT for years before phasing it out !

Hi,

Just an update : at this point, I still can't make any use of the 256Mb card (I sold the 32Gb) on this particular XT, but I was able to make it work flawlessly on a more modern machine using the same CF adapter.

I bought another Sandisk 128Mb CF card, and it worked perfectly on my XT (I made the partition from the XT, thing I hadn't done with the first card due to the lack of DOS floppy with a partition editor on it).

I guess that there might be an issue with this particular XT clone motherboard/BIOS, creating a conflict which prevents writing on most CF cards.

 

[Krille]

I've just added support for the Silicon Valley Computer ADP50L controller. Anyone up for testing? See here for more info.

Thanks to Great Hierophant for providing the original BIOS!

More than five and a half years later, the Silicon Valley Computer ADP50L IDE controller has finally been confirmed to work with XTIDE Universal BIOS!

I'm very grateful to forum member gepooljr for doing the testing! Thank you Geoff!

The testing was done using a custom build I made specifically for this purpose as the controller BIOS is limited to a maximum size of 6 kilobytes (when using 8 KByte ROMs at least - the controller also supports 32 KByte ROMs but it remains to be seen how exactly that works).

I've attached this build in case anyone else would like to try it.

View attachment XUB_r600+_ADP50L.zip

The zip-file contains two BIOS files, adp50l.086 for use with 8088/8086 processors, and adp50l.186 for NEC V20/V30 processors. They must be configured with XTIDECFG.COM before programming/flashing.

For future reference, these are the build options;

MODULE_STRINGS_COMPRESSED
MODULE_8BIT_IDE
MODULE_8BIT_IDE_ADVANCED
MODULE_HOTKEYS
MODULE_EBIOS
MODULE_POWER_MANAGEMENT
MODULE_COMPATIBLE_TABLES
ELIMINATE_CGA_SNOW
RESERVE_DIAGNOSTIC_CYLINDER
NO_ATAID_VALIDATION
CLD_NEEDED

And for the adp50l.186 file there's also this;

USE_186

The Boot Menu and the Virtual Serial Drive support is not included, but aside from that, this is everything you need in an XT build of the XUB.

 

[Krille]

I am looking for a volunteer for testing of a new transfer mode for XT-IDE cards (rev 2, 3 and 4 but also rev 1 cards with the Chuck mod).

This new transfer mode is an attempt at improving transfer speeds (reads) specifically on Olivetti M24 and its derivatives and is not meant for any other type of machine. However, for testing purposes any XT-class machine should suffice but ideally a volunteer for testing this should have an XT-IDE card as mentioned above installed in any of the following machines;

Olivetti M24
AT&T PC6300
Xerox 6060
Logabax Persona 1600

If you're interested in trying this (even if you don't have any of the above machines) let me know via PM and don't forget to include your e-mail address. I will send you a zip-file containing the latest XT and XT+ builds of XUB for testing (which one to use depends on the CPU in your machine).

The XT-IDE card must be configured for High Speed mode on rev 2+ cards or have the Chuck mod done if it's a rev 1 card. The BIOS must be configured manually to use the "XTIDE rev 2 (Olivetti M24)" device type (Auto Configure doesn't work with this just yet). See image;


Aside from testing that it works I would also be grateful for any benchmark results comparing the performance of this new transfer mode with the old "Compatibility mode"/XT-IDE rev 1 device type (the only other option for Olivetti M24 owners with XT-IDE cards). It would also be interesting to see how much slower this new transfer mode is compared with the regular High Speed mode/XT-IDE rev 2 device type.

Anyone interested in the technical details can read more here.

 

[Trixter]

I have 2 working 6300s, parts to make two more, as well as a Xerox 6060 I haven't set up yet, so I'm the most likely candidate for testing. The only drawback, in the short term, is that I don't have a rev 2/3/4 card. Most of my cards are ADP50s, Rev 1 cards, or suddenlymatt cards. So, I've ordered an assembled Rev 4 card with the slot 8 mod, and hopefully it will arrive relatively soon.

For a proper test, I'd like a recommendation on what configuration I should load for the "normal" test, so that we have metric baselines to compare with the new code. I'm assuming "8-bit mode", and jj_pearce's DISKTEST is an acceptable benchmarking and testing program.

 

[glitch]

Do you want me to loan you some earlier rev boards? I can ship them with the rev 4 order. I'd test myself but I don't have any of the listed machines.

 

[Trixter]

That's a better question to ask of Krille. Assuming the rev 2/3/4 boards all have the low and high data registers one byte apart, I don't see how rev 2/3 would be any different, but I might be missing something.

 

[Malc]

...For a proper test, I'd like a recommendation on what configuration I should load for the "normal" test, so that we have metric baselines to compare with the new code. I'm assuming "8-bit mode", and jj_pearce's DISKTEST is an acceptable benchmarking and testing program.

I used DISKTEST and CheckIt 3 when i tested XUB v1.1.5 - r591 > r600, Not sure if they are the best to use though, I have none of the listed systems either.

 

[Krille]

I have 2 working 6300s, parts to make two more, as well as a Xerox 6060 I haven't set up yet, so I'm the most likely candidate for testing. The only drawback, in the short term, is that I don't have a rev 2/3/4 card. Most of my cards are ADP50s, Rev 1 cards, or suddenlymatt cards. So, I've ordered an assembled Rev 4 card with the slot 8 mod, and hopefully it will arrive relatively soon.

You know, all four of those controllers are supported by XUB and as it happens XUB supports up to four controllers in the same machine. *HINT* *HINT*

For a proper test, I'd like a recommendation on what configuration I should load for the "normal" test, so that we have metric baselines to compare with the new code. I'm assuming "8-bit mode", and jj_pearce's DISKTEST is an acceptable benchmarking and testing program.

The "normal" test would be with the card configured for Compatibility mode and the IDE controller device type set to "XTIDE rev 1" in XTIDECFG. Use the same BIOS version in all tests.

Do you want me to loan you some earlier rev boards? I can ship them with the rev 4 order. I'd test myself but I don't have any of the listed machines.

The basic functionality can probably be tested on any machine - I don't expect any weirdness from the listed machines. The benchmark results on the other hand are going to be quite a bit more interesting as the listed machines are the intended target, and they have 8086 or V30 processors unlike almost all other XT-class machines, so benchmark results from an 8088 machine is not really going to be relevant. That said, I welcome anyone willing to test or benchmark this.

That's a better question to ask of Krille. Assuming the rev 2/3/4 boards all have the low and high data registers one byte apart, I don't see how rev 2/3 would be any different, but I might be missing something.

That's correct. If it works on one revision then it should work on all of them.

I used DISKTEST and CheckIt 3 when i tested XUB v1.1.5 - r591 > r600, Not sure if they are the best to use though, I have none of the listed systems either.

Yeah, James' DISKTEST and CheckIt are good candidates for benchmarking. Another option is mbbrutman's IOTEST.

 

[Trixter]

You know, all four of those controllers are supported by XUB and as it happens XUB supports up to four controllers in the same machine. *HINT* *HINT*

That's... an interesting prospect. Assuming two 8GB CFs per cable, that would be 64GB in a single system -- but DOS would only give me 24 drive letters, so I'd only be able to use 48GB of it. I'll pass

The basic functionality can probably be tested on any machine - I don't expect any weirdness from the listed machines. The benchmark results on the other hand are going to be quite a bit more interesting as the listed machines are the intended target, and they have 8086 or V30 processors unlike almost all other XT-class machines, so benchmark results from an 8088 machine is not really going to be relevant. That said, I welcome anyone willing to test or benchmark this.

Just for you, I'll test with and without an NEC V20. I usually leave the NEC V20 out, since it breaks Geoworks Ensemble, and 640x400 Geoworks is a sight to behold on these systems.

Here's another thought: Do the M24/variants ALWAYS swaps word order, or SOMETIMES swap word order? If the former, then this might be viable:

	in	ax, dx			; Load word from port
	stosw				; Store swapped-order word to [ES:DI] in correct order

 

[Krille]

That's... an interesting prospect. Assuming two 8GB CFs per cable, that would be 64GB in a single system -- but DOS would only give me 24 drive letters, so I'd only be able to use 48GB of it. I'll pass

Too bad. I would have loved to see a youtube video of such a ridiculously tricked out XT machine. :D

Just for you, I'll test with and without an NEC V20. I usually leave the NEC V20 out, since it breaks Geoworks Ensemble, and 640x400 Geoworks is a sight to behold on these systems.

I'm curious, how does the V30 break Geoworks Ensemble? Did they make use of Intel's undocumented instructions? Maybe it can be patched or would it be too much work?

Here's another thought: Do the M24/variants ALWAYS swaps word order, or SOMETIMES swap word order? If the former, then this might be viable:

	in	ax, dx			; Load word from port
	stosw				; Store swapped-order word to [ES:DI] in correct order

There's more to it than just byte swapping, you might recall this thread?

 

[Trixter]

Too bad. I would have loved to see a youtube video of such a ridiculously tricked out XT machine. :D

That strikes a nerve! Okay, I might consider it. But the same thing can be achieved with just a single XT-IDE and a 64G or higher drive.

I'm curious, how does the V30 break Geoworks Ensemble? Did they make use of Intel's undocumented instructions? Maybe it can be patched or would it be too much work?

It hangs on startup, and I never bothered to troubleshoot it further. I was hoping the recent open source release of geoworks would shed some light but I haven't had time to look into it. I'm guessing it's a faulty CPU detection routine.

There's more to it than just byte swapping, you might recall this thread?

I do, but I'd forgotten a byte is inserted into the stream. I thought it was just an endian problem.

 

[Trixter]

(15 minutes is way too short a time for editing posts. Admins, please lengthen.)
Looking at the geoworks source code at bluewayse/pcgeos, CPU detect looks ok (it's in SysInit.asm) but there seems to be a disconnect between detecting an 80186 and later in the code assuming there is only an 8086 or 80286. I'd really have to trace it to see.

 

[JohnElliott]

That's... an interesting prospect. Assuming two 8GB CFs per cable, that would be 64GB in a single system -- but DOS would only give me 24 drive letters, so I'd only be able to use 48GB of it. I'll pass

According to devdriv.txt in the source release, MSDOS 2 supports 63 drives:

The theoretical limit is 63 (2^6 - 1), but it should be noted that after 26 the drive letters get a little strange (like ] \ and ^)

Must admit, I've never tried it.

 

[Trixter]

I'm not sure how this would work in practice, because the characters mentioned when it gets "a little strange" are just the ASCII characters beyond upper-case letters. Past those, we get into lower-case letters, but since DOS treats lower-case letters as upper-case, you wouldn't be able to actually access them. At a bare minimum, COMMAND.COM and FDISK would have to be patched to allow any ascii character as a letter, and traditional DOS programs would likely not be able to access those drives either.

Such an experiment is only useful if the storage is actually accessible by programs so I still posit that 24 would be the practical limit. I suppose you could forcefully override A: and B: as well, but that almost seems like cutting off the nose to spite the face.

 

[pearce_jj]

I've wondered for some time why databases from the time didn't write to disk partitions directly, it would have been a lot faster with such tiny cpu and ram. Or use FAT12 at least.