Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Zexall question

Reply to topic
Author Message
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Zexall question
Post Posted: Mon Jan 30, 2006 3:04 pm
i've checked the ld <bcdexya>,<bcdexya> instructions more times than i can count and can't find anything wrong with them. are these load instructions treated differently than ld <bcdehl(hl)a>,<bcdehl(hl)a>, any common mistakes made with these?
funnily enough, all my other ixh/ixl/iyh/iyl, ix+d/iy+d instructions work fine in zexall. :/

also, though the name says otherwise, does the aluop a,<b,c,d,e,h,l,(hl),a> access the ixh/ixy? because it's the only alu op that's failing on me now.
  View user's profile Send private message
  • Joined: 21 Jul 2005
  • Posts: 411
  • Location: GBG
Reply with quote
Post Posted: Mon Jan 30, 2006 4:47 pm
Maybe show us some source code? ( a link to the relevant portion would be good).
  View user's profile Send private message Visit poster's website
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Post Posted: Mon Jan 30, 2006 5:22 pm
sure, LD for IXH/IXL (DD instructions):

case 0x44: reg.B=reg.IXH; break;
case 0x45: reg.B=reg.IXL; break;
case 0x4C: reg.C=reg.IXH; break;
case 0x4D: reg.C=reg.IXL; break;
case 0x54: reg.D=reg.IXH; break;
case 0x55: reg.D=reg.IXL; break;
case 0x5C: reg.E=reg.IXH; break;
case 0x5D: reg.E=reg.IXL; break;

case 0x60: reg.IXH=reg.B; break;
case 0x61: reg.IXH=reg.C; break;
case 0x62: reg.IXH=reg.D; break;
case 0x63: reg.IXH=reg.E; break;
case 0x64: reg.IXH=reg.IXH; break;
case 0x65: reg.IXH=reg.IXL; break;
case 0x67: reg.IXH=reg.A; break;

case 0x68: reg.IXL=reg.B; break;
case 0x69: reg.IXL=reg.C; break;
case 0x6A: reg.IXL=reg.D; break;
case 0x6B: reg.IXL=reg.E; break;
case 0x6C: reg.IXL=reg.IXH; break;
case 0x6D: reg.IXL=reg.IXL; break;
case 0x6F: reg.IXL=reg.A; break;

case 0x7C: reg.A=reg.IXH; break;
case 0x7D: reg.A=reg.IXL; break;


the LD IYH/IYL (FD equivelents) are identical, of course.

and no code to post for aluop a,<b,c,d,e,h,l,(hl),a> question. just looking for yes/no answer.

on page 11, this pdf document talks about the DD instructions and how they are handled like HL/(HL) equivelents. contains a pretty straight forward explanation: http://www.smspower.org/dev/docs/z80/z80-documented.pdf

thanks.
  View user's profile Send private message
  • Joined: 21 Nov 2005
  • Posts: 150
  • Location: Sydney, NSW, Australia
Reply with quote
Post Posted: Mon Jan 30, 2006 7:01 pm
That looks fine. So it must be something periferal to that.

Are you storing IX and IY separetly from IXH, IXL, IYH, IYL. If so, are you updating IX and IY?
  View user's profile Send private message Visit poster's website
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
:/
Post Posted: Mon Jan 30, 2006 7:10 pm
yeah, they are stored in a union and share the same memory space so changes are also shared (automatic).

i'll keep looking it over, but this is one of those strange bugs where the solutions is probably too simple to see at a glance...

and to make things more interesting, the aluop a,<b,c,d,e,h,l,(hl),a> instructions pass IF i take out all the other tests in zexall and recompile/link it... wth?
  View user's profile Send private message
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Re: :/
Post Posted: Mon Jan 30, 2006 7:51 pm
MiracleWarriors wrote
and to make things more interesting, the aluop a,<b,c,d,e,h,l,(hl),a> instructions pass IF i take out all the other tests in zexall and recompile/link it... wth?


