Undefined behavior for ABCD and SBCD

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Undefined behavior for ABCD and SBCD

Post by Mask of Destiny » Sun Mar 19, 2017 10:43 pm

flamewing wrote:So, I decided to conduct my own investigation into this issue, and did some HW tests, patent investigation, and number crunching; and after doing all that, I discover this thread, in which I confirm my findings that every single emulator does it wrong.
Even BlastEm? I admittedly haven't done an exhaustive test of every single value, but I did test the "interesting" edge cases and it should be producing the same results and flags as hardware as of 0.4.0. If you have a case it fails on, I would be very interested.

flamewing
Very interested
Posts: 56
Joined: Tue Sep 23, 2014 2:39 pm
Location: France

Re: Undefined behavior for ABCD and SBCD

Post by flamewing » Mon Mar 20, 2017 2:47 pm

Mask of Destiny wrote:Even BlastEm?
Yes, every emulator. Although to be fair, BlastEm does better than most and passes all abcd and nbcd tests, failing only on sbcd:
Image
First four rows are the number of errors per instruction; "value" is how many results were wrong, "flags" is how many flags were wrong. Maximum number of errors is $40000 for abcd/sbcd, $400 for nbcd, meaning complete failure on all tests.

The other rows are the first few errors found. The first column are starting flags, then follows the instruction and parameters, then the result (green is a match, red is an error), output flags (each flag is either red or green, depending on whether it is right or not) and the last couple columns are the expected results and flags.

This is the ROM, in case anyone wants to test on emulators.

My guess is that BlastEm is checking (probably indirectly) for decimal validity in sbcd, which gives an incorrect correction factor.

Edit: Oh: and the flags are uppercase if set (1), lowercase if clear (0).
Last edited by flamewing on Mon Mar 20, 2017 9:40 pm, edited 1 time in total.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Undefined behavior for ABCD and SBCD

Post by Mask of Destiny » Mon Mar 20, 2017 5:23 pm

flamewing wrote:My guess is that BlastEm is checking (probably indirectly) for decimal validity in sbcd, which gives an incorrect correction factor.
Ah, you're totally right. Sorry, I should have read your first post more carefully about the asymmetry between abcd and sbcd when it comes to calculating corf. I clearly didn't choose my test cases well enough for sbcd.

Thanks for doing all that investigation and for the thorough test ROM!

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Re: Undefined behavior for ABCD and SBCD

Post by r57shell » Mon Mar 20, 2017 5:48 pm

flamewing wrote:This is the ROM, in case anyone wants to test on emulators.
My ROM have same goal, but:
1) it has source
2) it has easier bcd implementation
AFAIR it has correct bcd implementation
Image

flamewing
Very interested
Posts: 56
Joined: Tue Sep 23, 2014 2:39 pm
Location: France

Re: Undefined behavior for ABCD and SBCD

Post by flamewing » Mon Mar 20, 2017 9:58 pm

FYI, I reuploaded the ROM because, as it turns out, I had an earlier nonworking version layout around which got uploaded instead.
r57shell wrote:My ROM have same goal, but:
1) it has source
2) it has easier bcd implementation
AFAIR it has correct bcd implementation
I can easily post the source for mine; but since it was done in pure assembly with a binary table generated by the above C code I posted (for speed reasons), there is little benefit.

I will check out your BCD implementation to see how accurate it is; but you did ask "Someone please make correct implementation of abcd_emu and sbcd_emu" on the post before, so I figured it would be inaccurate.

I will say that easier is a relative term; I consider my implementation to be pretty straightforward. But then again, I am used to bit-level hacks.

My implementation has the advantages that it is branchless (even "rr != 0" can be computed without a branch), computes everything in parallel whenever possible, and closely mirrors what the hardware likely does. The first two are pretty important for emulator speed because they make the code faster; the latter would be useful for writing an emulator that does microcode-level emulation.

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: Undefined behavior for ABCD and SBCD

Post by HardWareMan » Tue Mar 21, 2017 6:16 am

I do not understand, hasn't anyone looked at the CPU die shots yet?
Basic die shots. Then, Quietust has made a great contribution by isolating the metal traces. Olivier Galibert was able to make use of this layer image, with a few corrections, to produce a full transistor-level schematic of the 68000. In result, here the interactive map. You can look at ALU under the magnifying glass. I don't see any problem in getting true behavior without guessing.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Re: Undefined behavior for ABCD and SBCD

Post by r57shell » Tue Mar 21, 2017 10:20 am

flamewing wrote:I can easily post the source for mine; but since it was done in pure assembly with a binary table generated by the above C code I posted (for speed reasons), there is little benefit.
Okay. Speed reasons hmm.
flamewing wrote:I will check out your BCD implementation to see how accurate it is; but you did ask "Someone please make correct implementation of abcd_emu and sbcd_emu" on the post before, so I figured it would be inaccurate.
It would be nice.
But you never said whether your ROM pass tests on original MD (not clone).

