What 65816 test analogous to nestest?

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.

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.

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

Here are some ROMs: https://board.byuu.org/viewtopic.php?f=16&t=1486


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.

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.


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:

(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:

Page 54:

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.

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)

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

A handful of NES games use the 6502 unofficial opcodes, but these opcodes have different meanings on the 65816.

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?

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

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?

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")

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.

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.

As a comparison, this is what a native 6502 has:

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

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.

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)


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


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


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

Thanks for this -- I'd skimmed this one some time ago but had completely forgotten it contained relevant info. The bus activity diagram doesn't help me (again: not a hardware guy), but the Table 3-1 Addressing Mode Summary, Table 5-4 Opcode Matrix, and Table 5-7 Instruction Operations don't match up cycle-count wise. I want to assume the misunderstanding is something I'm doing, not the documentation/technology, but I really don't know:

Table 3-1 says for Absolute Indirect (Jump), the cycle count is 5. What's weird is: it says the cycle count of the original 6502 is 5, as well as for the 65816 is 5.
Table 5-4 says for opcode 6C (JMP (a)), the cycle count is 5. No entry in the "Cycle Count Assumes" notes under the chart apply to this opcode.
Table 5-7 says for entry 3b. Absolute Indirect (a) JMP: 5 cycles and shows the exact same data as what the GTE doc does (thus I suspect the GTE doc info originated from WDC)

And to recap: from the Programming the 65816 document:

Page 360 says for opcode 6C the cycle count is 5, with sub-notes "add 1 cycle if 65C02" and "6502: if low byte of addr is $FF: yields incorrect result" (known 6502 page wrap bug).
Chapter 19 for Instruction Lists says the same thing as Page 360.
Page 436 of an opcode chart says for opcode 6C, the cycle count is 5.

We do know the WDC PDF contains several mistakes all over the place (that's how/why I Emailed them some time ago and got a response from Bill Mensch acknowledging the mistakes). However, I also own the original Lichty/Eyes book (which contains basically both of WDC's above documents), but there's no difference in what's depicted.

I wonder if the 6 cycle thing is somehow truly a 65c02 specific detail, and that proper page wrapping (as implemented on the 65816) doesn't cost an additional cycle -- i.e. the 65c02 had some "kludge" put in place to fix the JMP ($xxFF) bug that cost an extra cycle, which was later alleviated on the 65816 (where the bug is also fixed) sans the cycle penalty.

I should probably just ask WDC. Sorry for getting hung up on a single opcode, but I do find it strange.

There really seem to be a few errors in there - SNES/emu coders have to compare with enthusiast documents (e.g. 1 2 3). But JMP (a) seems to be correct.

As to the 65?02 variants I've found these docs: 1 2 3

Thanks for that link, finally finished coding the bare minimum PPU/DMA features that these roms needed, so I can finally use them to fix up the (numerous) CPU bugs they detect :p

And thanks for taking the time to make this post, tepples!

Does the IIgs still not have counters?

I don't know what you're talking about, unless it's PMC? If so, no, there isn't any performance monitoring counters in the CPU. In fact, I don't know of this being very commonplace on any non-present-day CPU. There isn't anything that can relay/display/whatever that level of granularity either (a 1 CPU cycle variance). Generally speaking for counting CPU cycles, you quite literally count them -- based on CPU vendor documentation. Which is where there's a strange discrepancy. I do suspect though that it's 5 cycles, and that for whatever reason (kludge-fix) it's 6 on the 65c02 specifically.

If you only run the instruction once, sure. But if you do it one hundred times, that's a difference between 500 cycles and 600 cycles, and that's a lot easier to measure.

On the Commodore range- PET->A4000 we have VIA and/or CIA chips which have cycle level timers.

So on a C64, I can start the timer, perform an instruction, then read the timer. If we know the length of the other instructions, then one can do simple maths to work out how long the unknown bit took.

I can see if I can find somebody with a SuperCPU to test it if you like.

