CPU Speed NOT updating, when using ETHERLOAD.

[drex69]

Describe the bug When you try to enable another CPU speed, other than 40mhz, in your program, and then use ETHERLOAD to push your program through to the Mega65, the CPU speed still stays at 40mhz, and the Freezer confirms this.

To Reproduce Try enabling, different CPU speeds via the, $D054 & $D031 registers. Then send your .prg file to the Mega65 using ETHERLOAD. (etherload -r name.prg)

Expected behaviour The chosen CPU speed in your program, should be reflected on the Mega65, and in the Freezer, when using ETHERLOAD.

Findings If you want to use different CPU speeds when sending programs via ETHERLOAD, then you need to, Poke0,64. (thanks, lgblgblgb)

[lgblgblgb]

Is it possible that the speed gate overrides things (the POKE 0,65 thingy) used by etherload or something like that?

[drex69]

Ahhhhh.......

You are right, if you want to use the the $D031 & $D054 registers to control the CPU speed, then you need to Poke 0,64.

When I load a program via the sd-card on the Mega65, or I launch my program using Xemu, then this poke is NOT needed, not sure why ?

But when sending the .prg via ETHERLOAD, then this poke is needed.

[lgblgblgb]

Not sure, maybe etherload sets the speed gate as its own and does not turn it off. Which can be a problem if it's really that ...

Usually in my programs I always store value 64 to 0 just to be safe if I really want to set other speed. I guess most ppl won't catch bugs like this otherwise since 99% time we anyway want 40.5MHz clock.

Thus my gut feeling makes me said this: etherload probably sets the speed gate (so enough speed for smoothly receiving things via ethernet, which is fine), but forgets to reset it then?

[drex69]

From what you have said, that makes sense.

I will put this at the start of all my programs, from now on, as well.

Not sure, how well documented this Poke is though, so people know about it.

I will leave this issue OPEN, as I think, it still qualifies as a bug.

[lgblgblgb]

I would say: it should be left open till someone who is more familiar (an actual developer of it) with ethertool's internal says more on the topic. What I do here is more like an "educated guess" only.

[ki-bo]

Indeed, I can confirm the ETHLOAD.M65 is setting the force_fast state in the CPU, which needs to be disabled before any other speed setting can be active. I will make sure the exit routines of etherload all disable that flag again to better resemble a reset machine state.

On the other hand, programs relying on a specific CPU speed should make sure they write all registers affecting the resulting CPU speed, including POKE0,64 in case speed should be < 40MHz.

[ki-bo]

@drex69 Should be fixed in latest development HEAD, please re-test

[drex69]

Just tested, and can confirm, that it is working correctly.

Thanks Ki-bo.