Page 2 of 2

Re: Oric programs statistics

Posted: Tue May 26, 2015 1:38 pm
by Godzil
Symoon wrote:Oricium has 70% of zeroes ;) (bits, not bytes)
Also tested individually:
- Morts Subites (text basic adventure game)
- Crypt Show (hires advennture game)
- Defence Force
- 3D Fongus

All are between 60% and 65% of zeroes.

Ho it was bits and not bytes, ok makes more sense.

Re: Oric programs statistics

Posted: Tue May 26, 2015 1:54 pm
by Symoon
Godzil wrote:Ho it was bits and not bytes, ok makes more sense.
Yes, zero bit is apparently in majority in most programs, but the zero byte is also one of the most used (with space) - though this time it won't be true for all programs individually.

Re: Oric programs statistics

Posted: Tue May 26, 2015 3:39 pm
by Godzil
For pure assembly software I think this could be attributed to the instruction set itself, first there is a lot of hole in the ISA of the 6502, all code with the lower bits set to one are unused ($x3 => xxxx0011, $x7 => xxxx0111, $xB => xxxx1011, $xF => xxxx1111)

It would be really interesting to see the must used instruction and do some entropy calculation on them, but I suspect that it is quite bad. Anyway, the 6502 ISA was not made with this in mind.
It would also be interesting to look at the opcode for the BASIC, but we may end in a similar situation

Re: Oric programs statistics

Posted: Tue May 26, 2015 5:02 pm
by polluks
Symoon wrote:Oricium has 70% of zeroes ;) (bits, not bytes)
I don't see your point, one is information and zero is information.

Re: Oric programs statistics

Posted: Tue May 26, 2015 5:48 pm
by Chema
The point is that the saving/loading routines encode bits with value zero as larger tones (using more time) than with value one, so are more effective if the number of ones is greater.

Re: Oric programs statistics

Posted: Wed May 27, 2015 5:42 am
by Symoon
Chema wrote:
polluks wrote:I don't see your point, one is information and zero is information.
The point is that the saving/loading routines encode bits with value zero as larger tones (using more time) than with value one, so are more effective if the number of ones is greater.
Exactly, BTW what about Tap2CD, does it encode 00, 01 and 10 faster than 11 ?

As for the bytes, if four bytes are used massively, one can also encode them on tape in a special way (shorter than 8 bits) to go faster.

Now you can guess that I'm (very slowly) working on turbo tape routines ;) (or more precisely a saving routine, Tap2CD is fast enough to load back things!)
I suspect the statistics might also be useful for data compression.

Re: Oric programs statistics

Posted: Wed May 27, 2015 9:07 am
by Chema
tap2cd (new version) was made by Fabrice when I wanted it to work with SkoolDaze, not me. I just tested and helped him to tweak it so it loaded in as many different Orics as possible. Anyway it encodes bit pairs as you said: 00 (slowest) 01, 10, 11 (fastest), so yeah it could be made faster if it used the opposite encoding ;)

At least that is what I understood from the code here https://github.com/norayr/oric-tools/bl ... d/loader.s

And indeed using these statistics for code compression may be a good idea!

Re: Oric programs statistics

Posted: Wed Jun 22, 2016 7:36 am
by Symoon
I forgot something in my statistics...
The datas are made of 60% (or so) of zeroes, but... The datas are loaded with parity, start and stop bits in the signal. And there are 3 stop bits at "1" for only 1 start bit at "0", which makes 75% of "1"...

So in the end, I'm not sure reversing the 0 and 1 signal would be that much helpful... And maybe even worse, who knows ;)

Re: Oric programs statistics

Posted: Wed Jun 22, 2016 12:16 pm
by Godzil
Hey that just gave me an idea for a new "format" (not on the sound level, but on the storage level) I should test how it behave :D

(Not to myself: not forget that idea!)