New version of tibetuef.php (0.5):
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.
Quadbike 2: Tape Transcriber
- Diminished
- Posts: 1252
- Joined: Fri Dec 08, 2017 9:47 pm
- Contact:
- Diminished
- Posts: 1252
- Joined: Fri Dec 08, 2017 9:47 pm
- Contact:
Re: Quadbike 2: Tape Transcriber
Latest edition of "tools which really should have been written 15 years ago".
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.
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
- Posts: 1252
- Joined: Fri Dec 08, 2017 9:47 pm
- Contact:
Re: Quadbike 2: Tape Transcriber
Updated tibetuef.php (0.6):
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.)
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
- Posts: 1252
- Joined: Fri Dec 08, 2017 9:47 pm
- Contact:
Re: Quadbike 2: Tape Transcriber
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).
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).
- Diminished
- Posts: 1252
- Joined: Fri Dec 08, 2017 9:47 pm
- Contact:
Re: Quadbike 2: Tape Transcriber
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).
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).
Re: Quadbike 2: Tape Transcriber
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.
Regards Peter.