This sounds like a much better spec. Using the 65c816 keeps the 8-bit vibe but doesn't force you to play the bank switching game to access more than 64K. DVI instead of VGA itself is also enough to give it a much better chance of success.
So while changing a bank register is easier than doing bank switching with a 6502, it's actually not that different. And using the 16-bit registers on the 816 require a mode change, so working back and forth between 8 and 16 bit values is also awkward.
The 816 on paper sounds good at first. In practice, after working with it for a while (I wrote an emulator for an earlier version of her machine and then started working on software) I found I didn't enjoy the 816 as much as I thought I would and understand better now why Commodore and Atari made the jump to the 68000 instead of to the 816 or other modifications to the 6502.
I am currently working on a compiler for the 65816 and has taken the approach of avoiding mode shifts as much as possible. I also lock the direct page and bank register to a fixed place while running normally. This simplifies it a lot.
Segmenting your functions/code block on 64K is not a huge limitation. How big functions do you write? LOL
The 65816 does require more discipline when programming than the 6502.
Yes, they all went 68000 which is no wonder as it was a step up further. The 16 revolution never really happened, we went from 8 to 32 bits computers.
Commodore did go back to modify the 6502 later, that was the Commodore 65. That the C65 project went as far as it did is beyond me. I would have stopped it immediately if I was shown it at the time, both from marketing and technical aspects. Today, I suppose it makes some minor sense to revive it as a curiosity, just for the sake of it.
I wonder how you can find the 65816 odd, when the Mega 65 comes with three altered variants of the 6502. Also considering that some well known 6502 programming idioms no longer works as before, as soon as you move the zero page or the stack. Having studied them all, I find the 65816 puts those 6502 variants to shame.
When I was playing with the 816 I did use the technique you describe using the direct page. But I recall there being limits on where I could use that.
The 816 is a bunch of compromises. And some awkward ones because the opcode space was all eaten up.
If you move the stack or zero page, the well known trick of using absolute plus index register no longer works the same as on the 6502 (breaking existing code). Sure, you could hardcode a different page, but the point of moving the stack is (probably) so you could do multi-tasking. But if processes are given different stack pages, they can no longer share code (if using such well known tricks in the code). Moving zero page is in 256 steps, so you cannot use it as a movable stack frame (the 65816 can set it to any location in the first 64K).
I know there is a lot of interest in the Mega65, but I found it had so many poorly made design decisions that made me want to stay far away.
So far I find the 65816 to a well designed 16 bits ISA (I am also familiar with PDP-11, MSP430, MELPS7700 and Motorola 6812) that gives a lot of 6502 vibes, but is just a lot better. There are a couple of odd corners, probably due to the opcode space as you mention, but I would not call it a bunch of compromises.
They have GEOS running on it, they have backwards compat with the C64, they have games modified to use its extra capabilities, they have injected molded plastic cases, they have keyboards and keycaps manufactured, they have a version of the Kernal and BASIC ported and expanded, they have a user manual, etc.
And it's a) open source and b) open.
And b) is key because they're also making it possible for their hardware to be used with other FPGA bitstreams, including ones developed for the MiST/MiSTer. They demoed their hardware being used with a GBA core running a GBA game.
Further, they seem to have a CC65 backend -- I don't know of what quality -- but it seems C based software is running on it.
That makes it an interesting and more complete platform and consumer product.
And if I want a better 6502 variant on it, I could do that myself and use one of the various 65xx variant cores out there, or write my own.
EDIT: And, yeah, from my perspective from just casually reading their docs is that the CPU in the MEGA65 is an 8-bit CPU with bank switching and a couple weird 32-bit ops. It's not a 16-bit machine despite.
But the thing about the 816 is that it's only _sort of_ a machine with a 24-bit address bus. It effectively just has a bank switching mechanism, but not external. Mensch really just bolted some stuff onto the front of the 65C02 and widened the accumulator and registers by 8 bits. But the 16-bit registers are a pain. I just wish he'd added some new registers (and a way of combining them) instead of having the mode switch.
Given that a 65c816 is what’s in the SNES, I’d say it has a distinctly 16-but vibe.
Don’t get me wrong; 16-bit is my favorite! Far too few retro projects targeting early-90s era tech, or its portable early-2000s mirror.
(Imagine if you will: a plug-and-play with extended GBA-clone hardware, with a tile-and-sprite PPU that could push 1080p@60 with tons of layered graphics colour-math + windowing + DMA effects, but which explicitly didn’t offer a bitmap mode, let alone 3D acceleration; and tack on both Flash storage and Ethernet APIs, exposed through simple MMIO hardware registers to the games, with all the complexity shunted to a Wii-like IO coprocessor running its own RTOS. It’d be the perfect modern platform for retro-modern 2D JRPGs to be released on. A WonderSwan+++, per se. A PlayStation Zero.)
I don't think retro 3D is a bad idea though. Just do what the DS does (keeping it separate from 2D in the process) and I think it would probably be the greatest console ever made.
Same with bitmap modes: people will use them as a crutch by combining them with software rendering.
(Maybe this could be fixed by putting a hard cap on the 3D frame rate. Maybe even make it so low that all 3D must be precomputed, baked down into a tile map and used through sprites! Under that restriction, it could look arbitrarily good, but the results would still look more SMRPG than Goldeneye.)
And same for sufficiently-good PCM sound. The ideal early-90s sound chip would be something like 128-voice polyphonic MIDI with a huge wavetable (but banked — no playing PCM by walking wavetable samples), passed through an arbitrary FM synth module, with the whole thing being bytecode that can do loops and branching.