File: untitled.png (19.7 KB)

19.7 KB PNG

>>12463490
Anybody here know how to make Game Genie codes?

I'm making a short little Castlevania III ROM hack where I'm just replacing all the levels up to the first boss. I would like to make it so that when the player kills the first boss and picks up the orb that the game just goes to the credits instead of the map screen after the health and score counting sequence completes. Anyone know how to make a game genie code I can patch into the ROM that will do this?

I've tinkered with a hex editor but I can't seem to find the spot in the code where the target destination for level switching is set. There are already Game Genie codes out there for going to the end/credits screen at will by pressing start so I know it can be done I just have to find a way to tie it to the boss orb specifically.

I've already successfully implemented Game Genie codes into the ROM that skip the title screen intro sequence, name screen, and opening cut-scene, so having a code that will end the game to the credits after the boss is defeated is the only thing left I need to make this a tidy little episode. Currently I have a code implemented that disables the timer so that when the boss orb is picked up the point counter goes up to infinity because time cannot count down and so the game stops and cannot proceed past the end of the boss fight, but this isn't an ideal way to end the game.

Any help/suggestions would be appreciated. Pic related is a screenshot of one of the new levels I'm making.

>>12463539
My approach as a noob who knows nothing about this would be to copy the goal orb that appears when you beat Dracula.

File: untitled.png (22.3 KB)

22.3 KB PNG

>>12463710
That's an interesting idea actually, just swap the orb itself, but I still have no idea how to do it. Anyone know if there a hex editor for dummies I could use that visualizes the data in a more comprehensible fashion? The hex editor in FCEUX seems to be for advanced users.

Have another screenshot btw.

>>12463539
I looked into this briefly and if you go to rom address 0x004167 and change the "08" to "0d", then the game will go to the end credits instead of the map screen.

KOF in SNES:

https://youtu.be/Rx_bwdkFRZk

File: untitled.png (21.6 KB)

21.6 KB PNG

>>12463790
Thank you Anon, I punched that into my hex editor and it worked perfectly.

Super MD Boy!
https://jungrock.itch.io/mega-meat-boy

File: HackingCV3.png (239.3 KB)

239.3 KB PNG

>>12463734
>visualizes the data in a more comprehensible fashion?
Nope. The data the hex editor shows is just what the data is. Each game is gonna use the data however it does and there's no way to generalize it more than that. What you have to do is the hard work of working out what data is what, unless someone else has already done that and posted it on some place like the data crystal wiki. That's where I looked to find https://datacrystal.tcrf.net/wiki/Castlevania_III:_Dracula%27s_Curse/RAM_map and the entry:

$0018 System State
00 = Title; 02 = New Game; 03 = In-game Transition; 04 = In-Game;
05 = Game Over Transition; 06 = Game Over; 07 = Stage Select Debug;
08 = Map Screen; 09 = Prayer Scene; 0a = Name Entry; 0b = Password Entry;
0c = Epilogue; 0d = Credit Roll; 0e = Respawn; 0f = Sound Test Debug

Then I set a write breakpoint for that address which triggered after getting the orb and above the sta command that wrote the accumulator to the address, there was an lda command that loaded the value of 0x08 into the register.

Chun Li please snap my dick in half! https://www.youtube.com/watch?v=dovUMLsLzUI

>>12453121
More ideas for a GBA game?

>>12464447
Mario but you can rape all the enemies

https://youtube.com/watch?v=9U9Re7HSKBQ

File: sex triangle.png (10.8 KB)

10.8 KB PNG

>>12436531
looks nice

>>12464447
A time-limited collectathon themed around sex.

While I do see technical and gameplay improvements in this new Till & Hat demo, I definitely don't like the new tiles for the trees, rocks and the color palette. Some pillow shading here and there too.
The old build was weird mechanically and there was some visual flaws (there was some tangents between the foreground platforms and the background, main character a little lame), but overall the art style was much more consistent.

Right now it feels like the game slapped different assets together without trying to make them coherent.

I do wish the dev finishes the game first though.

https://youtu.be/Gw65V0AGHqo

File: untitled.png (17.2 KB)

17.2 KB PNG

>>12464392
Thanks for all the great info and help fren, I didn't even know a website like data crystal existed. I will study this.

File: gopnik.png (90.5 KB)

90.5 KB PNG

>>12465808
All valid points, but I do really appreciate how the villains are an overt communist stand to the point that they are wearing Adidas as well.
This dev seems to have a sense of humor so maybe they are all right.

