Minigames 2006 : Go !

[Euphoric]

This year, the 1K category compo will end as soon as the 10th of May.
So, it's time to start your minigame and maybe talk a bit of it in this forum: this way we won't have twice the same game on the Oric platform...

Then, if you are more interested in the 4K category, you have up to August 31st to finish your 4K game, and this year a new 8K category is experimented: this one will end on October 31st... (I don't think there will be many entries in this category, on our platform most of the published commercial games would have fit in 8K once compressed... Anyway, I might be wrong about the number of entries: this category could interest people with graphic skills, and we could see not-so-big programs that use rich graphics...).

Ok, to start the ball rolling, here is what I intend to write in the 1K category (most likely, I will only be able to start during next Easter holidays):
- an "Astro Invader" (Stern 1980) for the Oric
- a "Crash" (Exidy 1979) for the Microtan 65

[Dbug]

I don't know exactly if I will have time to code something, and the new deadlines are a bit weird...

Not directly related: since somebody posted an Intellivision game of the minigame compo 2004 on pouet, I decided to put mines too I only started by Cyclotron http://www.pouet.net/prod.php?which=24254, but I will add 4kKong, and probably other Oric minigames if everybody is ok with that.

[Euphoric]

Hello there, I'm trying to complete a 1K game for the Minigame compo 2006, and I'm spending way too much time on testing (spent lots of hours catching bugs).

Bugs should be eradicated now, but who knows, so, if you are not yourself preparing a minigame (deadline is 10th of May, I hope you haven't forgotten), I would appreciate beta testers, ready to test the successive versions to come. Also, despite my efforts to lose weight (not myself, the program... , I'm still a hundred bytes too fat (and I still have an important feature to add), so if you have a very small compressor/decompressor that can makes me comply with the 1K barrier, it would be appreciated...

Cheers,

Fabrice

[Dbug]

Hello there, I'm trying to complete a 1K game for the Minigame compo 2006, and I'm spending way too much time on testing (spent lots of hours catching bugs).

I know that, been there many times already

Bugs should be eradicated now, but who knows, so, if you are not yourself preparing a minigame (deadline is 10th of May, I hope you haven't forgotten),

Arghhhhh, totaly forgot it was *that* early !

I would appreciate beta testers, ready to test the successive versions to come. Also, despite my efforts to lose weight (not myself, the program... , I'm still a hundred bytes too fat (and I still have an important feature to add), so if you have a very small compressor/decompressor that can makes me comply with the 1K barrier, it would be appreciated...

I unfortunately have no time for that, I have a friend arriving today from Lyon, she stays until the 14th, and I can hardly imagine myself telling her that I wish to stay coding on the Oric while she's here instead of going out showing her the city :-/

The only decompressor I have is the one I use in my 4k games, and the unpacking code itself takes (if I remember correctly) about 192 bytes, so except if it packed exceptionaly well I doubt it will match your needs.

Can you send me the source code by mail ? I will try to find one hour here and there to see if I can find out a way to shrink that down).

You should try to pack it with FilePack, and see how small it get.
http://www.defence-force.org/computing/ ... /index.htm

Good luck !

[Euphoric]

I have tried filepack, but it only outputs a 7-bytes file (the LZ77 signature)... I remember having had this problem in the past, but I don't remember how to work around it (I have tried both the July 2002 and the November 2002 versions)... Any hint ? or is it just that it doesn't work with too small files ?

Cheers,

Fabrice

[Dbug]

OOps, looks like the version of filepack in the archive is both invalid and obsolete.

Please try that one:
http://www.defence-force.org/download/oric/filepack.zip

This version has an option that allows the program to not save any header, and instead generate a text file containing #define lines with adresses and sizes of data.

I also put the last version of the unpacking code, that hopefully will be not bugged... the unpacking routine I used in Cyclotron is slightly different, since it was not supposed to be used as a OSDK depacking routine with function passing parameters and stuff, and looks like this:

Code: Select all

	.zero

	*= $50

ap	.dsb 2
fp	.dsb 2
sp	.dsb 2
tmp0	.dsb 2
tmp1	.dsb 2
tmp2	.dsb 2
tmp3	.dsb 2
tmp4	.dsb 2
tmp5	.dsb 2
tmp6	.dsb 2
tmp7	.dsb 2
op1	.dsb 2
op2	.dsb 2
tmp	.dsb 2
reg0	.dsb 2
reg1	.dsb 2
reg2	.dsb 2
reg3	.dsb 2
reg4	.dsb 2
reg5	.dsb 2
reg6	.dsb 2
reg7	.dsb 2

	.text

;// Packed source data adress
#define	ptr_source			tmp0	

;// Destination adress where we depack
#define	ptr_destination		tmp1	

;// Point on the end of the depacked stuff
#define	ptr_destination_end	tmp2	

;// Temporary used to hold a pointer on depacked stuff
#define ptr_source_back		tmp3	

;// Temporary
#define offset			tmp4	

#define mask_value			reg1
#define nb_src			reg2
#define nb_dst			reg3


_Unpack
	;// Initialise start and end adresses
	lda #<run_adress
	sta ptr_destination+0
	lda #>run_adress
	sta ptr_destination+1

	lda #<run_adress_end 
	sta ptr_destination_end+0
	lda #>run_adress_end
	sta ptr_destination_end+1
	
	lda #<_UnpackBeginData
	sta ptr_source
	lda #>_UnpackBeginData
	sta ptr_source+1


	;// Initialise variables
	;// We try to keep "y" null during all the code,
	;// so the block copy routine has to be sure that
	;// y is null on exit
	ldy #0

	lda #1
	sta mask_value
  
_UnpackLoop
	;// Handle bit mask
	lsr mask_value
	bne _UnpackEndReload

	lda (ptr_source),y ;// Read from source stream

	inc ptr_source  ;// Move stream pointer (one byte)
	bne _UnpackEndReload1
	inc ptr_source+1
_UnpackEndReload1
	ror 
	sta mask_value   
_UnpackEndReload
	bcc _UnpackCopyBlock

_UnpackWriteByte
	;// Copy one byte from the source stream
	lda (ptr_source),y
	sta (ptr_destination),y

	inc ptr_source
	bne _UnpackWriteByteEndTmp0Inc
	inc ptr_source+1
_UnpackWriteByteEndTmp0Inc

	lda #1
	sta nb_dst



_UnpackEndLoop
	;// We increase the current destination pointer,
	;// by a given value, white checking if we reach
	;// the end of the buffer.
	clc
	lda ptr_destination
	adc nb_dst
	sta ptr_destination

	bcc _UnpackEndLoopSkip
	inc ptr_destination+1
_UnpackEndLoopSkip
	cmp ptr_destination_end
	lda ptr_destination+1
	sbc ptr_destination_end+1
	bcc _UnpackLoop  

_UnpackEnd
	;// Run the unpacked executable
	jmp run_adress
	

_UnpackCopyBlock
	;//BreakPoint jmp BreakPoint	
	;// Copy a number of bytes from the already unpacked stream
	;// Here we know that y is null. So no need for clearing it.
	;// Just be sure it's still null at the end.
	;// At this point, the source pointer points to a two byte
	;// value that actually contains a 4 bits counter, and a 
	;// 12 bit offset to point back into the depacked stream.
	;// The counter is in the 4 high order bits.
	;//clc  <== No need, since we access this routie from a BCC
	lda (ptr_source),y
	adc #1
	sta offset
	iny
	lda (ptr_source),y
	tax
	and #$0f
	adc #0
	sta offset+1

	txa
	lsr
	lsr
	lsr
	lsr
	clc
	adc #3
	sta nb_dst

	sec
	lda ptr_destination
	sbc offset
	sta ptr_source_back
	lda ptr_destination+1
	sbc offset+1
	sta ptr_source_back+1

	;// Beware, in that loop, the direction is important
	;// since RLE like depacking is done by recopying the
	;// very same byte just copied... Do not make it a 
	;// reverse loop to achieve some speed gain...
	;// Y was equal to 1 after the offset computation,
	;// a simple decrement is ok to make it null again.
	dey
_UnpackCopyBlockLoop
	lda (ptr_source_back),y	;// Read from already unpacked stream
	sta (ptr_destination),y	;// Write to destination buffer
	iny
	cpy nb_dst
	bne _UnpackCopyBlockLoop
	ldy #0

	;// C=1 here
	lda ptr_source
	adc #1
	sta ptr_source
	bcc _UnpackEndLoop
	inc ptr_source+1
	bne _UnpackEndLoop

_UnpackEndCode

_UnpackBeginData

I know that this version is bugged, and has been not working some particular set of data, in which case you can probably play with both routines, a la Docteur Frankenstein; and insert the initialisation code of the shortest routine in the OSDK one.

Of course it makes sense only if the pack ratio you got with this new version of FilePack is good enough.

Good luck !

[Euphoric]

Mhhh, still the same problem... this version also outputs a zero-length packed file (or 7 bytes without the -p0 option)...

Ok, don't bother, there were few chances that it compressed it enough to leave room for the decompressor anyway...

Good luck !

Luck ? this is not a question of luck...
Anyway, I've nearly finished and I am quite proud of it. I think this program might win this year
Ah, just understood... luck with the votes ?
You're right... Oricians don't seem to bother with this minigame compo, I will need luck to make all those Spectrum, Atari and C64 fans accept to vote for an Oric game...

Cheers,

Fabrice

[Dbug]

Mhhh, still the same problem... this version also outputs a zero-length packed file (or 7 bytes without the -p0 option)...

That's weird !
Could you send me your program by mail so I can see what's wrong with the packer ? I don't really like the idea that it fails on some particular programs, specialy if it happens twice for you

Also could you tell me which operating system you are using ?

Are you using a path with a space in it, or other weird characters ?

*perplexified*

[Euphoric]

I've put the code on http://oric.free.fr/TAPES/invasion.bin

It's exactly 1024 bytes, phew...
If you manage to use FilePack, please tell me how well it packs...

Cheers,

Fabrice

[Dbug]

Ok I tested... well actually there is a bug in Filepack because instead of signaling "The program cannot be compressed, result is bigger than original" it just continued and outputed a 0 byte long stream of data.

But well, I'm not that surprised.

Programs that are coded to be small don't compress well. I had to make 4kKong and Cyclotron bigger to get them smaller, by using a lot of tables of adresses (sorted by low/high bytes), use jmp and jsr instead of relative branches, etc... to increase the chance I get patterns that can be compressed effectively.

I don't really know how 1k program can be efficiently packed.

[Euphoric]

The program cannot be compressed, result is bigger than original

Well, I suspected that, I had put the 1K game in a Zip archive and had seen that the compression ratio was near 0.

Anyway, thanks for trying...

Cheers,

Fabrice

[carlsson]

Otherwise, if a zip archive indicated there is some space to remove, did you try to port Steve Judd's xip? It was written for C64, but has been ported to such bizarre systems as ZX Spectrum, so for anyone who knows what they're doing, Oric probably is within reach.

[Euphoric]

Hello Anders, "such bizarre systems as ZX Spectrum", eh ?
No, I haven't had a look at it... How long is the decompressor on the C64 ?

[carlsson]

If I count correctly, the decompressor is 56 bytes, and a 1K program on average is reduced by about 25-50 bytes after counting the decompressor.

The algorithm is very simple. It assigns n bits to the most common values, and escapes all other values as nine bits. In general, 2^(n-1) bytes are compressed; i.e. n=4 means 8 bytes in the lookup table, n=6 is 32 bytes. I'm not sure if n=6 is the maximum, but the program outputs which bytes are most common and may give you hints how to optimize the program by changing instructions or data to get maximum compression.

The C64 implementation of xip makes a lot of assumptions, which may not be required to honor in a port:

1) You load the program from disk (only) with ,8,1.
2) It loads to $0326, which happens to be the CHROUT vector, normally points to $FFD2 on VIC/C64. It means it will also overwrite a number of other vectors (LOAD, SAVE etc).
3) When Basic returns to print READY via CHROUT, the newly loaded code will execute, effectively auto booting.
4) It will take the current value of the CHRGET ($0073) routine, increase the address by one and decompress to that address, i.e. the decompressed program should start at $7AE7.

You can download xip here: http://www.ffd2.com/fridge/rad/

[Euphoric]

Ok, reading the readme file suggests that some programs might not have a positive reduction, so before trying to port the program to the Oric, I'm doing some stats on my minigame...
If I understand well, n bits are used for coding the 2^(n-1) most common values, and 9 bits for the others ?
So, if X is the total number of those 2^(n-1) most common values, and Y the total numbers of the other values, the compressor will output X*n+Y*9 bits, am I right ?

If I choose n=4, the eight most common values in my program are used 221 times, the others are 1024-221=803, so the compression scheme would output 1014 bytes (no space enough for the decompressor), argh.
Let's try n=5, my sixteen most common values count for a total of 349 bytes, so the scheme would output 978 bytes. Not bad, but with the decompressor, I'm still in the negative camp
Mhhh, with n=6, I can expect 957 bytes, so if the decompressor is 56 bytes, it gives 1013 bytes, i.e 11 bytes won, hurrah
(n=7 would output 966 bytes, so a gain of only two bytes).

Thanks for pointing me to this interesting scheme, Anders !
The scheme is simple, so it will be faster for me to write a compressor on the PC than to port the C64 version to the Oric...

Cheers,

Fabrice