Turbo Cassette

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
8bitkick
Posts: 68
Joined: Thu Aug 11, 2016 4:45 pm
Location: California
Contact:

Re: Turbo Cassette

Postby 8bitkick » Mon Oct 30, 2017 3:09 am

davidb wrote:
BigEd wrote:Have you tried arranging for a shorter than normal stop bit? It could only gain 5% so perhaps isn't worth it. (If the stop bit is detected half way through the bit time, you can possibly follow it with the start bit transition earlier than you normally would.)

I have no idea how you'd arrange to do it, mind.


Good suggestions - only a small modification on PlayUEF and it works fine. Replaced the normal stop bit (2 cycles of 2400Hz, same as a 1 bit, in blue) with just 0.5 cycle (new stop bit is in red in diagram).

Image

This plus David's suggestion of minimal interblock carrier tones has taken >20% off at 1200 baud. I have parameterized this as one option, TURBO=1, in the URL to the javascript. https://s3-us-west-1.amazonaws.com/8bitkick/PlayUEF/PlayUEF.html?TURBO=1

You can also increase base frequency, whilst keeping the integer gaps and file start carrier tones constant (for compatibility with Jet Set Willy and other games that use tape timing during load). Needed to tweak phase for 1570Hz to work, but I've got Arcadians 37% faster down to 150 seconds!

Suspect with the baud/phase tweak YMMV and I'd appreciate any feedback on limits on other Elks.

https://s3-us-west-1.amazonaws.com/8bitkick/PlayUEF/PlayUEF.html?TURBO=1&BAUD=1570&PHASE=220

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Mon Oct 30, 2017 2:14 pm

Commie_User wrote:Is there some way to port the tape data to digital storage via the Electron serial, so you can flood it back in through a modem socket or something?

The Electron doesn't have a modem socket, otherwise we'd already be trying to find ways to misuse that. ;)

At some point I'd like to improve my programs for cassette I/O to do more fine-grained bidirectional communication via the cassette port. I think that would open the door to using things like modems without too much additional hardware, but that's a topic for another thread. :)

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Mon Oct 30, 2017 2:45 pm

If you're willing to transform UEF files on the fly so that they contain simple decompression code and compressed files then you could make more savings.

For example, you only need the second file in Arcadians and this can be compressed to around 80% of the original size (15 fewer blocks) with a simple compression scheme. If the decompression program is only a couple of blocks long, there's still a net saving. Of course, if you start to throw away things like loading screens then you'll make even more savings. :)

User avatar
8bitkick
Posts: 68
Joined: Thu Aug 11, 2016 4:45 pm
Location: California
Contact:

Re: Turbo Cassette

Postby 8bitkick » Mon Oct 30, 2017 4:44 pm

davidb wrote:If you're willing to transform UEF files on the fly so that they contain simple decompression code and compressed files then you could make more savings.

For example, you only need the second file in Arcadians and this can be compressed to around 80% of the original size (15 fewer blocks) with a simple compression scheme. If the decompression program is only a couple of blocks long, there's still a net saving. Of course, if you start to throw away things like loading screens then you'll make even more savings. :)


Making UEF of compressed data on the fly - and inserting decompression code upfront - is totally doable! Metadata per game would likely be necessary to handle exactly what files are loaded/discarded and where the loader resides though :? I guess removing the loading screen and keeping it there might be an option in some cases!?

Can you point me to the code for the decompression routine / algorithm for compression? I will investigate this route.

I'd like it to be generic / automated enough to work with the 800 titles....The carrier tone & stopbit optimizations are now an option in the player and can be applied to the whole STH UEF archive with one switch =D>

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Mon Oct 30, 2017 5:42 pm

8bitkick wrote:Making UEF of compressed data on the fly - and inserting decompression code upfront - is totally doable! Metadata per game would likely be necessary to handle exactly what files are loaded/discarded and where the loader resides though :? I guess removing the loading screen and keeping it there might be an option in some cases!?

I suppose so. I thought it might be possible to load a routine into memory at the start of the "cassette" then insert small programs between the files to load the data, call the decompression routine and optionally run the original code.

Arcadians isn't a good example because it uses an annoying loader that makes loading the main game fairly opaque, but a reasonably well behaved program like Killer Gorilla might change the file order from this

Code: Select all

KG1
KG2
KG3

to this

Code: Select all

DECOMP
KG1 (wrapper to load the next file, decompress it and run it)
KG1
KG2 (wrapper to load the next file, decompress it and run it)
KG2
KG3 (wrapper to load the next file, decompress it and run it)
KG3

The wrappers all use the same file names as the original files so that, for example, *RUN KG2, in KG1 will still work but will actually load the KG2 wrapper which will actually perform the task of loading the real KG2. Unfortunately, this won't work if the original program just does a *LOAD on a file. I suppose if a game loader doesn't actually use the loaded data, merely loading it in pieces, then a later wrapper could include code to decompress earlier compressed files as well as the one it is expected to handle for itself.

8bitkick wrote:Can you point me to the code for the decompression routine / algorithm for compression? I will investigate this route.

