Better Tape handling suggestions for Oricutron

[Twilighte]

One of my main concerns with Oricutron is its current handling of Tapes.
Personally i liked the Euphoric method (although seemingly a little convoluted) that allowed me to

Code: Select all

CLOAD"TOLTOP":CLOAD"TOLGAME".

However the current (0.5) version of Oricutron does not permit this.

One problem seems to be that the level above the operating system has no way of knowing what the required tape file is. It means the current directories tape file headers being sent in succession until the Tape routine recognises a filename that was enclosed in quotes in the CLOAD argument.

A further problem seems to be that whilst i can attach a tape file it is not a permanent attachment. I can CLOAD the file but when i reset Oricutron the tape file is lost. ie. If i CLOAD the file again it gets stuck in Searching..

The only current way of correcting this particular scenario is to place the tape filename after the oricutron exe in the command line and then rebooting oricutron each time i want to retry the tape file.

Would it make sense to reserve the Tape option in the menu to select the tape directory (by default being Oricutron/Tapes)?
Then CLOAD"" will load the first tape file in the directory (on first bootup of Oricutron), any subsequent CLOAD"" will load the next tape file.
A CLOAD"Gumball" will run through the current tape directory until a matching filename is found. If not found the emulator would keep looping round on the current tape directory (Not ideal but compliant with real oric behaviour).

For the first scenario i wrote above CLOAD"TOLTOP":CLOAD"TOLGAME" will work so long as both files exist in the selected (or default) tapes directory.

If the CLOAD after the first contains the same filename as previous it suggests a multi-file tape file and the next section should be loaded.
Not sure if the standard Tape file format supports this but it makes sense.

CSAVE could perhaps be a simpler schema, in that it would save the supplied filename to the current tape directory.
However if the file already exists, then it should overwrite the current version and if CSAVE "" then it should generate BLANKxxx.TAP where xxx is a sequence number for the next unused BLANK file.

There are many other scenarios, some of which may not be well supported by this format. Please comment but also please keep in context with this forum thread

[Dbug]

I guess the main issue here is how to "emulate" a number of concepts in one single feature:
- the fact that we have many "tape" files
- the fact that a tape file can contain one or more records
- the fact that records may or may not have names
- the fact that an oric can load records without having to specify a name
- the fact that a tape physically memorizes the current position (so if you keep doing CLOAD"" or CSAVE"" you always append, never overwrite).

The typical Euphoric implementation is basically a filename based jukebox.

When I launch Euphoric and type CLOAD"INVADERS" what really happens is that Euphoric intercept the name, try to find a "invaders.tap" file on the host machine, open the file, and then try to load the first file in it.

Older versions of Euphoric behaved differently of more recent ones, and one casualty is my very old 1997 demo that was exploiting the implementation by having a number of files (demo.tap, plasma.cod, logo.hir, ...) loaded from the demo itself, assuming the emulator would find the correct thing to load. This demo does not work anymore on either Euphoric or Oricutron.

I'm not sure it's possible to find an universal way of dealing with all the possible problems, I'd say we could have some kind of hybrid system:

- have the GUI always display the currently inserted tape file, plus an indication of the position on the tape (and perhaps make it possible with some keyboard short-cut or menu to select the position in the file by going to the start, to the end, or positioning on a particular record in the tape file)

- if the user has chosen a physical file to use, either as a parameter on the command line, or by inserting a tape in the menu, then the emulator is not allowed to try to be smart and find a tape itself if the filename does not match: Just use the name between quotes as something to find relative to the currently selected tape file: If I tape CLOAD"", then search and load the next file on the tape, or keep SEARCHING if there's nothing. If I tape CLOAD"INVADERS", and there is no INVADERS file on this tape - just fail, even if there is an INVADERS tape file in the folder.

- if the user has not chosen a physical file to use, then allow the CLOAD or CSAVE quoted name to be used a a physical tape file name, find the file, open it, and then load the first file found on the tape (as a CLOAD""), if it was a CSAVE then it's probably worth saving the record with the specified name.

An additional idea could be that Oricutron should lock the tape file ONLY if the tape is being accessed (ie: the remote relay is active), this would allow any external script, backup, patcher to modify the file. Of course Oricutron should still remember the position on the tape (at least during this session).

For the particular problem of Twilighte with the reset, I guess an option to automatically rewind a tape when resetting could be good idea.

Not sure if that all makes sense, would like to have many people opinions, because having a good CLOAD/CSAVE system is important, and the choices made there are going to impact everybody.

