https://www.bttr-software.de/forum/ DOS ain't dead en Reply from Japheth, 09.07.2026, 14:52:

> > > Did you run DebugD? Does it crash the same way?

Didn't test it, but it crashed in DEBUG.COM at an IRETD ( 32-bit IRET ). That instruction allows to set RF ( resume flag ) when returning to the debuggee. All Debug/X variants use this instruction if a 386+ cpu has been detected.]]> https://www.bttr-software.de/forum/forum_entry.php?id=23563 Thu, 09 Jul 2026 14:52:48 +0200 Reply from ecm, 09.07.2026, 07:45:

> > Did you run DebugD? Does it crash the same way?
>
> Don't know. What is DebugD?

Debug/X which doesn't hook interrupts 1 and 3, to allow debugging it: https://hg.pushbx.org/ecm/fddebug/file/809a6fbe45b6/MAKEX.BAT#l5]]> https://www.bttr-software.de/forum/forum_entry.php?id=23562 Thu, 09 Jul 2026 07:45:32 +0200 Post by rr, 08.07.2026, 21:24:

User DosWorld asked to make you aware of his recent "self-hosting Oberon-07 compiler for 16-bit MS-DOS real mode".

From README.MD:

===== WHY THIS EXISTS =====

There is no free, modern, actively-usable Pascal-family compiler that targets (and works) 16-bit MS-DOS real mode. Borland stopped at Turbo Pascal 7 / Borland Pascal 7 in the early '90s and never open-sourced it. FreePascal — the natural place to look — has supported 16-bit i8086 code generation since around 2014, but it was always the neglected back corner of the project: undermaintained, thin on runtime support, and never treated as a first-class target the way its 32/64-bit backends are. I had been waiting since the late 1990s for a serious free 16-bit target from the Pascal world (i8086-msdos in FreePascal was the closest anyone got, decades after the fact), and it never became something you could really build on.

So this project doesn't try to be that. It picks Wirth's other, smaller language — Oberon-07, Pascal's own successor — and builds a compiler for it from scratch, purpose-built for 16-bit DOS real mode, with no inherited 32-bit assumptions to work around. The compiler, linker, dependency scanner, archive manager, and test tools are all written in Oberon-07 and compile themselves, on the target architecture (8086 real mode), from a single checked-in bootstrap binary. Feed it its own source and it reproduces itself byte-for-byte — a full fixpoint, verified on every change.

That means:

* No hidden C runtime. SYSTEM.MOD + a small SYS.ASM are the entire foundation.
* No 32-bit protected-mode escape hatch. Real segmented 8086 memory, real 64 KB segments, real far pointers.
* A compiler that could, in principle, have been built in 1987 — but with the discipline of zero-heap-leak, byte-reproducible modern engineering practice behind it.

===== HIGHLIGHTS =====

* Self-hosting, byte-stable. toc /ENTRY=Run TOC.MOD rebuilds the whole compiler in a single process; two consecutive generations are byte-identical. See TESTS/test_selfhost.sh.
* Zero heap leaks, guaranteed. Every compile and every link reports 0 leaked paragraphs — enforced by LeakGuard instrumentation and regression tests, not just hoped for.
* All-in-one driver. toc.exe is the dep-scanner, incremental compiler, and smart linker in one binary and one command — no makefiles required to build an Oberon program.
* Real DOS constraints, handled properly. Per-module 64 KB code segments, far pointers (segment:offset), a large memory model, EMS-backed temp files, and a linker that streams instead of holding everything in RAM.
* 272-row regression manifest plus DOS-side executable and unit-test suites — every codegen change is checked against real compiled/linked/run output, not just "it compiled."
* Turbo Debugger-compatible debug info. Compile with (*$D+*), link with /G, and get a Borland TDS/TDINFO v2.08 block appended straight onto the .EXE — inspect with the included tdinfo.exe.
* Linkable with external assembly. The linker consumes standard RDOFF2 object files, so hand-written assembly modules assembled with NASM, YASM, or MSA2 (-f rdf) can be linked directly alongside Oberon-compiled .rdf/.om modules — no C shim required.

(…) Read more at https://github.com/DosWorld/toc/]]> https://www.bttr-software.de/forum/forum_entry.php?id=23561 Wed, 08 Jul 2026 21:24:32 +0200 Reply from Japheth, 08.07.2026, 21:19:

> Did you run DebugD? Does it crash the same way?

Don't know. What is DebugD?]]> https://www.bttr-software.de/forum/forum_entry.php?id=23560 Wed, 08 Jul 2026 21:19:26 +0200 Reply from ecm, 08.07.2026, 17:28:

