Today I tried out a "Dell Wyse 5020" and "Dell Wyse 5060" thin client with SBEMU and FreeDOS, both worked just fine, however both had a problem were the keyboard seemed to make more moment than it should have, making the in game moment feel a small bit "slippery", kinda reminded me of a Nintendo game that has ice on the floor, I noticed that this "slippery" feeling was worse on the "Dell Wyse 5060" thin client, I had been doing some forum searching and found that it might help to use older PS/2 compatible mice and keyboards, so that is what I tried, and it seemed to help, but not completely remove the "slippery" feeling, however it's not so bad the games are unplayable.

After learning about Newly made PCMCIA sound card specifically its method of emulating DMA with TRS and fifo
Re: Newly made PCMCIA sound card
Re: Newly made PCMCIA sound card
Re: Newly made PCMCIA sound card

it becomes obvious we dont really need to trap <100h ports after all, thus it should be possible to stick to emm386.
All of vdma stuff could be replaced with TSR reading out currently programmed transfer buffer address/size instead of emulating DREQ. It works on real hardware, no reason not to work in software.

rasz_pl wrote on 2024-05-22, 11:28:

After learning about Newly made PCMCIA sound card specifically its method of emulating DMA with TRS and fifo Re: Newly made PCMC […]
Show full quote

After learning about Newly made PCMCIA sound card specifically its method of emulating DMA with TRS and fifo
Re: Newly made PCMCIA sound card
Re: Newly made PCMCIA sound card
Re: Newly made PCMCIA sound card

it becomes obvious we dont really need to trap <100h ports after all, thus it should be possible to stick to emm386.
All of vdma stuff could be replaced with TSR reading out currently programmed transfer buffer address/size instead of emulating DREQ. It works on real hardware, no reason not to work in software.

But that would only work with systems that have actual Intel 8237 compatible DMA controllers integrated in their chipsets, right? The LPC spec does include DMA, but it's an optional feature, and not all chipsets implement it. Especially since modern motherboards don't come with floppy controllers anymore or ECP-enabled parallel ports anymore, and TPM chips usually don't require DMA. So that completely eliminates the need for hardware-level 8237 DMA compatibility.

So yeah, on pretty much any laptop that is old enough to have PCMCIA slots, that would likely not be a problem. But SBEMU is also meant for more modern systems, and it's meant to support PCI(e) era sound devices as well.

But maybe SBEMU could be enhanced to offer such an emulation mode in the case that a compatible EMM isn't loaded and a legacy DMA controller is detected in the system? Not entirely sure if it would be worth adding, though. Unless maybe when such an emulation method would be faster, especially on such older systems?

I have long figured out the fake EMS sheet frame, a few simple lines in Config.sys. EMS is not created, only the sheet frame, so XMS/EMS sensitive titles run smoothly. Old and new systems are ok. Whether it is sbemu or sb dosdrivers.

DarthSun wrote on 2024-05-22, 22:46:

I have long figured out the fake EMS sheet frame, a few simple lines in Config.sys. EMS is not created, only the sheet frame, so XMS/EMS sensitive titles run smoothly. Old and new systems are ok. Whether it is sbemu or sb dosdrivers.

Will you please share how this is done? A few simple lines in CONFIG.SYS? It will be good to have as reference information. Thanks.

will1384 wrote on 2024-05-21, 22:49:

Today I tried out a "Dell Wyse 5020" and "Dell Wyse 5060" thin client with SBEMU and FreeDOS, both worked just fine, however both had a problem were the keyboard seemed to make more moment than it should have, making the in game moment feel a small bit "slippery", kinda reminded me of a Nintendo game that has ice on the floor, I noticed that this "slippery" feeling was worse on the "Dell Wyse 5060" thin client, I had been doing some forum searching and found that it might help to use older PS/2 compatible mice and keyboards, so that is what I tried, and it seemed to help, but not completely remove the "slippery" feeling, however it's not so bad the games are unplayable.

