Commander X16

DragWx wrote: ↑Tue Feb 13, 2024 8:29 pm I think they just want the option of an upgrade path to the 65816 to stay available for those who would be interested in doing so, remembering that the X16 is meant for tinkering, and that includes seeing what can be done when a 65816 (a friend of the 6502, remember) is dropped in.

Actually, this started because David wanted to use a 65C816 in the Gen-2 system. That would not be upgradable, since that will be soldered in.

This would mean the KERNAL and hardware now need to fully support the 816 as an option, since the current system is the "Developer" system, intended to be used to write and test software for the future "Console" Gen-2 system.

I could even see batch 3 just coming with a 65C816 by default, with maybe a $20 upgrade to get a 65C816 upgrade kit for the prototype, batch 1, and batch 2 systems.

TomXP411 wrote: ↑Wed Feb 14, 2024 4:35 am ... Actually, this started because David wanted to use a 65C816 in the Gen-2 system. That would not be upgradable, since that will be soldered in. ...

Well, in that case, I take it back ... don't include the BBR etc. operations.

Also, yoawza, if the X16 Console has the 65C816, that pushes me from a probably get to a certainly get, probably pre-order.

Looks like I get to brush up on the 65816 then.

BruceRMcF wrote: ↑Wed Feb 14, 2024 6:10 am

TomXP411 wrote: ↑Wed Feb 14, 2024 4:35 am ... Actually, this started because David wanted to use a 65C816 in the Gen-2 system. That would not be upgradable, since that will be soldered in. ...

Well, in that case, I take it back ... don't include the BBR etc. operations.

Also, yoawza, if the X16 Console has the 65C816, that pushes me from a probably get to a certainly get, probably pre-order.

It's not a sure thing, yet, but there's been a lot activity around addressing the issues. Stuff with VERA, the native mode interrupts, and a few other odds and ends have been attacked by user over the last few weeks.

TomXP411 wrote: ↑Wed Feb 14, 2024 8:31 am

BruceRMcF wrote: ↑Wed Feb 14, 2024 6:10 am

TomXP411 wrote: ↑Wed Feb 14, 2024 4:35 am ... Actually, this started because David wanted to use a 65C816 in the Gen-2 system. That would not be upgradable, since that will be soldered in. ...

Well, in that case, I take it back ... don't include the BBR etc. operations.

Also, yoawza, if the X16 Console has the 65C816, that pushes me from a probably get to a certainly get, probably pre-order.

It's not a sure thing, yet, but there's been a lot activity around addressing the issues. Stuff with VERA, the native mode interrupts, and a few other odds and ends have been attacked by user over the last few weeks.

I was following the part of the native mode interrupt work which was passed along ... which is clever coding ... and the stuff with writing the Vera Dataports A and B with a single 16bit 65816 instruction ... which is so far out of my wheelhouse that I don't know whether it is clever FPGA design work, but is in any event a clever improvement ... and so I'm going to have my fingers crossed on the "few other odds and ends".

Faster p-code or m-code Pascal, faster Forth ... I would presume it would allow someone to make speed improvements on Basic and/or to write a hosted Small C compiler generating both smaller and faster code (though the writing of those are left as an exercise for the reader) ...

... and increasing the bandwidth between the main X16 system and Vera's internal RAM for assembly language games ...

... what's not to love?

BruceRMcF wrote: ↑Wed Feb 14, 2024 6:01 pm
... what's not to love?

Rewriting all my code. Every breaking change to the emulator has put me behind by months as i go back and revise code. This change would wipe out four years of work.

Why would you rewrite all of your code? Do you make that heavy use of the BBR, BBS, RMB and/or SMB instructions?

As long as you don't use the Rockwell bit-specific instructions, and the Kernel and interrupt processing works correctly, the 65C816 running in emulation mode should run existing code just fine.

BruceRMcF wrote: ↑Wed Feb 14, 2024 6:01 pm... what's not to love?

A 16-bit CPU with a 24-bit address bus weirdly hamstrung by a memory map designed for an 8-bit CPU isn't quite ideal, IMHO.

Ser Olmy wrote: ↑Wed Feb 14, 2024 9:14 pm

BruceRMcF wrote: ↑Wed Feb 14, 2024 6:01 pm... what's not to love?

A 16-bit CPU with a 24-bit address bus weirdly hamstrung by a memory map designed for an 8-bit CPU isn't quite ideal, IMHO.

Yeah, that's not ideal. We actually discussed ways to mitigate that (a few of us on Discord)... but those would all cause the situation Ed was complaining about. Allowing the CPU to directly control the bank registers would certainly be a breaking change.

Personally, I'd love to see some sort of interposer board that lets you add 65816-specific extended memory and which could be addressed using the 816's internal bank registers. We could even load a modified KERNAL into memory on this board with improvements for things like far get, far fetch, and far jump instructions (by putting them on 816 extended memory, rather than $A000 banks.)

Someone will end up designing a proper Commander 816, which moves to a flat memory model... but it will, of course, require heavy modifications to the KERNAL and application programs to operate.

BruceRMcF wrote: ↑Wed Feb 14, 2024 8:26 pm Why would you rewrite all of your code? Do you make that heavy use of the BBR, BBS, RMB and/or SMB instructions?

Yes. Lots and lots. The main loops on both Asteroid Commander and the Surreal game engine. Lots of uses in the META/L editor. The multiplication and division of FASTMATH and FASTATAN. Everything. I'd have to change around 20 thousand lines of assembly language code to make it all work without BBR, BBS, RMB, and SMB.