News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_CraigsBar

Breaking Baud on actual tape. Has anyone managed this?

Started by CraigsBar, 20:02, 02 April 18

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mr. DVG

I also tried to get a physical copy from the .wav file I found on this thread, but the real test on a CPC 464 was not successful.  :(

I state that as indicated, the audio recorded on tape is very high, and the tape used is a TDK practically new, but after loading the first block the demo does not proceed...  :'(
There is someone who really managed to to run this demo on a 464? And if so, how did you make it happen?

Thanks to all those who will answer!  :)

remax

Quote from: CraigsBar on 11:40, 19 March 19
I'll try it on my tzxduino tonight, I have got it working once before on a car cd tape adaptor and a pc playing a WAV

Sent from my ONEPLUS A3003 using Tapatalk


I think that was the first thing i tryed with mine and it worked. (but on a 6128)
Brain Radioactivity

CraigsBar

Quote from: roudoudou on 15:59, 27 January 19
I found a tape deck workingunfortunatelay, BB did not work, only the loader is workingi tried with differents recording levelsthen i tried again with my tape replacement, failed too!  :o the level must be very important


Yeah, that is my finding too. it seems running this awesome production outside of emulation is trickier than expected. (Yes I know Smartphone or feeding the Audio through an audio tape adaptor works, but then you are emulating the tape and not the CPC. I would really really love to see this running using genuine retro hardware, including the tape deck and tape.


I know I am mad, even insane maybe, but I actually now appreciate tape loading!


Craig

IRC:  #Retro4All on Freenode

protek

I got it working on a Philips NMS 1515 but unfortunately it no longer works on that. Also my Sony recorder fails to play it properly. I probably should try to record it again from different source.

CraigsBar


I have resolved this issue. If you see elsewhere I have fitted a small signal amplifier in my 6128plus to amplify the audio in from the tape socket before it arrives on the PCB. This means I can load everything perfectly from my tzxduino first time, which was not possible before, and also load musical loaders and breaking baud which simply failed every time previously. I can also load the musical loaders from a real shoebox tape recorder at the same volume level as I use on the Cpc 6128 and no longer need to boost up the volume for the plus. A win all round.

Craig


Sent from my iPhone using Tapatalk
IRC:  #Retro4All on Freenode

protek

Good to hear you got it working, Craig.  What kind of signal amp did you use?

CraigsBar

Quote from: protek on 17:28, 14 June 19
Good to hear you got it working, Craig.  What kind of signal amp did you use?
It was a premade pcb module from China intended for Arduino projects. The chip on it is a LM358

Sent from my ONEPLUS A3003 using Tapatalk

IRC:  #Retro4All on Freenode

protek

Finally managed to get Breaking Baud to play from tape with my Sony recorder. I played the wav through the USB sound card of my headset and playing it out with enough volume did the trick.

protek

I don't know if this would be better suited on the hardware section, but since it involves the recording and loading of the Breaking Baud demo, I'll ask it here. Not all recorders, including my Sony TCM-939, have a dedicated setting for the recording level. It only has the volume setting. Does the volume setting have an effect to the recording, though? I've tried transferring the Breaking Baud demo onto tape a few times through my sound card with varying output levels, and I just don't seem to get a recording that would load consistently, when played back. Is there any point of trying to adjust the azimuth, as the tape is being played back on the same device it's being recorded with? What kind of levels are ideal for the CPC programs?

matburton

I naively tried this as well, and it didn't work.

I recorded the tape via a C64 and C2N, which normally works fine if the tape is fine.

I quickly 'played' with the .WAV of the demo, and 'stretched' it by 0.5%
Even that was enough for it no longer load in WinAPE.

Was this demo was made for emulators, or a least an idealised CPC, tape and drive that doesn't really exist?

Shaun M. Neary

I've managed it by converting the cdt file to a wav file using JavaCPC

Then playing back the wav and recording it to a cassette using one of these.
ACE | Retro Cassette Radio With Bluetooth, USB & SD | Black: Amazon.co.uk:  Electronics & Photo

I got it working on one of my CPC464's but the second one doesn't want to know at all!

Edit: Seriously? We can't copy and paste an image into a forum in 2021?!
Currently playing on: 2xCPC464, 1xCPC6128, 1x464Plus, 1x6128Plus, 2xGX4000. M4 board, ZMem 1MB and still forever playing Bruce Lee.
No cheats, snapshots or emulation. I play my games as they're intended to be played. What about you?

CraigsBar

Quote from: matburton on 14:52, 12 October 21
I naively tried this as well, and it didn't work.

I recorded the tape via a C64 and C2N, which normally works fine if the tape is fine.

I quickly 'played' with the .WAV of the demo, and 'stretched' it by 0.5%
Even that was enough for it no longer load in WinAPE.

Was this demo was made for emulators, or a least an idealised CPC, tape and drive that doesn't really exist?


It works fine when the CDT is played from a tzxduino into a cpc6128 (or any other CPC/plus with a standard CPC 6128 tape in mod) the challenge seems to be getting clean enough audio on the cassette.
IRC:  #Retro4All on Freenode

megachur

Maybe it's the tools you have used that aren't accuracy enough  :o .
Here is a wave file converted from the official cdt file with my own emulator ( 8) cpcemupower 8) ) :
Give it a try and tell me if it's works  ;D !?


