C64 CPU MEMORY MAPPED REGISTERS missing details on M65 specifics

[binarycrusader]

Describe where we can find the problematic topic
In Appendix K, there is a section titled "C64 CPU MEMORY MAPPED REGISTERS" that provides a minimal listing as such:

mega65-user-guide/appendix-45gs02-registers.tex

Line 532 in d1ae32d

\section{C64 CPU Memory Mapped Registers}

While it's true that the use of these appears largely unchanged from the C64 (notably, bits 0-5), the Mega65 seems to have undocumented uses for bit 6 and possibly 7.

Describe the solution you'd like
It would be helpful if the Mega65's use of bits 6-7 could be documented. Informally, it appears that bit 6 is used to affect processor speed. It is unknown if bit 7 has any use. For bit 6 it appears bit 0 when 0 is "LOW" and selects "normal speed" (c64 / 1mhz?) while 1 "HIGH" selects "high speed" (4510 / 40MHz?).

Additional context
The C64 Programmer's Reference Guide documents addresses "0 & 1" as "6510 Registers" in the "Simple Memory Map". In the "Memory Management" section it documents this as follows [abbreviated for conciseness]:

The 6510 input/output port appears at location 1. The data direction register for this port appears at location 0. ... the data direction controls whether a given bit will be an input or output, and the actual data transfer occurs through the port itself.

NAME	BIT	DIRECTION	DESCRIPTION
LORAM	0	OUTPUT	Control for RAM/ROM at $A000-$BFFF (BASIC)
HIRAM	1	OUTPUT	Control for RAM/ROM at $E000-$FFFF (KERNAL)
CHAREN	2	OUTPUT	Control for I/O/ROM at $D000-$DFFF
	3	OUTPUT	Casette write line
	4	INPUT	Casette switch sense
	5	OUTPUT	Casette motor control

The most up-to-date reference I found was this:

https://github.com/MassiveBattlebotsFan/mega65-core/blob/3492834b59db3f0d68927831182742ceb9ad6b7b/iomap.txt#L3

And dddaaannn mentioned "force_fast" in gs4510.vhdl.

[dansanderson]

I agree that the first six bits should appear in a table in our docs, and that the magic poke behavior should also be explained if we're going to keep it.

One wrinkle is that the magic pokes really are magic: POKE 0,65 does not result in PEEK(0) returning 65, nor does it set the directionality of any I/O registers. The 45GS02 CPU notices the attempt to write that value to that address, intercepts it, and sets an internal force_fast flag that cannot be read by a program. So it's not a behavior of a register bit, it's a behavior of the CPU. This behavior would not be a row in a table of register bits.

[binarycrusader]

dddaaannn shared this vhdl link that shows how this is actually implemented:
https://github.com/MEGA65/mega65-core/blob/11e45cb476bae3e89ff1b3ba52f24b958d761e21/src/vhdl/gs4510.vhdl#L3304