> - even the totally innocent DEBUG.COM causes a reboot with cmd 'q' (Quit)

Did you run DebugD? Does it crash the same way?]]> https://www.bttr-software.de/forum/forum_entry.php?id=23559 Wed, 08 Jul 2026 17:28:01 +0200 Reply from Japheth, 08.07.2026, 15:32:

Just tried it a bit ( 3 games and a few applications ).

Positive:
- it passes my DPMI IRQ routing compliance test
- DOOM and Redneck Rampage work

Negative
- sound in ROTT isn't convincing
- HX Win32 emulation crashes
- even the totally innocent DEBUG.COM causes a reboot with cmd 'q' (Quit)

So it's in alpha stage.]]> https://www.bttr-software.de/forum/forum_entry.php?id=23558 Wed, 08 Jul 2026 15:32:01 +0200 Reply from Zyzzle, 07.07.2026, 10:08:

> 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.]]> https://www.bttr-software.de/forum/forum_entry.php?id=23557 Tue, 07 Jul 2026 10:08:49 +0200 Reply from Laaca, 06.07.2026, 09:50:

I contacted the author and he sent me the DJGPP binary so I added in into archive and reuploaded
I can confirm that the DJGPP build is faster. (with good DPMI server)]]> https://www.bttr-software.de/forum/forum_entry.php?id=23556 Mon, 06 Jul 2026 09:50:46 +0200 Reply from Laaca, 06.07.2026, 05:41:

The same guy who is developping the 3D modeler also works on paint program. It uses the same GUI which is nice but quite slow and memory hungry.
The GitHub page has only sources. I was able to compile it under OpenWatcom 1.4 and I uploaded the binary here
It works, the speed is on my Core2 duo 2,6GHz OK but I am afraid that on anything slower it would not be 100% fluent.
The author says that DJGPP builds are faster but I was not able to compile it with DJGPP as the compilation process raises many syntax errors.
I believe that I do not have the proper version of DJGPP so maybe someone with newer DJGPP (newer GCC) will be able to compile it.
I have 4.1.]]> https://www.bttr-software.de/forum/forum_entry.php?id=23555 Mon, 06 Jul 2026 05:41:46 +0200 Reply from RayeR, 06.07.2026, 05:06:

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
==========================================
]]> https://www.bttr-software.de/forum/forum_entry.php?id=23553 Mon, 06 Jul 2026 05:06:26 +0200 Reply from bencollver, 05.07.2026, 15:24:

> Have you seen https://github.com/noyesno/awka/ ?

Yes, that's the source code i am in the middle of porting to Watcom.]]> https://www.bttr-software.de/forum/forum_entry.php?id=23552 Sun, 05 Jul 2026 15:24:23 +0200 Reply from Laaca, 05.07.2026, 12:14:

Even the UPX 5.2.0 still can't pack FreePascal 3.x.y DOS executables :-(]]> https://www.bttr-software.de/forum/forum_entry.php?id=23551 Sun, 05 Jul 2026 12:14:20 +0200 Reply from jadoxa, 05.07.2026, 08:21:

Have you seen https://github.com/noyesno/awka/ ?]]> https://www.bttr-software.de/forum/forum_entry.php?id=23550 Sun, 05 Jul 2026 08:21:53 +0200 Reply from Rugxulo, 05.07.2026, 07:10:

Don't forget that common optimizations like -ox are the same as -obmiler -s (and turns off stack checking). Plus, being large model (and not flat), the stack is much smaller (4 kb?).]]> https://www.bttr-software.de/forum/forum_entry.php?id=23549 Sun, 05 Jul 2026 07:10:43 +0200 Reply from bencollver, 05.07.2026, 05:09:

> No, that's right, as the retf 0x0c pops the six pushes of the arguments
> (other functions don't have as many arguments, so they're wholly passed in
> registers). If you're getting stack corruption, it's not because of that.

Thanks for the hint, i think it will help.

The awka_insertop() declaration in da.c has 6 arguments:

void
awka_insertop(int op, char *cval, char *carg, int minst, char *file, int line)
{

The awka_insertop() prototype in code.c has 5 arguments:

void awka_insertop(int, char *, char *, int, int);

And dump_code() indeed calls it with 5 arguments instead of 6.

I guess it's GIGO and it's on me to fix it.]]> https://www.bttr-software.de/forum/forum_entry.php?id=23548 Sun, 05 Jul 2026 05:09:56 +0200