markusC64
commented
2 years ago Some ideas to detect 2 MHz Mode on C128:
- After a reset, observe address bus. It should tell you if the rest vector at $FFFC/d is accessed first (C64) or the Z80 takes control (other reset vector). If C64: No 2 MHz.
- If a write access in VIC cycle occured => 2 MHz mode. VIC does not write.
- Two or three byte commands (opcodes with 1 or 2 byte paramter) should result in read access to consecutive bytes. So if you observe those in normal and vic cycle interleaved, then this is an indication for the 2 MHz mode. If you obserbved that fairly often, then it's probably better to assume 2 MHz than 1 Mhz.
- (Just an idea that has not been worked out) Use the fact that absolute adressing (and other) first have an adress in the data bus (fetching instruction, lo, hi) and then on the adddress bus. Assume 2 MHz and see if you hit this pattern. Then you might guess 2 MHz.
- Otherwise 1 Mhz.
Should test if those ideas give the information about 1 or 2 MHz mode with reasonable probability.
BTW: If you need FPGA space, consider a C128 specific firmware version. Kernal replacement can the thrown away on a C128 specific firmware - it does not work anyway on a C128.
On Fri, Feb 16, 2018 at 11:14 AM, I wrote:
I thing your analysis from My 21th, 2017 is right:
As described in the document, there are three ways to freeze the CPU, of which the safest is to wait for a bad line and then just set the DMA line and wait for BA to become high. This way, the bad line was correctly started by the VIC, and we just extend it indefinitely.
I must admit that I do not know what exactly happens in 2 MHz mode. Obviously, the VIC fetches are given a lower priority. I'd say that the bad lines do not occur anymore at all, but I haven't done measurements to confirm this.
If bad lines don't occur, the Ultimate hardware will wait for the next most feasible solution, which is waiting for three writes in a row; which happens when an interrupt occurs. However, in 2 MHz mode, these three writes do not happen in three consecutive cycles, but they appear at three consecutive HALF-cycles, so the Ultimate won't recognize this.
Most likely, the Ultimate will fall back to the third, unsafe option: just assert DMA and accept the chance of losing a write cycle from the CPU. This may indeed lead to random crashes. It MAY even be so that this method incorrectly breaks a read cycle, because 2 MHz timing is not considered. When a read fails, you know what will happen: upon continue, any opcode / operand might be corrupt, your program might crash right there and then.