simple 68k loop

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

User avatar
Sik
Very interested
Posts: 716
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: simple 68k loop

Post by Sik » Thu Oct 11, 2018 8:37 am

bioloid wrote:
Wed Oct 10, 2018 6:15 am
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.
Sik is pronounced as "seek", not as "sick".

bioloid
Very interested
Posts: 107
Joined: Fri May 18, 2012 8:22 pm

Re: simple 68k loop

Post by bioloid » Thu Oct 11, 2018 4:39 pm

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

User avatar
Miquel
Very interested
Posts: 341
Joined: Sat Jul 30, 2016 12:33 am

Re: simple 68k loop

Post by Miquel » Sat Oct 20, 2018 9:01 pm

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
Yeah, I see you have to hive hope for the “believers” and the “non- believers”. Don’t worry I know.
“How much you have yet to learn”, is usually what them tell me when I fail to comprehend.

Chilly Willy
Very interested
Posts: 2603
Joined: Fri Aug 17, 2007 9:33 pm

Re: simple 68k loop

Post by Chilly Willy » Tue Oct 23, 2018 8:03 pm

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.

User avatar
Miquel
Very interested
Posts: 341
Joined: Sat Jul 30, 2016 12:33 am

Re: simple 68k loop

Post by Miquel » Tue Oct 23, 2018 9:29 pm

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.
Yeah, I see you have to hive hope for the “believers” and the “non- believers”. Don’t worry I know.
“How much you have yet to learn”, is usually what them tell me when I fail to comprehend.

User avatar
Miquel
Very interested
Posts: 341
Joined: Sat Jul 30, 2016 12:33 am

Re: simple 68k loop

Post by Miquel » Sat Nov 03, 2018 4:15 am

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.
Yeah, I see you have to hive hope for the “believers” and the “non- believers”. Don’t worry I know.
“How much you have yet to learn”, is usually what them tell me when I fail to comprehend.

Chilly Willy
Very interested
Posts: 2603
Joined: Fri Aug 17, 2007 9:33 pm

Re: simple 68k loop

Post by Chilly Willy » Sat Nov 03, 2018 11:59 am

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests