Any volunteer proofreaders?

dclxvi · Post by **dclxvi** » Sat Apr 23, 2011 8:10 pm

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.

ChuckT · Post by **ChuckT** » Sat Apr 23, 2011 9:42 pm

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.

BigDumbDinosaur · Post by **BigDumbDinosaur** » Sat Apr 23, 2011 11:18 pm

dclxvi wrote:

The long-promised 65C816 opcodes write-up is finally complete...Verifying examples -- I don't have an actual 65C816 to experiment with at the moment...

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

GARTHWILSON · Post by **GARTHWILSON** » Sun Apr 24, 2011 12:13 am

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.

BigEd · Post by **BigEd** » Sun Apr 24, 2011 9:33 pm

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.

ElEctric_EyE · Post by **ElEctric_EyE** » Mon Apr 25, 2011 12:29 am

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

dclxvi wrote:

...If anyone is interested, let me know (PM or email is fine) ....

dclxvi · Post by **dclxvi** » Wed Apr 27, 2011 2:36 am

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:

Quote:

Example: If the accumulator is $0F06 and the m flag is 0, then after EOR
#$F103

the accumulator will be $FE05
the n flag will be 1
the z flag will be 0

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:

Quote:

Example 2: If the D register is $FF00 and the m flag is 0, then LDA $FF
loads the low byte of the data from address $00FFFF, and the high byte from
address $000000

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!

GARTHWILSON · Post by **GARTHWILSON** » Wed Apr 27, 2011 4:35 am

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

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Apr 27, 2011 7:33 pm

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.

dclxvi · Post by **dclxvi** » Thu Apr 28, 2011 2:10 am

GARTHWILSON wrote:

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

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.

ElEctric_EyE wrote:

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

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.

BigDumbDinosaur · Post by **BigDumbDinosaur** » Thu Apr 28, 2011 4:30 am

ElEctric_EyE wrote:

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.

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.

dclxvi wrote:

I tried to capture emulation mode behavior (particularly with new instructions/features) reasonably completely

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.

BigEd · Post by **BigEd** » Thu Apr 28, 2011 6:05 am

BigDumbDinosaur wrote:

dclxvi wrote:

I tried to capture emulation mode behavior (particularly with new instructions/features) reasonably completely

From my perspective, a "boiled down" version with little discussion of emulation mode seems entirely appropriate.

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

BigDumbDinosaur · Post by **BigDumbDinosaur** » Fri Apr 29, 2011 4:28 am

BigEd wrote:

BigDumbDinosaur wrote:

From my perspective, a "boiled down" version with little discussion of emulation mode seems entirely appropriate.

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.

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.

Quote:

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.

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.

dclxvi · Post by **dclxvi** » Sat Apr 30, 2011 6:38 pm

BigDumbDinosaur wrote:

you can't relocate zero page

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.

BigDumbDinosaur wrote:

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?

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.

dclxvi · Post by **dclxvi** » Thu Jun 23, 2011 1:56 am

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.