1541ultimate icon indicating copy to clipboard operation
1541ultimate copied to clipboard

Crash in 2Mhz mode on C128 when running an EasyFlash crt image

Open JackAsser1337 opened this issue 3 years ago • 21 comments

When using a 1541U2+ device on a real C128 with an attached EasyFlash image, things will crash if you enable 2Mhz mode on the C128.

JackAsser1337 avatar Sep 05 '22 09:09 JackAsser1337

Duplicate of https://github.com/GideonZ/1541ultimate/issues/39

markusC64 avatar Sep 05 '22 15:09 markusC64

Duplicate of #39

No, that is about a 2mhz issue with something extremely specific in that geos boot rom, which is a C128 function rom, and does get serve_vic enabled. Something else is going wrong with that one.

This report is about a C64 cartridge, and the fact that serve_vic = 0 for c64 cartridges, which means the cartridge reads will fail for cycles which overlap with what normally would be the vic2 'phase'.

bvl1999 avatar Sep 05 '22 15:09 bvl1999

When using a 1541U2+ device on a real C128 with an attached EasyFlash image, things will crash if you enable 2Mhz mode on the C128.

This is related to ezflash (original hardware, not modern variations) not supporting that either. But most modern variations do support this, so.. its a bit of a bummer this doesn't work.

The workaround is changing a default in the firmware (serve_vic=1) but, that is not entirely according to spec. Ideally, one could en/disable this from the ui, or maybe auto detect a c128 and enable on c128 only.

As EotB isn't the only game doing this (Prince of Persia, ezf version of SMB64, to name 2 other examples), it would be nice if this got a more permanent solution than a quick firmware hack.

bvl1999 avatar Sep 05 '22 15:09 bvl1999

Ok, that can be done, but just enabling serve_vic would not help because of the other bug.

markusC64 avatar Sep 05 '22 15:09 markusC64

Ok, that can be done, but just enabling serve_vic would not help because of the other bug.

Yes it totally helps. Tested with a bunch of ezflash crts which use 2mhz mode.

Your geos boot rom does something special, it is the exception, not the rule.

I run function roms in 2mhz mode for many hours a day on a c128, it works, stop trying to say it doesn't because you have one broken example.

bvl1999 avatar Sep 05 '22 15:09 bvl1999

Your geos boot rom does something special, it is the exception, not the rule.

No. It just copies very much data from external cartridge bank to bank 1 (or 0?) With the observation noted. If you read much less data, you might get more time before the misread occurs.

Anyway, one bug at a time. Enabling service_vic would allow testing that.

BTW: Freezing in 2 MHz mode (with the button) is also broken... 2 MHz is therefore poorly supported.

markusC64 avatar Sep 05 '22 16:09 markusC64

I run function roms in 2mhz mode for many hours a day on a c128, it works, stop trying to say it doesn't because you have one broken example.

Okay, different C128 might have different timing. Well, they have - due to different phi values needed that is obvious.

markusC64 avatar Sep 05 '22 16:09 markusC64

We discussed freezing in 2 MHz mode many times, and it is not possible to do a solid freeze without knowing whether the CPU runs in 2 MHz mode or 1 MHz mode.. At least not in the way the freezer works currently.

The only other option is to freeze in a read cycle, during the read cycle itself (late DMA, while PHI2 is high). I have seen this fail on some machines when I started the Ultimate project ~14 years ago. There is a chance that I was wrong back then and maybe it's worthwhile to use this method as an option. It would make freezing a whole lot easier if i was wrong; just jank the DMA line whenever you're in a read cycle; no extension of bad lines or assumptions about the order of read and write cycles.

GideonZ avatar Sep 05 '22 16:09 GideonZ

When doing the U2+L, where I had to re-invent the timing on the cartridge bus basically, I ran into the peculiarity that the PHI2 offset is different for the PHI2=1 and the PHI2=0 case. In fact, for the PHI2=0 case it is fixed to quite a high delay; the setting there does not have any effect. I think with some proper analysis, this setting shouldn't even need to exist.

On Mon, Sep 5, 2022 at 6:01 PM markusC64 @.***> wrote:

I run function roms in 2mhz mode for many hours a day on a c128, it works, stop trying to say it doesn't because you have one broken example.

Okay, different C128 might have different timing. Well, they have - due to different phi values needed that is obvious.

— Reply to this email directly, view it on GitHub https://github.com/GideonZ/1541ultimate/issues/279#issuecomment-1237251220, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACUFDSOEKPSQWYMPOLJ6SF3V4YKONANCNFSM6AAAAAAQEZAIMI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

GideonZ avatar Sep 05 '22 16:09 GideonZ

I run function roms in 2mhz mode for many hours a day on a c128, it works, stop trying to say it doesn't because you have one broken example.

Okay, different C128 might have different timing. Well, they have - due to different phi values needed that is obvious.

Yes, taken care of.

Look, there are some 700+ people using my device manager with an UII+ and C128. That runs code in 2mhz mode. That is on a very wide variety of C128s, and yes, they need slightly different phi2 settings at times. That is actually testable (which my device manager does at startup, and warns about if the setting does not match the hardware).

I've had 3.10c firmware with serve_vic=1 as default which is being used by dozens of people, it lets them run the mentioned easyflash crts with 'turbo mode' enabled.

So lets just stop conflating EVERY report about 2mhz mode with this same exception, and instead figure out why that geos boot rom fails while pretty much everything else works. There must be an underlying issue knowing it does work in 1mhz mode, but it is not a reason to polute every other bug report, so please stop that.