Possible it's input lag on your monitor? I use a VGA connection to my monitor and haven't noticed any lag, but I'm also not as sensitive to lag as others are. If you're using DVI, you could try VGA and/or fiddle with your monitor settings. If it is an sbemu issue, does the keyboard input start lagging on the command line when you start sbemu?

MoneySquirrel wrote on 2024-05-23, 01:10:

will1384 wrote on 2024-05-21, 22:49:

Today I tried out a "Dell Wyse 5020" and "Dell Wyse 5060" thin client with SBEMU and FreeDOS, both worked just fine, however both had a problem were the keyboard seemed to make more moment than it should have, making the in game moment feel a small bit "slippery", kinda reminded me of a Nintendo game that has ice on the floor, I noticed that this "slippery" feeling was worse on the "Dell Wyse 5060" thin client, I had been doing some forum searching and found that it might help to use older PS/2 compatible mice and keyboards, so that is what I tried, and it seemed to help, but not completely remove the "slippery" feeling, however it's not so bad the games are unplayable.

Possible it's input lag on your monitor? I use a VGA connection to my monitor and haven't noticed any lag, but I'm also not as sensitive to lag as others are. If you're using DVI, you could try VGA and/or fiddle with your monitor settings. If it is an sbemu issue, does the keyboard input start lagging on the command line when you start sbemu?

I don't think it's an SBEMU problem, but I have noticed keyboard and or mouse problems on all the thin clients I have tested, and I have tried a few different keyboards and mice, the keyboards and mice that seem to work the best are the ones that are USB and PS/2 compatible, so it may be a BIOS or mouse driver issue, I am testing a "10ZiG Technology 51xx Thin Client" right now, and it also seem to have problems with JemmEX and gives an error that F000 FFFF might be in use, and the mouse seems to have random movements in DOOM and Quake, I tried a USB mouse and a PS/2 mouse with the BIOS support for USB legacy mice disabled, and the problem still happened, however SBEMU seems to work just fine on the "10ZiG Technology 51xx Thin Client" after you disable the ports in BIOS to free stuff up for SBEMU.

I forgot to add that the PDF I found for the "10ZiG Technology 51xx Thin Client" that I have, lists this for the CPU info "VIA C7 1GHz/ VIA CN700+VT8237R Plus", and SBEMU said "VIA VT82XX AC97".

F000-FFFF should 'always' be in use: It's where the system bios lives.

Similar with C000-CC00, (sometimes CFFF) is the VGA bios.

The regions that might be free would be D000-DFFF, and E000-EFFF.

USB 'legacy keyboard and mouse support' handler, and any lan PXE bioses would live in that space though. Caveat emptor and all that.

Came across this amazing program recently, decided to try it and it's working pretty good with my HP t5530 Thin Client so far (apparently it has a VIA VT8233/A AC'97 enhanced audio controller that works fine on WIN98SE but not for DOS...)

I set it up with MS-DOS 6.22 and Windows 98SE (managed to find all the required drivers) and it works great, as long as the AUTOEXEC.BAT and CONFIG.SYS files used are different on the dual boot option (usually they have a .DOS extension) and Windows 98SE can load the old MS-DOS version without any problem!

