TeensyROM is not booting its menu

[sy2002]

@dansanderson reported via Discord:

I do not know the TeensyROM cartridge, yet and assume it is this one:

https://github.com/SensoriumEmbedded/TeensyROM

@dansanderson please clarify/confirm: I do assume you tested on an R6 board using V5.1 RC3 or RC3A?

[dansanderson]

Correct, that's TeensyROM. C64 core WIP-V5.1-RC2.

Technically we tested on an unpatched R5, which might make a difference. I didn't get around to installing the bodge wires that IIRC we told Trenz to install on the R6. I should have an R6 to test with when my number comes up soon.

[sy2002]

@dansanderson Indeed it would be great if you could confirm that the problem persists on a R6 board. Reason: The C64 core explicitly makes use of "hardware stuff" that requires a modded R5 or a (regular) R6 board. Means: If you use an unmodded R5, then the C64 core might stumble. But I am not claiming this is the reason ;-) There MIGHT be other reasons. Please take your time, we are not in a hurry regarding this issue - but as soon as time is ripe, please confirm.

[paich64]

I just got my Tensyrom and tested it with my R6 board.

Here are the observations using the c64 core V5.1 :

1. When booting the Mega65 with the Tensyrom inserted, the C64 core is started, meaning, the cartridge is detected as a C64 cartridge
2. However, the TensyROM menu won't show show up
3. Pressing the "main menu" TensyROM button will result in the core being reset (obviously) but the menu won't show up
4. Short/long reset of the C64 core won't help

