DOS ain't dead

There's some progress of utilizing 2-cores under DOS - a new library for DJGPP:
https://github.com/arjunae/2core_dos

Also it seems include some 1st real dualcore app for DOS - a h264 video player...

---
DOS gives me freedom to unlimited HW access.

Black magic

---
DOS-u-akbar!

> There's some progress of utilizing 2-cores under DOS - a new library for
> DJGPP:
> https://github.com/arjunae/2core_dos
>
> Also it seems include some 1st real dualcore app for DOS - a h264 video
> player...

Hmm - 18 years ago, in 2008, someone added dual-core support into HX's kernel32 emulation dll ( dkrnl32.dll ) - and used it for their DOS applications ( he sent me the needed modifications in the source ). So the label "1st real dualcore app for DOS" has already been awarded long ago.

---
MS-DOS forever!

Why it was not adopted to official HX version? Or is already there and we don't know about it? :)

We know that Michael Chourdakis also experimented with dualcore many years ago but just a demo. Doing some heavy load like video decoding makes good sense for dualcore use. Maybe a challenge for new dugl player :)

---
DOS gives me freedom to unlimited HW access.

> Why it was not adopted to official HX version?

Can't remember what I thought back then. Judging from today I'd say it wasn't generic enough. Isn't it necessary to fully disable the PIC when the APIC is enabled? In DOS that can only be done with the help of a v86 monitor program, which was surely not done back then. So it probably was just a hack, working for a specific purpose only...

---
MS-DOS forever!

> We know that Michael Chourdakis also experimented with dualcore many years
> ago but just a demo. Doing some heavy load like video decoding makes good
> sense for dualcore use. Maybe a challenge for new dugl player :)

I'm planning a hybrid implementation of DUGL/DWorker concept: if ring 0 detected and if there is a free CPU core use it to start/run the DWorker, else start/run as a regular PThread thread. Let's see how far I can go but would be very interesting for heavy load apps as video decoding.

Thinking it shouldn't be much harder to use all available cores not just 2, when there are routines to send commands to specific APIC ID. Just need to probe all available APIC IDs and maybe classify them if they are physical cores or multithreading unit of one core. I think MPS tables should cover this. Not sure if modern MBs still support MPS 1.x or ACPI only. My MB supports MPS 1.4...

---
DOS gives me freedom to unlimited HW access.

> > We know that Michael Chourdakis also experimented with dualcore many
> years
> > ago but just a demo. Doing some heavy load like video decoding makes
> good
> > sense for dualcore use. Maybe a challenge for new dugl player :)
>
> I'm planning a hybrid implementation of DUGL/DWorker concept: if ring 0
> detected and if there is a free CPU core use it to start/run the DWorker,
> else start/run as a regular PThread thread. Let's see how far I can go but
> would be very interesting for heavy load apps as video decoding.
I thought the reason FFMPEG 6.0 couldn't be ported to DOS is that it requires pthreads and that this was previously "impossible" in DOS. There is no pthreads binary in DOS. Your idea of offloading the actual h.264 decoding onto a second core and doing the video stuff on the first core should speed up DUGL player a lot.

> I thought the reason FFMPEG 6.0 couldn't be ported to DOS is that it
> requires pthreads and that this was previously "impossible" in DOS. There
> is no pthreads binary in DOS. Your idea of offloading the actual h.264
> decoding onto a second core and doing the video stuff on the first core
> should speed up DUGL player a lot.

You can find djgpp pthread port under https://www.delorie.com/pub/djgpp/current/v2tk/fpth314b.zip but it's limited to a single CPU core.
Already FFMPEG 5.x support multi-threaded video decoding, but require a true multi-core pthread lib else it will be slower than using single core for decoding.

Did someone else tried the edge_pr.exe under DOS too?
I did, it seems started 2nd core and also switched to VESA mode but quits very soon. I guess it can play only a raw h264 video stream - not MP4 container?

[DBG loadBin] edge_wk.bin geladen via himem 217408 bytes -> Phys=0x0016BC00
[setupSys] memBase=0x0001B000 workerEntry=0x0016BC00
[setupSys] arg1=0x00022000 arg2=0x0001D000
--- VBE modes 1024x768 ---
  mode 104: 1024x768 4bpp LFB=no base=0
  mode 105: 1024x768 8bpp LFB=yes base=ef000000
  mode 117: 1024x768 16bpp LFB=yes base=ef000000
  mode 118: 1024x768 32bpp LFB=yes base=ef000000
-----------------------
VESA: mode 118  32bpp  pitch 4096  base ef000000
[startAp] cand=2 init assert...
[startAp] init deassert...
[startAp] SIPI 1...
[startAp] SIPI 2...
[startAp] waiting for AP...
[startAp] AP alive auf APIC-ID 2 (self-reported 2)

==========================================

Jobs 12481 Frames 0
Time 0.18 s FPS 0.00
CPU2 Log alive nal=12288 inH=31 inT=27 rH=0 rT=0 pushed=0
==========================================


---
DOS gives me freedom to unlimited HW access.

> Did someone else tried the edge_pr.exe under DOS too?
> I did, it seems started 2nd core and also switched to VESA mode but quits
> very soon. I guess it can play only a raw h264 video stream - not MP4
> container?
Yes, it requires .mp4 files to be demuxed into the raw elementary h.264 stream (.264 file). Even then I could not get it to run, as you seem to need to specify the exact resolution of your h.264 file. When I tried a 640x480 5mbps file, it crashed. On i5-8250 CPU with no MTRRs enabled but with LFB and VBE3.