The long-promised 65C816 opcodes write-up is finally complete. I have been proofreading it, but I am the point where all I am seeing is what I intended to write rather than what I did write. The only proofreader for my previous articles was me, and miraculously, they didn't wind up riddled with technical errors. (The errors I've since caught were of the bad-writing variety, e.g. misplaced commas, "the the" which should have been "the".)

Since this new article is about 3.5 times longer than anything else I've done (the v flag and decimal mode tutorials were "long" by this standard), a second (or third or more) set of eyes would probably be good, before it gets added to the Tutorials and Primers and I look even more ridiculous than usual.

The big things to look for are:

• Technical errors
• Explanations that aren't clear
• Verifying examples -- I don't have an actual 65C816 to experiment with at the moment, and won't for a little while. Much of the article was based on notes I'd made, so there's a distinct possibilty of error there.

However, if you want to nitpick things like commas and verb tense, that's fine too. A comment such as "this is boring and should be completely rewritten" may be perfectly accurate, though I may have to decline to act on that.

If anyone is interested, let me know (PM or email is fine) approximately when you'd be have time to proofread it (this article has been on-again, off-again for a long time, so it isn't essential that you're available immediately).

For your efforts you will receive...well, there is no prize; reading a long text file of my stultifyingly boring prose is more like penance. Seriously, I'm sure I can talk Mike into giving some sort of contributor credit when he adds it to the Tutorials and Primers.

My wife is a school teacher and types papers in for other people on the college level. I can't promise you anything but I'll see how she feels looking at it.

I have a functioning 65C816 system (my POC unit), on which I can assemble and run programs. I can verify modes of operation (other than the /ABORT hardware input). Lemme know...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I can give it a try. For proofreading one's own stuff, I read many years ago that something that works well is to read it upside down. I do find it works surprisingly well.

I can help with the proofreading, and probably with the '816 aspects too (supposing everything still works as it did last time it was all put together) - although it sounds like BDD is better placed for a quick start on that.

I would like to ask as well, even though you had originally said to PM or email...

Thanks everyone for volunteering!

Almost all the are of the examples are a single instruction, with the relavant flags, registers and memory locations before and after. This is typical:



So testing it just involves setting up the relavant registers and flags, then outputting the result to make sure I got the results right, and that I didn't have a flag inverted, the byte order is correct, etc. Each example should be easy/quick to test. There's a lot of examples, though.

The addressing mode examples are somewhat untypical. Here's one:



The direct page is usually not at $FF00; however, this was chosen to illustrate that there is not page wrapping but there is bank wrapping. Some of the addressing mode examples may be tricky to test because they're at/near the interrupt vectors (bank-switched RAM/ROM or the VPB signal is helpful here).

Any or all of the articles and/or examples that anyone cares to look at and/or test would be great.

I don't want to say that the writing portion is irrelevant (again, feel free to comment on that), but I think accuracy of the technical details is far more important. The audience isn't literary critics, so my goal here is to write "good enough for an engineer".

I just emailed it out a couple of minutes ago, so if you didn't get it but want it, let me know. Hope I didn't forget anyone!

That'll definitely take some time to get through, due to its length.

Seems to be more like a boiled down version of the 438+ Pg. Programming the 65816 by Eyes & Lichty, which I've not gotten around to reading yet.
Bruce's work sort of looks like a 65816 primer, not so intimidating as the 438pg monster. I'm going to print it out and put it in the same folder.
When it comes time to update my PWA with the '816, I plan on using the T65 Core, and then I'll be more qualified to speak on this. Maybe compare notes with BDD.

My other articles I was able to proofread in their entirety in one sitting/evening. Then the next evening I could look at it again. This one was too long for that. I wish it wasn't so long, since it's easy to forget earlier pieces (making consistency more difficult) when reviewing it a piece it a time.

There is no rush, though. I'd rather it be reviewed thoroughly at a more leisurely pace than getting it in the Tutorials and Primers right away.



Yes, there is overlap between the two. I don't remember if WDC had that on their website back way back when I first started this. I tried to capture emulation mode behavior (particularly with new instructions/features) reasonably completely, and I though the addressing mode diagrams turned out well.

The Eyes and Lichty tome is dated, and some of the information is suspect. For example:

The assembly syntax used in this book is that recommended by the Western Design Center in their data sheet (see Appendix F). The assembler actually used in the ProDOS ORCA / M assembler for the Apple II computer, by Byteworks, Inc.

I've never found anything published by WDC that recommends or recommended the ORCA/M assembler, or any other assembler, other than that included in the WDC ProSDK. Also, where's this Appendix F they refer to? It isn't in the book or in the data sheet.

