It is currently Wed Sep 18, 2019 4:36 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Feb 11, 2019 8:40 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21591
Location: NE Indiana, USA (NTSC)
When kevtris was developing the Kevtendo, the prototype of the Analogue Nt Mini, he wrote a program called "nestest" that exercised the official 6502 instructions as well as the useful unofficial ones. Nowadays, it's become common for developers of emulators to use nestest and compare a trace log against that from Nintendulator as a smoke test to ensure the CPU is at least halfway functioning.

Is there an analogous ROM to exercise a 65816, SPC700, or Super FX core? I've heard rumors on the Internets of a new Super NES emulator from the developer of a well-known NES emulator, and in case they're true, I'd like to know what to recommend other than just running Super Mario World.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 11:39 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 757
Its odd that 6502.org don't have a 65816 test suite, but it seems they don't..

I would recommend the https://github.com/Klaus2m5 the C version is a good start, as the 65816 in E mode should match, and the probably within one or two exceptions should also pass in 65816 mode ( depending on how well the RWM RMW is tested. )
The VICE emulator has a test suite that could be modified to suit a SNES to test some of the edge cases of the 65816 https://sourceforge.net/p/vice-emu/code ... U/jeek816/

Possibly an extension for the 65816 should be made.


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 1:13 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
Regarding 65816:

I'm not aware of any 65816 instruction test ROMs.

Please remember that the 65816's emulation mode (sec/xce), the CPU emulates a 6502 -- not a 65c02 -- except bugs like the page-wrap jmp ($xxFF) bug have been fixed. So in a way it's something between a 6502 and 65c02.

Invalid opcode testing would also fail, as the 65816's emulation mode does not properly emulate all of the invalid opcodes on the 6502 -- in other words, using one of the 105 (?) invalid opcodes on 6502 will actually execute the correct/associated 65816 opcode. In contrast/comparison, the 65802 (not a typo) does emulate the 105 invalid instructions correctly (AFAIK).

There's a lot more to it than just that, too. I suggest reading -- not skimming -- WDC's Programming The 65816 manual, pages 48 to 62, for details. The final paragraph of page 58 is highly relevant.

In short: if you want a "true 6502" (all the way down to the pinout), the 65802 is a better choice. The 65816 is "pretty good" in emulation mode, but you really have to make sure the underlying 6502 program isn't "clever" in anything it's doing and doesn't rely on... I don't know what to call them, 6502 design/aspect quirks?... otherwise you'll probably end up with unexpected results. As such, I've mentally always treated the 65816's emulation mode more like a 65c02, despite that not being entirely true.

As for more SNES-specific stuff:

Your best bet for emulator development/testing is just to run commonplace mode 20 (LoROM) games. Like with the NES, 95% of the development time is going to be spent on PPU-related emulation. Avoid testing with any games that use expansion chips (DSP, etc.). Move on to mode 21 (HiROM) after.

Super Mario All-Stars (mode 20, 16mbit) might also make for an interesting test -- the game that not only has copy protection (stops running on certain SNES copiers, requiring a patched ROM), but is rumoured to use emulation mode, as well as legacy NES-compatible MMIO registers $4016 and $4017 for joypad reading since the code was copied over from the NES/Famicom originals. I can certainly confirm the former, but the latter two were rumours that I strongly suspect are true.

The very old snes9x-debug release from Geiger has a output-all-instructions/flags/etc-to-a-file mode that might work well for log comparison, similar to nestest. You'll need these details/files to get it running, at least on Windows 7 (no idea about 8 or 10), otherwise you'll get an unintuitive error.

Otherwise, in all sincerity, try to track down authors or maintainers of existing emulators. The original (and present maintainer) ZSNES folks were incredibly helpful, and so was Gary Henderson (never had the pleasure of talking to him myself). And, obviously, byuu would be a fantastic person to chat with too. And, of course, I'm still around too (my IIGS sits nearby).


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 6:34 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 205
Location: Germany
Here are some ROMs: https://board.byuu.org/viewtopic.php?f=16&t=1486

koitsu wrote:
In contrast/comparison, the 65802 (not a typo) does emulate the 105 invalid instructions correctly (AFAIK).

Afaik (from reading the manual) the 65c8xx core doesn't emulate the illegal opcodes at all; the only difference between the 65c802 and the 65c816 is that there's no way to get the bank address bits out of the chip.

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 10:35 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
creaothceann wrote:

