Nice. I'm thinking why didn't the SBEmu project take this approach? It would be less intrusive to games and better resemble a "hardware" sound card... at least from DOS's perspective.

oooo.. I wonder what results would be on a socket 5 pentium...

Probably "No APIC" 😉

wbahnassi wrote on 2025-12-13, 16:03:

Nice. I'm thinking why didn't the SBEmu project take this approach? It would be less intrusive to games and better resemble a "hardware" sound card... at least from DOS's perspective.

I already suggested something like this as a possible use-case in my README.md

The second core would appear to the main core/DOS as regular device doing DMA (like a real SB in ISA Slot). The second core could be translating this to a HD Audio or AC97 on PCI(e)

One reason why they probably didn't do it like this is, because you have to do some real assembler magic (taps own should). Afaik no one has done this as of today.

But it shouldn't be too hard for SBEmu project to adapt with this ready on hand now.

thewhiteambit wrote on 2025-12-13, 17:29:

But it shouldn't be too hard ...

man... If I had a dollar...

But to your reply about "no APIC" the board I'd test this on has one.

The notion of using another core on an SMP system to do the dirty work DID actually get briefly mentioned in the SBEMU thread(s), but nobody wanted the headache of trying it.

Since there is this lovely Proof of Concept here, with perfectly portable code though, I could see YetAnotherFork of SBEMU doing it, and then it getting backported later, much like the soundfont core was done.

luckybob wrote on 2025-12-13, 17:37:

thewhiteambit wrote on 2025-12-13, 17:29:

But it shouldn't be too hard ...

man... If I had a dollar...

But to your reply about "no APIC" the board I'd test this on has one.

