/vr/ - Retro Games

A cartridge in it's most basic form is just a convenient way to plug a ROM chip into the CPU of a console.

ROM is very simple. You give ROM a number called an "address", and it returns a number that is the "data" at that address.

Because we are working with digital electronics, these numbers are specified as binary numbers. For old ROM chips found in carts, the bits for both the address and data numbers have a direct mapping to the pins on the ROM.

For example, let's say we have a ROM that can take a 15-bit address and returns 8-bit data, for a total of 2^15-1 bytes of memory. In that case, there are literally 15 address pins on the ROM chip labeled A0-A14 and 8 data pins labeled D0-D7. The pins are directly connected to the contacts on the cartridge.

Everything gets reduced down to a number on a computer, both data and code alike. Loosely speaking, a computer is designed to execute instructions by keeping track of the address of the instruction to execute (called the "program counter" or PC), fetching the number at that address, interpreting the number as an instruction, executing that instruction, incrementing the PC, and doing it all over again.

In this way a game can be stored on a ROM, which a console can read to execute code and get data.

there might be a chip-select pin or output-enable pin on a ROM chip too, but those are minor details.

make sense?

>>2889374
>>2890867
I learned assembly by myself and a short online tutorial a little before and during learning C freshman year in college. It was incomprehensible at first, but ultimately I picked up low level software engineering better than anyone else I know because of it, granted there aren't many people interested in metal anymore.

Those books cover the 65xx and 68k series, which are used everywhere in retro systems. A manual is much better than an online tutorial, but much more wordy. I suggest you find a system and game you want to hack, learn the assembly with one of those books, and look at some disassembly vomited out by an emulator to see how much you can read as you go.

If you're interested in 65xx, I'd highly suggest this book: http://wiki.nesdev.com/w/images/7/76/Programmanual.pdf

>>2889951
watch this faggot's 6.004 lectures on computer architecture:
https://www.youtube.com/watch?v=CvfifZsmpQ4
they are fucking fantastic. They walk you through building a preocessor from the logic gate up to assembly languages and compilers. I found this guy after learning all of this stuff, but its great to see it all so masterfully covered in such a condensed set of videos.

>>2891140
Eh, commodity retro
processors are pretty much variations on the same design.

>>2893396
Just curious, would a game developed for a retro system be retro?

>>2843723
This should be a really simple hack. The easy (but more limited) way is to zero out some values in the sound data, while the harder (but more general) way is to locate the code that fires off the sound effects.

Easy way: The A-DSP is designed to make this kinda of hack almost trivial. You need to find in ARAM where the Source Table (a table with pointers to the BRR sound data) is located by examining the DIR register (DSP $5D). Next find which pointer corresponds to the crying and timer sound effects (for instance, by setting all pointers to the same value and listening for the results). Once you have found the pointers you can locate the BRR data in ARAM. Then you will need to trace back where the data is located in ROM. Luckily often times audio data isn't compressed on the SNES, so this amounts to watching for CPU=>APU transfers and noting the source of the data. The final step is to figure out where the BRR data is in ROM and zeroing it out. Viola, no more crying Mario/timer, but you may have inadvertently disabled other sound effects that rely on crying/timer (more likely than you think).

Harder way: Locate the program causing the sound effects to be played. This can be done by searching for programs that modify registers APUIO0-3 (CPU $2140 - $2143). There should be a sound effect routine that plays a sound when called. It will take as arguments a sound id and perhaps panning, volume, priority, etc. Once you know the address of the program, it's easy to search ROM for calls to this program. Look for the id that corresponds to Mario/timer sound effects, and NOP out the calling instruction. Viola, no more crying Mario/timer, and you _won't_ break anything on accident.

If something that I wrote doesn't make sense, don't hesitate to ask.

>>2811642
>>2811680
You broke the D3 pin, or in other words data bit 3. If you can't read this line, you're fucked.

Fyi: SNES has a 24-bit address line, and a 8-bit data line.

>>2581706
>NMI
Non-Maskable Interrupt. It's an interrupt that the processor can't ignore. On the SNES it is tied to a safe time to update the video registers without glitching: the Vertical Blank (V-Blank) interval.