Zexall has known "state leaks", where memory is not correctly cleared between tests, resulting in test results that depend on the results of previous tests.

Your case is the opposite (because one test passes for you when no other tests are run), but it is probably a related problem.

I know I fixed some of these problems at one point. It's possible I missed one, or that I never uploaded the changes to S8-Dev. I'll have to check my local copies against the released versions.

What version of Zexall are you using? Does your emulator fail with the released binaries?

--
Eric R. Quinn
  View user's profile Send private message Visit poster's website
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Post Posted: Mon Jan 30, 2006 8:03 pm
i'm using the version of zexall found on this page: http://www.smspower.org/dev/demos/


ZEXALL 0.12 (zexall012.zip)
Sega Master System - Technical
By Maxim, Eric R. Quinn
Last update: June 15, 2003



of all my opcodes, only 3 fail:

ld <bcdexya>,<bcdexya>
aluop a,<b,c,d,e,h,l,(hl),a>
daa //not finished implementing

the daa only fails because i saved it for last and am currently working on it.
  View user's profile Send private message
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Post Posted: Mon Jan 30, 2006 10:19 pm
I would say that if you can get your test to pass under *some* combination of tests in Zexall, then you probably have the correct implemention for the tested instructions.

I checked my personal copies of ZEXALL. I do indeed have a new working version (0.13_working) that includes fixes for the test state leaks. There are between 15 and 20 tests that require fixes.

