CLEAR command messes with Beepola ROMBeep tunes on a real 48K?

[TakuikaNinja]

So this is a really weird problem I've ran into. I was trying to play a Beepola ROMBeep tune from my 48K unit and this is what happens:

• The tune starts 1 or 2 patterns into the song data instead of the first pattern.
• Pressing a key to stop the tune (or letting the tune stop on its own if configured) causes the system to bug out. I've seen corrupted screen writes, unusual BASIC errors, and even uncommanded resets.

It plays perfectly fine on Fuse and BizHawk. I've already eliminated the "tape interface" from the equation as I've tried playing audio from my PC using a tape2wav conversion.
I've narrowed down the BASIC loader to these lines for the simplest possible way to break it (VAL "" statements can be swapped with plain numbers):

Code: Select all

10 CLEAR VAL "39999": LOAD ""CODE
20 RANDOMIZE USR VAL "40000"

The issue mysteriously goes away if I do this instead:

Code: Select all

10 LOAD ""CODE
20 RANDOMIZE USR VAL "40000"

So my question is: Why does the CLEAR command break things in this specific scenario? Is it my hardware or the ROMBeep engine at fault here? Or is there some behaviour which emulators aren't emulating correctly?

[jamesh]

Unless there is something specific to the song you have, that could be a bad RAM.

The only difference between those two is that the working one never touches the area below 40000. I think the next practical troubleshooting step would be running a memory test, like this one (use TestTape/testram.tap, details).

P.S. a few sample pieces were working just fine on the real 48k for me.

[TakuikaNinja]

I've run testram.tap multiple times and it never reported any problems...

[TakuikaNinja]

I should also add that I haven't run into any of these issues when using the other engines in Beepola.

[TakuikaNinja]

Unless there is something specific to the song you have, that could be a bad RAM.

The only difference between those two is that the working one never touches the area below 40000. I think the next practical troubleshooting step would be running a memory test, like this one (use TestTape/testram.tap, details).

P.S. a few sample pieces were working just fine on the real 48k for me.

I just opened the thing up and found this beneath the heatsink plate...



Looks like a previous owner broke a pin on one of the logic ICs and tried to salvage it in the worse way possible. I also managed to bend more of its pins by trying to remove it from the double socket. I was going to replace the voltage regulator anyway, so I guess that's a new thing to add to the parts list...

Edit: That is definitely a logic IC, not RAM.

[PROSM]

That 74LS157 chip isn't a RAM IC, but it is directly involved in the operation of the RAM - it passes the address from the CPU to the upper RAM chips, so a fault in that (like a dodgy pin) could make the top 32K behave strangely.

Since that chip and the three below it are in sockets, I would presume that this was originally a 16K model that was later upgraded to 48K.

[TakuikaNinja]

I see. Thank you all for the help. I still find it really funny that so many other pieces of software work fine with this busted IC.

[1024MAK]

What make of 'upper' DRAM chips are fitted? And which issue board is it?

On issue two boards, for some makes of DRAM, this logic chip had to be modified so that the make of DRAM that was fitted would work correctly.

Some issue 3 boards also used this system even though the wire jumpers on it could be changed.

Mark

[TakuikaNinja]

Issue 3, mostly Texas Instrument ICs if I recall correctly.

[TakuikaNinja]

Also, the photo may have made it hard to notice but the bent pin is covering a completely broken pin. That can't be normal, right?