Wow...4k sure is counter productive

[rpgfaker]

No wonder most games are one screen. Looks like my project needs a complete re-evaluation of priorities to save some space for sound fx and enemy AI...bummer

[Impaler_26]

No wonder most games are one screen. Looks like my project needs a complete re-evaluation of priorities to save some space for sound fx and enemy AI...bummer

Why don't you just make it 8k or 16k?

[rpgfaker]

No wonder most games are one screen. Looks like my project needs a complete re-evaluation of priorities to save some space for sound fx and enemy AI...bummer

Why don't you just make it 8k or 16k?

 

What and break the sacred first game is 4k pledge ...never!

[Nukey Shay]

Sometimes all it takes is to rethink how things are done (not necessarily the order they are done in)...even "small gainers" begin to add up in 4k. If the Y register is used as an index to ram, try to use X to implement it (as opposed to A...which wastes a byte), or change the register...that sort of thing. If empty loops are used to waste time, check if tasks that eat up the same amount of time can be placed there instead. Use unconditional branches instead of jumps whenever you can. If a number of values are "hard coded" to be stored in succession, use a loop (and reorganize ram allocation to do so). If you have variables that are used once and then thrown away (often like score digit pointers), stick them in upper ram so that this ram can be used for stack space afterward...allowing you to nest subroutines to save more space.

 

Regarding subroutines, you can reclaim a lotta space if a specific one is called many times by changing it to be a BRK interrupt instead.

 

Also, audio registers do not use all bits (C and V use only the lower nybble, F uses only 5 bits). So if audio data tables are used, they can often be merged with other data. By the same token...color values do not use the lowest bit, so that can be used to hold another attribute. Programs often feature data tables that can at least share the upper or lower byte(s) with other data.

 

 

Those tricks always work when hacking games For homebrews, I suggest that you subscribe to Stella if you haven't already...so you can get feedback from the brainiacs over there. At the very least, post up some snippets in the programming/homebrew forum that you suspect are wasting space.

[Impaler_26]

No wonder most games are one screen. Looks like my project needs a complete re-evaluation of priorities to save some space for sound fx and enemy AI...bummer

Why don't you just make it 8k or 16k?

 

What and break the sacred first game is 4k pledge ...never!

Yep, that's a good point!

 

If your game doesn't use scrolling you can save a few hundred bytes (IIRC) if you don't include the pf_scrolling.asm module.

 

Just open the includes.bB file in your bB folder, delete the pf_scrolling.asm line and save it.

[MausGames]

Uh oh, someone forgot their "bB inside" disclaimer, but the second half of that is def useful information NS, thanks!

 

PS - That 4k rule soooo doesn't apply to bB, bankswitching and code management are cake...

Edited January 21, 2009 by MausGames

[rpgfaker]

Uh oh, someone forgot their "bB inside" disclaimer, but the second half of that is def useful information NS, thanks!

 

PS - That 4k rule soooo doesn't apply to bB, bankswitching and code management are cake...

 

Dang! ..and I would have got away with with it if it hadn't been for these kids and that pesky pooch.

[rpgfaker]

Sometimes all it takes is to rethink how things are done (not necessarily the order they are done in)...even "small gainers" begin to add up in 4k. If the Y register is used as an index to ram, try to use X to implement it (as opposed to A...which wastes a byte), or change the register...that sort of thing. If empty loops are used to waste time, check if tasks that eat up the same amount of time can be placed there instead. Use unconditional branches instead of jumps whenever you can. If a number of values are "hard coded" to be stored in succession, use a loop (and reorganize ram allocation to do so). If you have variables that are used once and then thrown away (often like score digit pointers), stick them in upper ram so that this ram can be used for stack space afterward...allowing you to nest subroutines to save more space.

 

Regarding subroutines, you can reclaim a lotta space if a specific one is called many times by changing it to be a BRK interrupt instead.

 

Also, audio registers do not use all bits (C and V use only the lower nybble, F uses only 5 bits). So if audio data tables are used, they can often be merged with other data. By the same token...color values do not use the lowest bit, so that can be used to hold another attribute. Programs often feature data tables that can at least share the upper or lower byte(s) with other data.

 

 

Those tricks always work when hacking games For homebrews, I suggest that you subscribe to Stella if you haven't already...so you can get feedback from the brainiacs over there. At the very least, post up some snippets in the programming/homebrew forum that you suspect are wasting space.

 

Thanks Nukey Shay I do need to work on a more efficient algorithm to crunch some space even if I'm using bB right now it still applies...and when the bB version is done I'll try this in .asm so I can still use all these tips!

[rpgfaker]

No wonder most games are one screen. Looks like my project needs a complete re-evaluation of priorities to save some space for sound fx and enemy AI...bummer

Why don't you just make it 8k or 16k?

 

What and break the sacred first game is 4k pledge ...never!

Yep, that's a good point!

 

