Forums

OK, I guess I'll make this a 32k game then. I didn't know any better when I started this game. Anyway, this should be a learning exercise, and I have been learning a lot about Game Gear coding.

I don't see the logic.

I tried dividing the code into 4 banks. It didn't work at all.

.memorymap
defaultslot 0
slotsize $4000
slot 0 $0000
slot 1 $4000
slot 2 $8000
slot 3 $c000

.endme

.rombankmap
bankstotal 4
banksize $4000 ; 16kb
banks 4
.endro

The above code should give me 4 banks that are each 16k, but the program is giving me error messages:

Quote

MEM_INSERT: Origin ($4000) overflows from bank (3).
LOAD_FILE_DATA: Could not open file "object.o".
The system cannot find the file specified.
> Execution finished.

the breakdown of the code is:
bank 0 - lines 90-1216
bank 1 - lines 1217-2335
bank 2 - lines 2335-2739
bank 3 - lines 2730-2806 (essentially, all the includes)

What am I doing wrong? My code is in this link.
http://www.atari2600land.com/mrultra/mrultra21a.asm

sverx wrote

If you go 64 KB you'll have 4 16 KB banks.

Why can't I have 2 32k banks? It lets me do that.

The common mappers have 16KB slots. You only have 48KB of ROM space so that's a sensible division. WLA DX will let you do anything but it won't be compatible with emulators or existing hardware.

The error you get is telling you that something in slot 3 is specifying an origin (.org) at address $4000 but the bank is effectively from 0 to $3fff (in terms of space in the bank, if you use .org) or from $8000 to $bfff (in terms of mapped addresses in slot 2, if you use .orga). Maybe there's something in an included file? Or maybe you need to put origin directives after your bank directives to reset the address, I can't remember if that's required...

It looks like your banks won't be very full. When it builds, WLA DX should be able to tell you the unused space in each. I can't check it myself without having all the files...

This game reminds me of a atari 2600 game very simple gameplay.

Maxim wrote

The error you get is telling you that something in slot 3 is specifying an origin (.org) at address $4000 but the bank is effectively from 0 to $3fff (in terms of space in the bank, if you use .org) or from $8000 to $bfff (in terms of mapped addresses in slot 2, if you use .orga). Maybe there's something in an included file? Or maybe you need to put origin directives after your bank directives to reset the address, I can't remember if that's required...

Could it be the PSGLib? That seems to be what it might be, since it uses slot 3.

PSGlib expects RAM (not ROM) at slot 3. If you've got RAM at a different slot, change the slot in your PSGlib.inc code.

The include is in bank 3, slot 2. I really need the full source to figure it out.

Your use of banks is a bit messed up.
Did you randomly place .bank/slot pairs?
For example why do you put bank 1 and bank 2 into slot 1?
You're never setting any mapper registers so you will never see bank 2 in slot 1.
Also you've placed PSGlib into bank 3 and never page in bank 3 but still you're calling PSGlib functions. While this won't cause trouble in the assembler it will most likely make your game crash.

Please remove the line

.bank 2 slot 1

because your code won't take more than bank 0 and bank 1 and you're never mapping bank 2 into slot 1 anyways.

And as suggested by Maxim always add

.org 0

right after your .bank/slot pairs to ensure that the assembler starts at the beginning of the new bank.

And also please put

.include "filestouse\PSGlib.inc" ; include the library

before

.bank 3 slot 2

and turn

.bank 3 slot 2

into

.bank 2 slot 2

Depending on the size of your data you might need to split the data up (your includes at the end of the file) and put some of it into

.bank 3 slot 2

Also I believe most of those

.include

should be

.incbin

instead. Or did you store all your tiles/tilemaps in textual format?

But if I get rid of the bank 3 line, where would it go?

Gamegearguy wrote

But if I get rid of the bank 3 line, where would it go?

I've assembled your code without any include (as I don't have the files) and I've removed all of your .bank/slot directives other than

.bank 0 slot 0

so all code goes into bank 0 and then there is still 72.38% free in bank 0. So why do you spread your code over all 4 banks?
There's most likely no need for a bank 3 yet because you still have bank 1 and bank 2 to fill.

You could put some assets into bank 1 and others into bank 2. That way you won't need to bother with mapping yet.

