Experimental support for Oric in exomizer

[zagon]

Hi guys! Since exomizer already supports several 6502 based 8-bit computers I thought it would be nice to add Oric to the list of supported sfx targets too.

For general exomizer info see http://hem.bredband.net/magli143/exo/

Exomizer i a cross cruncher that can generate executable files that decompress themselves in memory when run. The just released 2.0 beta 6 release can generate self extracting Oric tap files. It does not run Oric basic programs. I haven't been able to find any info about how to start a basic program from ml for the Oric platform. Anybody know anything about where to find info about this?

Now for some technical details.
The exomizer decruncher needs a 156 byte space that it uses as a lookup table. It begins by copying the decruncher code to the stack and then it generates the decrunch table. finally it decrunches the data and jmps to the target address.

It defaults the location of this table at $b800 and by default loads the crunched file to $0400. However, It will limit the decrunched data to about $0402-b800

Another option is to place the table at $0400 and load the file to $0498
However this will limit tha data to $049a-$c000

Would it be possible to store the table at page 2?
This would allow the data to cover $0402-$c000.

However the default are overrideable by flags.
Here's an example:

exomizer sfx 0x70AD -t1 -o <outfile> <infile> -Di_table_addr=0x400 -Di_load_addr=0x500

When finished the decruncher will jmp to $70AD.
the -t flag selects target computer, 1 is Oric 1.
Omitting the -D<x>=<y> options will make the decruncher use its default settings.

The outfile will be an Oric tap file.
The infile must be a .prg file or a plain file. This is explained further in the exo20info.txt file in the distribution. However this file is not updated with any Oric specific info yet.

Any feedback is welcome.

[Dbug]

The outfile will be an Oric tap file.
The infile must be a .prg file or a plain file. This is explained further in the exo20info.txt file in the distribution. However this file is not updated with any Oric specific info yet.

