x0114 issue with security waves chunk.

[arkadiuszmakarenko]

I have found that this chunk is not working as expected. Need to investigate.

[PeterBBCUser]

A note on this parity chunk from what I have discovered :- 7e2 = &01 7o2 = &05 7e1 = &09 7o1 = &0D 8n2 = &11 8n1 = &15 8e1 = &19 8o1 = &1D

I have been playing around with some files with parity, and found something very interesting out which maybe the cause of confusion with parity. I wrote a file with 4 blocks 1st 8N2, 2nd 8N1, 3rd 8E1, 4th 8O1, And I can read them back in on the BBC with another program I wrote, now comes the interesting part when I take the wav file and process it with makeuef. I have to use the following switches to create a successful UFE file :- makeuef -i paritytest.csw -w 0 180 -z 1 8n2 -z 2 8n1 -z 3 8o1 -z 4 8e1 as you notice I have to switch the parity for 8E1 8O1 for a successful decode see the log :-

Not sure if the problem is in CSW or makeuef but someone seems to have made an error along the way and switched the two parity’s 8E1,8O1 around.

[arkadiuszmakarenko]

I have never completed proper implementation of this chunk! There is the spec. I need get my head round it first.

Chunk &0114 - security cycles

Security cycles are mainly found at the start of a run of carrier tone as an identification feature. Rarely they are at the end of a run of carrier tone. They consist of cycles of the base frequency and twice the base frequency and sometimes have a leading and/or trailing pulse. The first three bytes of this chunk (a 24 bit value) denote the number of 'cycles'. It is possible that the first and last may be only pulses. The fourth byte holds the ASCII code for 'P' or 'W'. If it is 'P', the first cycle is replaced by a single high pulse. The fifth byte again holds the ASCII code 'P' or 'W' which, if it is 'P' signifies that the last cycle is replaced by a low pulse. If the fifth byte is 'P' the fourth byte must be 'W' but has no relevance. If the 'cycles' follow a gap then the fourth byte can logically be 'P' or 'W'. If the 'cycles' follow other cycles then the fourth byte will logically be 'W'. This chunk never offends the general rule that the stored waveform consists only of gaps and pulses joined at zero crossings, and never creates an external or internal phase change. The UEF is encoded with eight 'cycles' per byte. Slow cycles (at the base frequency) are denoted by 0 bits. Fast cycles (at twice the base frequency) are denoted by 1 bits. Bits are ordered such that the most significant bit represents the first cycle on the tape. Spare bits in the last byte should preferably be 0 bits. When the number of cycles is 1:Only one of the fourth and fifth bytes may be 'P'If the fourth byte is 'P' the fifth byte must be 'W' but has no relevanceExamples: The sequence of cycles LSLLLSSLSSLLSL will be stored as &0E, &00, &00, 'W', 'W', &9D, &2C. A sequence following other cycles having only 1 short pulse will be stored as &01, &00, &00, 'W', 'P', &00. A sequence following a gap having only 1 short pulse followed by 3 long waves will be stored as &04, &00, &00, 'P', 'W', &0E. PSEUDO-CODE (NB: see phase notes at head of document) let NumCycles = number of stored cycles, the first three bytes in chunkread the first bit from the chunkif fourth byte of the chunk is an ASCII 'P' then output a single high pulse of the frequency implied by the bit just read, read new bit from chunk, decrement NumWaveswhile NumWaves > 1 read next bit from chunkif it is a zero, output a single cycle at the base frequencyif it is a one, output a single cycle at twice the base frequencydecrement NumWavesif NumWaves is equal to 1 if fifth byte of chunk is an ASCII 'P' then output a single low pulse of the frequency implied by the final bitelse fifth byte of chunk must be an ASCII 'W' so output a single cycle of the frequency implied by the final bit

[arkadiuszmakarenko]

A note on this parity chunk from what I have discovered :- 7e2 = &01 7o2 = &05 7e1 = &09 7o1 = &0D 8n2 = &11 8n1 = &15 8e1 = &19 8o1 = &1D

I have been playing around with some files with parity, and found something very interesting out which maybe the cause of confusion with parity. I wrote a file with 4 blocks 1st 8N2, 2nd 8N1, 3rd 8E1, 4th 8O1, And I can read them back in on the BBC with another program I wrote, now comes the interesting part when I take the wav file and process it with makeuef. I have to use the following switches to create a successful UFE file :- makeuef -i paritytest.csw -w 0 180 -z 1 8n2 -z 2 8n1 -z 3 8o1 -z 4 8e1 as you notice I have to switch the parity for 8E1 8O1 for a successful decode see the log :-

Not sure if the problem is in CSW or makeuef but someone seems to have made an error along the way and switched the two parity’s 8E1,8O1 around.

Peter are you sure it is about Chunk &0114 - security cycles ? Not Chunk &0104 - defined tape format data block?

Security Chunks are just like 5 byte long, they contain very little data?

Arek

--

[arkadiuszmakarenko]

There is no need to implement this. Replacing with low signal works fine. This project do not produce exactly the same tape, but working equivalent. Which should be fine.

[PeterBBCUser]

but if you want to use this to convert BBC tapes it does not work with some of the special copy protected tapes. But was only to bring it to others attention, besides PlayUEF works 100% for both BBC and Electron and can also be used to convert UEF toWAV.