I put some code in bank 3 because I thought there had to be something in all banks. I did what you suggested and I still get error messages. I guess I'll stick to 32k, and perhaps my next game can be planned better and be 64k if it needs to be. I'll plan it out better. If anyone wants the include files, they're in the link in post #1 of this thread.

Gamegearguy wrote

I put some code in bank 3 because I thought there had to be something in all banks.

You can leave banks empty. That's no problem at all.

Gamegearguy wrote

I did what you suggested and I still get error messages. I guess I'll stick to 32k, and perhaps my next game can be planned better and be 64k if it needs to be. I'll plan it out better. If anyone wants the include files, they're in the link in post #1 of this thread.

You will have a very hard time filling 32k with game code alone. Very few games do this. So, normally, there should be no need for paging in code, which is pretty much the only thing that's can be tricky in regards to paging. Most people just use the additional banks to store data, which they access by paging the appropriate bank(s) into slot 2.

Speaking of data, all your includes seem to be uncompressed raw data. It's only natural that the files are huge as a result. You really, really want to look into compression if you want to get anywhere in SMS/GG programming. Even one of the less efficient methods (like the popular PS compression) will free up a ton of ROM space. Even simple RLE would be an improvement over raw uncompressed data.

I tried making it a 32k with 2 banks and I couldn't even do that. It kept giving me a whole bunch of MEM_INSERT error messages.

The game is finished. I have 3.52% of room left for stuff to change. Let me know what you think.
http://www.atari2600land.com/mrultra/

Gamegearguy wrote

Let me know what you think.

Considering this is your first venture into z80 assembly language, the game's actually quite nice. As I said before, it reminds me a lot of that old Intellivision Smurfs game. I also like the simplistic style of the graphics, it's really unique. And the music is nicely done and very humm-able.

All in all, Mr. Ultra could use a little more variety, though. Does the game actually scroll or are the chasms created using sprites? Is there some sort of ending? I haven't been able to pass even the first corn enemies in level 3.

The holes are sprites. There is an ending after the 7th level. The trick to getting past the corn is to wait until they come closer, then jump over them and press right when they're closer to the left edge of the screen. Thanks for the compliments.

Congrats for completing your first gg-game! I think it turned out pretty well. And you go full circle with graphics, music, multiple levels, etc.

The mr. Ultra sprite reminds me a little of the characters from the Sierra adventure games from back then...

I'm amazed how you have worked/added/improved/transformed the code from Racer into this completely different game!

The source code is certainly amazing :) It's basically a bunch of code for everything, not really any data to drive the levels. Clearly it works, but it doesn't seem like it will scale well to a much more complex game.

Can you provide the source graphics? I'd like to have a go at compressing them to show how much space it saves - right now, your 31613 bytes of game are 23552 bytes of graphics data, 2459 bytes of music data, and 5241(ish) bytes of code. By comparison, my "ono" game (the only one I have handy right now) is 5459 bytes of code and 3426 bytes of graphics and lookup tables (not counting the music engine and data as that's a binary blob). Admittedly ono doesn't have a lot of graphics, but then nor does Mr. Ultra...

Here are all the pictures to Mr. Ultra:
http://www.atari2600land.com/mrultra/mrultrapictures.zip

I suggest you start working on your second game taking advantage of what you learnt doing this one. Don't forget ramsections.

Impressive and in such a short time frame :)

sverx wrote

Don't forget ramsections.

In a brief play with the code, it was clear that PSGLib's use of ramsections is quite hard to mix with other methods of RAM control. I'm not convinced that RAM sections are useful for Sega 8-bit use as they are intended, i.e. swappable chunks for memory reuse in blocks. As a library, I think PSGLib should try to live with a definition or label as the bootstrap to its memory use, as Mod2PSG2 does, to put less restrictions on the user.

On the contrary, I see ramsection as the perfect way to lift the burden of defining each variable at a constant position, with its risk of overlap, and in a more efficient manner. Even if you don't need to swap chunks, using ramsections you can separately declare variables in each of your asm sources and keep things simpler. Finally, I believe libraries (such as PSGlib) should never use memory at a fixed address, both ROM or RAM.

