Well, some good news, I was finally able to get X-Men Children of the Atom working with the UNIVBE.DRV file that @llm linked to above (using 53a version from https://www.dosdays.co.uk/media/drivers/graph … cs/modified.zip ), but I found out that what was ultimately stopping me again was the issue with the CD drive access failing to read properly and causing crashing (likely because it was trying to play CD audio).

My suspicion is that it is the same issue as I've been having: Mounting of certain CD images crashes applications upon disc access, likely related to the IDE Controllers running in Compatibility Mode. It continues to be a nasty thorn in my side, alas. Simply not mounting any CD image (with NO-CD crack) allows it to play normally.

Anyways, for XMEN COTA I believe it was a few things together, the univbe.drv file as well as a larger array of resolutions that I added into the vbeplus config file (attached below), as well as using the NO-CD crack and *NOT* mounting any image. For XMEN COTA, I was using the 8MB installed version /w crack, and (inside the xmen.bat) running vbeplus before xmenpc (without the -U option for no univbe).

Going to go back to Flight Unlimited and see what other things I can dig up over there.

So with Flight Unlimited, I went back to it, and found it uses SDD 5.1a. So I again put back in the modified UniVBE driver for closer testing - it shows the intro screens but doesn't progress to the weird 3d main menu they've got going on (in fact it just hangs and then resets the entire weeCee after a minute - this tends to be the standard behavior of most things I've tried, if not just a direct crash back to DOS). The same result happens when you try to run it using the +nounivbe command line option for not using UniVBE (which is talked about in the FU readme). Running NoUniVBE beforehand didn't help much either, as it caused it to immediately crash instead of hang (an improvement - at least it didn't reset the weeCee).

However, I noticed that FU has a fun little batch file, video.bat, that runs"uvconifg.exe -gen -p ." off the CD. So for kicks I try just running uvconfig normally (which opens a little menu screen), selecting the default search return options it gives me for TSeng Labs "ET4000/W32 unknown revision" 2MB 8bDAC (which has worked in a number of other univbe/univesa configs I've been through already) along with checking "Disable VBE 2.0 extensions" and tried that driver. This driver at least allowed me to play more of the game in a way, but it creates massive screen distortions and screen overlap effects in the main menu, with the main game playing just as badly. At least the preflight and flight recorder screens worked using this mode (an improvement over the SiSVBE option).

If I simply try just running "uvconifg.exe -gen -p ." (as video.bat does), that just drops me right back to DOS after creating the new driver file (no menu or anything). Running FU using this driver just leads me to a blank screen, but you can clearly hear the main menu sound effects playing (and interaction sound effects as you move your mouse around). It is at least not hanging or crashing before going into the main menu, like it does normally, but it's a completely blank screen (I even tried connecting the VGA cord directly into the monitor instead of through the OSSC, but it's still just a blank screen).

As I try to also continue messing around with other uvconfig options (including forcing various different chipsets) it's about the same, with most uvconfigs just crashing FU outright right after intro screens. A few other TSeng Labs options do about the same with the blank screen where you can still hear the main menu running and such. No configs that just /work/.

At least running Flight Unlimited with the SiSVBE beforehand allows you to play the game, it just garbles up the intro scenes and the preflight and flight recorder screens. The main game plays flawlessly tho. This is still the best option I have found, but it is of course lackluster.

At least FU has cheeky dev photos like this:

Running NoUniVBE beforehand didn't help much either, as it caused it to immediately crash instead of hang (an improvement - at least it didn't reset the weeCee).

NoUniVBE is execlusivly for 5.3a

did you tried the 6bitdac tool?

6bitdac simply let the VESA bios report that it is not capable of switching to an 8bit DAC. Why would you want to do this, since this limits the amount of colors? Some games like Flight Unlimited I from Looking Glass have buggy support for the 8bit DAC.

Re: VESA Fix Utility Listing (for old video cards)

llm wrote on 2022-04-21, 15:52:

did you tried the 6bitdac tool?

I did, as well as a variety of TSeng Labs VESA drivers and every other trick I could think of. No difference when running 6bitdac ahead of time.

Edit: Yeah, I'm ready to move on from Flight Unlimited. First game I have found to have problems running fully, but it is also known as being a bit of a buggy early-VESA2 game. For any crazy smart DOS hackers out there who want a challenge, there ya go.

In other news, I finished my extra units and have the first one up on eBay (no link but easy enough to find). If any of you wanted to buy one, now is the time. Next month I have to start looking for new work, so this has been the summation of my time off. :3

The first weeCee is sold and has left the building - and I'm kind of in shock at how much that one sold for.

Anyways, the last two are going up on eBay next Monday, May 2nd, at noon PDT. Watch out for them if you'd like one! This time as Buy-Now, with one lower in price than the other, to help out one lucky person who really wants one but can't afford the full cost. Tell your friends!

Last two weeCee's sold not within 2 minutes of them going up for sale. Really crazy how fast they went! I can't even describe how happy it makes me to be able to sell the extra ones off. I am thinking about maybe doing another batch of them.

Does anyone - looking maybe at you @640K!enough ?? (maybe? please?) - want to help come take a look at the CD drive lockup issue that seems to be driver related (compatibility mode 16-bit IDE->MicroSD Win98 drivers)? If interested, I can send a free weeCee (for keeps) and be pushed to make another batch. But I'd need a serious commitment to helping out, as they can be a bit costly.

Outside of that, I did hear back from rasteri concerning the addition of any 3D hardware -> the basic reality is that only the ISA bus (not PCI bus) is being exposed by the SOM (an entire pin header and a quarter more is just for the ISA bus lines alone), and the way it would need RAM access (amongst other things) would make for a ton of extra room needed for a lot of extra traces, and the weeCee just doesn't have enough board space. For any 3D hardware to work, it would almost have to come from ICOP itself. So sorry to ruin people's day on that - on the flip side, maybe a software GL solution could be made to run? Might be able to get a few early Windows games running using such on the 800MHz chip (*cough* 300 pentium *cough*), alas.

That being said, rasteri did mention he was looking at some other SOMs and designs and maybe his partnership with ICOP turns out something really cool for all of us, but nothing soon is expected. So the weeCee is likely to stay in its current state, minus anyone who is interested in taking the torch and, maybe at most, adding in some extra pin headers for some misc extra stuff (battery, power/hdd LED, maybe speaker, maybe SPI/I2C headers?). Would be nice to see a build of it switch over to USB-C, which I think would be really neat.

Alas, those are all the weeCee updates I have. No new crazy games with issues (everything seems to be playing fine), just still the one with Flight Unlimited, and the CD lockup issue (as prev mentioned, possibly related to the IDE->MicroSD drivers running in 16-bit compatibility mode under Win98).

@NachtRave A IDE Driver is available for Linux https://github.com/torvalds/linux/blob/master … /ata/pata_rdc.c the actual LoC is pretty slim!

I will throw up a repo on GitHub and see what I can make happen.

So I managed to hack the Windows XP Embedded Vortex86 IDE drivers to work on Windows 98.

I have no idea if they are any faster or anything, but at least the yellow exclamation mark is gone...

drivers attached. I'll do more testing

EDIT : doesn't seem any quicker TBH, and I'm still getting the warnings about compatibility mode filesystems in the system performance tab

quicker or not, does it still do a total stall of a few seconds every few seconds when you FTP transfer a large file to the weeCee?

Mu0n wrote on 2022-05-04, 13:10:

quicker or not, does it still do a total stall of a few seconds every few seconds when you FTP transfer a large file to the weeCee?

Not tried FTP but I'm still getting write stalls extremely regularly when copying files HD->HD. Probably this driver has made no difference. In fact if you go to driver information it hasn't even loaded the sys file, I think this might be a wild goose chase.

alright. time to buy a logic analyzer and SCIENCE the SHIT out of all the address and data pins and rewrite the BIOS or something

or take a nap.

@rasteri that's awesome, what change did you make? Did you see any errors in the BOOTLOG. I have the same kind of error for loading the Ethernet driver in Windows 95, it just silently does nothing. I have a lot to learn debugging wise.

In the Windows 95 DDK I see `SCSIAdapter` is defined. Maybe I could try creating a new `SCSIAdapter` and pull the subroutines out of `rdcatapi.sys` (the Windows 2000 driver)? Guess it depends on much the APIs have changed.

Does that sound like a good idea or completely off base?

The laggy file transfers are definitely seen all over all these units as a result of that IDE->MicroSD controller.

@Mu0n, since you're going to be getting a scope analyzer (I unfortunately don't have the $ for a nice one so all I got is the cheapo one on eBay), can you check the true frequency rate of the clock on the SD card as you're testing? I am not skilled enough to know exactly what MicroSD uses for communication, but I did notice that it looked a lot like an SPI interface. If it is in-fact an SPI-like interface running, I bet you the speed will be controlled by how fast that clock line is going (a big duh, but hear me out). So, regardless of it being in 16-bit/32-bit, this or that, if the source clock speed to that MicroSD card never changes (because it's hard coded or controlled via other means (like some sort of internal divider), maybe?), it just ain't going to matter. We will be 100% limited by that link in the chain.

