To: ballyalley@yahoogroups.com From: ballyalley@yahoogroups.com on behalf of Paul Thacker Sent: Sat 8/14/10 7:05 PM Subject: 300 baud archiving status I don't know how many have been waiting with bated breath for news about 300 baud Astrocade programs, but I figure it's time for an update. When last we left off, Ronaldo had discovered a very useful tool for cleaning up recordings- -Casio Utilities. We e-mailed back and forth with the author, Marcus van Cube, and he gave a few explanations and made a few improvements. I believe we've reached the point now where, while Marcus is still available to answer questions, any further improvements will need to be done by the Astrocade community. The current version of the program can be downloaded here: http://www.mvcsys.de/download/casutil.zip The official documentation is here: http://www.mvcsys.de/doc/casioutil.html#mozTocId83898 Adam, this would be a good thing to add to the Astrocade Tape Archive Tools page. It's GPL, so there should be no problem with distribution as long as the source code and license is included. So, how do you use this program for Astrocade recordings, you may ask? Two utilities are useful for Astrocade recordings--wav2wav, and wav2raw. These should work with any recordings using the Kansas City Standard. wav2wav makes a direct bit-for-bit copy of the original, just cleaned up into square waves so it should load and compress more easily. This is great for keeping exact timing intact. wav2raw is slightly more processed, recovering the data bytes. From this, you can get a .prg/.bin file which could be converted to the actual source code by Ronaldo's tools. wav2raw should be used as follows: wav2raw.exe -b -PN1 -i input.wav output.bin -b means we're decoding data bytes. -i means to ignore parity and framing errors (the Astrocade doesn't even use parity). -PN1 means one stop bit. There are also two relevant environment variables. You would set these from the command prompt before running the program. WAVE_PHASE can be either 0, for standard, or 1 to invert the wave pattern. I seemed to have better luck with 1, but it's worth trying both ways. set WAVE_PHASE=1 WAVE_THRESHOLD determines the sensitivity to amplitude changes. The core part of the program is determining when the amplitude crosses the center line of the waveform. But maybe it just goes a little above or below it. If it's too sensitive, it might be affected by random noise. If it's not sensitive enough, it might miss real data. The values vary from 0 to 100, with higher numbers being more sensitive. I had good luck with set WAVE_THRESHOLD=75 but this will vary from recording to recording. There's not much to using wav2wav: wav2wav input.wav output.wav Keep in mind that you can still vary WAVE_PHASE and WAVE_THRESHOLD, though. So, with that in mind, what are some of the problems we run into with 300 baud recordings? If you zoom in on a waveform, you'll hopefully see a regular almost square wave pattern, with repeating patterns of either eight waves at a 2400 Hz frequency or four waves at a 1200 Hz frequency. The worst thing that can happen is a dropout. The pattern just breaks down at some point, becoming either silence or random noise. There's a bit of redundancy built into the Kansas City Standard, but if a dropout goes on for very long, data loss is inevitable. Bothersome, but more manageable, is amplitude variation, where the tape will be quiet in some areas and loud in others. This is where the WAVE_THRESHOLD comes in handy. If the tape is warped, you can also see it speeding up and slowing down, affecting the frequencies. The utilities seem fairly robust against this, but it's something to keep in mind. Probably the most important problem we noticed was bias. The ideal waveform will be exactly centered, with the high amplitudes rising and the low amplitudes falling by the same amount. But some recording didn't look like this at all. We could see the amplitude rising and falling, but it would be off center. Sometimes, in fact, peaks would never rise above the center, or troughs would never fall below the center. This might occur in a low frequency wobbling pattern. You could see the high frequency amplitude variation of the data pattern, but imposed on this would be a lower frequency pattern slowly moving the entire waveform up and down. I credit Marcus for finding an easy way to counteract much of this effect--a high-pass filter. A high-pass filter lets high frequency variation (the data pattern) pass through, but filters out lower frequency variations (the wobble). One tape we saw lots of wobble on is a collection by Super Software. By using Audacity to apply a high-pass filter of 2400Hz to the recording before using the utilities, I got dramatically improved, and sometimes flawless results. For examples, this: . SUPER CRAPS 1 . 2 . 3 . BY ROB ROSENHOUSE 4 . FOR SUPER STEP ?RE 5 . 6 . (C) 1980? 7 . 8 . 9 :RETURN ;NC=2a0;F?.? ??"# ERS (1 20 K=KP-48;??1)+(K>4)GOTO 20 30 ?T=3;MU="Q";NT=0;FOR A=1;@(A)=50;NEXT A 40 100 FOR K;CY=-8×;CX=PRINT "PLA#2,?@(A 2-8×K-7STEP -8;CY=Z to this: . SUPER CRAPS 1 . 2 . SUPER CRAPS 3 . BY ROB ROSENHOUSE 4 . FOR SUPER SOFTWARE 5 . 6 . (C) 1980 7 . 8 . 9 :RETURN ;NT=0;BC=240;FC=174;CLEAR 10 CY=0;PRINT "# OF PLAYERS (1-4) 20 K=KP-48;IF (K<1)+(K>4)GOTO 20 30 NT=3;MU="Q";NT=0;FOR A=1TO K;@(A)=50;NEXT A 40 CLEAR 100 FOR A=1TO K;CY=-8×A-7;CX=-70;PRINT "PLAYER ",#2,A,;CX=26;PRINT @(A);NEXT A So, where do we go from here? For one thing, I think it's time to start (gradually) cleaning up the recordings we've already got. We can get easily loadable, massively compressible files, and extract the source code to .txt files in the process. (Volunteers definitely welcome.) In addition, I've got a lot of 300 baud tapes that either I had problems with before or I haven't looked at at all. This is definitely a good time to put some more effort into those. Looking ahead, perhaps there will be an opportunity to improve the tools to recover even more data. Sometimes, the tools just stop at a certain point in the recording. I'd like it to skip ahead until it could start processing again, and tell me the exact time in the file that it retrieved every character. This way, we could really hone in on the problem area, and see if it was possible, either through examining the .wav file or the BASIC code, to determine what should have been there. Perhaps even the automated processing has room for improvement. Paul