G1FTU CW Easter Egg

[jpnz]

I was taking a look at the original TZX release of G1FTU CW trying to work out why it crashes after loading is complete

The BASIC and last block of code are encrypted, and the loader is similar to a Speedlock type standard R-register decrypter

And that's where the problem is - when the decrypter starts for the last code block, R is set at 0x34 and produces garbage

If you set a breakpoint at 0xf09c and set R to become 0x08 then the code will decrypt correctly and the utility will start OK

As for why this actually occurs, I'm not sure - perhaps an issue with the TZX. Could probably be fixed with a patch or something along those lines

Anyway, I digress - while I was looking around I found some curious code at 0x5cde that performs a key scan

Imagine my surprise when this happened! Be patient and wait for the loading screen to render...

Spoiler

[PeterJ]

Nice @jpnz!

There is a nice video from 2017 which shows the software in action with a modern Airspy device:

[jpnz]

@PeterJ thank you for the link - great to see the real thing working

I have put a fix together to resolve the loading crash which can be downloaded here

Tested under emulation and with a real +3 - the Easter Egg [described in the first post] will still work

Make sure your machine is in 48K mode, load the fix up TZX then playback the G1FTU CW TZX in real time - disable tape traps for emulators!

Interesting to see that once loading is complete the tape was originally released to radio operator G3FME - after a Google search it appears they had resided, at some point, about 8 miles away from my home town...

Instructions for G1FTU CW have been recently uploaded and published - thank you to the SC team for that!

[jpnz]

Just a brief update - I have sourced a cassette of G1FTU CW and taken a WAV sample

After the last block of code there are some all important tones (which are missing from the TZX):



I have run the sample through MakeTZX and wav2tzx and haven't had much luck making a reasonable TZX

I'm sharing the sample with the community and hopefully someone can incorporate those vital tones

I'm guessing that SSTV will be expecting the same tones - perhaps that TZX could be retrospectively fixed as well...

Thank you!

[Guesser]

For those like me who aren't proficient with their morse:

Spoiler

Code: Select all

CQ CQ DE G1FTU [end of message] [invitation to transmit]

[Guesser]

After the last block of code there are some all important tones (which are missing from the TZX):

Interesting. I wonder if they're specific to each tape?

[lfaria]

I see that this latest wav file is from a version used bu operator M.S.3 ?!? weird identification...
The operator of the "different" tzx on the archive is ON1KLE , (from Belgium? )
and, like @jpnz stated above, the one from the main tzx is G3FME (UK)

Anyway, and back to the wav: Some 840ms after the big block come 3 sets of pulses:
the 1st one with roughly sixty-something "bits" with average pulse length between a "0" and a "1",
a 20ms pause,
the 2nd one with roughly 50 "bits" with average pulse length the same as a "0",
another 20ms pause,
and the 3rd one is similar to the 1st one.

So, appending 3 "pure tone" blocks to the tzx with "pauses" between them would fix it...

But instead, (after some disassembling to check what's going on) here's what I did:

Fired up an emulator (Fuse), placed a breakpoint at 0xF040 (just after big block has loaded, before checking if it failed), load wav, press play on tape.
When breakpoint hits, stop tape and then let the emulation continue (therefore the 3 pulse groups don't play)...
and it works! (yes, if I simply cut them out of the wav file, it also works)
Conclusion: the pulse groups are not needed (and probably are some artifact of the duplicator tool used to create the tape) and something else is wrong with the tzx!

[jpnz]

Thanks all for the feedback and analysis - have kind of given up on a working TZX at the moment, and uploaded some PZX & CSW images along with some other scans

[jpnz]

I was taking a look at the original TZX release of G1FTU CW trying to work out why it crashes after loading is complete

The BASIC and last block of code are encrypted, and the loader is similar to a Speedlock type standard R-register decrypter

And that's where the problem is - when the decrypter starts for the last code block, R is set at 0x34 and produces garbage

If you set a breakpoint at 0xf09c and set R to become 0x08 then the code will decrypt correctly and the utility will start OK

As for why this actually occurs, I'm not sure - perhaps an issue with the TZX. Could probably be fixed with a patch or something along those lines

Anyway, I digress - while I was looking around I found some curious code at 0x5cde that performs a key scan

Imagine my surprise when this happened! Be patient and wait for the loading screen to render...

Spoiler

Had a couple of comments added to that video earlier today...

Spoiler

You found the easter egg! Well done - I don't think that anyone else has... John (G1FTU)

There should be one in G1FTU RTTY and G1FTU SSTV, too