bvl1999 avatar Sep 05 '22 16:09 bvl1999

Ideally, one could en/disable this from the ui, or maybe auto detect a c128 and enable on c128 only.

Ideally a cartridge subtype in the .crt would enable this. But as .crt requiring this are already published, this is not necessarly the most user friendly option.

markusC64 avatar Sep 05 '22 16:09 markusC64

When doing the U2+L, where I had to re-invent the timing on the cartridge bus basically, I ran into the peculiarity that the PHI2 offset is different for the PHI2=1 and the PHI2=0 case. In fact, for the PHI2=0 case it is fixed to quite a high delay; the setting there does not have any effect. I think with some proper analysis, this setting shouldn't even need to exist.

Interesting, it would be nice if you can get rid of those settings entirely. I guess we'll know soon enough!

But back to the original issue, the problem is there being a number of CRTs out there which will enable 2mhz mode when detecting a C128.

This used to be really the exception, but it is a popular thing to do in most modern games which would benefit from this, and it is supported by modern ezflash compatible hardware (tho not by the original easyflash cartridge).

Good possibilities would be to override serve_vic for ezflash and related crt types or maybe even change the default when running on a C128, or to make it user configurable.

bvl1999 avatar Sep 05 '22 16:09 bvl1999

Ideally, one could en/disable this from the ui, or maybe auto detect a c128 and enable on c128 only.

Ideally a cartridge subtype in the .crt would enable this. But as .crt requiring this are already published, this is not necessarly the most user friendly option.

That would be really nice indeed. But I believe it is safe to assume enabling serve_vic for all easyflash crts will work, and not hurt those which don't need it.

I only have tested a couple dozen random crt files of various types with serve_vic defaulting to 1, and have yet to find one which doesn't work, but that isn't really good enough to say enabling it for every crt type will be fine. However, the kff cartridge for example does serve both phases, and so does current easyflash 3 hardware, so... I guess it is fair to assume this works with all the easyflash crts even if the original didn't support this.

bvl1999 avatar Sep 05 '22 19:09 bvl1999

Will not claim that I know anything about hardware, but my EasyFlash 1 clones using either modern discreet logic or CPLD-logic (ATF1502) works just fine in 2 Mhz mode. Maybe I'm just lucky?

JackAsser1337 avatar Sep 05 '22 20:09 JackAsser1337

Completely unrelated. The U2+ uses (DDR2) RAM to store the ROM content, and this RAM is also used by the application CPU, the disk drive RAM/ROM, the REU, and basically everything else you can think of. The access to the RAM is time shared, and to get the right byte on the bus (on time), the cartridge logic needs to decide which cycles to 'serve'. If the cycle is not served, or too late, the CPU in the C64/C128 will crash.

Message ID: @.***>

GideonZ avatar Sep 05 '22 20:09 GideonZ

Will not claim that I know anything about hardware, but my EasyFlash 1 clones using either modern discreet logic or CPLD-logic (ATF1502) works just fine in 2 Mhz mode. Maybe I'm just lucky?

I bet it does, both should be fast enough.

And I think the UII(+) should do the same for easyflash crts.

bvl1999 avatar Sep 05 '22 21:09 bvl1999

Hmm.. not sure if serving VIC cycles is enabled for EasyFlash.

Message ID: @.***>

GideonZ avatar Oct 11 '22 07:10 GideonZ

Hmm.. not sure if serving VIC cycles is enabled for EasyFlash.

There seems to be no override for serve_vic for easyflash, so it uses whatever the default is (0). Which does seem somewhat odd, as from what I remember, it can use ultimax mode.

bvl1999 avatar Oct 11 '22 16:10 bvl1999

EF always boot in Ultimax so yeah… and ultimax is needed to even program the cart from the c64-side (write cycles wouldn’t reach the flash ROM otherwise).

11 okt. 2022 kl. 18:08 skrev Bart van Leeuwen @.***>:

 Hmm.. not sure if serving VIC cycles is enabled for EasyFlash.

There seems to be no override for serve_vic for easyflash, so it uses whatever the default is (0). Which does seem somewhat odd, as from what I remember, it can use ultimax mode.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

JackAsser1337 avatar Oct 11 '22 19:10 JackAsser1337

EF always boot in Ultimax so yeah… and ultimax is needed to even program the cart from the c64-side (write cycles wouldn’t reach the flash ROM otherwise).

serve_vic determines if a cartridge should also serve the 'phi2=0' half of a cycle, which only happens in 2 situations:

  • ultimax mode and vic2 reads display data from cartridge rom
  • c128 in 2mhz mode

In all other situations, vic2 will read internal ram or character rom during its half of the clock cycle. (well, there is a corner case with the UII+ with kernal replacement where vic2 reads from ram in the UII+, but that is handled separately)

As programming ef always happens during the cpu half of a clock cycle (phi2=1), having serve_vic set to 0 wouldn't be a problem for that, but it would when a cartridge would for example use cartridge rom based sprites for a logo like the kcs power cartridge, and essentially for any freezer mode which has vic2 read cartridge rom for displaying menus, and of course with a real ef, for playing games from an ultimax crt image.

The UII+ will enable serve_vic for ultimax cartridges, but at least in the current firmware it doesn't do this for the ef cartridge.

I believe you have a copy of the slightly modified 3.10c firmware with the default for serve_vic changed to 1. Did you test if this works for eye of the beholder?

bvl1999 avatar Oct 11 '22 21:10 bvl1999

any news here?

leissa avatar Jun 12 '23 12:06 leissa