2014 NESDev Compo - Guidelines/Rules

Moderator: Moderators

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 2014 NESDev Compo - Guidelines/Rules

Post by tokumaru »

pops wrote:Possibly just 8 bytes? I wouldn't say no to 16 though!
For such a small amount of data, couldn't you make do with passwords?
pops
Posts: 91
Joined: Sun Apr 04, 2010 4:28 pm

Re: 2014 NESDev Compo - Guidelines/Rules

Post by pops »

tokumaru wrote:
pops wrote:Possibly just 8 bytes? I wouldn't say no to 16 though!
For such a small amount of data, couldn't you make do with passwords?
Of course - although 8 bytes (12-16 char password) is really the longest password I'd consider. Just asking. Don't know if it's even possible with the hardware - but possibly some spare flash?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by infiniteneslives »

It's possible with the hardware on the cart. The main thing is software support. Part of the trouble is sector size of 4KB. You can't erase anything smaller than 4KB, although you can program one byte at a time. I don't think we want to give each entry their own 4KB to use solely for saves. If we were interested in this, the best way to handle that would be to setup something through a OS style interface with the multicart software. That would be up to what Tepples thinks about setting up something like that.

Another less versatile, but easier route would be to designate a bank for free range for all entries. If you toggled between games that also used that space they'd stomp on eachother. But if the player stuck with only the one game then perhaps that'd be a shortcut to entering the password each time. I would still have a password in that case though to allow for recovery post-stomping. We had discussed designating a bank or few to the bootloader, so perhaps just opening that to anyone would work.

The main trouble with developing saves on flash is that the only real way to test things working is on the end hardware. I can make blank mapper28 boards available to aid in development if people would like. Things can be a little tricky because the save routine needs to operate from system SRAM because flash is not readable while programming. That and a poorly written erase routine could brick the cart or a given game on the cart if the wrong sector was erased unintentionally. There are ways to prevent that, but that's why I'm thinking a OS helper routine could go a long way.

Tepples, here are my thoughts on such a helper routine I'm thinking about. Let me know what you think:

Small chunk of assembly code provided to all. This would be the same routine for every entry which choose to use save flash. Perhaps the most universal routine would be one that copied itself to SRAM. The main reason for putting it in SRAM isn't because of the flash operation, but because the OS will have to be bank-switched in which isn't universal for all entries. The programmer would have to be aware that they'll loose that block in SRAM. Perhaps they could be responsible for storing any vital info in chr-ram temporarily. This could be the same location (or same address range) which the OS will operate from while storing/loading save data. This makes it a little simpler for the game as it only needs to worry about one chunk of SRAM which will be stopped on by the OS.

The programmer would have to pass a few variables into the OS. So specifing a location in SRAM for these variables would be needed. Perhaps something like these:
game number- OS needs to know how to setup banking to return to game.
slot number- slot number in the eyes of the game. The OS would determine end location based on slot number and game number. This could allow us to give one game more than one slot if needed.
save/load- tell the OS whether you're saving or loading the data into or out of flash
current bank- for games which utilize bank switching the OS may need to know which bank to initialize the game back to, as the OS may have stomped on the current bank number.

The save size would be a specified size and location of SRAM. So the programmer has to put the save data there before calling the OS if it's not normally there. And the programmer knows that's where they'll find the save data when loading.

This would keep flash operations the sole responsibility of the OS. And the programmer would 'simply' have to follow the rules above.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by tepples »

I could make something like that, but nowhere near in time for this compo's deadline. Maybe for the next compo?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: 2014 NESDev Compo - Guidelines/Rules

Post by lidnariq »

infiniteneslives wrote:Part of the trouble is sector size of 4KB. You can't erase anything smaller than 4KB, although you can program one byte at a time. I don't think we want to give each entry their own 4KB to use solely for saves. If we were interested in this, the best way to handle that would be to setup something through a OS style interface with the multicart software. That would be up to what Tepples thinks about setting up something like that.
The obvious system for that is some kind of log-structured filesystem. Although with only 2K of RAM, some of which needs to be reserved for the flash write routine as well as everything that needs to be written back to flash after an erase, it might get kinda cramped...
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by Memblers »

pops wrote:
tokumaru wrote:
pops wrote:Possibly just 8 bytes? I wouldn't say no to 16 though!
For such a small amount of data, couldn't you make do with passwords?
Of course - although 8 bytes (12-16 char password) is really the longest password I'd consider. Just asking. Don't know if it's even possible with the hardware - but possibly some spare flash?
Yeah it's possible, but you can't use just 8 bytes. The data is written as individual bytes, but is erased in sectors. You can only write to the blank parts (changing 1s to 0s). I'm guessing this board would be using 4kB sector sized flash. In that case, you just reserve a 4kB bank in your program. On a 4kB boundary of course, such as $8000-$8FFF. For your save data you'd make a block like 16 bytes or whatever, including a blank ($FF) byte for a flag. When you save the latest data, you clear that flag on the old block(s). So when you load, you would scan through the data to find the most recent save. When the sector is full, delete it and start over.

Wouldn't be hard at all to have multiple games share the same kind of memory space. Include an identifier in the block, the game ignores blocks that don't match it's own. Identifier could be a CRC or checksum of the program, if it needed to be automated.
infiniteneslives wrote: The main trouble with developing saves on flash is that the only real way to test things working is on the end hardware.
I don't think it's a problem. One should isolate the the write byte and erase sector routines. Those parts are straight-forward, and are also the only parts that are specific to the memory type. IOW I'm saying that this kind of filesystem is equally useful for SRAM or Flash.
lidnariq wrote:The obvious system for that is some kind of log-structured filesystem. Although with only 2K of RAM, some of which needs to be reserved for the flash write routine as well as everything that needs to be written back to flash after an erase, it might get kinda cramped...
The solution for that is to use 2 sectors. Then it can copy over the blocks that aren't flagged for deletion, before erasing. This is fine with large sectors. I was just looking at one I like that has 128kB sectors.. 1024 of them, heheh.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by infiniteneslives »