>>12465886
*stand in

>>12465886
I didn't.
Cool to hear that though, kek.

>>12459973

duck
https://retrotainmentgames.itch.io/cease-desist

https://www.youtube.com/watch?v=tiUnsWjaAxo

A Clock Tower wanabee for the Genesis but something looks very off, like it used AI assets or something.

>>12467943
it adds to the spookiness

4chanbob
https://www.youtube.com/watch?v=Ss3ZRVucsWk

>>12467305
looks kind of cool. grabbed it, will try it out after this sick ass nap i'm about to take

File: OAkLQj.jpg (517.6 KB)

517.6 KB JPG

>>12467305
>https://retrotainmentgames.itch.io/cease-desist

Ok, at least put an image next time.

Genesis port of 3D Pinball Space Cadet when?

I want to do a romhack of NHL 94; a 6-team league, change names/logos, and change the checking grunt SFX. anybody here got experience with the romhacking scene for that game?

>>12468601
I know it has a noteworthy scene. Maybe this site can help you
https://forum.nhl94.com/index.php?/forum/6-editing-amp-hacking/

>>12468621
>a sports game from the 90's has an active rom hacking community
What a world.
My brother has NHL 94 for the Genesis btw.

https://xcancel.com/yhzmr442/status/2036139610544443780

https://www.youtube.com/watch?v=KpvrkCeuR7o

>>12468726
NHL 94 is considered one of the best sports games of all time, and one of the top Genesis titles. it's good, not just as a "sports game" but as a game full-stop.

holy shit

Any one tried using Claude for assistance with modding?

>>12471847
no

>>12471847
Gross

Has anyone made Lanky Kong Country?

https://www.youtube.com/watch?v=UUXW-NcZiAk

SILICONGRAPHICS
https://www.youtube.com/watch?v=lXxmIw9axWw

https://www.smspower.org/Homebrew/RoadFighter-SMS

>>12473337
Has anyone made Jungle de Ikou 64, Shamanic Princess 64, and Birdy the Mighty 64?

>>12473504
What the hell are you smoking dude?

>>12469767
https://www.youtube.com/watch?v=QmMrbfyJ0vE

>>12473506
It's the trannie Jannie ofuscating and derailing for fun.

>>12473506
Herb from resident evil/biohazard

https://www.smspower.org/Homebrew/FridgeFury-SMS

>saves the 3DO
https://www.youtube.com/watch?v=ciFdfj3D_NA

>>12474243
Not clicking that shit.

>>12473337
neat.

>>12474243
>Komplete
>Still full of innacuracies.

Was going to enter the SMS coding competition but my game had bugs causing it to not start property, probably would have taken a week to fix. My fault since I knew about the deadline since December.

>>12475687
post the game

>>12475687
>was gonna larp so did

>>12473504
>Jungle de Ikou
Based!
>Shamanic Princess
Based!
>Birdy the Mighty
Based!

>>12464005
Cadillac and Dinosaur on SFC
https://x.com/yoshinokentarou/status/1985927882284335362

Earthion!
https://x.com/yuzokoshiro/status/2038310414937964761

>>12471847
Its better at counting cpu cycles than giving you code that isn't the coding version of a bubba gun

File: 2026_03_29_14_54_54_268.jpg (234.3 KB)

234.3 KB JPG

>>12463490
I've been enjoying the ECW Born to be Wired mod for WWF No Mercy. Been in development for a while, but the open beta dropped a month ago.

https://youtu.be/dM0j8vUkxv4?si=mQML8D_1kCo4wpD2

https://tavuntu.itch.io/ppux
Pixel art editor for NES

>>12473492
Frogger SMS port? It seems to be oddly absent from any Japanese systems.

>>12476896
Ok, this is interesting, but how does it compare to NAW?

>>12477085
what's that?

>>12476896
This shit doesnt work.

I never liked the NES Boulder Dash and wondered how hard it would have been to do a straight port of the original Atari 800 game?

>>12477509
>I never liked the NES Boulder Dash and wondered how hard it would have been to do a straight port of the original Atari 800 game?
the original was 16k so you're talking like an NROM game? i don't think it'd be possible. the NES had a lot of limitations that home computers didn't have.

>>12478342
Little Nemo is pretty short. For contrast SMB2 has the same ROM size but is over twice as long since many of the stages are reusing the same graphics over and over instead of having unique ones for each stage.

