Action 53 volume 3

I haven't had time to work on this compo's cartridge release because of other obligations, such as something that will see limited release at an upcoming convention, as well as translated version of a previously released game. Heck, I didn't even judge this time.

So anyway, up to 480 KiB of entries will fit on a 4 Mbit cartridge. But we appear to have more than that, and infiniteneslives explained that with a 3 volt memory, we can go up to 32 Mbit.

I'd like to push a very picky recommendation that the anti-aliased text from the Vol. 1 title screen be nixed. Compared to all the sharp, designed-for-crisp-pixels text elsewhere, it ends up looking fuzzy and hasty, even if it represents a technologically more modern way of rendering text.

How long do we have to tidy up our games for the cartridge release?

Do we have a deadline? I mean, to improve the games before release.

Also, I think it would be a good idea to set up a thread where people can submit the updated versions.

Category 1 alone is 17 games and 1 toy, totaling 1*16+2*24+8*40+1*48+6*64 = 816 KiB. That's not even counting what gets submitted to category 2 while I make sure the builder can handle all of them.

In a later post, I plan to break them down by PRG+CHR size, as I can split CHR ROM out into a separate file, compress it, and insert it into unused parts of PRG ROM. But a 4 Mbit release ain't gonna happen.

Yeah, I know SHA-1 was recently SHAttered, but the important part is that my tools spit out one line per 8192-byte CHR ROM bank:



So PRG ROM covers 8 * 12 = 96 KiB. Though the mapper supports CNROM, the current menu software does not, and I imagine that NES emulators with mapper 28 but not NES 2.0 do not either. This is part of why Solar Wars in volume 2 was hacked to UNROM. Sinking Feeling is CNROM, but it could be hacked to NROM.

Wrecking Balls only uses 8230 bytes, the first 4672 of which are raw tile data. Even with sound it should be well under 16K. Maybe even 8K if I can compress/optimize it enough.

I hate to sound like a broken record, but how long do we have to polish the entries up for the multicart? I won't even be able to start on mine for at least another week.

You have at least another few weeks. I have two unrelated projects going on.

Here's a first crack at a multicart of the majority of category 1 entries, packaged as one 8 Mbit ROM to test in emulators and two 4 Mbit ROMs to test on a PowerPak.

Remaining from others:

• Descriptions (16 lines, up to 28 characters each)
• Screenshots, 64x56 pixels, using black and three other NES colors
• Improved ROMs over the next few weeks

Remaining from me:

• Alignment directives for ROMs larger than 32K
• True CNROM support

I see the Rock, Paper, etc title doesn't fit. How about "Rock Paper Scissors" or "Rock Paper Scissors +" or "Rock Paper Scissors..."

And, Sinking Feeling is missing.

Known issue. I'll have to get in touch with INL to see if the board supports the two traces (CHR A13 and A14) needed to enable CNROM support.

Yes, the mapper will have control of chr ram A13-14 reguardless of which of my designs we utilize.

Lol the tabs' text

For SuperTiltBro., the "2 players ONLY" can be fixed by using the version with AI posted in the progress thread.

I'm making a bunch of behind-the-scenes progress in the builder. I haven't got around to proper CNROM support yet, but one big round of refactoring that I did today lets me mix games of different PRG ROM sizes more freely.

After using submultis to combine two pairs of NROM-128 games, I'm getting PRG banks arranged as follows:

Bank 0: 240p Test Suite
Bank 2: Filthy Kitchen
Bank 4: Cheril the Goddess
Bank 6: LaLa the Magical
Bank 8: Twin Dragons
Bank 10: Waddles the Duck
Bank 12: Flappy Jack
Bank 13: Karate Kick
Bank 14: Wo xiang niao niao
Bank 15: Nebs 'n Debs
Bank 16: Brick Breaker + Rock Paper Scissors Lizard Sbock
Bank 17: Jupiter Scope 2 + Super Tilt Bro.nes
Bank 18: Spacey McRacey
Bank 19: The Paths of Bridewell
Bank 20-30: Unused
Bank 31: Menu

Sinking Feeling, Wrecking Balls, and jroatch's toys are currently not included but expected to occupy banks 20-21. I don't see any way to get it under 512 KiB (15 game banks and one menu bank) other than by voting entries off the proverbial island, but at least this shows how much space remains for late (category 2) submissions.

These remain for me:

• Move the title screen out of a fixed place in the menu
• CNROM support
• Ask JRoatch about integrating his toys

Tentatively I want to set the deadline in late March, but that depends on when INL is ready to produce cartridges.

Thanks for the analysis and effort Tepples!

I don't see any good reason to restrict ourselves to 4mbit. We surpassed that threshold with the submitted entries, and all submissions are more than worthy of inclusion on the cartridge. It does cost us a few more dollars in hardware and fine pitched assembly, but it's still well within the budget.

I had the same late March deadline in mind for submissions to have any last min changes and polishing. In reality there probably will be a bit more time for changes bug/fixes before cartridge assembly starts. But March 31st is a good date we can plan to stick with annually so we can always tell devs how much time they have remaining. Anything past that date can't be promised, and it's probably time to start working on next year's compo entry anyway!

How we decide to address printed materials will have a bigger bearing on when cartridges will be able to start production. Specifically if we choose traditional cardboard boxes again which I'm unable to print myself in house. It'll easily take 1-2months to get traditional boxes printed off and in my hands once artwork is finalized. And we effectively need the cartridge rom in release candidate status with final title lineup before artwork can be finalized. For this reason March 31st deadline for rom submissions also makes sense. The alternative to large initial investment and long lead time of traditional boxes is to utilize bitboxes from stoneage gamer that I'm able to print the inserts for in house. Looking back on last volume, it's hard to say the traditional boxes were financially worthwhile. We've only consumed a small portion of the large volume that was printed 2 years ago. But people appreciate them, so perhaps that's good enough, we can just plan to not print as many this time. If we run out of traditional boxes we can always shift over to bitboxes and consider the traditional box limited print.

I plan on printing the cartridge labels in house. And if the manuals are relatively simple I would print them in house as well. If the manual is has more than a couple pages I'd prefer to send them to a print shop with the traditional boxes.

I expect May, and possibly part of June to be consumed by printed material production. Cartridges can be produced in that same time frame. Which means we could expect release in July perhaps. Opting for bitboxes and printing everything in house could pull that date in quite a bit if we preferred. Either way works well with my current schedule.

Just probing for possibilities: Any chance anyone might add a few sprite tiles to the composition?

It's already drawn as sprites because it has to overlap the border of the window where the screenshot is shown without using either MMC5 ExGrafix or a scroll split.

As entrant, do we have to do it, do we can do it or somebody dedicated wants to work for us?

The "screenshot" has to be screenshot like or can it be more like cover art?

I have several *ahem* NOAC handhelds with a built-in multicart. The screenshot for each game is not a full-screen shot (as it would look tiny), but a crop or even a depiction of the game, and I think it looks better. It would work like some sort of mini-cover art using ingame graphics. I was going to produce my shots in such style, but maybe it would feel out of place?

Honestly, the tiny 4-color screenshots are one of my favorite parts of the previous Action 53 entries. Some are quite admirable in the success of their representation, all are interesting to examine and easy to remember once playing the game.

@Roger (or anyone else)
If you'd like a hand with the screenshots, I could make the time to put some together.

Anyone can do it. I did most of them myself for the first two volumes, but now that we're having compos more often and I'm much more busy with other NES programming projects both paid and free, I need help.


The art style I'm trying to ape is that of PlayStation Interactive CD Sampler volumes 7 and later, which actually use a screenshot.

Such as Sampler 9

Earlier Samplers, particularly 3 and 5, use a UI similar to that of its competitor's subsequent Wii Menu, on which nemulator's ROM chooser was based. But I deemed that too intense for NES.

Sampler 5: UI that Wii copied but we will not

Here are the screenshots from the previous volume (some colors may be wrong; click to zoom):

The CNROM support isn't really mandatory for this year, now that we know the date, I can make the NROM conversion before Mar 31. Would be good for next year, though.

Here what I have been able to pull out as screenshot for this evening.

One that I like but is a cropped screenshot:


Another that is ugly but is more in the style of your examples:


Feel free to use it as it is, redraw it or give me clues on how to improve it

I am in favor of the cropped shot. I think stylized art for the game would fit in stylistically as well.

Are the other 3 sprite palettes reserved?

One of the sprite palettes is used to draw the arrow sprite at the top of the screen.

But the real problem is that I'd have to add to the screenshot format some sort of data structure specifying which parts of the screenshot use which palette. This would be a breaking change to the extractor, but then I admit I haven't tested the extractor much anyway.

Wouldn't it be better if the border was made of sprites? Anyway, I don't think that the border is interesting enough that the screenshots have to suffer because of it.

The border would eat all eight sprites, but that doesn't matter because the background already eats all eight sprites.


Would this border look any better?


But seriously now:

Currently each screenshot is converted from a PNG file. If it were instead a background with sprite overlays, how would the location of the overlays be specified?

Want to include a bootloader program? I considered it, but didn't prepare it for the compo since it's unusable without the hardware. Didn't seem appropriate. But I'd be happy to give a USB adapter to any/all interested compo participants. Though I'm having some really weird inconsistent problems with PAL compatibility at the moment.

It would need just a few kB for the program itself, and preferably a blank 32kB page. And I would need to know what flash chip is used. And if there are any other requirements like a reset code stub, etc.

I suppose it wouldn't technically be a bootloader (I mean I suppose you could call it if the NES powers up with some buttons pressed or something). I imagine it would be one of the 'toys', and if you wanted, you could have a menu option that would run the game that's in the bootloaded page.

Is this the same USB to NES controller adapter you gave me a year ago at the interview?

The problem with including a bootloader that can write to flash is that I don't want to let users accidentally mess up their games, causing INL to incur warranty service costs. Or is there a way to make most of the ROM not self-flashable after the cart is fully assembled, analogous to the SL1 write-protection jumper on the Nintendo DS mainboard (keyword: FlashMe)?

I figured that if it's a new page and I'm the lead engineer, I can double post for a status update.

Build-related bugs

The build process involves telling the builder which parts of each 32K bank of ROM are not used, so that reset patches and other games' CHR ROM and screenshots can be stuffed into those areas. Usually I do this by detecting long runs of $00 or $FF bytes. But if the $00 are actually the 64 attribute bytes of a nametable that uses only the first background subpalette, or the end of a lookup table for high bytes of note periods, that can cause unintended behavior.

During initial play testing, I thought several games had bugs due to important zero- or $FF-filled data getting overwritten, but it turned out all these quirks have different causes. I'll report each in the game's own topic later.

• Scrambled map in Cheril the Goddess
  It's just not that visually distinct because it's monochrome.
• Freeze on Game Over screen in Filthy Kitchen
  The unmodified ROM also freezes on my PowerPak.
• Playfield attribute clutter in Spacey McRacey
  I run the unmodified ROM in FCEUX for Windows, fill $23C0-$23FF with value $E8, and reset, and the corruption remains. It isn't initializing the first attribute table at all.
• "X" getting corrupted in Rock Paper Scissors Lizard Sbock
  In FCEUX for Windows, a breakpoint on writes to PPU $0000-$1FFF in the unmodified ROM Rock4.nes shows that the game is overwriting CHR RAM. Flashback to Terriblegate.

Screenshots


Thank you.

Here's the process I followed:

1. Take screenshot in FCEUX
2. In GIMP, crop to 256x224
3. Resize to 64x56, linear (that is, area averaging)
4. If it doesn't look good, move the sprites by a few pixels and try again
5. Choose three colors carefully
6. Paint over the background in a new layer

But we can try a crop to see if that works better.

Mapper support


I spent yesterday getting myself (and FCEUX) ready for next year.

Burn down list

Here's what I know I have left to do. I won't necessarily be able to work on it every day because of other paid and/or free projects.

