[C64] strange issue with scandoubler and SD card

[nippur72]

I have a strange issue with the C64 core that is driving me mad.

After the recent updates, the C64 always starts in scandoubler mode, regardless of the scandoubler_disable=0 setting in the mist.ini file.

And when I open the F12 menu for loading a file (.PRG or .D64), the SD card shows a corrupted directory.

The old core (c64_191220.rbf) works perfectly fine as well as the other cores. C64 cores newer than 191220 all show the same problematic behavior.

I updated to latest firmware and formatted the SD card putting fresh new files to no avail.

I was able to trace back in time and this commit is the one where the issues started to appear. But looking at the committed code I can't figure what is happening and why isn't working correctly.

Do you have any clue?

Should I assume my board is defective? (or non Mist-compatible as it's a Mistica). A friend who has another Mistica does not have my issues.

[gyurco]

Try set ROM_DIRECT_UPLOAD => 1 to 0 for user_io to check if it is caused by the direct SD-Card - FPGA SPI communication.

[nippur72]

I just did that, and now it works!!! The core boots in 15Khz as expected and the files in the SD card are ok.

Is this a bug or is my board defective?

[gyurco]

Did you try it with other SD Card?
This feature is used in minimig-hdd from the beginning, it's strange why there's a problem only in the C64 core. Maybe because it is used for boot ROM downloading?

[harbaum]

Core download in the Genesis core also has issues for me since the direct approach is being used. Initial Download of fpgagen.rom always fails. First manual download via OSD also always fails. Second manual download always succeeds.

Interestingly not a single byte arrives in memory. If there's a rom image still in ram it doesn't get corrupted/replaced by the first two Download attempts.

Since this is very reliable I assume it's a simple setup problem. The fact that the c64 also reliably does something wrong sounds like a logical error and not like a glitch or noise or ....

[gyurco]

As it seems to happen only with boot ROM downloading, and "the SD card shows a corrupted directory", maybe something in the firmware? Or three-stating of SPI_MISO is not working well? But I don't see a problem with the code.
Would be interesting to capture some SPI communications when the issue hits. Unfortunately(?) it never happens to me.

[nippur72]

I tried with a different SD card brand and it works!

So the issue is caused by SAMSUNG SD cards: I've tried two different "SAMSUNG EVO PLUS 1 32 GB", and they both don't work with the C64 core. I copied the exact same files, I've even tried to format them to 32 kb cluster, but the result it's always the same.

What do you think is the source of incompatibility? It's because the card is "SDHC" and not simple "SD" ?

[gyurco]

I don't think so. I'm using a SanDisk Ultra SDHC card currently. Probably something weird happens on the SPI bus with your cards.
I still wonder about those marks:
https://github.com/mist-devel/mist-firmware/blob/master/fat.c#L1216

Finally: I could reproduce the issue with FPGAGEN. If I have a genesis.rom, then the initial loading, and the next load from OSD fail. If I don't have a genesis.rom, then the loading from the OSD always works. I'll try to fix it, and then we can see if the C64 problem is the same. However I'm afraid, it is not.

[gyurco]

Hmm, FPGAGEN issue is because the downloader doesn't work during reset, and the ARM sets status[0] during the initial boot ROM upload. I wonder why it did work before.

[gyurco]

Found it: it worked, because the CFG loader loaded the reset value from the .cfg, too (which was obviously a non-reset state). This change prevented to mess with reset:
mist-devel/mist-firmware@e648509#diff-03554b634dd123239aa8d64c6e5741e3L314
But caused reset held until the initial download finished (which is the original intention, I think). And the un-reset override didn't work until the cfg is created, thus GENESIS.ROM didn't work until a CFG is actually saved (pretty messy behavior).

However I'm afraid all of these nothing to do with the C64 issue.

[retrofun]

But now the new cores 200523 don't start when there is no GENESIS.ROM present!
No video signal, no OSD.

Previous cores work fine (fpgagen_20200314.rbf & fpgagen_svp_20191125.rbf).

[gyurco]

Ooops, more testing next time...

[gyurco]

Now it should be OK. Btw, is it working with the problematic SD cards? Also all recent cores from Jotego are using the direct ROM download.

[harbaum]

Excellent. Genesis works like a charm. My 11 year old is seriously impressed that someone from half around the globe just fixed his problem :-)

[gyurco]

I'm not that far away :) Greetings to her/him from Hungary!