superfury wrote on Yesterday, 22:47:

Running RetroOS in my emulator now I see something interesting when I look into VRAM after it finishes 'booting': The video card […]
Show full quote

Running RetroOS in my emulator now I see something interesting when I look into VRAM after it finishes 'booting': The video card is operating in 16-bit color graphics mode (according to the DAC 5:6:5 mode, 2 bytes per pixel). But looking into VRAM I see text mode data. The rows roughly say (ignoring the attribute bytes every second byte):
!!! FATAL !!!
(on adres A0h voor de volgende regel:)at bazel-out/k8-opt/bin/kernel/src/kernel/display.rs:556
(on adres 140h, so fixed 160 bytes row size in text mode (even though the adapter is rendering graphics according to it's registers):)banked VBE present failed: Rejected(0x4f05)
(on adres 280h:)RetroOS kernel retroos-gfb651a0
(on adres 320h:)Stack trace:
(etc.)

It's like it forgot to switch back to text mode while dumping the error message in VGA text mode format onto the screen.

Quickly asking AI to interpret the VRAM as text (instead of having to type it myself) was luckily easy (simple text parsing request):

!!! FATAL !!! at bazel-out/k8-opt/bin/kernel/src/kernel/display.rs:556 banked VBE present failed: Rejected(0x4f05) […]
Show full quote

!!! FATAL !!!
at bazel-out/k8-opt/bin/kernel/src/kernel/display.rs:556
banked VBE present failed: Rejected(0x4f05)

RetroOS kernel retroos-1-gfb6651a0
Stack trace:
0: 0xc0b14c72
1: 0xc0b13ef6
2: 0xc0bae7cb
3: 0xc0bbd5f9
4: 0xc0bbdb4f
5: 0xc0bdc9aa

Hopefully it's useful to what's going wrong in UniPCemu with this OS? This dump was from the current UniPCemu commit and RetroOS ISO image.

That seems to be: https://github.com/gerben-stavenga/RetroOS/bl … display.rs#L556

Wow this is really useful. Okay from the log it seems like the VBE doesn't properly support direct bank-switching. I've released a new one that just uses the standard int path. With a best effort to produce a text mode panic in this case. This exposed a subtle issue in rust panic handler, I dont have access to the local wrapped bios VM86 needed to switch to text mode. Need to think about this, luckily if all goes well panics should happen less and less. It should appear in the klog on disk.

btw. can unipcemu support port E9 like bochs/qemu then one can see this kind of errors immediately.

LSS10999 wrote on Today, 01:36:

After some fiddling with the system's disk layout I'm able to actually save a KLOG. Some issues with disk and storage: - The SAT […]
Show full quote

gsos wrote on Yesterday, 18:54:

@LSS I see, quake is using GUS which is still emulated through HDA. Can you provide me the klog of your system, that might contain some info relevant to why SB is not working. I'm really interested because you provide me the only system where SB really can run natively as RetroOS intended. I think we are very close to get it working with disappointment. I'm released a new version where hopefully the HDA_OUTPUT=Jack problem is fixed.

After some fiddling with the system's disk layout I'm able to actually save a KLOG.
Some issues with disk and storage:
- The SATA controller on my P8B75-M is in IDE mode, and RetroOS doesn't pick it up.
- RetroOS cannot handle extended/logical partitions in MBR, so I have to use a primary partition as a backing partition for the purpose.

The KLOG suggests HDA is still defaulting to "Speaker" which doesn't exist and instead chose Headphone first, but correctly defaults to Jack as specified in CONFIG.SYS now.

I only tested Skyroads and Wolf3D at the moment. FM works but sound does not.

An excerpt regarding Sound Blaster init.

Copy code to clipboard

1ISA LPC: LDRQ1# restored from GPIO23 to native mode
2ISA LPC: dISAppointment: configured Intel LPC + Fintek F85226; ISA DMA initialized
3ISA PnP: no Sound Blaster found; trying legacy DSP discovery
4sb: DSP 4.x at 0x220 — IRQ5 DMA1 (SB16: straps read from the mixer)
5Audio: NativeSb (SB_AUDIO=native)
6Audio: ISA DMA buffer pages ch1=0x0 ch5=0x0 (0 means unavailable)
7Audio: SB16 restrapped to BLASTER (IRQ5 DMA1 HDMA5)
8Audio: SB IRQ5 routed

So it seems CT2290 (non-PnP) is storing IRQ/DMA settings inside the mixer...
The ISA DMA buffer pages line lists both DMA1 and DMA5 being 0. Not sure if this means ISA DMA is not being configured correctly...

When running Wolf3D it seems the mixer is being touched.
However, volume from SB output still feels too low -- I have to raise the volume knob of the SB output to max to be able to at least hear the FM.
Normally the volume knob is kept at around 40-50% for other OSes where the card works, and I'm getting decent volume there.
Maybe it's a good idea to be able to manage SB mixer settings in the F12 menu similar to HDA.

This was very informative. I might have a solution to the sfx not working on the new release. I added a master volume control in the f12 osd menu. I hope this fixes things.

gsos wrote on Today, 01:47:

superfury wrote on Yesterday, 22:47:

Running RetroOS in my emulator now I see something interesting when I look into VRAM after it finishes 'booting': The video card […]
Show full quote

Running RetroOS in my emulator now I see something interesting when I look into VRAM after it finishes 'booting': The video card is operating in 16-bit color graphics mode (according to the DAC 5:6:5 mode, 2 bytes per pixel). But looking into VRAM I see text mode data. The rows roughly say (ignoring the attribute bytes every second byte):
!!! FATAL !!!
(on adres A0h voor de volgende regel:)at bazel-out/k8-opt/bin/kernel/src/kernel/display.rs:556
(on adres 140h, so fixed 160 bytes row size in text mode (even though the adapter is rendering graphics according to it's registers):)banked VBE present failed: Rejected(0x4f05)
(on adres 280h:)RetroOS kernel retroos-gfb651a0
(on adres 320h:)Stack trace:
(etc.)

It's like it forgot to switch back to text mode while dumping the error message in VGA text mode format onto the screen.

Quickly asking AI to interpret the VRAM as text (instead of having to type it myself) was luckily easy (simple text parsing request):

!!! FATAL !!! at bazel-out/k8-opt/bin/kernel/src/kernel/display.rs:556 banked VBE present failed: Rejected(0x4f05) […]
Show full quote

!!! FATAL !!!
at bazel-out/k8-opt/bin/kernel/src/kernel/display.rs:556
banked VBE present failed: Rejected(0x4f05)

RetroOS kernel retroos-1-gfb6651a0
Stack trace:
0: 0xc0b14c72
1: 0xc0b13ef6
2: 0xc0bae7cb
3: 0xc0bbd5f9
4: 0xc0bbdb4f
5: 0xc0bdc9aa

Hopefully it's useful to what's going wrong in UniPCemu with this OS? This dump was from the current UniPCemu commit and RetroOS ISO image.

That seems to be: https://github.com/gerben-stavenga/RetroOS/bl … display.rs#L556

Wow this is really useful. Okay from the log it seems like the VBE doesn't properly support direct bank-switching. I've released a new one that just uses the standard int path. With a best effort to produce a text mode panic in this case. This exposed a subtle issue in rust panic handler, I dont have access to the local wrapped bios VM86 needed to switch to text mode. Need to think about this, luckily if all goes well panics should happen less and less. It should appear in the klog on disk.

btw. can unipcemu support port E9 like bochs/qemu then one can see this kind of errors immediately.

Yeah, port E9 is supported and implemented (and even extended with a special interface at port EAh which is enabled by writing a string read from port EA(which is FFh terminated instead of NULL-terminated, but written to the debug E9 port with a newline after it (which activates the command interface for the emulator at I/O port EAh and EBh, with EBh reads returning EBh (also used for triggering hardware logging being armed with appropriate commands))). Port ECh is a simple 8/16/32-bit port usable for diagnostic writes and readback (used to test I/O ports safely). There's also a qemu logging port (I/O port 402h alias of E9h for writes only), but that will need to be enabled with a command line parameter (debuggerqemu).
The EBh/ECh I/O ports were added in later commits since the last release version. I/O port EBh can be detected by reading from it and it returns EBh (fully confirmed if EAh gives back a non-empty string instead of a floating bus(0xFF) for at least 1 reads (indicating some text being stored into it to trigger the port EAh to become a proper command interface)). Port ECh can be detected by writing data to it and reading it back (it's just a simple 8/16/32-bit I/O buffer for diagnostics), but doesn't exist if the other 3 I/O ports (E9h, EAh and EBh) don't exist. Also, writing the string read from EAh to port E9h to activate the EAh interface (also resetting it to it's initial command mode ready state) isn't logged of course (it's detected and parsed as a special command line for the emulator. All other whole lines logged using port E9h (terminated with newline as \r, \n, \r\n or \n\r) are normally logged to the (default) logging file. The command interface at EAh can be used to change the filename of the logging to something else (defaults to "porte9").

Edit: Found it indeed generated a log:

gsos wrote on Today, 02:40:

LSS10999 wrote on Today, 01:36:

After some fiddling with the system's disk layout I'm able to actually save a KLOG. Some issues with disk and storage: - The SAT […]
Show full quote

gsos wrote on Yesterday, 18:54:

@LSS I see, quake is using GUS which is still emulated through HDA. Can you provide me the klog of your system, that might contain some info relevant to why SB is not working. I'm really interested because you provide me the only system where SB really can run natively as RetroOS intended. I think we are very close to get it working with disappointment. I'm released a new version where hopefully the HDA_OUTPUT=Jack problem is fixed.

After some fiddling with the system's disk layout I'm able to actually save a KLOG.
Some issues with disk and storage:
- The SATA controller on my P8B75-M is in IDE mode, and RetroOS doesn't pick it up.
- RetroOS cannot handle extended/logical partitions in MBR, so I have to use a primary partition as a backing partition for the purpose.

The KLOG suggests HDA is still defaulting to "Speaker" which doesn't exist and instead chose Headphone first, but correctly defaults to Jack as specified in CONFIG.SYS now.

I only tested Skyroads and Wolf3D at the moment. FM works but sound does not.

An excerpt regarding Sound Blaster init.

Copy code to clipboard

1ISA LPC: LDRQ1# restored from GPIO23 to native mode
2ISA LPC: dISAppointment: configured Intel LPC + Fintek F85226; ISA DMA initialized
3ISA PnP: no Sound Blaster found; trying legacy DSP discovery
4sb: DSP 4.x at 0x220 — IRQ5 DMA1 (SB16: straps read from the mixer)
5Audio: NativeSb (SB_AUDIO=native)
6Audio: ISA DMA buffer pages ch1=0x0 ch5=0x0 (0 means unavailable)
7Audio: SB16 restrapped to BLASTER (IRQ5 DMA1 HDMA5)
8Audio: SB IRQ5 routed

So it seems CT2290 (non-PnP) is storing IRQ/DMA settings inside the mixer...
The ISA DMA buffer pages line lists both DMA1 and DMA5 being 0. Not sure if this means ISA DMA is not being configured correctly...

When running Wolf3D it seems the mixer is being touched.
However, volume from SB output still feels too low -- I have to raise the volume knob of the SB output to max to be able to at least hear the FM.
Normally the volume knob is kept at around 40-50% for other OSes where the card works, and I'm getting decent volume there.
Maybe it's a good idea to be able to manage SB mixer settings in the F12 menu similar to HDA.

This was very informative. I might have a solution to the sfx not working on the new release. I added a master volume control in the f12 osd menu. I hope this fixes things.

Thanks for the new release. Native SB now works as expected. I'm getting proper sound output in games.

I wonder if there can be additional controls for the SB mixer.
Setting SB master volume to 100 allowed me to hear SFX at decent volume but I think there's a need to adjust other parameters for a better balance of volume across different elements, like Wave, FM, CD.
As for CD, not sure if RetroOS can handle Redbook CD audio, but on my B75 system I have a working analog CD audio path. Though it would be optional if digital audio path (actual or virtual CD) is optimal enough.
My usual UNISOUND mixer arguments are "/VF99 /VC80" (CD volume is set to 0 sometimes, which means muted). FM/MIDI tends to be a bit too quiet in practice compared to WAVE.

On the other hand, looks like something's not right when writing to disk.
While in RetroOS I noticed the klog output has stopped, with the last line being incomplete "sb: nati".
Seems to point to SB native mixer stats comparing to my previous klogs.
After rebooting to Linux it seems the backing partition has been borked, appearing as "Unknown".
I'll see if I could recover the partition, or simply just start it anew as there's nothing except a modified CONFIG.SYS and klogs.

Anyway, I'm thinking of bringing in some games that previously failed with emulated SB as a cross test later on.

EDIT: The backing partition is on an NVMe SSD that's being picked up by RetroOS.
Thankfully I'm able to fsck the partition back alive. Looks like some kind of superblock corruption.

1fsck from util-linux 2.42.4
2e2fsck 1.47.4 (6-Mar-2025)
3ext2fs_open2: Bad magic number in super-block
4fsck.ext2: Superblock invalid, trying backup blocks...
5RETRO was not cleanly unmounted, check forced.
6Pass 1: Checking inodes, blocks, and sizes
7Pass 2: Checking directory structure
8Pass 3: Checking directory connectivity
9Pass 4: Checking reference counts
10Pass 5: Checking group summary information
11Free blocks count wrong for group #0 (23503, counted=23481).
12Fix<y>? yes
13Free blocks count wrong for group #16 (24544, counted=24540).
14Fix<y>? yes
15Free blocks count wrong for group #17 (32768, counted=32759).
16Fix<y>? yes
17Free blocks count wrong (16369539, counted=16369504).
18Fix<y>? yes
19Free inodes count wrong for group #0 (8180, counted=8176).
20Fix<y>? yes
21Free inodes count wrong for group #16 (8192, counted=8180).
22Fix<y>? yes
23Directories count wrong for group #16 (0, counted=4).
24Fix<y>? yes
25Free inodes count wrong (4194292, counted=4194276).
26Fix<y>? yes
27Padding at end of inode bitmap is not set. Fix<y>? yes
28Block bitmap differences: Group 0 block bitmap does not match checksum.
29FIXED.
30
31RETRO: ***** FILE SYSTEM WAS MODIFIED *****
32RETRO: 28/4194304 files (3.6% non-contiguous), 407712/16777216 blocks

Since any further klog was lost, I've no idea what might happened to the backing partition at that time leading to this...

On the other hand, I guess it's probably the time to consider the function to gracefully shutdown or reboot from RetroOS.
When performing shutdown or reboot, the mounted partitions should be properly unmounted during the process.

superfury wrote on Today, 04:10:

Yeah, port E9 is supported and implemented (and even extended with a special interface at port EAh which is enabled by writing a […]
Show full quote

gsos wrote on Today, 01:47:

superfury wrote on Yesterday, 22:47:

Running RetroOS in my emulator now I see something interesting when I look into VRAM after it finishes 'booting': The video card […]
Show full quote

Running RetroOS in my emulator now I see something interesting when I look into VRAM after it finishes 'booting': The video card is operating in 16-bit color graphics mode (according to the DAC 5:6:5 mode, 2 bytes per pixel). But looking into VRAM I see text mode data. The rows roughly say (ignoring the attribute bytes every second byte):
!!! FATAL !!!
(on adres A0h voor de volgende regel:)at bazel-out/k8-opt/bin/kernel/src/kernel/display.rs:556
(on adres 140h, so fixed 160 bytes row size in text mode (even though the adapter is rendering graphics according to it's registers):)banked VBE present failed: Rejected(0x4f05)
(on adres 280h:)RetroOS kernel retroos-gfb651a0
(on adres 320h:)Stack trace:
(etc.)

It's like it forgot to switch back to text mode while dumping the error message in VGA text mode format onto the screen.

Quickly asking AI to interpret the VRAM as text (instead of having to type it myself) was luckily easy (simple text parsing request):

Hopefully it's useful to what's going wrong in UniPCemu with this OS? This dump was from the current UniPCemu commit and RetroOS ISO image.

That seems to be: https://github.com/gerben-stavenga/RetroOS/bl … display.rs#L556

Wow this is really useful. Okay from the log it seems like the VBE doesn't properly support direct bank-switching. I've released a new one that just uses the standard int path. With a best effort to produce a text mode panic in this case. This exposed a subtle issue in rust panic handler, I dont have access to the local wrapped bios VM86 needed to switch to text mode. Need to think about this, luckily if all goes well panics should happen less and less. It should appear in the klog on disk.

btw. can unipcemu support port E9 like bochs/qemu then one can see this kind of errors immediately.

Yeah, port E9 is supported and implemented (and even extended with a special interface at port EAh which is enabled by writing a string read from port EA(which is FFh terminated instead of NULL-terminated, but written to the debug E9 port with a newline after it (which activates the command interface for the emulator at I/O port EAh and EBh, with EBh reads returning EBh (also used for triggering hardware logging being armed with appropriate commands))). Port ECh is a simple 8/16/32-bit port usable for diagnostic writes and readback (used to test I/O ports safely). There's also a qemu logging port (I/O port 402h alias of E9h for writes only), but that will need to be enabled with a command line parameter (debuggerqemu).
The EBh/ECh I/O ports were added in later commits since the last release version. I/O port EBh can be detected by reading from it and it returns EBh (fully confirmed if EAh gives back a non-empty string instead of a floating bus(0xFF) for at least 1 reads (indicating some text being stored into it to trigger the port EAh to become a proper command interface)). Port ECh can be detected by writing data to it and reading it back (it's just a simple 8/16/32-bit I/O buffer for diagnostics), but doesn't exist if the other 3 I/O ports (E9h, EAh and EBh) don't exist. Also, writing the string read from EAh to port E9h to activate the EAh interface (also resetting it to it's initial command mode ready state) isn't logged of course (it's detected and parsed as a special command line for the emulator. All other whole lines logged using port E9h (terminated with newline as \r, \n, \r\n or \n\r) are normally logged to the (default) logging file. The command interface at EAh can be used to change the filename of the logging to something else (defaults to "porte9").

Edit: Found it indeed generated a log:

The attachment porte9.log is no longer available

you didn't run the last release? i added a fix in the newer version this seems to be the previous release

LSS10999 wrote on Today, 04:16:

Thanks for the new release. Native SB now works as expected. I'm getting proper sound output in games. […]
Show full quote

gsos wrote on Today, 02:40:

LSS10999 wrote on Today, 01:36:

After some fiddling with the system's disk layout I'm able to actually save a KLOG. Some issues with disk and storage: - The SAT […]
Show full quote

After some fiddling with the system's disk layout I'm able to actually save a KLOG.
Some issues with disk and storage:
- The SATA controller on my P8B75-M is in IDE mode, and RetroOS doesn't pick it up.
- RetroOS cannot handle extended/logical partitions in MBR, so I have to use a primary partition as a backing partition for the purpose.

The KLOG suggests HDA is still defaulting to "Speaker" which doesn't exist and instead chose Headphone first, but correctly defaults to Jack as specified in CONFIG.SYS now.

I only tested Skyroads and Wolf3D at the moment. FM works but sound does not.

An excerpt regarding Sound Blaster init.

Copy code to clipboard

1ISA LPC: LDRQ1# restored from GPIO23 to native mode
2ISA LPC: dISAppointment: configured Intel LPC + Fintek F85226; ISA DMA initialized
3ISA PnP: no Sound Blaster found; trying legacy DSP discovery
4sb: DSP 4.x at 0x220 — IRQ5 DMA1 (SB16: straps read from the mixer)
5Audio: NativeSb (SB_AUDIO=native)
6Audio: ISA DMA buffer pages ch1=0x0 ch5=0x0 (0 means unavailable)
7Audio: SB16 restrapped to BLASTER (IRQ5 DMA1 HDMA5)
8Audio: SB IRQ5 routed

So it seems CT2290 (non-PnP) is storing IRQ/DMA settings inside the mixer...
The ISA DMA buffer pages line lists both DMA1 and DMA5 being 0. Not sure if this means ISA DMA is not being configured correctly...

When running Wolf3D it seems the mixer is being touched.
However, volume from SB output still feels too low -- I have to raise the volume knob of the SB output to max to be able to at least hear the FM.
Normally the volume knob is kept at around 40-50% for other OSes where the card works, and I'm getting decent volume there.
Maybe it's a good idea to be able to manage SB mixer settings in the F12 menu similar to HDA.

This was very informative. I might have a solution to the sfx not working on the new release. I added a master volume control in the f12 osd menu. I hope this fixes things.

Thanks for the new release. Native SB now works as expected. I'm getting proper sound output in games.

I wonder if there can be additional controls for the SB mixer.
Setting SB master volume to 100 allowed me to hear SFX at decent volume but I think there's a need to adjust other parameters for a better balance of volume across different elements, like Wave, FM, CD.
As for CD, not sure if RetroOS can handle Redbook CD audio, but on my B75 system I have a working analog CD audio path. Though it would be optional if digital audio path (actual or virtual CD) is optimal enough.
My usual UNISOUND mixer arguments are "/VF99 /VC80" (CD volume is set to 0 sometimes, which means muted). FM/MIDI tends to be a bit too quiet in practice compared to WAVE.

On the other hand, looks like something's not right when writing to disk.
While in RetroOS I noticed the klog output has stopped, with the last line being incomplete "sb: nati".
Seems to point to SB native mixer stats comparing to my previous klogs.
After rebooting to Linux it seems the backing partition has been borked, appearing as "Unknown".
I'll see if I could recover the partition, or simply just start it anew as there's nothing except a modified CONFIG.SYS and klogs.

Anyway, I'm thinking of bringing in some games that previously failed with emulated SB as a cross test later on.

EDIT: The backing partition is on an NVMe SSD that's being picked up by RetroOS.
Thankfully I'm able to fsck the partition back alive. Looks like some kind of superblock corruption.

Copy code to clipboard

1fsck from util-linux 2.42.4
2e2fsck 1.47.4 (6-Mar-2025)
3ext2fs_open2: Bad magic number in super-block
4fsck.ext2: Superblock invalid, trying backup blocks...
5RETRO was not cleanly unmounted, check forced.
6Pass 1: Checking inodes, blocks, and sizes
7Pass 2: Checking directory structure
8Pass 3: Checking directory connectivity
9Pass 4: Checking reference counts
10Pass 5: Checking group summary information
11Free blocks count wrong for group #0 (23503, counted=23481).
12Fix<y>? yes
13Free blocks count wrong for group #16 (24544, counted=24540).
14Fix<y>? yes
15Free blocks count wrong for group #17 (32768, counted=32759).
16Fix<y>? yes
17Free blocks count wrong (16369539, counted=16369504).
18Fix<y>? yes
19Free inodes count wrong for group #0 (8180, counted=8176).
20Fix<y>? yes
21Free inodes count wrong for group #16 (8192, counted=8180).
22Fix<y>? yes
23Directories count wrong for group #16 (0, counted=4).
24Fix<y>? yes
25Free inodes count wrong (4194292, counted=4194276).
26Fix<y>? yes
27Padding at end of inode bitmap is not set. Fix<y>? yes
28Block bitmap differences: Group 0 block bitmap does not match checksum.
29FIXED.
30
31RETRO: ***** FILE SYSTEM WAS MODIFIED *****
32RETRO: 28/4194304 files (3.6% non-contiguous), 407712/16777216 blocks

Since any further klog was lost, I've no idea what might happened to the backing partition at that time leading to this...

On the other hand, I guess it's probably the time to consider the function to gracefully shutdown or reboot from RetroOS.
When performing shutdown or reboot, the mounted partitions should be properly unmounted during the process.

was this the latest release? i had a bug in dma shared with nvme that i subsequently fixed in a new release

btw "shutdown" command in command.com makes it save to turn off.

Few suggestions about minor things.

1) Logs are saved with Unix style LF line ends, something that DN's editor manages, but most DOS editors does not, I think that changing this to CR+LF doesn't involve a lot of coding, while beeing a valuable improvement

2) Speaking of logs, now that we have not overwriting a "maxlog" setting may be worth to implement say with maxlog=10 the 11th log would start overwriting the 1'st log and so on, maxlog =1 would restore the of behavior of a single log taken, and maxlog=0 would disable the log.

Not a hig priority thing for sure, but worth to take in account.

3) The USB image has now two fat32 partitions, the first one marked as EFI (EF) partition the second as a plain fat32 (C).
Having the EF partition isn't really needed, in our case a single C partition would be more than enough, and will be visible on older Windows that are confused by two partitions on a removable device.

Two partitions are really needed when the second partition has an unsupported FS by the UEFI like, say BTRFS or ext4.

gsos wrote on Today, 05:14:

was this the latest release? i had a bug in dma shared with nvme that i subsequently fixed in a new release

btw "shutdown" command in command.com makes it save to turn off.

Okay... I think I was on eb451ba which apparently made my CT2290 working.

Will retest the latest commit, though it certainly would be better if additional SB mixer options can be controlled from F12 menu along with master volume.

Should be good enough for me to conduct real/emulated SB cross-tests on my B75 system.

The Solutor wrote on Today, 07:25:

3) The USB image has now two fat32 partitions, the first one marked as EFI (EF) partition the second as a plain fat32 (C).
Having the EF partition isn't really needed, in our case a single C partition would be more than enough, and will be visible on older Windows that are confused by two partitions on a removable device.

Two partitions are really needed when the second partition has an unsupported FS by the UEFI like, say BTRFS or ext4.

I think the first partition being EF is probably meant for enabling BIOS/UEFI dual boot.
While the two partitions now have distinct UUIDs, Linux for still doesn't show the first partition by default, likely because of its ESP role.
Though this is not something very important as I can always mount it manually either via command line or using tools such as GNOME Disk Utility.

LSS10999 wrote on Today, 09:43:

I think the first partition being EF is probably meant for enabling BIOS/UEFI dual boot.
While the two partitions now have distinct UUIDs, Linux for still doesn't show the first partition by default, likely because of its ESP role.

As I already explained earlier, you don't even need a GPT partitioning scheme, you need just a supported FS and the EFI folder, where fat32 is the bare minimum, common to all platform, but most UEFI implementation will just boot from NTFS, for example. Then corner cases of too strict implementations of the UEFI guidelines (or misinterpretation of them) are always possible, but personally I have to encounter one.

Though this is not something very important as I can always mount it manually either via command line or using tools such as GNOME Disk Utility.

I'm talking about Windows hosts, and even in Linux a simpler setup is always better than a more complicate one. KISS...

gsos wrote on Today, 05:10:

superfury wrote on Today, 04:10:

Yeah, port E9 is supported and implemented (and even extended with a special interface at port EAh which is enabled by writing a […]
Show full quote

gsos wrote on Today, 01:47:

Wow this is really useful. Okay from the log it seems like the VBE doesn't properly support direct bank-switching. I've released a new one that just uses the standard int path. With a best effort to produce a text mode panic in this case. This exposed a subtle issue in rust panic handler, I dont have access to the local wrapped bios VM86 needed to switch to text mode. Need to think about this, luckily if all goes well panics should happen less and less. It should appear in the klog on disk.

btw. can unipcemu support port E9 like bochs/qemu then one can see this kind of errors immediately.

Yeah, port E9 is supported and implemented (and even extended with a special interface at port EAh which is enabled by writing a string read from port EA(which is FFh terminated instead of NULL-terminated, but written to the debug E9 port with a newline after it (which activates the command interface for the emulator at I/O port EAh and EBh, with EBh reads returning EBh (also used for triggering hardware logging being armed with appropriate commands))). Port ECh is a simple 8/16/32-bit port usable for diagnostic writes and readback (used to test I/O ports safely). There's also a qemu logging port (I/O port 402h alias of E9h for writes only), but that will need to be enabled with a command line parameter (debuggerqemu).
The EBh/ECh I/O ports were added in later commits since the last release version. I/O port EBh can be detected by reading from it and it returns EBh (fully confirmed if EAh gives back a non-empty string instead of a floating bus(0xFF) for at least 1 reads (indicating some text being stored into it to trigger the port EAh to become a proper command interface)). Port ECh can be detected by writing data to it and reading it back (it's just a simple 8/16/32-bit I/O buffer for diagnostics), but doesn't exist if the other 3 I/O ports (E9h, EAh and EBh) don't exist. Also, writing the string read from EAh to port E9h to activate the EAh interface (also resetting it to it's initial command mode ready state) isn't logged of course (it's detected and parsed as a special command line for the emulator. All other whole lines logged using port E9h (terminated with newline as \r, \n, \r\n or \n\r) are normally logged to the (default) logging file. The command interface at EAh can be used to change the filename of the logging to something else (defaults to "porte9").

Edit: Found it indeed generated a log:

The attachment porte9.log is no longer available

you didn't run the last release? i added a fix in the newer version this seems to be the previous release

I keep try to use the latest RetroOS image, but don't always know there's a new version to download.
On UniPCemu, I'm always on the latest commit of it's repisitory (as I'm working on it). The official release version of that is already a few years ago due to me trying to get the bugs out before doing a proper release (which keeps eluding me for some reason, unless I'm chasing ghosts). I know there's protected mode issues (or maybe even real mode somehow), but I can't figure out where it's going wrong (with Windows 3.x/BIOS FPU misdetection and Windows 9x in-GUI crashes that are new to the new protected mode's through-the-BIU way of working). All testsuites I throw at it don't report anything weird (and somehow the BIOS seems to detect a FPU where there is none, causing mayhem on FPU emulation going missing (not enabled), executing invalid instructions on apps requiring it due to a missing FPU).

The Solutor wrote on Today, 10:54:

but most UEFI implementation will just boot from NTFS, for example.

Personally I've never seen a board that allowed UEFI booting directly from NTFS without relying on a FAT32 ESP. NTFS by default can only be used for BIOS/CSM booting.
Though the ESP (and boot/active partition) does not have to be the first physical partition of a disk.

USB disk creators like Rufus and Ventoy put their own stuffs in the (FAT32) ESP which is placed at the end of the disk as a second partition, taking up a small amount of space.
The first partition is used for normal data, formatted as either NTFS or exFAT. Older Windows versions than Win10 don't handle additional partitions than the first one, so the resulted stick can continue to be used as usual in such environments, and the boot partition will not be touched under normal circumstances there.

However, since RetroOS is now shipped directly as a USB IMG file it needs to be kept as minimal as possible so as to be able to be written to USB sticks of any common size.
With the boot partition on the first one and a data on the second, the data partition can be resized at will without breaking anything.
The downside, as mentioned before, would be that you need at least Win10 to access the second (data) partition. This is not an issue with Linux, though.

Putting the boot partition on the second one (with the first one meant for data) is another story.
You need to first move the boot partition further rightwards, then resize the main data partition to fill the gap.
UEFI booting usually doesn't mind, but BIOS boot may break as a result, depending on the underlying MBR boot code logic.

Regardless, at present RetroOS doesn't have proper USB mass storage support so the data partition is mostly useful for transferring files (including klogs), not as a backing partition.

Okay few updates
- I made usb a single partition as the simplest setup for now.
- Added Wave/FM sound blaster volume control
- Added some sort of unicode support so that the arrows are displayed correctly, this refactor also factored the code such that the codepage was just a table. So added a few more common codepages so europeans can use those.
- Added better windows file support so MC is displaying size/mtime properly
- I fixed the garbage left in the screen when switching between windowed/fullscreen and give the windows a small frame to make the compositing a bit more apparent.

The disk corruption is concerning but i hope it was the one release i pushed that fixed the sb dma but causing a dma conflict with disks. I hope you wont encounter it again.

LSS10999 wrote on Today, 11:32:

Personally I've never seen a board that allowed UEFI booting directly from NTFS without relying on a FAT32 ESP.

Very likely it's because you never tried, just like 99% of the users, but being unlucky is also a a possibility.

NTFS by default can only be used for BIOS/CSM booting. Though the ESP (and boot/active partition) does not have to be the first […]
Show full quote

NTFS by default can only be used for BIOS/CSM booting.
Though the ESP (and boot/active partition) does not have to be the first physical partition of a disk.

USB disk creators like Rufus and Ventoy put their own stuffs in the (FAT32) ESP which is placed at the end of the disk as a second partition, taking up a small amount of space.
The first partition is used for normal data, formatted as either NTFS or exFAT. Older Windows versions than Win10 don't handle additional partitions than the first one, so the resulted stick can continue to be used as usual in such environments, and the boot partition will not be touched under normal circumstances there.

The small partition used by default by MS since the Vista days (so way before UEFI and GPT were things) is there to allow booting of OS even if residing on an encrypted partition, which obviously wouldn't be possible on a single encrypted partition, but that's not a concern in our case.

However, since RetroOS is now shipped directly as a USB IMG file it needs to be kept as minimal as possible so as to be able to be written to USB sticks of any common size.
With the boot partition on the first one and a data on the second, the data partition can be resized at will without breaking anything.
The downside, as mentioned before, would be that you need at least Win10 to access the second (data) partition. This is not an issue with Linux, though.

Sure, but, a single partition is even simpler.

Putting the boot partition on the second one (with the first one meant for data) is another story.
You need to first move the boot partition further rightwards, then resize the main data partition to fill the gap.
UEFI booting usually doesn't mind, but BIOS boot may break as a result, depending on the underlying MBR boot code logic.

That would be a complication, not a simplification, but even in that case, the bcdboot command is your friend, just rerun it after any partition change that may break the bootability in MBR schemes.

P.S. speaking of bcdboot on GPT partitions, you can check yourself that something like bcdboot C:\Windows /s C: /f UEFI will happily create the EFI folder and whatever is needed to boot on your NTFS formatted C:. If that was forbidden it would have returned an error

Regardless, at present RetroOS doesn't have proper USB mass storage support so the data partition is mostly useful for transferring files (including klogs), not as a backing partition.

We already discussed that with gsos, the main point of having a simpler scheme (gsos made it already simpler than it was) is to ease the access from another OS not RetroOS itself, at least until removable USB units will be properly supported.

gsos wrote on Today, 14:13:

Okay few updates - I made usb a single partition as the simplest setup for now. - Added Wave/FM sound blaster volume control - […]
Show full quote

Okay few updates
- I made usb a single partition as the simplest setup for now.
- Added Wave/FM sound blaster volume control
- Added some sort of unicode support so that the arrows are displayed correctly, this refactor also factored the code such that the codepage was just a table. So added a few more common codepages so europeans can use those.
- Added better windows file support so MC is displaying size/mtime properly
- I fixed the garbage left in the screen when switching between windowed/fullscreen and give the windows a small frame to make the compositing a bit more apparent.

The disk corruption is concerning but i hope it was the one release i pushed that fixed the sb dma but causing a dma conflict with disks. I hope you wont encounter it again.

Great, I'm going to test the new image ASAP 😉

Ok tested the new image briefly.

It's working both in UEFI and BIOS mode, which is good

It's 60MB smaller which is very good, especially because the time required to flash it on slower pendrives

But you forgot to set the partition type to C, so it's not accessible by default in windows.

Just use fdisk /dev/sdx --> T --> C -->W to set it as normal fat32 partition, it will change nothing from ReactOS POV, but windows will assign a letter to it w/o resorting to command line's diskpart, each time.

The keyboards still work as we discussed earlier, but as long as in UEFI I can use my white keyboard it's ok for me, we can look at the matter in the future.

The shutdown command is nice to have, but still the fat32 partition accessed on the HDD is marked as dirty, windows will check it after reactos ran, and it will find no errors.

MC still seems a no go for me, but I haven't experimented a lot with it, yet.

gsos wrote on Today, 14:13:

Okay few updates - I made usb a single partition as the simplest setup for now. - Added Wave/FM sound blaster volume control - […]
Show full quote

Okay few updates
- I made usb a single partition as the simplest setup for now.
- Added Wave/FM sound blaster volume control
- Added some sort of unicode support so that the arrows are displayed correctly, this refactor also factored the code such that the codepage was just a table. So added a few more common codepages so europeans can use those.
- Added better windows file support so MC is displaying size/mtime properly
- I fixed the garbage left in the screen when switching between windowed/fullscreen and give the windows a small frame to make the compositing a bit more apparent.

The added Wave/FM sound blaster volume control works as expected. I can make the wave and FM volume a bit more balanced now.
Mix through SB doesn't seem to work at the moment. I'm not getting any sound output. I couldn't find anything of importance in the klog regarding this.
MIDI works in some games but not others. Not sure if it actually uses the MIDI hardware (e.g. Wave Blaster compatible daughterboards) in native mode.

Some games that previously didn't work with emulated SB works with the actual one:
- Titus the Fox music (with sound effects) plays through the actual SB FM instead of PC speaker.
- Tyrian 2000 correctly picked up the actual SB hardware.
- Unpatched Duke Nukem II works with sound (ADPCM samples). Played through a whole level and did not encounter any hang that I once had on native DOS.

It seems actual SB retains most of the behavior observed in native DOS, and it works a bit better in RetroOS in some cases.
1. Digital sound effects sometimes cut off in Wolf3D engine games with SB16, but in RetroOS it doesn't take too long to recover from it.
This appears to only affect Creative SB16 cards AFAICT. On SB (mostly SBPro) compatible cards of other vendors, like ESS, Avance Logic, this issue doesn't manifest as much as SB16.
2. Nova 9, when configured to use "Sound Blaster" instead of "Adlib" for sound, results in no sound and stuck animation.
This is a known issue, already observed on real SB compatible hardware on native DOS so it's not an issue with RetroOS itself.
For some reasons "Sound Blaster" mode works fine (just like Adlib mode) with emulated SB.

Though I do have a feeling that the system's responsiveness isn't stable.
- FM music plays slower than usual in some cases such as Duke3D.
- While Tyrian 2000 works with the actual SB16, music playback kind of hangs in the menu, and the whole games hangs right after entering a level, requiring killing via F12.
- Some games' setup program don't seem to update the interface in a timely manner when choosing options. In Wacky Wheels' SETUP, the highlighted line is actually the previously selected option, not the current one, so pressing ENTER may result in opening the wrong menu or perfoming the wrong action.

gsos wrote on Today, 14:13:

The disk corruption is concerning but i hope it was the one release i pushed that fixed the sb dma but causing a dma conflict with disks. I hope you wont encounter it again.

I'm not seeing any actual disk corruption this time, but I observed that sometimes games would complain about being unable to load files (usually the game's SETUP program).
The issue is not always reproducible, as on subsequent launches of these programs the files are read successfully.
Not sure about the performance with NVMe backing partition compared to SATA ones, but on my B75 the SATA controller is in IDE mode and RetroOS doesn't pick it up for some reasons.

I added partition type and I support two keyboard inputs now, but it's not hot pluggable they are detected at boot only.

I think MC is working now, I had the necessary windows dll's in the wrong place on the image.

LSS: Overall I'm pleased things start working better and better.

Some questions: Can you freely toggle back and forth between "native sb" and "hda kernel mixing" while a game is running? If Tyrion doesn't run with emulated sb, does it work toggling to emulated sb mid game when initialization/detection already happened? When in native mode, midi is send to actual MPU from the SB so that won't necessarily work if not backed by a synth. I updated so that we can separately emulate the general midi even in native sb mode.