Fixing the state leaks is somewhat complicated. The state leaks only show up for certain tests and only under certain conditions. Specifically, certain tests must run before others in order for the latter tests to pass. The problem with fixing the state leaks is that the CRCs for the tests must be recomputed. (The original CRCs were calculated using results in memory that were "dirty". Ensuring the use of clean (initialized) memory changes the resulting CRC). This is why I haven't released 0.13: I can't verify the new CRCs on a real Z80 system. I can only verify them on the various SMS emulators that exist. I believe I used a majority voting scheme between Meka, MesaDX, Emukon and ChaSMS to verify the new CRCs. (Now that I think about it, I'm not sure if Meka, Emukon and ChaSMS use different Z80 emulators. I know MesaDX does because I wrote its Z80 emulator myself from scracth). If I can get consensus on the new CRCs from a variety of emulators does any one have a problem with using those new CRC's even though they weren't calculated on a real Z80?

--
Eric R. Quinn
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8344
  • Location: Paris, France
Reply with quote
Post Posted: Mon Jan 30, 2006 10:27 pm
Well, what about sending me or Maxim a build, so we can get the proper CRC from a Master System?
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2005
  • Posts: 483
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Mon Jan 30, 2006 10:52 pm
Do your DD prefix instructions work correctly even in the cases when the prefix is ignored (for example, adding a DD prefix to "LD B, C")?
  View user's profile Send private message Visit poster's website
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Post Posted: Tue Jan 31, 2006 7:07 pm
Bock wrote
Well, what about sending me or Maxim a build, so we can get the proper CRC from a Master System?


I'm still testing the latest build. I need to run Zexall with all the tests enabled, and then with each test invidividually to ensure there are no state leaks. I'll let you know when it's ready.

How should I provide it to you (Bock, Maxim)? I don't think I have FTP access to S8-Dev anymore.

--
Eric R. Quinn
  View user's profile Send private message Visit poster's website
  • Joined: 21 Nov 2005
  • Posts: 150
  • Location: Sydney, NSW, Australia
Reply with quote
Re: :/
Post Posted: Tue Jan 31, 2006 10:12 pm
MiracleWarriors wrote
yeah, they are stored in a union and share the same memory space so changes are also shared (automatic)...


IIRC from when I was developing my Z80 core for Mimic (now thats a blast from the past), I had the same issue. It turned out that the compiler was not allining the union to the byte, but rather to the word (or long, I forget which) by default.
  View user's profile Send private message Visit poster's website
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Post Posted: Wed Feb 01, 2006 2:47 pm
mike, i read about this anomaly a while back, but had competely forgot about it until you mentioned it. it's possible that that's the culprit.
  View user's profile Send private message
  • Joined: 21 Jul 2005
  • Posts: 411
  • Location: GBG
Reply with quote
Post Posted: Thu Feb 02, 2006 10:22 am
Paul Baker wrote
Do your DD prefix instructions work correctly even in the cases when the prefix is ignored (for example, adding a DD prefix to "LD B, C")?

I think you should check all the DD prefix instructions and make sure you trap all the ones you haven't implemented yet.
  View user's profile Send private message Visit poster's website
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Post Posted: Tue Feb 28, 2006 7:15 pm
is there a document that lists specifically which instructions (documented and undocumented) are addressed with each operation in zexall?

for instance, i'm getting an incorrect crc with these two operations, but would be able to debug easier if i knew which instructions in my emulator to focus on.

aluop a,<b,c,d,e,h,l,(hl),a>
ld <bcdexya>,<bcdexya>

also, to Paul:
Quote
Do your DD prefix instructions work correctly even in the cases when the prefix is ignored (for example, adding a DD prefix to "LD B, C")?

Paul, i tried this suggestion and ran zexall and when it gets to ld (<ix,iy>+1),a ,zexall starts over immediately.
  View user's profile Send private message
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Post Posted: Tue Feb 28, 2006 11:50 pm
MiracleWarriors wrote
is there a document that lists specifically which instructions (documented and undocumented) are addressed with each operation in zexall?


Unfortunately, there's no easy direct way to tell which instructions are being executed. You can tell by looking at specific bytes in the TestData descriptor for each test.

For example, the TestData for aluop a,<b,c,d,e,h,l,(hl),a> is:


; aluop a,<b,c,d,e,h,l,(hl),a> (753,664 cycles)
alu8r:
  .db FlagMask
  TestData $80,0,0,0,$c53e,$573a,$4c4d,MachineStateBeforeTest,$e309,$a666,$d0,$3b,$adbb
  TestData $3f,0,0,0,0,0,0,0,0,0,0,-1,0  ; (16,384 cycles)
  TestData 0,0,0,0,$ff,0,0,0,-1,-1,$d7,0,0 ; (46 cycles)
  CRC $5ddf949b
  MessageString "aluop a,<b,c,d,e,h,l,(hl),a>."


The first test instruction opcode is in the first 4 bytes of TestData, in this case they are: $80,0,0,0
The next line contains the information about how to modify the opcode in each successive iteration. In this case the data is: $3f,0,0,0. This means that only the first byte of the opcode will be modified, and that the low six bits will be successively counted through. So, the opcodes tested by this test include: $80 through $BF.

Similarly, the opcodes tested by ld <bcdexya>,<bcdexya> are:

$40 through $7F.

The best way to narrow down which opcodes are being tested is to fix how the opcode is modified during each successive test. For example, changing the $3F (in the second line of TestData in both of the above cases) to something like $0F will reduce the numer of opcodes tested and (if memory serves) will test specific ALU ops (like ADC) in the first case, and only test LDs to a specific 8-bit register (like LD B, reg8) in the second case. Of course doing this will result in a bad CRC check, so you'll have to run the modified test on another trusted emulator, like Meka, to see what CRC it gets.

Good luck.

--
Eric R. Quinn[/code]
  View user's profile Send private message Visit poster's website
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Post Posted: Wed Mar 08, 2006 4:10 pm
Eric thanks for the excellent explanation.

Recompiling zexall to run each instruction individually, I've solved the problem with the ld <bcdexya>,<bcdexya>.

The only outstanding issue is aluop a,<b,c,d,e,h,l,(hl),a>:

It runs fine with no errors if i compile it to run only aluop a,<b,c,d,e,h,l,(hl),a>, but when i do the full, unmodified zexall run it fails with an incorrect CRC. I even ran it's constituents grouped by instruction (ie 0x80-0x87, 0x88-0x8F, 0x90-0x97, 0x98-0x9F, 0xA0-0xA7, 0xA8-0xAF, 0xB0-0xB7, 0xB8-0xBF), and each CRC matched Meka's.

I've been saving DAA implementation for last and thought that it's unfinished state might have affected it? Otherwise, I'm not sure what could be causing this problem. This one is tough to debug simply because it takes almost an hour to run...

Again, thanks for your help!
  View user's profile Send private message
  • Joined: 05 Jan 2006
  • Posts: 36
Reply with quote
Post Posted: Wed Mar 08, 2006 5:14 pm
Hi,

I had some trouble with my DAA implementation. In the end I 'stole' the tables from Marat Fayzullin's Z80 emulator. The tables can be generated from the instructions given at http://www.myquest.nl/z80undocumented/. If you like there's some sourcecode you could steal from the top of my Z80 class (http://sourceforge.net/projects/thingbob - dig around the CVS) to generate those tables. Hope that helps.
  View user's profile Send private message
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Post Posted: Wed Mar 08, 2006 5:35 pm
Thanks SerenWib,

but i'm not having trouble with DAA (yet), just haven't implemented it yet as i was saving it for last.

also, i couldn't bare to borrow anyone elses source code having come this far on my own and the fact that i'm doing this as a learning exercise for my favorite 8-bit system.

thanks for the consideration though!
  View user's profile Send private message
  • Joined: 05 Jan 2006
  • Posts: 36
Reply with quote
Post Posted: Wed Mar 08, 2006 6:14 pm
No trouble at all.

I still recommend the 'myquest' link though. Good luck with your emulator.
  View user's profile Send private message
  • Joined: 18 Sep 1999
  • Posts: 498
  • Location: Portland, Oregon USA
Reply with quote
Post Posted: Wed Mar 08, 2006 6:32 pm
MiracleWarriors wrote
The only outstanding issue is aluop a,<b,c,d,e,h,l,(hl),a>:

It runs fine with no errors if i compile it to run only aluop a,<b,c,d,e,h,l,(hl),a>, but when i do the full, unmodified zexall run it fails with an incorrect CRC. I even ran it's constituents grouped by instruction (ie 0x80-0x87, 0x88-0x8F, 0x90-0x97, 0x98-0x9F, 0xA0-0xA7, 0xA8-0xAF, 0xB0-0xB7, 0xB8-0xBF), and each CRC matched Meka's.


I really should get Zexall 0.13 uploaded to S8-Dev. That may fix your problem. Some of the tests (and at least one ALU test) have memory leaks that affect the test CRC depending on which tests have and have not run prior. I.e., running the tests singly or in groups changes their CRCs. Zexall 0.13 fixes this. The problem might be zexall, not your emulator.


MiracleWarriors wrote
I've been saving DAA implementation for last and thought that it's unfinished state might have affected it? Otherwise, I'm not sure what could be causing this problem. This one is tough to debug simply because it takes almost an hour to run...


It's possible.

As for the lenght of the test, you can reduce the number of opcodes tested per run, or you can reduce some of the other counters. Here's the test data again:


; aluop a,<b,c,d,e,h,l,(hl),a> (753,664 cycles)
alu8r:
  .db FlagMask
  TestData $80,0,0,0,$c53e,$573a,$4c4d,MachineStateBeforeTest,$e309,$a666,$d0,$3b,$adbb
  TestData $3f,0,0,0,0,0,0,0,0,0,0,-1,0  ; (16,384 cycles)
  TestData 0,0,0,0,$ff,0,0,0,-1,-1,$d7,0,0 ; (46 cycles)
  CRC $5ddf949b
  MessageString "aluop a,<b,c,d,e,h,l,(hl),a>."


Do you see that -1 in the second "TestData" line (second from the end)? Change that to some other number with less set bits. -1 has 8 bits set. Try using 0 (0 bits set) or 1,2,4,8,16,32,64,128 (1 bit set). This will greatly reduce that 16,384 cycle number. Again, you'll have to compare your CRCs against another emulator.

As for DAA, I gave up and finally copied the DAA tables from another Z80 emulator. The problem with all the Z80 DAA documention I've found (including Sean Young's) is that it only describes how DAA works for valid input combinations. It only gives you the DAA operation given flag and data settings that are possible after an arithmetic operation. It does not cover every possible case (see the table on page 15 of Sean Young's Undocument Z80. He doesn't describe what DAA does when NF=CF=HF=1, and the low nybble is between 0 and 5, for example.) Zexall tests any possible case (not just valid input cases), so using that doc will not get you the full implementation of DAA. I've tried to derive it, but it's not worth the effort to me.

--
Eric R. Quinn
  View user's profile Send private message Visit poster's website
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Post Posted: Wed Mar 08, 2006 7:19 pm
Quote
I really should get Zexall 0.13 uploaded to S8-Dev. That may fix your problem.

I'm sure several people would be interested to know when you upload the new ver of zexall, myself included

Quote
Do you see that -1 in the second "TestData" line (second from the end)? Change that to some other number with less set bits. -1 has 8 bits set. Try using 0 (0 bits set) or 1,2,4,8,16,32,64,128 (1 bit set). This will greatly reduce that 16,384 cycle number. Again, you'll have to compare your CRCs against another emulator.

thanks, that will help a lot!

Quote
As for DAA, I gave up and finally copied the DAA tables from another Z80 emulator. The problem with all the Z80 DAA documention I've found (including Sean Young's) is that it only describes how DAA works for valid input combinations. It only gives you the DAA operation given flag and data settings that are possible after an arithmetic operation. It does not cover every possible case (see the table on page 15 of Sean Young's Undocument Z80. He doesn't describe what DAA does when NF=CF=HF=1, and the low nybble is between 0 and 5, for example.) Zexall tests any possible case (not just valid input cases), so using that doc will not get you the full implementation of DAA. I've tried to derive it, but it's not worth the effort to me.