If your game doesn't use scrolling you can save a few hundred bytes (IIRC) if you don't include the pf_scrolling.asm module.

 

Just open the includes.bB file in your bB folder, delete the pf_scrolling.asm line and save it.

 

Wow never knew that a module not being used actually uses up space (maybe I'll stash it somewhere for future games!)

[SeaGtGruff]

No wonder most games are one screen. Looks like my project needs a complete re-evaluation of priorities to save some space for sound fx and enemy AI...bummer

Why don't you just make it 8k or 16k?

 

What and break the sacred first game is 4k pledge ...never!

No, no, no! The sacred pledge is "First game is 2k"!

 

Michael

[rpgfaker]

2k!

 

Oh and I tried removing the scrolling module but the file won't compile without it... I guess it's staying

[Impaler_26]

Oh and I tried removing the scrolling module but the file won't compile without it... I guess it's staying

It doesn't work the way i remember as it seems...

 

EDIT: Here's how it really works - http://www.randomterrain.com/atari-2600-me...ml#includesfile

Edited January 21, 2009 by Impaler_26

[+selgus]

Sometimes all it takes is to rethink how things are done (not necessarily the order they are done in)...even "small gainers" begin to add up in 4k. If the Y register is used as an index to ram, try to use X to implement it (as opposed to A...which wastes a byte), or change the register...that sort of thing. If empty loops are used to waste time, check if tasks that eat up the same amount of time can be placed there instead. Use unconditional branches instead of jumps whenever you can. If a number of values are "hard coded" to be stored in succession, use a loop (and reorganize ram allocation to do so). If you have variables that are used once and then thrown away (often like score digit pointers), stick them in upper ram so that this ram can be used for stack space afterward...allowing you to nest subroutines to save more space.

 

Regarding subroutines, you can reclaim a lotta space if a specific one is called many times by changing it to be a BRK interrupt instead.

 

Also, audio registers do not use all bits (C and V use only the lower nybble, F uses only 5 bits). So if audio data tables are used, they can often be merged with other data. By the same token...color values do not use the lowest bit, so that can be used to hold another attribute. Programs often feature data tables that can at least share the upper or lower byte(s) with other data.

 

 

Those tricks always work when hacking games For homebrews, I suggest that you subscribe to Stella if you haven't already...so you can get feedback from the brainiacs over there. At the very least, post up some snippets in the programming/homebrew forum that you suspect are wasting space.

While I agree all this information is gold when trying to hack an existing game ROM to change it's behavior, I would say for developing a new title today on the 2600, it is less relevant.

 

The whole 4K issue was based around design decisions made 30 years ago, and when there was a difference in cost of a 4K ROM vs. 8K vs. 16K, etc. Today this does not really apply. We also have methods, well documented, of how to use bank selection. So unless it is something you wish to prove, spend time working on your game and not trying to make the ROM code fit into an artificial constraint (IMHO).

 

Now, if you are using these kinds of techniques to save cycles, then I am totally with you.

--Selgus

[roland p]

Jay Miner would have agreed with you

 

In order to save money, Atari limited the cartridge connector to 24 pins, omitting read-write and clock lines for RAM, as well as lines for addresses greater than 4096. Mr. Miner and Mr. Decu ir agreed in retrospect that this decision was a mistake, since a 30-pin connector would have cost only 50 cents for each VCS and 10 cents a cartridge and would have allowed both RAM and a 64-kilobyte address space.

http://www.atariage.com/2600/archives/desi...l?SystemID=2600

 

But the 6507 only has 13-bit (8K) address space? Maybe he already thought about some bankswitching logic inside the atari...

[supercat]

But the 6507 only has 13-bit (8K) address space? Maybe he already thought about some bankswitching logic inside the atari...

 

Or else about using a full 6502. Not sure which he was considering; bank-switching on systems with proper timing signals would hardly have been unknown, though I wouldn't see much reason not to put the bank-switch logic in the carts themselves.

[Nukey Shay]

While I agree all this information is gold when trying to hack an existing game ROM to change it's behavior, I would say for developing a new title today on the 2600, it is less relevant.

 

The whole 4K issue was based around design decisions made 30 years ago, and when there was a difference in cost of a 4K ROM vs. 8K vs. 16K, etc. Today this does not really apply. We also have methods, well documented, of how to use bank selection. So unless it is something you wish to prove, spend time working on your game and not trying to make the ROM code fit into an artificial constraint (IMHO).

 

Now, if you are using these kinds of techniques to save cycles, then I am totally with you.

--Selgus

 

...or trying to work within the native limitations. That challenge will always be there...not to mention 1k competitions.

[+selgus]

While I agree all this information is gold when trying to hack an existing game ROM to change it's behavior, I would say for developing a new title today on the 2600, it is less relevant.

 

The whole 4K issue was based around design decisions made 30 years ago, and when there was a difference in cost of a 4K ROM vs. 8K vs. 16K, etc. Today this does not really apply. We also have methods, well documented, of how to use bank selection. So unless it is something you wish to prove, spend time working on your game and not trying to make the ROM code fit into an artificial constraint (IMHO).

 

Now, if you are using these kinds of techniques to save cycles, then I am totally with you.

--Selgus

 

...or trying to work within the native limitations. That challenge will always be there...not to mention 1k competitions.

Writing a modern game with only 128 bytes of memory is enough challenge for me.

--Selgus

[elad]

No wonder most games are one screen. Looks like my project needs a complete re-evaluation of priorities to save some space for sound fx and enemy AI...bummer

Why don't you just make it 8k or 16k?

 

What and break the sacred first game is 4k pledge ...never!

Yep, that's a good point!

 

If your game doesn't use scrolling you can save a few hundred bytes (IIRC) if you don't include the pf_scrolling.asm module.

 

Just open the includes.bB file in your bB folder, delete the pf_scrolling.asm line and save it.

wow thanks for the tip deleteing that one line saved me almost 200 bytes, now to implement more features

[ScottHuggins]

>Uh oh, someone forgot their "bB inside" disclaimer,

 

MausGames, please expand on this. What exactly are you implying?

[SeaGtGruff]

>Uh oh, someone forgot their "bB inside" disclaimer,

 

MausGames, please expand on this. What exactly are you implying?

He was implying that the first half of Nukey Shay's response (see below) was aimed at assembly coders, and wasn't really something that (many) batari Basic programmers would probably be able to benefit from, or even control, in their batari Basic programs. Of course, batari Basic does allow in-line assembly code to very easily be included in batari Basic programs, either interspersed between batari Basic statements, or in custom include files. But if you're using batari Basic statements, then batari Basic will compile those statements into assembly code according to the way the compiler is programmed to convert them, and there's not a whole lot you can do about it-- other than pull up the assembly code after the batari Basic program has been compiled, edit the compiled assembly code, and use DASM to assemble the edited assembly code.

 

I believe this is what MausGames was referring to in Nukey Shay's post:

 

Sometimes all it takes is to rethink how things are done (not necessarily the order they are done in)...even "small gainers" begin to add up in 4k. If the Y register is used as an index to ram, try to use X to implement it (as opposed to A...which wastes a byte), or change the register...that sort of thing. If empty loops are used to waste time, check if tasks that eat up the same amount of time can be placed there instead. Use unconditional branches instead of jumps whenever you can. If a number of values are "hard coded" to be stored in succession, use a loop (and reorganize ram allocation to do so). If you have variables that are used once and then thrown away (often like score digit pointers), stick them in upper ram so that this ram can be used for stack space afterward...allowing you to nest subroutines to save more space.

 

Regarding subroutines, you can reclaim a lotta space if a specific one is called many times by changing it to be a BRK interrupt instead.

Michael

[+SpiceWare]

What and break the sacred first game is 4k pledge ...never!

What pledge? My first game was 32K, while my second game 12k.

[supercat]

But the 6507 only has 13-bit (8K) address space? Maybe he already thought about some bankswitching logic inside the atari...

 

Or else of using a 6502. Actually, 13 address lines would be plenty if the system did a couple other things to ease cartridge design:

 

-1- Run the phi2 and r/w signals to the cartridge port.

 

-2- Add some gates so the TIA and RIOT would only be mapped in pages 0-3 (or maybe 0-1, or 0-7). Possibly send a couple decodes out to the cartridge port.

 

Combined with the above, phi2-qualified decode signals that would go low on any access to $0400-$07FF and $0800-$0FFF, would make it very easy to make a bank-switched cartridge with 2K RAM, using only 3 chips. Or an unbanked cart with 2K RAM with two chips (the RAM and the ROM). All nice and easy.

[yuppicide]

My sacred pledge for you..

 

Just make games and make them available to people. Don't worry about RAM/ROM. Just make it happen.

[EricBall]

When I developed Skeleton a bankswitched cartridge wasn't an realistic option if I wanted cartridges made as the circuit boards didn't exist. (Just recycled commons with a 7404 hacked on.) These days, that's not an excuse. However, there is something ... satisfying ... about managing to fit your dreams into 4K.

 

Places to look for space savings:

#1 Lookup tables can consume significant ROM. See if there is a way to replace them programatically. In Skeleton I had a lookup table which was used to cycle the color of the skeleton when it was killed. In Skeleton+ I replaced that lookup table with calls to the random number routine. The final effect wasn't the same, but was close enough.

#2 Sometimes the reverse is also true - long & clumsy code can be replaced with a smaller lookup table - especially if the number of input values is small.

#3 Don't be afraid to ask for help from the community - there are some really good coders out there who are willing to share their tricks.

#4 Never lose sight of the end objective - create a game that is fun to play. 4K is a great objective, but if the game will be twice as fun if you go bankswitched...

[carmel_andrews]

Not too sure about a 2600 running more then 16/32k or a 6502, thats why they created the A8 hardware