Several of the homebrew 6502 cores here have extended the original instruction set, sometimes by using prefix bytes. But the C65GS project extends the 65CE02 which already has all opcodes assigned.

Paul Gardner-Stephen's innovative solution is to use NOP, SED and CLD as prefixes! This is interrupt safe because these operations are single-cycle and there is no interrupt window before the next instruction.

For more info, see our gplus post and the links within:

On the prefix idea, and
http://c65gs.blogspot.com.au/2014/11/ea ... emory.html

On Commodore's never-released C65 product:
http://www.floodgap.com/retrobits/ckb/secret/65.html
http://en.wikipedia.org/wiki/Commodore_65
http://www.zimmers.net/cbmpics/cbm/c65/c65manual.txt

On the CPU:
http://en.wikipedia.org/wiki/CSG_65CE02
http://www.commodore.ca/manuals/funet/c ... 65ce02.txt

On the enhanced FPGA rebuild project, C65GS, there's a blog, a github repo and a mailing list:
http://c65gs.blogspot.com.au/
http://github.com/gardners/c65gs
https://groups.google.com/forum/#!forum ... evelopment

And there are videos:
https://www.youtube.com/results?search_query=c65gs

What if a programmer wants to toss in a couple of NOPS as a delay mechanism?

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

> What if a programmer wants to toss in a couple of NOPS as a delay mechanism?

Most instructions would be unaffected. Of course, some awareness of the mechanism is necessary! It's maybe worth noting that NOP is renamed as EOM in the 65CE02 - it already has a side-effect.

Hello,



This is fine before anything other than a (ZP),Z instruction (although (ZP),Y will probably gain this enhancement, too, as it is convenient and efficient to be able to copy between two pointers that way.

If you want to cause a single cycle delay, then there are plenty of other single-cycle instructions, e.g., CLD could be used. As mentioned elsewhere, NOP is EOM on the 4502 in any case, so it is not free of side-effects.

Really the main concern is software that is written for the 65CE02, but finds itself on a GS4510 somehow. The planned solution in that case is that presumably that software would be running in C64/C65 mode, and the hypervisor would just lock out the 32-bit pointer extension, so that NOP + LDA ($12),Y does what it used to do. Hypervisor-based CPU extension control flags are easy to implement.
For completeness, a GS4510-aware programme running in C64/C65 mode on a C65GS could in the future trigger a hypervisor trap to request that particular extensions be turned on.

Paul.

(Good to see you here Paul! Welcome, and I hope you stick around - please consider a post to the Introduce Yourself thread.)

Hello,



Thanks -- I'll do that when I have a bit of spare time to compose something orderly.

Meanwhile, I need to make an ELF-like file format for loading programmes >64KB so that I can start serious testing of the 32-bit pointers in my unicode string renderer.

Paul.

The 65CE02 already has a 4 byte AUG instruction ($5C) "reserved for future expansion", whose purpose I assumed was to act as a prefix, followed by a new 3 byte opcode, giving 256 more operations. This would surely be a more conforming way to do this?

As far as I can know, AUG is replaced by the MAP opcode in case of C65 (on 4510 which is basically [?} a 65CE02 core and two CIAs) it allows 1Mbyte of RAM mapped into the 64K address space of the CPU. Also the NOP opcode is also treated as EOM (End Of Mapping?), though just executing NOPs does not cause anything unexpected. These are for C65 (not C65GS which knows some extra mapping, 32 bit addressing etc [?] too, in addition of this).

Btw, have you heard? http://mega65.org/