Yeah, the Apple II series has nothing like that that I can think of off the top of my head, but of course the last time I was deeply involved with the system was in the very early 90s. You Europeans and your fancy Commodore equipment... ;-)

There may be some other incredibly clever way to do this, but it gets into being clever with the hardware, which is again an area where I tend to bow out. References I can think of which might be helpful:

* http://www.1000bit.it/support/manuali/a ... erence.pdf -- for ROM01. This is probably where you'll find the answer / get an idea
* https://archive.org/details/Apple_IIGS_ ... Publishing -- firmware reference. This may also be where you'll find the answer / get an idea. Edit: actually, this is probably the best place to start looking for ideas, then maybe the above PDF for the rest. This is what documents the MMIO registers for a lot of the capability, but actual memory map and things like graphics memory layout are in the Hardware Reference (you really needed both sets of books)
* https://apple2.gs/downloads/Apple_IIgs_ ... ematic.pdf -- schematics. Not sure if this is of ROM00 (yikes! No!) or ROM01 (good/OK), but certainly not ROM03 (yes it is different)

I have some of these volumes in print, but finding proper digital copies is sometimes painful. I have a digital copy of an older (by 3 years) draft version of the IIGS Hardware Reference if needed: better scan (B&W), OCR'd (so you can search for words), and not photos of just "an open book stuck on a scanner bed where half the time the text can't be read" (whoever did that scan really didn't bother checking the quality of their work. Sad).

I'm sorry that I'm not throwing tons of effort into diving in and coming up with the method/answer myself, despite my IIGS background, but you could say my heart just isn't in it for something like determining a 1 cycle variance on a specific opcode addressing mode that is probably not commonly used given its design. I can't even remember how much CPU time (cycle-wise) VBlank is on the IIGS, for example. It's been that long.

