NESDev Compo - Front End idea

[NESHomebrew]

A facebook friend posted this up today. It's an ebay listing for a famicom original pirate/homebrew cartridge. It is roughly modeled after windows XP. Has anyone ever seen this before? I can't seem to find any info on it.

http://www.ebay.com/itm/NES-Famicom-Nin ... 228794777?

I thought this would be a cool idea for a homebrew competiton front-end (maybe even do linux/windows editions).

That being said, any interest in another competition? The cartridge sales seem to be going well.

[infiniteneslives]

That being said, any interest in another competition? The cartridge sales seem to be going well.

Yes we are doing pretty well, it would be nice to see us get the ball rolling on another IMO. The winter months are the best time for most people as well.

[tokumaru]

The winter months are the best time for most people as well.

It won't be winter for everyone who joins the competition though, since there are people in the southern hemisphere, such as myself, who like to code for the NES.

[Bregalad]

The winter months are the best time for most people as well.

Oh no, god no.
I have several projects to finish in december, a wave of exams in december, and a wave of exams in january, and I have to spend time with my family in between.
So no, winter is possibly the worst time for me.
However february-march should be the best time for me as it's usually quiet in the study department.

[tepples]

I haven't seen this "Windows XP". I wonder if it's anything like Windows 98 or Windows 2000, designed for one of those keyboard famiclones. For something without a mouse and keyboard, we might instead want to try something a little more "metro" like the Windows or Xbox 360 start screen. And given the NES's limited capacity for different color palettes on one screen, I wonder what advantage that would bring over the existing Action 53 UI.

It also means we'd need to come up with homebrew clones of well-known Windows games. I've made mockups of the graphics.

[NESHomebrew]

It also means we'd need to come up with homebrew clones of well-known Windows games. I've made mockups of the graphics.

I'm pretty sure that an open source minesweeper clone already exists, but it could definitely use some polishing. From the videos it looked like most of the "programs" were just mockups anyway. I'm also not saying that this would be any better or worse than A53, but it wouldn't hurt to do something completely different for future releases.

As for the competition start date, I'd say that 2013 doesn't have much time left and I'd personally make it a 2014 competition. That should give us plenty of time to get better organized.

[infiniteneslives]

As for the competition start date, I'd say that 2013 doesn't have much time left and I'd personally make it a 2014 competition. That should give us plenty of time to get better organized.

How much time do we want to allow for the compo? If we only want to give 2-3 months I think going with early next year would be a good idea. Although I'd say we should iron out the details and such now and announce that it's coming up with whatever details we have planned. People can always start early if they'd like. We just wouldn't open up a registration of any sort or officially announce prizes. That and people could make plans to wrap up their current projects in the next couple months so they have those 2-3 months 'free' for development.

That time frame would allow for cart releases to happen around the same time they did this year ~early summer. I think that's a good time of year to do it off setting with the holidays. It also makes it easier to build up in preparation for the holidays if we want to capitalize on carts sales as gifts.

It'd be nice to have an annual routine of this so we don't hum haw around till we make the decision to go for the next one. The same time of year isn't going to be idea for everyone. But a regular schedule allows some assurance to people that there will be an upcoming compo. If they'd like to get an early start during the winter months for those on the bottom of the globe or other school obligations etc. It's hard to be motivated to start early when there hasn't been any plan for the next one.

Here's my proposition:
Compo announced with basic plan (not in stone): Nov 1st
Official compo details announced set in stone: Dec 1st
Compo officially starts, registration opens: Jan 1st
Compo ends, all entries due: April 1st
Winners announced, prizes paid out: May 1st
Final rom/menu/hardware/label of cart ironed out: June 1st
Carts open for sale: July 1st

This is something that sounds like it could work year in and year out. We might not always be perfect, but it's better than keeping ourselves from going 3 years without a compo.

Thoughts?

On the other subject the windows/OS idea and solitare/minesweeper sounds kinda fun. Even if it was just to change the looks of the current A53. The whole login and high scores type setup would require some battery ram/nvm write access though to be done right. Part of me thinks we should make it our own branding though, and give the illusion of an OS as we see fit instead of copy-catting microsoft products and branding.

[NESHomebrew]

Dates look good to me. Anyone else have any ideas?

[tepples]

If we were to go all out on this Windows-themed shell, we'd probably need to run an "app" contest in parallel with the "game" contest. The lack of a keyboard on 72-pin consoles might pose a barrier though. Entries would need a quit feature that copies mapper reset code to RAM and runs it:

