Action 53 volume 3

Moderator: Moderators

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Action 53 volume 3

Post by tepples »

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
M_Tee wrote: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
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
calima wrote:The CNROM support isn't really mandatory for this year [...] Would be good for next year, though.
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
M_Tee
Posts: 430
Joined: Sat Mar 30, 2013 12:24 am
Contact:

Re: Action 53 volume 3

Post by M_Tee »

tepples wrote:
RogerBidon wrote:As entrant, do we have to do it, do we can do it or somebody dedicated wants to work for us?
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.

Here are the screenshots from the previous volume (some colors may be wrong; click to zoom):
da53_screenshots.png
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:
Image
(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.
Last edited by M_Tee on Thu Mar 02, 2017 7:59 pm, edited 2 times in total.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Action 53 volume 3

Post by Memblers »

tepples wrote: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)?
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.
M_Tee
Posts: 430
Joined: Sat Mar 30, 2013 12:24 am
Contact:

Re: Action 53 volume 3

Post by M_Tee »

tepples wrote: 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
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.
User avatar
RogerBidon
Posts: 44
Joined: Wed Dec 28, 2016 7:16 am

Re: Action 53 volume 3

Post by RogerBidon »

M_Tee wrote:I thought it might be best for consistency to have one person handle them all and put these together this morning
Do you know how awesome you are? Thank you!
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Action 53 volume 3

Post by dougeff »

"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.
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
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Action 53 volume 3

Post by infiniteneslives »

Memblers wrote:Whatever chip is on this board could be totally different though.
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.
Last edited by infiniteneslives on Wed Mar 01, 2017 2:39 am, edited 1 time in total.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
na_th_an
Posts: 558
Joined: Mon May 27, 2013 9:40 am

Re: Action 53 volume 3

Post by na_th_an »

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:
Attachments
crop_wo.png
crop_wo.png (1.02 KiB) Viewed 11803 times
crop_la.png
crop_la.png (1.13 KiB) Viewed 11803 times
crop_go.png
crop_go.png (1.18 KiB) Viewed 11803 times
Last edited by na_th_an on Wed Mar 01, 2017 4:06 am, edited 1 time in total.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Action 53 volume 3

Post by calima »

@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?
Attachments
sinking3.png
sinking3.png (385 Bytes) Viewed 11810 times
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Action 53 volume 3

Post by gauauu »

tepples wrote: 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.
I'm not surprised. I'll fix it as soon as I get a chance.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Action 53 volume 3

Post by tepples »

M_Tee wrote: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
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.
M_Tee wrote:each screenshot uses different settings (regarding scaling mode, dithering, and locked-in colors) to try to get the best result.
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.
M_Tee wrote:There are two for the 240p test, I think the bars would be better
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.
Memblers wrote:unless the mapper has a habit of ignoring mapper writes or changing banks on it's own, which would be strange indeed.
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.
infiniteneslives wrote: I'm not really interested in a flash chip that can't be programmed in circuit.
By "in circuit" do you mean in a Kazzo device with full expansion pin control or in a stock NES or Famicom?
calima wrote:Do you still need it converted to NROM?
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.
M_Tee
Posts: 430
Joined: Sat Mar 30, 2013 12:24 am
Contact:

Re: Action 53 volume 3

Post by M_Tee »

tepples wrote:
M_Tee wrote: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
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.
M_Tee wrote:each screenshot uses different settings (regarding scaling mode, dithering, and locked-in colors) to try to get the best result.
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.
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.
Attachments
240pee-3.png
240pee-3.png (1.37 KiB) Viewed 11698 times
NEStopia_Palettes.zip
(1.68 KiB) Downloaded 349 times
Palette.png
Palette.png (3.79 KiB) Viewed 11698 times
2017-compo_jroatch-misc-stuff-2.png
2017-compo_jroatch-misc-stuff-2.png (1.29 KiB) Viewed 11698 times
M_Tee
Posts: 430
Joined: Sat Mar 30, 2013 12:24 am
Contact:

Re: Action 53 volume 3

Post by M_Tee »

tepples wrote: 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.
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.
Image

Edit: typo.
Last edited by M_Tee on Sat Mar 04, 2017 8:25 am, edited 1 time in total.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Action 53 volume 3

Post by infiniteneslives »

tepples wrote: 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.
Yeah that sounds about right. That's how it's been setup to date with the kazzo code to flash games during production.

infiniteneslives wrote: I'm not really interested in a flash chip that can't be programmed in circuit.
By "in circuit" do you mean in a Kazzo device with full expansion pin control or in a stock NES or Famicom?
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.
calima wrote:Do you still need it converted to NROM?
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.
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.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Action 53 volume 3

Post by gauauu »

tepples wrote:
  • 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.
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.
Post Reply