that's a very convincing reason for me to make an exception of borrowing the DAA tables for use in my emulator. but i'm very curious how marat got his info? and SerenWib, i think i understand the basis for your recommendation now.
  View user's profile Send private message
  • Joined: 05 Jan 2006
  • Posts: 36
Reply with quote
Post Posted: Wed Mar 08, 2006 8:29 pm
What does it mean if a Z80 implementation passes a ZEXALL 0.12 test?

Um. I have no idea where Marat got his information from. I think MEKA uses a derived version of Marat's Z80. Although MEKA seems to have code to allow other Z80 implementations to be used.

I imagine you'd get the information out of a real Z80 by using

Push onto stack special 16 bit value (with the right Carry, Half Carry and Negative flags, Accumulator value)
POP AF
DAA
PUSH AF
Top of stack is the result.

in some sort of loop.

I'm not much of an assembly person so that might be completely wrong. But that would be my first guess :)
  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8344
  • Location: Paris, France
Reply with quote
Post Posted: Thu Mar 09, 2006 12:01 am
I posted the full Zexall 0.13 package now:
http://www.smspower.org/dev/demos/
http://www.smspower.org/dev/demos/zexall013.zip
Thanks Eric.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13633
  • Location: London
Reply with quote
Post Posted: Thu Mar 09, 2006 5:32 pm
I had a look through the Zexall source this morning and did quite a lot of cleaning up. There's a few issues to work out with WLA DX though - it'd be good to get it using ramsections, for example - and it's somewhat annoying that a lot of the CRCs change if you relocate some of the variables, because various registers have different values during the test sections. Nevertheless, it seems good to clean it up (some more) and make it somewhat more documented.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Mar 2002
  • Posts: 177
  • Location: Toronto, Canada