Code: Select all

  ; Action 53 mapper reset code, untested, as small as possible
  ldx #$80
  ldy #$00
  stx $5000  ; bank mode
  sty $8000  ; 32K game size, 32K PRG bank size, 1-screen mirroring
  inx
  dey
  stx $5000  ; outer bank number
  sty $8000  ; last bank
  jmp ($FFFC)

And with apps, we'd need to have some sort of expanded save functionality. The Action 53 mapper supports a mode where writes to $8000-$FFFF do absolutely nothing: game size 32K, inner bank size 32K (AOROM/BNROM), $5000 pointed at inner PRG bank register ($01). So with appropriately small-sector flash memory, we could consider a file system oriented toward in-circuit reprogramming of the PRG flash. The builder already includes an option to reserve the first few 32K banks for other purposes.

[infiniteneslives]

The Action 53 mapper supports a mode where writes to $8000-$FFFF do absolutely nothing: game size 32K, inner bank size 32K (AOROM/BNROM), $5000 pointed at inner PRG bank register ($01). So with appropriately small-sector flash memory, we could consider a file system oriented toward in-circuit reprogramming of the PRG flash. The builder already includes an option to reserve the first few 32K banks for other purposes.

That is the same method I used to flash the second batch of carts which used my v2.0 boards. I used SST39SF040's which have a uniform 4KB sector mapping. That should be sufficiently small. Although that assumes we stay under 512KB which probably isn't an option. My v1 boards have support for up to 1MB of PRG, but that would put us on a MX29F800C That one's architecture isn't uniform. See page 5 of the datasheet, most sectors are 64KB. The first (or last) 64KB are split up into 4 smaller sectors. One 32KB, two 8KB, and one 16KB.

If we needed more than 1MB, it would probably be prudent to completely overhaul and switch to SPI flash. Looking at the datasheet I have of a 2MB SPI flash it has 64KB sectors. Then sprinkled throughout there are 6 sectors that are broke down into 16 separate 4KB sectors.

[tepples]

Individual bytes can be reprogrammed from $FF to any other value without erasing, right? If we end up going with a 2 MB memory, we can reserve four of the 64K pages for a log-structured file system. Files aren't erased or rewritten; instead, a newer version of the file is appended. At any given time, one page is always kept blank. Then once all but one of the pages have become full, the file system copies any non-superseded files in the page with the most superseded files to the blank page and then erases the old page.

I just wonder what kind of "apps" we can make without a keyboard or a mouse. The classic video game store near me doesn't carry the Super NES Mouse, even if it does have extra Mario Paint carts to store an extra drawing. Someone would have to come up with a proof of concept of a refinement of Valve's "flower" IME for text entry.

[infiniteneslives]

Individual bytes can be reprogrammed from $FF to any other value without erasing, right? If we end up going with a 2 MB memory, we can reserve four of the 64K pages for a log-structured file system.

Yes you can even program bits individually. So you can make a 8 value (psuedo 3-bit) counter from a single byte. So you could use a combination of bytes as a large counter to point to the most recent data block in the sector. You could set it up so the counter was exhausted at the same time all the data blocks in the sector were. Then you could then erase the sector and start over or move to the alternate sector. That might not be the best if there are multiple apps and files though. But it gives the idea of what's possible with a single sector to reduce the erase cycles.

When you start thinking about complex file structures like this the concept of an OS starts to be come legitimate. If you want multiple apps written by various people to utilize the file system you have to either give them their own sector, or have an OS to interface with that handles the file structure for them. With the cost of SPI you could easily afford giving each app it's own 4KB sector (or even two of them for that matter) and just let them use it however they pleased. That becomes a little expensive with parallel memory though. Using SPI could work with suppling a library, whereas parallel you'd want an OS to handle things if you had more than 2-3 apps.

[NESHomebrew]

Incorporating the SNES mouse as an "app" selection tool would be pretty epic. Would it be possible to use the zapper as well? That would step things up a notch. These would open the doors to what kind of apps you could make if the OS had built in zapper support.

[tepples]

Incorporating the SNES mouse as an "app" selection tool would be pretty epic. Would it be possible to use the zapper as well?

The current Action 53 menu can be operated with a mouse in port 1 or a Zapper in port 2. I did this so that people could plug in two mice for Thwaite or two Zappers for ZapPing.