Usually for "amount of time" visual representations, cycle-wise, we used the technique briefly mentioned here (used bits 3-0 of $C034), but it isn't precise. For example, I can't tell you how many CPU cycles it would take to get something "visual" that was consistent, enough where you could tell the difference between, say, 5000 and 6000 cycles. Maybe instead just using the entire screen filled with a single colour (ex. colour #0) then adjusting palette selection when doing a whole series of jmp ($xxxx)s, and resetting the actual palette colour back to a different colour, on a per-scanline basis, would work (sorry, IIGS terms here). I mention tweaking the palettes instead of actually updating the on-screen video RAM because the former involves way less bytes.

I'm an Ozzie, aka Aussie aka Australian, Commodores are half the price of the Apple computers and Commodore was an American Company.
You just fell for Apple's misleading marketing, they weren't even big in America

If it's still not precise enough, just keep adding 0s until you can measure it with a stopwatch. Or a sundial...

I had never thought about using sundials for hardware tests... but for long-term test results, that's probably really more accurate than using quartz oscillators, or even ceramic resonators. Then on the other hand, https://www.3dbrew.org/wiki/TIMER_Registers claims that 3DS timers"run at a frequency of 67,027,964.0 ± 2^-32 Hz" so the estimated error would be about ±1 cycle per century, or less than ±1 second per billion years... if that's true then a 3DS might outperform sundials : /

For measuring opcode timings with low frequency timers, I have used someting like this: Execute opcode, Increment counter, Repeat until vblank. That's more than accurate enough, but can get slow when testing hundreds of different opcodes.

PS. 65C02 being an 8bit CPU, it makes sense that it would be 1 cycle slower on 16bit increments than a 16bit CPU (or than a 8bit CPU tht lacks proper page wrapping).

Actually, they were big in America -- particularly in schools, which is exactly where most people around my age got introduced to them (I'm 42). Nearly every school I attended growing up had Apples. Other folks that had them were enthusiasts, since at the time the original Apple II debuted, the concept of a "computer at home" was considered ridiculous except to engineers and nerds. And much like the Famicom/NES, they were designed minimally and on a budget (Jobs wanted to maximise profits); Wozniak was a genius in a way, but all of that didn't necessarily make for a more "capable" machine (compared to C64, Amiga, and PC); a great example of serious design annoyance on the Apple II were "screen holes", something I really hate remembering.

I certainly won't deny that the Apple's stuff was overpriced: I still have the original store purchase receipt for my IIGS in December 1987 (it was RTM September 1986): US$2809.40, including monitor + floppy drives + RAM upgrade + printer + software (I didn't get a SCSI controller and HDD until ~1991). Not much has changed with Apple and their inflated prices. :-)

I should add that I've never been an "advocate" for any particular kind of computer from any company, nor did I have a fixation on Steve Jobs (Wozniak was always the guy who I felt more in line with); despite being brought up on Apple hardware, I was never an "Apple II zealot", though that attitude was rampant in the Apple II community (and did in the Macintosh community too -- still is, just that the worship today comes in a different form). My home had an XT growing up, but it wasn't until late 1993 when I managed to buy my own personal computer (486 DX2/66) that I really felt like I had something that was capable of all the things I wanted and had been missing out on. It took me a little over a year to "ween" myself off of the IIGS (I gave away my entire setup to my demogroup-mate, and looking back on it now, I honestly wish I hadn't). I'll always have a soft spot for the thing, but I wish I'd gotten a PC (or even an Amiga) a lot earlier. But, I certainly wouldn't have done my SNES docs or my NES docs had I not been brought up on Apple II hardware and gotten to know 65xx.

Regardless, if you haven't read Jobs' biography and Wozniak's autobiography, I would highly recommended both.

Anyway -- I could say the same thing of Commodores and Amigas: I only knew one kid at school who had a C64 (most people had nothing, else an Atari or TI computer), and not until 1993 did I encounter anyone with an Amiga (A500), after which I managed to meet 3 more who did (A1200, A2000, and A4000). I still find them more or less "obscure" in the United States. Point: when it comes to discussing 80s/90s computers, region/demographic matters tremendously.


Having hardware folks around is always helpful. :-) Then this would explain the added cycle on the 65c02 for sure, and why the added cycle doesn't apply to the 65816. I'm not even sure I need to go code anything up given this statement!

Big is a relative term. So yes America was Apple's no1 and largest market, and if you compare Apple in the USA to Australia(and everywhere else), Apple was big in the USA. However they were small in the computer market. Apple were always 3rd in the race and not just 3rd but dead 3rd. Tandy TRS-80 line was the 2nd personal computer and the no1 in America for a long time, until the Tandy 1000 range took over their "80" range. The first personal computer the P.E.T was the worlds number one, however it was a solid 2nd in the USA. The PET and TRS-80 sold in the 6 digits, Apple ][s where 5 digits by the time the VIC-20 came out. The VIC-20 sold like hotcakes in the US(hitting 7 digits in under a year), then the C64 dominated, the 128 carved out a nice corner of the market. Apple pushed into the education market hard and a lot of schools had them ( here as well ) however it didn't really help them that much in the end. While they designed the Apple ][ to be low cost, it still cost double the P.E.T and the P.E.T was the first computer out. To be fair the first model P.E.T had a chiclet keyboard which sucked infinity but they fixed it quickly. And the PET doesn't have bitmap graphics, or colour. The Apple II disc drive was the fist on the market and was a brilliant piece of engineering, however the way it was built into the machine became a curse more than a benefit I feel.

Don't believe a single word that comes out of Steve Jobs's mouth, the guy has a reality distortion field that could deflect a nuke http://www.righto.com/2012/02/apple-did ... power.html and http://www.righto.com/2017/10/the-xerox ... puter.html

I do recommend this book https://www.amazon.com/Sophistication-S ... 0986832278 it does its best to dance around and conveniently not mentions some other things that had happened at the time, but it does have to stare down the barrel of reality sometimes, even if it does claim Woz invented the "monitor"

If you want to know what the Apple revisionist have removed and what Apple has slapped their name on, read this one https://www.amazon.com/Commodore-Compan ... 0973864966 although be prepared for some face palming because Man at the end Commodore's management really really did some dumb stuff.. its no accident the company is no longer around...