1. Move title screen out of menu bank
2. Automatic reset patch for non-NROM games (prepend lda #$81 sta $5000)
3. Look for updated versions in all project threads
4. Test for delayed $00 writes in FCEUX 2.2.3
5. Integrate JRoatch's coredump patch
6. Integrate JRoatch's other toys into 240p Test Suite build process

Unless there are objections, I thought it might be best for consistency to have one person handle them all and put these together this morning:

(4 colors each with black in all)
If you need to know which color values these are (for example, which green is each green), these all use colors from the NEStopia YUV (default) palette, so you can cross reference the RGB from an eyedropper, or ask and I can check.

I've set up some Photoshop presets to help speed up the progress, but each screenshot uses different settings (regarding scaling mode, dithering, and locked-in colors) to try to get the best result. (There are two for the 240p test, I think the bars would be better, but I included one of the menu as well.)

Individual files are here.

If I'm missing any, or if we include anything else, let me know and I can provide those as well.

EDIT: 240p screenshot #two updated.
EDIT 2: Updated Group Preview & zip file.

Yes, it's the same USB adapter. I keep saying I'm going to make a better (synchronous) one, but haven't done it yet. When I do make a better one, I'll try to have it start it a backwards-compatible mode, if possible.

Some FlashROMs do include sector write protect, AMD and Macronix at least, but probably not in a form we can use. At least on the 5V ones, enabling protection is kind of like an EPROM, in that you need a 12V VPP or something similar. So you can only use that in a chip programmer, and not in-circuit. Whatever chip is on this board could be totally different though.

We'd be safe with sector erase, unless the mapper has a habit of ignoring mapper writes or changing banks on it's own, which would be strange indeed.
For this version it would be hardcoded to only erase and write whatever sector numbers are reserved for it. The process works like this:
-bootloader copies itself into RAM, then runs there
-waits for valid data packet (CRC16)
-if valid, write bank select register, erase sector, and write it
In this case I would just have it abort if it goes past 32kB or whatever is reserved for it.

I didn't notice this post. My method is similar. First, I saved a Photoshop color table from the NEStopia palette and set a Save for Web optimization preset to only pull colors from that color table.

Then, I…

1. Took a screenshot of each game, trying to get an iconic area with the player sprite in a visible position, but also trying to align scrolling games to the grid so blocks would resize uniformly.
2. Then, in the Save for Web options, I would "lock-in" black, and preview each combination of scaling method (nearest neighbor, bilinear, bicubic) with each dithering option (none, diffusion, pattern) to try to get the best result.
3. If a specific color that I thought would be necessary wasn't showing up, I would manually lock-in that color and check each combination again.
4. Chose the best settings and saved the png.

Only a couple took manual editing. For instance, I darkened some areas in Wrecking Balls and Twin Dragons to allow more black for contrast (for the smaller size) and merged the results from two different settings for Nebs and Debs.

Do you know how awesome you are? Thank you!

You are correct. I was writing to PPU $0000-1fff. Bug in the PPU loader code (it was supposed to write a zero after the end of data = zero bytes to write, so that it would exit the PPU write subroutine...it didn't write a zero... so it assumed the next 2 bytes was a PPU address, it wasn't). Should be fixed now, see official RPSLS thread*. (Rock6.NES)...though I might make lots of changes to the game (including graphics) so any effort you make now to put into the multicart might be a waste of your time.

* viewtopic.php?f=32&t=15481&start=15

We will most likely be using spansion-cypress S29AL/GL series. I'm fairly certain they have no such protection. I'm not really interested in a flash chip that can't be programmed in circuit.

I'm probably going to have to shelf this idea for next year, but I was considering using my new dual port design for the cart release. Was thinking of making all the LE's standalone versions at my own expense with full USB and SDmirco. I'm making good progress with hardware dev but it's been slow going. I'm not expecting I'll have a poslished design fully beta tested and ready for production in time. Not to mention all the software tools to make it useful. Last thing we want is the cart release hung up on half baked hardware.

If there's something I can do in Goddess to solve the issue, tell me. I'm applying the last layers of polish to the game for the cart right now.

EDIT: I like M-Tee's work, but in case crops are prefered, there are mine:

@M_Tee
Sinking's looks quite hard to make out, I wonder if a zoomed shot would represent it better. One attached.

@tepples
Do you still need it converted to NROM?

I'm not surprised. I'll fix it as soon as I get a chance.

Has Nestopia's default palette been exported to a .pal file or an indexed .png file so that I know what to compare with on the eyedropper? If not, I could try to build Nestopia on my laptop. Some of these look fairly dark, but that could just be Nestopia.


The dithering on the screenshot with two NES controllers is a bit dirty. And I imagine a lot of the dithering would look even dirtier in NTSC.

I had trouble figuring out what the second from last on the third row was until I applied alphabetical order and realized that black thing was supposed to be Waddles. I would have done some green paintover around it.


Bars like that are very hard to represent in black plus three colors. That's probably why I saw far more than three when I zoomed in on that screen. I had planned on using the Linearity card for that one.


Except you want the mapper to ignore writes while you're writing to the memory behind it. The problem is similar to that for the self-flashable variant of RetroUSB UNROM 512, where a dual 2-to-4 decoder circuit enables flash writes only at $8000-$BFFF, flash reads only when not writing, and mapper writes only at $C000-$FFFF. This allows $C000 to control A18-A14 before each write to flash.

Correct me if I'm wrong, but I imagine that self-flashing in the Action 53 mapper would follow these steps:

1. The mapper needs to generate /OE and /WE.
2. Configure the mapper for 32K game size: $5000=$80, $8000=$00-$03
3. Switch to a 32K bank: $5000=$81, $8000=bank number
4. Select the inner bank register, which causes writes to $8000-$FFFF not to affect the mapper's PRG bank output because the game size is 32K
5. Write commands to $D555, $AAAA, $D555.

By "in circuit" do you mean in a Kazzo device with full expansion pin control or in a stock NES or Famicom?


I'd prefer it. I think self-flashability in the console (without expansion pins) and CHR RAM bank output would both fit in the CPLD, but only INL could confirm that.

Yeah, the darks (0x range) are really dark in that palette, my only major complaint for the palette. I've resisted altering them myself because I don't want to make "yet another NES palette" but most other palettes are horridly oversaturated, so I deal with it.

Anyway, here are some files that might help There is an .aco and an .act file (two different photoshop palette formats) and the nestopia_yuv palette that comes with FCEUX (also included in the zip, but should be in your FCEUX palette folder if you have it installed). The Photoshop files were built using eyedropper selections from an FCEUX screenshot that (I"m 90% sure) used the .pal file included (from the LoopyNES palette ROM). The .aco / .act / and attached png should 100% be using the same palette as the screenshots though.

Oh, and here's another screenshot, with dithering, but with a different scaling mode of those NES controllers.
As for Waddles, I tried to avoid manually touching any of them up as much as I can. It's a slippery slope for me, and I know I'd end up trying to pixel out a lot more than necessary by hand. Feel free to take a go at it though.

As for the 240p screenshot, is that the white circle on black? If so, I pulled a screenshot of that when I did the others, just didn't include it. It's attached as well.

Actually, you saw more colors because I accidentally dithered when I updated the group preview with that screenshot. The solo screenshot in the zip should have always been three colors. Have since updated the group preview, including the cleaner resize of the controller screen.


Edit: typo.

Yeah that sounds about right. That's how it's been setup to date with the kazzo code to flash games during production.



Membler's mentioned something about needing 12v to unlock sectors which is available on neither the kazzo/NES. I prefer to have the kazzo always capable of erasing and reflashing. But with mapper 28's design and my current boards if the kazzo can flash/erase, so can the NES.


Both of those features have been available on all A53 released cartridges to date aside from the very first batch of 50 which used EPROMs. The old XC9536XL implementation utilized 27 of 36 macrocells. With us stepping beyond 4Mbit with 3v flash, the CPLD of choice due to my current board designs will be Mach XO-256 of which we'll only be using a small fraction (~10% perhaps) of it's available resources to implement current mapper 28 definition.

I posted an updated version in the thread about the game. Unfortunately, (like I said there), I'm in the middle of moving, so I haven't yet had a chance to properly test. Just wanted to post this in case I forget about it, in the chaos of moving and selling the old house.

New page, new build:

• Added M_Tee's screenshots
• Put the title screen under control of the builder, as opposed to hardcoding it in the menu binary. This means all three builds (the whole thing for emulators and the two partial builds for PowerPak) get distinct title screens.
• PowerPak partial builds make thematic sense, and section titles in the whole thing reflect it
• Added Sinking Feeling and Wrecking Balls
• Updated Cheril the Goddess to 1.2
• Updated Wo xiang niao niao to 1.2
• Updated Filthy Kitchen to build0209
• Updated Super Tilt Bro. to the version with AI
• Updated Rock Paper Scissors Lizard Sbock to version 6
• Some games will not run correctly in FCEUX prior to r3339

Right now I'm slowly working through redesigning the exit patcher to handle each ROM based on its mapper, not individual 32K banks as if it were still using oversize BNROM.

But it's been a slow process because of several other demands on my time over the past week. These include increased hours at my day job, continued maintenance on a prior paid NES project, multiple birthday parties, outdoor exercise on those few days when the weather in my city isn't cold, wet, or excessively windy, and a roommate who likes to listen to progressive political talk for hours on end at a distractingly loud volume to laugh at U.S. President Donald Trump and insists on vocally sharing both her outrage at successes of the Republican Party and her Schadenfreude at its failures with me.

If only "orange skin, red ball cap, and hair that looks like a bad wig" still meant this fella:


Bumpus Wobbleworks, © Hasbro

Remaining things that I believe only I can do:

• Exit patch each game appropriately for its mapper
• Explain what's confusing about the map screen in Goddess
• Test for delayed $00 writes in FCEUX <= r3338 (e.g. 2.2.2 and 2.2.3)
• Integrate JRoatch's coredump patch
• Integrate JRoatch's other toys into 240p Test Suite build process
• Continue to look for updated versions in all project threads

Remaining things that others more familiar with the games can do better than I:

• Write descriptions for all activities
• Build FCEUX for Windows from SVN, as the interim build is r3338, and the first revision that can correctly run CNROM games in an Action 53 (mapper 28) multicart is r3339

For warranty purposes, should we be concerned if the user flashes code that switches to another bank and overwrites the rest of the cartridge?

I'm getting gibberish tiles for Sinking Feeling (FCEUX 2.2.2).

Yes, there's no fceux release with the mapper fix.

Try r3340, which I'm mirroring. It's newer than the latest interim Windows build on fceux.com (r3338), which in turn is newer than 2.2.3, which in turn is newer than 2.2.2.

I finished revamping exit patching and plan to produce a revised build on the next page. The builder produced this bank map for the full collection:

No, I'm not being immodest by putting my own work first, at least not on purpose. The builder orders ROMs by decreasing patched size, in order to assure correct power-of-two alignment of each game, then alphabetically by filename ("filthy" before "mojon"). CHR data takes essentially no space because several NROM-256 games use less than 20 KiB of PRG ROM.

We appear to have 320K of space for other things, provided we drop Wrecking Balls, I squeeze JRoatch's toys into the 240p Test Suite bank, and I squeeze JRoatch's coredump into the menu bank as suggested.

Anyone up for writing descriptions?

I thought, maybe, you were going to use the blurb to come up with descriptions.

Is there a size maximum (for total words)?

Is it supposed to be a one sentence description?

I haven't had quite as much chance to master playing these entries as I did with those in the first two volumes.



This was a slight simplification, as the actual limit is 128 VWF pixels, but it's close to 28-30 characters in most cases.

It should describe the basics of the scenario and method of play, including controls. Think of the slip of paper that might have been included with a rented game back in the day. If you don't have the first two volumes' ROMs handy, here are a few past examples.

The STREEMERZ description incorporated a correction by the port programmer.


The one for Thwaite mentions controllers.


For Munchie Attack, I used "Burger World" because the logo on the fries resembles that of a fictional quick-service restaurant chain in the animated series Beavis and Butt-head.


I was able to write a description for my cousin's game Double Action Blaster Guys because I was involved in testing it before its release.


RHDE: Furniture Fight needed more detail. But now that I think about it, I think the description of each volume 2 entry must have started with the description from the 2014 compo's page.


Super PakPak is also fairly complex:

Descriptions, like this?

Nebs n Debs - Girls be like, yeah, I got an octopus hat on. You got a problem wid that?

Filthy Kitchen - Boys be like, how come there ain't any clean dishes? No I ain't gonna clean em.

Lala the Magical - Witches be like, I ain't time for no magic class, bzzap. Y'all levitatin and shit.

Cheril the Goddess - Girls be like, can you get the door for me? Next thing you know, they're flying through the ceiling carrying a big rock.

Karate Kick - karate guy be like, I ain't wearin no shoes. I don't want to get your blood on my Adidas. Pa-Yah!

Flappy Jack - Bosses be like, don't spill no shit on my floor, as they tossing pancakes at you from a mile away.

Wo xiang niào niào - Chicks be like, y'all don't mind if I bounce my butt right off your head, right?


This is my attempt at humor.

I managed to come up with basic descriptions based on the blurbs, which I'll include in the next build. I also integrated Coredump and stuck JRoatch's toys into a corner of 240p Test Suite.

"And on the seventh day God rested."

At this point I'm out of things to do. To design the cover art and title screen, we need a theme for this collection. (Goddess and Rock have a little something in common.) Then all I have to do is wait for ROM updates to pour in over the next 19 days. The one I'm most looking forward to is the Rock facelift.

Updated. Probably done.

I don't suppose you've had a chance to re-build with my new version of Spacey McRacey to confirm that my attribute table fix worked?

Yes, it works.

great, thanks!

Here's an updated screenshot for RPSLS.

What is the likelihood of other games/toys being added? If so, are there any particular contenders?

I'm only asking to help with my loose layouts and sketches for cover art.

This might be the last build before the freeze at the end of March.

• Integrated JRoatch's coredump tool
• Exit patches do not set stack pointer, so that coredump (A+B+Reset) can see the stack pointer
• Added rainwarrior's port of "Crowd" to 240p Test Suite
• Put JRoatch's toys in the same bank as 240p Test Suite
• Updated Rock to version 9 (with corresponding screenshot)
• Updated Waddles to 1.1

We still have a quarter megabyte of ROM free for things submitted in the next few days. But I haven't seen anyone submitting more things, and I doubt that I have enough Twitter followers to get a decent response from this notice. In #nesdev on EFnet, alphamule recommended including blargg's serial boot, but I don't have a cable to test that.

I still wonder what's the best way to hide Forty-Two Melody in the menu and make it the Easter egg it's supposed to be.

Thank you for all the work done. I'm sorry that I didn't test this out weeks before, but I'll try my best to test these on a console with PowerPak. I can't guarantee anything though considering that my day job suddenly had me do overtime while ill this last weekend.

I immediately found bugs with my toys, where they do not wait for the button to depress before doing hold button actions. For example entering Button Logger with start keeps the screen blank, pressing a at that point makes it feel like it locked up. Likewise Musical Controller immediately plays a note.


I'll hide it (as best as Free Software can hide anything) in Button Logger, while I fix the bug mention above.

I really wish I can fix up the sound of Musical Controller, I only have at most 3 hours per day this week and I don't know how to ask for help on this.

Edit:
with Karate Kick, sometimes I start with an orange background, and if I press Start before the screen has time to load it's title screen no baddies come.

Edit 2:
Nebs & Debs has the vblank overflow and random deaths talked about in it's thread. I'm guessing this build has a stale version, the current ROM is on the first post titled nebs-n-debs-2-15-2017.nes

I'll edit in this post as I find more bugs.

Easter Egg - you could do a 'no button presses' for a certain amount of time... Like, if you let the screen set idle for 30 seconds in the menu, it will start playing. ?

To easy to activate accidentally for a thing that eats 100% CPU for 8 seconds. Maybe if it's a button combo after waiting?

Is there any button not being used on title ? Select ?

Select + Start ?

Attached is what I think are improved thumbnails for my two things.

I also posted some bug fixes in its thread, and hidden a way to activate that easter egg in that update.

For Button Logger, Is there a way to concisely explain what the B button does?
It makes the logger pause at the top of the plot, but not just an ordinary pause like from the A button, a kind of pause where some input from pad 2 will unpause it. Pressing A and B together will pause for pad 2 input right where it is at instead of waiting to get to the top.

Thanks JRoatch. Yes, please include the newest Nebs Debs build from the thread referenced above

Shit, I only just realized that 2/3 of the music in Karate Kick aren't playing. What gives? I'll try to figure this out by tonight.

@JRoatch: Those are nice looking thumbnails

Vol. 1 seems to be listed in various places with various arrangements of Streemerz (bundle): Action 53 Function 16 volume one. The second is'double action 53 vol. 2"...

Is there an extended title for v. 3 planned?

I almost forgot. If there's free space you can include this little game.

Zombie Calavera (Prologue)

You can play using Santos or Maria. Gameplay is different, but the objective is the same (collect all the glowing crosses).

- Play as Santos: A jumps, B shoots.
- Play as Maria: A jumps, DOWN glide mid-air.

There are bats which will pursue you relentlessly unless you hide. To hide just move behind bushes or trees and stuff. Bats will retreat and that will give you time.

Monsters you kill will transform into bats, so don't kill the monsters unless it's necessary. Bats cannot be killed.

Quickly threw together an improved Karate Kick build.

Thanks both of you. I expect beta to start tomorrow, so get ready to test.

Then the list becomes as follows:

1. Screenshot for Zombie Calavera (Prologue)
2. Figure out sections other than the current "Mojon" and "Not Mojon"
3. Title screen
4. Box art (front, back, sides, label)
5. Manual
6. If there aren't going to be enough games to fill the last quarter (256 KiB) of the ROM, figure out what to stick there: original music or whatever else

I posted (what will almost definitely be) the final Filthy Kitchen build into its progress thread.

viewtopic.php?f=32&t=14936&p=192322#p192322

Jupiter Scope 2 update:
- Dendy mode
- PAL/Dendy emphasis fix
- RGB mode (press Select in title screen)
- Non-Scroll mode (press A in title screen)
- Easy is slower
- Score deals with survival and accuracy
- Some other stuff I cant remember

ONE more change. The sound speeds up now like in the original iOS game.

More life issues have conspired to prevent me polishing up Wrecking Balls in time for the cart. FrankenGraphics and I have agreed we'd rather re-submit a completed version next time around, assuming the rules allow it, or just finish it in our own time. Feel free to drop it.

New stuff:

• Updated Cheril the Goddess to 1.3, Filthy Kitchen to 0284, JRoatch's toys to 03-28, Jupiter Scope 2 to today's build, Karate Kick to today's build, Nebs 'n Debs to 02-15, and Wo xiang niao niao to 1.3
• Updated screenshots for JRoatch's toys
• Added Zombie Calavera (Prototype) and Haunted: Halloween '85 (Mall Demo)
• Removed Wrecking Balls and the menu item for Forty-Two Melody
• Tools improvement: I've made a program to find runs of $00 and $FF in PRG ROM

I've long planned a remix compo devoted to improvements and remakes.

Wow - there's a *BIG* goodie included

infiniteneslives and I have been talking over packaging. I've decided on a layout, so if the most recent build is the final list of games, I'll start on the artwork. If not, I'll wait until the game list is final to begin. Would rather not have to add / remove elements after starting.

A few developers have PM'd me regarding the art, but again, if anyone else has any input regarding the packaging, they should post here, in the packaging thread, or PM me.

As for sections? How about:

1. 2016 Competition Winners (the top x amount, ordered by place)
2. 2016 Runners-Up (the rest of entries, alphabetically)
3. Other Games (games not part of the competition, alphabetically. Could currently be titled Zombie Games. )
4. Toys

As for making the game list final, we still have 192 KiB free.

Rearranging the sections as described produces this:

• Winners
  
  1. Twin Dragons
  2. Nebs 'n Debs
  3. Filthy Kitchen
  4. Lala the Magical
     Cheril the Goddess
     Wo xiang niao niao
  5. Sinking Feeling
• Runners-Up
  
  • Brick Breaker
  • Flappy Jack
  • Jupiter Scope 2: Op. Europa
  • Karate Kick
  • The Paths of Bridewell
  • Rock Paper Scissors +
  • Spacey McRacey
  • Super Tilt Bro.
  • Waddles the Duck
• Zombie
  
  • Haunted: Halloween '85
  • Zombie Calavera (Prologue)
• Toys
  
  • 240p Test Suite
  • Button Logger
  • Musical Controller

Not at all comprehensive but here I go with another report of bug testing.

Karate Kick is missing!
Power pak reported that it has a "bad header" (0xff in places where 0x00 should go) so mabye the builder missed it because of that.

Haunted: Halloween '85 demo:
Can not successfully reset from most places after the Retrotainment logo, and will remain locked up on what I think is a ill defined mapper state.
Selecting Credits from options will freeze on a gray screen (but ironically avoids the first lock up bug described here).
Also being just a demo, should the whole soundtrack be available from the options screen?

Zombie Calavera:
"Lowercase t"? I'm very sure those are better described as grave markers or simply just crosses. I'm sure I could look over the descriptions for other games, but this one particularly stuck out to me as just being plain wrong.

Spacey McRacey:
This one is really baffling me. I didn't know anything wrong was going on until I watched RogerBidon play it on emulator. Apparently when played on Power Pak, (both as part of the multicart and by itself) there is no background music during gameplay! along with shaky scrolling. I'll try to spend more time on this to pin point the cause, and maybe even hex edit in a fix.

Action 53 Function Ceiling ⅓ (Action 53/3 for short)
[…54/3 = 18 = round(53/3)= ceil(53/3)]
Action 53…3…3…3…3…3…3…
Action 53 3: Too Hot For the Kitchen
JAN CTION PON 53
[hr]
Sounds like more bug testing and fixing is needed before production? We don't want to be Action 52; that's the entire point of this thing.

It turned out that there was a stray space: it was trying to load "kkick_2017-03-31.nes ", which didn't exist. But thanks for catching that. Now we're down to 160K free.


This being the first BNROM entry, I'll have to investigate what's going on in the builder.

EDIT: Fixed in my tree. Exit patching now always defaults to the last bank.


Greg and I noticed that this morning, and I fixed the credits freeze in my tree.


I think I already released much of the OST in .ogg format when trying to defend it from comparisons to Hummer Team.


For "time to leave" (South Park S05 E12). Also to parody the cross ban during the NES's commercial era. (TCRF is down for April Fool's Day, or I'd link more details about the cross ban.)

I've attached the current builder config file; feel free to suggest diffs to the descriptions.

Only the front page is in its "new" layout, which does in fact link to various pages in its wiki (albeit with scripting rather than forms, boo). Search works just fine.

p.s. †

I don't know what Select is supposed to do in Lala the Magical, but it changes the floor color until I fall through it and run out of time.

That's because silly me let the debugging code on. I can produce a new version tomorrow, but I'm afraid we are long past the deadline.

The deadline was soft anyway, just something not to let it slip indefinitely like the first two volumes did. Critical fixes are still OK. There's one in the pipe for the credits of HH85, for instance.

Anything that the community wants to toss in to try and fill up the 1MByte rom space is fine by me. Starting to get to the point where any further additions may not get reflected in the artwork though. M-Tee is about to start working on the artwork with plans to submit the file for printing by the end of April. I'm planning to assemble the first batch of cartridges in May. I don't plan to start flashing the carts with the final rom till late May/early June. That's really when the rom has to be finalized by. If everything goes well with all that we'll be on track to release by the end of June.

I've been discussing the plan with printed materials with M-Tee on the sidelines. We've got a rough plan together but still waiting on a quotation for printing of traditional boxes.

Current hope is to have a modest print run of traditional boxes instead of ordering excessively too many like we did last volume. If/when we run out of traditional boxes and the volume is still in print we can shift to bitboxes which I'm able to print the inserts in house in small batches as sales flow in.

M-Tee had the idea to create a poster instead of a more traditional multi page manual. This seems more fitting since we don't have entrants provide a manual page with their entry. The poster will cost a couple dollars to print each one, because of this I feel it's more fitting for the poster to be paired with the CIB option alone. That way people who like spending a couple dollars more for fancy printed materials can, and those happy saving a few dollars can cut the box and poster with the loose cart option.

We'll keep the manual simple just like last volume which itself is generic enough to be used as is. That way I'm able to print them in house and the cost is negligible, so the manuals will be included with CIB and loose cart. I'm planning to print the labels in house as well to help keep costs down and avoid the impossible decision of deciding how many to print before release.

Which in my opinion makes it even more important for entrants to suggest improvements for the descriptions within the menu.

I think we should try to make this write up part of the blurb for compos moving forward to make production tasks like this simpler.

Speaking of, it's prob about time to start a discussion on anything that we're looking to change or implement for next years compo. I don't think there's much that needs changed, so hopefully it'll be a quick process copy pasting most rules/guidelines from last compo.

One other thing I kind of forgot to mention is that I'm planning to release this volume in both 60 & 72pin versions. I've got all the parts needed to do so. The main thing to sort out is handling of printed materials for famicom vs NES releases.

Quality is why I iterate.

• Restored Karate Kick
• Updated Super Tilt Bro., Lala the Magical (1.1), Spacey McRacey
• Removed debugging "feature" at title screen to hold Up to corrupt graphics
• exitpatch: Fixed marking exitmethod=none banks as already patched
• a53build: Allow insertion of ROMs as unreachable data banks

Just found an A53 exclusive bug in Waddles - if you start waddles, reset, then reopen the game you may not be able to beat it! Trying to figure out what to do about it.

I had a feature in the original rom where if you reset, your collected gems would stay collected. I store this data in $400-$4ff, including a special byte I set to a known value at startup. If that special byte is set, I don't clear $400-$4ff while clearing ram. This works great in isolation, but it seems like the menu software writes to some (but not all!) of these bytes. This results in extremely high gem counts on reset - also making the game unwinnable.

I guess I see a couple options:
1) If there's $100 or so bytes the menu doesn't use, move the gem data there, and call it a day.
2) Kill that feature entirely for the multicart, and add a 3rd start menu option that allows returning to the title. (If you reset, you're just done.)

I haven't spent much time with the A53 sources, but I suspect I might be able to get away with using $700 or so. But then, I'm not sure how fragile that will be. It seems like killing the feature is the safer option.

I'll try to fix this in some form in the next week or two. I'd welcome any thoughts other folks have.

@cppchriscpp I responded in the game thread.
------

Here's My long report of testing this build on Power Pak. I posted the important bugs that I believe needs attention in each of their respective threads. The rest of this post are kind of cosmetic stuff that I quickly jotted down.

I was did not reach the end of Wo xiang niao niao, Haunted: Halloween '85 Demo, or Zombie Calavera. So I might be missing some things in those games.

# Twin Dragons
There's some sort of PPU glitch (color line stripe, accidental scroll) at the end rescue scene.
The second to last fire ball in Level 2-2 initially spawns at the bottom of the screen, but it fixes itself when it lands in the lava.

# Filthy Kitchen
There was 3 momentary glitches that I couldn't reproduce, so unfortunately this report is not going to be much help here.
At one time some garbage was written in the score area. At another time the fly swatter went crazy for a bit. and I think the fly swatter hit the boss by warping around from the left side.

# Lala the Magical
I find it odd that releasing (instead of pressing) the A button advances the dialog.

# Cheril the Goddess
likewise with the dialog.
Twice I encountered a moment where a column of 2 metatiles loaded visually and physically incorrect. It's easy enough to just step back to reload it again.

# Wo xiang niao niao
I find it frustrating that the jumping fish still occasionally hurts Lin Lin even though she stomps them.

# Sinking Feeling
Some bizarre visual stuff happened when I think I got 2 achievements simultaneously. I'm not sure as it just happened once.

# Karate Kick
Background occasionally starts orange instead of black.

# The Paths of Bridewell
I understand that the sources to this was lost, so I don't expect anything about this game to change, but here's a list of oddities anyway.
Game briefly shows the OAM from the Action 52 menu with the Bridewell tileset before loading the title screen.
The title screen arrow blinks in time to the music (doesn't on emulator).
There's some sort of frequent miss set scroll for occasional video frames. I suspect (but did not verify) the music/sound engine load has something to do with it.
It's quite odd that the point to check tile effects (like water or ice) is a offseted point in front of billy instead of his center.
Billy can walk horizontally into a solid block as long at there's two ice tiles above him.
Billy can creep along a wall to the right to avoid the fast charging baddies.

# Spacey McRacey
Player 2 wins in the case of a tie between player 1 and 2.

# Waddles the Duck
The action 53 TV screen appears for a frame before the game starts loading graphics.
The game slows downs at two particular portals (I forgot to write down which ones)

# Haunted: Halloween '85
The camera starts way off to the left at a particular check point showing the tile columns getting loaded on the right of the screen, but the game does this in the retail version as well.

------
Just for kicks I tried the "slow button" on the NES advantage controller. "slow" works by turbo pressing the Start button. The actual effectiveness of this varies for each of the games.

- Karate Kick, Sinking Feeling: Works perfectly with no audio distortions.
- Button Logger: I designed this specifically for the "slow button".
- Nebs 'n Debs, Cheril the Goddess, Flappy Jack: Works decently with audible annoyance.
- Jupiter Scope 2: Works without audible or visual changes, but unfortunately drops input.
- Twin Dragons, Filthy Kitchen: Works but with some dropped input making it sometimes difficult to do things.
- Rock Paper Scissors +: Auto advances the "press start" notice.
- Super Tilt Bro: Oddly enough, only your character walks slow.
- Lala the Magical: Game remains stuck in pause if you try pressing any buttons.
- Musical Controller: I guess that's an interesting musical effect?
- Wo xiang niao niao, Brick Breaker, The Paths of Bridewell, Zombie Calavera (Prologue): Does not pause, thus "slow" does nothing.
- Waddles the Duck: The pause menu eats all your jumps and pressing down while in "slow" will reset the level.
- Haunted: Halloween '85: Sound becomes garbage and eats your inputs.
- Spacey McRacey: Enforced minimum pause time makes the "slow button" awful.
- 240p Test Suite: "slow" causes unusable repeated flashes of menu and test loading.

I also tried "The Game Handler" which, among being finicky with it's directions, it allows me to press left and right at the same time. Most games just have some button priority where left overrides right and sometimes vice versa. The exceptions being:

- action 53 menu, Jupiter Scope 2, 240p Test Suite: Left + right is canceled into neutral.
- Nebs 'n Debs: Retains momentum while moon walking to the right.
- Flappy Jack: Walks in place
- Rock Paper Scissors +, Super Tilt Bro: Stops all input until Left + right stops happening.

I'm impressed, that's some quality testing that I never expected anyone to bother with You're absolutely right, later players always win in a tie:
I figured ties are extremely unlikely in actual play, so didn't care to build-in a tiebreaker.

Anyway, thanks for taking the time to do the in-depth testing of all the games!

Thanks for testing.



Oh, that glitch again. I thought I had sorted it out (in fact, I thought I had sorted it out with each new version, as It got reported every single time and I changed the scrolling engine every time, tested, couldn't reproduce, and thought it was solved - but no). I really don't know what's wrong. It seems stray data left on the nametables when you change to other level which doesn't get overwritten. I'll keep working on it.

I've updated Karate Kick a tiny bit, hopefully helping with some of its issues.

Wow, thanks for all those tests !
Which version did you try ?
I just saw that version 0.073 was available on the forums, but the "official" entry version is 0.074 (downloadable here), and IIRC, the PPU glitch was in v0.073.
I just updated my messages on the forums by the way.

Have not seen the garbage in the score area, but that sounds strange.

Fly swatter goes crazy has a fix for it.

Fly swatter going left and hitting the boss.... I think I'm okay with. Honestly seems like a neat trick.

Even though the code freeze happened March 31, we can still submit new versions, but only for bug fixes?

Sorry everyone that I didn't respond until now, busy week and all that.


I checked with a binary comparison and found we're using 0.074, but I found that there's inexplicably 1 bit of difference. In version "page 7" of a53games.nes, byte 0x06c031 is 0xad whereas in Twin-Dragons-20170131-0.074.nes byte 0x00c031 is 0x8d.


Yes, we have been accepting bug fixes.

Easily explicable.

From roms.cfg:

From the filename in rom=, we see the use of 0.074. The patch1=C021=AD disables setting the outer bank. A standalone game using the Action 53 mapper needs to set the outer bank, but it shouldn't when included in a multicart.

The reset handler is at $C000, and it includes mapper initialization code starting at $C01A that disassembles as follows:

ahh, sorry about that.
I guess today ended up being a day where I did everything the stupid hard way with stupid stuff like hex-editing via cut and pasting bitmaps, and where I didn't even bother to look at the blatantly obvious info already available.

I believe I figured out how this may be done. This is my suggested change to the description of Button Logger

I'll trust that the user will find that the Zapper button also works, and I think that explanation of Start is not necessary as A is the recommended pause button.

Midnight repost: B button grammar

If you want to burn PRG space, somebody should yell "ACTION FIFTY-THREE!" in a Crazy Taxi-style voice.

While searching for a post to quote in another thread, I found this post:

Maybe this could be included? I dunno.

I also have this wishlist (from when I previously looked for space fillers) of things I would like to have on Action 53 eventually, but probably never will due to licensing and/or contact issues.
- Alter Ego
- Inversion
- STING

I don't think Shiru will object to the inclusion of Alter Ego.

Going beyond 18 does reduce the suitability of ⎡Action 53/3⎤ as volume title, not that that should mean much to anyone.

New build. Changes:

• Fixed mirroring in autosubmulti, primarily affecting Super Tilt Bro.
• Updated Cheril the Goddess, Filthy Kitchen, Karate Kick, and Waddles the Duck

Alter Ego is a port of a ZX Spectrum game by Denis Grachev. We'd need to seek his permission.

Unchained Nostalgia is essentially a music video for a musical composition by Alex North. We'd need to seek his permission.

So anyway:
The title screen has up to 208 tiles and must satisfy the palette and attribute restrictions of an NES background. (The other 48 tiles are used for the version and copyright notice strings.)

I got a stupid idea that would work for filling 1 of the 4 32KiB banks left.

I spent like 30 minutes hacking together a NROM build of Russian Roulette which has a single CHR ROM page, making sure it doesn't do any MMC1 or extended ram writes. It plays and sounds exactly the same but the portraits are hilariously scrambled and non animated.

The idea I had was to include that hacked NROM build complete with description, but dummy it out by decrementing the total number of titles on the last page. That way it can still be played by restoring it with a single Game Genie code.

Could you do an UNROM build with portraits that aren't scrambled but aren't animated either? Or would it be better just to save it for the remix compo, where it "votes off" the Russian Roulette game from volume 1?

Better to save it for remix compo. Otherwise I'll end up spinning myself into frustration again. Like, I still don't know how to make assembly subroutines into C callable functions.

I was suggesting the hidden NROM idea because I have successfully tested that in my local a53 menu build, including the game genie code reveal.

oops, sorry I forgot to attach the thing I was even talking about in my last post.

If you have at most one 8-bit, 16-bit, or 16-bit pointer parameter to the function, and the return value is at most the same, then all you have to do is declare the function with __fastcall__, e.g.:
char * __fastcall__ functionname (char *);
and in the asm file, precede the label with an _:
_functionname:

For a 16-bit parameter, X:A will contain the parameter when the function is called.
For an 8-bit parameter, A will contain the parameter, and X has no guarantee.

You are not required to preserve the contents of A, X, or Y in your assembly function.

On function return, X:A should contain the 16-bit extended form of the return value to the outside function. (For an 8-bit return value, X:A must contain the 16-bit promoted version of that 8-bit return value, lest you coax out bugs like this one)


If you have more than one parameter, or the type of that parameter is more complex, then I'd recommend looking through cc65's libc.

Thank you. Would it be possible to build with the last rom in the Super Tilt Bro. thread? It should fix an ugly v-blank overflow when entering in the options screen.

(Oh, and if anybody can confirm it is fixed on actual hardware, I cannot test on hardware for now.)

I knew I forgot something during the weekend.

I confirm that the latest version of Super Tilt Bro that fixes the tile corruption was not used. The latest version is "NESDEV V4" where the old version that's in "page 8" is currently "NESDEV AI". Additionally Juniper Scope 2 (which Super Tilt Bro shares it's ROM space) also got it's mirroring flipped from vertical to horizontal so that the planet in the background is now completely missing.

My fix for the mirroring was wrong. Egg on face. I apologize. Will fix.

We may have found our filler if the authors of the Ludum Dare entries are willing to let us use them.

You can use both Lunar Limit and Ralph 4 as filler, assuming there's space.

Lunar Limit is ~22 KB + 1.5 pattern tables of chr. Over 3Kb could be shaved off easily by trimming the lookup tables.

Ralph 4 is ~9 KB + 1 pattern table of chr. The sprites and backgrounds are actually on separate pattern tables but it wouldn't be hard to combine them.

(you can also include Color-A-Deer as a joke game but I don't think it's worth the space)

Lunar Limit will make a great adition to the cart. I love it!

It is not possible just because he died more than 25 years ago.

We'd need to seek his estate's permission.

While the offer for inclusion of additional work is appreciated, I don't feel that works which require licensing of that nature are fitting for the action53 project. Dealing with deceased person's estates is very different scale from the lax "license agreement" we have with contributors to the cartridge. It would present too great of a risk that loss of license, or some license conflict would put the project in jeopardy. Aside from any legal or financial ramifications of license issues, it would put cartridge sales on hold while a patch was created to remove the work. Reflashing and testing of all carts which already contained the work, etc. Then all printed materials listing it's inclusion are also wrong/outdated.

Nesdev isn't it's own legal entity to bear this liability. Being the person primarily responsible for publishing the cartridge, legal action would most likely be taken against myself. I simply don't feel comfortable with it's inclusion.

Twin Dragons doesn't load at all for me in this build. There's a stack underflow (RTS with empty stack) at $C06B once Y decrements down to 0.

We should provide our own title screens, yes? Looks like 3 colors, 56 tiles, drawn using sprites, correct? Seems like the other 3 sprite palettes are unused. Would it be asking too much to use those as well? Either way I'll get to work on creating my title screen.

I updated Super Tilt Bro., added Ralph 4 and Lunar Limit, fixed patch processing in the builder, re-fixed autosubmulti's mirroring output, and began a refactor of game launching toward better RAM clearing and better separation of mapper-specific code. I also ran a check that all games at least boot.


I was being a bit facetious to preempt others who would be similarly facetious, but thank you for clarifying policy about what INL does and doesn't want to handle. Now I have a post where I can point others who include unlicensed proprietary material in their entries.


I noticed this too today when I was testing a refactoring related to RAM clearing. The cause was that this game sets the outer bank, which is fine (and desirable) alone but needs to be patched out when it's included in a multicart, and I made a mistaken change to a part of the builder that processes patches.


If you're referring to the picture displayed to the left of the game list or game description, preferably a representative in-game screenshot.


Screenshots are 3 colors plus transparency, which is black. The builder assumes the same palette used by savtool.


One other sprite palette is used: the one for the arrow pointing at the tab for the active pane. As for making use of those two other sprite palettes, for a total of three, that might require changing the builder to allow manually specifying the palettes for each screenshot.

Reposting this for clarification. Must the screenshot be a scaled representation of the full-screen, or can we do some editing and cropping so that it has a fighting chance to actually look good?

I forget what the consensus was, but the discussion began here.

I think the cropped screenshots look slightly better. Showing the main character of a game is really descriptive.

Also, I fixed a rarely-occurring crash in Lunar Limit so I'll attach a new rom to this post. Thank you for working on this, tepples.

That was my opinion, I'd rather have representative crops, but it seems that most people favoured the full screenshot. I produced and posted images for my games, just in case.

I feel creators should be more than welcome to provide their own graphic if they would like.

Perhaps this is something we could suggest/recommend entrants provide with their submission in the future.

Here Super Tilt Bros. previously made cropped screen.

It seems the discussion did not end on an explicit consensus. From what I understood:

Pro cropped screenshot:

• Often look better

Pro scaled screenshot:

• Like previous A53 editions
• Like "PlayStation Interactive CD Sampler volumes 7" which inspired A53 menu
• Easy to produce in semi-automated fashion
• All screenshots following the same rules improve consistency
• A screenshot for each game has actually been produced

Developers tend to prefer cropped, making the debate balanced: more supporters for crop, more arguments in favor of scaled.

I am personally now neutral on this matter.

Do we need a consensus? Can entrants just make the decision for their own game as they see fit and everyone be okay with that? If they choose to not provide their own artwork then, the generic zoomed version that's already created will be used.

Feels like we're making a big deal about a relatively minor thing. Am I missing something?

Mostly it's a matter of consistency: "Why are these zoomed in and these others zoomed out?"

I don't see why creative work needs to be consistent I guess..

If someone complains/asks, telling them the choice was up to the game developer should be enough for them I'd think..

I agree with this completely, though I am not an entrant.

I'm also not an entrant, but my vote goes towards consistency, even though the full screenshots sometimes don't look very good or particularly representative of their respective games. It would maybe help if the game pictures themselves weren't under such severe color restrictions in favor of the surrounding interface, which isn't even that good looking TBH.

I tried making cropped versions for the rest of the games for comparison.

It was pointed out to me privately that like Slappin' Bitches from volume 1, Sinking Feeling has text in its intro that could wreck a hypothetical E10+ rating. So in the next build, I'll replace "GODDAMN" with "G.D." and "FUCKING" with "ONLY". I'll suggest something to a similar effect in the volume 4 planning topic as well.

And allow me to explain the placement of Wo xiang niao niao: Because each team can place only once, I have considered each team's entries as a unit. Thus if 4th place goes to The Mojon Twins, I put all their stuff in the 4th place slot, above 5th place and the runners-up.


Improving the appearance of the menu is something I'm willing to discuss for volume 4.

You're using all four BG palettes for that black-gray-white menu & TV boundary?

Now, if we had some means of shrinking images into black+18 colors… (would require scroll split or a height increase of the TV to get around attribute clash of it being 8x7).

[hr]

And for those of us opposed to and offended by censorship?

We can leave the entry out completely if that's desired by the creator. Or someone can arrange put in the effort to arrange and produce their own adult/MA compilation rom and cartridges if they'd like.

The compo rules specifically cover explicit content:

Three of four. One is a gray ramp (0F001020), and two are for the text, which is rendered to two bitplanes (0F100F10 and 0F0F1010). Somehow the screenshot color limit didn't cause a problem for the first two volumes.


A scroll split would make Zapper navigation more difficult, as the Zapper requires timed code to read the Y coordinate. I'd have to either A. split the Zapper polling loop into two "is it above the scroll split" and "is it below the scroll split" loops, or B. offer a build-time choice between support for the Zapper and support for higher color depth.


In the United States, it's common for DVD Video publishers to offer particularly raunchy movies with separate SKUs for the theatrically rated and "unrated" editions. But I haven't seen this for video games for some reason.

I guess it would be possible to display zoomed-in screenshots when game descriptions are displayed. That is, if there's enough space and it isn't too much effort.

I really didn't think a couple swear words would be explicit content. I hear much worse from 5 year olds.

If that's the criteria for keeping it in, then do censor it like you said above.

Hot Coffee.

An IPS for the competition versions of Mojon games will be difficult what with compression.
Do leave extra spaces in the string to make reverting them easy, if you would, please.

Everyone missed the joke: censorship, sinking feeling? But I do hate censorship, generally…

The first edition of Grand Theft Auto: San Andreas was recalled once Hot Coffee was discovered. I should have clarified that the theatrical and explicit cuts of a film or the edited and explicit versions of a popular music recording are purposely sold side by side.


I have done that. It was a lazy hack in a hex editor, after all.

I was providing it as a reason, not a counterexample. If concurrent releases happened, then it makes it downright trivial to provide an explicit mod of the allegedly-inexplicit game, and, with that precedent's horrible implications…

Much obliged.

I can understand "fucking", but is "goddamn" really considered explicit at all? o_O
Isn't that really weak by today's standards?

On U.S. TV, you can say "ass", and you can say "hole", but "asshole" is bleeped. Likewise, you can say "god", and you can say "damn", but "goddamn" is bleeped.

Further reading: ELI5; All The Tropes

Despite what one might believe these cartridges are played by many young children. Plain and simple these words are unacceptable for children. Just because you heard some 5 year old using these words doesn't make it acceptable. If you want some one to yell at and be mad about for the censorship I'll take that heat.

Sounds like we need to be more descriptive of what's considered explicit, or general rating guidelines for games to be accepted on cartridge.

I don't have any problem with self censorship and catering to these kinds of "ratings". I don't believe a good game needs any kind of "explicits", and any excessive use of such usually comes across as immature rather than mature (see GTA games, etc, for example)

It's just genuinely confusing to me that you consider it wrong for a kid to see a word like "goddamn" on a cartridge full of games that involve shooting stuff and kicking people. Hell, there's a russian roulette game in this compo. It's a pretty absurd dissonance that I keep seeing in American culture, and I don't think I'll ever understand that. But it's not like I object to it, I don't think it's important enough to get upset about.

That sounds like a hassle, but not a bad idea -- particularly as different countries have different things that are considered worse. Nudity like in Wo Xiao Niu Niu is generally considered a big deal in America, but other places may have more issues with the violence found in most of the games. Different swear words are more or less "serious" in different cultures. Picking a standard at the beginning would help people know what to expect.

The Russian Roulette game in volume 1 was at least perfectly clear that it was paintball.

Yeah, after na_th_an's game was censored, I didn't bother to submit my own entry at all. I'm completely disgusted by censorship.
(You can download the 4-level demo of "Cotton" over on 2CH instead, if you know where to look! )


Yeah, I learned this the hard way. Clearly, the 40 year-old man-children of NA will be so offended, if you say something they don't like.

I've jokingly suggested to my colleagues, to make our own, adults-only compo, "Action 69"

This is a tough call to make, especially after the fact, but if anyone chooses to use a nude or sexualized character they knew what they were in for from the start.


Complaining in this melodramatic way about censorship isn't going to garner much sympathy; it's not like this kind of change is a violation of one's rights or some serious offense. Nobody said to na_th_an, "you can't make your game with a nude character ever", just that it is not appropriate for the multi-cart. It's just asking "can you not use this community project as an excuse to share drawings of your favorite body parts?"

I guess you can argue that the expectations were not made clear in the beginning, but if nobody has said otherwise, it's safe to assume that it's inappropriate for the context, not the other way around. I can not think of any contexts where it's a safe assumption otherwise.

Yet a game about shooting people/yourself in the face with a realistic gun is not a safe assumption? I'm gonna make a bold assumption that you're probably also American. As rainwarrior and tokumaru already pointed out in the 2017 planning thread, you gotta remember that you probably have a very subjective assumption of these things based on your region and upbringing (as do I).
In most parts of the world, nudity or even straight up sex is not considered offensive, explicit nor inappropriate for children. That said, oversexualization of women could often be considered offensive for completely different reasons.

Of course, I'd agree that you can usually guess when you should leave out a lot of these things, but you can't assume that everyone has the same insight in American rating systems. It's still baffling to me that "goddamn" would be offensive, despite my heavy exposure to American culture.
I don't really think there's a problem with the way it worked in this compo, it's not like it's a big problem to remove these things. As long as participants are warned in due time so it doesn't have to affect the judging.

Yes, but in that post you are referring to my main point was that as its publisher infiniteneslives needs to have the executive control over it.

I wasn't making any point about his concerns being more or less valid because they are subjective. He's the one making and distributing it, so the things subject to him are what matter. If you've got additional concerns that you think he's missing, by all means point them out, but noting that they are subjective concerns doesn't dissolve their relevance to the subject.

I find this asumption mildly offensive, for example

Who mentioned a game about shooting people in the face with a realistic gun? I wouldn't defend such a game for inclusion either, as that's pretty explicit. I don't care for guns, I've never held a firearm, and I don't plan on it, but thanks for the generalization.

Like it or not, the NES's largest audience was North America, and I'd expect that to still be the case (though the homebrew scene has certainly globalized the platform and moved the scale a bit). If sensitivity towards the audience is something to be considered, applying the (expected) sensibilities of the (expected) audience is not an unreasonable thing to do.

I also think being concerned over goddamn is being a little extra-sensitive, but given INL's concerns, it's changing very little for better peace of mind.
Who mentioned a game about shooting people in the face with a realistic gun? I wouldn't defend such a game for inclusion either, as that's pretty explicit. I don't care for guns, I've never held a firearm, and I don't plan on it, but thanks for the generalization.

Like it or not, the NES's largest audience was North America, and I'd expect that to still be the case (though the homebrew scene has certainly globalized the platform and moved the scale a bit). If sensitivity towards the audience is something to be considered, applying the (expected) sensibilities of the (expected) audience is not an unreasonable thing to do.

I also think being concerned over goddamn is being a little extra-sensitive, but given INL's concerns, it's changing very little for better peace of mind.


My irritation in my previous post was mostly directed at Alp's post, which read as being overly dramatic. Your game is not really an example of the out-of-place sexualization I am irritated with.

Well, neither am I. I thought I made that pretty clear.


My apologies, apparently the game is a "category 2" game which means it's not eligable for the multicart, so my point is moot. This was the one I was thinking about (very bottom of the page):
http://nesdevcompo.nintendoage.com/contest16/


Those are two very broad assumptions
I won't argue that the NES sold more in North America than anywhere else, but Japan was a very close second, and comparatively a much smaller country. You also can't deny that the NES was -huge- in Europe, and on the "retro" scene, it still is. I just returned from a "retro game fair" in Sweden last weekend, which had roughly 4000 attendants, and the NES was by far the most represented platform.
Also, I highly doubt the homebrew scene has changed anything. If the weights are being shifted recently, it's probably more likely due to emulation and YouTube. In the end though, nostalgia and historic importance is still the system's biggest claim to fame.

All this is completely off-topic of course. In the end I don't think we really disagree about anything in regards to how A53 is produced, and it's not like my opinion should matter anyway.


Btw, now I'm really curious about what alp's game was

Furry shemales, if memory serves me right.

You're missing the point. It's the principle of the thing, censorship is slippery slope to fall into, and if a game with tasteful nudity isn't okay, but a game containing obvious suicide is, then a cute game with a girl throwing veggies at monsters is clearly out of the question! Think of the children!

Despite its' removal from the compo, as previously promised, I will indeed be completing the game, regardless, and releasing it on its' own, at some point in the future.


Incorrect.

While "Transamnia" is indeed a game that I'm working on, my unsubmitted compo entry "Cotton", was a disgustingly adorable Super Mario Bros. clone, with nearly Kirby-like visuals. I had posted a preview of it, on the "How's everyone doing?" thread:
viewtopic.php?f=32&t=15153#p183677

Here's a slightly updated preview, because why not? I will not be releasing a demo, just the full game.




My NSFW game on the other hand, is an RPG, clearly meant for adults. It's title screen alone, even puts most NES games to shame!

Cotton looks amazing, basically my favorite type of game! As for Transamnia, while the title screen does indeed look nice, it's kinda hard to read, hard as in "I wouldn't know the name of the game if it wasn't also written in plain text".

Who said a game about obvious suicide would get a thumbs up from everybody? This is a recurring pattern. That is another type of theme I would rather not put in a game collection to be sold that represents a community.

Cotton looks like it is coming along well and I look forward to its release.


I didn't mention Japan because the Famicom sold in Japan, not the NES

I don't necessarily have an issue with goddamn, but fuck (especially on opening scenes) is beyond what I feel is acceptable.

I was suggesting we use some 3rd party list of what words are acceptable and what's not instead of coming up with our own list and arguing what words fall on what side of that line.

Honestly for me it's a bigger deal if the explicit words are presented immediately or late in the game. A kid picks up the controller when on display at a gaming convention with a parental figure standing at their side. Kid reads through opening scenes and reads the F word creating a rather uncomforable situation I'd rather avoid..

As for the 'cartoon' topless nudity in Wo Xiang, I've failed to bring up my thoughts on the matter up to this point. I have a hard time classifying 2-3 pixels as nudity. But since we're on the topic... It would be nice if she were able to have a bathing suit/bra top. Maybe have the topless an unlocked feature later in the game?

IDK, how reasonable this idea is but if there were a relatively simple way to toggle what we deem explicit maybe that would make everyone happy..? Sounds like a lot of work to make something like that happen with each individual rom especially after the fact. Maybe something like entering the contra cheat code at power up or game boot unlocks censorship? Again, I'm not sure if this idea is worth the effort.. But it would satisfy my request to make explicit/questionable material less accessible. From my perspective there's a difference between getting exposed to explicit material immediately when booting the game, verses late in the game. That's an even more grey line to try and draw however probably digging an even deeper hole.

Sorry if I misread you. I was mainly objecting to being quoted out of context.

Nudity was removed before the latest submitted version. The "end of level" cutscene is also covered. No need to unlock anything, nudity was not a reward to the player - it was just, I don't know, never thought about it. So somebody privately asked me to remove both features, and I did.

In fact, and please bear with me, tepples, I think I might resubmit this game once again. There's a couple of things more that I might change.

As for the suggested unlockable uncensored version, I don't think it's necessary or worth the effort. I think the rules are pretty clear: you want your game in the cart, it must be for all audiences, period. I don't think its such a big deal.

Much appreciated, sorry I didn't catch that update.

FWIW, I liked Cheril's sprite better before you gave her the "collar" to suggest clothes. Seemed to fit the "goddess" theme better too. (This is not a suggestion about what belongs or doesn't belong on the cartridge, though.)

That was exactly the reason for her original design. It fit the theme, nothing more, nothing less.

Now she looks like the main character in a cheesy late 70s space opera, which is also cool. I've grown to like it. In fact, I have kind of redesigned the character around the new look.

I'm glad I'm not the only one that made that connection. I've been referencing the Barbarella comics for Cheril inspiration for the cover art.

Are we going to want a relatively plain title screen like the one we have, or is a better one possible with 208 tiles? (The other 48 are for the notices at the bottom.) And is "Revenge of the Twins" still the theme?

For what it's worth, I like the simplicity of the title screen. However, as I work on the box art, if you'd like me to convert the logo and title from the box to a format suitable for the title screen, I'd be more than willing to.

As for the theme, I'll wait until it's absolutely confirmed before I work on the logo for the box. Still inking the illustration anyway.

I like the title screen fine, though I'm not sure I like the VWF font that's being used (is that Verdana Bold?)

The font is Chicago 12, the iconic UI font of Macintosh System 1 through 7. I chose it because it works at that resolution without antialiasing, about which you complained earlier. For "Press Start Button" in the first two volumes, I used Droid Sans (now called Open Sans).

I'd've said "what Chrono Trigger (and/or FF6) use" … and it seems like only one other person has noted the similarity.

Fair. It looks clean and legibility is up. It might just stand out to me because I am so used to 8x8 fonts on the system.

I like the simple clean title we have personally... I certainly don't have the graphical skills to come up with anything better. (Have you seen what happens when I try to draw a duck? )

Also, I uploaded what might be the final version of Waddles to its own topic. I ran through it on the latest multicart (on powerpak, yay) and poked it a bit; everything seems stable. This is probably the last version unless I take the time to get rid of that pesky graphical glitch at level start. I can't stop seeing it now, but I'm having a seriously hard time finding what I'm doing outside vblank/forced blank. (Note: If that improving prior entries contest ever happens, I may tweak Waddles more for that. As it stands though, I need a long break from that codebase)


Tepples - would you be willing to turn off exit patching for Waddles now that I've added the "Exit to Menu" option? (It's actually a menu item now; no weird two-button shortcut)

