simple 68k loop

[Sik]

and this one doesnt save bytes, it looks like it's unrolled at build time

Code: Select all

.rept 62
	dc.l    _INT
.endr

But that's precisely what you want (there are 64 vectors, two of those are reset and entry point, the rest are interrupts). But yeah, that's pretty much the same thing dcb would do.

Anyway, there's what Miquel said if you really want to save bytes, but honestly I wouldn't get too hung up over saving bytes in the 68000 vectors (especially if you intend to use the vblank or hblank interrupts later, as they end up in the middle of the vector table...) The last 16 vectors (64 bytes) are pretty much unused tho so feel free to put garbage there.

[bioloid]

Sik you are right, for a 4k I would need this blanks interrupts anyway, nevertheless I find what Miquel taught is awesome!

[Miquel]

And to do the main loop in GCC, the one you should never exit, simply:

Code: Select all

mainLoop:
	/* more code, like for example: */
	bsr readInput
	/* more code */
	jra mainLoop

[Chilly Willy]

If the readInput routine reads the controllers directly, the main loop must have logic that prevents it from looping more often than once per vblank. Some controllers go crazy if they're read more often than 60 times per second. In fact, most people read the inputs as part of the vblank code, not the main loop.

[Miquel]

readInput was just an example without real meaning, if I have understood it correctly what bioloid wants to do is set the screen to one color with the less possible file/rom size, were not talking about a typical MD program/game.

[Miquel]

You can avoid using vertical exceptions by checking the vertical bit on the vdp. Also there is the STOP instruction, but without exceptions I think it will not work.

Alternatively, you can use the same schema we used for the the ‘SEGA’ mark:

Code: Select all

	/* code */
	jra 1f
.org 0x78					/* check twice if it's really this number */
	dc.l VerticalException
1:
	/* code */
VerticalException:
	/* VE code... */

I don't understand that 4kb rule, but if you are trying to do a 4kb ROM game you are going to suffer a lot of size pain, better compress the whole game and decompress it to RAM.
Instead if is a 4kb after compressing with zip/rar is more or less doable as long as graphics are plain and not compressed.

[Chilly Willy]

Most tiny program contests I've seen allow compression and competitors make heavy use of that. If the one he's involved in does, the best thing would be to assemble the code to ram as well as data and compress that. The first two longs are the reset sp and reset vector, then you'd have the tiniest decompressor you can manage (with 0x100 being "SEGA" as usual), followed by the compressed block. The reset vector would point to the decompressor which would decompress the code/data block into ram and then jump to it.