Reply with quote
Post Posted: Thu May 03, 2007 8:01 pm
Bock wrote
I posted the full Zexall 0.13 package now:
http://www.smspower.org/dev/demos/
http://www.smspower.org/dev/demos/zexall013.zip
Thanks Eric.


People,

I'm using Zexall as a first test to check the precalculated tables on my Z80 core. In one of my tests, i broke some instructions and zexall started to execute "crap" instructions.

I noticed something was wrong because it was taking too much time to complete the test. It would be nice to know if it's really working (the screen remains frozen until the test finishes), so i changed version 0.13 a bit and included routines to animate the screen when tests are being performed.

It's a simple change, but it's nice. :)
zexall014.zip (108.13 KB)

  View user's profile Send private message
  • Joined: 21 Jul 2005
  • Posts: 411
  • Location: GBG
Reply with quote
Post Posted: Sat Nov 13, 2010 1:24 pm
Last edited by FluBBa on Sat Nov 13, 2010 9:20 pm; edited 2 times in total
I fixed the source so that it now can compile with UseSDSCDebugConsole = 1, and added CRCs for testing ALL flags (including undocumented ones).
The tests that have different CRCs are:

<adc,sbc> hl,<bc,de,hl,sp>
add hl,<bc,de,hl,sp>
add ix,<bc,de,ix,sp>
add iy,<bc,de,iy,sp>
aluop a,nn
aluop a,<b,c,d,e,h,l,(hl),a>
aluop a,<ixh,ixl,iyh,iyl>
aluop a,(<ix.iy>+1)
bit n,<b,c,d,e,h,l,(hl),a>
cpd<r>
cpi<r>
<daa,cpl,scf,ccf>
<inc,dec> a
<inc,dec> b
<inc,dec> c
<inc,dec> d
<inc,dec> e
<inc,dec> h
<inc,dec> l
<inc,dec> (hl)
<inc,dec> (<ix,iy>+1)
<inc,dec> iyl
ldd<r> (2)
ldi<r> (1)
ldi<r> (2)
neg
<rrd,rld>
<rlca,rrca,rla,rra>
shf/rot (<ix,iy>+1)
shf/rot <b,c,d,e,h,l,(hl),a>
ZEXALL-SMS-0.15.zip (151.14 KB)
ZEXSMS 0.15

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13633
  • Location: London