Adding exitmethod=none to Waddles and updating to the latest build.

Probably the last thing before I declare the ROM final is whether to keep "Revenge of the Twins" as the subtitle. Does INL have any QA facility to ensure nothing else is seriously wrong?

IDK if I'd call my little operation a facility, but sure.

I've yet to migrate my action53 mapper implementation over to my 8Mbit+ 3v board version and update erase/program algorithms. I'll do my best to get this wrapped up this week.

Once that's taken care of, and with the rom nearing completion, it'll be time to whip up the first batch of boards.

Haven't heard back on the print quotes if I don't end up doing everything in house, I just pinged the print house again so hopefully can get that ball rolling asap.

One more hacky fix: viewtopic.php?f=32&t=15476&p=196179#p196179

If you prefer it, here's a title screen that corresponds with the packaging design:

Because of its white background, I think +/- #10 fades to and from white and black would help the transitions, as shown above.

If you want to use it, the zipfile includes .chr, .pal, and NESst .nam with attribute table. Because the credits text is no longer color #02 against color #00, I just included it in the .chr. Wasn't sure about that.

That looks nice and clean. Maybe it's not very NES-like for the in-game art to match the box art

Loving that title screen!

All I really need to add a title screen are the PNG and the palette. and added it to a53games.cfg.