I have no flashcart, so I had to ask mate run my ROM on his MD. AFAIR it wasn't show any incorrect result. But it had strange issue with loop...

Branchless is nice. But my goal was to get high level interpretation in first place. And only after, everyone will be able to optimize at wish.
HardWareMan wrote:I do not understand, hasn't anyone looked at the CPU die shots yet?
Didn't know about any of this links.
Image

flamewing
Very interested
Posts: 56
Joined: Tue Sep 23, 2014 2:39 pm
Location: France

Re: Undefined behavior for ABCD and SBCD

Post by flamewing » Tue Mar 21, 2017 11:07 am

HardWareMan wrote:I do not understand, hasn't anyone looked at the CPU die shots yet?
Basic die shots. Then, Quietust has made a great contribution by isolating the metal traces. Olivier Galibert was able to make use of this layer image, with a few corrections, to produce a full transistor-level schematic of the 68000. In result, here the interactive map. You can look at ALU under the magnifying glass. I don't see any problem in getting true behavior without guessing.
Ah, yes, because looking at completely unlabelled transistor-level schematics and figuring out what each transistor is doing, and what signal each wire corresponds to, is extremely easy.

Edit:
r57shell wrote:Okay. Speed reasons hmm.
Well, my ROM does test every possible input combination (0-255 in each register, plus all four combinations of X and Z values); so computing as little as possible in the hardware makes the test take some 10-15 seconds instead of several minutes.
r57shell wrote:But you never said whether your ROM pass tests on original MD (not clone).
It was made with data obtained from real hardware; so I left implied that it passed. But to be more explicit: I had a few people test it with their flashcarts on real hardware, and the ROM passes every abcd, sbcd and nbcd test. So the code I gave matches real hardware on every possible input combination.

Edit 3: The ROM was tested on both Genesis model 1 and Genesis model 3 VA2. All tests pass on both.

Edit 2:

@r57shell: I looked into your abcd and sbcd code. Your abcd code is correct, and gives correct results and flags for all inputs.

Your sbcd code, on the other hand, is almost as bad as it can be (maximum possible error count is $40000 for results and $40000 for flags):

Code: Select all

		errors value  flags
		abcd  $00000 $00000
		sbcd  $3F578 $39CE4
XnzvC sbcd $00,$00=$01 xnzvc ($99 XNzvC)
XnZvC sbcd $00,$00=$01 xnzvc ($99 XNzvC)
XnzvC sbcd $01,$00=$02 xnzvc ($00 xnzvc)
XnZvC sbcd $01,$00=$02 xnzvc ($00 xnZvc)
XnzvC sbcd $02,$00=$03 xnzvc ($01 xnzvc)
XnZvC sbcd $02,$00=$03 xnzvc ($01 xnzvc)
[261518 lines skipped]
Which is actually not surprising: the sbcd_emu code is actually adding the two numbers and the carry. Fixing it to be subtracting both improves the results, but only slightly:

Code: Select all

		errors value  flags
		abcd  $00000 $00000
		sbcd  $2F000 $21A00
XnzvC sbcd $00,$00=$FF XNzVC ($99 XNzvC)
XnZvC sbcd $00,$00=$FF XNzVC ($99 XNzvC)
XnzvC sbcd $10,$00=$0F xnzvc ($09 xnzvc)
XnZvC sbcd $10,$00=$0F xnzvc ($09 xnzvc)
XnzvC sbcd $20,$00=$1F xnzvc ($19 xnzvc)
XnZvC sbcd $20,$00=$1F xnzvc ($19 xnzvc)
[203258 lines skipped]
Better, but still far to go.

Test source code.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Re: Undefined behavior for ABCD and SBCD

Post by r57shell » Tue Mar 21, 2017 12:58 pm

flamewing wrote:Ah, yes, because looking at completely unlabelled transistor-level schematics and figuring out what each transistor is doing, and what signal each wire corresponds to, is extremely easy.
Yes. For me, who is not familiar with transistor stuff is not easy to figure out what it is:
Image
I had to google "transistor notation schema", to find something close, but closest what I've found is here:
https://en.wikichip.org/wiki/cmos
This picture:
Image
Implying that those two types of elements on first picture corresponds to elements on this one...
I still have no idea. It makes no sense to me.

More details. I suggest two possibilities:
1) With thin line corresponds to element without circle, and element with bold line corresponds to element with circle.
Thus, in case if we have ground on pin from bottom, then bottom right element is closed, thus ground from nearest to it is opened and two other ones is closed, thus all vcc on picture is closed. it's okay.
In case if vcc on pin from bottom, then vcc at bottom right is open, thus nearest ground is closed and two other elements is opened, thus all vcc on picture is opened, but bottom left vcc opens top left ground thus top pin has ground & vcc opened at same time which is no sense to me.
2) With thin line corresponds to element with circle, and element with bold line corresponds to element without circle.
This case has similar confuse.