Reply with quote
Post Posted: Sat Nov 13, 2010 7:03 pm
I updated the homebrew page:

http://www.smspower.org/Homebrew/ZEXALL-SMS

FluBBa, you should be able to edit/upload there if you like.
  View user's profile Send private message Visit poster's website
  • Joined: 21 Jul 2005
  • Posts: 411
  • Location: GBG
Reply with quote
Post Posted: Sat Nov 13, 2010 9:21 pm
I screwed up the first upload but I think I've fixed it now.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13633
  • Location: London
Reply with quote
Post Posted: Sat Nov 13, 2010 10:12 pm
It still has SVN metadata in the zip. I cleaned it out of the version on the above link.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13633
  • Location: London
Reply with quote
Post Posted: Wed Dec 08, 2010 12:50 pm
I was looking a little more closely and realised FluBBa's change involved duplicating the source into zexdoc.asm. I've made a version that combines both sets of CRCs, and uses assembler definitions to produce the four variants we now have. Does anyone else have any changes they want to contribute?

I think the progress slashes might be causing the tests to take longer to run, as it waits for a VBlank for each slash printing (so permuting over 16 bits will take 18 minutes). Has anyone noticed a performance regression? It might be nicer to have a clean VBlank interrupt handler giving some fractional completion for the test (iteration x of y), which would be a bit of work...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13633
  • Location: London
Reply with quote
Post Posted: Thu Dec 09, 2010 12:32 pm
Multipost! Is there an emulator that passes all the undocumented flag checks so I can confirm I didn't break it without needing to resort to real hardware?
  View user's profile Send private message Visit poster's website
  • Joined: 21 Jul 2005
  • Posts: 411
  • Location: GBG
