Is your feature request related to a problem? Please describe.
Sometimes there is need to query the actual I/O mode without any prior knowledge on that. Last time I saw this when someone wanted to write a debugger/monitor (sorry, I can't remember exactly), and wanted to display/get to know the actual I/O mode. Or maybe the same scenario but setting some MEGA65 specific thing: thus, the monitor/debugger must set MEGA65 I/O mode, do its thing, then restore the original I/O mode (so that should be queried before).
Similar but less serious issue: query the actual CPU speed. This one can be done, but very expensive, collecting "C128 fast", "C65 fast" and "MEGA65 fast" bits of various registers, and decode their meaning on certain combinations. Also the "speed gate" (the POKE 0,64 and 65) is something I am not even aware if can be queried at all (a program may want to know the actual speed set, even if it's overridden by the speed gate).
Describe the solution you'd like
For the first one: it's hard to find an I/O register which is available in all I/O modes. However we have one: $D02F the key register. Now, for sure, the behaviour of that register for writing shouldn't be bothered! However I mean about its meaning on reading. I am not sure, if it's a problem to change the read behaviour of the key register though. My idea is something like this:
of course, system's behaviour on writing $D02F shouldn't change!
reading $D02F though can return useful information which is available this way in all I/O modes without problem
read value:
bits 1-0: actual I/O mode, ie, C64, C65, MEGA65, MEGA65/Ethernet
bits 3-2: actual CPU speed set (thought this is maybe overridden currently by the speed gate!), ie: C64(1MHz), C128 fast (2MHz), C65 (3.5MHz), MEGA65 (40.5MHz)
Is your feature request related to a problem? Please describe.
Sometimes there is need to query the actual I/O mode without any prior knowledge on that. Last time I saw this when someone wanted to write a debugger/monitor (sorry, I can't remember exactly), and wanted to display/get to know the actual I/O mode. Or maybe the same scenario but setting some MEGA65 specific thing: thus, the monitor/debugger must set MEGA65 I/O mode, do its thing, then restore the original I/O mode (so that should be queried before).
Similar but less serious issue: query the actual CPU speed. This one can be done, but very expensive, collecting "C128 fast", "C65 fast" and "MEGA65 fast" bits of various registers, and decode their meaning on certain combinations. Also the "speed gate" (the POKE 0,64 and 65) is something I am not even aware if can be queried at all (a program may want to know the actual speed set, even if it's overridden by the speed gate).
Describe the solution you'd like
For the first one: it's hard to find an I/O register which is available in all I/O modes. However we have one:
$D02Fthe key register. Now, for sure, the behaviour of that register for writing shouldn't be bothered! However I mean about its meaning on reading. I am not sure, if it's a problem to change the read behaviour of the key register though. My idea is something like this:$D02Fshouldn't change!$D02Fthough can return useful information which is available this way in all I/O modes without problemDescribe alternatives you've considered
Going to the corner of my room, and crying. :)