A few modern C64 carts not detected as C64 carts by core selector

[dansanderson]

Test Environment (required)
You can use MEGA65INFO to retrieve this.

• Platform: MEGA65 R5
• Core Commit: slot 0: 0828173 "Looping RC#67.4 test"

Describe the bug
Several modern ProtoVision carts intended for the C64 appear to the core selector as non-C64 carts. With a MEGA65 core flagged for M65 carts and the C64 core flagged for C64 carts, the ProtoVision carts are starting the MEGA65 core (and mostly not working with GO64 mode, but that's not the bug).

This is consistent across TM Ultra and Soul Force, both from ProtoVision, as well as l'Abbage de Morts on cartridge. These games all work with the C64 core if I select the core manually from the core select menu.

To Reproduce

1. Install MEGA65 and C64 cores, with a modern cartflash-derived 0.96 test core in slot 0.
2. Connect a ProtoVision Soul Force cart.
3. Power on.

Expected: C64 core starts, cart plays. Can confirm C64 core with Help key.

Actual: MEGA65 core starts, cart fumbles in GO64 mode. Can confirm MEGA65 core by entering the Freezer.

Additional context
Not a regression and not a v0.96 launch blocker, just noting for future reference. The easy workaround is to use the core selection menu to choose the C64 core, as in v0.95.

[paich64]

Exact same issue / symptoms / workaround with the following modern cartridge games :

• Tiny Quest
• Robot Jet Action

[lydon42]

Not a MEGAFLASH issue, this most probably is #778

[gardners]

Can any of these failing carts be simulated using an Easy Flash 3? Otherwise I don't have them on hand to test. My gut feeling is that they might be external KERNAL based cartridges, which requires some skull-duggery to handle on the current R3-R6 hadware.

The fix for #778 requires testing by someone with one of the failing cartridges, to see if it fixes the problem with this issue.

[paich64]

@gardners they were detected correctly with R3A batch 2 configurations (Mega65 core, rom, C64 core). I mean on R3A, 0.95, Former autoboot feature and a C64 core handling physical cartridges, these 3 cartridges were correctly autobooting with C64 core.

[paich64]

The issue does not seem to be 100% fixed :

R5 status with MegaFlash build v71 and c64 V5.1RC1

Soulforce => now boots as expected with the C64 core

Robot Jet Action => now boots as expected with the C64 core

Tiny Quest => is not recognized as a C64 cartridge yet (the mega65 core starts in "GO64" mode)

R3A status with MegaFlash build v71 and c64 V5.1RC1

Soulforce => boots as expected with the C64 core

Robot Jet Action => detected as a C64 cartridge but the C64 core won't boot it : The c64 core starts but does not boot the cartridge

Tiny Quest => detected as a C64 cartridge but the C64 core won't boot it : The c64 core starts but does not boot the cartridge

[gardners]

Tiny Quest seems to have a ROM with boot signature at $8000, but nothing visible at $A000 or $E000 by default, and pulls /EXROM low, and leaves /GAME high.

According to https://www.c64-wiki.com/wiki/Bank_Switching, this should have KERNAL mapped and cart ROM at $8000.

Single-stepping through, the cart gets detected, and C64 ROM starts, and does JMP ($8000). At some point it ends up with no ROMs at all mapped, and executing BRK instructions.

Gets to $802E.

Draws "have a nice day" message on screen.

Gets to $8031

Gets to $8043, which then jumps to $0100, which seems to have a little routine in it:

That routine appears to copy banks of ROM from the cartridge to RAM, and then jump to $080D to start the program:

,00000100  A9 00     LDA   #$00
,00000102  85 FC     STA   $FC
,00000104  A9 83     LDA   #$83
,00000106  85 FD     STA   $FD
,00000108  A9 01     LDA   #$01
,0000010A  85 FE     STA   $FE
,0000010C  A9 08     LDA   #$08
,0000010E  85 FF     STA   $FF
,00000110  A9 00     LDA   #$00
,00000112  85 FB     STA   $FB
,00000114  8D 00 DE  STA   $DE00
,00000117  A2 77     LDX   #$77
,00000119  A0 00     LDY   #$00
,0000011B  B1 FC     LDA   ($FC),Y
,0000011D  91 FE     STA   ($FE),Y
,0000011F  C8        INY   
,00000120  D0 F9     BNE   $011B
,00000122  E6 FD     INC   $FD
,00000124  E6 FF     INC   $FF
,00000126  A5 FD     LDA   $FD
,00000128  C9 A0     CMP   #$A0
,0000012A  D0 0B     BNE   $0137
,0000012C  E6 FB     INC   $FB
,0000012E  A5 FB     LDA   $FB
,00000130  8D 00 DE  STA   $DE00
,00000133  A9 80     LDA   #$80
,00000135  85 FD     STA   $FD
,00000137  CA        DEX   
,00000138  D0 E1     BNE   $011B
,0000013A  78        SEI   
,0000013B  A9 08     LDA   #$08
,0000013D  8D 00 DE  STA   $DE00
,00000140  A2 FF     LDX   #$FF
,00000142  9A        TXS   
,00000143  A9 00     LDA   #$00
,00000145  AA        TAX   
,00000146  A8        TAY   
,00000147  A9 37     LDA   #$37
,00000149  85 01     STA   $01
,0000014B  4C 0D 08  JMP   $080D

[gardners]

Writing to $DE00 doesn't cause the ROM bank to change. This is the likely cause of the issue.

This is with a 20231223 bitstream, which doesn't have the fix to F_CTRL_EN.

Try again with a more recent bitstream, same issue.

Time to connect cartridge port break-out board, and see if /IO1 strobes.

[gardners]

No sign of strobe of /IO1 or /IO2 on writes to $DE00 or $DF00.

This would seem to suggest either F_CTRL_EN or F_CTRL_DIR are not being set correctly.

The IC used is a https://www.ti.com/lit/ds/symlink/sn74lvch16t245.pdf

It looks superficially as though it is connected properly, and that we are driving it correctly. Will need to probe further to investigate.

If someone could probe pins 1 and 48 of U8 while doing POKE $FFD0E00,0 from BASIC65 that would be helpful. I'll otherwise do it when I can.

[MJoergen]

@paich64

R3A status with MegaFlash build v71 and c64 V5.1RC1

Soulforce => boots as expected with the C64 core

Robot Jet Action => detected as a C64 cartridge but the C64 core won't boot it : The c64 core starts but does not boot the cartridge

Tiny Quest => detected as a C64 cartridge but the C64 core won't boot it : The c64 core starts but does not boot the cartridge

Regarding the R3A status, what is the status using the previously released C64 V5 core? I'm interested in knowing whether or not this is a regression from V5 to V5.1.

[paich64]

@MJoergen
there's definitely no regression with V5.1

• Tiny quest is now at @gardners home
• I still have Robot Jet Action so i could extensively test :

Using Latest MegaFlash core in slot 0 on R3A with V5.1 in slot 2=> Robot Jet Action won't start
Using Latest MegaFlash core in slot 0 on R3A with V5.0 in slot 2=> Robot Jet Action won't start

I even Reflashed very first MegaFlash core in slot 0 (the one which was delivered when autoboot cartridge was implemented) and V5.0 in slot2 => Robot Jet Action won't start

I know the pattern is hard to capture but please,

1. remember my R3A used to be able to autoboot both "Robot Jet Action" and "Tiny Quest" with very first MegaFlash core using V5.0 alpha releases, and overtime it started to stop being able to autoboot these 2 cartridges and also EF1 cartridges.

2. remember that on R3A they have always been recognized as C64 cartridges but they fail to boot.

combining 1) + 2) It's obvious to me that on R3A, there's no regression, simply my very own Mega65 R3A has problems with the cartridge port. It's not the C64 core, it's my R3A board which fails for an unknown reason.