Reply with quote
Post Posted: Sun Dec 12, 2010 1:49 pm
Haven't seen one yet, you could send the binaries to me if you can't test them yourself.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Dec 2010
  • Posts: 6
  • Location: Columbus, Ohio
Reply with quote
Post Posted: Wed Dec 29, 2010 5:42 pm
Is there a listing somewhere of the proper machine states for each of the CRCs? I'm working on a Z80 emulator of my own, but I'm not sure of the particular issue I'm having with some of my instructions.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13633
  • Location: London
Reply with quote
Post Posted: Wed Dec 29, 2010 8:41 pm
Not sure what you mean. The source includes the machine state at the start and some modification masks, but the CRC is of the combination of all intermediate states. To find the precise problem, zero some of the modification mask bits and compare CRCs to a known-good emulator to binary-search for a problem case. (Or zero the masks entirely if you think it's totally wrong.)
  View user's profile Send private message Visit poster's website
  • Joined: 28 Mar 2013
  • Posts: 3
Reply with quote
DAA
Post Posted: Thu Mar 28, 2013 10:34 pm
I can give you DAA code if you like.

But on your ALUop problem, you say that this fails if you run preceding tests but if you run it by itself, it passes?

Did I understand you correctly?

I may have similar issue: everything passes except this (the longest) test.


MiracleWarriors wrote
i'm using the version of zexall found on this page:


ZEXALL 0.12 (zexall012.zip)
Sega Master System - Technical
By Maxim, Eric R. Quinn
Last update: June 15, 2003



of all my opcodes, only 3 fail:

ld <bcdexya>,<bcdexya>
aluop a,
daa //not finished implementing

the daa only fails because i saved it for last and am currently working on it.
  View user's profile Send private message
  • Joined: 28 Mar 2013
  • Posts: 3
Reply with quote
CP/M Compiled version
Post Posted: Thu Mar 28, 2013 10:38 pm
Does anyone know where I can find a CP/M compiled version of ZEXDOC v 0.15?
  View user's profile Send private message
  • Joined: 28 Mar 2013
  • Posts: 3
Reply with quote
My non-table DAA - passed ZEXDOC
Post Posted: Thu Mar 28, 2013 10:53 pm
This is messy because it is generated from a flag specification: rZXsXp.s
r means copy bit from re(sult)
Z means test re(sult) for zero
X means ignore
s means copy bit from n2
p means lookup parity table
. means don't change

void setfDAA(int n1, int n2, int re){ (( f=+(f&0x02)+(n2&0x11)+(re&0x80)+(re==0)*64+PAR[re] )); }; /* _spec=rZXsXp.s _f0=0 f&2 n2&11 re&80 a&0 r&0 */;

Non-table based DAA. It calculates +-diff value, new H flag and new C flag (which are passed to setfDAA to set all flags).

This can still be optimised I think, but I think worst-case is 4 comparisons to calculate diff, H and C.

void DAA(){
int _diff,_fc,_fh,_hc,_lo,_hi;
(( _lo=a&15, _hi=a>>4, _diff=(_lo<=9) ? (a<=0x99 ? 0 : 0x60) : (a<=0x8f ? 6 : 0x66) ));
(( _diff|=f&FC ? 0x60 : 0, _diff|=f&FH ? 0x06 : 0 ));
(( _fc=(f&FC) ? FC : (a<=0x99 ? 0 : FC) ));
(( _fh=(f&FN) ? (f&FH?(_lo<5>=10 ? FH : 0) ));
(( _hc=_fc|_fh ));
(( a=(a+(f&FN ? (-_diff) : _diff))&255 )); setfDAA(0,_hc,a);

}; /* from ./pc-z80-3.bash.374 */;

Forgive this messy code, it is actually machine translated from a bash script into C.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!