Starting from the last page working backwards, it looks like some of the test ROMs by krom may potentially have bugs. This report followed by this follow-up (which TMK has had no update since) seem to imply such. Looks like the last update, at least in GitHub was from a couple years ago (so I doubt it's the "fixed" version for DEC that krom talks about in his subsequent post; git history says the file on GitHub was last updated Feburary 2017, post confirming bugs was from June 2017. I suspect krom never commit+push'd his fixes). higan folks were able to catch the mistakes due to already having a working 65816 emulation core and pre-existing trace logs, as indicated. Situation is trickier for a brand new emulation core. That said, I imagine this would probably be better than nothing, though comparing trace logs to something else known to be working (and can output them) would certainly be ideal.

creaothceann wrote:
Afaik (from reading the manual) the 65c8xx core doesn't emulate the illegal opcodes at all; the only difference between the 65c802 and the 65c816 is that there's no way to get the bank address bits out of the chip.

Yeah, you're right. I didn't interpret what was written on page 45 that way, given its phrasing. I had to refer to other sections to get a clearer picture. Those details:

Page 45:
Quote:
Power-On Status: 6502 Emulation Mode
...
Unlike the NMOS 6502, which has undefined results when unimplemented opcodes are executed, and
the 65C02, which treats unimplemented opcodes as variously-timed and –sized no-operations, the 65802
instruction set implements every one of the 256 possible one-byte opcodes. These additional instructions are
available in emulation mode as well as in native mode.

(I took "every one of the 256 possible one-byte opcodes" to mean "we did in fact on the 65802 emulate all the illegal instructions while in emulation mode", but that is certainly wrong.)

Page 52:
Quote:
New 65816 Addressing Modes
...
Not only do the 65802 and 65816 provide all the 6502 and 65C02 addressing modes, but they also offer
nine new addressing modes of there own, in both emulation and native modes.

Page 54:
Quote:
Instructions
There are 78 new opcodes put into use through the 28 new operations listed in Table 4.4, as well as
through giving the previous processors’ operations additional addressing modes. ...
<Table 4.4 footer reads: Table 4-4 New 65816/65802 Instructions>

So, in short, "illegal opcodes" are not implemented in emulation mode (on either 65816 or 65802) -- you will end up executing 65c02 or 65816 instructions. I remember this definitely being the case the last time I tried it on a IIGS, which was probably when I was testing out B flag behaviour on BRK in emulation mode.

Thanks for catching my mistake WRT the 65802.


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 11:17 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 205
Location: Germany
Speaking of the IIGS...