Here's what it looks like on a TV:


It wouldn't be that easy to do the fade to white. Currently once the title jingle finishes its sixth loop, it cuts to a blank (now white) screen while the voice sample plays, and it'd be painful to interleave 100% CPU for the audio playback with PPU access for the fadeout. But I could probably add a fade-in and fade-out to the menu screen. I don't want to do anything too fancy because there are complaints that it doesn't look very attractive in the first place.

I think the menu screen itself just needs a little sprucing up, but is generally fine. A little animation with some sprites and maybe some sounds and I think it doesn't need much change at all.

I hadn't considered the white border that'd display outside of the nametable area. That would be especially noticeable for anyone playing on a console hooked up to an HDTV (a lesson I should have learned while working on Cowlitz, as we have a similar screen that suffers from it).

Honestly, the original black and white title screen would probably be better for that reason, and to provide interest through contrast with the box art, a result of Mike's earlier observation that title screens rarely coincide with packaging.

The horizontal blank isn't quite so blank on the NTSC NES. (I hear it's black on PAL though?)

If you favour the aesthetic of always-black hblank, you could still use black as colour 0 if you dropped just one colour from the action53 text/outlines, though. You could even make that text black instead of that dark teal to do it?

I should definitely add hblank to my vocabulary. Up until last year, I only had a CRT, on which it wasn't visible, so I wasn't even aware of it.