Again, it used to be able to boot these 2 cartridges using V5.0 alpha releases and i'm pretty sure it could also boot these 2 cartridges with V5.0.

In order to ensure it's not related to the core, I have re-tested all V5.0 Alpha releases (since the very first one) and none of them will let me boot these 2 cartridges, while i had been able to boot them by the past.

So I confirm : V5.0 is OK, V5.1 is OK.
It's all related to my very own R3A board.

A few month ago a friend of mine has tested these cartridges on his on R3A and he could boot them with V5.0 while i could not with V5.0.

[paich64]

@MJoergen when i get my second Mega65 (in June obviously) I hope you or @sy2002 will have some time to investigate what's wrong with my R3A. I know you'll be very busy with possible an Amiga Core, but if you can find time to debug the cartridge port of my R3A i will be more than happy to ship it to you or @sy2002. Maybe you can find out what's wrong by comparing it with your own R3/R3A.

[sy2002]

@gardners Paul, you wrote this here in your above-mentioned comment:

Tiny Quest seems to have a ROM with boot signature at $8000

Since we are talking about detecting a cartridge as C64 cartridge and start the dedicated C64 core (and not about "why is it not running on the MEGA65 core"): Can't we consider a cartridge as C64 cartridge as soon as you detected the boot signature at $8000?

