http://laughtonelectronics.com/Arcana/K ... intro.html
For something that was developed independently of the 65816, it's shockingly reminiscent.
65C02 plus lots of external logic yields similar to 65816
Re: 65C02 plus lots of external logic yields similar to 6581
Just to give a TL;DR (although I thought it was a quick read):
* Use two 74'670s to yield four bank registers (he calls them K0 through K3)
* The /SYNC output on the 65C02 lets him capture, intercept, and replace opcodes from memory before it enters the CPU. This is microcoded using external ROMs
* Forces all stack and direct-page accesses to only bank 0, while normal execution happens from K0
* Opcode prefixes (like the Z80 or x86) let him force the following instruction to always use a different bank register for the data portions of that instruction
* special hardware-optimized implementation of NEXT for fast FORTH performance
* function to copy just the computed address from (zpg,X) into a pair of zeropage registers
* special ZX80-like "emit bytes starting at this address as a scanline of pixel data" instruction
And one last interesting bit:
* This 65C02 retains several of the "multibyte nop that does memory accesses" of the NMOS 6502, specifically: $82, $C2, and $E2 are still NOP #imm, $44 is still NOP zpg, $54, $D4, and $F4 are still NOP zpg,X. However, $DC and $FC are now just NOP abs, not indexed by X, and $5C is now extra bonus weird.
* He decided on the same "LoaD and Discard" mnemonic that I had thought of when we were discussing these instructions
* Use two 74'670s to yield four bank registers (he calls them K0 through K3)
* The /SYNC output on the 65C02 lets him capture, intercept, and replace opcodes from memory before it enters the CPU. This is microcoded using external ROMs
* Forces all stack and direct-page accesses to only bank 0, while normal execution happens from K0
* Opcode prefixes (like the Z80 or x86) let him force the following instruction to always use a different bank register for the data portions of that instruction
* special hardware-optimized implementation of NEXT for fast FORTH performance
* function to copy just the computed address from (zpg,X) into a pair of zeropage registers
* special ZX80-like "emit bytes starting at this address as a scanline of pixel data" instruction
And one last interesting bit:
* This 65C02 retains several of the "multibyte nop that does memory accesses" of the NMOS 6502, specifically: $82, $C2, and $E2 are still NOP #imm, $44 is still NOP zpg, $54, $D4, and $F4 are still NOP zpg,X. However, $DC and $FC are now just NOP abs, not indexed by X, and $5C is now extra bonus weird.
* He decided on the same "LoaD and Discard" mnemonic that I had thought of when we were discussing these instructions
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: 65C02 plus lots of external logic yields similar to 6581
I was rather intrigued by this idea when I found the article ~year ago. Had thought about how it would be interesting to apply some of these methods to the NES with a mapper. Utilizing undocumented NOP's to create new 8/16bit registers, far addressing, and other functionality could be of great benefit to a C compiler if one were so motivated to put in all the hardware and software development required. Problem with that idea is assembly isn't actually as bad as many make it out to be, and you could make a number of games/tools with the work involved with something like that and not become dependent on high end hardware.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: 65C02 plus lots of external logic yields similar to 6581
The one thing C does is let you share game logic with a PC, Sega Genesis, or Game Boy Advance version of the same game, even if you do write all the graphical and audio output in assembly language.infiniteneslives wrote:Utilizing undocumented NOP's to create new 8/16bit registers, far addressing, and other functionality could be of great benefit to a C compiler if one were so motivated to put in all the hardware and software development required. Problem with that idea is assembly isn't actually as bad as many make it out to be
Re: 65C02 plus lots of external logic yields similar to 6581
Pretty neat. Not having worked with the 65C02, I didn't realize it has a single-cycle NOP.
Previously I had considered making an NES mapper with separate program and data banks. My idea would have just been memory-mapped registers and not anything as fancy as what that guy made. We don't have the SYNC signal, but you could emulate a 6502 inside the mapper to generate one. Considering that though, to me made it sound more attractive to just add some memory and run the emulated 6502 independently and faster.
Previously I had considered making an NES mapper with separate program and data banks. My idea would have just been memory-mapped registers and not anything as fancy as what that guy made. We don't have the SYNC signal, but you could emulate a 6502 inside the mapper to generate one. Considering that though, to me made it sound more attractive to just add some memory and run the emulated 6502 independently and faster.
Re: 65C02 plus lots of external logic yields similar to 6581
Thanks for your interest, lidnariq, and for the summary you wrote -- I was glad to get your take on the project.lidnariq wrote:* Use two 74'670s to yield four bank registers (he calls them K0 through K3)
* The /SYNC output on the 65C02 lets him capture, intercept, and replace opcodes from memory before it enters the CPU. This is microcoded using external ROMs
* Forces all stack and direct-page accesses to only bank 0, while normal execution happens from K0
* Opcode prefixes (like the Z80 or x86) let him force the following instruction to always use a different bank register for the data portions of that instruction
* special hardware-optimized implementation of NEXT for fast FORTH performance
* function to copy just the computed address from (zpg,X) into a pair of zeropage registers
* special ZX80-like "emit bytes starting at this address as a scanline of pixel data" instruction
I notice you linked to the KK Computer main article, which is over eight pages long. In case anyone finds that too long -- but found your summary too short -- here is a summary I wrote myself. It's just one page, so hopefully in the Goldilocks zone, lengthwise. The KK Computer appeared on NesDev before but basically got ignored. (That was before I added the summary.)
No kidding, you called 'em that, too? That's funny. But I never realized LDD was among the undefined instructions on the NMOS chip. I only studied the Rockwell 65C02 undefined instructions. (BTW, recent tests reveal KK also works with a modern WDC 65C02 installed, confirming its undefined instructions are identical to Rockwell's. Well, almost identical. There are two less, as WDC added the STP and WAI opcodes.)lidnariq wrote:He decided on the same "LoaD and Discard" mnemonic that I had thought of when we were discussing these instructions
Yeah, and the single-cycle NOP's have terrific potential for hardware hacking, mainly because they're so easy to decode. Garth Wilson posted an example of this (below). Not exactly mainstream for a NES forum, but maybe some of you will find it interesting.Memblers wrote:Not having worked with the 65C02, I didn't realize it has a single-cycle NOP.
-- Jeff
Some tricks from Jeff Laughton (Dr Jefyll on 6502.org's forum)