>>12478349
http://nintendoforever.free.fr/Nes/LittleNemoDreamMaster/LittleNemoDreamMaster_Soluce/LittleNemoDreamMaster_08_Plan_NightmareLand.php?lang=en

Nine tile sets. The CHR ROM is the usual 1 megabit size which can fit 32 sets so the game never comes close to using all of it.

>>12478380
i think a lot of NES games didn't necessarily need all the CHR space, publishers bought cartridge hardware mostly based on cost and availability and Nintendo I guess offered SLROM/TLROM boards cheap.

https://vgmaps.de/maps/nes/chip-n-dale-rescue-rangers.php

I count about 13 tilesets.

>>12478380
What is the CHR ROM size limit? In BYTES?

>>12478765
It's 128k (131,072 bytes). Each NES tileset is 4k so 32 sets of background tiles and 32 sprite sets.

>>12477547
Why do you think it wouldn't work?

>>12478380
>125kbytes

>>12478780
And how many tiles those tilesets can hold? Counting cutscenes a la Ninja Gaiden too.

>>12478805
it's 256 tiles per set. each tile is 16 bytes so one set is 4k.

>>12478519
Counting the Title Screen and the two unique cutscenes of Gadget and the group, I'd say they are 17

>>12478797
>Why do you think it wouldn't work?

Boulder Dash has 4 way scrolling, I think that isn't possible without a 32k PRG.

>>12478812
So mappers won't increase the size?

>>12478820
No. It's a hard limitation of the PPU.

https://www.boulder-dash.nl/down/maps/PeterLiepa/BoulderDash01.html

here's the levels on C64. there's 2 char sets the title screen and everything else. C64 tilesets are 2k a piece (256 chars, each 8 bytes). sprites are 64 bytes which seems like a lot although you don't need as many of them as you would NES sprites to build a large object.

>>12478812
the NES treats sprites and tiles interchangeably and you can select which of the two halves of the CHR bank are used for what, although only 64 total sprites can be on screen at once (out of a total 256 per set).

>>12478849
Oh, so you have to use CHR banks for sprites, between 32 banks?

>>12478867
Yes of course. The PPU can see one set of sprite and tiles at a time and the mapper switches between sets. Most of them however have banking of various granularities, for instance MMC1 does 4k meaning each tile or sprite set can be swapped individually, while MMC3 has 1k banking so the sets can be swapped in quarters.

>>12478872
So that's why NES games were so damn tiny and short, but why would there be bigger up to 1MB then instead?

>>12478874
>So that's why NES games were so damn tiny and short

the main limitation was really the PRG ROM since that affects the actual length of the game (ie. how much game logic you can have) and the most common PRG size (used by probably 60% of the library) was 128k.

https://shop.nesmaps.com/wp-content/uploads/2017/10/Contra800.png
Contra maps. Eight tile sets plus a ninth for the title screen. The Famicom version also had cutscenes that got dropped in the process of converting it to UNROM since they had to store the CHR data in the PRG ROM and there wasn't enough space for them.

>>12478874
16-bit console games aren't necessarily longer, the larger ROMs are mostly needed for the graphics which are huge compared to NES graphics.

>>12477128
This thing has basically two stages that repeat themselves.

>>12477509
>I never liked the NES Boulder Dash and wondered how hard it would have been to do a straight port of the original Atari 800 game?

In order to do that, you would need the Atari 800 version's original source code (or, more realistically, a fanmade code disassembly), which then you would have to convert to Assembly (the language used by the NES), along with updating the code to make use the NES' capabilities instead of the Atari 800's.

Alternatively, you could also make a ROMhack of the NES version where you change as much content as possible to match the Atari 800 version.
Some changes might require you to change the code, however, in which case you'll need to learn Assembly and then disassemble parts of the code so you can understand how the game engine works. I recommend Mesen for this, thanks to its excellent debugger.

>>12479139
the version we got was apparently not a source port and it doesn't play anything like the original computer versions from 83-84 which were all based off the Atari Boulder Dash code base

