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

• Tiny Quest
• Robot Jet Action

from mega65-core.

Not a MEGAFLASH issue, this most probably is #778

from mega65-core.

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.

from mega65-core.

@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.

from mega65-core.

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

from mega65-core.

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

from mega65-core.

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.

from mega65-core.

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.

from mega65-core.

@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.

from mega65-core.

@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.

from mega65-core.

@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.

from mega65-core.

@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...

from mega65-core.

Talking about this here?

from mega65-core.

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).

from mega65-core.

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

from mega65-core.

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)

from mega65-core.

@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.

from mega65-core.

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.

from mega65-core.

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)

from mega65-core.

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.

from mega65-core.

I'm not convinced that we have been controlling cart_ctrl_dir correctly. Will test if the above fix allows things to work correctly.

from mega65-core.

@gardners Sounds promising, Paul! Thank you.

Just for clarity: Works correct = C64 core is started (or at least C64 cartridge is detected). The game itself will not play, neither on the MEGA65 core nor on the C64 core, but this does not matter. What matters is, that the cartridge detection works.

from mega65-core.

oh, ok. TinyQuest doesn't work on C64 core? Do you know why not?
I'll focus on stabilising the behaviour of the cartridge detection, then.

from mega65-core.

Hmmm.. not entirely sure how the cartridge clock was being generated before. In simulation at least, it was simply not ticking.
Argh! 781-c64-carts seems to be based on some weird branch history. It is quite similar to development, but not merged. I'll have to re-base it.
This doesn't clear up the mystery of how on earth DOTCLOCK was ticking on real hardware, however.

from mega65-core.

ok, that's weird: Fixing the dotclock to work under simulation has it not ticking in hardware. Ah: It was expecting it in MHz, not Hz. Making consistent in Hz, as elsewhere.

from mega65-core.

MEGA65 R1 cartridge support has been purged as it complicates things a fair bit, and is realistically no longer required on this reasoning from me:

I don't like deprecating old targets, but I also don't see that the 3 R1 boards produced are likely to be used with carts, due to: (1) their fragility (SD card is via blue-wire, for example); (2) 1 of 3 boards is locked in my cupboard; (3) the other 2 are also unlikely to be updated to recent releases due to their primary value being historical.

from mega65-core.

/IO1 and /IO2 activate under simulation, but not on real hardware. Suspect still an issue with driving the buffer IC, most likely the direction line.

from mega65-core.

Actually, it is working now: I can see /IO1 going low when required.

from mega65-core.

Writing to $DE00 from hardware is causing /IO1 to go low. Confirm that R/W also goes low at that time.
/IO1 and R/W are aligned to the clock.
Is it possible that we don't have a long enough hold time, and thus the value being written might not be latched properly by the cartridge. According to: https://www.princeton.edu/~mae412/HANDOUTS/Datasheets/6502.pdf there is a minimum write hold time of 60ns, and 20ns for read. Fixing that should hopefully help.

from mega65-core.

Need to implement sub-cycle phase management to implement the differential read and write hold times.

from mega65-core.

Also R/W and address have hold requirements of at least 30ns.

from mega65-core.

The Tiny Quest cart itself uses a 74LS04N and 74LS173AN, as described here:
https://www.hackup.net/2019/07/bank-switching-cartridges/

In short, it definitely needs setup and hold times for things, as the 74LS173 will latch the data lines some tens of ns after the positive clock edge. Right now, we have the clock exactly synchronised with the data, and thus of course things go badly, because by the time the clock edge has been seen, by definition, the data lines are no longer showing the value.

Holding the data lines (and /IO1 and /IO2 since they can be required for decoding a write in the cartridge circuit) for half an 8MHz dotclock period will give us a delay of ~64ns, which is just about perfect based on the 6502 data sheet requirements.

from mega65-core.

With the hold time implemented, its now being a bit weird:

Output changes each time, as well. Other key thing is mostly its the upper nybl of the data that is zeroed out each time.

Anyway, there is clearly something wrong still, and the changing data may or may not in fact be all that's happening, i.e., suggesting that the cartridge is not latching the address.

Actually, with the Tiny Quest cartridge, because it uses a discrete 74LS173, I can probe the latched lines directly, and see if it is in fact latching things or not.

from mega65-core.

Confirmed by probing the board that with the hold time fixes that the 74LS173AN does latch the bank number.

So the problem must be with reading from the EPROM. That relies on R/W being high and /ROML being low.

from mega65-core.

Writing a little BASIC loop that reads the ROM continuously and shows the hex over the top of itself on the screen, I can see that the lower nybl values change, while the upper nybls are broadly stable, often clamped to 0.

from mega65-core.

Without hold time fix, it looks like latching doesn't happen with the 74LS173AN, as expected.
So now to find and fix whatever the problem with reading the ROM is. The test bed does not currently test that, nor does it model the dir and en lines for the various signals. Next step is to expand it to do exactly that.

from mega65-core.

Note that this cartridge design can disable itself by setting bit 3 of $DE00. After that it requires /RESET to go low to re-enable itself.
Info on the cartridge here (in German): https://www.hackup.net/2019/07/bank-switching-cartridges/
I've seen that happening sometimes on boot during testing.

from mega65-core.

With R/W and /IO1 on cart port delayed by 125ns, I'm still not reading anything. But the $DE00 writes to select banks now seems to be working fine. So I'm guessing that the problem is now isolated to reading from the ROM.

from mega65-core.

Hi @gardners - WOW! This is a thorough analysis and debugging session. Thank you for investing so much time and energy and for sharing your "debugging diary"! Very interesting and helpful for me to read and to follow.

Just to give you another "impulse" - because for me personally, sometimes "debugging by thinking about the DIFF" helps :-) Here is the thought:

Why could it be, that on an R3/R3A board the cartridge detection works fine and stable, while on an R5 board it does not? Can there be other reasons than the ones you described? For example - why would the hold time issue not be an issue on the R3/R3A? And why would we care for /IO1 and /IO2 when all that @lydon42 's detection code needs is "CBM80" at $8000?

from mega65-core.

"CBM80" at $8000

It's CBM80 at $8004 (reference), and just for completeness: this is the autostart marker the C64 KERNAL looks for, a cartridge needs to pull down EXROM/GAME or no memory is mapped. We just doing this as we can access cartridge ROM without EXROM/GAME being low, and because there are weird cartridges out there not doing this properly.

Also note that an Ultimax mode cartridge does not need (nor will have) this marker at all, as ROMH replace KERNAL at $E000, and so the autostart is not done by looking for this marker, but because the reset vector is replaced by the cartridge ROMH.

from mega65-core.

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.

from mega65-core.

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.

from mega65-core.

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

from mega65-core.

@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.

from mega65-core.

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?

from mega65-core.

@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

from mega65-core.

from mega65-core.

from mega65-core.

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

from mega65-core.

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

from mega65-core.