Edit: looks like I'm mixed up vcc and vdd. :s checking.
flamewing wrote:It was made with data obtained from real hardware; so I left implied that it passed. But to be more explicit: I had a few people test it with their flashcarts on real hardware, and the ROM passes every abcd, sbcd and nbcd test. So the code I gave matches real hardware on every possible input combination.
Nice! Awaiting full source :P.

I did kinda same but without generation, and relying on gcc.
Image

flamewing
Very interested
Posts: 56
Joined: Tue Sep 23, 2014 2:39 pm
Location: France

Re: Undefined behavior for ABCD and SBCD

Post by flamewing » Tue Mar 21, 2017 1:17 pm

r57shell wrote:Yes. For me, who is not familiar with transistor stuff is not easy to figure out what it is:
Image
I had to google "transistor notation schema", to find something close, but closest what I've found is here:
https://en.wikichip.org/wiki/cmos
This picture:
Image
Implying that those two types of elements on first picture corresponds to elements on this one...
I still have no idea. It makes no sense to me.
These are actually very different; that empty ball on the second image is an inverter. I am not sure what the thick line means on the top image, though.

But yeah, if the schematics corresponded directly to standard logic gates (and, or), it would be hard; but there are several transistor-level optimizations done at transistor level which muddy the issue a lot.
r57shell wrote:Nice! Awaiting full source :P.
I will prepare the source and put on GitHub, along with all other code I have related to this. I just have to clean a few things up (I have several code files with the abcd, sbcd and nbcd code, instead of splitting them out into their code files and linking, for example).

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Undefined behavior for ABCD and SBCD

Post by Mask of Destiny » Wed Mar 29, 2017 12:01 am

HardWareMan wrote:I do not understand, hasn't anyone looked at the CPU die shots yet?
I've spent some time looking at them trying to figure out the micro/nanocode layout. Made some progress (though it turns out Olivier had already done what I was doing and more, but just hadn't gotten around to uploading the updated files), but the end result didn't make sense. The patent has the reset microprogram at address 0 (very sensible), but the microcode chain starting at 0 didn't make sense for reset given what we know from the patent. That suggests either the address decoding matrix was transcribed wrong (possible, but my results matched Olivier's almost perfectly apart from one or two transcription errors), the organization of bits is wrong (can't remember if I traced the NMA outputs back to the address inputs, but I think I did) or the reset address is not 0 in the final chip (seems unlikely). I should revisit that again.

I haven't looked at the ALU though. For the most part, it's not very mysterious. Calculation of corf was admittedly not clear, but flamewing's test seems to have removed the remaining ambiguity there.
flamewing wrote:I am not sure what the thick line means on the top image, though.
IIRC, that's VCC.

Thanks for the test ROM by the way. Very helpful in fixing the remaining issues in BlastEm's sbcd implementation.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Re: Undefined behavior for ABCD and SBCD

Post by r57shell » Wed Mar 29, 2017 4:59 pm

Mask of Destiny wrote:
flamewing wrote:I am not sure what the thick line means on the top image, though.
IIRC, that's VCC.

Thanks for the test ROM by the way. Very helpful in fixing the remaining issues in BlastEm's sbcd implementation.
Question is what means element with thick line.
Image

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: Undefined behavior for ABCD and SBCD

Post by HardWareMan » Wed Mar 29, 2017 5:18 pm

It is dynamic load. Because this sample is more likely nMOS (or pMOS) and not CMOS. And second one (with only two elements) is pure CMOS. Here.
Image

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Undefined behavior for ABCD and SBCD

Post by Mask of Destiny » Wed Mar 29, 2017 5:26 pm

r57shell wrote:
Mask of Destiny wrote:
flamewing wrote:I am not sure what the thick line means on the top image, though.
IIRC, that's VCC.

Thanks for the test ROM by the way. Very helpful in fixing the remaining issues in BlastEm's sbcd implementation.
Question is what means element with thick line.
Oh, you mean the transistors with the thick lines. I think it might be to distinguish between enhancement mode and depletion mode, though I'm not sure which is which.
HardWareMan wrote:Because this sample is more likely nMOS (or pMOS) and not CMOS.
68000 is NMOS. The 68HC000 is CMOS, but I'm pretty sure it's the original chip that's been decapped.

flamewing
Very interested
Posts: 56
Joined: Tue Sep 23, 2014 2:39 pm
Location: France

Re: Undefined behavior for ABCD and SBCD

Post by flamewing » Fri Mar 31, 2017 11:57 pm

Here is the test ROM source.

Yes, I know, AS and all. It works.

Post Reply