Anyway, removing a color from the logo border allowed me to do this:



It would use the palette:

And here's the image @240px high and w/o credits (not sure if the importing method requires full height or not) :


Thoughts?

I find this version harder on the eye than the original. The transition from pitch black to pure white gives too much contrast to the composition, in my illiterate opinion.

I'm agreeing with na_th_an. I don't know if it will look good or not, but since you have gray in there, you could add a thin drop shadow with one line black, one line gray, or just one or two lines of gray (or some other configuration) just under the 'card' to suggest a material dimension to help guide the eye.

If the gray is too warm for a drop shadow, you could perhaps use the jade one.

And what about a version of the original design adapted to the new palette, so the background colour is black?

The border being white isn't that big a deal. Concentration Room had the same problem, and nobody complained.

It's been a while since the last build; here are the changes that I can remember:

• Assembly-time option to disable title messages (version and copyright notice)
• New title screen
• Updated Waddles and Karate Kick
• Fixes for egg-on-face bugs introduced previously

@na_th_an
Yeah, I tried some with black instead of white and didn't find it appealing. I'm fine with the title screen in the current build as long as it's agreed upon that the abrupt ending of the diagonal pattern at the edge of the hblank isn't a problem.

@tepples
I think Rock Paper Scissors Lizard Sbock isn't using the current build. There's a palette change in version 9b, the latest posted in the game's dev thread, that isn't reflected in it.

