Here is what it outputs under DosBox:

Why does it output different from FreeDOS running under QEMU?

If you run your program in a debug build of DOSBox, the log messages it produces give you an excellent clue about one problem. The compiled program is using FPU opcodes that DOSBox does not emulate, e.g. FCOMIP that is only found on Pentium Pro and later. I think you may need to set the target CPU to 486 or Pentium when compiling in DJGPP, but I don't know the details of how to do that. Anyway, the CPU/FPU compile target is a good place to start, but there may be other issues after you fix that one. The fact that you have long filenames also suggests you're not using MS-DOS 5 or 6, which is what DOSBox targets.

ripsaw8080 wrote on 2020-06-23, 20:28:

If you run your program in a debug build of DOSBox, the log messages it produces give you an excellent clue about one problem. The compiled program is using FPU opcodes that DOSBox does not emulate, e.g. FCOMIP that is only found on Pentium Pro and later. I think you may need to set the target CPU to 486 or Pentium when compiling in DJGPP, but I don't know the details of how to do that. Anyway, the CPU/FPU compile target is a good place to start, but there may be other issues after you fix that one. The fact that you have long filenames also suggests you're not using MS-DOS 5 or 6, which is what DOSBox targets.

Damn, the compiler I've made for my programming language relies on "fcomip" for every floating-point comparison.

Ah, well, if running in DOSBox is important to you then perhaps recoding for FCOMP is a possibility, although you may find working with the FPU flags more cumbersome than with EFLAGS.

ripsaw8080 wrote on 2020-06-23, 21:06:

Ah, well, if running in DOSBox is important to you then perhaps recoding for FCOMP is a possibility, although you may find working with the FPU flags more cumbersome than with EFLAGS.

Well, it's not that important to me. I assumed it had something to do with the inline assembly I put in my program, not with the code my compiler generates.

@FlatAssembler you may want to try with dosbox-x, it has a cputype=ppro_slow

_Rob wrote on 2020-06-24, 12:29:

@FlatAssembler you may want to try with dosbox-x, it has a cputype=ppro_slow

I mean, I can run my program in QEMU and VirtualBox. It's just that I hoped DosBox was an easy way for my future employers who will review my code to run it. Now they will most likely say they don't know if it works. Well, fair enough, I've done enough stuff already, I think.

Do you perhaps happen to know, what would be the easiest way to modify my AEC-to-x86 compiler (you can run the core of it in browser: https://flatassembler.github.io/compiler ) to be able to target i486? Right now, I think it targets i486, except relying on the `fcomip` instruction which exists only on i686 and newer. At first I thought I might replace `fcomip` with something like:

1fsubp
2fist dword [result]
3cmp dword [result],0

But the problem with that is that I'd also need to replace every `ja` with `jg` and every `jb` with `jl`, which, given the way the compiler is structured, is not a simple task (I'm afraid it's too error-prone). Do you have a better idea?
Is there a way to push FPU flags (ones affected by `fcomp`) and pop them into CPU flags that would work on both i486 and 64-bit x86 processors?

FCOMIP just saves you the work of manipulating EFLAGS, so you could use FCOMP and merge the condition flags the hard way, for example:

1fcomp
2push ax
3fstsw ax
4mov al,ah
5lahf
6and ax,0ba45h
7or ah,al
8sahf
9pop ax

Maybe make it a subroutine if used a lot.

ripsaw8080 wrote on 2023-01-06, 16:59:

FCOMIP just saves you the work of manipulating EFLAGS, so you could use FCOMP and merge the condition flags the hard way, for ex […]
Show full quote

FCOMIP just saves you the work of manipulating EFLAGS, so you could use FCOMP and merge the condition flags the hard way, for example:

Copy code to clipboard

1fcomp
2push ax
3fstsw ax
4mov al,ah
5lahf
6and ax,0ba45h
7or ah,al
8sahf
9pop ax

Maybe make it a subroutine if used a lot.

Thank you, I've tried it and now the Analog Clock program works under DosBox. I don't quite understand your code, though. What does `0ba45h` mean?

0ba45h masks the EFLAGS bits in AH to retain and the FPU condition flag bits in AL to merge. It takes advantage of the fact that the condition flags (carry, parity, zero) are in the same relative positions in both registers, which is almost certainly by design. Note that I didn't include the overflow flag because I'm not sure it has the same meaning in both registers.

Not sure what exactly this program is supposed to do ... seems to just draw an analog clock.
(although at 60+k it seems kinda big to just do that -- must be some other functions? - sorry
haven't spend the time to go through all the files)

FWIW You definitely don't need floating point to do an analog clock.

I threw together a very simple program to do this, it just draws a clock (in VGA 640 x 480), and
updates it to keep matching the current time - quick job, no guarantees of "bug free" etc.
-- and yes, it works fine in DosBox

I've included both the executable, and Micro-C source code - available from my site!

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

DaveDDS wrote on 2023-02-03, 05:51:

- quick job, no guarantees of "bug free" etc.

Yeah - about line 96 - "(i*2333)/1000" should have been: "(i*2333)/100"

I have replaced the .ZIP in the original post with a corrected one.

Kinda fun to play with - I don't recall ever doing such a straight analog time display before!

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)