640K!enough wrote on 2022-03-18, 07:45:

NachtRave wrote on 2022-03-17, 17:47:

I agree it's definitely a high cost barrier. On the flip side though, if you ever wanted a weeCee to test with.... :p I actually just finally got the non-SST NAND Flash version bought from DSL/ICOP in the UK, and to get just that one SOM shipped to here in the US, wow! 279 pounds they ask for (that's including 155 pounds for the SOM, and 124 pounds for the "Export Carriage, Insurance & Packing"), but after you add in wire transfer fees and everything else, a 180 USD SOM turns into 458.68 USD expense.

Ouch! No thanks. I'll tell you what: when I win the lottery, I'll make sure to build one of these and see if I can't be useful somehow. 😀

Haha, don't worry - tell you what, if I make batch #2 I'll mail you one for free. Least we can do for all you've done for the retro gaming community.

Another idea I actually had, after I have spent the last couple of weeks installing an ultra mega truck load of games, is the issue of CD audio in these old DOS games (some of which are fantastic). We have the ability to ofc rip the audio tracks and turn them into ogg/mp3, and then use, at least on the Windows side, a tool like Daemon Tools or _inmm to do DLL injection that redirects CD play commands to play ogg audio files. The problem in DOS, however, as I have been reading up on, is that DOS gives full access to the audio equipment to the game running, so doing software-level muxing is what makes emulating that CD audio so tricky - you really do need a hardware solution. What I am thinking, given we have a GPIO bus, is maybe using it to talk to an external hardware ogg/mp3 decoder, and mux the audio output line into the CD input rails of the CS4237B, which are currently ofc held low. There are many different options available here, and you could even use the GPIO lines to send the audio data itself over the line ahead of game boot, and also do some simple things like force loop the audio track being played.

@rasteri Maybe another v0.4 idea is including a CD audio hardware emulation chip, something that can be hooked up to the GPIO lines (SPI/I2C) and then its output hooked up to CD IN on the crystal chip. I'd gladly donate some of my time to making a test program/script to prototype with. Could be one of the coolest things since sliced bread, as least for the DOS gaming scene.

Alright, I hate to dive back into technical issues after dominating the thread for a few pages there, but I am currently, after putting together boards #2 and #3 (#2 still dealing with the audio chip (which I think is dead), #3 is at least working now tho) and finally having some time to troubleshoot using different hardware I know is working on other boards, I cannot for the life of me figure out why Daemon Tools is literally locking the Win98 system up when I try to mount .ccd images ripped off CloneCD (issue I'm experiencing similarly on /all/ boards I've so far made). When mounting from a cue/bin it seems to have less issues (read as: autorun at least runs), but still locks up after too much is attempted to be read from it. Trying to play CD audio really likes to lock it up, and the only way to get around is to CTRL-ALT-DELETE and kill off CD Player or Explorer or whatever is stuck reading from the mounted CD image. Sometimes the emulated CD audio does start playing (after killing the CD player executable for example) and... It's pretty terrible quality, with a lot of skips and changes in tempo and playback speed and such (feeling like a result of very slow disk access)...

Any tips or tricks or other things I could look at to try and resolve such issues? Could this perhaps be an issue with compatibility mode disk drivers? Are there any msconfig or other settings I could look into?

I really hate to ask, I messaged Mu0n over PM to see if he was having similar issues, alas he was not. I hate to say this is just my issue, considering I now have 3 (mostly working) boards and all of them are experiencing the same. Any help is of course greatly appreciated.

You said you were using 4.37 and I was using 3.47. Have you tried downgrading to 3.47? I tried a few before settling on the one I'm using.

Mu0n wrote on 2022-03-29, 19:39:

You said you were using 4.37 and I was using 3.47. Have you tried downgrading to 3.47? I tried a few before settling on the one I'm using.

No, I've been using 3.47. Also tried 3.44, 3.17, and 2.70. All having similar issues.

Check this out, you can get it to "sorta" go through with whatever it's accessing by CTRL-ALT-DELETE'ing, and just as long as the application isn't in a "not responding" state (which means you kinda have to do this sooner than later), you can just hit Cancel, and it gets a bit further before locking up again.

Weirdest dang thing. I was actually able to install a game off a Clone Image CCD, for instance, by doing this trick. Definitely not a solution, as you would need to constantly do this to even play a CD game, but it at least gets it unstuck for a few seconds enough to get done whatever it was trying to do.

What could *possibly* be causing this kind of thing? It almost seems like the disk driver being in compatibility mode is causing this kind of access restriction. I wonder if there is some hidden setting you can set to get around such.

have you tried on a new windows install?

rasteri wrote on 2022-03-31, 17:10:

have you tried on a new windows install?

I have - several in fact, even thought maybe installing it at a lower MHz might make it okay, but still same issue. I have even tried with/without the 2004 security update, as well as with/without the unofficial SP3 packages (versions 2.1a and 3.66) (this also includes installed Daemon Tools after these are installed). I have also tried all the Win98 ISOs I can currently find online, none have worked. Same issue being experienced on three separate boards.