I wrote this to transform UEFs to ROMs. It's just an accumulation of code but the decompression routine is fairly simple. Others, like tricky, have written their own routines that may well perform better.

The MGC ROM Recipes repository contains recipes for games that can be converted to ROM for systems like the Mega Games Cartridge. Not all games, but many that are worth playing. :)

User avatar
vanekp
Posts: 345
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands

Re: Turbo Cassette

Postby vanekp » Mon Oct 30, 2017 7:20 pm

I failed to get the UEFtoROM to work under Python, I get the following :-
C:\Python27>Python uef2rom.py frakv11_b.uef test.rom
2 bytes of workspace used.
'ophis' is not recognized as an internal or external command,
operable program or batch file.
Do I need a different version of Python to run it?
Peter.

User avatar
8bitkick
Posts: 68
Joined: Thu Aug 11, 2016 4:45 pm
Location: California
Contact:

Re: Turbo Cassette

Postby 8bitkick » Mon Oct 30, 2017 7:29 pm

vanekp wrote:I failed to get the UEFtoROM to work under Python, I get the following :-
C:\Python27>Python uef2rom.py frakv11_b.uef test.rom
2 bytes of workspace used.
'ophis' is not recognized as an internal or external command,
operable program or batch file.
Do I need a different version of Python to run it?
Peter.


Not the expert, but check the Orphis 6502 assembler is installed and path set correctly

https://bitbucket.org/dboddie/uef2rom/src/1c9dd5ba8d0aecf4573ef2a5328e2f7211c55838/README.txt?at=default&fileviewer=file-view-default

https://michaelcmartin.github.io/Ophis/

User avatar
vanekp
Posts: 345
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands

Re: Turbo Cassette

Postby vanekp » Mon Oct 30, 2017 8:12 pm

Thanks...got over that hurdle now on to the next one lol, I get a lots of switches i can use but have no idea where to start :-
C:\Python27>uef2rom.py frakv11_b.uef
Usage: C:\Python27\UEF2ROM.py [-f <file indices>]
[(-m [-M <custom routine oph file> <custom routine label>]
[-I <custom routine oph file> <custom routine label>])
| ([-p] [-t] [-T] [-w <workspace>] [-l])]
[-s] [-b [-a] [-r|-x] [-B <boot file>]] [-c <load addresses>]
[-P <bank info address> <ROM index>]
<UEF file> <ROM file> [<ROM file>]

The file indices can be given as a colon-separated list and can include
hyphen-separated ranges of indices. Additionally, a special value of 's' can
be used to indicate the end of a ROM, so that files following this will be
added to a new ROM.

The first ROM image can be specified to be a minimal ROM with the -m option.
Otherwise, it will contain code to use a persistent ROM pointer.
The second ROM image will always be minimal, but can be specified to use a
persistent ROM pointer if the -p option is given and the first ROM is not a
minimal ROM.

If a minimal ROM image is not used, the -t option can be used to specify
that code to override *TAPE calls should be used. Additionally, the -T option
can be used to add code to trap filing system checks and always report that
the cassette filing system is in use.

The workspace for the ROM can be given as a hexadecimal value with the -w option
and specifies the address in memory where the persistent ROM pointer will be
stored; also the code and old BYTEV vector address for *TAPE interception (if
used) and the code and old ARGSV vector address is filing system checks are
intercepted. The workspace defaults to a00.

If you specify a pair of addresses separated by a colon (e.g, d3f:ef97) then the
second address will be used for the BYTEV vector address.

The -l option determines whether the first ROM will be read again after the
second ROM has been accessed. By default, the first ROM will not be readable
to ensure that files on the second ROM following a split file can be read.

If the -s option is specified, files may be split between ROMs.

If the -b option is specified, the first ROM will be run when selected.
Additionally, if the -a option is given, the ROM will be made auto-bootable.
If the -B option is also specified, the PAGE for subsequent BASIC programs
can be specified as a hexadecimal number.

The -r option is used to specify that the first file must be executed with *RUN.
The -x option indicates that *EXEC is used to execute the first file.

The -c option is used to indicate that files should be compressed, and is used
to supply information about the location in memory where they should be
decompressed. This is followed by colon-separated lists of load addresses,
themselves separated using slashes.
The -P option causes code to be included that writes to the paging register
at 0xfc00. The code reads from the bank info address specified to obtain a base
page number and adds the specified ROM index (base 10) to it in order to swap
in the ROM from the resulting bank number.
The -M option allows a custom piece of code to be used to respond to the star
command that is otherwise not used for minimal ROMs.
The -I option is like the -M option except that the custom code is not
as a star command and will be run before any other initialisation
code that may also be inserted into the ROM by other options.

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Turbo Cassette

Postby davidb » Mon Oct 30, 2017 9:38 pm

Try this to start with:

Code: Select all

uef2rom.py frakv11_b.uef frak1.rom frak2.rom


Return to “software: other”

Who is online

Users browsing this forum: grobda and 5 guests