I mean to allow the user to define a symbol like PSGLibRAM, which is the first byte used, by whatever means they like and you define all your memory relative to that. Unfortunately ramsections require you to define a suitable memory map with RAM in the correctly numbered slot. I tend to use enums instead due to some stuff not working with ramsections (e.g. defines referencing items).

Gamegearguy wrote

The holes are sprites. There is an ending after the 7th level. The trick to getting past the corn is to wait until they come closer, then jump over them and press right when they're closer to the left edge of the screen. Thanks for the compliments.

Ah this trick! Finished the game, thanks for the fun.

Maxim wrote

I mean to allow the user to define a symbol like PSGLibRAM, which is the first byte used, [...]

I got it, I'll try to add a note and some code to switch away from ramsections if the user wants it...

edit: update released. It shows how to use a WLA-DX .enum section instead of a .ramsection

Author	Message
Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Tue Oct 20, 2015 9:24 pm
	OK, I guess I'll make this a 32k game then. I didn't know any better when I started this game. Anyway, this should be a learning exercise, and I have been learning a lot about Game Gear coding.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14726 Location: London	Posted: Tue Oct 20, 2015 10:07 pm
	I don't see the logic.

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Wed Oct 21, 2015 2:59 am
	I tried dividing the code into 4 banks. It didn't work at all. .memorymap defaultslot 0 slotsize $4000 slot 0 $0000 slot 1 $4000 slot 2 $8000 slot 3 $c000 .endme .rombankmap bankstotal 4 banksize $4000 ; 16kb banks 4 .endro The above code should give me 4 banks that are each 16k, but the program is giving me error messages: Quote MEM_INSERT: Origin ($4000) overflows from bank (3). LOAD_FILE_DATA: Could not open file "object.o". The system cannot find the file specified. > Execution finished. the breakdown of the code is: bank 0 - lines 90-1216 bank 1 - lines 1217-2335 bank 2 - lines 2335-2739 bank 3 - lines 2730-2806 (essentially, all the includes) What am I doing wrong? My code is in this link. http://www.atari2600land.com/mrultra/mrultra21a.asm

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Wed Oct 21, 2015 3:25 am
	sverx wrote If you go 64 KB you'll have 4 16 KB banks. Why can't I have 2 32k banks? It lets me do that.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14726 Location: London	Posted: Wed Oct 21, 2015 7:40 am
	The common mappers have 16KB slots. You only have 48KB of ROM space so that's a sensible division. WLA DX will let you do anything but it won't be compatible with emulators or existing hardware. The error you get is telling you that something in slot 3 is specifying an origin (.org) at address $4000 but the bank is effectively from 0 to $3fff (in terms of space in the bank, if you use .org) or from $8000 to $bfff (in terms of mapped addresses in slot 2, if you use .orga). Maybe there's something in an included file? Or maybe you need to put origin directives after your bank directives to reset the address, I can't remember if that's required... It looks like your banks won't be very full. When it builds, WLA DX should be able to tell you the unused space in each. I can't check it myself without having all the files...

OmegaPrime Joined: 18 Dec 2014 Posts: 95 Location: Canada	Posted: Wed Oct 21, 2015 6:35 pm
	This game reminds me of a atari 2600 game very simple gameplay.

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Wed Oct 21, 2015 9:23 pm
	Maxim wrote The error you get is telling you that something in slot 3 is specifying an origin (.org) at address $4000 but the bank is effectively from 0 to $3fff (in terms of space in the bank, if you use .org) or from $8000 to $bfff (in terms of mapped addresses in slot 2, if you use .orga). Maybe there's something in an included file? Or maybe you need to put origin directives after your bank directives to reset the address, I can't remember if that's required... Could it be the PSGLib? That seems to be what it might be, since it uses slot 3.

sverx Joined: 05 Sep 2013 Posts: 3794 Location: Stockholm, Sweden	Posted: Thu Oct 22, 2015 8:12 am
	PSGlib expects RAM (not ROM) at slot 3. If you've got RAM at a different slot, change the slot in your PSGlib.inc code.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14726 Location: London	Posted: Thu Oct 22, 2015 8:20 am
	The include is in bank 3, slot 2. I really need the full source to figure it out.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Thu Oct 22, 2015 9:53 am
