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 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.
Undefined behavior for ABCD and SBCD
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 615
- Joined: Thu Nov 30, 2006 6:30 am
Re: Undefined behavior for ABCD and SBCD
Re: Undefined behavior for ABCD and SBCD
Yes, every emulator. Although to be fair, BlastEm does better than most and passes all abcd and nbcd tests, failing only on sbcd:Mask of Destiny wrote:Even BlastEm?
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.
-
- Very interested
- Posts: 615
- Joined: Thu Nov 30, 2006 6:30 am
Re: Undefined behavior for ABCD and SBCD
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.flamewing wrote:My guess is that BlastEm is checking (probably indirectly) for decimal validity in sbcd, which gives an incorrect correction factor.
Thanks for doing all that investigation and for the thorough test ROM!
Re: Undefined behavior for ABCD and SBCD
Re: Undefined behavior for ABCD and SBCD
FYI, I reuploaded the ROM because, as it turns out, I had an earlier nonworking version layout around which got uploaded instead.
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.
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.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 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.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Re: Undefined behavior for ABCD and SBCD
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.
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.
Re: Undefined behavior for ABCD and SBCD
Okay. Speed reasons hmm.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.
It would be nice.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.
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.
Didn't know about any of this links.HardWareMan wrote:I do not understand, hasn't anyone looked at the CPU die shots yet?
Re: Undefined behavior for ABCD and SBCD
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.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.
Edit:
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:Okay. Speed reasons hmm.
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.r57shell wrote:But you never said whether your ROM pass tests on original MD (not clone).
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]
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]
Test source code.
Re: Undefined behavior for ABCD and SBCD
Yes. For me, who is not familiar with transistor stuff is not easy to figure out what it is: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.
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:
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.
Nice! Awaiting full source .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.
I did kinda same but without generation, and relying on gcc.
Re: Undefined behavior for ABCD and SBCD
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.r57shell wrote:Yes. For me, who is not familiar with transistor stuff is not easy to figure out what it is:
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:
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.
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.
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).r57shell wrote:Nice! Awaiting full source .
-
- Very interested
- Posts: 615
- Joined: Thu Nov 30, 2006 6:30 am
Re: Undefined behavior for ABCD and SBCD
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.HardWareMan wrote:I do not understand, hasn't anyone looked at the CPU die shots yet?
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.
IIRC, that's VCC.flamewing wrote:I am not sure what the thick line means on the top image, though.
Thanks for the test ROM by the way. Very helpful in fixing the remaining issues in BlastEm's sbcd implementation.
Re: Undefined behavior for ABCD and SBCD
Question is what means element with thick line.Mask of Destiny wrote:IIRC, that's VCC.flamewing wrote:I am not sure what the thick line means on the top image, though.
Thanks for the test ROM by the way. Very helpful in fixing the remaining issues in BlastEm's sbcd implementation.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 615
- Joined: Thu Nov 30, 2006 6:30 am
Re: Undefined behavior for ABCD and SBCD
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.r57shell wrote:Question is what means element with thick line.Mask of Destiny wrote:IIRC, that's VCC.flamewing wrote:I am not sure what the thick line means on the top image, though.
Thanks for the test ROM by the way. Very helpful in fixing the remaining issues in BlastEm's sbcd implementation.
68000 is NMOS. The 68HC000 is CMOS, but I'm pretty sure it's the original chip that's been decapped.HardWareMan wrote:Because this sample is more likely nMOS (or pMOS) and not CMOS.