Here are the observations when enforcing the MEGA65 core to boot with the cartridge inserted (Holding NOSCROLL and selecting the MEGA65 core in slot number 1

1. Most of the of the time, the TensyROM main menu will show up
2. When the TensyROM menu does not show up (instead we have the Mega65 basic prompt) a simple reset, or using GO64 will result in the TensyROM menu showing up
3. Contrary to the C64 core, the "main menu" TensyROM button does not trigger any reset (while it should)
4. .prg will load and work as expected
5. .crt will keep loading forever and will never start
6. F2 which is supposed to leave the menu and go back to the Basic prompt does not work and result in freezing all other keys which are usually working

I have ordered a second TENSYROM and will ship it to @MJoergen as soon as i get it.
I confirm it's this cartridge : https://github.com/SensoriumEmbedded/TeensyROM
I confirm that TRAVIS agrees to help us with the troubleshooting.

[paich64]

update : Tensyrom will be shipped to Michael next monday. In the meantime here is the behaviour observed on 3 different configurations :

Note, this is the manual for the Tensyrom : https://github.com/SensoriumEmbedded/TeensyROM/blob/main/docs/General_Usage.md

TENSYROM on Ultimate 64 This is the expected behaviour.

https://www.youtube.com/watch?v=zu5A68Ha8nY

switching on the Ultimate 64 results in the cartridge booting and starting the tensyrom menu.
we can hit F3, browse the Tensyrom SD card, select a .prg file, the .prg file gets loaded and the program started.
Hitting the Tensyrom button reset button results in the tensyrom cartridge being reset (loading again the the tensyrom menu).
Holding the reset button a long time results in the catrige starting its reset procedure but being frozen (as if cpu was stopped) and releasing it
will result in the tensyrom cartridge reset procedure completing (loading again the the tensyrom menu).

TENSYROM with the MEGA65 core 0.96 (R6 board)

https://www.youtube.com/watch?v=tLNC_dhvpHY

the c64 core is not installed, so if a c64 cartridge is inserted the Mega65 core will start in GO64 mode.

switching on the Mega65 WITHOUT the C64 core installed and the Tensyrom inserted results in the GO64 mode starting and the cartridge booting and starting
the tensyrom menu. As on a real C64, we can hit F3, browse the Tensyrom SD card, select a .prg file, the .prg file gets loaded and the program started.
Note : because of the limitations of the GO64 mode, not all .prg will load and play.

The tensyrom reset button does not work when in GO64 mode : pressing it does nothing.
To go back to the Tensyrom menu, we have to push the Mega65 reset button.

TENSYROM with the C64 core V5.1 (R6 board)

https://www.youtube.com/watch?v=U397i7pEvgc

the C64 core is installed and configured to start when a c64 cartridge is inserted.

switching on the Mega65 with the C64 core installed and the Tensyrom inserted results in the C64 core starting.
This means that the tensyrom is detected as a C64 cartridge. However, The tensyrom menu does not show up.

The video show the Mega65 booting the C64 core (but no tensyrom menu shows up). Then 2 short resets are consecutively
executed using the Tensyrom reset button : each time a black screen appears and we get back to the C64 "ready" prompt.
Then 1 long reset is executed with the Tensyrom reset button (we keep the tensyrom reset button held a few seconds before releasing it) :
The black screen appears and stays until we release the Tensyrom reset button. When we release it we get back to the C64 "ready" prompt.

[Kugelblitz360]

And @SensoriumEmbedded mentioned to me that TeensyROM is holding the Reset line for approx. 50.000 Phi2 cycles in order to initialize itself; this halts the CPU.

[SensoriumEmbedded]

The 50mS reset hold time was chosen somewhat arbitrarily. If you think holding it that long is the cause, I'm happy to do a build with shorter reset time to help prove it out. Just let me know, thanks!

[Kugelblitz360]

When the MEGA65 is in M65 Core mode, GO64 activates the (physical) TeensyROM cartridge. It boots, Music plays, Menu works. Internal functionality like updating via SD card works too.

In the C64 Core the cartridge does not boot but the RAM test in Reset sees that there is a ROM and outputs 30719 BASIC BYTES FREE

A quick and dirty test:

10 PRINT PEEK (32768)
20 GOTO 10
show the value 255 with a 70% chance. In the other 30% of cases it shows either 9 (the correct value for most carts), 63 or 127.
Doing the test with 32769, which most often contains $80, gets again most often 255, some 128, some 191 and some 159.

So somehow the cart simply is not read correctly.

In the setup screen (f8) "RW Read Dly" is default "Off". You could set this to "On" (it gets saved in EEPROM) then power off and back on to apply it and see if you notice anything different.

When this is done, the values switch to 9, 41 and 57. Getting there, 9 is the correct value, but still there is something wrong.

[sy2002]

@Kugelblitz360 Can you please check what happens, if you turn "HDMI: Flicker-free" OFF, save the settings (confirm by resetting without the cartridge) and then try again?

[Kugelblitz360]

That was with Flicker-Free off (because I was still testing CRT stuff too) but in 5:4 576p and Audio On, if that makes a difference?

With HDMI Flicker ON the values for $8000 are most often 63, some 9, some 61.

[Kugelblitz360]

POKE 32768,0 or POKE 32768,255 does not change anything, so it is not that it sometimes reads the RAM.

Sanity checked with 32767 too, there PEEK gives the value I poked.

[SensoriumEmbedded]

I've documented my findings around GO64 and C64 Core compatibilities with the TeensyROM in the attached documents. This includes recommendations for code improvements on the Mega65 side.
I've temporarily worked around the largest issue with TR firmware to get it working in C64 core mode. FW available here

Findings docs:
Mega65+TeensyROM using C64 Core.pdf
Mega65+TeensyROM using GO64.pdf

[MJoergen]

@dansanderson @paich64 @sy2002 @SensoriumEmbedded @Kugelblitz360

Here is a screenshot from the FPGA's built-in logic analyzer (ILA):

The numbers at the top are core clock cycles @ 32 MHz, i.e. the units are approx 32 ns.

The interesting traces are cart_a_o (address output) and cart_d_i (data input), as well as cart_phi2_o. Here the trace is reading from address 0x8008, and the correct value 0x30 is available already after 8 clock cycles (250 ns) later. However, when cart_phi2_o has the falling edge, the data input changes to 0x7F (not visible in the picture). This is the value seen by the CPU, so that indicates that the CPU is sampling the data lines right around the falling edge of the PHI2 clock.

I've made a small fix in commit 03960c6 (on branch mfj_issue_143 to be merged into the develop branch) that delays the PHI2 clock to the cartridge by one clock cycles (i.e. 32 ns). With that fix the TR menu appears.

However, since this fix changes the timing on the cartridge port, we need to perform an extensive test of the existing hardware cartridges to check for any negative side effects of this fix (i.e. regressions). Therefore, I've put this fix on the develop branch, which is the target for the later V5.3 release.

However, if anyone is willing to give this fix a quick spin, please do and please report back here with your findings.

[Kugelblitz360]

If you would build that core, we could test Sidekick64 against it which also fails to run currently. Would you mind sharing a binary, maybe on our other communication channel?

…

________________________________ From: Michael Jørgensen ***@***.***> Sent: Friday, December 6, 2024 10:58 To: MJoergen/C64MEGA65 ***@***.***> Cc: Boris Schneider-Johne ***@***.***>; Mention ***@***.***> Subject: Re: [MJoergen/C64MEGA65] TeensyROM is not booting its menu (Issue #143) Here is a screenshot from the FPGA's built-in logic analyzer (ILA): Screenshot.from.2024-12-06.10-10-04.png (view on web)<https://github.com/user-attachments/assets/57e19271-3253-4d68-89c7-868a076060e6> The numbers at the top are core clock cycles @ 32 MHz, i.e. the units are approx 32 ns. The interesting traces are cart_a_o (address output) and cart_d_i (data input), as well as cart_phi2_o. Here the trace is reading from address 0x8008, and the correct value 0x30 is available already after 8 clock cycles (250 ns) later. However, when cart_phi2_o has the falling edge, the data input changes to 0x7F (not visible in the picture). This is the value seen by the CPU, so that indicates that the CPU is sampling the data lines right around the falling edge of the PHI2 clock. I've made a small fix in commit 03960c6<03960c6> (on the develop branch) that delays the PHI2 clock to the cartridge by one clock cycles (i.e. 32 ns). With that fix the TR menu appears. However, since this fix changes the timing on the cartridge port, we need to perform an extensive test of the existing hardware cartridges to check for any negative side effects of this fix (i.e. regressions). Therefore, I've put this fix on the develop branch, which is the target for the later V5.3 release. However, if anyone is willing to give this fix a spin, please do and please report back here with your findings. — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AORPL6XHVEIMARX6P4GMHOL2EFYMHAVCNFSM6AAAAABJYXC3YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRSG4YDIOJWGI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[paich64]

Hi just made a quick regression test with V5.3A1 and my hardware cartridges :

They are all working with V5.1 Final

With V5.3A1 :

Zetawings => won't boot
EF1 with "Eye of the beyholder" => won't boot
Robot Ject Action => won't boot
Super BreadBox => won't boot
Protovision Sam's Journey => won't boot
Protovision Galencia => Won't boot

Kung Fu Flash => boots, works
EF3 => boots, will boot any game, especially "Eye of the beyholder" and works
EF1 with "A pig Quest" => boots and works
Protovision "Soulforce" => boots and works
Protovision "A pig quest" => boots and works
Seawolves => boots and works
Avengers => boots and works
Pinball Spectacular => boots and works
Hesware "Grid Runner" => boots and works
Custom made cartridge "Creatures" => boots and works
Custom made cartridge "Mayhem in Monsterland" => boots and works
Power Cartridge => boots and works
Custom made Super Snapshot V5 => boots and works

Interesting to note that it's not all EF1 which fail : It looks like it depends on the game which is flashed on EF1.

[paich64]

@MJoergen you're the FPGA master !!!!!!

I again re-tested all my cartridges, one more time with V5.3A1 (and the results did not change),

BUT, then, re-tested all my cartridges with V5.3A2 and you did it !

Zetawings => boots and works
EF1 with "Eye of the beyholder" => boots and works
Robot Ject Action => boots and works
Super BreadBox => boots and works
Protovision Sam's Journey => boots and works
Protovision Galencia => boots and works
Kung Fu Flash => boots, works
EF3 => boots, will boot any game, especially "Eye of the beyholder" and works
EF1 with "A pig Quest" => boots and works
Protovision "Soulforce" => boots and works
Protovision "A pig quest" => boots and works
Seawolves => boots and works
Avengers => boots and works
Pinball Spectacular => boots and works
Hesware "Grid Runner" => boots and works
Custom made cartridge "Creatures" => boots and works
Custom made cartridge "Mayhem in Monsterland" => boots and works
Power Cartridge => boots and works
Custom made Super Snapshot V5 => boots and works

And my Tensyrom boots fine with C64 core and launch games without any special firmware :)

Now have to keep testing the tensyrom features, but it boots and launch games !!!

Thanks a lot !

[paich64]

Adding the following 2 cartridges which keep working as expected with V5.3A2 👍

Action Replay VI => boots and works
Final Cartridge III => boots and works

[paich64]

Tested the TensyROM supported cartridge types with the C64 core V5.3A2 (Lastest Tensyrom firmware)

All the TENSYROM supported cart type are working perfectly when launched from Tensyrom.

Cart_Generic 0 ===============> OK , including Ultimax Games !
Cart_Oceantype1 5 ===============> OK
Cart_FunPlayPowerPlay 7 ===============> OK
Cart_SuperGames 8 ===============> OK
Cart_EpyxFastload 10 ==============> OK
Cart_C64GameSystem3 15 ===============> OK
Cart_Dinamic 17 ===============> OK
Cart_ZaxxonSuper 18 ===============> OK
Cart_MagicDesk 19 ===============> OK
Cart_EasyFlash 32 (file size limit and no EAPI support) ===============> OK

[paich64]

After having tested many .PRG files which currently do not work with the C64 core (to be fixed in 5.2) I confirm .PRG loading works nicely when loaded via TENSYROM using V5.3A2.

[sy2002]

@MJoergen I checked the commit and delaying the PHI2 output is indeed a "dangerous" change as it changes absolutely everything we do on this hardware port. On the other hand: @paich64 's tests sound EXTREMELY promising. I reviewed your fix and it is clean and easy. So I would tend to even add it to V5.2 if you agree and if @paich64 can confirm that...

a) ... these encouraging results are working on R3 and R6 systems