pelrun

Note that recording data to tape and playing it back warps the signal, shrinking the width of the pulses by a small amount. That is probably enough to cause Breaking Baud to fail.

The CPC actually applies precompensation when recording to tape so it is close to the expected result when played back (See Soft968 section 8.3). No CDT tool does it that I know of, because the general expectation is they are played directly into the CPC skipping the tape step altogether.

Devlin

I've had this playing back off cassette before, though I used a "Type-II" cassette and recorded at a relatively high volume. Took me about 4 attempts but got there. I've had success from also playing it back using one of those cassette "mp3" adapters.
I use WinTZX 0.9a 09/2009 to convert my files.
CPC464 & CPC6128 + USIfAC II + Revaldinho 512k(universal cpld ver) - Schneider CRT TV
Administrator of Amstrad Discord : https://discord.gg/ksWvApv

matburton

Cracking open the CDT file it seems the frequency tops out a little over 11kHz!  :o

That's pretty high! I haven't seen a commercial fast loader go above about 8-9 kHz (on other platforms).

matburton

Quote from: pelrun on 07:07, 13 October 21The CPC actually applies precompensation when recording to tape so it is close to the expected result when played back (See Soft968 section 8.3)

That's really interesting. I'll have a go at applying those shifts.

That document says:

QuotePrecompensation is used  - which adds to the period of a one bit and subtracts from the
period of a zero bit to make the waveform closer to the ideal when it is read.

Do you know the amount that gets added and subtracted?

ralferoo

Hey, it's meeeee!  ;D

I've actually been thinking about precompensation again recently, and how maybe I could improve on this area.

The CDT as generated doesn't use precompensation, because I was actually overly concerned about overall tape bias that I didn't even think about it. Tape bias is the tendency for the magentism of the head to become densensitive the longer it stays in a +ve or -ve state (which correspond to 0 and 1 in the Amstrad firmware manual).

So, the encoding of breaking baud is much more like GCR encoding on disks (mostly only done on the Apple ][) rather than the normal encoding which has parallels to MFM encoding on disks (you could consider it a precursor to disk).

The standard tape encoding achieves overall zero bias by having high and low pulses of the same length (assuming no precompensation) and so this isn't an issue, but has IMHO the unfortunate side effect of variable length encoding - an encoded 1 bit is twice as long as an encoded 0 bit.

