To make up for there being no multicart for the 2011 NESdev compo, I'm working on rewriting the menu system so that we can include the NROM entries from both last year's and this year's, as soon as I can drag myself away from Cracked.
Need to drag yourself away from Cracked? Try TvTropes.
That's something I wanted to add too. Making carts shouldn't take long at all, I mean Tepples engine probably isn't too bad to add games too, I don't see why it didn't get put together last year. At the least make it work on something like MMC1 and commission a repro maker to make the games.
Dwedit wrote:
Need to drag yourself away from Cracked? Try TvTropes.
Ha Ha Ha!!!!! Nice.
Dwedit wrote:
Need to drag yourself away from Cracked? Try TvTropes.
Way ahead of you, brother.
Q: It takes two to
- tango
- mango
- make an accident
- make a multicart
- make a thing go right
- make it out of sight
- all of the above
A:
Imagine it being as easy to build a multicart of NROM games as it currently is to build a PocketNES image.
Nice work Tepples! I don't want to write off the CompoCart yet, but I don't see why they couldn't be on both.
53 NROM games on one cart? 
That's a really BIG amount.
Nice work, Tepples!
That's a really BIG amount.
Nice work, Tepples!
Does BNROM guarantee that the first page will be swapped in at reset, or does every page need reset code?
I believe it could start in any bank. But another consideration, is that we can't know what bank it will be in the when the user hits reset - you'll always want some kind of reset vector available.
Because it uses the '161 which has a /clear input, I suppose it would have been possible to put an RC circuit (resistor-capacitor) on that, charged by Phi2 (M2). Kinda sucks I didn't consider that when I did the board layout, but oh well, it's only slightly annoying to add a bunch of 8-byte segments into LD65's configuration (8 bytes should be enough for mapper reset and JMP).
Because it uses the '161 which has a /clear input, I suppose it would have been possible to put an RC circuit (resistor-capacitor) on that, charged by Phi2 (M2). Kinda sucks I didn't consider that when I did the board layout, but oh well, it's only slightly annoying to add a bunch of 8-byte segments into LD65's configuration (8 bytes should be enough for mapper reset and JMP).
Memblers wrote:
8 bytes should be enough for mapper reset and JMP
I imagine you'll have to replace every game's reset vector by the address of this 8-byte sequence as well. Could this possibly be a problem? I don't think many games use their reset vectors for strange purposes.
With some of these smaller games you certainly will want to fit more than one game per bank. The games true reset vector would be wherever it's convenient for the menu program (such as in a table that includes the NMI and RESET vectors of every game). In this case I normally set the ROM's NMI to point to $0170 or someplace odd that wouldn't be touched normally, the menu program can just put a JMP there. The "fake reset" triggered by the menu would be similar, but include a bankswitch write before the JMP.
Memblers wrote:
With some of these smaller games you certainly will want to fit more than one game per bank. The games true reset vector would be wherever it's convenient for the menu program (such as in a table that includes the NMI and RESET vectors of every game). In this case I normally set the ROM's NMI to point to $0170 or someplace odd that wouldn't be touched normally, the menu program can just put a JMP there. The "fake reset" triggered by the menu would be similar, but include a bankswitch write before the JMP.
The reset vector doesn't even have to be the same in all banks, as long as you are willing to make the reset code larger than 8 bytes (so that it can bankswitch from RAM). This is a good idea if by any chance it's impossible to find a ROM location that's free in all games. Something like this should work if the menu is in bank 0 (finding 19 free bytes is harder than finding 8, but finding 8 free bytes in the same location in all games might be harder than finding 19 bytes anywhere):
Code:
Reset:
ldx #$06
- lda Bankswitch-1, x
sta $ff, x
dex
bne -
jmp $0000
Bankswitch:
stx Bankswitch-1
jmp InitializeMenu
ldx #$06
- lda Bankswitch-1, x
sta $ff, x
dex
bne -
jmp $0000
Bankswitch:
stx Bankswitch-1
jmp InitializeMenu
In banks that only have one game, the NMI vectors don't have to be changed. Some games have very timing-sensitive NMI routines, so this is a good thing. Hopefully this will not be the case for the smaller games.
Dwedit wrote:
Does BNROM guarantee that the first page will be swapped in at reset, or does every page need reset code?
Tokumaru guessed most of the design that I plan to use. NROM-128 automatically gets patched at $BFF0 if the reset vector is in $C000-$FFFF or at $FFF0 if the reset vector is in $8000-$BFFF. With NROM-256 or CNROM, the user must specify in a config file (the same one with the instruction blurbs) whether to patch 10 bytes at $FFF0 (more or less the Barbie stub) or 21 bytes anywhere (more or less the stub tokumaru listed). I also plan on storing the data that the patch replaces in the ROM's directory so that extraction of individual ROMs from the multicart is still lossless.
Memblers: Multiple titles can share a PRG ROM bank if the config file gives each game's entry point. These can even use CNROM if the game doesn't bankswitch after starting.
How are you emulating CNROM with BNROM?
tokumaru wrote:
How are you emulating CNROM with BNROM?
By loading the CHR bank assigned to the title before handing control over to the game. It's for things like Donkey Kong Classics, which combine two originally NROM-128 games into one CNROM. Games that switch banks after the game begins obviously wouldn't work. For example, the config records for four of the games might look like this:
Code:
# config file for action 53
title=LJ65
author=Damian Yerrick
year=2009
rom=LJ65_CRoom.nes
chrbank=0
reset=$C000
description:
Pack the blocks[etc]
.
title=Concentration Room
author=Damian Yerrick
year=2010
rom=LJ65_CRoom.nes
chrbank=1
reset=$8000
description:
Flip cards[etc]
.
title=Lawn Mower
author=Shiru
year=2011
rom=Mower_Thwaite.nes
chrbank=0
reset=$C000
description:
Cut grass[etc]
A: Go fast
.
title=Thwaite
author=Damian Yerrick
year=2011
rom=Mower_Thwaite.nes
chrbank=1
reset=$8000
description:
Shoot down ABMs[etc]
B: Fire from left silo
A: Fire from right silo
.
title=LJ65
author=Damian Yerrick
year=2009
rom=LJ65_CRoom.nes
chrbank=0
reset=$C000
description:
Pack the blocks[etc]
.
title=Concentration Room
author=Damian Yerrick
year=2010
rom=LJ65_CRoom.nes
chrbank=1
reset=$8000
description:
Flip cards[etc]
.
title=Lawn Mower
author=Shiru
year=2011
rom=Mower_Thwaite.nes
chrbank=0
reset=$C000
description:
Cut grass[etc]
A: Go fast
.
title=Thwaite
author=Damian Yerrick
year=2011
rom=Mower_Thwaite.nes
chrbank=1
reset=$8000
description:
Shoot down ABMs[etc]
B: Fire from left silo
A: Fire from right silo
.
Each ROM would become two titles in the menu software:
("LJ65", PRG=4, reset=$C000, CHR=6)
("Concentration Room", PRG=4, reset=$8000, CHR=7)
("Lawn Mower", PRG=5, reset=$C000, CHR=8)
("Thwaite", PRG=4, reset=$8000, CHR=9)
I believe Mouser needs to be on this multicart to maintain the expected lack of quality.
B00daW wrote:
I believe Mouser needs to be on this multicart to maintain the expected lack of quality.
I do not think Mouser works on NES without redoing everything, Because NBASIC programs are totally incompatible with a real NES,
One of the reasons is the Init code for these programs are wrong. But there are other reasons like bad interpretation of BASIC code to NES.
If people want an updated Mouser, they can download the Super NeSnake 2 demo.
Nothing special to show yet, but I have come up with a few deliverables:
Now I can continue work on the menu program.
Nothing special to show yet, but I have come up with a few deliverables:
- LJ65+Concentration Room multicart on NROM-256 with CHR RAM
- Thwaite+Lawn Mower multicart on CNROM
- iNES file parser in Python (which caused conjectures on #nesdev that I was writing an NES emulator in Python)
- Tool to checksum CHR ROM banks in an iNES file, extract banks to PNG, and insert PNG to banks (download here)
- PB53, a mostly-RLE tile codec that I described in the last paragraph of this post, with Python compressor and decompressor and 6502 decompressor
- Parser for an INI-like configuration file language that allows multi-line values
- ROM builder and extractor appear working
Now I can continue work on the menu program.
Definitely interested in this project!
Welcome to the BBS, Tempy from #nesdev. And thank you for your support.
Anyway, I've got the menu program displaying the titles of pages and games inserted through the builder.
Tempy's first post's body text sounds like something certain automated posting processes would write in order to build reputation, but I recognize the nick. AGF for now plz.
Anyway, I've got the menu program displaying the titles of pages and games inserted through the builder.
Tempy's first post's body text sounds like something certain automated posting processes would write in order to build reputation, but I recognize the nick. AGF for now plz.
tepples wrote:
Welcome to the BBS, Tempy from #nesdev. And thank you for your support.
Anyway, I've got the menu program displaying the titles of pages and games inserted through the builder.
Tempy's first post's body text sounds like something certain automated posting processes would write in order to build reputation, but I recognize the nick. AGF for now plz.
Anyway, I've got the menu program displaying the titles of pages and games inserted through the builder.
Tempy's first post's body text sounds like something certain automated posting processes would write in order to build reputation, but I recognize the nick. AGF for now plz.
Oh, I registered a while ago to PM someone about multicarts. My first post wasn't that interesting I guess
Don't know much about NES programming yet; done 2 repros (Hyaku Monogatari, Recca), built a SNES USB controller with internal flash drive, started a Road Fighter hack which would fit better on the badderhacks forum than here.It's alive and kicking on my PowerPak. I can choose from 9 games and play all of them.
Both the ROM builder and ROM extractor appear to be working. I plan to release them very soon, but first I have to write a manual for the builder and work on my requirements checklist.
Is that font visible on a LCD tv? Just wondering if you tried it. This is a pretty cool project 
Would be nice to see it filled with 53 unique homebrews.
Would be nice to see it filled with 53 unique homebrews.I just tried it on both a Vizio LCD and a Magnavox CRT. (The TV depicted in the menu is a Sharp CRT.) But then my camera is a cheap piece of Chinese cr█p. Let's just say that the text is easier to read than the text in Mario Is Missing for Super NES.
Now you get to try it too:
EDIT (Sat 02-04): I've just realized something. Sometimes it's hard to MAKE YOUR SELECTION NOW! if the menu doesn't support the specialized controller that the game uses. For example, Thwaite with two mice or ZapPing with two Zappers. Should I put Zapper support and mouse support into the menu program so that someone can choose a game with the same controller used to play it?
EDIT (Sun 02-05): Mouse and Zapper are working in my source tree. I also got LAN Master to build in ca65 by writing a noddy Python script to translate NESASM syntax to ca65 syntax. I hope to shrink its CHR enough that I can stick it in a submulti with Munchie Attack.
EDIT (Mon 02-06): I've successfully stuffed both Munchie Attack and LAN Master's compressed CHR into LAN Master's PRG bank.
EDIT (Wed 02-08): I made a tool to combine any NROM-128 game at $8000 with an NROM-128 game at $C000. This let me turn Slappin' Bitches, FHBG, MineShaft, and Zap Ruder (ZapPing + Axe + Zapper Calibration) from four PRG banks into two. This effort also uncovered a couple bugs in my builder, which I fixed.
Now you get to try it too:
EDIT (Sat 02-04): I've just realized something. Sometimes it's hard to MAKE YOUR SELECTION NOW! if the menu doesn't support the specialized controller that the game uses. For example, Thwaite with two mice or ZapPing with two Zappers. Should I put Zapper support and mouse support into the menu program so that someone can choose a game with the same controller used to play it?
EDIT (Sun 02-05): Mouse and Zapper are working in my source tree. I also got LAN Master to build in ca65 by writing a noddy Python script to translate NESASM syntax to ca65 syntax. I hope to shrink its CHR enough that I can stick it in a submulti with Munchie Attack.
EDIT (Mon 02-06): I've successfully stuffed both Munchie Attack and LAN Master's compressed CHR into LAN Master's PRG bank.
EDIT (Wed 02-08): I made a tool to combine any NROM-128 game at $8000 with an NROM-128 game at $C000. This let me turn Slappin' Bitches, FHBG, MineShaft, and Zap Ruder (ZapPing + Axe + Zapper Calibration) from four PRG banks into two. This effort also uncovered a couple bugs in my builder, which I fixed.
I've released version 0.02 of the menu source and builder and updated the collection.
0.02 (2012-02-10)
I made a tool to translate just enough NESASM syntax into ca65 syntax to get LAN Master assembling in the ca65 environment. I used this to fit LAN Master's CHR and Munchie Attack into unused parts of LAN Master's PRG bank.
The tool to combine two NROM-128 games works by patching each game's reset to set or clear bit 7 of a memory location (e.g. $07FF) and patching the NMI handler to switch on this location, at the cost of about 10 CPU cycles of vblank time.
Any ideas for other NROM games to include or other things that'd be nice to have in the menu?
0.02 (2012-02-10)
- Menu: easier to see which tab is selected
- Menu: select an activity with Super NES Mouse in port 1
- Menu: select an activity with Zapper in port 2
- Menu: controller reading is DPCM-unsafe for mouse compatibility
- Menu is 7.5 KiB
- FFD: allocating end of slice no longer invalidates entire slice
- Reset patch: made the relocatable patch actually work
- Collection: added Munchie Attack to unused space in LAN Master
- Collection: moved FHBG into unused space in Slappin'
- Collection: moved MineShaft into unused space in Zap Ruder
- Collection is 11 games and 2 toys in 256 KiB
I made a tool to translate just enough NESASM syntax into ca65 syntax to get LAN Master assembling in the ca65 environment. I used this to fit LAN Master's CHR and Munchie Attack into unused parts of LAN Master's PRG bank.
The tool to combine two NROM-128 games works by patching each game's reset to set or clear bit 7 of a memory location (e.g. $07FF) and patching the NMI handler to switch on this location, at the cost of about 10 CPU cycles of vblank time.
Any ideas for other NROM games to include or other things that'd be nice to have in the menu?
@ tepples
I am working on a 32 in 1 for 128/128 TLROM by using two M27C322
The total size of two M27C322 is 8192KB so that It can hold
32 TLROM which are 128/128KB or
128 NROM-128 which are 16/8KB or
256 NROM-256 which are 32/8KB
Do you think you can expand the menu list to other pages by pushing select button?
I am working on a 32 in 1 for 128/128 TLROM by using two M27C322
The total size of two M27C322 is 8192KB so that It can hold
32 TLROM which are 128/128KB or
128 NROM-128 which are 16/8KB or
256 NROM-256 which are 32/8KB
Do you think you can expand the menu list to other pages by pushing select button?
A collection can have up to five pages, and each page can have up to 20 games. This covers your 32-in-1.
Ordinarily, you switch pages with left and right on the Control Pad, by shooting the tab bar with the Zapper, or by moving the mouse straight to the left or right. The current collection has four pages: games developed by myself and NovaYoshi, page 2 with games developed by Shiru, page 3 with games developed by others, and page 4 with things that aren't games. The pages are listed in the tab bar at the top of the screen. Did you want to add completely separate sets of pages? How many pages do you want to have? Or did you just want to add Select as an alias for right on the Control Pad?
Ordinarily, you switch pages with left and right on the Control Pad, by shooting the tab bar with the Zapper, or by moving the mouse straight to the left or right. The current collection has four pages: games developed by myself and NovaYoshi, page 2 with games developed by Shiru, page 3 with games developed by others, and page 4 with things that aren't games. The pages are listed in the tab bar at the top of the screen. Did you want to add completely separate sets of pages? How many pages do you want to have? Or did you just want to add Select as an alias for right on the Control Pad?
For now my goal is 32 in 1 and I want to have two pages with 16 games in each page.
If I can get it work, I am sure I can design the necessary hardware for 128/256 in 1 too. They also need some more pages.
What is the logic behind 20 games in a page? Isn't It possible to add more games to one page?
If I can get it work, I am sure I can design the necessary hardware for 128/256 in 1 too. They also need some more pages.
What is the logic behind 20 games in a page? Isn't It possible to add more games to one page?
FARID wrote:
What is the logic behind 20 games in a page?
The area for displaying titles of games is 128 pixels wide and 160 pixels tall, and the text display engine assumes 8 pixels per line.
In this post about an NES port of a spiritual sequel to an Action 52 game, thefox wrote:
not sure if I can fit the game in NROM though (not really interested in trying to optimize it for just that reason).
Then I need to figure out how to put games bigger than CNROM into a collection. My current idea is to take a bigger game designed for mapper 34 and then have the builder stick a table of relocated bank numbers at $FFE0-$FFEF of each bank to take into account where in the collection the game is loaded. Given the way bus conflict avoidance works in mappers like 2, 3, and 34, it might be crazy enough to work.
First off I wanted to let you know I tested this out on the NESDEV1 and it works great. I did have one funky thing that happened but not sure why. One time I started it up and the menu screen (not title though) was orange background vice black. I played LJ65 and everything was fine. I reset to play another game and everything looked normal with black background in the menu. Not sure if it was something funky that happened after I configured my CPLD for the first time or what but I couldn't recreate it. I assume it's a non-issue but I thought I'd bring it up.
By bigger than CNROM do you mean PRG, CHR or both? I don't quite follow what your idea is. Sounds like you're looking for PRG bankswitching of BNROM but CHR switching of CNROM at the same time? If you elaborate a little more I could help you come up with the hardware and test something on the NESDEV1 if you're interested.
tepples wrote:
Then I need to figure out how to put games bigger than CNROM into a collection. My current idea is to take a bigger game designed for mapper 34 and then have the builder stick a table of relocated bank numbers at $FFE0-$FFEF of each bank to take into account where in the collection the game is loaded. Given the way bus conflict avoidance works in mappers like 2, 3, and 34, it might be crazy enough to work.
By bigger than CNROM do you mean PRG, CHR or both? I don't quite follow what your idea is. Sounds like you're looking for PRG bankswitching of BNROM but CHR switching of CNROM at the same time? If you elaborate a little more I could help you come up with the hardware and test something on the NESDEV1 if you're interested.
The way it handles CNROM and the way I plan for it to handle BNROM are completely separate. Donkey Kong Classics is a well-known CNROM multicart. I've made a few CNROM multicarts specifically for this collection: MineShaft + Zap Ruder, Thwaite + Lawn Mower, and LJ65 + Concentration Room + Russian Roulette. These are added with one PRG bank and multiple CHR banks, and each game's entry in roms.cfg specifies which of the ROM's CHR banks to decompress into CHR RAM before the game starts running.
The solution I envision is for games that span multiple PRG banks. It would need zero special support from the mapper beyond existing support for oversize BNROM, unless we were to somehow add mirroring control to this mapper or move the PRG bank register down to $6000. A game would be made for mapper 34 and vertical mirroring, and it would switch PRG banks through a bank table like that seen in the listings here. The ROM builder would patch the bank table to change what PRG bank numbers get read and written.
In case the wiki page gets moved or something, here's the code:
The ROM builder might patch this to
And because the same byte gets read and written back, we relocate the program and avoid bus conflicts.
The solution I envision is for games that span multiple PRG banks. It would need zero special support from the mapper beyond existing support for oversize BNROM, unless we were to somehow add mirroring control to this mapper or move the PRG bank register down to $6000. A game would be made for mapper 34 and vertical mirroring, and it would switch PRG banks through a bank table like that seen in the listings here. The ROM builder would patch the bank table to change what PRG bank numbers get read and written.
In case the wiki page gets moved or something, here's the code:
Code:
.segment "BANKTABLE"
banktable:
; assuming a game as big as Deadly Towers
.byte $00, $01, $02, $03
.segment "ZEROPAGE"
current_bank: .res 1
.segment "RAMCODE"
bankswitch:
lda banktable, y ;read a byte from the banktable
sta banktable, y ;and write it back, switching banks
sty current_bank ;store the current bank in RAM
rts
banktable:
; assuming a game as big as Deadly Towers
.byte $00, $01, $02, $03
.segment "ZEROPAGE"
current_bank: .res 1
.segment "RAMCODE"
bankswitch:
lda banktable, y ;read a byte from the banktable
sta banktable, y ;and write it back, switching banks
sty current_bank ;store the current bank in RAM
rts
The ROM builder might patch this to
Code:
banktable:
.byte $07, $08, $09, $0A
.byte $07, $08, $09, $0A
And because the same byte gets read and written back, we relocate the program and avoid bus conflicts.
Well that sounds fine enough, you mentioning things being "crazy enough to work" I got the impression you were considering something more complex than that. So Really you're just making a BNROM within your 'big' BNROM master mapper.
So something like mapper 78 in the Holy diver flavor for mirroring? Is there something to be gained by moving to $6000 aside from preventing bus conflicts? If not it should be less hardware/logic to just pull PRG-ROM /CE high like ANROM does during writes.
Are options limited based on what Memblers designed up (and possibly already ordered?) If not it seems like it would be worth while to add the extra logic to allow the versatility. You could do the extended BNROM, selectable mirroring, and avoid bus conflicts with three chips. A single '377 octal FF and pair of '02 NAND gates. Selectable mirroring only needs 3-4 NAND gates depending if you want to use 1 or 2 of the FF's outputs, and the bus conflicts only requires an inverter and a NAND gate aka two NAND gates. If you really wanted to you could even do single screen mirroring by using 1 more (3 total) of the FF's outputs and (EDIT: two) of the the unused NAND gates for ANROM style mirroring.
That would still allow for 1MB of PRG with the 5 FF outputs left. Or 512KB PRG and get some CHR-RAM bankswitching action for no added cost assuming 16/32KB SRAM is cheaper than 8KB which it usually is.
Quote:
unless we were to somehow add mirroring control to this mapper or move the PRG bank register down to $6000.
So something like mapper 78 in the Holy diver flavor for mirroring? Is there something to be gained by moving to $6000 aside from preventing bus conflicts? If not it should be less hardware/logic to just pull PRG-ROM /CE high like ANROM does during writes.
Are options limited based on what Memblers designed up (and possibly already ordered?) If not it seems like it would be worth while to add the extra logic to allow the versatility. You could do the extended BNROM, selectable mirroring, and avoid bus conflicts with three chips. A single '377 octal FF and pair of '02 NAND gates. Selectable mirroring only needs 3-4 NAND gates depending if you want to use 1 or 2 of the FF's outputs, and the bus conflicts only requires an inverter and a NAND gate aka two NAND gates. If you really wanted to you could even do single screen mirroring by using 1 more (3 total) of the FF's outputs and (EDIT: two) of the the unused NAND gates for ANROM style mirroring.
That would still allow for 1MB of PRG with the 5 FF outputs left. Or 512KB PRG and get some CHR-RAM bankswitching action for no added cost assuming 16/32KB SRAM is cheaper than 8KB which it usually is.
infiniteneslives wrote:
Is there something to be gained by moving to $6000 aside from preventing bus conflicts?
I already have plenty of infrastructure in the menu program to work around bus conflicts. It's just that Memblers mentioned something about distinguishing writes to the mapper from writes to the flash memory so that a surface-mounted memory can be soldered first and programmed later once it's on the board.
I like that solution to that issue. Much better than a doing a mapper defeat with EXP0. It also comes with the added benefit of being able to store save data on the cartridge if desired.
Instead of 2 NANDs to prevent bus conflicts like I was discussing above, you need something to NAND 4 signals. Best way to do that is probably something like a 4068 (8 I/P NAND).
Then you could add in the single '02 if mapper selectable mirroring was desired.
Anyways, I'm sure it all works as you've got it planned, but my offer is still there if you'd like to test something. I've got flash onboard as well if you want to test any functionality there.
I guess the downside of all of this is there isn't any emulator support for this mapper currently. But that could also be considered a good thing I guess, the games are all available individually if people want to play on an emu. It may provide a little more incentive to buy the carts.
Instead of 2 NANDs to prevent bus conflicts like I was discussing above, you need something to NAND 4 signals. Best way to do that is probably something like a 4068 (8 I/P NAND).
Then you could add in the single '02 if mapper selectable mirroring was desired.
Anyways, I'm sure it all works as you've got it planned, but my offer is still there if you'd like to test something. I've got flash onboard as well if you want to test any functionality there.
I guess the downside of all of this is there isn't any emulator support for this mapper currently. But that could also be considered a good thing I guess, the games are all available individually if people want to play on an emu. It may provide a little more incentive to buy the carts.
I doubt that all games using mappers with bus conflicts read the value from ROM before writing it back... Sometimes when I want to switch quickly to a constant bank I just write the bank number over the operand of the instruction that loaded the value. These would have to be hacked individually.
Even when I use a bankswitch table, I usually prefer saving 2 cycles by just transferring the bank index from one register to the other rather than loading the value from ROM.
Even when I use a bankswitch table, I usually prefer saving 2 cycles by just transferring the bank index from one register to the other rather than loading the value from ROM.
Tepples,
In a few hours I will be setting up the homebrew exhibit at the MGC. I need the ROM image for Action 53. Please email it to me when you get a chance.
In a few hours I will be setting up the homebrew exhibit at the MGC. I need the ROM image for Action 53. Please email it to me when you get a chance.
tokumaru wrote:
I doubt that all games using mappers with bus conflicts read the value from ROM before writing it back
Then it'd just be a requirement for porting games to Action 53, just as vertical mirroring is a requirement.
clueless: These ROMs use a pre-0.03 menu engine and have the requested censorship applied to their config files (gambling game omitted from menu, Slappin' renamed).
- 4 Mbit version (includes Pogo Cats and NES15)
- 2 Mbit version (omits those games)
tepples wrote:
- 4 Mbit version (includes Pogo Cats and NES15)
- 2 Mbit version (omits those games)
Bad news. Neither of those ROMs will play on my powerpak. My other ROMs load fine. When I tell the powerpak to load either of the action53 roms, the screen clears to black, but the game never boots up; the NES locks up.
You have an old version of mapper 34. The old version supports only 128 KiB, as I mentioned before; the new version supports all 512 KiB.
Do I need to put detection for this situation into the menu software?
Do I need to put detection for this situation into the menu software?
tepples wrote:
You have an old version of mapper 34. The old version supports only 128 KiB, as I mentioned before; the new version supports all 512 KiB.
Loopy's mappers solved my problem. Thank you.
tepples wrote:
Do I need to put detection for this situation into the menu software?
Actually, detecting the problem and giving the user an error message would be useful. Can you detect that you are on a powerpak with older mappers from inside the NES?
clueless wrote:
Can you detect that you are on a powerpak with older mappers from inside the NES?
It's easy to detect when upper banks aren't accessible. I wouldn't go through the trouble of doing this though. If you own a PowerPak, it's common sense to blame the mapper when a game doesn't run, so the first thing you should do is look for the most updated version.
tokumaru wrote:
It's easy to detect when upper banks aren't accessible.
Yeah, BNTest from the previous discussion was my method of proving out this limitation.
tokumaru wrote:
I wouldn't go through the trouble of doing this though.
Especially because doing so would require putting part of the menu (the part that detects whether the last bank is reachable) in bank 0, 1, 2, or 3, space that could be used for another game in a pinch.
I guess you COULD put the mapper validation code with the menu in one of the lower banks (the part that tries to access upper banks would run from RAM), so that no more space would be needed in other banks, but I still think it's not worth the trouble.
Action 53 0.03 is out
0.03 (2012-06-21)
Collection | Menu source code
0.03 (2012-06-21)
- FFD: pads to power of 2 banks early instead of adding banks on demand during CHR and screenshot insertion
- Can insert CHR and screenshot data into the last bank if needed
- New values for number of players: 2-4 alt and 2-6 alt
- "Make your selection now!"
- Collection: properly clear top score in Munchie Attack
- Collection: added NES15 and Pogo Cats
- Collection: removed LJ65 due to scenes a faire failure
- Collection is 12 games and 2 toys in 512 KiB
Collection | Menu source code
I like the whoo-yeah intro music.
rainwarrior wrote:
I like the whoo-yeah intro music.
It takes tepples to make a ROM go write..
I'm backing up the source code for the version of the menu used in Double Action 53: Volume 2.
0.04 (2014-11-06)
0.04 (2014-11-06)
- Menu: Fixed certain combinations of tab lengths causing blank block in 11th line of tab display
- Menu: Bank arrow sprite positioned correctly even if tab width differs from first tab's width
- Menu: Fixed uncleared line caused by rapidly switching from a long to medium to short page
- Menu: Performs a write sequence to fully initialize mapper 28 without losing support for mapper 34
- Menu: Can customize the title screen using a .png file and a palette specified in the makefile
- a53build: startbank= option to leave several 32K banks blank at the start of the ROM, for adding mapper 28 UNROM games
- a53build: blank banks inserted as power-of-two padding are no longer mistakenly included in the ROM directory
- innie: Supports [section title] syntax
- a53extract: support ROMs created with startbank=
- Collection: moved NES15 into unused space in Concentration Room
- Collection: added Russian Roulette to unused space in Concentration Room
- Collection: abandoned author-based groups
- Collection is 12 games and 3 toys in 256 KiB
Again (ab)using the forum as backup, this time for my progress toward volume 3.
- Menu: Update music engine from Pently 3 to Pently current
- Menu: Update VWF engine to unrolled shift version
- Menu: Update source code file naming conventions
- Menu: Remove antialiasing from start button notice
- tools/*: Convert to Python 3
- makefile: Work around quirks in Python for Windows
- a53build: Specify unused ranges for multiple PRG banks in one activity
- a53build: ROMs using Action 53 mapper (28) boot as if they're UNROM (2)
- a53build: If prgbank not given, guesses last ROM bank for UNROM (2) and Action 53 or first for others
- a53build: Refactored title validation and ROM patching into separate subroutine
- a53build: Sorts ROMs by descending PRG size before inserting them, fixing arbitrary mixes of C?NROM and [ABU]NROM
- autosubmulti: Doesn't limit input or output to one directory
More progress (call this 0.05 alpha 2):
- Menu: Include title screen in data part of last bank (near ROM directory) instead of menu executable
- a53build: Set filename and palette of title screen with config file keywords titlescreen= and titlepalette=
- a53build: Handles grayscale mode screenshots and indexed screenshots with black not first
- a53build: Correctly exit-patches larger ROMs (breaks a53extract though)
Hey, is that bit-banged 7-bit PCM playback?
I was kind of hoping the "Make your selection now" speech would be rhythmically integrated and transition back to the music, though.
I was kind of hoping the "Make your selection now" speech would be rhythmically integrated and transition back to the music, though.
More changes to the menu in preparation for volume 3
- Menu: Integrate JRoatch's coredump tool
- Menu: Up at title screen no longer corrupts the background; it was a debugging tool anyway (reported by Greg Caldwell)
- exitpatch: Exit patches do not set stack pointer, so that coredump (A+B+Reset) can see the stack pointer
- exitpatch: Fixed marking exitmethod=none banks as already patched
- a53build: 32K mappers (BNROM, AOROM) default to last PRG bank instead of first, working around an exit patch problem
- a53build: Load ROMs on a blank-named page but don't list them as titles, to allow including unreachable TCRF-bait content (requested by [redacted])
- Added tools/prgunused.py to find runs of 32 or more bytes of value $00 or $FF in the PRG ROM of an iNES image
None of these work for me. wip1 hard-crashes after pressing start at the title screen, wip2 and wip3 don't even render the title screen, they just show solid grey. Running fceux 2.2.3 and Nestopia 1.4.1. Do I need a specific build?
Are you trying to run a53menu.nes by itself, without using a53build.py to add games? Do I need to add code to the menu to detect that no games have been added?
tepples wrote:
Are you trying to run a53menu.nes by itself, without using a53build.py to add games? Do I need to add code to the menu to detect that no games have been added?
I think the simplest way to keep people from running a53menu.nes and being disappointed is to rename it to a53menu.bin so we don't mistake it for something that we could run.
I, like dustmop, had made this same mistaken assumption but didn't mention it. Of course I could have read 10 pages of README.txt to discover that it's not supposed to work as-is, but I'd already assumed it was some other problem long before then.
Agree with rainwarrior here. I think POLA applies. Either the ROM shouldn't be runnable (.bin extension works), or it should fail fast, with a more obvious indication that things are broken.
Turns out README.txt already mentioned that problem:
But the fact that this wasn't very discoverable is itself a bug. So I want to make several layers of fixes:
Q. Why does a53menu.nes just hang?
This file contains the code for the menu. It contains no activities
and thus will not work unless activities are added using a53build.py.
But the fact that this wasn't very discoverable is itself a bug. So I want to make several layers of fixes:
- Build a53menu.prg without a header instead of a53menu.nes with a header: Done in my tree
- Display an error message if the key block is still FF-filled: Done in my tree
- Describe the expanded capabilities of Action 53 when running with mapper 28: Begun in my tree; detailed documentation will have to wait until step 4 is done
- Reorganize the documentation to make it less tl;dr: I'll need help with finding a good approach.
I initially had trouble compiling Action 53 because I didn't see where the config file was in the makefile, but then I found it in the tools directory. While editing the config, I had thought you had placed all the stuff outside the a53menu directory because of all the ../. I eventually figure out that the working directory for that script seems to be the tools directory instead of where the makefile was.
JRoatch wrote:
While editing the config, I had thought you had placed all the stuff outside the a53menu directory because of all the ../. I eventually figure out that the working directory for that script seems to be the tools directory instead of where the makefile was.
I have changed the builder to drop the implicit rule "paths are relative to the working directory, and the working directory happens to be tools". Instead, paths in a config file will have the same semantics as paths in C #include, ca65 2.14+ .include, and HTML href and src attributes: paths are relative to the directory containing the config. I did this for two reasons: to make volume 3's workaround for the PowerPak's PRG size limit easier to automate in the makefile, and to make the rule easier to explain in the docs to avoid confusion like yours.
This release adds polish. (Not to be confused with adding a translation to język polski.)
Executive summary:
Detailed changes:
Executive summary:
- The menu with no games added is less astonishing, using POLAK (Principle Of Least Astonishment Key) principles.
- make dist builds both the .zip of the menu and the .7z of volume 3, both full and PowerPak subsets
Detailed changes:
- Menu: Don't include iNES header in menu-only binary to discourage accidental execution (requested by rainwarrior and dustmop)
- Menu: Display error if key block is missing a screenshot (requested by dustmop)
- autosubmulti: Map from mirroring to map mode bit 0 was backward (reported by RogerBidon)
- a53build: Prints exception message for each ROM that failed to load (requested by JRoatch)
- a53build: Paths are explicitly relative to config file's directory (requested by JRoatch)
- a53build: Config file can change path of menu binary
- a53build: Screenshot converter shares NES palette with savtool
- a53build: Filename of config file no longer hardcoded
- makefile: make dist builds and packages both the menu source and one or more collections
- Workaround for Info-ZIP Zip's nonzero exit status when no changes are needed (per Stack Overflow)
- Docs: Mention new features related to Action 53 mapper
In this post, tokumaru wrote:
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.
This refers to the 64x56 pixel thumbnails that represent each game in the menu.
In a reply, tepples wrote:
Improving the appearance of the menu is something I'm willing to discuss for volume 4.
Now that volume 3 is final, that time is now.
The first improvement I can think of is expanding each screenshot to ten colors: gray ramp as background plus a sprite overlay to provide non-gray colors. Each 8x8 pixel area of the screenshot would use one of two 7-color palettes:
- Black, dark gray, light gray, white, A, B, C
- Black, dark gray, light gray, white, D, E, F
With this change, I expect screenshot sizes before compression to increase from 64*56*2/8+3 = 899 bytes to 64*56*3/8+8*7/8+6=1357 bytes. Compressed sizes may vary with the planned switch from PB53 to Bagel.
Sorry if I missed it earlier, but why can't the screenshots be allowed to pick any of the four sprite palettes per 8x8 region, in addition to the greyscale ramp behind the sprites? Other than the arrow, what are the other sprites up to?
I had planned on limiting sprite palettes per screenshot to two in order to leave room for future expansion should I revamp the menu to add sprites in other places.
How to write a config file entry for an activity
These fields define an activity's appearance in the menu:
Entries to a competition MUST give title, author, year, and description. The font is variable-width, and with most glyphs in lowercase text being 3 to 5 pixels wide, it allows about 28 characters per 128-pixel line.
Screenshots and patching information can be provided later, as I imagine that some games will get substantial graphical overhauls before release. Rock Paper Scissors... from the third compo did, and I expect Wolfling Zero from the fourth to as well. So here's what the full config for Twin Dragons looks like:
Most of the new fields are quite technical:
These fields define an activity's appearance in the menu:
Code:
title=Twin Dragons
author=Antoine GOHIN
year=2016
description:
Cater Killar has kidnapped
your twin. Choose Dinky
or Minky and go find your
twin, crushing the various
dangers in different worlds.
+ Move
A: Jump
Down+A: Jump down
B: Shoot
Up+B: Shoot with powerup
.
author=Antoine GOHIN
year=2016
description:
Cater Killar has kidnapped
your twin. Choose Dinky
or Minky and go find your
twin, crushing the various
dangers in different worlds.
+ Move
A: Jump
Down+A: Jump down
B: Shoot
Up+B: Shoot with powerup
.
Entries to a competition MUST give title, author, year, and description. The font is variable-width, and with most glyphs in lowercase text being 3 to 5 pixels wide, it allows about 28 characters per 128-pixel line.
- title=
The game's title as it shall appear in the menu. (1 line) - author=
The name of the game's author or publisher, as it would appear in a copyright notice. (3/4 of a line) - year=
Year in which this version was first published. (4 digits, 1970 to 2099) - players=
Number of players for the game. If not specified, the menu builder uses 1. Valid values are as follows; if your game does not match these, I can add one. The "alt" means "alternating".
1, 1-2, 1-2 alt, 1-3, 1-4, 2, 2-4, 2-4 alt, 2-6 alt - description:
Up to 16 lines of text. It should describe the game's premise, the control scheme on the standard controller, any other specialized controllers (such as the Zapper or Power Pad) that this activity uses, and (if you have room) some game tips.
The colon instead of equal sign after description means that a multi-line value follows, where a . (period) on its own line terminates the value. (The convention used is the same as that of SMTP.)
Screenshots and patching information can be provided later, as I imagine that some games will get substantial graphical overhauls before release. Rock Paper Scissors... from the third compo did, and I expect Wolfling Zero from the fourth to as well. So here's what the full config for Twin Dragons looks like:
Code:
page=NESdev Compo
title=Twin Dragons
author=Antoine GOHIN
year=2016
screenshot=../tilesets/screenshots/Twin-Dragons-20170131-0.png
rom=../Category 1/Twin Dragons/Twin-Dragons-20170131-0.074.nes
; this patch disables setting the outer bank
patch1=C021=AD
prgbank=1
prgunused0=FE00-FFF9
prgunused1=FF60-FFF9
description:
Cater Killar has kidnapped
your twin. Choose Dinky
or Minky and go find your
twin, crushing the various
dangers in different worlds.
+ Move
A: Jump
Down+A: Jump down
B: Shoot
Up+B: Shoot with powerup
.
title=Twin Dragons
author=Antoine GOHIN
year=2016
screenshot=../tilesets/screenshots/Twin-Dragons-20170131-0.png
rom=../Category 1/Twin Dragons/Twin-Dragons-20170131-0.074.nes
; this patch disables setting the outer bank
patch1=C021=AD
prgbank=1
prgunused0=FE00-FFF9
prgunused1=FF60-FFF9
description:
Cater Killar has kidnapped
your twin. Choose Dinky
or Minky and go find your
twin, crushing the various
dangers in different worlds.
+ Move
A: Jump
Down+A: Jump down
B: Shoot
Up+B: Shoot with powerup
.
Most of the new fields are quite technical:
- page=
Each activity appears on a page, whose name is displayed in a tab at the top of the menu screen. This is the only field that comes before the title. - screenshot=
Relative path to a 64x56-pixel PNG image with black and three other colors, representing the reduced by a factor of four in each direction. The color capability may be expanded if I get time. - rom=
Relative path to the ROM file. Activities using the same ROM file may have different entry points. - prgunused0=, prgunused1=
Comma-separated list of address ranges in each 32K bank of ROM on whose data the program does not depend. These are hexadecimal and inclusive; FFF0-FFF9 means ten bytes. - patch1=
Entries using the Action 53 mapper directly for runtime changes to nametable mirroring will need the write to register $81 (outer bank number) edited out of its init code. It's traditional to change a STA $8000 to a BIT $8000. I have also used this to fix NROM and CNROM games that inadvertently overwrite the CHR data that the menu loads into CHR RAM. - entrypoint=, chrbank=, prgbank=, and mapmode=
These are most often used when multiple NROM-128 entries are packed into one 32K PRG ROM bank. But if you have a separate activity within your ROM that you want to make accessible from the title screen, specify it as a separate activity with the same rom= and a different entrypoint=. - exitmethod=, exitpoint=
By default, the ROM builder patches the reset vector and an unused area of each ROM to return to the menu when Reset is pressed. Add exitmethod=none if your ROM wants to trap the Reset button for itself, with a menu option to switch in the last bank and JMP ($FFFC), or add exitpoint=FFF0 if your ROM already has the approved exit code at that address. If no exit method is specified, the entry MUST have enough prgunused to fit the exit code.
M_Tee wrote:
tepples wrote:
This release adds polish. (Not to be confused with adding a translation to język polski.)
The game we plan to submit has a ż (lowercase z with a dot over it) in the title and our author name has an Ł in it (capital L with a slash through it).
Oops, ya got me.
I'll see what I can do for Unicode support. Would it be acceptable to support only "simple" characters, those that can be drawn left to right without having to contextual choices or align two horizontally overlapping glyphs relative to each other, such as precomposed characters in Latin and emoji?
If that's fine, we need to design glyphs. ł (lowercase l with slash) appears visually distinct from t. Are these glyphs for Łł Tt Żż OK?
Attachment:
litecoin_t_polishkriskross.png [ 237 Bytes | Viewed 6634 times ]
In case there is space issues prohibiting the use of ż and Ł,
these letters have the lowest relative frequency in english (although game titles may not reflect typical use):
Chances are some of them won't be used.
Reserving two sprites and a palette to be identical is another makeshift option. Making the . character centered so it can be placed above z is another.
As for designing glyphs, the diagonal bar of Ł / ł should start lower than that of t. Preserving the dot over upper case Ż is also important (though it won't be used in this specific situation).
these letters have the lowest relative frequency in english (although game titles may not reflect typical use):
Code:
z 0.074%
q 0.095%
x 0.150%
j 0.153%
k 0.772%
v 0.978%
b 1.492%
q 0.095%
x 0.150%
j 0.153%
k 0.772%
v 0.978%
b 1.492%
Chances are some of them won't be used.
Reserving two sprites and a palette to be identical is another makeshift option. Making the . character centered so it can be placed above z is another.
As for designing glyphs, the diagonal bar of Ł / ł should start lower than that of t. Preserving the dot over upper case Ż is also important (though it won't be used in this specific situation).
The article you linked states that barred Z is acceptable for uppercase, which is important with as little leading as I have to work with. I'll move the slash on the L down a pixel.
There are other ASCII characters more likely to be unused than Latin letters, such as the backslash. But the same font is also used for game descriptions. So I do plan on expanding it as needed.
But while I'm adding support for UTF-8 titles in the builder, I might as well put in other improvements (Zapper responsiveness and screenshot color depth). Screenshots in particular would require 56 tiles of background space, and I don't have that in the first pattern table of the current VRAM layout. I'm also already using sprite 0 to time Zapper reading.
$0000-$019F Borders (26 tiles)
$01A0-$047F Unused (46 tiles)
$0480-$045F Tab titles (24 tiles)
$0600-$0FFF Text area (160 tiles; 320 with palette hackery)
$1000-$137F Screenshot (56 tiles)
$1380-$139F Tab arrow (2 tiles)
$13A0-$13FF Unused (198 tiles)
So I'd have to move the tab strip to the second pattern table, producing a map more like this:
$0000-$015F Borders excluding top (22 tiles)
$0160-$027F Unused (18 tiles)
$0280-$05FF Screenshot gray plane (56 tiles)
$0600-$0FFF Text area (160 tiles)
$1000-$17FF Top borders (8 tiles)
$1080-$11FF Tab titles (24 tiles)
$1200-$157F Screenshot colored plane (56 tiles)
$1580-$1FFF Unused (168 tiles)
This produces a new burn-down list:
There are other ASCII characters more likely to be unused than Latin letters, such as the backslash. But the same font is also used for game descriptions. So I do plan on expanding it as needed.
But while I'm adding support for UTF-8 titles in the builder, I might as well put in other improvements (Zapper responsiveness and screenshot color depth). Screenshots in particular would require 56 tiles of background space, and I don't have that in the first pattern table of the current VRAM layout. I'm also already using sprite 0 to time Zapper reading.
$0000-$019F Borders (26 tiles)
$01A0-$047F Unused (46 tiles)
$0480-$045F Tab titles (24 tiles)
$0600-$0FFF Text area (160 tiles; 320 with palette hackery)
$1000-$137F Screenshot (56 tiles)
$1380-$139F Tab arrow (2 tiles)
$13A0-$13FF Unused (198 tiles)
So I'd have to move the tab strip to the second pattern table, producing a map more like this:
$0000-$015F Borders excluding top (22 tiles)
$0160-$027F Unused (18 tiles)
$0280-$05FF Screenshot gray plane (56 tiles)
$0600-$0FFF Text area (160 tiles)
$1000-$17FF Top borders (8 tiles)
$1080-$11FF Tab titles (24 tiles)
$1200-$157F Screenshot colored plane (56 tiles)
$1580-$1FFF Unused (168 tiles)
This produces a new burn-down list:
Move controller detection before title screen, relying on Reset press rather than hot pluggingIf Zapper is connected, poll Zapper during 25% of frames even if display is updatingIf Zapper is connected, shooting offscreen should change pagesSplit Zapper polling loop into two: one for top 24 pixels and one for rest of screenRescale returned Zapper coordinates on PAL NESSplit border graphics into two filesMove top border and tab titles to second pattern table- Make a converter for 10-color screenshots
- Display 10-color screenshots
- Extend VWF routine glyph address calculation from 128 to 224 glyphs
Associate codepoints for additional glyphsAdd capital L with stroke, small z with dot, and arrows
Quote:
The article you linked states that barred Z is acceptable for uppercase
I recognize the problem with diacritics above capital letters. But at the same time, the statement referred to in the quote above would assume the bar is legible via fine detailing of the die, vector file or high resolution raster. At a low resolution like this, it is hard or sometimes impossible to make it come across as a barred Z, let alone the pretty much standardized Ż. Even though i'm only half-polish from an expat parent, i dare say it is uncommon to see a barred z in polish print, historic or recent.
The usual ASCII text mode solution to capital letters + diactrics is lowering the height to make room for the diacritic, but still have it higher than the lower case ones. Going outside standard ascii, special symbols for diactrics on the row above looks a bit better whenever it is viable and can cover the needs of several languanges in less space.
Thank you both. Ten color screenshots sound sweet too.
I'm about halfway down the list. What custom characters do you see already?
Love the arrows and buttons. Should they also have colons after them?
I had been using a colon only after a letter, not a symbol. You see this in the first three volumes, where + is a symbol for "Control Pad".
So anyway, I managed to get layered screenshots implemented in the builder and menu. Later, I plan to post a Python demo program so people can practice drawing layered screenshots.
So anyway, I managed to get layered screenshots implemented in the builder and menu. Later, I plan to post a Python demo program so people can practice drawing layered screenshots.
Looks great.
The screenshots look great this way. Looks quite good in the example picture.
As with most of my other projects, you'll need to have Python 3 and Pillow (Python Imaging Library) installed, per the standard instructions to set up a build environment for Pin Eight projects.
The input image must be 64x56 pixels, in BMP, PNG, or any other format that Pillow reads. It must follow the engine's limits (grays + 3 colors in each 8x8 pixel area, two distinct groups of 3 colors).
The main() function in a53screenshot.py is hardcoded for testing purposes so that I can test from within IDLE, the editor that comes with Python. You'll need to comment that at the bottom of the file and uncomment plain main().
EDIT: Fixed documentation
The input image must be 64x56 pixels, in BMP, PNG, or any other format that Pillow reads. It must follow the engine's limits (grays + 3 colors in each 8x8 pixel area, two distinct groups of 3 colors).
The main() function in a53screenshot.py is hardcoded for testing purposes so that I can test from within IDLE, the editor that comes with Python. You'll need to comment that at the bottom of the file and uncomment plain main().
Code:
# Convert by guessing the 3-color palettes, then display
./a53screenshot.py thwaite.png
# Convert by guessing the 3-color palettes, then save conversion
./a53screenshot.py thwaite.png -o thwaite-indexed.png
# Convert using the given palettes, then display
./a53screenshot.py --palette 12162A122738 thwaite.png
# Convert using the given palettes, then save conversion
./a53screenshot.py --palette 12162A122738 thwaite.png -o thwaite-indexed.png
# Save a PNG image showing the NES palette that savtool uses
./savtool.py --write-swatches=bisqwit_nes_palette.png
REM Windows Command Prompt may require backslashes or removal of the
REM leading ./ entirely. I haven't tested this on Windows. Let me
REM know which of these work for you.
.\a53screenshot.py thwaite.png
a53screenshot.py thwaite.png
py a53screenshot.py thwaite.png
python a53screenshot.py thwaite.png
./a53screenshot.py thwaite.png
# Convert by guessing the 3-color palettes, then save conversion
./a53screenshot.py thwaite.png -o thwaite-indexed.png
# Convert using the given palettes, then display
./a53screenshot.py --palette 12162A122738 thwaite.png
# Convert using the given palettes, then save conversion
./a53screenshot.py --palette 12162A122738 thwaite.png -o thwaite-indexed.png
# Save a PNG image showing the NES palette that savtool uses
./savtool.py --write-swatches=bisqwit_nes_palette.png
REM Windows Command Prompt may require backslashes or removal of the
REM leading ./ entirely. I haven't tested this on Windows. Let me
REM know which of these work for you.
.\a53screenshot.py thwaite.png
a53screenshot.py thwaite.png
py a53screenshot.py thwaite.png
python a53screenshot.py thwaite.png
EDIT: Fixed documentation
Now that screenshots can be more colorful, wouldn't this be a good time to improve the graphics of the television set itself? Maybe something like this:
a53-television.png [ 2.33 KiB | Viewed 6869 times ]
Attachment:
a53-television.png [ 2.33 KiB | Viewed 6869 times ]
Code:
./a53screenshot.py inherent.png
Traceback (most recent call last):
File "./a53screenshot.py", line 385, in <module>
main(["a53screenshot.py", "-v", "../tilesets/screenshots/thwaite.png"])
File "./a53screenshot.py", line 360, in main
im = Image.open(infilename)
File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2258, in open
fp = builtins.open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: '../tilesets/screenshots/thwaite.png'
Traceback (most recent call last):
File "./a53screenshot.py", line 385, in <module>
main(["a53screenshot.py", "-v", "../tilesets/screenshots/thwaite.png"])
File "./a53screenshot.py", line 360, in main
im = Image.open(infilename)
File "/usr/lib/python3/dist-packages/PIL/Image.py", line 2258, in open
fp = builtins.open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: '../tilesets/screenshots/thwaite.png'
Hardcoded inputs overriding what I passed?
edit: When I comment the hardcode line and uncomment the main() line, it goes further, but the inputs do not match your README, they expect -o instead of two filenames.
edit2: The new image did not use the new palettes for some reason, even though the run was successful:
Code:
./a53screenshot.py inherent.png -o new.png
palette: 03 17 27, 08 17 27
palette: 03 17 27, 08 17 27
And the preview did not change any colors either.
calima wrote:
Hardcoded inputs overriding what I passed?
Yup. Sometimes I hardcode argv so that I can test from within an environment that doesn't offer a way to specify argv. You caught me with the -o there as well: I changed the API and forgot to change the manual. Thank you for helping to test.
calima wrote:
The new image did not use the new palettes for some reason, even though the run was successful:
Code:
./a53screenshot.py inherent.png -o new.png
palette: 03 17 27, 08 17 27
palette: 03 17 27, 08 17 27
Try changing parse_palette(s) to parse_palette(args.palette). If that doesn't work, could you attach inherent.png for me to test with?
Code:
File "./a53screenshot.py", line 173
def parse_palette(args.palette):
^
SyntaxError: invalid syntax
def parse_palette(args.palette):
^
SyntaxError: invalid syntax
Image attached. Please use this one as Inherent's screenshot, it should pass all restrictions (though the colors the tool picked may be bad, there's no purple 03 anywhere, and 18/28 may be closer to the yellows than 17 and 27)
My camera sucks, as do the room lighting and the TV's color temperature settings. But this photo at least shows more colorful screenshots on hardware.
@calima
I meant in the function's use, not its definition.
But anyway, I found a bunch of other dumb typos, and I have attached a revised version with them fixed. Thank you for the test materials.
As for the purple, the conversion uses a palette generated using Bisqwit's tool. In the revised version of a53screenshot, I've added functionality to savtool.py --write-swatches where .pal writes a 192-byte binary palette for use with an emulator, and .txt writes a 64-line tab-separated file with 6-digit hex codes (e.g. #342800 for color $08).
@tokumaru
That'd certainly be doable with my current framework.
The screenshot frame in the current version of Action 53 was based on a TV belonging to NovaSquirrel, made by Sharp. That was the TV that I had in front of me while making the menu software. Pictures of model 19C140 found through Google Images appear to match it.
I could have modeled it after a more iconic bezel if I knew of one. What TV model is tokumaru's suggested frame based on?
Attachment:
File comment: A familiar game with houses and explosions using different palettes
thwaite_19C140.jpg [ 47.56 KiB | Viewed 6775 times ]
thwaite_19C140.jpg [ 47.56 KiB | Viewed 6775 times ]
@calima
I meant in the function's use, not its definition.
But anyway, I found a bunch of other dumb typos, and I have attached a revised version with them fixed. Thank you for the test materials.
Attachment:
File comment: A bunch of fixes to the command-line front end
a53screenshot.zip [22.08 KiB]
Downloaded 258 times
a53screenshot.zip [22.08 KiB]
Downloaded 258 times
Attachment:
File comment: You mean this isn't about long-eared leporids?
inherent_19C140.jpg [ 47.51 KiB | Viewed 6775 times ]
inherent_19C140.jpg [ 47.51 KiB | Viewed 6775 times ]
As for the purple, the conversion uses a palette generated using Bisqwit's tool. In the revised version of a53screenshot, I've added functionality to savtool.py --write-swatches where .pal writes a 192-byte binary palette for use with an emulator, and .txt writes a 64-line tab-separated file with 6-digit hex codes (e.g. #342800 for color $08).
@tokumaru
That'd certainly be doable with my current framework.
The screenshot frame in the current version of Action 53 was based on a TV belonging to NovaSquirrel, made by Sharp. That was the TV that I had in front of me while making the menu software. Pictures of model 19C140 found through Google Images appear to match it.
Attachment:
File comment: Yo dawg, I put a Sharp TV in your Sharp TV so you can game while you game
droste_19C140.jpg [ 52.04 KiB | Viewed 6775 times ]
droste_19C140.jpg [ 52.04 KiB | Viewed 6775 times ]
I could have modeled it after a more iconic bezel if I knew of one. What TV model is tokumaru's suggested frame based on?
tepples wrote:
I could have modeled it after a more iconic bezel if I knew of one. What TV model is tokumaru's suggested frame based on?
I took bits and pieces from different TVs, but the biggest inspiration was this one (apparently a Sony Trinitron KV-20TR23):
Attachment:
sony-trinitron.jpg [ 82.1 KiB | Viewed 6763 times ]
I don't think this is about using an iconic model though, I just think it has to be believable. The current one looks a bit too boxy, and the light color blends with the background too much (the Windows 95 style shading doesn't help here). I figured that a dark/black television would stand out more, and would have better contrast overall.
If you provide a reference image of any other model you think would work better, I can take a shot at pixeling it.
Looking good, and you're credited in CHANGES.txt of the menu source code.
Cool! I'm glad you liked it.
The old bezel looked fine, but the new one has some nice character to it.
yeah well done tokumaru!
In the volume 3 topic, infiniteneslives wrote:
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 added a new feature to the builder to let me reserve space in the ROM for notices on the title screen, specifying their position and color. Previously they had been hardcoded in the RODATA of the menu program. The new arrangement should let me build multiple collections from the same menu program even if they have different title screen layouts, particularly volumes 3 and 4.
Now that you've added button icons, how would you feel about one for the d-pad as well?
I've uploaded the ROM builder's source code to Microsoft GitHub so that JRoatch can make pull requests in the course of building the master ROM.
pinobatch/action53
Could the design of these overlapping tab tiles be improved? (top: current; bottom: proposed)
pinobatch/action53
Could the design of these overlapping tab tiles be improved? (top: current; bottom: proposed)
I'll get myself set up to commit changes to that github repository right away.
Overlapping tabs would be a welcomed improvement as I am considering a possibility of organizing in 5 tabs.
The only improvement for readability I can think of at the moment is darkening the unselected tabs (attachment is a super quick mock-up), but that would further stress the tile bandwidth for updating the screen. A TODO thing for myself at some time.
a53_overlapping_tabs_darken.png [ 461 Bytes | Viewed 2755 times ]
Overlapping tabs would be a welcomed improvement as I am considering a possibility of organizing in 5 tabs.
The only improvement for readability I can think of at the moment is darkening the unselected tabs (attachment is a super quick mock-up), but that would further stress the tile bandwidth for updating the screen. A TODO thing for myself at some time.
Attachment:
a53_overlapping_tabs_darken.png [ 461 Bytes | Viewed 2755 times ]