I finally got time to try out these Python scripts. SHORT VERSION: They worked
So here goes my story...
I was trying to understand what happened to Wheel of Fortune 1. We still enjoy playing Wheel of Fortune 2, as it works with CGA and 256KB RAM systems. I'm still trying to understand how, by 1988, WOF2 was still a CGA game. WOF3 finally went EGA, but still neglected any Adlib/SB support (and anyhow runs too slow for my 4.77mhz, so we stick with WOF2).
Apparently there WAS an earlier WOF from 1987, from Sharedata - with roughly the same gameplay/style as WOF2, but even WORSE (more orange) graphics. So, WOF2 is the best.
And then.... I came across what I will call WOF0. The "original" 1984 "text-based" WOF written by Phil Katz (yes, of PKZIP). And it was written in BASIC.
So then it hit me: what a perfect time to test this BASIC to WAV conversion Python script. Which, incidentally, I knew this WOF0 wouldn't run from ROM BASIC -- because it references an external file to get all the categories and puzzles. This .BAS was intended for use by BASICA.COM. Still, it is basically just a text file, so I decided to try it out.
So here we go:
(and yes, I installed Python 3....)
F:\IBMPC\GAMEs\WHEEL_OF_FORTUNE\WOF0>asciiwrite.py fortune.bas test.wav
255 bytes written.
510 bytes written.
...
7650 bytes written.
7905 bytes written.
End of file reached.
8103 bytes written. <-- this checks out, that's the size of the BAS file.
(this resulted in a 11.5MB WAV file)
Then, while I was at it, I also decided to try the same experiment I did with 5150caxx and use the other script to write PTROOPER.COM.
(to keep example simple, I previously copied the PTROOPER.COM file into this same WOF0 working directory)
F:\IBMPC\GAMEs\WHEEL_OF_FORTUNE\WOF0>binwrite.py ptrooper.com ptrooper.tap 0 0
Silence finished at 0:00:03.496636
Basic header finished at 0:00:04.809484
Written bytes: 256
Written bytes: 512
Written bytes: 768
...
Written bytes: 16128
Written bytes: 16384 <-- ok, checks out, same size as the .COM file
Finished at 0:01:48.548295
(this resulted in a 7.8MB WAV file)
I then brought the TRS-80 cassette recorder to the (modern) PC. Double checked things, it was recording the WAV files out of the headphone jack just fine.
SIDEBAR:
krebizfan
While I was at it, I decided to also record the two WAV files archon11k25.wav and bdash11k25.wav that were referenced
here
Basically, quick story on this is that neither of these two WAVs worked for me. ROM BASIC just said "Device Error" when trying to load. When I inspected the raw data using 5150caxx, it just loaded a 256 byte header and said there was some CRC error (and this header didn't look quite right to me). Are these PCjr-only games? (although I wouldn't expect the ROM BASIC for the PCjr to not really be different - in terms of how BASIC loads and saves; I'd understand if the game didn't run, but it still should have loaded something). Anyhow, no luck for me on these particular WAV files.
Results:
(#1 PTROOPER binary)
So... I tried loading PTROOPER first, from the WAV recording created by
binwrite.py. I was bummed because at first it didn't work. I even loaded the binary package using 5150caxx, and it reconstructed the .COM just fine. So I felt like the data was there, it was very close.... Then I figured it out: I was loading at offset decimal 100 instead of hex 100 (i.e. should have been loading at offset decimal 256).
So, upon creating the WAV using Python, and physically recording it to a tape at 1:1 real time playback.... Then here is what I had to do, to load that binary back using ROM BASIC:
def seg=&H2000 ' I just picked a segment, I'm not sure if it really matters which one
bload " ",256 ' this is where I went wrong, I was using ,100 instead of ,256
(press play on tape, wait for ptrooper.M to be found)
A=256 ' set some variable to the starting offset ($100 or &H100 or 0x100 = decimal 256, for most .COM programs)
call A
Brilliant, this is essentially how we do it on the Commodore PET from '77
(just in the PET the command is SYS instead of CALL).
Boom! It passed execution to the binary that was loaded into memory, and Paratrooper was up and running via ROM BASIC loaded from a tape. That's a bit exciting, except I have to say that I still like the 5150caxx 32-byte pre-loader a bit better (just avoids having to do a CALL).
(#2 fortune.bas)
Next I tried the FORTUNE BASIC program that was recorded to the tape via the WAV created by the
asciiwrite.py script (sorry, I still call them scripts, not programs
).
And that worked too! I can tell you, for sure I didn't type this ~200 lines of BASIC myself. As expected, it didn't run - LINE 40 works, that's about it. It does an OPEN statement right after that, so the program eventually just times out ("Device Not Found" or something). So that's pretty cool too.
Only observation I have is: while loading the BASIC program, the Cassette relay clicked quite a few times - is the program saved in "chunks" of like 500 bytes? Not sure if there was any actual pause in the playback, but I could certainly hear the clicks.
So that's pretty neat, Python to make WAV files that are recordable and loadable.
5150caxx is a little more "seamless" in that it can encode a file directly to tape, pre-fixed with an appropriate "pre-loader" so you don't really have to think about how to load it -- you just do load " ",r and go. And that it runs directly in "real-mode" as a DOS program (essentially use the BIOS ROM as its API for doing the actual audio output). I'm up to about 20 .COM programs recorded to tape and verified reloadable from tape.
I guess only one thing left for me to try: will it load using my iPhone as playback instead of that massive TRS-80 tape deck?
Need to find a place to host a 10MB WAV file, hmm....
EDIT: Answer, yes it does (load when playedback from phone). WAV is hosted
here until I'm forced to move it. Don't need a DOS, just x86 it up and go
