forum.defence-force.org

My thought was wihtout recompiling anything, but using play tap file, ok it could be see as an emulator, but it wouldn't be one

The problem when going from BASIC to C is that the then generated binary code is way too big compared to the space the Basic took in the Oric's memory.

As l'Aigle D'Or fills the whole memory I don't think it's possible to make a C Oric version.
Maybe by splitting it in several programs on a disk but I'm not even sure it would work.

Or maybe I'm too lame when translating Basic to C manually.

JOTD, what are your ratios when going Basic to C in term of memory usage ?

You have to consider that you if you don't use the BASIC, you can use the 16k of overlay memory.
Also the BASIC is efficient in code term, but the storage of variables is highly inefficient compared to what you would have in C or assembler.

Not every time, if you use Sedoric and/or some ROM routines and HIRES like l'Aigle d'Or you are stuck with 37 Ko or so.
Of course we could try to re-code the ROM routines needed in assembler but that would lead to something even more complex to code.

L'Aigle d'Or, e.g., is quite optimized already. It stores a lot of Data directly in RAM (i.e. everything is loaded from tape or disk into memory and used there) and it uses very few Basic variables IIRC.

Hialmar wrote:L'Aigle d'Or, e.g., is quite optimized already

Optimized for BASIC you mean
Because honestly the speed of the display is just laughable

Hialmar wrote:Not every time, if you use Sedoric and/or some ROM routines and HIRES like l'Aigle d'Or you are stuck with 37 Ko or so.
Of course we could try to re-code the ROM routines needed in assembler but that would lead to something even more complex to code.

L'Aigle d'Or, e.g., is quite optimized already. It stores a lot of Data directly in RAM (i.e. everything is loaded from tape or disk into memory and used there) and it uses very few Basic variables IIRC.

I strongly think that "translating" such a game into ASM or C will make is more optimised, both in size and speed.

The basic is not really efficiently stored as only the command name is stored as token, all the other part are stored as text, which is fact a pretty stupid mistake from the 6502 MS BASIC.

And when translating from one language to another is not juste doing is line by line, this would be wrong, you need to do it function per function, and changes things accordingly to the new language you use, as for exemple, in C all variable are not global one.

Also using the ROM for an ASM/C version does not seems to be a good idea.

Anyway, there are much more complex game, both in graphs and game logic, that are made in ASM/C that use less or same amount of memory. I'm pretty sure that we can halve the memory usage of this game, just by converting it to asm/C (and not a "dumb" conversion, but a real adaptation)

The speed problem is directly related to the stupid floating point operations in Basic IMHO.
Using an integer basic like Apple II Woz's you could accelerate a lot Oric Basic programs.
I know there are other Basics for Oric and maybe one of them just did that.

Now what you propose Godzill is very good but it will require a complete rewrite of the game. So basically you would only keep the Graphics and Sound and redo all the rest. I'm not sure I have enough free time to do this.

I have taken a look of L'Aigle D'or source code, it's "highly" optimized to be quick with the Basic interpreter, but the way the code is not necessarily done in a good way. The code is really a mess, and translating it directly won't be really interesting, nor possible..

Converting such a game to native language will takes some times, but I don't think it takes that much time, a few (full-time) days, or around 2 or 3 weeks of less intensive work should be enough for the conversion.

About the "redo all the rest" if you blindly convert the Basic code into C/ASM you will just obtain a mess, that will, anyway be modified to clean it, and it's what is my "solution" anyway, convert the code into more "powerfull" language, and clean it, part by part.

There are also part like
That are absolute non-sense on a lowlevel language, we don't need to load ASM code in memory, then call it when we already execute native code

(By the way, I found this code here not really well design, maybe it save some bytes, but it's a lot of loss time just to convert the strings to values before poking them)

A much cleaner and simpler way would be:
Which behave exactly the same and will be really quicker, and if my counting is correct, save 40 bytes (270 bytes for the actual code, 231 for mine, and I'm sure there are way to optimise size more)

My experience with DATA/READ is that it is awfully slow. And I think this is why the coder did it with strings.
I also think that he did this at the last minute because for other ASM routines the code is directly in memory.

Edit: I checked and what you copy/pasted is from the intro which is not very optimized. You need to look at the code of the game.

You can save even more bytes by removing the "#" from the data, and evaluate it with POKE I,VAL("#"+A$), and it's still almost readable.
I did this in my games a looooong time ago.

Hialmar you're right about C taking much more room than the BASIC counterpart. Global variables or not, a "for" loop, a while, a if/else must generate a lot of asm code. For this BASIC is just unbeatable with the 1-byte tokens.

But in some BASIC programs there's a lot of copy/paste because sometimes it was easier than doing a proper subroutine with "params".

Godzil you're right, maybe rewriting/factorizing some converted code and keeping the things that sound OK would work. Well, worth a try anyway.

I think it could work as-is with some more modest programs like Manoir du Dr Genius, which was full BASIC, awfully slow, and not taking all the memory at all (I already converted this program to C and it runs 100% in a windows exe)

Sorry about the noob question but is it possible to bypass the 16K ROM and get 16K RAM instead ? I don't think so, so we are left with calling the ROM for functions like HIRES, MUSIC ... (much easier like this anyway!). Or we could rewrite a minimalist run-time (no BASIC interpreter) a gain a few kbytes...

You can overwrite the ROM if you use a disk drive because then the ROM is copied in a RAM overlay.

jotd wrote:Sorry about the noob question but is it possible to bypass the 16K ROM and get 16K RAM instead ? I don't think so, so we are left with calling the ROM for functions like HIRES, MUSIC ... (much easier like this anyway!). Or we could rewrite a minimalist run-time (no BASIC interpreter) a gain a few kbytes...

A "vanilla" oric can't switch by itself the ROM/Overlay RAM, you need something plugged on the External port to provide something to do the switch. All disk drive provide this for exemple, but making a simple hardware that with a D latch (or a flipflop to make it even simpler) that will toggle the ROM will be easy to do, just need a bit of address decoding (I think 2 or 3 chip would be suffisent to make a simple one)

You mean that the machine has 64k ram and 90% of the users could not use it because they only had a tape deck?

Isnt basic faster with ram than rom? Well Ill stop the offtopic after that but this question annoyed me for 30 years

jotd wrote:You mean that the machine has 64k ram and 90% of the users could not use it because they only had a tape deck?

Yep. And IIRC it would have been quite easy to use a free port on the sound chip to switch the rom on/off by software, but they didn't include that in the circuity.

I think there is a mod to use this trick to switch between two roms. Fabrice made it I think...

jotd wrote:You mean that the machine has 64k ram and 90% of the users could not use it because they only had a tape deck?

That's why some of my demos (ex: Buggy Boy), despite being one single executable file that fits in memory, are available only as floppy versions: It's to have access to the additional 16k of RAM.

jotd wrote:Isnt basic faster with ram than rom? Well Ill stop the offtopic after that but this question annoyed me for 30 years

RAM is not inherently faster than RAM, but it allows some operations that are not doable in ROM (such as self modified code).