So a Dual-Socket 5? Then you would need to comment/disable USE_64BIT_LONG_MODE, USE_PAGETABLE and locate WORKER_BASE somewhere inside the available ram (currently at 768MB with enough space for the additional WORKER_SIZE (effectively where the stack starts growing to lower memory) and compile by yourself. USE_16BYTE_EXCEPTION_IDT and USE_12BYTE_EXCEPTION_IDTR could be problematic as well.

Chances are still bad this will work with the APIC, but I can't tell from my head. But it would tell you about missing APIC then.

wierd_w wrote on 2025-12-13, 17:48:

The notion of using another core on an SMP system to do the dirty work DID actually get briefly mentioned in the SBEMU thread(s), but nobody wanted the headache of trying it.

Since there is this lovely Proof of Concept here, with perfectly portable code though, I could see YetAnotherFork of SBEMU doing it, and then it getting backported later, much like the soundfont core was done.

I would love to see that! They could even use the TSR as starting ramp and save some headaches. I must confess I am not well informed about the SBEmu project.

thewhiteambit wrote on 2025-12-13, 17:55:

So a Dual-Socket 5? Then you would need to comment/disable USE_64BIT_LONG_MODE, USE_PAGETABLE and locate WORKER_BASE somewhere inside the available ram (currently at 768MB with enough space for the additional WORKER_SIZE (effectively where the stack starts growing to lower memory) and compile by yourself. USE_16BYTE_EXCEPTION_IDT and USE_12BYTE_EXCEPTION_IDTR could be problematic as well.

Chances are still bad this will work with the APIC, but I can't tell from my head. But it would tell you about missing APIC then.

yea... You're speaking Greek to me now. Programming is completely outside of my skill set. What was your target hardware for this? if I might be so bold to ask.

luckybob wrote on 2025-12-13, 18:19:

thewhiteambit wrote on 2025-12-13, 17:55:

So a Dual-Socket 5? Then you would need to comment/disable USE_64BIT_LONG_MODE, USE_PAGETABLE and locate WORKER_BASE somewhere inside the available ram (currently at 768MB with enough space for the additional WORKER_SIZE (effectively where the stack starts growing to lower memory) and compile by yourself. USE_16BYTE_EXCEPTION_IDT and USE_12BYTE_EXCEPTION_IDTR could be problematic as well.

Chances are still bad this will work with the APIC, but I can't tell from my head. But it would tell you about missing APIC then.

yea... You're speaking Greek to me now. Programming is completely outside of my skill set. What was your target hardware for this? if I might be so bold to ask.

It is not really programming, just search for the macro definitions in dos64smp.asm, write a semicolon in front and compile with NASM command from the README.md

I mainly developed this on a M4 MacBook Pro under Windows in Parallels (I love having >12h battery life) and tested it on a Q9550 Core2Quad, a i7-7800X and E5-2699 v4 on X99 Chipset (the last CPU that has LPC with DMA)

Oh well reconfiguring the worker base may be a bit more complicated. Just tell me how much ram you have and I will provide something the coming days.

luckybob wrote on 2025-12-13, 18:19:

yea... You're speaking Greek to me now. Programming is completely outside of my skill set. What was your target hardware for this? if I might be so bold to ask.

I looked it up and chances aren't that bad that it will actually work on a Pentium P54C. Your Motherboard has to allow it by setting voltage on the APICEN pin. Assuming this is a dual Socket 5, that might be the case. I mean: What would be the point of having two CPUs if you can't possibly use them together? Would be interesting to see it running on the first ever APIC CPUs.

Just tell me the amount of Ram and the MHz of the CPUs and I will provide my best shot for that system.

Wow, this could result in a Voodoo emulation in Dos i assume? "Just" switch in a VBE Mode and fill the Framebuffer from the other core...

ElTentakel wrote on 2025-12-14, 10:50:

Wow, this could result in a Voodoo emulation in Dos i assume? "Just" switch in a VBE Mode and fill the Framebuffer from the other core...

At least in theory this is how this could work. In terms of SMP it would be quite simple to use multiple additional cores when present.

However, a full Voodoo emulation/simulation is probably a bit more complicated than pretending to be a SoundBlaster (or other Soundcard) and just passing the Audio-Data on to the actual Soundcard.

All the rendered etc. has to be implemented in Software and I think a 3Dfx Voodoo inter-process communication (via Glide or OpenGL) is also way more complicated than observing a DMA Buffer, Ports and Interrupts.

Hi,
Should this TSR work on AMD multicore systems?
I'm asking because I have tested it with Phenom II X4 and after 'Step3: Start SMP' it always reboots the system...

@Edit:
I have also tested this with an I7-4770k on a GA-Z97X-UD5H board and it works the 1st time after a cold boot. If I restart DOS with Ctrl+Alt+Del after 1st successful usage and start the TSR again then it does the same as on the Phenom II X4 system. That is it restarts the system after Step 3.

Falcosoft wrote on 2025-12-14, 11:37:

Hi,
Should this TSR work on AMD multicore systems?
I'm asking because I have tested it with Phenom II X4 and after 'Step3: Initializing SMP' it always reboots the system...

It should, but I had no AMD System to test on. This could be a timing issue. Timing for APIC is really strangely different on many CPUs. Look out for the timer macros and use the APIC timer maybe (comment Busy-Loop Timer with a semicolon and remove semicolon in front of APIC Timer definition).

I assume it has at least 1GB of Ram because the worker code is placed at 768MB.

It is a bit strange the crash is happening at STEP 3 already (prepare SMP) and not at start of SMP.

Falcosoft wrote on 2025-12-14, 11:37:

@Edit:
I have also tested this with an I7-4770k on a GA-Z97X-UD5H board and it works the 1st time after a cold boot. If I restart DOS with Ctrl+Alt+Del after 1st successful usage and start the TSR again then it does the same as on the Phenom II X4 system. That is it restarts the system after Step 3.

Strange observation. What happened when you try to run it a second time after successful run without rebooting?

thewhiteambit wrote on 2025-12-14, 12:00:

It should, but I had no AMD System to test on. This could be a timing issue. Timing for APIC is really strangely different on ma […]
Show full quote

Falcosoft wrote on 2025-12-14, 11:37:

Hi,
Should this TSR work on AMD multicore systems?
I'm asking because I have tested it with Phenom II X4 and after 'Step3: Initializing SMP' it always reboots the system...

It should, but I had no AMD System to test on. This could be a timing issue. Timing for APIC is really strangely different on many CPUs. Look out for the timer macros and use the APIC timer maybe (comment Busy-Loop Timer with a semicolon and remove semicolon in front of APIC Timer definition).

I assume it has at least 1GB of Ram because the worker code is placed at 768MB.

It is a bit strange the crash is happening at STEP 3 already (prepare SMP) and not at start of SMP.

Hi,
1. The system has 8 GB RAM.
2. STEP 3 is 'Start SMP'. I remembered incorrectly. STEP 2 is 'Initializize AP' (not SMP) and it seems to be working correctly.

thewhiteambit wrote on 2025-12-14, 12:03:

Falcosoft wrote on 2025-12-14, 11:37:

@Edit:
I have also tested this with an I7-4770k on a GA-Z97X-UD5H board and it works the 1st time after a cold boot. If I restart DOS with Ctrl+Alt+Del after 1st successful usage and start the TSR again then it does the same as on the Phenom II X4 system. That is it restarts the system after Step 3.

Strange observation. What happened when you try to run it a second time after successful run without rebooting?

It seems I can run many instances of the TSR without any problems in the same DOS session and the test application (DOS64USE.COM) can communicate with the active ones.
Maybe it's a BIOS quirk. I will try to determine what conditions are necessary exactly to reproduce the problem.