Quadbike 2: Tape Transcriber

[Diminished]

New version of tibetuef.php (0.5):

tibetuef-0.5.php.zip

(13.78 KiB) Downloaded 24 times

This fixes a bug which occurs in 0.4 if:

a) 300 baud data is used, and
b) this 300 baud data is marked with a /baud 300 hint in the TIBET file, and
c) chunk &114 is abused to encode the data.

In the above situation, 0.4 would mis-encode the data as 1200 baud data instead. It should now work correctly.

[Diminished]

Latest edition of "tools which really should have been written 15 years ago".

mktibet-0.1.php.zip

(3.96 KiB) Downloaded 27 times

This PHP script will let you select files from the local filesystem and package them up into a MOS tape, which is saved as a TIBET file. From here, you can process the TIBET with tibetuef.php to get a UEF file.

I wrote this quickly for a specific 300 baud test I needed to conduct, so it is basic, and there are a lot of features missing. For example, you can't currently change the lengths of leader tone between blocks and files. Still, if you need to build an arbitrary tape image from locally stored files, this may be the only way to do it right now.

Code: Select all

Usage:

  php -f mktibet-0.1.php +t <output TIBET> [opts] <file1> [opts] <file2> [opts] <file3> ...

where each per-file [opts] may be:

  +x <hex>        specify execute address for next file
  +d <hex>        specify load address for next file
  +b <1200|300>   specify baud rate for next file
  +n <filename>   override MOS filename for next file

[Diminished]

Updated tibetuef.php (0.6):

tibetuef-0.6.php.zip

(13.58 KiB) Downloaded 13 times

This adds the option +no-117, which prevents tibetuef.php from emitting the baud change chunk &117. (This chunk currently upsets Elkulator, since the Elk has no 300 baud capability.)

[Diminished]

Updated tibetuef.php (0.7)

This fixes some problems with empty chunks being generated when testing with a very long (~6 hour) concatenated TIBET source. (Yes, you can concatenate TIBET files to produce entirely valid new TIBET files).

"Empty chunks" in this case means "correctly formed, but with a data length of zero". The b-em tape overhaul I have been working on has more aggressive sanitisation of UEF files, and is now rejecting these void chunks; tibetuef.php 0.7 should no longer generate such chunks (hopefully).

tibetuef-0.7.php.zip

(14.56 KiB) Downloaded 16 times

[Diminished]

Updated mktibet.php to 0.3.

There is a bug (or, very charitably, a "feature") in BeebEm by which it won't start loading a tape until primed with at least one zero bit. Going from pure leader tone directly into the first file will cause the sync at the start of block 0 to be missed. In real-world files saved with MOS 1.2, the CFS bugfix in the OS will inject a dummy &AA byte before any valid data, so this bug is not triggered. However, custom UEFs built from e.g. tibetuef.php fall foul of this (but beebjit and my patched B-Em are unbothered; real hardware does not need a priming &AA byte).

By default, then, mktibet 0.3 will now prepend a dummy &AA byte flanked by leader tone before the start of every file (unless disabled with the new per-file +no-dummy option).

mktibet-0.3.php.zip

(4.25 KiB) Downloaded 7 times

[vanekp]

yes that has always been a problem with tape files that have no sync &AA at the start I quite often then just edit the UEF manually and add in my own &AA otherwise you have to mess around rewinding the tape to get it to load, so a handy feature.