The reason I mention is because I am unsure how fast the device's SPI speeds can go up to, but I've worked with SPI based video units in the past that had a 20MHz rate limit on their SPI clock line, so maybe there is a similar limit being imposed here? Might be worth looking into how exactly that MicroSD card is interfacing with the SOM. Cause it certainly ain't an IDE line despite living on the IDE line.

I also did buy me a programming book on VxD Win9x driver programming a while back, but I'm not going to lie, it's pretty involved and not for the faint of heart (and here I thought I could learn anything if I put my mind to it), and not like I have access to the source code of this stuff anyways. I would gladly loan it to anyone who thinks their Win9x C++ skills are l33t enough to take a stab at it, alas. I'm not eager to run down that rabbit hole.

I also tried a bunch of various different disk options in one of those hidden Win98 menus, and it seems like, for what I tried, I wasn't seeing much change in anything. I welcome others to attempt to try the same, I was not the most thorough by any stretch.

Oh, and I guess I let my mom convince me to build another 4 units, just because she thinks the ones I made are worth way more than what I sold them for. I dunno, I'm not out to take advantage of anyone, but I took her advice and bought all the parts for another 4 units, and this time put it on a different credit card so I could track the expense a bit better. I will have to sell these at auction rates tho, just because of the time investment. New boards are ordered, new parts too, only had to sub 1 or 2 additional parts out (which was fairly easy to do so). BIOS chip had to get the -M/SN version, but seems like the same thing basically. The only main thing I had trouble with, again, is the 3.3 LDO, which I did kinda find a 1A (similar to Muon's actually I believe (or someone earlier in the thread)) that I'm sure will work, but also ordered the right one from China. Crystal chips ordered off same eBay supplier, as are SOMs + connectors from WDL (US distributor). Unfortunately again with the SST NAND Flash, that I have to manually disable, but luckily is only a single resistor (or just the whole NAND chip, take your pick).

