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

56 views
Skip to first unread message

Steve Nickolas

unread,
Aug 10, 2022, 9:33:38 PMAug 10
to
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.

peter....@gmail.com

unread,
Aug 11, 2022, 2:16:43 PMAug 11
to
Do you have test-cases that reproduce the wrong behaviour(s)?

peter....@gmail.com

unread,
Aug 11, 2022, 2:16:58 PMAug 11
to

Steve Nickolas

unread,
Aug 11, 2022, 6:10:35 PMAug 11
to
On Thu, 11 Aug 2022, peter....@gmail.com wrote:

> 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.

peter....@gmail.com

unread,
Aug 11, 2022, 9:26:33 PMAug 11
to
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.

peter....@gmail.com

unread,
Aug 11, 2022, 9:26:48 PMAug 11
to

peter....@gmail.com

unread,
Aug 11, 2022, 9:32:08 PMAug 11
to
or, rather, result ^ 0x80 & original value & 0x80.

Steve Nickolas

unread,
Aug 11, 2022, 9:47:22 PMAug 11
to
On Thu, 11 Aug 2022, peter....@gmail.com wrote:

> 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.

peter....@gmail.com

unread,
Aug 11, 2022, 9:56:12 PMAug 11
to
mov ah, bl
xor ah, 0x80
and ah, [ra] ; but output differs, set V.
and ah, 0x80
jnz %%5 ; Output is different sign: skip.

peter....@gmail.com

unread,
Aug 11, 2022, 9:56:27 PMAug 11
to

peter....@gmail.com

unread,
Aug 11, 2022, 10:30:54 PMAug 11
to
My service provider has issues with newsgroups. The double-posting is not on purpose.

Steve Nickolas

unread,
Aug 11, 2022, 10:37:33 PMAug 11
to
On Thu, 11 Aug 2022, peter....@gmail.com wrote:

> 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.

Vladimir Ivanov

unread,
Aug 13, 2022, 2:30:42 AMAug 13
to
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

unread,
Aug 13, 2022, 8:55:58 AMAug 13
to
I believe that's what Randy Spurlock's emulator also did.

-uso.
Reply all
Reply to author
Forward
0 new messages