What do you call a ".prg" file ? We do not have prg files on the oric, we only have to kind of "files":
- tapes (tap extension), with a header with name and load adress, file type, etc...
- floppy disc files, that are basicaly the same thing except that the header is not part of the file (it's part of the floppy directory structure).

A simple thing to do would be to support ".tap" files as native files, and automaticaly setup the table, load and run adress based on the content of the header.

Would make it simple to use:

Code: Select all

exomizer -o packed.tap program.tap

On the Oric, the jump adress of the file is the first byte of the file. So if the file loads in the $500-$1000 memory area, you will do a jump to $500 anyway to run it

[zagon]

As it is now the different targets all supports the same kinds of in file types. It would be nice to support Oric tap files as in files and also be able to extract the start address from it too, like what is already done for Atari xex-files. However I haven't found a way yet to reliably automatically tell Oric tap from .prg files yet. I'll look into this.

The plain and .prg files are supported across all targets.
A .prg file is a plain file that has a two byte litte endian load address prependen to it.
the load address of a prg file can be overrided like this on the command line: <prg file name>,<load address>

A plain file is loaded like this <plain file name>@<load addres>

load addresses are in base 10 or hexadecimal if prepended with $ or 0x

One thing that I forgot to mention is that exomizer supports more than on in file. For instance one file may be code, another music a third graphics. In this case it makes sense to use plain or .prg files i think.

exomizer supports multiple in files like this:
exomizer sfx $<start> <in1> <in2> <in3> -o <out>

[Twilighte]

With disk drive connected we also have the ability to address the top 16K of RAM, so Exomiser should at least give the facility to be able to extract up to $FFFF. Page 2 is only a problem if some elements of BASIC are required to remain. Page 3 must be avoided and not written to as part of the decrunching process(See below), and if Sedoric (The disc OS) is required Page 4 should be left too.
With no Sedoric and BASIC requirement, but placed onto a machine with disc drive connected, a decruncher may potentially be placed in Page2 (Unsure if writes to the complete Page3 range will upset it if it (The via, Disc controller and other peripherals) is restored after the decrunching) and occupy $400 to $FFFF.

[zagon]

Ok, after doing some research, accessing the top 16K RAM is done as simple as writing %1xxxxx0x to $0314 and returning to BASIC ROM is done by writing %0xxxxx1x to $0314? In the RAM configuration mode the interrupts need to be disabled too, right?

So code like this should change into ROM:
sei
lda $0314
and #$fd
ora #$80
sta $0314

And this back to ROM:
lda $0314
and #$7f
ora #$02
sta $0314
cli

Another thing, the default decrunch effect changes the character in the lower right corner of the screen. This can possiblu corrupt decrunches that decrunches into the screen memory. To turn off decrunching effect use flag -n

Does anyone have any suggestions for some other decrunch effect? Preferrably achieved by poking some IO-register since they are out of the way from decrunchable memory.

[Dbug]

In the RAM configuration mode the interrupts need to be disabled too, right?

Well, only the first time you disable the ROM, because there is nothing in RAM, and the first interrupt call with just crash. But as soon as an IRQ handler (and associated code) is installed in $FFFx, you can flip/flop as will. Just need to know what you are doing

Another thing, the default decrunch effect changes the character in the lower right corner of the screen. This can possiblu corrupt decrunches that decrunches into the screen memory. To turn off decrunching effect use flag -n

Does anyone have any suggestions for some other decrunch effect? Preferrably achieved by poking some IO-register since they are out of the way from decrunchable memory.

There are no IO register for the display, so you can forget about that.
The only way to get visual feedback is to poke in the video memory.

Now, be carreful about which values you are putting, because you can actually badly fuck up the display if you change the video mode or the frequency. In your place I would restrain to the 8 PAPER color attributes (ie, values from 16+0 to 16+7). Then you are on the safe side, sure to not fuckup anything, and it will work as well in HIRES or LORES modes

PS1: Ideally you would save the original value and put it back at the end of the depacking !

PS2: Clearing the IRQ during the depacking operation will speedup the depacking by about 20%

PS3: Good job !

[zagon]

There are no IO register for the display, so you can forget about that.
The only way to get visual feedback is to poke in the video memory.

Ok, are there any sound registers that produce sound when repeatedly poked that don't require any set up code to be run first?

I would restrain to the 8 PAPER color attributes (ie, values from 16+0 to 16+7). Then you are on the safe side, sure to not fuckup anything, and it will work as well in HIRES or LORES modes

Ok, sounds reasonable.

PS2: Clearing the IRQ during the depacking operation will speedup the depacking by about 20%

Ok, quite time consuming default interrupt handlers there. As it is now (this is true for all sfx targets) the interrupt are disabled only if the data covers addresses below ROM areas. (in which case ROM are flipped out and irqs are disabled during decrunch. When done, both the ROM/RAM config and the irq setting are restored to their previous values.

However the behaviour towards sei/cli and RAM/ROM is completely configurable by the i_irq_enter i_irq_during i_irq_exit symbols (valid values are 0 and 1). Also RAM/ROM banking will be overrideable (like other targets) with by using the symbols i_ram_enter i_ram_during i_ram_exit (0 and 1 is valid)

So to generate a decruncher that always disables irqs and starts the progam with disabled irqs use these flags on the exomizer command line:
-Di_irq_during=0 -Di_irq_exit=0

I'm working on a version with an Oric target that has RAM/ROM banking. Also it will have tha ability to load oric tap files and autodetect the run address from them. I'll post a link when its ready.

[Twilighte]

Ok, are there any sound registers that produce sound when repeatedly poked that don't require any set up code to be run first?

No, apart from ROM calls. This is because the Orics sound chip is not directly memory mapped. Instead it has to be configured through the internal Versatile Interface Adaptor (VIA 6522).

Ok, quite time consuming default interrupt handlers there.

The default ROM IRQ handler is atrociously written, and yes consumes a hell of alot of cpu cycles to do hardly anything exciting.
Infact the IRQ takes 14 cycles to exit what it is currently doing and start execution of the IRQ and another 6 to return to what it was doing.

[zagon]

No, apart from ROM calls. This is because the Orics sound chip is not directly memory mapped. Instead it has to be configured through the internal Versatile Interface Adaptor (VIA 6522).

Ah, ok no sound decrunch effect then.

Implementing tap reading and examining several tap files makes me woder about the end address in the tap header. Is the last data byte written at the address immediately preceeding the end adress (exclusive) or is it written at the end address (inclusive)? In other words, is the length of the data equal to (end - start) or (1 + end - start)?

I thought it was exclusive, but now I'm not so sure. There seems to be a lot of variation in the headers of different files.

I'm almost done with the new version, however I'm having trouble testing the RAM/ROM flip feature. I would be grateful, if someone could point me in the direction of some suitable oric files to crunch.

Euphoric doesn't seem to have an microdisc controller when booted using a tap file. Do I have to convert the tap files to disc-images to test the RAM/ROM flip feature? And if so, which is the easiest way to do this?

[Dbug]

In other words, is the length of the data equal to (end - start) or (1 + end - start)?

Second choice.
In my programs to generate tape headers I have this kind of code:

Code: Select all

adress_end=adress_start+file_info.size-1;

if (flag_auto)   Header[7]=0xC7;
else	      Header[7]=0;

Header[10]=(adress_start>>8);
Header[11]=(adress_start&255);

Header[8]=(adress_end>>8);
Header[9]=(adress_end&255);

I'm almost done with the new version, however I'm having trouble testing the RAM/ROM flip feature. I would be grateful, if someone could point me in the direction of some suitable oric files to crunch.

Define 'suitable' ?
I very often use the overlay ram in my programs, but as additional memory used as buffers. I never actually tried to get a program assembled to be run directly at this location.

I guess we could try to assemble a simple program that would run at the adress range $c000-$ffff for you tests ?

Euphoric doesn't seem to have an microdisc controller when booted using a tap file. Do I have to convert the tap files to disc-images to test the RAM/ROM flip feature? And if so, which is the easiest way to do this?

Well, there is two possible ways, and both involve having a bootable floppy disc.

First is that you just boot in microdisc mode with let's say a standard Sedoric.dsk disc, and then from there you can CLOAD you test program lying on a tape.

Second is to generate a floppy disc from a tape file using the great Fabrice utility called Tap2dsk.
(You can find it here: http://oric.free.fr/TOOLS/tap2dsk.zip)
And then you boot on this floppy.

Syntax to boot euphoric with a floppy is with the -m flag:

Euphoric -m floppy.dsk

[zagon]

Second choice.

Ok, this mens that there are a few tap file out there that one byte short. Well, Euphoric seems to load them fine so I probably should allow them to load in exomizer too.

I very often use the overlay ram in my programs, but as additional memory used as buffers. I never actually tried to get a program assembled to be run directly at this location.

Ok, I guess I should have realised that the number of tap-files that load directly into the top 16kB RAM probably equals zero

I guess we could try to assemble a simple program that would run at the adress range $c000-$ffff for you tests ?

That would be great, something that makes it easy to see if it works. I'm not that familiar with the Euphoric debugger.

I'm changing the default load/start address of the selfdecrunching program to $0500 to allow it to load from disc. I guess that files that require a microdisc controller to work are more likely to be loaded from disc.

[zagon]

I guess we could try to assemble a simple program that would run at the adress range $c000-$ffff for you tests ?

That would be great, something that makes it easy to see if it works. I'm not that familiar with the Euphoric debugger.

Nevermind, I managed to make a very small test program myself.

[zagon]

Ok, here's a new version to test, dos and win32 versions this time. No source code. If you need it to compile for some other target please notify me and I'll clean them up.

http://hem.bredband.net/magli143/exo/exooric.zip

It supports tap file reading and microcontroller 16 kB RAM flipping.

Have fun.

This is what will go into the next beta release so please report any bugs you find.

[Dbug]

Tried the win32 version, works fine on two test (one is a 3k program, the other one was 36k), and both pack and unpack without any problem

I used the following command:

Code: Select all

exomizer sfx %OSDKADDR% -t1 -o build\%OSDKNAME%.PAK build\%OSDKNAME%.TAP

Now for the comments:
- Your program is also compatible with the Oric Atmos or Telestrat, so there is not reason to only talk about "Oric 1" in the documentation.
- It would be nice to get the start adress automaticaly extracted from the tape header if the source file is a .TAP

If this is ok with you, I can probably add Exomizer to the OSDK, with direct support for packed executables in the configuration files. This way people can directly get everything in one single package. If that's ok, I will of course add adequate copyrights/emails/weblinks on the Exomizer documentation page.

[Chema]

This is indeed a fantastic tool! Congratulations.

So I suppose it could be possible to load part of a program, decrunch it in overlay ram, switch to rom and load the rest in normal memory and then switch back to ram to run everything together?

This way it is not necessary to load data from disk as we do in Space 1999 to use overlay ram!

BTW I have allways wondered if it would not be possible to make a wire-connection in the expansion bus, so overlay ram is activated without the need of an external disk drive... Something like outputting the correct signal via page 3 and feed it into the ROMDIS pin? Maybe it is a stupid question... I just don't know.