search

GideonZ / 1541ultimate

Official GIT archive of 1541 ultimate II sources
GNU General Public License v3.0
177 stars 45 forks source link

Cartridge Access with 2 MHz buggy #39

Open markusC64 opened 5 years ago

markusC64 commented 5 years ago

On On Wed, Feb 14, 2018 at 3:23 PM, I wrote:

Load "geos128de1571.ext.rom" as cartridge rom and select module type "Custom C128 External ROM", which means "C128 External Function ROM". It should boot GEOS and request for a disk with Desktop.

But on the 1541 Ultimate II(+?) it crashes. The file "geos128de1571.ext2.rom" is just the same, but I disabled switching to 2 Mhz - and you find it working. So clearly this is a 2 Mhz issue - completely unrelated to freezing the C128.

Analyzing the problem I found: Mostly all data is read correct. Just a small percentage is read wrong. And every wrong value is the same (cannot find my note while writing this).

Ok, I just found my note: If a value is read wrong, the high byte of the address is read instead of the content of the ROM.

Edit: Probably the same issue has been observed with other module types since them, e. g. easyflash. If you cannot find the mentioned sample files, I'll mail them to you again.

xlar54 commented 5 years ago

been trying to figure this one out as well. thanks for looking deeper into it Markus

markusC64 commented 1 year ago

https://github.com/GideonZ/1541ultimate/issues/200 also contains yet another hints in the comments what's going wrong.

bvl1999 commented 1 year ago

One note on this issue. A while ago I spent a fair bit of time on trying to figure out when it goes wrong, and there are a few things conspiring to make it fail to read data from rom.

Both cause a slight change in timing in the mmu, and conspire to make the geos boot rom fail while (most) other roms don't. For example, there is a Basic 8 .bin file and crt which also copies rom from below io space at 2mhz, but doesn't enable high common ram, and this works fine. There are some C128 .bin/crts around created with my fromify tool which also do this, and work fine. But when you add 16k or more high common ram, those start showing the exact same problem as the geos boot rom.

Seeing the high byte of the address on the data bus is no surprise, the copy code uses lda (ptr),y and the last thing which did succeed before the failed read from rom is reading the high byte of ptr from the zeropage. That also shows this fails because nobody is answering the read (supposedly because it comes either too early, or too late, I suspect the later) and hence, whatever was already on the databus is what you'll get.

Lets see if the UII+L related changes solve this.

markusC64 commented 1 year ago

Lets see if the UII+L related changes solve this.

Indeed, that is to be checked when available. I'm looking forward to test that.