[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games

Search:


View post   

>> No.8137293 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
8137293

>>8137057
it was me the whole time

>> No.8085153 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
8085153

>>8085103
nerdy-nights.nes.science/
masswerk.at/6502/6502_instruction_set.html/
wiki.nesdev.com/w/index.php?title=Programming_guide
Post questions if you get stuck. GL HF

>> No.8085024 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
8085024

>>8084125
> It is a stock game as far as I know
You're 100% sure it's not a reproduction? Those can run hot. A legit cart really shouldn't break a sweat.

>> No.8068383 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
8068383

>>8068332
it's been reverse engineered completely and a replacement has been produced. 100% legal.
funny story is that the Tengen (Atari) clone chip had some debug functions that allowed the algorithm to be dissected.
https://wiki.nesdev.com/w/index.php/CIC_lockout_chip

>> No.8047172 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
8047172

>>8047136
when i was testing the crack, freezing $4AA to 0 just instantly beats every level, because the game thinks you have to rescue 0 people. pretty hilarious

>> No.7961035 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7961035

>>7960326
there were actually technical reasons for this: most of the game calculations were done in the "static sky / hud part" so the processor could do the scanline trickery to accomplish these effects when rendering the road.

>> No.7916535 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7916535

>>7916120
As long as the main structure isn't touched it could be done. Most romhacks just change a few things here and there, or add subroutines pointing to unused spaces in the ROM. That is all well and good and perhaps adaptable with automation.
Where you run into trouble is if the game was reassembled and data / branches / jumps were shifted or moved around. You (maybe) could regenerate two linking structures with each file and somehow match them up. You'd run into Real Trouble if you ran out of space or you had to combine the patches in such a way that branches no longer fell within the -128 / 127 byte range.
For most cases i think your plan would work: I don't know if anyone has tried to make a disassembler / linker. Sounds like a fun project.

>> No.7893646 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7893646

https://www.copetti.org/writings/consoles/
found this the other day, tech specs and architecture for a bunch of retro consoles.

>> No.7411976 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7411976

>>7411962
> I don't think the NES got REALLY good in America until around 1987
There is a reason for that. Bankswitching mapper chips were invented to extend the ROM space. The NES natively can only address 32kb of ROM (code) and 8kb of CHR (graphics). All of the black box games are 40kb or less, and there is only so much you can do in that space.

>> No.7406560 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7406560

>>7406441
>Why they did this is still a matter of speculation.
Well, probably because they could, and it was cheaper. DRAM needs to be accessed constantly so it doesn't decay and lose it's contents. This would have been a huge design problem for WRAM, but, sprite memory is always being accessed so, DRAM it is.
The NES allows for a fast DMA copy of an entire page of WRAM that mirrors OAM. You can't access VRAM or OAM RAM while the screen is drawing, so, it actually works quite nicely.

>> No.7342373 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7342373

>>7341971
ugh. i'll bite.
> ran at a mere 1/3rd the speed
True. The 68000 is faster on paper. The SNES has additional functionality in it's PPU for native transparency effects, scaling (mode 7), 4 simultaneous graphics layers, not to mention an audio processor with 8 simultaneous sampled channels. It could do alot more with the cycles it has.
> The SNES is the only console that generation that cannot exceed 256x240 before being restricted to a mere 16 simultaneous colours
No. Jackass. 8 palettes of 16 simultaneous colors. 256 possible colors of a palette of 65,636. The Genesis could ONLY do a maximum of 256.
> The SNES outputs audio at almost half the sample rate of the Mega Drive
Just straight up untrue. The 64KB of audio ram was certainly a bottleneck, but it could output a wide host of sample rates and bit depths. It also has a linear interpreter to smooth over less depth / frequency samples.
> the shit SNES is, simply put, far behind.
Much like the NES, it is built with cartridge expandability in mind. You can see how later games like Mario RPG / Kirby Superstar took advantage of the SA-1 coprocessor at 10Mhz.
> Genesis
No transparency effects. No native scaling or transformation, all software. Sample rate was locked at 22khz and sound generally terrible, like the horrible SOR voices. I love me some YM chiptunes done right, but, you're stuck with that sound.

>> No.7328824 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7328824

>>7328276
> Is there any way I can load the value of whatever tile is on a particular place on the screen
Technically yes, but, it's (usually) not a great idea to access VRAM. Once the screen begins drawing, you (mostly) have to leave the PPU alone. You could preload and store some values of tiles before vBlank ends, but, a better solution (usually) is to find wherever the values are in ROM and compare those. Most games deal in 16x16 metatiles anyway, so, comparing that value from ROM is how most games operate.
TL;DR - Don't bother the PPU. It is very busy.

>> No.7265503 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7265503

>>7265234
So that's PRG ROM, CHR ROM (not ram) and WRAM right? Also the smaller CIC and the MMC3 itself respectively?

>> No.7086771 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7086771

>>7086649
It's pretty easy. You load the low byte of an address into the OAM address register ($2003) , usually $00, and the high byte into the OAM ($4014) , usually $02, and 514 cycles later all of your sprites are magically copied into OAM RAM! $200-$2FF contains a copy of the sprite table in most games, as a de-facto standard. You want to do this every frame: if you don't, the cheap ass DRAM they used starts to decay and forget things. It only takes up 3(ish) scanlines of the 20 you have for vBlank, so, you have some time to do other things before the next frame starts drawing and the PPU is busy doing that.

>> No.7037803 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7037803

>>7037683
> 820 banking configurations.
MMC3 appears to be a strong winner IMO. But yes, bank switching is a pain in the ass.

>> No.6943027 [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
6943027

>>6941425
> NES ports and their flicker
You know what's funny about that? Nintendo tried to make more than 8 sprites drawable per scanline, but they fucked up the hardware implementation. A sprite overflow detection flag is also built into the 2A03, and it doesn't work right either. Woops LOL
https://wiki.nesdev.com/w/index.php/PPU_sprite_evaluation

>> No.6943017 [DELETED]  [View]
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
6943017

>>6941425
> NES ports and their flicker
You know what's funny about that? Nintendo tried to make more than 8 sprites drawable per scanline, but they fucked up the hardware implementation. A sprite overflow detection flag is also built into the 2A03, and it doesn't work right right either. Woops LOL
https://wiki.nesdev.com/w/index.php/PPU_sprite_evaluation

>> No.4450426 [View]
File: 64 KB, 300x276, 300px-Gtw_mario.png [View same] [iqdb] [saucenao] [google]
4450426

Post your repair issues, progress, and questions here.

I have a GBC with a very corroded headphone jack that even with alcohol cant seen to clean it up. its so bad that the gbc wont output sound because it thinks there;s a headphone plugged in. Can i just buy a new headphone jack and solder it in? Where could i even find something like that now?

>> No.1762705 [View]
File: 64 KB, 300x276, 300px-Gtw_mario.png [View same] [iqdb] [saucenao] [google]
1762705

http://www.gametechwiki.com/w/index.php/Main_Page

Previous thread: >>1641351

Got questions about repairs, mods, or other technical details? Bring 'em here.

If your console has trouble reading games or self-resets, you may just need to clean it. Check out the game an console cleaning guide first before asking questions here:
http://www.gametechwiki.com/w/index.php/Game_and_Console_Cleaning

GTW needs more repair and mod info! If you're working on a project, consider adding what you learn (or links to guides you use) on the wiki.

>> No.1468896 [View]
File: 64 KB, 300x276, 300px-Gtw_mario.png [View same] [iqdb] [saucenao] [google]
1468896

http://www.gametechwiki.com/w/index.php/Main_Page

The last one was deleted for whatever reason, but who cares about that?

Repairs, mod guides, etc., you need it, we should know how to do it.

Navigation
View posts[+24][+48][+96]