Calindro Joined: 14 Apr 2013 Posts: 624	Your use of banks is a bit messed up. Did you randomly place .bank/slot pairs? For example why do you put bank 1 and bank 2 into slot 1? You're never setting any mapper registers so you will never see bank 2 in slot 1. Also you've placed PSGlib into bank 3 and never page in bank 3 but still you're calling PSGlib functions. While this won't cause trouble in the assembler it will most likely make your game crash. Please remove the line .bank 2 slot 1 because your code won't take more than bank 0 and bank 1 and you're never mapping bank 2 into slot 1 anyways. And as suggested by Maxim always add .org 0 right after your .bank/slot pairs to ensure that the assembler starts at the beginning of the new bank. And also please put .include "filestouse\PSGlib.inc" ; include the library before .bank 3 slot 2 and turn .bank 3 slot 2 into .bank 2 slot 2 Depending on the size of your data you might need to split the data up (your includes at the end of the file) and put some of it into .bank 3 slot 2 Also I believe most of those .include should be .incbin instead. Or did you store all your tiles/tilemaps in textual format?

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Thu Oct 22, 2015 9:26 pm
	But if I get rid of the bank 3 line, where would it go?

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Thu Oct 22, 2015 9:45 pm
Calindro Joined: 14 Apr 2013 Posts: 624	Gamegearguy wrote But if I get rid of the bank 3 line, where would it go? I've assembled your code without any include (as I don't have the files) and I've removed all of your .bank/slot directives other than .bank 0 slot 0 so all code goes into bank 0 and then there is still 72.38% free in bank 0. So why do you spread your code over all 4 banks? There's most likely no need for a bank 3 yet because you still have bank 1 and bank 2 to fill. You could put some assets into bank 1 and others into bank 2. That way you won't need to bother with mapping yet.

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Fri Oct 23, 2015 6:35 am
	I put some code in bank 3 because I thought there had to be something in all banks. I did what you suggested and I still get error messages. I guess I'll stick to 32k, and perhaps my next game can be planned better and be 64k if it needs to be. I'll plan it out better. If anyone wants the include files, they're in the link in post #1 of this thread.

Kagesan Joined: 01 Feb 2014 Posts: 875	Posted: Fri Oct 23, 2015 4:29 pm
Kagesan Joined: 01 Feb 2014 Posts: 875	Gamegearguy wrote I put some code in bank 3 because I thought there had to be something in all banks. You can leave banks empty. That's no problem at all. Gamegearguy wrote I did what you suggested and I still get error messages. I guess I'll stick to 32k, and perhaps my next game can be planned better and be 64k if it needs to be. I'll plan it out better. If anyone wants the include files, they're in the link in post #1 of this thread. You will have a very hard time filling 32k with game code alone. Very few games do this. So, normally, there should be no need for paging in code, which is pretty much the only thing that's can be tricky in regards to paging. Most people just use the additional banks to store data, which they access by paging the appropriate bank(s) into slot 2. Speaking of data, all your includes seem to be uncompressed raw data. It's only natural that the files are huge as a result. You really, really want to look into compression if you want to get anywhere in SMS/GG programming. Even one of the less efficient methods (like the popular PS compression) will free up a ton of ROM space. Even simple RLE would be an improvement over raw uncompressed data.

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Fri Oct 23, 2015 6:27 pm
	I tried making it a 32k with 2 banks and I couldn't even do that. It kept giving me a whole bunch of MEM_INSERT error messages.

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Tue Nov 03, 2015 3:33 pm
	The game is finished. I have 3.52% of room left for stuff to change. Let me know what you think. http://www.atari2600land.com/mrultra/