b) ... FLASHING the EF1 and EF3 still works like a charme on R3 and R6 systems: Flash the EasyFlash 1CR with a small (<64k) and large (>512k) game and playtest these games, Flash the EasyFlash 3 with a small (<64k) and large (>512k) game and playtest these games

c) ... saving and loading savegames still works on R3 and R6 systems (example Sam's Journey save game, load game)

[paich64]

@sy2002 @MJoergen remember that my R3A is not reliable at all when it comes to the cartridge port ....
So I'm afraid but when it specifically comes to the cartridge port i can't provide meaningfull results.
Just for the record, EF1 do not work anymore on my R3A, KFF has never worked on my R3A, even with the workaround ......

I will confirm b) and c) for R6 at least.

For R3A, despite the non reliability of my very own cartridge port, i only have the R6 version of V5.3A2.

Unless someone find a way to provide me a R3A board not having issue with the cartridge port, these specific test are unlikely to be accurately confirmed on my side.

[Kugelblitz360]

I will be testing TeensyROM network, NFC and other USB functionality (not MIDI I am afraid, but if I can get network to work), then Sidekick64 (excluding the 2nd SID emulation because that needs extra wires to the (non existing) SID inside the C64), then EF3 flashing and game saving and many more KFF tests with writing to the SD Card.

