Tape protection systems

discussion of beeb/electron applications, languages, utils and educational s/w
Coeus
Posts: 777
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Tape protection systems

Post by Coeus » Fri Jan 05, 2018 8:51 pm

Something to bear in mind is that for a protection tape format to be used for distribution of software for a BBC micro it does not need to be possible to write that format from a BBC micro, only that a BBC micro can read it. The binary data could be transferred from the BBC to a different machine with different capabilities and the master tape written from there.

User avatar
billcarr2005
Posts: 1191
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Tape protection systems

Post by billcarr2005 » Fri Jan 05, 2018 8:57 pm

Rich Talbot-Watkins wrote: No idea what is supposed to be changing &76 as I don't see any custom IRQ or event hooked. Maybe something is supposed to have self-modified it.
IRQ2V is pointing to &4B3, set up at &495

Code: Select all

4B3 LDA &FC
4B5 PHA
4B6 TXA
4B7 PHA
4B8 TYA
4B9 PHA
4BA LDA FE08
4BD BMI &4D2
4BF PLA
4C0 TAY
4C1 PLA
4C2 TAX
4C3 PLA
4C4 STA &FC
4C6 JMP (&0072) BACK TO IRQ2V
4C9 SEC
4CA SBC #01
4CC STA &FD
4CE LDA &104,X
 4D1 STA 7585 /  4D2 STA 75
4D4 AND #04
4D6 BEQ &4DA
4D8 DEC &76
4DA LDA FE09
4DD STA &74
4DF JMP 4BF
This is accessed after
LDA#&00
STA &76

whilst in the loop you mentioned, and DEC &76 to escape it!

[Edited, since I discovered the correct load/exec address of the code]
At the end of ABBEY3, before ABBEY4 a small piece of code is loaded at 3E00

Code: Select all

3E00 LDA #C8 ; LDX #03 ; LDY #00 ; JSR OSBYTE
3E09 LDA #08 ; JSR 541
3E0E LDA 7C ; CMP #92 ; BNE 3E17
3E14 JMP 645
3E17 JMP (FFFC)
That's seems to be followed by some strange data in the UEF
Last edited by billcarr2005 on Sat Jan 06, 2018 11:15 am, edited 2 times in total.

User avatar
Rich Talbot-Watkins
Posts: 1280
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Tape protection systems

Post by Rich Talbot-Watkins » Sat Jan 06, 2018 10:03 am

Ahh hahaha, I forgot IRQ2V even existed! Don't think I ever used it in my life!

So, if the uef.hq has preserved the data correctly, the question is: what is it about the data which is not reading correctly in BeebEm, B-Em or jsbeeb? And have you figured out the basic mechanism of the protection?

User avatar
billcarr2005
Posts: 1191
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Tape protection systems

Post by billcarr2005 » Sat Jan 06, 2018 11:23 am

I've never really looked into how UEFs are stored before, so I'm limited to pulling things apart and checking how things appear to work.
As far as I can tell, the code is all there in the UEF
All the tape blocks are standard 256 byte, although with ABBEY3 and ABBEY4 the "header" (if that's the correct terminology) before the data is shorter and I can't find where the length is stored.
Inbetween ABBEY2 and ABBEY3 there are plenty of "change of base frequency" and "security cycles"

User avatar
CMcDougall
Posts: 6058
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: Tape protection systems

Post by CMcDougall » Mon Jan 08, 2018 5:36 pm

me wrote:try using the .CSW with BackToLife prog to make the .WAV, then load
just tried this, & confirm works, also ABBEY4 is always block FF :shock: :?
ImageImageImage

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Tape protection systems

Post by ThomasHarte » Mon Jan 08, 2018 8:09 pm

billcarr2005 wrote:All the tape blocks are standard 256 byte, although with ABBEY3 and ABBEY4 the "header" (if that's the correct terminology) before the data is shorter and I can't find where the length is stored.
Inbetween ABBEY2 and ABBEY3 there are plenty of "change of base frequency" and "security cycles"
The period of high tone is likely specified as a wave cycle count; change of base frequency is of course something the encoder has to make a decision on the timing of. If you give me a discrete sample of the true wave and I see that within the high tone period that one wave cycle is 10 samples long, the next is 11 samples long, three more are then 10 samples long, the next two are 9 samples long, etc, for thousands of cycles, then I can:
  • try exactly to reproduce the discrete sample and chuck a change of base frequency in front of every single cycle that isn't exactly the same length as its predecessor;
  • put the difference down to the nature of discrete sampling, say that they're close enough, and set the base rate once so that each cycle would be somewhere around 10 cycles long (so I'm imaging perfect inspection of the original in a lossy container); or
  • put the difference down to the nature of discrete sampling and to wow and flutter in the playback because voltages, motors, etc, vary, and give myself however large a window I think is appropriate so that what I produce could have been the original on-tape signal for all I know about the means of input.
I would dare imagine Fraser's MakeUEF does something somewhere between options two and three.

But given that it works via Back2Life, most likely guess is that security cycles are used sufficiently infrequently, and no proper test cases have ever been supplied, that bugs propagate.

Also I had the feeling that jsBeeb is the only one of the BBC emulators that really tries to decouple reconstructing a tape signal from a UEF and how the BBC hardware interprets a tape signal, rather than just spiriting complete bytes directly from the UEF to the 6850. But that might be an outdated or wholly incorrect belief. But worth investigating.

User avatar
Pernod
Posts: 1204
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: Tape protection systems

Post by Pernod » Mon Jan 08, 2018 8:41 pm

ThomasHarte wrote:Also I had the feeling that jsBeeb is the only one of the BBC emulators that really tries to decouple reconstructing a tape signal from a UEF and how the BBC hardware interprets a tape signal, rather than just spiriting complete bytes directly from the UEF to the 6850. But that might be an outdated or wholly incorrect belief. But worth investigating.
MAME converts the UEF to WAV internally, but doesn't yet handle hq.uef, in progress...
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Tape protection systems

Post by ThomasHarte » Mon Jan 08, 2018 9:00 pm

Pernod wrote:
ThomasHarte wrote:Also I had the feeling that jsBeeb is the only one of the BBC emulators that really tries to decouple reconstructing a tape signal from a UEF and how the BBC hardware interprets a tape signal, rather than just spiriting complete bytes directly from the UEF to the 6850. But that might be an outdated or wholly incorrect belief. But worth investigating.
MAME converts the UEF to WAV internally, but doesn't yet handle hq.uef, in progress...
I have to admit never to having looked into MAME.

We should put together some test cases, I think, so that it's easy to unit test new implementations. My current implementation still lazily rounds baud rates to integer values so it won't quite do yet, alas, but forming some test UEFs should be pretty easy.

Post Reply