I can reproduce a bug some people on Facebook noted with their C128s. Using an Ultimate II+ all works fine, but using my original Commodore 1750 REU I get a screwed up title-screen and the game hangs when trying to start. I posted pics on Forum64. We were theorizing that the REU-setup may be done in 2 Mhz-mode which the original REU likely can't handle. Bart van Leeuwen thinks it may also be because "any 'real' 17xx REU is nowadays slightly out of spec timing wise due to drift of components over those 30 years."

Can run tests on my hardware with original 1750 and UII+ if required.

Quote:

Bart van Leeuwen thinks it may also be because "any 'real' 17xx REU is nowadays slightly out of spec timing wise due to drift of components over those 30 years."

not really. however the 1541U REU is "slightly out of spec" indeed :)

i'd be very interested in test cases for REU+2MHz for that matter - since there exists only wild guesses and conclusions based on anecdotes so far.

Quoting Groepaz

Quote:

Bart van Leeuwen thinks it may also be because "any 'real' 17xx REU is nowadays slightly out of spec timing wise due to drift of components over those 30 years."

not really. however the 1541U REU is "slightly out of spec" indeed :)

And yet, it works, where a real 1750 didn't?

Many components do go 'off value' with enough time, including things like that resistor which is different between a 1750 and 1764 and supposedly affects timing.

Quoting Groepaz

i'd be very interested in test cases for REU+2MHz for that matter - since there exists only wild guesses and conclusions based on anecdotes so far.

DMA at 2mhz is not reliable because the potential of a misfetch when the transfer is complete. That is already clearly stated in the documentation of a real Commodore 1750, and can be verified by testing. Its not even specific to the REU, it can also happen with other devices which use DMA. For doing DMA 'load/save' with the Ultimate II(+) on the C128, I also had to force 1mhz mode during the actual DMA transfer for the same reason.

So I'd rather say.. if 2mhz does work for DMA, that is because you happen to just luck out and not have a bad fetch after the dma completes.

And that is not speculation, as said, this is already documented in the manual of the 1750 (among others).

Quote:

including things like that resistor

of all things, resistors will not change their value over time :) and btw. that resistor goes to a pin on the REC that will inform it about the type of ram installed on the board - the actual value of that resistor is pretty irrelevant as long as its there (or not).

Quote:

this is already documented in the manual of the 1750

which doesnt mean much really - it may or may not be correct. the only proof is an actual testcase that you can run and verify on the actual hardware. and so far we have no such thing :)

Quote:

including things like that resistor

of all things, resistors will not change their value over time :)

and btw. that resistor goes to a pin on the REC that will inform it about the type of ram installed on the board - the actual value of that resistor is pretty irrelevant as long as its there (or not).

as long as they arent available, they can be considered non existant. so if you have testcases (preferably with source so we can easily mod them for the testbench), please provide them.

Quoting Groepaz

as long as they arent available, they can be considered non existant. so if you have testcases (preferably with source so we can easily mod them for the testbench), please provide them.

A testcase sounds usefull, but I do not have a simple testcase, if only because I fixed the places where I ran into this quite some time ago.

But I also think it is a bit the wrong way around. The documentation says X. X might be incorrect, sure, documentation isn't always correct.. but you'd have to demonstrate the documentation wrong when saying it is wrong, else it is still what tells how it should work. As this is merely the potential of a misfetch (claimed), proving that might not be so trivial. It working on one, or even a few machines, or even 99.9% of the time on all machines, does not actually demonstrate the documentation wrong.

At any rate, I'll check if I can recreate one of my old problem cases and distill the relevant code, but that won't be today.

A very closely related issue is the UII at times causing a crash on a c128 running in 2mhz mode when leaving the UII menu (this is also completely dma based). Almost always works for me, at times it crashes.

ned128: a testcase is needed not only to prove the documentation is right or wrong - its also needed to reproduce the exact behaviour. ie want we want to know isnt "it goes wrong", but "what exactly happens under what conditions". eg if this is a bustiming related issue, that described instruction fetch that goes wrong may actually depend on the last value transferred in the DMA.

Quoting Groepaz

ned128: a testcase is needed not only to prove the documentation is right or wrong - its also needed to reproduce the exact behaviour. ie want we want to know isnt "it goes wrong", but "what exactly happens under what conditions". eg if this is a bustiming related issue, that described instruction fetch that goes wrong may actually depend on the last value transferred in the DMA.