Breaking Baud does things totally differently (mostly because I'm an awkward sod). Instead, I consider a time intervals of 16 slots, each of which could be high or low, so we have 65536 possible combinations. But obviously, most of these will be totally unsuitable for tape encoding, so I only allow encodings where there are equal numbers of high and low states. There's a further complication for tape, because the tape speed isn't very reliable, so it becomes hard to tell longer periods apart. Initially, I tried a similar approach to tape loaders of doubling the time period, but whilst this is reliable for a normal loader which is doing nothing but loading, because I only sample the tape once every scan line, I'd occasionally misinterpret the length (which is almost certainly where it's falling down her). So, I settled on a long half-pulse being 3 times the length of a short half-pulse. In 16 scan-lines, this gives me 277 possible encodings that fit the scheme, which is what allows me to encode bytes at a constant rate and still have a few encodings to signal compressed data.

There's a more comprehensive write-up written when it was all still fresh in my mind:
https://github.com/ralferoo/breaking-baud/blob/master/docs/technical.txt

I don't have any CPCs out on my desk at the moment, but I might have a play with improving the CDT generation around Christmas time. Actually, I could throw out some CDTs with the proviso that I can't test them on actual tape at the moment as my CPCs are all packed away.

But in answer to the original question, it was developed using actual tape on an actual CPC from the start...


https://www.youtube.com/watch?v=qfGcvWOaFFw (very, very early, before music and palettes)

https://www.youtube.com/watch?v=0G6SX8tUDlw (early drafts of images, proof of concept for audio playback)

And, and it's not obvious, but if you get any read errors from breaking baud, you can just rewind a few seconds and it'll pick up where it had the error. You can see the read error at 2:15 in the second video where I just rewind the tape to recover.

Shaun M. Neary

Quote from: ralferoo on 11:37, 02 December 21And, and it's not obvious, but if you get any read errors from breaking baud, you can just rewind a few seconds and it'll pick up where it had the error.

This in itself is pretty mind blowing to be honest. Too bad a lot of loaders in it's day didn't support this.
Currently playing on: 2xCPC464, 1xCPC6128, 1x464Plus, 1x6128Plus, 2xGX4000. M4 board, ZMem 1MB and still forever playing Bruce Lee.
No cheats, snapshots or emulation. I play my games as they're intended to be played. What about you?

ralferoo

Quite a few of the turbo loaders that had a counter actually did support this. Each click was usually 256 bytes (as with breaking baud), although some loaders had counters every 64 bytes instead. Breaking baud was always supposed to have an on-screen counter (it maintains one internally), but despite working on it for about a year, as is usual there was a crazy rush in the last couple of weeks to finish everything in time for release at the demoparty, so that got cut!

ralferoo

Quote from: ralferoo on 11:37, 02 December 21because I only sample the tape once every scan line
Actually, this is wrong. I sample it every 31us or 32us (half a scanline or just under). I think I went with 31us in the end as the makes the border tears look more traditional (it's very weird when they are in exactly the same place on the screen)...

ralferoo

Another early video with a much higher data rate that wasn't really stable.


I forgot to mention... yellow+blue means its working, green+black means there was an error and you need to rewind.



https://www.youtube.com/watch?v=THERrApPHv0


ralferoo

I've also just found another video which shows me discovering the precompensation problem (back in 2012) when working on my FPGA emulator's tape circuit, but I don't think it dawned on me exactly what the issue was then:



https://www.youtube.com/watch?v=-GdPSnFswgk


ralferoo

And from 2011 when I was experimenting with tape loading using encodings of 3 different lengths of data at various speeds:



https://www.youtube.com/watch?v=uwRo5Pavt7g


Ultimately I gave up on this because even in this early visualisation I could see significant errors, which is why I ditched the medium length encoding, but maybe that was due to precompensation as well and I just didn't realise it.

Gryzor

Fascinating explanation even for someone non-technical, thanks!

Powered by SMFPacks Menu Editor Mod