You also wrote:

but nothing visible at $A000 or $E000 by default, and pulls /EXROM low, and leaves /GAME high.

According to this blog http://blog.worldofjani.com/?p=879 EXROM low and GAME high means we have an 8k cartridge and you can only expect data in $8000 and not in $A000 or $E000.

So I am wondering: If we already detect a CBM80 signature in $8000, what hinders us to classify this cartridge as "C64 cartridge" and start the C64 core?

@lydon42 What are the conditions in your code to decide if a cartridge is a C64 cartridge? I faintly remember having had a discusson with you about only taking the CBM80 signature months ago, but I might mis-remember...

[lydon42]

Talking about this here?

mega65-core/src/utilities/megaflash.c

Line 147 in e98485b

// there might be C64 cartridges that do some "magic", so we can't depend on

[gardners]

For me at least, some of the time it does seem to be detected as a C64 cart, but fails to start completely in M65 core at least (I don't have a C64 core configured to boot on my machine right now).

But I have seen both black screen, and partial-start screen of Tiny Quest (looks like C64 start screen with some extra messages).

[paich64]

@gardners this is what's supposed to happen on screen when Tiny Quest cartridge is booting :

TinyQuest_Startup.mp4

[lydon42]

MEGAFLASH can show you what it detects. If you interrupt autoboot by holding NO SCROLL, and then press HELP for the version info, the "secret" F1 key shows you extra boot information (i.e. the state of EXROM/GAME at the very start of MEGAFLASH, it's current state, and what ROM memory shows at the location that hold CBM80, cbm or m65)

[sy2002]

@gardners Can you do the test that @lydon42 describes 10 times in a row or so and share the result?

We need to understand, if and why the core selector fails to detect this as a C64 cart (and start the C64 core). To my knowledge, @paich64 reported that Tiny Quest is NEVER detected as C64 cart, which would contradict your observation and therefore I think doing the test 10 times provides more clarity and might even inspire where to debug further.

@lydon42 Am I interpreting the code snipped you shared correctly, that as soon as you detect CBM80 at $8000 the cart is detected as C64 cart? (Which would be great and would mean that sometimes - or always - you are not "seeing" CBM80 at $8000 when Tiny Quest is inserted.)

I would like to remind everybody that on R3/R3A boards Tiny Quest is detected reliably and flawlessly.

[lydon42]

Yes, it was decided that if there is CBM80 at $8004, regardless of the state of EXROM/GAME, a C64 cartridge is assumed.

I don't have that cartridge, so I can't tell you how it detects.

[lydon42]

Copied from discord for documentation (posted by AmokPhaze101):

on R5 with 683-cartflash #71:

on R3A with 683-cartflash #71:

R5 shows ROM area all zero and EXROM/GAME high ($60 in D67E), R3A shows some marker bytes at $8004 (but it's CBM00 not 80!), and EXROM low ($20 in D67E)

[gardners]

Powering on with Tiny Quest in R5 board (unpatched) 10x gives the same partial-boot 10x. This is on 20231212.19 / c6fb6d6 (r5-bringup) branch, because that's what I have flashed right now.

This is with the cartridge port break-out board fitted, which might affect some timing.

Without the break-out board: 3x boot to BASIC65, 7x same partial-boot progress. Again, with c6fb6d6.

I'll have time a bit later to flash a newer bitstream.

Will try with head of 781-c64-carts via JTAG next, however.

[gardners]

The above commits get all simulation-based tests passing, but Tiny Quest is still refusing to work. I did reduce the hold time for writes from ~120 to ~60 ns. Will try increasing it back.

[gardners]

No change. All reads return $00, which strikes me as suspicious. I'm thinking that I have messed up something with the data direction / enable stuff, or general plumbing of the input vs output versions of the cartridge port data lines.

[gardners]

Yes, there is something fruity going on: Writing $01 to $401DE00 causes all successive reads to read back as $01.

[sy2002]

@paich64 @lydon42 @gardners Gentlemen, as I plan to release the C64 V5.1 core that will support R6 boards very soon (my current ETA is Friday, June 28th), it looks like I need to add something to the core's FAQ, right?

@paich64 can you confirm that 2024 users of the MEGA65 will still run into this problem here:

"A few modern C64 carts are not detected as C64 carts by core selector" (scroll up here in this issue for details)

While users of older machines (or older CORE #0) will not have this probem, right?

I need to figure out what will I document in the FAQ, i.e. is there a planned fix up and coming, or is there even a better CORE #0 available, etc.

This is clearly a regression where new users have a worse experience than old users, so proper documentation is important here.

[gardners]

The complication here is that the cartridge port is more compatible, but that the detection of cartridges has suffered some regressions, that we hope will get resolved in a future core update. In the meantime, the workaround is to start the C64 core manually.

Something like that?

[sy2002]

@gardners @lydon42 I like this. And since I will probably not touch the C64 core and documentation for quite a while after the release (probably for more than a year from now on): Can I in my FAQ point to some documentation / Wiki / something that people can have a look at in future, how to upgrade CORE #0 etc. Is there a Wiki page or an Article on Filehost or something? In worst case, I could add a pointer to this issue to my documentation and tell them to search Discord, etc.

FYI: This is how the FAQ looks like: https://github.com/MJoergen/C64MEGA65/blob/V5.1-release/FAQ.md

[paich64]

@sy2002 ***@***.***> to me the R6 cartridge port is running even better than on R5 as far as i can tell. All my real cartridges are working perfectly with R6 (including EasyFlash, EasyFlash 3, KungFu Flash). I even have 2 custom made cartridges which would not start on R5 and that are running perfectly on R6. So to me, I consider the R6 as better compared to R5. Now of course it's only based on my very own game cartridges. Olivier. Le sam. 22 juin 2024 à 13:06, sy2002 ***@***.***> a écrit :

…

@paich64 <https://github.com/paich64> @lydon42 <https://github.com/lydon42> @gardners <https://github.com/gardners> Gentlemen, as I plan to release the C64 V5.1 core that will support R6 boards very soon (my current ETA is Friday, June 28th), it looks like I need to add something to the core's FAQ, right? @paich64 <https://github.com/paich64> can you confirm that 2024 users of the MEGA65 will still run into this problem here: "A few modern C64 carts are not detected as C64 carts by core selector" While users of older machines (or older CORE #0) will not have this probem, right? I need to figure out what will I document in the FAQ, i.e. is there a planned fix up and coming, or is there even a better CORE #0 available, etc. This is clearly a regression where new users have a worse experience than old users, so proper documentation is important here. — Reply to this email directly, view it on GitHub <#781 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABROXOC2DACTK7F6HCWQM6TZIVLEHAVCNFSM6AAAAABCN4BNS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBTHE4DCNZSHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[paich64]

Let me clarify : I really mean that not only all my cartridges now run on R6 but also, the Mega65 detects all of them and autoboots the C64 core. But again I only have 12 game cartridges. But all in all to me, R6 > R5 >> R3A when it comes to auto booting C64 cartridges and being able to run C64 Cartridges with the C64 core. Le sam. 22 juin 2024 à 16:08, olivier bernhard ***@***.***> a écrit :

…

@sy2002 ***@***.***> to me the R6 cartridge port is running even better than on R5 as far as i can tell. All my real cartridges are working perfectly with R6 (including EasyFlash, EasyFlash 3, KungFu Flash). I even have 2 custom made cartridges which would not start on R5 and that are running perfectly on R6. So to me, I consider the R6 as better compared to R5. Now of course it's only based on my very own game cartridges. Olivier. Le sam. 22 juin 2024 à 13:06, sy2002 ***@***.***> a écrit : > @paich64 <https://github.com/paich64> @lydon42 > <https://github.com/lydon42> @gardners <https://github.com/gardners> > Gentlemen, as I plan to release the C64 V5.1 core that will support R6 > boards very soon (my current ETA is Friday, June 28th), it looks like I > need to add something to the core's FAQ, right? > > @paich64 <https://github.com/paich64> can you confirm that 2024 users of > the MEGA65 will still run into this problem here: > > "A few modern C64 carts are not detected as C64 carts by core selector" > > While users of older machines (or older CORE #0) will not have this > probem, right? > > I need to figure out what will I document in the FAQ, i.e. is there a > planned fix up and coming, or is there even a better CORE #0 available, etc. > > This is clearly a regression where new users have a worse experience than > old users, so proper documentation is important here. > > — > Reply to this email directly, view it on GitHub > <#781 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABROXOC2DACTK7F6HCWQM6TZIVLEHAVCNFSM6AAAAABCN4BNS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBTHE4DCNZSHA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[lydon42]

https://mega65.atlassian.net/l/cp/KT0gV88D

[dansanderson]

We believe this is working well enough to resolve the issue. Thanks for the hard work getting this completed!