infiniteneslives wrote:
Use of existing tools/libraries/code qualify as long as permission has been granted by the author.
What about open source, openly shared code? So long as licensing requirements are upheld, would it not be okay to use especially things like generic libraries and such? Or if someone took a hello world example, or nerdy nights tutorial do we want to discourage things like that?
Was there any consideration to this? Or did I miss something?

In other news, it sounds like we might be able to support a 60pin release of these cartridges as well. I'm planning on making a 60pin version of the boards used for this multicart since new shells were recently found.

I wouldn't expect a 60pin release to debut at the same date as the 72pin release. But hopefully I'll have the boards complete by summer and we can release a 60pin version of action53 v1/v2/etc by the end of the year.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
NESHomebrew
Formerly WhatULive4
Posts: 418
Joined: Fri Oct 30, 2009 4:43 am
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by NESHomebrew »

tepples wrote:If your library is under a free software license, then the license itself is proof that "permission has been granted by the author". For example, anything copied out of Zap Ruder, such as controller and Zapper reading code, is under the GNU Permissive License.
I thought this was sufficient so I didn't add any more comments. It's obviously going to be difficult to tell if code has been directly ripped from another source. I wouldn't go as far as requiring written consent to use code, since most if not all code out there is released for others to use. However if you took existing code, changed some sprites and backgounds, added a few features, that wouldn't be allowed. If you got help, give them credit. Most of us wouldn't be here if it wasn't for other peoples code, and most people release with some sort of free licensing like Tepples mentioned.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by infiniteneslives »

Fair enough, just wanted to make sure we're on the same page.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: 2014 NESDev Compo - Guidelines/Rules

Post by zzo38 »

lidnariq wrote:The obvious system for that is some kind of log-structured filesystem. Although with only 2K of RAM, some of which needs to be reserved for the flash write routine as well as everything that needs to be written back to flash after an erase, it might get kinda cramped...
Maybe you can use CHR RAM and CIRAM as extra RAM too if needed, while rendering is turned off. Mapper 28 is supporting four CHR RAM banks, so maybe this could be used too.
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 2014 NESDev Compo - Guidelines/Rules

Post by tokumaru »

zzo38 wrote:Maybe you can use CHR RAM and CIRAM as extra RAM too if needed, while rendering is turned off.
That's an interesting idea. Only the saving routine itself must be at $000-$7ff, while the data to be saved could be read from VRAM. It should be trivial for a game to restore the contents of VRAM after a save. The only problem I see is the complete lack of visual feedback on the saving process. If it takes longer than a couple of seconds, players will find a blank screen weird.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: 2014 NESDev Compo - Guidelines/Rules

Post by zzo38 »

tokumaru wrote:
zzo38 wrote:Maybe you can use CHR RAM and CIRAM as extra RAM too if needed, while rendering is turned off.
That's an interesting idea. Only the saving routine itself must be at $000-$7ff, while the data to be saved could be read from VRAM. It should be trivial for a game to restore the contents of VRAM after a save. The only problem I see is the complete lack of visual feedback on the saving process. If it takes longer than a couple of seconds, players will find a blank screen weird.
I did see that problem too. Well, you can use emphasis bits to change the background color. You can also use sound effects if that helps. Couldn't the saving routine be stored in ROM, or am I missing something?
(Free Hero Mesh - FOSS puzzle game engine)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: 2014 NESDev Compo - Guidelines/Rules

Post by lidnariq »

zzo38 wrote:Couldn't the saving routine be stored in ROM, or am I missing something?
No, the flash is unreadable while it's being written, and writing takes several microseconds.
In addition, erasing takes several hundreds of microseconds to several milliseconds, so while the process as a whole should be really fast, it has to run entire from a physically separate memory.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: 2014 NESDev Compo - Guidelines/Rules

Post by Bregalad »

I'm probably going to disappoint everyone (especially my own self), but since my february vacation (where I did an extremely quick advance on the game) is over, I only get a couple of hours of actual free time per week (I have a zillion other things to do each weekend, and I live far away from my workplace, which means leave home at 7 and get back past 7, so I have not many hours and even less energy on evenings to work on this). So chances that I can finish my game by April 1st are extremely slim to nonexisting.

The game's world is complete but empty right now. I basically have to :
- Write the AI of half of random enemies and all bosses (except the first one which is already done)
- Write the music for most of the stages (only several ones are done)
- Do something at the ending
- Play test and balance the game so that the difficulty curve is ok

Chances that I can do all this in mere 2 weeks, even if I do some of the work at work (sigh), are none to slim.

I hope I can release this before May though, so that I can submit it in category #3 and be on the multi-cart ?

I'll probably have to do all of this before May, because all my weekends are extremely busy in May and I have my thesis to write in June which means few to no freetime before July.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by tepples »

Due to various things going on in my life, various collaborators dropping out or returning work late, and other people pushing me to switch to their own pet projects, my entry will be roughly 75% complete by the compo deadline. I plan to push a big update afterward, much as I did with mouse support, practice mode, and rebalancing of late levels in Thwaite.
Post Reply