It's only about 90% working, but...

[Steve Nickolas]

https://github.com/buricco/lemur

I'm having trouble with the CPU core (there's two slightly different
variants of the core in the source). There's some other less significant
bugs. I'm trying to teach myself 8086 ASM, but with that said, I think
I've had the same issue with my C attempt at a 6502 core.

-uso.

[[e-mail]]

Do you have test-cases that reproduce the wrong behaviour(s)?

[[e-mail]]

Do you have test-cases that reproduce the wrong behaviour(s)?

[Steve Nickolas]

Post by ***@gmail.com
Do you have test-cases that reproduce the wrong behaviour(s)?

The monitor is unusable at this point.

With an Integer ROM, negative numbers result in a >32767 error.

With FPBASIC, decimals are computed incorrectly; NEXT results in NEXT
WITHOUT FOR even if there is a FOR; whole numbers that result in
scientific notation (i.e., 1000000000 or higher) cause FPBASIC to go off
the rails and appear to freeze.

-uso.

[[e-mail]]

Your overflow checking is wrong. That's causing the >32767 issue.
V is the result of the XOR of bits 6 and 7, not simply the value of bit 6.

[[e-mail]]

or, rather, result ^ 0x80 & original value & 0x80.

[Steve Nickolas]

Post by ***@gmail.com
or, rather, result ^ 0x80 & original value & 0x80.

Current code has same issue (non-macro version shown, macro version uses
%%4 and %%5 and "jmp" is omitted from the final line):

.4: or byte [rp], FLAG_V ; Unless [ra] and AL were same sign
mov ah, [ra] ; but output differs, set V.
and ax, 0x8080
xor ah, al
jnz .5 ; Inputs not the same sign: skip.
mov ah, bl
and ah, 0x80
xor ah, al
jnz .5 ; Output not the same sign: skip.
and byte [rp], ~FLAG_V
.5: mov al, bl
mov [ra], bl
jmp _setzn ; Set Z+N flags, then we're outtie

I've tested a couple ADCs' overflow bits (63+63, 64+64) between MAME and
my core.

-uso.

[[e-mail]]

mov ah, bl
xor ah, 0x80
and ah, [ra] ; but output differs, set V.
and ah, 0x80
jnz %%5 ; Output is different sign: skip.

[Vladimir Ivanov]

mov ah, bl
xor ah, 0x80
and ah, [ra] ; but output differs, set V.
and ah, 0x80
jnz %%5 ; Output is different sign: skip.

Interesting topic.

One funny approach I used when developing Apple II emulator on a XT circa 1990 was to directly keep N/V/Z/C/ in their 8086 counterparts, then use POPF/PUSHF and get free results whenever possible. There was also code to do fixups now and then, as expected.

Example of ROL:

// ...
popf
rcl byte ptr [bx], 1
pushf
// ...

Same holds true for bunch of other ALU operations.

Looking back, I could've went with more profiling and compare this approach to others, but then again I was just a kid - learning and having fun.

[Steve Nickolas]

Post by Vladimir Ivanov

mov ah, bl
xor ah, 0x80
and ah, [ra] ; but output differs, set V.
and ah, 0x80
jnz %%5 ; Output is different sign: skip.

Interesting topic.
One funny approach I used when developing Apple II emulator on a XT
circa 1990 was to directly keep N/V/Z/C/ in their 8086 counterparts,
then use POPF/PUSHF and get free results whenever possible. There was
also code to do fixups now and then, as expected.
// ...
popf
rcl byte ptr [bx], 1
pushf
// ...
Same holds true for bunch of other ALU operations.
Looking back, I could've went with more profiling and compare this
approach to others, but then again I was just a kid - learning and
having fun.

I believe that's what Randy Spurlock's emulator also did.

-uso.

[[e-mail]]

mov ah, bl
xor ah, 0x80
and ah, [ra] ; but output differs, set V.
and ah, 0x80
jnz %%5 ; Output is different sign: skip.

[[e-mail]]

My service provider has issues with newsgroups. The double-posting is not on purpose.

[Steve Nickolas]

Post by ***@gmail.com
My service provider has issues with newsgroups. The double-posting is not on purpose.

Ah, I've been using Eternal September since my *previous* ISP dropped them
(my current ISP dropped them around the same time but I wasn't with them
then).

-uso.

[[e-mail]]

Your overflow checking is wrong. That's causing the >32767 issue.
V is the result of the XOR of bits 6 and 7, not simply the value of bit 6.