It seems to play a lot nicer with bin/cue images, but even then it's not a guarantee. When in DOS mode I can use SHSUCD, which works and doesn't have any lockups (so there is at least that, but it doesn't support CD audio emulation).

I've only tried like 3 cd images since I'm in a dos game binge ATM (a Sierra "gauntlet"), so I might have the same issue as you. I got the whole REMOVED months ago, so if your source is from that, let me know in a PM, I can test a game out on my end.

In other news, here are boards #4, 5, and 6, built, tested, and working. Getting these ready to put on eBay. :3

I think I may run a small power line over to a power LED that I’ll drill a small hole for right above the memory card slot. Going to CAD up a LED holder bracket that you can 3D print and use to mount such with, and throw it on Thingiverse.

These work really well, sits on top of the gameport. Just need a 3mm hole drilled 5mm above the MicroSD card, and yeah. Gonna fit a resistor to it and wrap it in heat shrink, make it look all nice. Pretty simple model to make and print.

NachtRave wrote on 2022-04-10, 06:13:

These work really well, sits on top of the gameport. Just need a 3mm hole drilled 5mm above the MicroSD card, and yeah. Gonna fit a resistor to it and wrap it in heat shrink, make it look all nice. Pretty simple model to make and print.

Looks great! I wonder if there'd be space anywhere for a power switch (that's the other thing people seem to keep requesting, although I just tell people to use switched USB cables)

rasteri wrote on 2022-04-11, 13:08:

I wonder if there'd be space anywhere for a power switch (that's the other thing people seem to keep requesting, although I just tell people to use switched USB cables)

I bet what you could find is probably a latching power switch that lights up. More than likely you could get away with a barrel connector kind with just a simple hole above the MicroSD port, then somewhere to wire it to.

Here’s some more pics of the LED holder wired up and working. I kept with your 4.7 47.0 scheme and sized a 470ohm resistor to it, so it’s not blindly bright or too dim. Nice sturdy 7mA of current on a 3mm LED.

Also, check this out. Finally got the VINE version, without the SST NAND Flash, and the v1.2 of that SOM doesn’t have a single missing resistor or cap or anything - identical to the SST NAND version, just without the literal flash chip. Pictures attached, and you can see the two resistors we identified from the v1.1 board of Rasteri's removed but installed in this product version.

Made me wonder if having removed that resistor if that was giving me the issues I was seeing, but no dice. Identical issue even on this VINE package direct from factory (which may just been a bad CD image, which isn't completely out of the ordinary given the age of the CD storage medium). So in short, it is 100% not worth it to go through the UK distributor here in the US just to get the version of the SOM without the flash, which costs about 500$ for a 180$ SoM after you account for all the fees you'll be charged. Just order from WDL in Texas (which only has the versions /w the SST NAND Flash), and just remove the resistor as I had posted earlier in this thread, way easier and safer.

rasteri wrote on 2021-04-13, 10:33:

I also have a Vortex86EX based SoM that I will benchmark shortly.

Whatever happened to the Vortex86EX?

Nikita Lita wrote on 2022-04-17, 03:24:

Whatever happened to the Vortex86EX?

Vortex86 series benchmarks

Guess what, it's your favorite annoying person in the thread with fun VESA stuff to report.

Challenge: Get X-Men: Children of the Atom working, which uses SciTech UniVBE. Tried all day the other day and was very unsuccessful, including disabling UniVBE with the -U command line parameter to XMENPC.EXE. First game that I have tested that I was not able to get working. I think one might need the actual physical CD for DOS mode to work (that is, not using SHSUCD), as I think SHSUCD limits the name of the CD and cuts off the last character needed for a direct title comparison to work (as the same exact setup works fine in DOSBox). There could be other things it's doing to check for the CD (I'm not going to dive into disassembly for that), but it really didn't want to play nice with SHSUCD.

I was able to at least get Flight Unlimited to work by running sisVBE beforehand, despite the cutscenes being scrambled badly. At least lets me play the game and not crash. Flight Unlimited uses SciTech UniVBE.

The only way I got Star Trek A Final Unity to work was to disallow it from detecting windows, as it would crash in pure DOS. It wasn't using SciTech but it was doing something funky.

KKND 1 I also had some trouble with as well but looks like I got it resolved by disabling its SciTech UniVBE. I forget how exactly.

Question: Have anyone found a SciTech UniVBE config that works? Still playing around with getting better results, but SciTech's UniVBE seems to struggle with the Z9S. The closest I've gotten is "UVConfig -s10" for the TSeng Labs family and then optionally "-c13" for the ET-4000 W/32 unknown revision /w 8-bit RAMDAC, and "-m8192" for the 8MB (a paltry sum of the available 32MB). But still just crashes most games I've tried it with, despite other non-SciTech drivers seeming to handle this same option rather well.