I didn't make myself clear. With "background colour" I meant the HW background colour, i.e. palette index "0", so picture borders (certainly apparent in PAL consoles) are black. Didn't mean the picture background, which I look as it is.

I think it looks fine as is. (As does all your other artwork for this project, great job!)

I like the white background more than the black one, even with the borders.

One quick way to lessen the "problem" could be something like this:

(Although this one in turn might look bad with black borders...)

What's the easiest way to determine whether it's actually using Rock9b?

It's a palette change, noticeable on the anti-aliasing of the countdown digits.
Build 13b is correct (screenshot #76). Screenshot #75 came from build 13.
I just happened to notice it while grabbing screenshots for the box.

I didn't document what I changed from 9 to 9b, but it appears to be just the color on the 3,2,1 sprites.

Rock9 game palette...
2010000F2019110F203323022027180F
001000020019110F0027180F0019160F

Rock9b game palette...
2010000F2019110F203323022027180F
003323020019110F0027180F0019160F

When does this actually come out?

Edit:
I didn't send the final files (inserts for bitboxes and famicom cart labels) until mid-November. (materials for boxed copies all ready earlier though). I assumed infiniteneslives has been busy for holiday season, but sent a message. They'll likely chime in here soon.

I'm going to say that things were pretty busy with the CAPCOM SFII release. "We designed, assembled, programmed, and tested all 5,500 of the circuit boards used for the limited edition Street Fighter II 30th Anniversary Cartridges."

Hey guys,

Yeah sorry about the delays here. My initial goal was to get the contributor carts out by the end of November within a week or two after I got the final artwork items from M_Tee. I had some delays due to printer problems, which have since been resolved. But that pushed me to close to the holidays to get anything done by the end of the year like I was hoping for the release..

So at this point I've got all the physical items in hand for the release. NES & Famicom bitboxes were all aquired a few months back around the same time the traditional boxes & posters came in. I've had the first batch of boards assembled awaiting programming for even longer.

I've been slow to update my software tools to support flashing 1MB rom onto the boards with all the other distractions going on. But I've been making progress on that over the past week. Part of that was making my programmer capable of JTAG communications greatly simplifies the rom flashing process and speeds up board programming time with only one tool.

So anyway, I'm not fully complete with the software updates to flash the final rom onto the boards, but my goal is to finish that by the end of the week. I'd like to start flashing and testing boards over the weekend. That would allow contributor carts to get fully assembled and ready to ship as early as next week. I'll be busy before and after the weekend of PAX south the weekend of Jan 12th. So with all this, I think targeting Jan 22nd for a release date is within reach.

What's the status of the final rom? I know it's effectively been done for months, but is there a final copy ready to go assuming all goes well with final hardware testing?

The other item I could use help with is acquiring names, addresses, and email for all the contributors to get their contributor copy. I think NESHomebrew already has some of this.? Ideally this is something we should be asking for in the submission process, but need to be cognizant of people who might have a different address by the time carts ship.

There's no rush, take your time

I agree, no rush. If anything it would make more sense to get ready for retail copies when this years compo is released. That way, when attention is pushed towards the new releases, we can send people over to buy last years cartridge. Keep things viable in the future. As for names/addresses, I vaguely remember saying I would get them, but I can honestly say that I did not. I'll get on that.

5 week bump. Anything new to report?

Not really unfortunately for the past couple weeks. But I've cleared out my schedule for this week so I can focus on getting all these put together. I'm hoping to have progress to report tomorrow that I've officially started assembly. Where's the final rom I should be using?

The most recent is Page 13b. But if someone wants to make new 10-color screenshots, I'm willing to spin up a new build based on the latest menu software.

Okay thanks for that. I'll report back with progress, and get final 'approval' for the rom before flashing here. I'm pushing to program and test boards this week. I can delay if that's what everyone wants to in order to update the screen shots. But I already feel severely delinquent on this and would like to avoid more delays esp on my part.

For what it's worth, I definitely don't have time in the immediate future to generate new screenshots. Unless someone else is willing to do those, I say we just go with what we have and save the interface updates for v. 4.

Just wanted to check in again quick. I've been focusing on the verilog on the CPLD, and flash algorithm for the program both yesterday and today with slow and mild success. I'm able to dump, verify flash manf/prod IDs, and erase the flash just fine. But the programming algorithm is failing for some unknown reason currently. I can get data on the chip, but some bytes aren't sticking, or are ending up in the wrong place. I've been tinkering with a number of different board/flash versions new & old to try to get to the bottom of things but still not there yet.

No clue why it's being such a bugger but it is.. My typical trick to flash the chip externally and then drop it in the socket doesn't work with tsop packaging. I think my next step is to configure the CPLD for a mapper which is less complex and simpler to program so I can get the flash chip fully flashed and verified. Then reconfigure the CPLD back to mapper 28 and make sure it's playing/tests/dumps properly as I'm highly suspicious of a verilog bug at the moment, but pretty sure I've got a flashing algorithm bug at the same time. So without confidence in any one part of the chain it's a bit of a challenge..

Anyway, I'm confident I'll figure things out soon enough. Just wanted to give update of where I'm at and this is no longer sitting on the back burner. Once I get things working I'll report back and plan on play testing until the following day. At which point I'll start programming boards with whatever is the most final rom version at that point. Expecting it'll be the same build Tepples pointed me to, but until I report back there's at least 24hrs to make any last min tweaks for any reason.

Another progress report for ya'll. As is typical I can't find problems without taking a break and getting a fresh look at things. I resolved all the problems I was having and am able to fully program the cartridges with my new inlretro programmer build (512KB PLCC & 1MB TSSOP-48). However a new problem has reared it's ugly head..

When running on the 1MB 3v TSSOP-48 flash, I can get things to boot and most games start. But they don't go for long until they crash. I have this problem with both vol2 & vol3 so it's not rom related. I also have effectively identical crash points for games on original NES & a cheap clone. I've also verified this on two different cartridge boards. So everything is highly repeatable and invariable for the most part.

HH85 always crashes after the serum/life count screen while trying to load the actual level I assume. Twin dragons boots & plays, but after 10-30sec of gameplay it locks up typically with garbled sprites. Nebs 'n Debs won't boot, and filthy kitchen runs okay, but there appears to be mirroring issues after walking into the house which is a bit strange..

When playing part1 & 2 separately on the 5v PLCC flash none of these issues exist and everything plays & boots just fine. I also doubled up action53v2 to 1MB and ran it from 3v TSSOP flash and experienced similar problems.

So it's pretty apparent I've got a bug when running from 3v TSSOP flash, as 5v PLCC flash runs perfectly. The biggest difference is that the 3v flash is behind a level shifter. I've got a single Lattice Diamond build for the CPLD where I'm only swapping out the few lines of code that toggle between 5v 'external' flash, and 3v 'internal' flash including level shifter control code. So I can mostly eliminate any of the other code from being a bug source. I'm a bit miffed as to what's going on, but I'm only just now running into the new problem. While it sounds like a timing issue, I'm not fully convinced. Both 5v and 3v flash chips are 70nsec, and with the crashes being so consistently repeatable between boards/consoles it smells of a logic problem. So I'll take a break for a bit and come back later today with fresh eyes and hope for the best..

[about to click submit on this post, and the therapy of writting out the problem gives me a handful of ideas for things to check...]

I solved it! Turned out that the flash chip was getting locked up with mapper writes to $8000-FFFF which were also getting 'written' to the flash chip. This was happening to the 5v PLCC flash as well, but the 3v TSSOP flash is a completely different part with different behavior. I've seen issues like this in the past with SNES designs of mine using this same flash chip. And this is effectively the first time I'm using 3v flash on my NES design. The 5v flash has proven more 'bullet proof' being unaffected by mapper writes that also get applied to flash causing any problems, so that explains why the issue never appeared previously.

So for now my temporary fix simply ties flash /WE pin high and it plays great. But this means I can't program the flash with this CPLD configuration. I can flash the CPLD twice, but I'd rather have a permanent fix for this issue. Really what we need is an addition to mapper 28 which enables/disables writes to flash. With other bits of the mapper being required to startup high, it's best to have this bit high upon startup as well. Default setting on startup should be flash writes disabled. So "F = 1" disables flash writes, and "F=0" enables flash writes.

Tepples, do you have input on where we should put such a 'flash write' disable bit? There is benefit in not requiring further address decoding other than what the mapper already requires, so it may be best to put this in "$5000: Register select" bit 1 perhaps? This has the disbenefit of all writes to $5000 requiring the Fbit to be set effectively which I assume requires modification of the current build(s)..? It also effectively makes older versions of action53 incompatible with this board. If all previous builds default to writting '0' to the unused $5000 bits, then I guess it's not a big deal for the CPLD to invert the write so F=0 disables flash writes.

The alternative would be to add another register address specifically for this bit. But as the mapper is currently defined, new CPU address pins would be required. Adding extra pins for decoding is a big of a pain for my smaller board which we use to publish volumes which are 512KB or less. However when 1MB or more is required, the mapper has the entire CPU bus visible as they all had to be levelshifted for the 3v flash anyway.

If we don't really want (or have time) to think too hard about redefining mapper 28, I can always put in a 'back door' register which may only ever exist in this build/publishing. Maybe a register at $5555 which has to be set to 0xAA in order to enable flash writes, and any other value disables them. This would also require the register select to only decode to all values of $5000-5FFF except $5555 which might be weird but likely works. This board doesn't have PRG-RAM, so $6000-7FFF is actually open and available, maybe putting the flash write enable somewhere in there makes more sense, but the definition isn't forward compatible with PRG-RAM being added in a future volume/build. And there's the whole aspect of temporary fixes typically becoming permanent solutions..

I'd be willing to explore extending the A53 mapper with new register $2A exposing a flash memory control port. Then enabling or disabling /WE would look like this:


These registers would still respond to $5000-$5FFF and $8000-$FFFF like any other A53 mapper feature, but use of $5555 or $AAAA thematically matches the rest of the flash unlock sequence and would be easy to catch with the debugger.

Not sure if I want to mark it as user ($2A) or supervisor ($AA) though. It depends on whether we want to built in a self-flash mechanism analogous to that of so-called UNROM 512.

Ahh yeah adding another 'internal' register "2A" should work which makes more sense for the design of the mapper. I'll test that out to confirm I don't have a conflict somehow during there for my flash routines.

For a quick fix, earlier I required $5000 bits 6-1 to be set to "101010" in order for writes to $8000-FFFF to get applied to the flash and everything including erasing, flashing, and playing was working great.

So thinking about this more closely as I'm trying to implement it, there's a number of ambiguities with things getting complex quickly.

So for the $5555 register, is that the only specific address where bits 6-1 of the select register stick? Or can you write 0x2A to any address $5000-5FFF and it has same effect as writes to $5555?

Similarly, does the write to the 'flash enable register' have to occur at $AAAA, or can it be anywhere in $8000-FFFF? I'm assuming it must be $AAAA specifically.

If I understand your code correctly, some modifications would be needed:


I do think there's value in simplification where possible so long as protection is adequate as there's been several mentions of interest from compo entries to utilize flash saves. But to be honest the complications here are quite significant and even I have a hard time wrapping my head around all this. It gets even further complicated by not really knowing what part number will be used for the game. 128-512KB, 1-2MB, and 4MB+ all have different address/command pairs, different expedited flash algorithms, and the board design may change in the future. 128-512KB flash doesn't even require flash write protection. The creator of a compo entry can't know any of those details in development. And even if they do, we may use a 512KB flash for that individual compo release, and a 8MB flash on a future multi-volume mass compilation. It's unlikely devs will be interested in updating their entry to support the new board config year(s) after the fact.

So I guess what I'm trying to say is for right now, the specifics of what we implement for this flash shouldn't really matter for the future. I'm suggesting we don't even publish the solution we use here in the wiki. It's only real purpose is to allow me to manufacture this volume's cartridge.

In the end if we want to provide flash save option to future compo entries, I think it's best to abstract away the actual flash save algorithm completely. There are a few ways we could do this, which is probably a discussion for a different thread. But one idea would be to define mapper 28 CHR-RAM as battery backable. In practice though, the action53 menu rom could have helper functions present at $6000-7FFF which transfer CHR-RAM data to/from flash instead of actually placing a battery on board. Or maybe we just avoid all the hassle and drop a 32KByte battery backed SRAM on the board and give each entry 128-1024Bytes of save RAM. IDK what's best, but the complexities of entries writing directly to flash may never be reasonably within reach..

The latter. It'd just be plain old register $2A that can be set to the flash enable value or any other value. All other values ($00-$29 and $2B-$FF) would retain their meanings per the mapper.


I had assumed anywhere in $8000-$FFFF.

But it seems that going forward, we don't want to put this in the mapper definition, instead treating it as an implementation detail. So do what you think is appropriate for this volume and the next.

Sounds good. I'll report back with the final implementation for documentation purposes.

Only other detail to cover for the rom's release then is special messages on the title screen. Is there a feature to do this as we have in past years with contributor carts and number of LE copies? I guess we'll survive without it, but if the feature is already built in and ready to use, what's the hex offset and limits for the message?

I plan to work on re-adding that feature this evening if I don't have any paid work to do.

Sounds good. Take whatever time you need as far as I'm concerned. I'm pretty slammed with Lizard builds at the moment. But as soon as that calms down I'm planning to shift directly into action53 builds. Aside from this final rom tweak, we still need contributor info including title message, mailing & email addresses before I can ship contributor carts, and follow with public release shortly afterwards.

I did some more thorough testing of the current build and found some issues. I'm not sure how important it is to us to remedy these, but I wanted to bring them up if their easy fixes.

Several games don't seem to handle reset. It's about 50/50 or worse, most of the times reset just crashes and can't be recovered from without a power cycle. Includes most/only Runner up games: Brick layer, Flappy, Jupiter.

Brick Breaker & Flappy Jack seem to have issues of not clearing out nametables, or perhaps making PPU writes while rendering..? Brick Breaker starts with a bunch of junk on the screen that gets scrolled to black as I assume it was supposed to be completely. Flappy Jack has 'junk' sprites/tiles scattered throughout the "LEVEL #" screen everytime. There are a couple other things like this during screen transitions in Flappy, but those are a brief single frame. The LEVEL screen they're permanent and scattered throughout the screen.

Waddles the Duck has a strange issue, maybe its a feature? But doesn't quite make sense. I don't think it's clearing out RAM on start up because if you restart the game, or even hit reset and replay Waddles, the 'gem' blocks (mimic of SMB coin blocks) are already collected if you got them in a different play through. If you really want a fresh start on Waddles, you MUST power cycle the console it seems.

For waddles, I can confirm that's a feature. It clears out all ram unless a specific byte in ram has a specific value that waddles sets to it. In that case the page in ram that has gems is left alone. To get the "true" ending, the player has to collect all gems in all levels, and the RAM thing is meant to make that a little less daunting. Loading and playing another game should reset it the way you'd expect most of the time. (And yes, I realize I'd have been smarter to do a checksum, but I didn't have the time/energy...)

Hope that helps narrow down the issues

Thanks cppchriscpp, that's certainly an interesting feature. Perfectly fine, thanks for the explanation.

Failure to recover from reset would be my problem. Because NROM-128 entries outnumbered CNROM entries in the first, second, and third competitions, I tried to pack two 16K PRG ROM segments into one 32K bank. When I get around to re-adding support for a gift message, I'll investigate reset failures in the games you mentioned. I anticipate that several things might make this take longer than I wish I could guarantee to you for the following reasons:

• Since I made the page 13 build, the second replacement battery in my laptop (that is, the third battery in all) had died, and I had migrated to a different computer. It might take me an hour to dig up the project files from my old computer that I no longer use.
• I can't test the full 1 MB ROM on hardware. I can test the half ROMs on a PowerPak or the full ROM in FCEUX debugger, but that's it.
• Paid work comes first. It'd have to be on a day when I don't get a lot of hours at Phil's Hobby Shop or Retrotainment Games.

Understood, TBH the reset problem isn't a huge deal IMO. I'll test with the 512KB versions to see if it behaves similarly.

While testing the 512KB rom with the reset problem titles, I was not able to replicate the issue as easily as with the 1MB rom had on real hardware.

I did get a core dump screen from brick breaker one time suggesting the reset vectors weren't in place. And one time I got jupiter scope to crash and hang on reset.

So with the 512KB rom I'd say it's much less noticeable for whatever reason. If you're unable to sort out what's wrong due to inability to easily test I'm not sure how much it's worth worrying about.

What actually happened to me over the past nine days is that Retrotainment Games dumped a ton of work on me related to a project that has not been announced.

Not a problem! I can completely understand that paid work goes before volunteer work. I've pretty much been in the same boat. I think that I can speak as a group in saying that your work has been invaluable to the success of the competitions.

Brick Breaker simply leaves the screen ON without first clearing the nametable and all video updates are done exclusively on vblank time. The new build I made fixes that by turning off the screen during startup and doing full screen updates via PPU burst mode which I should have done a long time ago. The newest build was posted in my game's thread.

I need to check this thread more often.

No worries, I'll be testing your latest build of brickbreaker and dougeff's flappy later today and reporting back.

Quick update, Flappy & Brick Breaker have updated roms in their respective threads with corrections to the issues mentioned previously. So this should cover things enough to call all individual roms ready for final build.

Status update: Today I recovered the files for volume 3 and got it building on volume 4's codebase, with the new versions of Brick Breaker and Flappy Jack.

Brick Breaker and Jupiter Scope have in common that they occupy the bottom half of a 32 KiB bank using the "submulti" mechanism, which puts two 16K PRG banks into one outer bank. When a submulti is running, the game's 16K bank is mirrored into both $8000 and $C000 using UNROM (180) mode for the bottom half game or UNROM (2) mode for the top half game. The exit patch for the bottom half game involves switching the second half into $C000 and then running the top half game's exit patch, which switches to the menu bank. This process works every time in FCEUX, but then FCEUX always stops execution at the same point in a frame. So just to make extra sure, I've added 3 bytes to the bottom half exit patch to disable NMI (which toploaders don't do on reset).