>>12478876
Ok, so you are limited to 32 bank (let's say "sheets) to do all of your graphics and sprites, but don't MMC3B and MMC5 allow you to increase the size of the sheets while still sticking to 32? Then how you did get stuff like the UMK3 hack of that Hummer bootleg.

>>12479375
https://www.nesdev.org/wiki/MMC5

No. It lets you bank the CHR in 1k chunks but each graphics table is a fixed 256 objects and that cannot be changed no matter what mapper is used. MMC3 supports up to 256k CHR ROM which means you can have 64 tile and sprite sets. However a lot of MMC3 games with 256k CHR use it to store the level data to free up PRG space for additional game logic or sound data.

>>12479413
Ugh...............so the NES was a limited piece of shit then, to think.

>>12479550
Its 70s/80s tech with newer chips strapped onto carts over time, yeah its limited.

>>12479550
What gave you the impression it wasn't?

>>12468726
Tecmo Bowl has multiple releases every year

>>12479375
Some games have more than 128 KB of CHR ROM. Metal Slader Glory has 512 KB of CHR ROM, for instance. 128 KB isn't a steadfast limit. It's just what was most common. Also, while you cannot increase the size of a tileset, you can swap tilesets mid frame with the condition that everything on the same scanline has to have the same tileset. You can use this to have more than 256 tiles in the background at once.

>>12479660
Kirby's Adventure swaps tile sets in mid-screen for the status bar.

>>12479660
128k is plenty of space, as we've seen a lot of games didn't even use all of the CHR ROM.

>>12480191
Most MMC3 do that on

>>12480841
Pirates! does char swap as well and that's MMC1.

So, for various reasons(I'm loading from a floppy disk on a computer with variable RAM) I need to be able to load code in dynamic memory locations. The architecture for relative jumps though is limited. What would be the best approach to handle function requests?
I have an idea already, I'm just fishing for better ideas. My idea is that I could have a function in a fixed location that, based on an identifying hash, looks in a table to see if the code snippet is loaded. If it is, it returns a jump table that the code snippet is associated with, and if it is not, it tries to load it from the disk.

File: sonicnes.jpg (105.7 KB)

105.7 KB JPG

>>12475926
>>12475997
I tried doing 4 way scrolling but I messed up the calculations somewhere so when loading the next tilemap some lines wouldn't line up with the screen. Something like if the tilemap is 960 bytes when you reach the end you increase the pointer by that much. I spent most of the time on image conversion outside of the game. I'm going back to my nes game and make the x and y co-ordinates a part of it from the start. I've started on a tool to convert sms graphics to the nes, I haven't done attributes yet so this is only 4 colours.

>>12481403
NES scrolling is easier if you do single screen mirroring but only some mappers can use that in particular AxROM and MMC1.

File: 9541screenshot3.png (4.1 KB)

4.1 KB PNG

https://www.youtube.com/watch?v=LbRPSs2buKA
Little surprised something like this hasn't happened sooner. Unless it did and I somehow didn't know about it.

>>12479660
ah, ok

https://nescartdb.com/profile/view/35/mega-man-4
https://nescartdb.com/profile/view/1114/mega-man-5
https://nescartdb.com/profile/view/891/mega-man-6

>go from CHR ROM to RAM and back again
why do?

>>12482667
It might have been parts availability, perhaps for MM5 they couldn't get 4 megabit ROMs at a reasonable price so they switched it to CHR ROM and two 2 megabit ROMs instead.

>>12482669
>Bits

Can we please JUST USE BYTES!?

You are fucking with people.

512kbytes that's what you mean.

>>12482736
Unfortunately, the official cartridge sizes are in bits. That's why you see people using megabit to describe them.
The reason is that bytes aren't actually a fixed size. For example, the TMS320 DSP chip uses 16-bit bytes, and the CDC Cyber mainframe series use 12-bit bytes. This is completely useless to know for consoles since no console uses a non-8 bit byte, but it's something worth noting.

>>12482667
one of the only games to use MMC3 with CHR RAM

https://strategywiki.org/wiki/Teenage_Mutant_Ninja_Turtles/Area_1

TMNT has about 18 tile sets for the levels, probably 24 total when the title screen and cutscenes are added. That would be 96k of unique graphics and the remaining 32k should account for the sprite sets. This is one instance where the CHR seems to have been completely used without leaving any waste.

>>12483243
Then how would you be able to have more cutscenes and sprite graphics?

>>12483247
>Then how would you be able to have more cutscenes and sprite graphics?
Use MMC3 because 128kb CHR ROM is the maximum size MMC1 supports.

>>12483243
the CHR ROM setup was important in the early days of the Famicom because they had very limited 16kb and 32kb ROMs and each tile is 16 bytes so it's 8k for one complete sprite and tile set. moving them to a separate ROM was important to save space; this was less of a problem on the SG-1000 since tiles only take 8 bytes.

>>12483243
Correction, 22 tile SETS for levels and maps.

Counting Title Screen, Pause Screen, and cutscenes, you have banks free

>>12483283
that would be 88kb of graphics, leaving 40kb remaining which would allow for ten sprite sets

>>12483248
There's this guy who himself confused others by saying you can't have more then 32 banks because of PPU hard limitation of something, now you can increase the size of a tileset bank, but then how do you get more space size? I think even he doesn't know or he ain't correct but doesn't wanna admit.

>>12483286
Eh, you didn't read it, I said 22 banks filled with JUST the levels and maps.

The rest and I should said the sprites as well takes 10 banks

>>12483287
each tile set is 256 objects, this is a hard limitation. the amount of tile sets you can have depends on the ROM size.

>>12483297
Well it was said you couldn't exceed 32 sets here, so, Can or Can't?

which mode for NES sprites would be the best for performance? 8x8 or 8x16?

>>12483514
https://www.nesdev.org/wiki/Sprite_size

>>12483247
>>12483248
Taito's TC0690 mapper (INES mapper 48) might also be worth looking at. The 2 kilobyte CHR banks can address up to 512 kilobytes of CHR data, and the registers are simpler than MMC3's. However, it was an uncommon mapper and might not have as widespread support in emulation and flashcarts.

>>12483514
8x16, reduces how much sprite metadata you need to update per object. The issue though is every sprite now occupying more scanlines and wasting precious CHR ROM if you have small sprites that would have fit in a 8x8 tile.

>>12483287
The confusion seems to come from >>12478780 saying 128 KB is the CHR ROM size limit.
I think they were trying to say
>128 KB is the limit for the MMC1 mapper.
which is true (https://www.nesdev.org/wiki/MMC1). Other anon interpreted this as
>128 KB is the limit for all mappers.
which is false.
The "PPU hard limitation" thing was referring to the fact that there are always 256 tiles in a tileset, not anything to do with CHR ROM capacity.

>>12483416
(1/3)
I'm going to explain everything from the top so there is no more confusion. All numbers in hexadecimal will be prefixed with $. If a number does not have $, it is in decimal.
For our purposes, 1 KB (1 kilobyte) is 1024 bytes, so 4 KB is 4096 bytes.

At all times, the PPU address space contains two 4 KB tilesets. I will refer to them as tileset 0 and tileset 1. Tileset 0 is mapped to PPU $0000-$0FFF, and tileset 1 to PPU $1000-$1FFF.
Each tile is 8x8 pixels encoded in a 2 bit per pixel format. 64 pixels per tile * 2 bits per pixel / 8 bits per byte = 16 bytes per tile.
16 bytes per tile * 256 tiles per tileset = 4096 bytes per tileset.

The format the PPU uses to store the background and sprites dedicates 1 byte to the tile index. 1 byte can have 256 different values, so one value for each tile in the tileset.
Which of the two tilesets the background draws from is controlled by bit 4 of register PPUCTRL.
Which of the two tilesets the sprites draw from is controlled by bit 3 of register PPUCTRL.
The background and sprites can only draw from the tileset that is currently allotted to them. If tileset 0 is allotted to the background, the background cannot use a tile from tileset 1. If tileset 1 is allotted to the sprites, sprites cannot use a tile from tileset 0.
Conventionally, one tileset is dedicated to the background and the other to sprites. This is not required. Both the background and the sprites can draw from the same tileset at the same time. Which of the two tilesets the background or sprites are using can be changed any time the CPU can write to the PPUCTRL register, so during either vblank or hblank.

>>12483602
(2/3)
This is where this gets tricky, so read carefully. With the exception of palettes which are fixed to palette RAM, the entire PPU address space is mapped by the cartridge. By mapped, I mean circuitry on the cartridge determines where the bytes that comprise the PPU address space are retrieved from. The cartridge circuitry can map segments of the PPU address space either to ROM or RAM within the cartridge, or to 2 KB of VRAM within the console. Conventionally, the tilesets (together PPU $0000-$1FFF) are mapped to the cartridge, and the tilemaps and attribute tables (PPU $2000-$2FFF) are mapped to console VRAM. You may notice that 2 KB of VRAM is not enough space to cover the 4 KB region of memory that comprises the tilemaps and attribute tables. This is the reason most games have mirror tilemaps. The cartridge circuitry dictates that the excess half of the 4 KB memory region be filled by duplicating the 2 KB of VRAM. Whether the mirroring is horizontal or vertical depends on which PPU memory regions are mapped as duplicates. Games with no tilemap mirroring (all 4 tilemaps are unique) work by mapping cartridge memory to the tilemap portion of PPU address space.

In the simplest standard cartridge, NROM, PPU address space mappings are fixed and cannot be changed at runtime. This is why the iNES header has to specify vertical or horizontal tilemap mirroring in NROM games, and why the tilesets cannot be changed. NROM has an 8 KB CHR ROM chip. The first 4 KB are mapped to tileset 0, and the second 4 KB are mapped to tileset 1.

>>12483606
(3/3)
Mappers, as their name implies, are hardware dedicated to have finer control of what memory gets mapped where. This is where terminology gets confusing as people using phrases colloquially muddies the waters of their precise meaning. "Mapper" does not refer to the entire cartridge. It refers specifically to the integrated circuit that controls the logic the cartridge uses to map memory. Unlike, say, NROM cartridges, cartridges with complex mappers such as MMC1 are able to map memory dynamically. What memory goes where is not fixed; it can be changed at run time. This is controlled by reading to and writing from hardware registers with the CPU.

The console has a limit to how much memory can be mapped at once, hence why 256 tiles per tileset is a hard limit, but it cannot limit how much memory is on the cartridge. There are no limits to the maximum possible size of PRG ROM, PRG RAM, CHR ROM, or CHR RAM in a cartridge. You could design a mapper that supports unlimited space; the console doesn't know or care. The aftermarket MXM-0 mapper supports a 1 gigabyte ROM. That's gigabyte with a g. When people talk about ROM size limits with respect to mappers, they are referring to the limits of the integrated circuit that controls the cartridge's logic. MMC1 is limited to 128 KB of CHR ROM because that's all the MMC1 ASIC was designed to handle. This limit has nothing to do with the console itself.

>>12483607
(4/3 i can't count lol)
There's once more concept I will elaborate on, which is "window." Both the regions of memory that are mapped to and the data that can be mapped to those regions are broken into discrete chunks of a fixed size. The size of these chunks is referred to as the "window" of the mapper. For example, the MMC1 has a CHR window of 4 KB, meaning it breaks the 8 KB tileset region of PPU memory into two 4 KB chunks (one for each tileset), and can assign a different 4 KB data block to each chunk. This is why things are often broken into "number of tilesets," especially when working with MMC1. This paradigm is not always effective however, since many mappers have a window smaller than 4 KB. For instance, MMC3 has a CHR window of 1 KB, meaning individual quadrants of each tileset can be swapped out. If quadrants are mixed and matched at will, the "total tilesets" way of thinking about CHR ROM space falls apart.

>>12463490
Play her games now
https://www.youtube.com/watch?v=aLSnS76W4k0

most ASIC mappers provide soft mirroring; without an ASIC mapper the cartridge was hard-wired for V or H mirroring since Nintendo originally assumed you would select this depending on what direction the game was going to scroll in. if AxROM or MMC1 is used you could also use single screen mirroring, the main advantage of that is the scrolling code is a little simpler to write.

>>12477509
https://www.youtube.com/watch?v=jzcIQiyprP8
try Crossfire instead, it would be a less ambitious porting project. no scrolling and only 8kb.

CNROM was the first and simplest banking scheme. Fixed PRG ROM and you can swap the CHR ROM in a single 8kb piece. Usually 32kb CHR ROM but sometimes 16kb. Most of these also put the level data in the CHR ROM to free up PRG space for additional game logic or music data.

>>12483609
Okay thanks

Another slight quirk of certain ASIC mappers is the power on ROM bank being random; you don't know which bank will be mapped into $C000-$FFFF so you may have to waste space putting redundant code in each one. I believe MMC3 always powered on with the last bank mapped in but MMC1 or at least some MMC1 revisions were random.

>>12484263
i think UNROM is also always last bank put in $C000-$FFFF?

>>12484270
yes. the bad thing about discreet mappers is they had bus conflicts, not an issue on emulator/flash cart but it was something that had to be minded when real carts were used. you could potentially fry the ROM chip by throwing its signal lines high.

File: SMSPower 2026 Competition.png (189.2 KB)

189.2 KB PNG

>>12463490
Haven't seen anyone mention this, but SMSPower started their anual competition 6 days ago:
https://www.smspower.org/forums/20838-29thAnniversaryCompetitions

There's in total 36 entries:
* 23 coding/game entries (homebrews)
* 10 music entries (VGM covers)
* 3 hacks entries (ROMhacks)

File: over 9000 hours for this.gif (903.3 KB)

903.3 KB GIF

Found these Pokemon romhacks called Red/Blue (Colorization) and I'm never going back to vanilla RB ever again. They're effectively just Gen1 with a Gen2 coat of paint but holy shit is it so much better.

>>12484583
Is there a good 151 hack that's compatible and doesn't attempt to fix bugs or add content that wasn't in the originals?

>>12484280
>you could potentially fry the ROM chip by throwing its signal lines high

afaik that was mostly an issue with CMOS ROMs because in a bus conflict the signal lines will go high while NMOS will go low. most NES carts used CMOS ROMs but some were NMOS (carts with NMOS ROMs will get noticeably warm when they've been running for a while). of course the programmers wouldn't know what was going in the carts so avoiding bus conflicts was important.

>>12484651
Make your own. Contribute, dont be a user

that anon was slightly off. a 128kb CHR ROM has 32 total slots that you can fit graphics tables in, but you can apportion them out however you like, you can have eg. 20 bg tile sets and 10 sprite sets.

It seems Mega Drive games had more 4 and 8 megabit games while SNES had more large-sized ROMs.

>>12484679
>It seems Mega Drive games had more 4 and 8 megabit games while SNES had more large-sized ROMs.
some of that was the MD coming out earlier, but also SNES graphics are typically bigger space hogs. there can be up to 4 background layers and Mode 7 objects take 64 bytes a piece while the MD has only 2.5 background layers. on the other hand its color depth is fixed 4 bit while SNES had low color mode with 2 bit color depth, mostly used on 4 megabit games to save on space.

SOJ had a cap of 24 megabits for cost reasons.

>>12484317
nice

give me your best zelda alttp rom hacks, bonus points for not picking parallel worlds. I am in the mood for some zeldavania

>>12486074
It's crazy how bad the selection is for ALTTP. Its peers SMW and Super Metroid have hacks, its successor OoT has hacks, but ALttP is still stuck with shit like Parallel Worlds. I guess everybody made Zelda Classic quests instead

>>12486203
yeah I feel you. as someone who came from sm and mario zelda feels like a wasteland outside of parallel worlds which is like super dated.

>>12471847
i've tested it by asking it to help me find addresses for stuff that i already know, and it literally just makes shit up and presents it as fact. do NOT use it for rom hacking. i feel bad for people who actually use llms for this sort of thing

>>12483786
The bad thing about MMC1 is that it's slow as shit due to the serial interface. It takes six register writes to perform an action while MMC3 takes three and discreet mappers usually just two. You can notice this in how MMC1 games have a noticeable pause when switching screens.

>>12487249
it was cheap and provided adequate capabilities for most games

>4 megabit PRG and 1 megabit CHR
>soft mirroring
>can do single screen mirroring
>supports cartridge RAM and battery saves (although you had to hold down Reset when powering off)
>no bus conflict issues like with discreet mappers

Is Star Fox 64 Randomizer console compatible?

>>12487526
Try it out
You weren't going to buy a console and flashcart just for that, right?

>>12487526
post a download link

>>12488061
Here's a pre-patched rom, latest version.
https://www.mediafire.com/file/433ca7z9hqw45kr/Star+Fox+64+Randomizer.z64/file

SILICONGRAPHICS
https://www.youtube.com/watch?v=xIUkoUEMf_g

File: maxresdefault.jpg (169.4 KB)

169.4 KB JPG

https://www.youtube.com/watch?v=Q0mN9xm4oq4

>>12488863
Animu 64 gonna look amazing.

>>12487864
Tried it out. It works.

>>12483707
>>12489275
Now gaming is peak.

>>12487249
Just so you know, there were two different MMC3s produced by Sharp and NEC and the Sharp ones let you have a scanline IRQ every eight rows while the NEC ones have just one.

>>12490668
Shut the fuck up trannie

>>12489275
Release a ROM or get lost! Stop fucking around, even the Till N Hat guy made 2 demos already.

You GameMaker Faker.

>>12490519
GET BANNED ALREADY!

NEW THREAD
>>12491710
>>12491710
>>12491710