Kagesan Joined: 01 Feb 2014 Posts: 875	Posted: Tue Nov 03, 2015 6:28 pm
Kagesan Joined: 01 Feb 2014 Posts: 875	Gamegearguy wrote Let me know what you think. Considering this is your first venture into z80 assembly language, the game's actually quite nice. As I said before, it reminds me a lot of that old Intellivision Smurfs game. I also like the simplistic style of the graphics, it's really unique. And the music is nicely done and very humm-able. All in all, Mr. Ultra could use a little more variety, though. Does the game actually scroll or are the chasms created using sprites? Is there some sort of ending? I haven't been able to pass even the first corn enemies in level 3.

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Tue Nov 03, 2015 6:37 pm
	The holes are sprites. There is an ending after the 7th level. The trick to getting past the corn is to wait until they come closer, then jump over them and press right when they're closer to the left edge of the screen. Thanks for the compliments.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Tue Nov 03, 2015 7:45 pm
	Congrats for completing your first gg-game! I think it turned out pretty well. And you go full circle with graphics, music, multiple levels, etc. The mr. Ultra sprite reminds me a little of the characters from the Sierra adventure games from back then... I'm amazed how you have worked/added/improved/transformed the code from Racer into this completely different game!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14726 Location: London	Posted: Tue Nov 03, 2015 9:13 pm
	The source code is certainly amazing :) It's basically a bunch of code for everything, not really any data to drive the levels. Clearly it works, but it doesn't seem like it will scale well to a much more complex game. Can you provide the source graphics? I'd like to have a go at compressing them to show how much space it saves - right now, your 31613 bytes of game are 23552 bytes of graphics data, 2459 bytes of music data, and 5241(ish) bytes of code. By comparison, my "ono" game (the only one I have handy right now) is 5459 bytes of code and 3426 bytes of graphics and lookup tables (not counting the music engine and data as that's a binary blob). Admittedly ono doesn't have a lot of graphics, but then nor does Mr. Ultra...

Gamegearguy Joined: 06 Sep 2015 Posts: 268 Location: United States	Posted: Tue Nov 03, 2015 9:20 pm
	Here are all the pictures to Mr. Ultra: http://www.atari2600land.com/mrultra/mrultrapictures.zip

sverx Joined: 05 Sep 2013 Posts: 3794 Location: Stockholm, Sweden	Posted: Tue Nov 03, 2015 10:18 pm
	I suggest you start working on your second game taking advantage of what you learnt doing this one. Don't forget ramsections.

psidum Joined: 01 Jan 2014 Posts: 331	Posted: Wed Nov 04, 2015 6:31 am
psidum Joined: 01 Jan 2014 Posts: 331	Impressive and in such a short time frame :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14726 Location: London	Posted: Wed Nov 04, 2015 7:45 am
	sverx wrote Don't forget ramsections. In a brief play with the code, it was clear that PSGLib's use of ramsections is quite hard to mix with other methods of RAM control. I'm not convinced that RAM sections are useful for Sega 8-bit use as they are intended, i.e. swappable chunks for memory reuse in blocks. As a library, I think PSGLib should try to live with a definition or label as the bootstrap to its memory use, as Mod2PSG2 does, to put less restrictions on the user.

sverx Joined: 05 Sep 2013 Posts: 3794 Location: Stockholm, Sweden	Posted: Wed Nov 04, 2015 8:55 am
	On the contrary, I see ramsection as the perfect way to lift the burden of defining each variable at a constant position, with its risk of overlap, and in a more efficient manner. Even if you don't need to swap chunks, using ramsections you can separately declare variables in each of your asm sources and keep things simpler. Finally, I believe libraries (such as PSGlib) should never use memory at a fixed address, both ROM or RAM.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14726 Location: London	Posted: Wed Nov 04, 2015 6:48 pm
	I mean to allow the user to define a symbol like PSGLibRAM, which is the first byte used, by whatever means they like and you define all your memory relative to that. Unfortunately ramsections require you to define a suitable memory map with RAM in the correctly numbered slot. I tend to use enums instead due to some stuff not working with ramsections (e.g. defines referencing items).

Niloct Joined: 25 Dec 2005 Posts: 607 Location: São Paulo - Brazil	Posted: Thu Nov 05, 2015 12:09 am
	Gamegearguy wrote The holes are sprites. There is an ending after the 7th level. The trick to getting past the corn is to wait until they come closer, then jump over them and press right when they're closer to the left edge of the screen. Thanks for the compliments. Ah this trick! Finished the game, thanks for the fun.

sverx Joined: 05 Sep 2013 Posts: 3794 Location: Stockholm, Sweden	Posted: Thu Nov 05, 2015 9:31 am
	Maxim wrote I mean to allow the user to define a symbol like PSGLibRAM, which is the first byte used, [...] I got it, I'll try to add a note and some code to switch away from ramsections if the user wants it... edit: update released. It shows how to use a WLA-DX .enum section instead of a .ramsection

Forums

View topic - Mr. Ultra: a Game Gear WIP