Does the timing change positively affect the skoe Kernal replacement trick? https://skoe.de/kernal/[kernal-cartridge.pdf](https://skoe.de/kernal/kernal-cartridge.pdf)

[MJoergen]

@MJoergen I checked the commit and delaying the PHI2 output is indeed a "dangerous" change as it changes absolutely everything we do on this hardware port. On the other hand: @paich64 's tests sound EXTREMELY promising. I reviewed your fix and it is clean and easy. So I would tend to even add it to V5.2 if you agree and if @paich64 can confirm that...

a) ... these encouraging results are working on R3 and R6 systems

b) ... FLASHING the EF1 and EF3 still works like a charme on R3 and R6 systems: Flash the EasyFlash 1CR with a small (<64k) and large (>512k) game and playtest these games, Flash the EasyFlash 3 with a small (<64k) and large (>512k) game and playtest these games

c) ... saving and loading savegames still works on R3 and R6 systems (example Sam's Journey save game, load game)

Historically, the V5.2 release was meant to fix the "HDMI jailbar issue" quickly, and to avoid abusing @paich64 's time and willingness to test. The V5.3 release is looking to become a "cartridge" release, fixing bugs in both physical and simulated cartridges. I even plan to looking into supporting simultaneously physical cartridge, simulated cartridges, and the simulated REU. The use case is a simulated cartridge with a game that needs REU, with an attached physical freezer cartridge. I can't find a GitHub issue with this feature request, but I think it should be doable. This seems like a nice feature to include in the V5.3 release.

So to summarize, I think we should avoid "feature creep" in the V5.2 release, and keep it simple.

[MJoergen]

Does the timing change positively affect the skoe Kernal replacement trick? [https://skoe.de/kernal/kernal-cartridge.pdf](https://skoe.de/kernal/%5Bkernal-cartridge.pdf%5D(https://skoe.de/kernal/kernal-cartridge.pdf))

It's quite likely to have an impact. I would need to study this document in detail, so not likely to happen right now. Is there already a GitHub issue with this bug ?

[Kugelblitz360]

It's the way Easyflash 3 does Kernal replacement, which you actively switched off because so far it did not work.

…

________________________________ Von: Michael Jørgensen ***@***.***> Gesendet: Sonntag, 8. Dezember 2024 12:43 An: MJoergen/C64MEGA65 ***@***.***> Cc: Boris Schneider-Johne ***@***.***>; Mention ***@***.***> Betreff: Re: [MJoergen/C64MEGA65] TeensyROM is not booting its menu (Issue #143) Does the timing change positively affect the skoe Kernal replacement trick? [https://skoe.de/kernal/kernal-cartridge.pdf<https://skoe.de/kernal/kernal-cartridge.pdf>](https://skoe.de/kernal/%5Bkernal-cartridge.pdf%5D(https://skoe.de/kernal/kernal-cartridge.pdf)) It's quite likely to have an impact. I would need to study this document in detail, so not likely to happen right now. Is there already a GitHub issue with this bug ? — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AORPL6RRVTOV2SYSAXXEICT2EQWGLAVCNFSM6AAAAABJYXC3YKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRVGY3TOMBVGI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sy2002]

@MJoergen OK agreed, let's avoid feature creep in V5.2 and then this one stays in V5.3 as it might become a "cartridge release". The smaller PRs from csoren go to V5.2 as discussed there.

@MJoergen EF3 kernal replacement will not work without larger tricks (particularly on R3 boards) as the EF3 does electrically some things that work on a C64 but that might overload the input/output drivers of the MEGA65 PCB. More details are here: #126 Summary @Kugelblitz360: This fix has nothing to do with the EF3 kernal replacements.

@Kugelblitz360 and @paich64 Thank you for testing what I have written above when time is ripe. Please document here.

[Kugelblitz360]

Very first tests show that the 5.3A2 changes made Sidekick64 (https://github.com/frntc/Sidekick64) boot and work. Stress tests to follow. But to me that change looks more and more promising because it enables more of the Software-Defined carts which in theory should be more critical than the good old EPROM based ones...