Since this is a 65c816 machine with a different memory map, would it be possible to test the wrapping behavior that anomie wasn't able to test because of the RAM mirroring?
(of course it's possible that someone at 6502.org or elsewhere has already done that)

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 5:27 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2312
Location: Fukuoka, Japan
@koitsu

It's a little bit off topic but what would be the advantage of emulating the illegal opcodes? I have never used any of them but are some that good to be used even though they are not supposed to be available? I always try to write code on the safe side so I never searched more on the subject but you got me curious here. If you even want to use them on the 65816 then some of them must be good to some degree, I guess.


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 6:22 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21591
Location: NE Indiana, USA (NTSC)
A handful of NES games use the 6502 unofficial opcodes, but these opcodes have different meanings on the 65816.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 7:53 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2312
Location: Fukuoka, Japan
I'm aware that some games uses them (Streamerz was one of them) but what I asked is "why" they would use them, what advantage compared to legal ones?


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 8:00 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8559
Location: Seattle
Tepples wrote a pretty good summary of both what they were, and how they could be used, on the wiki: https://wiki.nesdev.com/w/index.php/Pro ... al_opcodes

AXS #im is perhaps the most obviously useful one, because it allows adding/subtracting an arbitrary value to/from the X register.

For all of them, the advantage is "faster and smaller".


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 9:37 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
creaothceann wrote:
Speaking of the IIGS...

Since this is a 65c816 machine with a different memory map, would it be possible to test the wrapping behavior that anomie wasn't able to test because of the RAM mirroring?
(of course it's possible that someone at 6502.org or elsewhere has already done that)

I've never seen this doc until now. This document is weird. It's covering literally 5 or 6 things simultaneously, all the way down to emulation mode variances and even throws the PPU into the mix. This makes it confusing (for me). If you read the "Instruction Wrapping" items, most of them seem very expected (read: normal 65816 behaviour as I understand it -- but see next paragraph), and I don't suspect the memory map variance between the IIGS and the SNES would matter.

But then I went back up to the top of the doc and noticed the part that talking about "unmapped memory", and I have quite literally no idea what this phrase means, nor would I have any idea how you could test that since you wouldn't be able to stick code/data into regions which were "unmapped". I get the premise of open bus, but AFAIK almost all of the SNES's 24-bit memory map always has everything mapped or shadowed, regardless if mode 20 or 21, no? Was this testing against things like $2200-2FFF in bank $00-3F, for example, or was it simply testing general wrap behaviour? It's certainly possible I'm not understanding what's being described, conflated with the variance of what's being tested/analysed.

There are a couple interesting items in that doc though, I agree. Anything relating to emulation mode tends to be fairly "untouched" material documentation-wise, as it was *very* rarely used on any 65816 platform.

I get the impression, especially given the year of the document (2007), that Anomie was looking at the GTE 65816 documents, which are thorough but tend to be in text form and I think sometimes hard to read. Zophar's Domain still has a couple references to them, in particular this one, which provides T-state details on a per-addressing-mode/per-opcode basis, and a lot of inner CPU architecture details (not stuff I usually care to look at as I'm not a hardware guy).

All that said: sure, there could be behavioural variances between an actual WDC 65816 and the SNES 65816 (Ricoh 5A22, which is based on GTE's 65816, which is based on WDCs). It's certainly possible they implemented something differently (re: the "MDR" Anomie talks about in that doc). TMK nobody has done decapping and the massive RE worked needed to accomplish for the 65816 what was done for the RP2A03/RP2A07 on Visual6502, for example (point: we do know the SNES CPU, obviously, differs from a stock WDC 65816 due to things like DMA/HDMA, mult/div, and additional busses).

Bill Mensch, inventor of the 65816, is still around and actively answers Email (proof), so possibly some or all of these could be punted to him/WDC for insights?

Stepping back, here's a more practical question: is what's in this document by Anomie at all applicable to any existing SNES games? Rephrased: are we aware of any SNES games that erratically if the items in said doc aren't implemented that way? Will something break if this isn't done correctly? Or is this purely about pristine accuracy?


Top
 Profile  
 
PostPosted: Tue Feb 12, 2019 11:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8559
Location: Seattle
creaothceann wrote:
would it be possible to test the wrapping behavior that anomie wasn't able to test because of the RAM mirroring?
To try to spell out the specific behavior that anomie was trying to test:

if one executes JMP ($FFFF), is that pointer the two bytes at $00FFFF and $010000 or $00FFFF and $000000.

Regarding the two "XXX: untested" bits in PC-relative and PC-relative long addressing modes, the 65816 manual does explicitly say that PC-relative and PC-relative long both explicitly wrap within a bank. ("The Program Bank Register is not affected")

Quote:
(re: the "MDR" Anomie talks about in that doc).
In the same way that we've found that the NES's PPU has its own internal data bus with its own ability to be "open" (and that one can set by writing to the read-only register and then fetch back by reading from a write-only register), I think this is just saying that the two PPUs inside a 3chip SNES each have their own internal data buses and that they can be read and set independently.

I find Nocash's writeup (see "PPU1 open bus" and "PPU2 open bus") to be clearer.


Top
 Profile  
 
PostPosted: Wed Feb 13, 2019 12:01 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
Thanks, that helps. So this document is about general wrapping behaviour. We have lots of good documentation on that already since the early 90s: Programming the 65816 covers almost all of the wrapping scenarios. Maybe Anomie didn't have this book, and/or the GTE docs were a bit less clear?

Regarding jmp (abs), I can happily test this on my IIGS without much issue if asked, but as I understand it:

- jmp ($ffff) will read the low byte of the effective address from $00FFFF, and the high-byte from $000000
- B (a.k.a. "DBR" or "Data Bank Register") is not involved -- the reads are always from bank $00 -- this is something not immediately obvious
- K (a.k.a. "PBR" or "Program Bank Register") remains untouched
- e=0 and e=1 behave identically, because as covered earlier, the ($xxFF) page wrap bug is fixed on the 65816 even when e=1 (i.e. it behaves more like a 65c02)

References: WDC's Programming the 65816 circa 2007: pages 111 (table 8-1), 112 (full description of behaviour), 292 (operational diagram), and 360 (opcode definition and cycle counts).

One thing I can't determine or test is whether or not on a 65816 when e=1 if the instruction takes 5 or 6 CPU cycles. The documentation states an additional cycle is required on 65c02 (thus would be true on the 65816), and I suspect that's due to handling page wrapping properly on 65c02 onward. However, GTE's "G65SC802 and G65SC816" documentation has this for the T-states: it states 5 cycles. The mysterious "6th line" labelled "cycle 1" at the very end is just to indicate where the CPU "picks up from" -- it's present on things like rti, rts, mvp/mvn, etc.
Code:
 17a Absolute Indirect -- (a)
  (JMP)
  (1 Op Code)
  (3 bytes)
  (5 cycles)

  ADDRESS MODE
      CYCLE /VP /ML VDA VPA   ADDRESS BUS   DATA BUS   R/W
      1   1  1   1  1   PBR,PC      Op Code      1
      2   1  1   0  1   PBR,PC+1   AAL      1
      3   1  1   0  1   PBR,PC+2   AAH      1
      4   1  1   1  0   0,AA      NEW PCL      1
      5   1  1   1  0   0,AA+1      NEW PCH      1
      1   1  1   1  1   PBR,NewPC   New Op Code   1

As a comparison, this is what a native 6502 has:
Code:
  Absolute indirect addressing (JMP)

        #   address  R/W description
       --- --------- --- ------------------------------------------
        1     PC      R  fetch opcode, increment PC
        2     PC      R  fetch pointer address low, increment PC
        3     PC      R  fetch pointer address high, increment PC
        4   pointer   R  fetch low address to latch
        5  pointer+1* R  fetch PCH, copy latch to PCL

       Note: * The PCH will always be fetched from the same page
               than PCL, i.e. page boundary crossing is not handled.

I can't seem to find a T-state breakdown of this sort for the 65c02. :/


Top
 Profile  
 
PostPosted: Wed Feb 13, 2019 12:33 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 757
The 65816 checks of the Super CPU VICE emulator test the wrap around cases you mention (see my original post above) . If you wish to play with them the VICE emulator is probably the easiest as you can assemble code in the monitor. And it doesn't need any boot discs to run.

As far as I know ( and I will peal this off into another topic ) the N6502 is the only version that has illegal opcodes, and even then we(the Commodore community) speculate that you need a MOS/CSG N6502 to get the "set" we have.


Top
 Profile  
 
PostPosted: Wed Feb 13, 2019 5:09 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 205
Location: Germany
koitsu wrote:
But then I went back up to the top of the doc and noticed the part that talking about "unmapped memory", and I have quite literally no idea what this phrase means, nor would I have any idea how you could test that since you wouldn't be able to stick code/data into regions which were "unmapped".

I think he means any address where the hardware doesn't change the value on the data bus - e.g. a cartridge region that isn't mirrored and not backed by a chip, or $4000..$4015, or maybe VRAM reads during active display. (as mentioned in nocash's docs via lidnariq's link)

koitsu wrote:
I get the impression, especially given the year of the document (2007), that Anomie was looking at the GTE 65816 documents, which are thorough but tend to be in text form and I think sometimes hard to read. Zophar's Domain still has a couple references to them, in particular this one, which provides T-state details on a per-addressing-mode/per-opcode basis, and a lot of inner CPU architecture details (not stuff I usually care to look at as I'm not a hardware guy).

The data sheet (which is quite recent) also contains the bus activity.

koitsu wrote:
TMK nobody has done decapping and the massive RE worked needed to accomplish for the 65816 what was done for the RP2A03/RP2A07 on Visual6502, for example (point: we do know the SNES CPU, obviously, differs from a stock WDC 65816 due to things like DMA/HDMA, mult/div, and additional busses).

There's siliconpr0n, but that has all the layers not separated.

koitsu wrote:
One thing I can't determine or test is whether or not on a 65816 when e=1 if the instruction takes 5 or 6 CPU cycles.

This could possibly be tested by trying to write a value to VRAM close to the HBLANK edges.

I still have to read the 65816 programming manual in its entirety, it's quite big...

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group