Aside from the above, the Eyes and Lichty book tries to cover three different processors, which given the title Programming the 65816, is a bit annoying. The '816 is sufficiently advanced over its eight bit brethren to warrant a separate treatment that does not go on and on about emulation mode (Why use it?), elementary 65xx programming techniques (already discussed to infinity in countless other books) or how to use an assembler (Which one?). Eliminating the constant jumping between the 6502, 65C02 and '816 would knock at least 100 pages out of the book with no loss in useful information.

On the other hand, the Eyes and Lichty book barely touches on how the '816's interrupt handling is different from the eight bit MPUs, what happens when /ABORT is asserted, etc. Since all of us here are essentially working from bare metal with our creations, this sort of technical detail is quite useful, methinks.


From my perspective, a "boiled down" version with little discussion of emulation mode seems entirely appropriate. Emulation mode is 95 percent compatible with the 65C02, so why rehash a topic that has been endlessly covered by others? The other five percent represents a mode of operation that doesn't take advantage of what the '816 gas to offer. In other words, there's not a whole lot of benefit to designing an '816-powered system that is going to be run in 'C02 mode. That's like buying a Porsche and never getting it out of first gear. Just a curmudgeonly opinion, of course.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

But of course. Your perspective is the POC, a 'fresh start' 816 system. The nature of the 816 product is to allow for backwards compatible upgrades, and it's quite appropriate to document emulation mode for people with a wider perspective. The SuperCPU is a case in point, maybe also the Apple GS.

It may be that one could tease apart all mentions of emulation mode into separate sections or appendices, but I think a complete treatment is a very good idea. Knowing exactly what to expect when writing application code on an 816 when the OS (and interrupt handlers) expect to be running on an 02 is useful, when that's the situation.

Cheers
Ed

Well, the '816 is not plug-compatible with any eight bit 65xx iteration, so by definition, any system designed around the '816 would be "fresh start" methinks.


The operation of a 65C02 has been very well dissected. Excepting the BBR/BBS instructions of the 65C02, the presence of the '816-unique instructions and the /ABORT input, the '816 in compatibility mode *IS* a 65C02. You can't select the 16 bit register widths, you can't relocate zero page, you can't put the stack anywhere except page 1, the hardware vectors are in the same place, etc. Why reinvent the documentation wheel on all that? All of the unique '816 instructions (e.g., COP and TXY) will work in 'C02 mode, but most are of limited value. For example, MVN and MVP can only affect page zero in 'C02 mode, which makes them essentially useless unless in native mode.

My belief is if one is going to (re)write a manual about programming the '816, it should be about programming the '816, not its 'C02 alter ego. Some material about switching modes and the implications of doing so (especially in an interrupt handler) is fine, but I think the concentration should be on the MPU's native mode of operation.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Actually, this one you can do in emulation mode. You even get ZP wrapping as long as DL is $00. Personally, I've found this very helpful; I can get someone else's extant 65(C)02 code up-and-running first with two zero pages, then I'll resolve ZP conflicts (with I/O or OS routines) after that.



It doesn't spend much time on the 95%. A 65C816 version of the "NMOS 6502 Opcodes" is inevitably going to overlap the 65C816 Programming Manual, so rather than just repeating the material, I took the opportunity to fill in the gaps and address some of the things that come up on the forum from time to time. Things like differences between 8-bit native mode and emulation mode (TXS is one that's not obvious at first blush).

There is a lot more 65(C)02 code than 65C816 code out there, so I wanted to address things that might come up when adapting code for native mode. Adapting to 8-bit native mode before updating routines for 16 bits is one way to do this incrementally. There are quite a few of us here who are into retrocomputing and/or retrogaming (and who think simulators are "cheating" )

I also wanted to point out the things that are actually different between the 65(C)02 and emulation mode. For example, JMP ($12FF) get the high byte from $1300 (like the 65C02) but takes 5 cycles (like the NMOS 6502), so it's not exactly like either.

Also, many simulator writers seem to be very interested in replicating absolutely everything -- even things that would never break any code that isn't a unit test. For example, V flag in decimal mode, the fact that the high byte of the LDA ($FF),Y pointer is $0000 not $0100, etc.

Somewhat surprisingly, very few people (even those who are otherwise very knowledgable about the 65C816 and the 6502 family generally) are really all that familar with when page/bank wrapping does or does not occur. So that seemed like another good gap to fill.

Still, the thrust of the article is native mode. I used many 16-bit examples because 2 bytes allowed me to illustrate when wrapping did and did not occur with a single example.

It's been a while since I've received any feedback on this, and in a week or so, I'll have an actual 65C816 available to test examples. So, if you have any feedback, please send it to me on or before July 6. If anyone would like more time, let me know. I don't mind extending the deadline, but I might as well finish it up and send it off to Mike if there's no additional feedback forthcoming.

Once again, thanks to everyone for their feedback.