Also, what is VESA 3.0 really adding to VESA 2.0? I saw something about adding custom screen modes and such, but I didn't read into it too much. I wish there was more documentation on interacting with these things.

what UniVBE version is used with "X-Men: Children of the Atom"?

you could find the version in the header of the UNIVBE.DRV file (if there is one)

do the modified drivers work for you?

If your video card is not being recognized correctly by your game, it might be caused by the fact that some games use a built-in version of UniVBE/SDD
(UVBELib) and are not able to use the VBE BIOS from the video card. UVBELib generates a driver (univbe.drv) that contains video card specific code.

Just copy the correct univbe.drv file to the game directory, overwriting the existing univbe.drv file, and try the game again.

https://www.dosdays.co.uk/topics/graphics_drivers.php

or there is also my own tool NoUniVBE that works for UniVBE 5.3a games

https://github.com/LowLevelMahn/NoUniVBE/rele … tag/RELEASE-0.5

just start it before the game and it prevents the game internal UniVBE code from loading

llm wrote on 2022-04-19, 04:52:

what UniVBE version is used with "X-Men: Children of the Atom"?

SciTech UniVBE 5.3a. (Edit: Or more specifically: "Universal VESA VBE 5.3a")

The thing is, if you don't have a UNIVBE.DRV file and you run the game with the -U option, it respects it and certainly doesn't try to run UniVBE or load up the driver (and even reports if it cannot find the screen mode it wants to use). That doesn't lead me to think it's a VESA issue per sey, since it just crashes right away.

Update: That being said, I did notice that the XMEN COTA 8MB install with the NO-CD crack under Windows (QEMM config) at least got to the spot where it reported it couldn't find a screen mode: "X-Men cannot initialise a 360x240 256 colour graphics mode. Run the UVCONFIG program." -- Dunno about this 360x240 256 mode, that may be a non-standard graphics mode. This game does seem to be a port of an arcade game of sorts, so that kind of resolution is an interesting clue. Maybe it just needs added to a table of some kind?

You can't run it in DOS-only mode, where you only have SHSUCD, because it complains about not finding the CD drive (with the same files working fine in a DOSBOX environment, mind you). I believe this may be an issue with SHSUCD itself, and has me wondering if I should try to increase the CD name length and recompile it through NASM (not that I want to try that, just saying it's my best bet as to what would make it sorta work). Note: I also should mention I've tried both with and without the NO-CD crack (only for the 8MB install option) to only have it crash (under any and all config.sys/autoexec.bat variations I've tried, w and w/o emm386/qemm, trying against the 16MB install, the works).

You can't run it in Windows, where you have access to CloneCD and VirtualDrive (which likely handle the longer CD title correctly, amongst CD audio support and other things, and yes X-Men COTA has a CD audio track that plays behind the gameplay and really adds a lot to the overall game), because it fails out and crashes right away. I've tried a lot of different things to get the executable to run here and to unfortunately no avail. The manual of the game is also very specific about running it outside of Windows, which isn't atypical for this era of games.

llm wrote on 2022-04-19, 04:52:

do the modified drivers work for you?

So I did give them a try and, unsurprisingly, they did not work. Same basic situation as before.

I also tried the NoUniVBE on Flight Unlimited, which seemed to be working through the initial cutscene, but crashed on game launch (similar to many others I've tried). Still using the sisVBE on that one because even tho the cutscenes are trashed the main game still works.

I at least did manage to get you some output for UVBCHECK:

1Init signature: VBE2
2int 10h/ax=4F00h
3ax_reg: 0x004F
4bx_reg: 0x1234
5cx_reg: 0x4321
6dx_reg: 0x0000
7  Signature: VESA
8  VbeVersion: 0x0300
9  OemStringPtr: XGI
10  Capabilities: 0x00000000
11  VideoModePtr: 0x00000DE8
12  TotalMemory: -32768 KB
13---VBE2---
14  OemSoftwareRev: 0x0100
15  OemVendorNamePtr: XGI Technology, Inc.
16  OemProductNamePtr: Volari Z9s
17  OemProductRevPtr: 1.14.04
18UniVBE is not installed

Gotta love seeing the 32MB roll over the 16-bit register and return a negative amount of total memory. :3

So the XMEN COTA mystery gets even more interesting. As I check other versions of XMEN COTA I find a copy of VBEPlus with a bunch of extra modes relevant to the game in the config file (attached below). Adds a tons of additional modes, 48 to be exact, that at least helps resolve the times I've seen where it's saying it can't find a screen mode, alas, still just winds up crashing. Going to try another slew of config.sys/autoexec.bat changes to see where that gets me since I'm running Win98 under QEMM rn and that could be affecting things. Attached is also output of VBEPlus, listing what screen modes it's taking over at what addresses. It definitely has the screen mode right now, as it was able to at least get to the point where the screen was all garbled as the credits were rolling (well, before it locked up shortly after 🤣).