I don't expect volume 4 to use submulti because CNROM entries outnumber NROM-128 entries to such an extent that there isn't enough space in unused portions of PRG ROM banks to hold all their compressed CHR data.

Does this build work better? If so, that leaves one more thing for me to do, namely restore the ability to customize text displayed over the title screen.

Thanks for your efforts.

I've noticed a very, very, very minor issue with Goddess which my Obsesive Compulsive self can't let go: it's v1.5 but it says 1.3 on the title screen. Would it be much of a hassle if I submit a fixed version? If it is, I can live with the 1.3

The version string ("1.3") is stored at $DD20 in the iNES ROM, which corresponds to $DD10 in the fixed bank. So changing the byte at $DD12 to $35 fixed this. The Action 53 builder can replace short hex strings without needing to change the ROM file itself.

It's patch1 (not patch3 as might be expected for the fixed bank of a 64 KiB UNROM) because the prgunused and patch commands count 32K banks.

tl;dr: No worries.

Thanks for the effort on this Tepples, I'll test it out today and report back.

Thank you

4 day ping.

The next build will include space for a gift message of up to 26 characters and 128 pixels.

No Jupiter in Jupiter Scope. Mirroring problem?

Thanks for the poke Tepples, All the repairs to the individual roms appear corrected. The reset lock up problem still seems to be there. FWIW Jupiter scope is the easiest for me to replicate with and it seems like reset typically works from title screen, but resetting while playing or on game over screen locks up the cart/console more often than not. But IDK if it's worth getting to worked up about at this point since it's not looking to be an easy fix. I can get you a cart to allow you to build and test 1MByte roms on if you'd like.