[Xeron]

I've just checked some improved code into the SVN for oricutron, but i've not tested it yet.

If you have tape autoinsert enabled and you type:

CLOAD "FOO"

it uses the following logic:

* If there is a tape inserted, and we're not at the end of the tape, it lets the ROM try and load FOO from the current tape.

* If there is no tape inserted, or we're at the end of the current tape, it tries to load the first file from a tape image called "FOO" in the tape directory. If "FOO" does not exist, it tries again with "FOO.TAP"


If you had typed in:

CLOAD "FOO.TAP"

it doesn't care if there is a tape already inserted, it tries to load the first file from the tape image called "FOO.TAP" in the tape directory.

[Dbug]

Looks like it may actually work, will have to check that with my old tape based demo so I can finally make a movie of it and forget it forever

[Xeron]

I'm already trying to get that demo to work. I've got it to the point where LOADER.COD successfully gets BLOOD.HIR inserted, but fails to load any files from the BLOOD.HIR image. I hope to get this demo working eventually.

[Xeron]

Hmmm.. your demo does something very odd. LOADER.COD calls the ROM routine to read the file header of the file BLOOD.HIR. Once the header is in memory, it changes the start address from $a000 to $6000, but it doesn't modify the end address, then it calls the ROM routine to read the file into RAM, but of course, its trying to read $4000 extra bytes now, so the tape gets to the end and the ROM waits forever for more bytes.

I don't know how this ever worked!

Here is how i'm debugging it, if you want to follow my steps (with current SVN code):

1) Load Oricutron. Set a breakpoint for $E4AC (read file header)
2) Insert LOADER.COD via the "Insert tape..." menu option (this changes the current tape dir to the demo dir and allows autoinsert to work)
3) Type CLOAD""
4) When the debugger pops up, press F2 to quit it. LOADER.COD will now load and try and load BLOOD.HIR.
5) When the debugger pops up, trace through the load header routine with F11 until it gets to the RTS at $E4DF.
6) Inspect the header at $2a7. The start address is at $2a9/$2aa ($a000), and the end address is at $2ab/$2ac ($bf40).
7) Execute the RTS instruction, and you'll be back into the code from LOADER.COD. It modifies the start address at $2a9 to $6000, then jumps back to the ROM to read the file, which now never returns.

It doesn't matter if you use turbo tape or not; the ROM tries to read more data than is in the tape image. I have no idea if Oricutron is doing anything wrong, or why it ever worked in Euphoric. I'm hoping that because you wrote the code, you can figure out what is happening, and what should happen

[Xeron]

OK, I can confirm that the new auto-insert code works with the oric megademo. I put a bodge in the turbotape code where instead of giving up at the end of the tape image file, it just returned the last byte over and over again until the ROM code stopped asking for bytes from the tape. The demo then runs fine, but I really don't want to leave this bodge in place for two reasons:

1) It only fudges the problem and makes your demo work with turbotape mode. Real tape emulation won't work with the demo.

2) If the demo works on real hardware if you saved all the tape files to a tape one after the other, Oricutron is doing something wrong, and the bodge does not fix the problem.

[Xeron]

Well, if I adjust the load and end addresses in the header of the ".HIR" tape files, it works in Oricutron without any bodges...

[Dbug]

Good catch for the end address, explains why I could not manage to get it to run at all, so just fixing the end address would possibly make it run on a recent Euphoric as well.

For my defence, I wrote that in 1997, and the only thing I had to test it was Euphoric back then, and it accepted the code

Code: Select all

_LoadFlag	BYTE	0
_LoadAdress	WORD	0

_DoLoad
	php
	jsr $e76a ; prepare le via pour la lecture cassette
	jsr $e57d ; facultatif : si tu veux afficher "searching..."
	jsr $e4ac ; lis l'en-tete
	lda	_LoadFlag
	beq	continue_load
	lda	_LoadAdress
	sta	$2a9
	lda	_LoadAdress+1
	sta	$2aa
continue_load
	lda	$2a9
	sta	run_patch+1
	lda	$2aa
	sta	run_patch+2
	jsr $e59b ; facultatif : si tu veux afficher "loading ..."
	jsr $e4e0 ; le chargement effectif
	jsr $e93d ; restaure un etat correct du via
	plp

	lda	$2ad		; Si 0, pas de d‚marrage automatique
	beq	quitte_load
run_patch
	jsr	$1234

quitte_load
	rts