Which is why I said a testcase is a good idea anyway, and will spend some time on trying to distill one from my own code, however.. that still doesn't prove this is what is going wrong with Sonic.

I'd expect it to fail intermittently still on my hardware, but leaving it running for some 12 hours didn't show that. Maybe not long enough? could be. Needed the system for something else tho.

I can also report multiple people encountering the same problem with a real-world SuperCPU: loads to SEGA logo, then freeze. Sample does not play.

Setup:
NTSC C64
sd2iec loading original .d81 on #9 (no other drives attached), selecting Compatible load.
SCPU 64 w/4 MB RAM REV 2B ("UNIT" and "JIFFYDOS" always on Enable, read on for "SPEED" info)
REUs: Both CMD 1750XL 2 MB and C= 1764 256K

No difference in outcome based on which REU is used.
With SPEED switch in Turbo, the warning about NTSC 64 framerate will be skipped. With SPEED switch in Normal, the Y/N prompt about framerate is displayed.

When SCPU UNIT switch is DISABLED, game loads and plays (as long as not allowed to enter demo mode, as previously reported!)

And I'll add my configurations to those reporting garbled-title and hang-at-black-screen-upon-game-start:

NTSC C128D (with JiffyDOS)
sd2iec on #9
Either CMD 1750XL 2 MB or C= 1764 256K

Game skips the too-slow warning and correctly prompts for a full pre-load on 1750XL, but the Sonic the Hedgehog title screen is garbled, and the game hangs at black whether trying to run the demo or start the player-controlled game. (Choice of REU is irrelevant, crash appears identical.)

Quoting Groepaz

Quote:

including things like that resistor

of all things, resistors will not change their value over time :) and btw. that resistor goes to a pin on the REC that will inform it about the type of ram installed on the board - the actual value of that resistor is pretty irrelevant as long as its there (or not).

What you are talking about sounds like J1 (ram size jumper), it is different between a 1700 on one side, and the 1750 and 1764 on the other side, and indicates if 64x1 or 256x1 chips are used.

What I am talking about is resistor R4, which is not present on the 1764 but is on the 1700 and 1750. Does this connect to a pin on the REC? not that I can see...

R4 is a pullup, actual (precise) value doesnt matter here either :) It probably makes sense to install this one in a 1764 too.

Quoting Groepaz

R4 is a pullup, actual (precise) value doesnt matter here either :) It probably makes sense to install this one in a 1764 too.

When using it with a C128, yes. When using a 1750 or 1700 with a C64, it might be better to remove it, as per the designer of this device.

Quoting Groepaz

actually, it shouldnt matter in either combination - there already is a 3.3k pullup at the DMA line in both the C64 and the C128, adding another only makes it a bit stronger pullup. in practise though, both 3.3k or 1.5k should have the same effect. perhaps there exist C128 boards without that pullup, or something like that.

That sounds like a possible explanation. But have the same effect.. shouldn't the stronger pull-up result in also draining whatever charge is there a little bit faster and result in slightly faster response? If that makes a 10ns difference, it could be enough to be relevant here.

yes, but the difference shouldnt matter... both 1,5k and 3,3k are common values for this kind of thing. IF it actually makes a difference, that is a strong hint for the whole design being very fragile =P

Quoting Groepaz

yes, but the difference shouldnt matter... both 1,5k and 3,3k are common values for this kind of thing. IF it actually makes a difference, that is a strong hint for the whole design being very fragile =P

So.. enabling 2mhz, and doing reu -> c64 transfers (53 bytes, but amount doesn't seem to matter much) in a tight loop..

Seeing what looks like memory corruption at least on machines on which 2mhz isn't working with Sonic. Interesting. That also makes creating a reliable test which runs from ram a bit of a pita.

you could use EF or RR perhaps?

what type of corruption is it though?

Quoting Groepaz

you could use EF or RR perhaps?

what type of corruption is it though?

Good question.. seeing bytes being set to $f0 or $ff and some of my code getting modified by that.. need to see how that relates to REU data, if it does... but will be away till late on sunday.

that almost answers the question :) does it only happen after a dma write? (it might mean a instruction fetch turns into a write, the value then likely is some floating bus stuff) (perhaps some mod can split this reu discussion into a seperate thread....)