/vr/ - Retro Games

>>7772819
>Spectrum dev:
>worldofspectrum.org
Bring back the snes one.

just let this one die. i'll make another tomorrow.

>>7759779
UNROM/BNROM is often better than MMC1 unless you specifically need PRG RAM. It banks faster and the first 16k is fixed so you do not have to include redundant reset code in each bank. A lot of games that could have used UNROM however just used MMC1 anyway

http://bootgod.dyndns.org:7777/profile.php?id=6

Take Bugs Bunny Crazy Castle. MMC1 was not necessary for this game at all, it could have worked fine as UNROM. However devs may have not initially known a game's exact requirements in the beginning. For example they might end up needing PRG RAM, so it was safer to just go with MMC1 so you had that support available if necessary.

>>7773251
>UNROM/BNROM
Just gives more PRG ROM, right?

>>7773330
same amount as MMC1. usually 128k, a few games are 256k and modern homebrews use 512k UNROM which didn't exist in the NES's commercial lifespan. also you can include PRG RAM with UNROM/BNROM but an additional TTL is needed to decode it while ASIC mappers do that for you.

MMC1 is actually kind of shit because it's relatively slow and complicated to use and doesn't give you any major performance enhancements the way MMC3 does (it's so much nicer to have an actual IRQ counter for split scrolling instead of sprite 0 bullshit).

>>7773396
>modern homebrews use 512k UNROM
Man, modern programmers can't avoid using as much memory as they want.

>>7773407
512k is a huge amount of space for any 8-bit game. But it's mostly because you can get NROM and UNROM 512 PCBs from AliExpress so NES homebrewers always use those setups so they can make a physical cartridge run.

>>7773251
maybe also they wanted MMC1's ability to soft set the mirroring direction. the US Dragon Warrior 1 has a lot cleaner scrolling than the original Famicom game for this reason.

>>7773429
The main reason for MMC1 instead of the original CNROM was to support battery saves instead of 60+ character passwords (the soft mirroring was a free extra benefit)

bump

Are there any good resources/suggested reading material to get into PSX games translation?

bump

>>7773396
>>7773251
MMC1 lets you set single screen mirroring which makes 8-way scrolling a lot easier. Unfortunately MMC3 got rid of this option which would have been really nice in SMB3.

Darkstalkers: The Night Warrior (SNES)

>>7773429
>>7777228
there is one other thing. MMC1 allows the two halves of the CHR bank to be swapped separately. so you can switch in a separate sprite or tile set without disturbing the rest.

>>7777341
ha

>>7772819
Already asked this in the PC-FX thread the last days, but maybe someone here knows more:

Anyone has any info on how to do homebrew on the NEC PC-FX, and is there a good homebrew SDK, maybe even official SDK?
Sadly haven't found much yet, except some people made very few very basic homebrew, and ~2(?) even as Open Source on github.
I really want to test it out, since i really think this console has a lot of unused potential which would be sad to ignore.

>>7777654
The problem with targeting a japanese only console is that your documentation, tools and homebrew communities are probably going to be in japanese. Not to mention they only sold 400,000 of these things, compounded on 5th gen isn't as appealing to homebrewers, it'd be a miracle if you found Anything.
It might be fun to try and do some simple things on but i think it'd be suicide to actually target this thing for a serious project.

>>7778514
>The problem with targeting a japanese only console is that I'm oblivious to the facts that a lot of documentation has been translated, countless emulators have been "sold" for free, and you're asking for advice on a board full of underage fools.
Only one of those is true

>>7777654
Very so. There source tool

Why haven't you started a disassembly of your favorite game, anon?

>>7777228
the 2x2 tile map setup the NES uses is inefficient and wasteful. you will note the Gameboy and Master System were designed later and have what's basically just single screen mirroring (the Gameboy only has 1/4th of a tile map off-screen instead of a complete map as the NES has).

>>7778905
The true enemy to complicated homebrew is time. If you think you can pull it off then fuckin go for it. Who the hell am i to say you can't? Good luck. besides the fact that i've seen countless people barge into this thread with complicated plans and big dreams only to never hear from them again in about a week

>>7779062
it's not that you can't do X project, it's that you have so many ideas for projects that it becomes impossible to pick just one and focus on it

>>7779113
The common illusion is that once you can learn programming language X and system architecture Y that you'll just magically make all of these great games in your head. People don't seem to grasp how long it takes to write tens of thousands of lines of code, draw graphics, make music, and make all of it work in magic synchronization. It's unfortunate that things take as long as they do, but, that's life.

>>7779343
not sure what this weird tangent you're going off on has to do with his post, but i'm sure he's well aware of the time budget spent in making a game. he was saying more you can't make anything if you aren't able to decide exactly what you're making.

Wasn't Bomberman ported to the NES in 72 hours?

Hello, I just want to rip some sprites from a .32X sega rom file, what program can I use for this task?

>>7779383
> i'm sure he's well aware of the time budget spent in making a game
I don't think the best developers or companies in the world can do this properly. It's quite difficult. Scope creep is a bitch. No one seems to be able to grasp complexity properly until faced with the realities of it. Maybe i'm just a rambling old boomer. I don't really have a point. There's always more code to write and things to draw it seems. Such is life.

>>7779421
Oh it's not hard if you try. Back in the day US Gold would say "You are going to port Street Fighter to the ZX Spectrum in six weeks with nothing but an arcade cab for source material and you are going to like it." (^:

>>7779415
If it's uncompressed YY-CHR. If it is compressed you're basically fucked.
Ripping graphics from a ROM directly won't provide palette data anyway. Some emulators have graphics export, but i'm personally not sure about any genesis / 32x that have this feature.

>>7779430
Mega Drive games would have basically always used uncompressed tile graphics. I recall SNES graphics used more compression which is why there's typically an annoying long pause in games when switching screens.

>>7779421
that point was addressed near the top of the thread when it was mentioned that a lot of NES games used MMC1 when they could have gotten away with UNROM due to feature creep. developers wouldn't necessarily know what a game would require so it was better to have that additional margin just in case.

>>7779430
>>7779441
I tried, but after dropping the file into the program all I get is a garbled mess.
Im either blind or stupid, but Im just not seeing a thing Im looking for, which would be the background sprite in pic related

>>7779000
Because I have no idea of how to do that.

>>7779000
Could you get legally fucked for decompiling something? Reverse engineering seems like a giant gray area.

>>7779590
>First World problems
Nintendo lawyer have no power in Brazil whatsoever.

>>7779512
>I just had to dump the one MD game that has 3D polys with a custom cartridge chip
>no I couldn't just dump Aladdin or Altered Beast

>>7779343
Programming can be difficult, yes. Here's a program I got out of an old book about x86 programming that converts decimal numbers to hex. I wanted to convert it to 6502 asm. that was about three years ago and I still have yet to figure out the 16-bit operations or the CBW instruction or how to do those in 6502. I tried using the zero page but I couldn't get it to actually work.

>>7779824
how the hell do you expect to make an entire game when you can't even handle 40 lines of code?

>>7779824
>going from one assembly language to another instead of just referencing a high level implementation
>utterly fucking it up
chad move, beta execution

>>7779619
Baseado e vermelho pilulado

>>7779543
Method 1: Learn how to hex edit data, start mapping out the ROM locations of some of the data you're interested in. Start finding pointers, eventually you'll encounter pointers inline with ASM. Then look up an instruction set reference for your console CPU and start piecing together what's going on.
Method 2: Do cheat searching to find interesting RAM locations. Pull up your emulator's debugger and set watchpoints on those locations, step through the debugger and puzzle out what it's doing.

>>7780098
Man, those people that do disassembly are amazing if it is this hard.

>>7779824
This would be a piece of cake to do in Z80 asm. in 6502 yeah it's a bitch.

>>7780193
Why?
t. learning 6502

>>7780201
https://www.msx.org/wiki/Z80_Assembler_for_Dummies

it has a much more flexible and easy to use instruction set, and for this purpose it's a lot closer to x86 asm. 6502 asm is annoying especially when you want to do 16-bit arithmetic.

>>7780201
16 bit math is annoying in 6502, but very doable. here it is step by step. enjoy

Z80 code is more compact than 6502 and you can accomplish the same task with fewer instructions which saves you valuable memory. Mostly because you don't need 10 different zero page writes to perform 16-bit math.

>>7779383
Pick something relatively doable. Any retro machine could handle Sea Chase whereas there are other games that don't work so good on everything. We mentioned Mouse Trap? I said it might be an issue with the NES because the game expects three buttons to open and close the different doors in the maze. You could deal with one of them via an A+B button combo but it might just be easier to have only two different colored doors. Mostly because it's faster to just be able to press one button at a time than two--this is speaking from a lot of experience with NES Double Dragon where you press A+B to jump kick.

>>7779824
some of that code is MS-DOS specific, i recognize the int 21h at least. cbw you'd have to implement manually because you can only do 8 bit operations. there's no AL or AH either, only A, so that's where zero page would come in storing the 16 bit number in 2 bytes and reworking the logic to handle each byte separately. x86 has 4 general purpose registers as well, which must be nice, the 6502 only has one, the accumulator. X and Y are really just for indexing.
there are much simpler things i would try to do first before trying to translate x86 into 6502.

>>7780278
That's not an issue, I was testing the code in VICE and was just going to use the C64 kernal functions to read the keyboard and output to the screen.

>JSR $FFEF=read key
>JSR $FFD2=display character

For an Apple II or something of course you'd change this to whatever the equivalent functions there are. it's stuff like the CBW instruction that I can't figure out how to do in 6502.

>>7780292
> The cbw instruction sign-extends a byte into a word. In this case, it'll take the sign bit of AL (which happens to be 1) and copy it into every bit of AH.
So what you would do with your high byte is copy $00 or FF. Use a BMI or BPL instruction to determine which.

>>7780292
It would be something like:
LDX #$00
LDA lowByte
BPL +
DEX
+
STX highByte

XCHG is another nuisance, I suppose you could use zero page copies for that.

>>7780120
We learn by doing.

>>7780353
for memory you could:
TAX
LDA variable
STX variable
for registers you could:
STA temporary
TXA
LDX temporary
Either X or Y would work. If you don't have a register open, or want to switch between X and Y, you'd have to:
STX temporary0
STY temporary1
LDX temporary1
LDY temporary0
It's smart to reserve some temporary variables in zero page for general usage. I use var0-var7 mapped to $00-$07 personally.

>>7780276
I can think of Atari 2600 games the NES would have a hard time with.

The x86 also has a MUL and DIV instruction which 8-bit CPUs don't have?

>>7780712
Oh that's not a problem.

>LSR to divide
>ASL to multiply

Also on the 8086/88 the MUL and DIV instructions were useless as they're microcoded and incredibly slow so you end up using the old-fashioned bit shift method anyway. On the 286 they added hardware multiply and divide.

>>7780098
Thank you, anon. Going to do it for my fav NES game and also get better at both nes dev and 6502.

>>7780724
>Oh that's not a problem.
As long as you're dealing with powers of 2. In general you want to be dealing with powers of 2 anyway, it lets you do fancy bit tricks.

yes the Z80 is a lot better with 16-bit registers an XCHG instruction and block copy instructions. it makes your life so much easier and saves memory since less code is needed than it takes to do something on a 6502

so anon won his bet that despite Sea Chase being a game written for a 6502 machine he'd still end up replacing 70% of the code to convert it for the NES

>>7780765
my original take wasn't that far off actually
https://desuarchive.org/vr/thread/7597758/#q7610080
doing BCD replacement code as we speak. heh.

>>7780765
when i started i was hoping that some of the collision logic was coded and it wasn't all hardware. it was all hardware. that was a fun couple weeks.

>>7780765
the style of programming will radically change on different machines even with the same CPU. for example Z80 programming on a Colecovision is very different from Z80 programming on a ZX Spectrum.

on this Lemon64 thread they say the C64 collision registers are a waste of time and to just use box bounds checking instead

Hardware collision check is a little more accurate than soft collision check but also more limiting in a lot of ways. It works with Sea Chase because the game has a simple "touch something, flag a collision" setup but on other kinds of games this is unsuitable. Nintendo clearly didn't think hardware collision registers were useful since none of their consoles ever included them.

>>7780814
>box bounds checking
i did a mix of box bounds and center point, depending on the collision. box bounds doesn't work great for circles, like mines for example.

>>7780814
i can't speak for the C64 collisions, but the atari 800 ones seem to work fine under certain conditions. i was reading that they fail or give false positives readings in certain graphics modes.

>>7780834

>>7780846
right, if you have a small bullet moving at high speed it may never overlap with a graphic that it "hits": one frame it's before and the next it's after. it might not work in something like gradius with it's fast moving bullets for example.
even so, i'd hesitate to call hardware collisions "useless". there are plenty of examples where they are far superior to bounding boxes or center point distance. no CPU time is a huge advantage.
like anything, there isn't a solid answer to "what collision type is best", it all depends on the situation.

>>7780878
>i'd hesitate to call hardware collisions "useless". there are plenty of examples where they are far superior to bounding boxes or center point distance. no CPU time is a huge advantage.
The Atari 8-bit is a little slower than the NES due to the ANTIC DMA stealing cycles (although on paper it's the same clock speed). Thus the cycle saving from h/w collision is important there while the NES has more cycles to spare for soft collision checking.

>>7780903
yeah the NES is fairly fast although there are some gotchas to this such as the large # of small sprites which take a lot of CPU time to keep track of. the C64 is slower but its smaller # of big sprites also take less CPU. and of course hardware collision checking if you use it is cheaper in CPU time. in C64 games you also typically use char sprites for bullets which also use less CPU than hardware sprites.

>>7780925
> the C64 is slower but its smaller # of big sprites also take less CPU
don't you have to multiplex those manually?

>>7780945
yeah you do, it doesn't hardware multiplex. but do note that the NES has to have this since there's no scanline IRQs.

that fan project SMB C64 port had a lot of slowdown. this was attributed to C64's slower clock sleep however the autist guy also insisted on recreating all the game logic exactly from the NES instead of adapting it in a way that would work better or be more efficient. things like Mario's fireballs could have used char sprites and saved on CPU time.

>>7780951
right, you can't multiplex or rearrange sprites at all on the NES, just DMA a page of sprites over in vBlank and call it a day. you really don't want to touch sprites at all though, OAM is cranky though and if you try to use the sprite registers to do just about anything it corrupts sprite memory in early models. good times.
fun fact, some of the earliest NES homebrew used the sprite registers, and for that reason, it fails on real hardware.

as i said, the NES's higher clock speed is offset by the CPU time needed to keep track of numerous small sprites, no h/w collision checks, and the fact that you can't access the PPU any time you feel like, there's only a small window for it each frame. slowdown is a major problem with many NES games.

>>7780975
NES has its quirks and difficulties for sure, but having the equivalent of a complete framebuffer is a huge advantage.

>>7780975
Slowdown is pretty rare on C64 games but then it seemed programmers normally tried to avoid code loops that would overflow the raster time and take multiple frames, while NES programmers much of the time seemed to not give a shit and just accepted some slowdown as the price to pay.

A big issue with many C64 games is the h/w scrolling is extremely greedy and takes up to 20% of the CPU. NES scrolling takes like 2%. Note that VSP scrolling solves this issue nicely and saves a lot of cycles, unfortunately it wasn't discovered until 1992 or something and some C64s choke on it. however most modern homebrews use VSP because it's so much more efficient.

Setting up the color RAM carefully also saves CPU time while scrolling; ideally you want to design your graphics so the color RAM doesn't have to be touched at all. for example the "action" sections in North & South are set up like this. the lower part of the screen uses all yellow and the upper part white for the set colors so it doesn't have to scroll or touch the color RAM.

>>7781014
> NES programmers much of the time seemed to not give a shit and just accepted some slowdown as the price to pay.
I blame that entirely on the programmers not giving a shit =p

>>7781014
If you look at a game like Cobra Triangle there are a ton of sprites moving around with active hitboxes all within true 8 directional scrolling and the thing doesn't slow down a bit. It can be done right. Many times, unfortunately, it wasn't.
https://www.youtube.com/watch?v=dEDwRZ85f0s

there are quite a few later period games like TMNT: The Manhattan Project where it's obvious they were trying too much for what the NES was capable of

>>7781036
it takes some fairly complex code that splits up the different code portions between the NMI and main CPU thread and most programmers had neither the time or the motivation to bother with that, they'd just put everything in the NMI or main thread at once and it would cause slowdown. Cobra Triangle was a Rare game and these guys were insane code wizards who did things that Japanese coders never thought to try.

also helping this game was Rare's OC donut steal AxROM setup and its single screen mirroring which made 8 way scrolling much easier.

>>7779630
I will be honest with you, I have no idea what Im doing or why that would be a problem.
I tried turning rom into bitmap to see if there are any patterns that may be something akin to a sprite and to be honest there maybe are few?
At least there are some visually different parts and that probably means something.
>game that has 3D polys
that should actually make things easier, I think, the only sprites being the sky sprites and maybe road, all other shit being just colored vertices.
Now, the question is HOW said sky sprite data is stored inside the rom file, if its just a bitmap it may be one of distinct fields in pic related and I just need to find the right width to arrange the string of data into a picture. Tedious, but doable.
If its some other format, thats much more difficult if there are no headers to recognize, and there probably would be none.

bump

>>7781014
Also VSP is strictly for horizontal scrolling. There's a similar trick for vertical scrolling known as line crunching. But ask on Lemon64 about that.

I've been doing my second playthrough of Symphony of the Night with the quality + hard type hacks and holy fuck the hippogriph was an absolute slog, I spent 80 hearts worth of holy water and I still had to hack at for several minutes straight with only 10-20 damage per hit. Does hard type buff the health of any bosses significantly or was I just under equipped?

>>7779590
They can't do shit to you, the Pokemon disassembles remain online don't they?

>>7779590
> Reverse engineering seems like a giant gray area.
It's not. 100% legal. Proven time and time again in court. In the US at least.

>>7782540
yeah yeah this stuff was ruled on and found legal years and years ago even though Nintendo's website has a legal FAQ that still lies and claims it isn't

>>7779590
If a company really felt motivated they could go after you for graphics assets, which is why the SMB decompilation doesn't come with the CHR part, for example. Code is absolutely fine though.

>>7782546
>Nintendo's website has a legal FAQ that still lies and claims it isn't
well of course they do. companies pull this shit all the time. those "warranty void if sticker removed" for opening devices aren't legal either, but you see them all the time.

back in the day Nintendo also claim the Game Genie was illegal. a court ruled it wasn't but they were still extremely butthurt and refused to acknowledge the thing even though Sega endorsed them and made them an officially supported device.

>Mega Man 4
>512k ROM+CHR RAM
>Mega Man 5
>256k ROM+256k CHR ROM
>Mega Man 6
>512k ROM+CHR RAM

the later NES Mega Mans are all basically the same engine with a reskin. dunno why 5 inexplicably switched to a CHR ROM setup like that.

>>7782671
> the later NES Mega Mans are all basically the same engine
i thought so too, but an anon who knows his shit said they are actually very different internally

>>7782671
I believe Capcom and Sammy were the only devs to use MMC3 with CHR RAM.

Thread needs to be remade and have the Spectrum and Amiga links removed at once.

>>7782852
troll op fuckin sucks

>>7782608
>>7783786
I'd assume they used an FPGA implementation of MMC1. For a small cartridge run it's probably doable at a reasonable cost. Having said that, it'd be better to just use MMC3 unless you really need MMC1's single screen mirroring option.

>>7781014
LOL kid born in the late 90s thinks he can program retro machines after reading one Wikipedia page. How cute.

I think I have this worked out. Also it took 121 bytes of code to do this in 6502 asm while the original x86 code was 82 bytes.

>>7782852
>we should remove legitimate links about developing for retro machines
...

>>7784238
well no but the douchebag removed the SNES and DS links to put those there and keeps making the thread before the old one is dead. the fuck can i do about it?

>>7784223
nice going man. the 8086 costed hundreds of dollars when the 6502 costed tens of dollars. what do you expect =p
the only thing i'd consider is doing everything in little endian (LB then HB). it might look backwards, but pointers and relative jumps work that way, and it would make your routine more useful.

>>7784325
Good. He ought to remove the other Nintendo links and replace them with more worthwhile platforms as well, while he's at it.

>>7784223
however a lot of the early PC games from the CGA era are over twice the size of their C64 equivalent, for example I remember that Boulder Dash was around 45-50k on the PC while it was about 25k on C64. i think that's more got to do with the bitmapped graphics data taking more space than C64's YY-CHR graphics. in fact Apple II games are also larger most of the time than C64 ones despite same CPU as the Apple II also has bitmap graphics.

>>7784385
i hate that fuckbag. what the fuck is that picture even of anyway? sure don't look like anything that runs on a classic console. the last picture was of shovel knight which is a commercial game for modern platforms. i'm glad someone else is making the thread but he doesn't even know what homebrew is and is only making the thread to be a dickbag. oh well. you win some you lose some.

btw NES graphics being offloaded to the separate CHR ROM was quite useful as 6502 code has a larger memory footprint than Z80 code so the space saving in the PRG ROM from not having to store the graphics in there is important.

>>7784436
There are advantages, but, most carts didn't even use more than half of the address space for ROM, only $8000-$FFFF. You can't address the PPU memory directly, only through registers, and mostly in vBlank.
I don't think bankswitching or CHR RAM were even considered when they were drawing up the Famicom in 1983, but in retrospect they worked quite nicely with how the system ended up being arranged.

>>7784436
>6502 code has a larger memory footprint
true but most of your ROM ends up being data anyway, so it's not all that important. i'd sure like some of those Z80 features though.

>>7784450
they started with 16k ROMs on the very early Famicom games and not having to put the graphics in there was important for space saving. figure if you had 2-3k worth of graphics then all the space saved in the PRG ROM could be used for music or other content.

in addition to that, the graphics are already immediately in place and accessible to the PPU at power on and you don't need to include a copy routine to move them into video memory like you do on the Colecovision, so that also saves some space.

>>7784483
> not having to put the graphics in there was important for space saving.
it was and it worked out well, but i'll bet it was to cheap out on not having VRAM to store graphics. i reallllllly wish they would have just at least put 4k in CPU RAM, 2k is fuckin tight. 4k for 4 native nametables would have been great as well.

>>7784385
>replace them with more worthwhile platforms as well
Time to remove Spectrum and Amiga too.

IDK, Jumpman Jr. was on a 16k cartridge and is quite densely packed, it has at least as much content as any of the early Famicom titles. And that's with the graphics having to also fit in that 16k space.

>>7784521
The Amiga is wholly 3x faster than the SNES. The ZX Spectrum is wholly 2x faster than the NES. Both are capable of vastly more than their stock Nintendo counterparts, without relying on cheating, expensive, and complicated expansion chips.

>>7784521
The only homebrew project /vr/ successfully completed was for the Spectrum, so...meh.

>>7784545
The Spectrum isn't really faster as Z80 code takes longer to execute than 6502 code. It does have more brute CPU power though which makes up a little for the lack of hardware sprites and scrolling.

>>7784556
The Z80 is able to load 16-bit indexed in 16 clock cycles with one instruction, which the 6502 needs multiple instructions for. The Z80 is able to perform 16-bit addition in 11 clock cycles with one instruction. These both leave the 6502 in the dust, performing the operations more easily ("brute CPU power") and much faster at the 2x clock speed. The only "megahertz myth" here is that the NES can somehow magically keep up despite being half the speed with a more clunky and inefficient CPU architecture.

>>7784547
i don't want to remove those links, i just want the SNES and DS links to be back up there, and the picture that adorns the homebrew and romhack general thread to ACTUALLY BE HOMEBREW OR A ROMHACK. is that so much to fuckin ask? jesus.

>>7784575
Most 6502 machines rely heavily on custom chips to do the heavy lifting. In the late 70s it did have a performance/price advantage as early Z80s were only 2Mhz and eg. the Atari 2600 wouldn't have been possible with a Z80 at all. By 1980, the price of Z80s was dropping and they had faster units--eventually up to 8Mhz while there was never any 6502 faster than 2Mhz. As one other kicker, the Z80 had on-chip DRAM refresh which made it cheap to build a computer around.

I believe the OP pic is some kind of Mega Drive sprite/scrolling demo/test someone wrote. At least that's what reverse image search tells me.

>>7784590
> there was never any 6502 faster than 2Mhz
it was replaced by the 65C02 which is socket and byte compatible with all legal opcodes with the original. It ran at 4MhZ initially and got faster, you can still buy new ones. it powers the commemer x16
https://en.wikipedia.org/wiki/WDC_65C02

>>7784604
oh nevermind then. carry on.

Nintendo used the 6502 in the NES because it was cheap and easier to integrate the sound hardware onto and even then they still had to remove the BCD mode for legal reasons. A Z80 would have been much better but they couldn't sell it at the price point they wanted (originally only 66 USD).

>>7784492
of course you still have to set the tile map up before you can display anything

yes