Oh I didn't notice that, I'm not even sure I've seen Jupiter in the back ground. ever..?

I fixed the missing Jupiter in Jupiter Scope problem in my local build. It was indeed mirroring.

Another problem with fixing freezes that occur on hardware and do not occur in an emulator is that I don't own a logic analyzer with which to pinpoint which instruction caused the freeze. I'd be interested in ways to pinpoint which instruction caused the freeze without needing to purchase and use a logic analyzer.

I guess I'll have to get my (old model) Kazzo working again in GNU/Linux. The last time I tried it was several years ago, before I started using GNU/Linux almost exclusively.

I've got a new software and firmware build that runs in linux. I'll share it with you before I get the board sent your way. The old software and firmware won't even support flashing this new board design so don't waste your time with that.

I don't want to delay the release to sort out this reset issue, but with everything else on my plate at the moment I won't have time to release A53 for a few more weeks. So if we can manage a remedy in that time all the better. If not, we'll just move forward with the build that correct JScope and adds in custom messages.

This fixes the display of Jupiter and adds enough space for a 2-line gift message. But I still can't replicate the Reset freeze in an emulator.

This screen? if so, AFAIK coredump is not located directly under any hardware vector and only should pop up if the A and B buttons are pressed when the menu starts up.
Though now that I think of if, it would have a high probability to run correctly if something jumped into the middle of it, as it's whole state is contained in just 1 CPU register.

Is this being tested on a top-loader (HVC-* or NES-101) or a front-loader (NES-001)? It matters because a front-loader disables NMI on reset and a top-loader doesn't.

My next direction is to log all writes to the mapper ($5000-$5FFF and $8000-$FFFF) from game start to reset, in order to test for defects in the implementation of the mapper in the CPLD that depend on write order. I remember FCEUX having such order dependencies.

Was better part of a month ago now, but I believe so. I've seen the Lizard crash screen a number of times lately (poor connection at powerup when testing) so my photo memory is a little blurry. I just recall seeing something that fairly obviously looked like a blue screen crash report.

I'm testing on a front loader. Although I've also tested on a clone console and had no issues there. I have a few other consoles to test on including AVS and such so I'll try to see if it's limited to one specific console or not.

EDIT: With there being a significant amount of logic to spare on the CPLD, I'm wondering if it would be worthwhile to implement a hardware mapper register reset that detects reset condition on CPU A0 and/or M2 and resets all mapper registers. Guessing that may be a useful feature for rom builder tool as well..? That logic may not be as easily implemented on my 32 macrocell board if we step back down to 512KB PRG-ROM on future volumes, but I should be able to easily do it on this volume as I have a ~20Mhz oscillator and a plethora logic cells on chip at my disposal.

Surely all you need is one spare input, and the diode-resistor-capacitor detector externally?

Sure, but I don't have those external components and connections included in my current designs nor stock in blank boards. So that method of reset detect may not be an option.

That would break Waddles.

This is how it's supposed to play out. Do you have a simulator in your CPLD devkit? Can you feed in a sequence of $5000 and $8000 writes and monitor the output on A19-A14?

Player chooses Jupiter Scope 2
Alternate write $08 to $8531 and $FF to $FFFD until CHR RAM is filled
Code running from RAM
Write $19 to $83DA (outer PRG bank = Jupiter2 and Super Tilt Bro.)
Write $80 to $5000 (mode)
Write $8A to $8000 (mirroring=vertical, mode=UNROM180, outer size=32K)
Write $01 to $5000 (inner PRG bank)
Write $00 to $8000 (inner PRG bank = 0)
Write $81 to $5000 (outer PRG bank)
JMP ($FFFC)
Now running Jupiter Scope 2. A14 is high ($C000-$FFFF), but the output is 16K bank $32 because in UNROM180 mode, $C000-$FFFF is switchable
Play a while
Reset at $BFE0. A14 is low ($8000-$BFFF), and the output on A19-A14 should still be $32.
Write $01 to $5000 (inner PRG bank)
Now 16K bank $33 (Super Tilt Bro.) should be swapped into the top half.
Write $81 to $5000 (outer PRG bank)
JMP ($FFFC)
Now running Super Tilt Bro's exit patch. A14 is high, in 16K bank $33.
Write $81 to $5000 (outer PRG bank)
Write $FF to $8000 (outer PRG bank = $FF)
This changed the outer bank to that of the menu. A14 is high, in 16K bank $3F.
JMP ($FFFC)
Write $81 to $5000 (outer PRG bank)
Write $FF to $8000 (outer PRG bank = $FF)
Write $80 to $5000 (mode)
Write $02 to $8000 (mirroring=vertical, mode=BNROM, outer size=32K)
Now displaying Action 53 title screen

From here, the next steps are as follows:

1. Paul tries 8 Mbit builds of Holy Mapperel and test28, which I've attached
2. I make 4 Mbit and 8 Mbit ROMs similar to test28 that play this exact write sequence

Thanks for this Tepples, I'll be home again tomorrow and this gives me some things to test out and report back.

Did you get anywhere in the past few weeks, either running that write sequence through your simulator or running the 8 Mbit test ROMs?

So I tested the gift message action53 rom on a number of different consoles and found that the problem only exists on the original NES.

Two different NTSC front loaders, and a PAL front loader exhibited the issue.

RetroUSB AVS, Hyperkin FCmobile2, & RetroDuo portable all worked fine after reset.

Testing the mapper28 test I assume that I can effectively test the reset condition multiple times repeatedly very quickly by simply pressing reset over and over again? The rom seems to report the status of the most recent reset.

I found that the reset test always seemed to pass with AVS & FCmobile. With the retroduo it usually passed, if I hit reset enough times eventually it would fail and then get stuck in that condition failling forever afterwards.

With the original NES the reset test passes about half the time. Interestingly if I keep pressing reset it will go back to passing condition sometimes. It'll toggle between pass/fail over and over again never getting stuck in one state. But it's not like it toggles each reset. It fails a few times, then passes a few times in streaks of 1-5 tests or so..

Don't think it matters much as it's not a problem with the action53 rom, but the power up test fails sometimes. With the FCmobile it's the worst, sometimes I have to power cycle it quickly to get it to pass power up. The AVS failed the first power up test, but then passed every time afterwards. Retroduo seems to always pass. The NES typically passes, but if the power wasn't left off for long enough it'll fail typically. I'm guessing this is all due to startup sequence of the CPLD and whether or not it fully shuts down. Either way power up isn't an issue with the current action53 build.

So with all this my conclusion is that it's probably not a software issue. I was starting to doubt that anyway considering when I first found the issue it didn't fail 100% of the time. My best guess is the execution of the 6502 through a reset on the original NES isn't that 'clean'. Maybe if the CPU is in a write cycle during reset, it gets erroneously decoded as a write to the mapper register and corrupts the mapper state. Still doesn't explain why I've only seen the issue with certain games within a53, but none of this is consistent anyway..

I've got some ideas of how I might be able to filter things from the CPLD that I'm going to give a try over the weekend. I'm considering doing things such as fully decoding the CPU address for writes to the $5000 register. Or maybe block register writes if CPU A0 and/or M2 isn't toggling regularly. I seemed to have some issues with my flash write allow register getting corrupted when flashing the cart as well. Now that I'm writing this, perhaps it's all related to the same problem. So I'm also thinking I'll just go through my verilog to see if there's anything I can find that stands out as a potential issue or I want to rewrite the whole thing. It was forever ago when I wrote that and wasn't as experienced as now..

In the end I don't feel this is a big enough of issue to delay the release further. If anyone disagrees and considers this bug more significant please chime in.

I've got time set aside to start builds after tax day next Tuesday, so whatever the state of things is at that point I'm planning to move forward at that point.

The biggest thing I need right now is the email list of contributors so I can blast everyone asking for their shipping address and desired cart form 60/72pin. I don't want to release the public sale until those have been shipped out to contributors. But I've got ~200 carts to assemble to keep me busy while we're hunting down contributor info. I'm doing what I can to push and get contributor carts out and the public release by the end of April.

I'll get those to you tonight.

Cartridges are assembled, and I'm trying to push the release out by the end of this week if possible. Before the release I want to make an effort to get contributor carts out first. So I'm blasting the contributors right now to get their mailing addresses & desired gift messages. I'm pointing them here to discuss finer details of the gift message if needed.

What are the required specs? I see there's 2 lines total, but I'm guessing the length isn't a fixed character count as the text is variable width again. Based on the demo message looks like it's somewhere around 27 characters per line, with 2 lines total?

If the contributor doesn't want to use 2 full lines, I'm thinking a standard first line of something like "Contributor Edition" for the first line, with their name/message on the second. Anyone have a better less boring suggestion?


EDIT: I just blasted all contributors I had record of via email. So if you had an entry to the 2016 compo, or contributed to Action53 vol3 in anyway and didn't get my email let me know. emailing paul@infiniteneslives.com is best.

Are the contributor cartridges indistinguishable from the regular ones?

As is currently planned, they're physically the same. The difference would be on the title screen where the contributor editions will say something like "Contributor Edition <contributor's name/handle/message>". The publicly available 100x Limited Editions will say "Limited Edition 1 of 100" type thing. I haven't slapped the Caution stickers on the back of the carts yet, so if we wanted to come up with a different Caution label to physically distinguish them.

The regular edition NES carts will be grey, and all the famicom carts will be yellow.

Hold up, why'd I get an email? Nothing of mine is on the cart.

EDIT: Also, the shop page links to a contributor list that doesn't actually include volume 3 (yet).

You contributed Wrecking Balls to the competition, right?

Maybe you're confused which compo volume 3 includes? It's the 2016 entires from Feb 2017 (including your Wrecking Balls entry), I should have got the cart released within the year. But it's late now and releasing after the 2017 compo which ended a few months ago. Those entries will be on volume 4.

As mentioned in the contributor email it's still a work in progress with remnants of volume 2. I wanted to go ahead and give you guys the link while I had your attention. Not release the link publicly, but it's not that hard to guess anyway..

Yes, but I never finished it. Did it end up on the cart despite me pulling it? Or are contributor carts for all contributors, regardless of whether or not they made the cart?


Oops. Sorry.

Yes, it was left out of the cartridge but it was still an honorable entry to the competition so we would like to gift you the cartridge. Maybe we'll see it or another entry completed on a future compo/cart..? Don't feel like you owe anything of course, we just prefer to err on the side of generousity in these cases rather than nitpick what's good enough to be considered a contribution.

No worries!

Release details posted! http://infiniteneslives.com/action53vol3.php

Contributor copies are packed up and will ship out Monday/Tuesday.

EDIT: Would someone like to volunteer to update the contributors list on the wiki?

Here is half the work of updating the contributors list, from what I was able to gather on results page. Notably missing are "Button logger", "Musical controller" and anything in the "More" tab.

Content section:


It is sorted by position in the competition. Winners first, losers last.

Contributors serction:

Already present in volume 2:


First appearence (by order of appearence in the menu):

Two people report CHR corruption on the cart:
http://nintendoage.com/forum/messagevie ... =26#bottom

Was this one of the known issues?

"The glitches seemed to stop happening after I played the cart for 20-30 minutes, and now I haven't seen them reoccur since. It was like I had to break the cart in."

This is the first 8 Mbit game from INL, and the transition to putting the whole board behind 3.3 V translation isn't going to be easy. Someone with a logic analyzer will probably need to figure out what's going wrong, and I currently have too many other projects going on, paid and not, to become that someone myself.

Is there an official ROM version that has no placeholder gift message, but fixes Jupiter Scope 2's title screen?

I'd say just fill the gift message with spaces and call that official.

I haven't received my copy yet. I'll have to get in touch with Paul to see if he's still waiting on something.

It's just a ROM download with no instructions. How do I fill the gift space?

...and by "I", I mean the person I might like to tell about this amazing free ROM they can download. I know how to use a hex editor. What I'm saying is that there doesn't seem to be any official clean finished version I can link to. I could make one without the message, but I don't feel like it's appropriate for me to re-release your compilation, you know?

Here's the most recent build with the gift message replaced with spaces.

Thanks.

Has everyone else gotten theirs already? I'm trying to be patient, but haven't seen any sign of it yet

I can tell you i haven't seen mine yet. No stamps.com email either, though idk if that's expected here or not. (My past INL purchases have gone through them; only reason I mention it)

Mine arrived today.

Great, there's still hope. I was afraid the post office lost it or something

I don't think I need to say that I won't be seeing the cart soon. You guys are all privileged

Why is it that Ralph 4 doesn't play the title song, when it exists inside the ROM? The game has two songs but only the in-game song is playing.

The stand-alone version is the same way, so that doesn't seem to be a problem with the Action 53 ROM:
https://forums.nesdev.com/viewtopic.php?t=14070

The source code seems to suggest that the "title" music is actually used for the ending screen instead:
https://github.com/pubby/Ralph-4/blob/master/src/main.s#L270

Yeah it's the ending screen song.

Humm ok. It's just that the FTM says that song is title/end, so I guess in the end you decided to play it only in the ending. Kind of a bummer because I loved the song. I'm sending you a PM about it.