V-Blank occurs when a CRT's electron gun scans to the bottom of the screen and needs to turn off while it resets back to the top. This takes a relatively long amount of time, and during this time the TV is not drawing anything. Thus the Picture Processing Units (PPUs, read GPU) can be accessed without glitching the screen, and Video RAM (VRAM) can be read and written to by the CPU since the PPUs aren't accessing it to draw.

>DMA
Direct Memory Access. A fast way to move lots of data using special hardware rather than the CPU.

While a large part of what CPU does is move data, they aren't fast because of instruction fetches and loop overhead. Most computers have special hardware that the CPU can use to move large data blocks fast. Graphics and levels are good targets for DMA, individual variables not so.

>Joy
Joystick, aka controller.

>RNG
Random Number Generator. More precisely a Pseudo-RNG (PRNG). A function that generates random numbers.

I coded a 'linear congruential' RNG. You give it a seed, and every time you call the RNG it multiplies the seed by a number and adds another number. I also exchange the top and bottom bytes of a 2-byte word to mix up the lower bits more.

> OAM
Object Attribute Memory. The special memory region in the SNES that defines how to draw objects, one of two graphics primitives available (the other being backgrounds). OAM is how you tell the SNES to draw all 128 sprites every frame. An OAM entry is defined per bit as:

VHPPCCCN NNNNNNNN YYYYYYYY XXXXXXXX SX

S=Size (1 bit, small or large)
X=X position (9-bits, 0-511)
Y=Y position (8-bits, 0-255)
N=Name (9-bits, 512 character graphics)
C=Palette (3-bits, 8 palettes)
P=Background priority (2 bits, 4-priorites)
H=Horizontal flip (1 bit)
V=Vertical flip (1 bit)

>>2547141 See >>2547159

>>2547252
>>2547163
>>2547292
>>2547302
So I claimed that the maximum usable address space is 4MB in my original post. Let's explore that statement.

Correct me if I'm wrong, but no commercial game exceeded 4MiB. Nintendo didn't offer cartridge configurations larger, with one exception.

Clearly you guys know about memory mappers. The NES was famous for them, but the SNES has only one that I know, the SA-1, and that wasn't even the primary feature of the chip. I don't have any examples its mapper hardware being used. This is because the SNES memory space was large enough not to be an issue 99% of the time. Furthermore Nintendo claims the SA-1's memory controller supports up to 8MiB of ROM and 2MiB of RAM. But did any published game actually take advantage of this?

Sure, you'll find some Star Ocean ROMs that are 6MiB, but those are hacks to get around the difficulty of the SDD-1 coprocessor emulation. The actual on-catridge ROM is 4MiB.

Since any system's memory can be effectively extended to an arbitrary size with mapper hardware, and since the SNES wasn't generally known for mappers, I'm gonna limit the discussion to address space sizes of 24-bits (16MiB) or smaller.

The SNES hardware is really the deciding factor. A cartridge is connected to all 24 address lines (see picture)

Looking at the SNES memory map we can count the usable space (ignoring b-bus, internal registers, and memory mappers):
http://www.romhacking.net/documents/193/

Respecting /CART:
+(($3F-$00+1)+($BF-$80+1))*($FFFF-$8000+1)
+(($7D-$40+1)+($FF-$C0+1))*($FFFF-$0000+1)
= $BE0000 bytes = 12451840 bytes ~= 12.4 MB.

Ignoring /CART (because you can and commercial carts with coprocessors often did):
+(($3F-$00+1)+($BF-$80+1))*(($20FF-$2000+1)+($3FFF-$2200+1)+($FFFF-$4400+1))
+(($7D-$40+1)+($FF-$C0+1))*($FFFF-$0000+1)
=$EB8000 bytes = 15433728 bytes ~= 15.4 MB.

Vesus the largest commercially published games of 4 MB.

Interpret this as you will.

>>2476478
>You don't even know what information to look for let alone whether it's readily available online.

Google for "SNES cart pinout", first fucking result is the pinout that is needed to make a converter for a ROM dumper.

You don't know what the fuck you are talking about.