Most of the games I'm trying have sound with SBEMU (I'm using the latest beta version) but Windows 98SE crashes during installation if i use the same DOS info from the AUTOEXEC.BAT and CONFIG.SYS files (think it's related to the JLOAD and Jemmex programs it needs for the real mode games). For the WIN98SE files, i edited those lines out, using the regular HIMEM.SYS and EMM386.EXE and everything worked fine).

The only thing I noticed which is kinda weird was with Warcraft II: it's as if the sound volume is constantly turning up and then down and then up again, etc. The actual sounds and music sound great but it's as if the volume control is acting all the time.... I tried lots of different SBEMU and Warcraft II combinations but nothing seemed to help. I also think Warcraft II relies on the SET BLASTER= line on AUTOEXEC.BAT for correct soundcard autodetection sometimes. If it's not present, it always suggests just the "regular" soundblaster instead of the sb16, for example, resulting in choppy music...

I'm posting my DOS files here, in case someone has a suggestion, as I'm probably setting something wrong:
AUTOEXEC.BAT:
SET BLASTER=A220 I5 D1 H5 P330 T6
C:\SBEMU\HDPMI32I
C:\SBEMU\JLOAD C:\SBEMU\QPIEMU.DLL
C:\SBEMU\SBEMU
@ECHO OFF
PROMPT $p$g
PATH=C:\DOS
SET TEMP=C:\DOS
MODE CON CODEPAGE PREPARE=((850) C:\DOS\EGA.CPI)
MODE CON CODEPAGE SELECT=850
LH /L:2,17264 KEYB PO,,C:\DOS\KEYBOARD.SYS

CONFIG.SYS:
DEVICE=C:\SBEMU\JEMMEX.EXE RAM
BUFFERS=15,0
FILES=40
DOS=UMB
LASTDRIVE=H
FCBS=1,0
DOS=HIGH
COUNTRY=351,,C:\DOS\COUNTRY.SYS
DEVICEHIGH /L:2,15792 =C:\DOS\DISPLAY.SYS CON=(EGA,,1)
STACKS=0,0
DEVICEHIGH /L:2,14848 =C:\MOUSE\MOUSE.COM /L=GB

Also, I noticed that on this particular computer, HP t5530 Thin Client, there's two IRQ options for setting the LPT1 on Bios (accessible with F10): IRQ 7 or IRQ5.
Apparently SBEMU needs to have the same IRQ used for the LPT1 port, otherwise the digital sound will fail. Found out this when trying to configure Warcraft II, having IRQ 5 for SBEMU and IRQ7 for LPT1: card would be detected but there was a big stuttering when it tried to play the test sound "Your sound card is working perfectly!". IRQ5 is probably being used by another device if it's not assigned to the LPT1 port...

Again, thank you so much for this amazing program and thanks for any help on this issue!!!

You can check with e.g. HWinfo for DOS if IRQ5 is used by some PCI device. Having same IRQ for LPT and sound seems to work smoothly.

RayeR wrote on 2024-05-23, 17:00:

You can check with e.g. HWinfo for DOS if IRQ5 is used by some PCI device. Having same IRQ for LPT and sound seems to work smoothly.

It works smoothly, yeah... Like I said, on this particular model, it really has to be like that, otherwise SBEMU will hang on some games... HWINFO says that it's the USB Universal Host Controller. If I change the LPT1 to IRQ5, the USB Controller starts using IRQ7. As long as I set SBEMU to use the same IRQ that LPT1 is using, everything is fine, except for that volume problem on Warcraft II...

Do you know if SBEMU disables the "regular" PC speaker? Games like PCMAN and Golden Axe (only the adlib sound works if sbemu is loaded) stopped having sound when SBEMU is loaded... Is there some way to fix this and have both enabled? Thanks!

wierd_w wrote on 2024-05-23, 08:11:

F000-FFFF should 'always' be in use: It's where the system bios lives. […]
Show full quote

F000-FFFF should 'always' be in use: It's where the system bios lives.

Similar with C000-CC00, (sometimes CFFF) is the VGA bios.

The regions that might be free would be D000-DFFF, and E000-EFFF.

USB 'legacy keyboard and mouse support' handler, and any lan PXE bioses would live in that space though. Caveat emptor and all that.

I am using the "FDCONFIG.SYS" from FreeDOS with no changes, it has the line:

DEVICE=C:\JEMM\JEMMEX.EXE NOEMS X=TEST NOVME NOINVLPG

that it seems to default to when booting, and it does not give an error with the "Dell Wyse 5020" and "Dell Wyse 5060" thin clients, next I tested a "Lenovo X1 Yoga Core i5 6300u" laptop with the same FreeDOS USB thumb drive, I get no JemmEX errors, SBEMU works showing "INTEL HDA", and the keyboard works, however the laptops trackpad/trackpoint go crazy, and a USB mouse wont work at all, so I am not sure what to think, I guess I will start testing different mouse drivers next.

I'd say that your thinclient uses shadowram.

Or more accurately, it's predominantly uefi/efi oriented, and the csm gets copied into ram at f000, and may or may not get set read only. Jemmx probes, finds ram, but sees stuff written there. Makes a statement.

I would treat such an arrangement like glass, and give hard excludes for the 'roms' present.

X=TEST may not work 100% reliable on obscure platforms. You may try manually exclude the biggest address region of A000-FFFF if it helps and then try to narrow the regions that needs to be excluded. Deails are in JEMM readme.

X=A000-FFFF excludes the entire UMA.

While pedantic, that's a bit extreme, and would prohibit use of the mda monochrome display buffer at B000-B7FF for umb, which is usually pretty safe.

I dont know how bad the csm is on that thinclient, but if it fails to provide a chunk of writable ram there, I would hardly call it a real csm!

Then again... it's a thinclient.... ...

Just saying, I'd probably exclude like this:

X=A000-AFFF I=B000-B7FF X=B800-BFFF X=C000-FFFF NOEMS

which would give a teeeeny bit of UMB, allow dos to be hma resident, tell jemmex not to even try setting up an ems pageframe (nowhere to put it!), and should keep any fragile ram-only (and maybe not write protected) csm 'roms' more safe.

but only for temporary testing. (See if odd keyboard and mouse behaviors persist, etc.)

I'd likely boot with no managers loaded, look at the uma for areas with 'data' in them, exclude those areas, then trial and error include any areas full of FF or 00 bytes.

Then again, i'm old with grey hair. 😁

zyzzle wrote on 2024-05-23, 00:19:

DarthSun wrote on 2024-05-22, 22:46:

I have long figured out the fake EMS sheet frame, a few simple lines in Config.sys. EMS is not created, only the sheet frame, so XMS/EMS sensitive titles run smoothly. Old and new systems are ok. Whether it is sbemu or sb dosdrivers.

Will you please share how this is done? A few simple lines in CONFIG.SYS? It will be good to have as reference information. Thanks.

For conventional sbpci dosdriver:

1device=c:\config\limitmem.sys 32
2
3rem new version EMS
4DEVICE=C:\config\HIMEMX.EXE /NOABOVE16 /X /X2MAX32 /MAX=32768
5DEVICE=C:\DOS\UMBPCI.SYS
6DEVICE=C:\dos\EMM386.EXE RAM
7DOS=HIGH,UMB,AUTO
8rem end new version EMS
9
10SHELL=C:\dos\COMMAND.COM C:\ /p
11DEVICEHIGH=C:\dos\SETVER.EXE
12DEVICEHIGH=C:\dos\IFSHLP.SYS
13SHELL=C:\COMMAND.COM C:\ /E:1024 /P
14LASTDRIVE=Z
15DEVICEhigh=C:\HXCD-ROM\LTNIDE.SYS /D:MSCD000
16STACKS=9,256
17SWITCHES=/F
18FILES=20
19BUFFERS=20

(DOS 7.1 copied to the Root DOS directory from the Win98 folder)

Autoexec:

1set BLASTER=A220 I5 D1 H5 P330
2rem SET BLASTER=A240 I7 D3 H7 P330  T6
3SET CTSYN=C:\PROGRA~1\CREATIVE\SBLIVE\DOSDRV
4C:\PROGRA~1\CREATIVE\SBLIVE\DOSDRV\SBEINIT.COM
5rem c:\ahcildr.com
6rem lh c:\resident\tp7p5fix.com
7rem lh c:\resident\snarf.exe
8rem lh c:\resident\vthief.com
9rem lh c:\resident\doslfn.com
10PATH C:\QEMM;C:\DOS;c:\util;c:\nc;c:\dn;
11SET MIDI=SYNTH:1 MAP:E MODE:0
12SET PATH=%PATH%;c:\util\fastvid;
13rem C:\DOS\SMARTDRV.EXE /L /X
14SET NC=C:\NC
15SET DN=C:\DN
16SET TMP=C:\TMP
17SET TEMP=%TMP%
18rem @ECHO OFF
19PROMPT [DOS_7.1] $P$G
20lh c:\util\ctmouse.exe
21rem lh c:\fastvid\fastvid
22lh C:\DOS\MSCDEX.EXE /D:MSCD000 /L:y
23lh c:\nc\nc

EMM386 will give you a mistake, but in a few seconds it will go on, remains active and will not complain about sbeinit.
It is worth noting on the RAM map on the Himemx, Umbpci, EMM386 trio 😀
The fake sheet frame is now active. Testing for : S939 AGP, S775 PCIe, S2011v3, SAM4 - audio : SB0060/0100/0220.

SBEmu :

1[B450]
2device=c:\config\limitmem.sys 256
3rem new version EMS
4rem DEVICE=C:\config\HIMEMX.EXE /MAX=32768
5DEVICEHIGH=C:\config\HIMEMX.EXE
6rem DEVICE=C:\DOS\HIRAM.EXE
7DEVICE=C:\DOS\UMBPCI.SYS
8rem DEVICE=C:\dos\HIMEM.SYS
9DEVICE=C:\dos\EMM386.EXE RAM
10rem end new version EMS
11DEVICEHIGH=C:\dos\SETVER.EXE
12DEVICEHIGH=C:\dos\IFSHLP.SYS
13SHELL=C:\COMMAND.COM C:\ /E:1024 /P
14LASTDRIVE=Z
15rem DEVICEhigh=C:\resident\ahcicd.SYS /D:MSCD000
16rem DEVICEhigh=C:\HXCD_ROM\LTNIDE.SYS /D:MSCD000
17STACKS=9,256
18SWITCHES=/F
19FILES=20
20BUFFERS=20
21DEVICE=C:\sbemun\jemmex.exe
22DOS=HIGH,UMB,auto
23rem DEVICE=C:\sbemu\qemm386.sys

autoexec :

1:B450
2set BLASTER=A220 I5 D1 H5 P330
3rem SET BLASTER=A240 I7 D3 H7 P330  T6
4rem SET CTSYN=C:\PROGRA~1\CREATIVE\SBLIVE\DOSDRV
5rem C:\PROGRA~1\CREATIVE\SBLIVE\DOSDRV\SBEINIT.COM
6rem c:\ahcildr.com
7lh c:\resident\tp7p5fix.com
8rem lh c:\resident\snarf.exe
9rem lh c:\resident\vthief.com
10rem lh c:\resident\doslfn.com
11PATH C:\QEMM;C:\DOS;c:\util;c:\nc;c:\dn;
12SET MIDI=SYNTH:1 MAP:E MODE:0
13SET PATH=%PATH%;c:\util\fastvid;
14C:\DOS\SMARTDRV.EXE /L /X
15SET NC=C:\NC
16SET DN=C:\DN
17SET TMP=C:\TMP
18SET TEMP=%TMP%
19rem @ECHO OFF
20PROMPT [DOS_7.1] $P$G
21rem lh c:\util\gmouse.com
22lh c:\util\ctmouse.exe
23rem lh c:\fastvid\fastvid
24rem lh C:\DOS\MSCDEX.EXE /D:MSCD000 /L:y
25lh c:\sbemun\jload c:\sbemun\qpiemu.dll
26lh c:\sbemun\hdpmi32i
27rem lh c:\sbemun\hdpmi32i -r -x2
28lh c:\sbemun\sbemu.exe /a220 /i5 /vol7
29rem lh c:\util\fvid\fvid 1
30lh c:\util\mskvbef7\mskvbef7
31GOTO EXIT

Memory map:

Here only real mode. The XMS/EMS sensitivity counts on old titles, and Jemmex is enough for newer ones.
Tested: B450PRO/R3800X/Motherboard Voice/SB0060/Chinese RTL M2 CASE/8GB+90GB FAT32 Partitions.
Tyrian doesn't run like that, but it's ok with vsbhda. For that, a simple boot is enough, then start/start16.bat can be used to alternate the birth mode, a great program.

Okay I tested SBEMU a bit today on my MMX 233 machine with an SBLive PCI installed.
/T set to 6
Games configured for SB16 sound and music.
Audio output (both sound FX and music) seemed to be coming out only on the left side. Right channel is inaudible. For example, in Descent setup, the center and left test sounds come out of the left side but the right test sound is inaudible. Music seems to work fine, but stuck in the left side. Sound FX are way too fast at the default 22050 rate. Setting it to 11025 returned sound FX to its proper speed.
I was able to play Descent and Quake with little to no performance penalty on the latest release. I still want to try a pentium-mmx compiled version; Descent seemed to struggle a tiny bit in the intro.
Test sounds in the Duke3d setup program always ran at an incorrect speed, no doubt related to the sample rate problem.

EDIT: I just cold booted again and starting SBEMU with the same settings the channel problem has reversed to the right side, and the left side is outputting a crapton of noise, like constant white noise.

megatog615 wrote on 2024-05-24, 21:02:

Okay I tested SBEMU a bit today on my MMX 233 machine with an SBLive PCI installed. /T set to 6 Games configured for SB16 sound […]
Show full quote

Okay I tested SBEMU a bit today on my MMX 233 machine with an SBLive PCI installed.
/T set to 6
Games configured for SB16 sound and music.
Audio output (both sound FX and music) seemed to be coming out only on the left side. Right channel is inaudible. For example, in Descent setup, the center and left test sounds come out of the left side but the right test sound is inaudible. Music seems to work fine, but stuck in the left side. Sound FX are way too fast at the default 22050 rate. Setting it to 11025 returned sound FX to its proper speed.
I was able to play Descent and Quake with little to no performance penalty on the latest release. I still want to try a pentium-mmx compiled version; Descent seemed to struggle a tiny bit in the intro.
Test sounds in the Duke3d setup program always ran at an incorrect speed, no doubt related to the sample rate problem.

EDIT: I just cold booted again and starting SBEMU with the same settings the channel problem has reversed to the right side, and the left side is outputting a crapton of noise, like constant white noise.

These are too slow configurations for SBEMU. Faster machines are recommended if older, then calendar driver. SBEMU is for modern, fast machines. Ryzen is really good, the retro effect is full.

As I wrote above - testing for : S939 AGP, S775 PCIe, S2011v3, SAM4 - audio : SB0060/0100/0220 - these are good ...

I would strongly recommend a real old ISA sound card to anyone who still has one or more ISA slots on the board. But practically all other PCs that have AC97 sound onboard can use SBEMU. I don't know anything about minimum system requirements. If it works with the T5710 ThinClient here, it should work with almost any other PC.

DarthSun wrote on 2024-05-26, 03:09:

megatog615 wrote on 2024-05-24, 21:02:

Okay I tested SBEMU a bit today on my MMX 233 machine with an SBLive PCI installed. /T set to 6 Games configured for SB16 sound […]
Show full quote

Okay I tested SBEMU a bit today on my MMX 233 machine with an SBLive PCI installed.
/T set to 6
Games configured for SB16 sound and music.
Audio output (both sound FX and music) seemed to be coming out only on the left side. Right channel is inaudible. For example, in Descent setup, the center and left test sounds come out of the left side but the right test sound is inaudible. Music seems to work fine, but stuck in the left side. Sound FX are way too fast at the default 22050 rate. Setting it to 11025 returned sound FX to its proper speed.
I was able to play Descent and Quake with little to no performance penalty on the latest release. I still want to try a pentium-mmx compiled version; Descent seemed to struggle a tiny bit in the intro.
Test sounds in the Duke3d setup program always ran at an incorrect speed, no doubt related to the sample rate problem.

EDIT: I just cold booted again and starting SBEMU with the same settings the channel problem has reversed to the right side, and the left side is outputting a crapton of noise, like constant white noise.

These are too slow configurations for SBEMU. Faster machines are recommended if older, then calendar driver. SBEMU is for modern, fast machines. Ryzen is really good, the retro effect is full.

What the heck are you talking about? I just said in my post that SBEMU works very well now on a MMX 233. The only issues are the sound not playing correctly.