16K Issue TWO --> Hard reset when loading games

[HappyLittleDiodes]

Hi everyone

Hoping you can help me solve an issue. I think it's a hardware issue but I'm not sure at this point.
I've been refurbishing an issue two, jobs performed:

Recap
DCDC Mod (following Retroleum's instructions)
New membrane
Desocket and heatsink for ULA

I know the ULA works as I tried it in another machine.
Using a smart card the machine passes all the tests I can throw at it.

However, when loading a game using OTLA (Fast load) it will hard reset during loading. This also seems to happen when loading TAP files from a smart card.
When I loaded a 16K game using a WAV file, it loaded first time.

So, it seems like it doesn't like fast loading, it might be a setting I have wrong with OTLA, but I'm not certain.

Has anyone seen anything like this?

Thanks!

[1024MAK]

You need to separate a possible loading issue from the other possibilities.

What does
PRINT PEEK 23732 + PEEK 23733 * 256
return ?

Do typed in BASIC programs work? What about when you define a large array and fill it with values. Do the stored values read back okay (this tests the memory and the Z80)?

Do “16K byte” programs such as games, load and run okay.

Crashes that result in the microprocessor going via address zero in the ROM or via the code for the ‘NEW’ command during or after a failed load are not uncommon. So if loading from tape/audio devices, also try various volume levels.

Oh, and the ULA is highly unlikely to be the cause of a otherwise working system to crash once it has got to executing BASIC commands.

Mark

[Ast A. Moore]

OTLA needs to reside in non-contended memory to work, as far as I know. It’s essentially impossible to write a custom high-speed loader that can reside in contended memory (at least, I haven’t been able to make one). So, your machine probably works fine; OTLA is just isn’t something you’d want to test it with.

P.S. Unrelated, but OTLA’s biggest flaw in my book is that pressing a key while the code is loading will inevitably produce error. It’s unavoidable—that’s just the way the loader works.

[HappyLittleDiodes]

Hi Both

Thank you for your detailed responses.
Mark, the command returns the correct result for a 16K machine.
The reason I checked the ULA is I know I damaged a pad when I desocketed it, so I totally removed it (good practice) to find that it works, and it also allowed me to properly repair the trace.
For your interest, it was crashing during loading as oppose to after loading and executing.

16K games load and run OK as long as it's a "slow load" i.e. as from a tape, only the "fast load" from OTLA fails, but Mr Moore's post sheds more light there... thank you for that, I have zero idea about how OTLA works but I might spend some quality time with the wiki to try and learn.

I wondered if this was to do with OTLA not being compatible with a 16K and if I should crack on with the 48K upgrade and see if it helps, it sounds like it will!

Thanks again

[Ast A. Moore]

All tape loaders work on the same principle: you sample the audio input port for a change in value in a loop, while counting the number of loop iterations in between the changes. It’s arbitrary, but generally, longer counts (greater number of loop iterations) count as “one” and short as “zero.” That’s how you read data from tape, bit by bit.

Timing is pretty critical for the whole thing to work. The ROM contains a basic tape loader, and since the ROM is non-contended it will work on any Spectrum. Putting a loader in contended RAM will through off the timings in a rather unpredictable manner, and your program will never load. Since the entire RAM space of a 16K Speccy is contended, virtually all custom tape loaders—certainly all turbo loaders—are out of the question.

OTLA uses the IN F,(C) undocumented instruction and checks the parity flag. Since the Spectrum uses the same port for tape input and keyboard scanning, pressing a key while loading data from tape will affect the parity flag and you’ll get garbage data.