There is one thing that I haven't really seen discussed in this thread: what brand, type and class of SD cards are you using? I will admit that it was years ago, but I did some testing, and noticed that there were significant differences between brands. Of the brands tried, Kingston were the absolute worst performers (but were common because they were cheaper), while SanDisk units were consistently among the best. I have to clarify, however, that my testing was for simple sequential read/write operations, which won't likely match the usage pattern when running an active Windows installation.

If you read the results of tests done over the years, you will even see that, in some cases, having a card of a lower class will yield better results in random-access usage. Trying different brands and classes of SD cards may help to alleviate some of the performance problems. A working native driver might help, but if they really are using the cards in SPI mode (the only mode that doesn't require a license), performance may be limited in any case. Depending on card type, absolute maximum SPI clock rates are 25 MHz or 50 MHz.

As a test, have any of you tried a Linux or Windows XP installation to see if file system performance improves when using the official vendor driver?

640K!enough wrote on 2022-05-05, 04:58:

As a test, have any of you tried a Linux or Windows XP installation to see if file system performance improves when using the official vendor driver?

That's a fair point. I'll give XP/linux a go.

I don't think it's running in SPI mode though - all four DAT pins are hooked up to the SoC and only two are needed for SPI.

(EDIT : I'll also double check that with my logic analyzer)

If anyone wants to put some effort into performance testing, some decent ideas can be found here. As on that page, it would be useful to mention the SD card brand/size/type. Builds of the same tools can be had for Windows, so adding a comparison between Linux, Windows XP and Windows 9x (with the compatibility-mode file system) would really give us an idea of potential performance, versus what you are getting now. It could be that what you are seeing now is about as good as it's going to get on that configuration.

640k, the thing about the SD cards was also something that I had suspected too, having had similar issues with too-high-of-class SD cards not working in certain hobbyist electronics setups (quadcopters and such), but I also tried using a standard 2GB cheapo card and was still getting the same issue with them, too, as well as the 512GB card (and this is from a custom Win98 install on both, not just a copy-over). Just so I add my 2-cents, I saw the issue on SanDisk, PNY, and Transcend. It's definitely worth a mention, but I think the issue is just in how Win98 works with the IO subsystem. I definitely think it would be wise to test under Linux, or an approved OS (like WinCE), just to measure what is going on on those pins (as has been mentioned - is a really good idea).

Also, with an SPI interface, true you only need 2 lines really (clock and MISO likely), but that limits you from writing since, as per SPI, each clock cycle essentially "transfers" a bit from MOSI and from MISO (like a bit exchange). There are plenty of applications where, for instance, you tie down the MOSI to low since you never need to send anything to the device (that's all controlled over I2C typically). Alas, I am not privy to the exact way MicroSD works, I just noticed that it lays on the same IDE lines that would otherwise be for an IDE device, so there is some sort of line sharing going on. (Oh and MOSI = master out slave in, MISO = master in slave out, in case anyone is wondering - yes these terms are considered antiquated and should be changed)

I will take a look at that link tho and see what I can't conjure up.

640k are you sure I can't convince you into a free weeCee unit? 😁

NachtRave wrote on 2022-05-03, 01:09:

Outside of that, I did hear back from rasteri concerning the addition of any 3D hardware -> the basic reality is that only the ISA bus (not PCI bus) is being exposed by the SOM...

Could it be possible to use an external GPU, one of those USB graphics cards? I don't know the compatibility with old systems like Win98 SE, and don't know if we can still find GPU old enough to be covered by the old drivers. And if it works, if we're limited to USB 1.0 bandwith the performance should be quite miserable, but I found it was an interesting idea.

I've tried some initial speed tests.

First sanity-check test was just to copy a 140MB file from SD card to the same SD card.

Windows gets 0.5MB/sec, linux gets 7-9MB/sec, DOS (well, win98 DOS mode) gets 4-5MB/sec.

As DOS uses real-mode drive access (right?) the slow speeds in Windows maybe aren't due to the driver running in real mode after all.

If I had to guess, I'd say there's a problem with how Windows accesses the data - I know certain read/write patterns don't play well with SD cards and Windows 98 is obviously too old to know about them.

Interestingly I'm getting the same stalls every few seconds on both Windows and Linux (probably DOS too), so maybe that's just what happens with Vortex86 SD cards. But obviously the stalls don't matter so much when you're transferring at 10x the speed in between the stalls 😀

Using Roadkil's speed test on Windows gets around 2MB/sec read, but I get 21MB/sec read using hdparm on linux.

Next I'll try Windows XP and maybe ME at some point. I'll probe the sd card signals with the different OSs to see if that gives any clues too.