/vr/ - Retro Games

>>6959742
There wasn't time to do that and you'd have to scrap it all and start over once you started in ASM anyway.

Many games would use existing code from previous game by the same publisher as a base for some of the bases. See for instance Capcom's sound engine, or at Konami how similar TMNT is to Getsu Fuma Den and how similar The Lone Ranger is to both Getsu Fuma Den and Castlevania.

This is when the dev team concept became a thing so communication was important. Typically games would start as a design document. The lead designer would lay out everything the game needed. Level layouts and art assets would be physically drawn on graph paper. The programmers would implement that in-game. They typically would have known in advance what kinds of tech they needed and the mappers used would have either been designed in-house or have accompanying documentation.

The console's commercial lifespan lasted an entire decade and development tools will have changed considerably over that time. In the early days they would have used a minicomputer and a 6502 cross assembler. Graphics were plotted out on graph paper and converted to hex values by hand. In the late period of 1990-93 code and graphics could be done on a PC or Amiga.

Early games like Ice Climber were simple and one guy could do most of the work. Later AAA games had multiple people working on them.

There were no actual emulators for consoles back then, the most you'd have was a CPU emulator. You had to know what you were doing and be sure your code would actually work because the only way to get it onto the console was by burning ROMs which could only be used once and cost money. If you fucked something up, that was a wasted chip. This was a problem you didn't have writing computer software, because that was on magnetic media so if you made a mistake and your code crashed, you could just rewrite and fix it.

NES games were also heavily influenced by the cartridge hardware. They would have to decide what they needed and this depended on the time period (remember, the thing was out for 10 years) and what the developer was willing to spend.

>>6959868
They would probably use erasable EEPROMs during development, not mask rom.

>>6959742
If you look around on YouTube you can find some old video of Japanese developers working on NES games in their studio, you can see sprite art and shit on the computers and people coding. I can't remember what dev it was specifically, either Enix or Nintendo I think

>>6959742
> overall workflow
IDE's as we think of them today were non-existant. Much of the work was done by hand. I've seen graphics and level design were done with graphing paper and the hex values manually punched in.
> erasable EEPROMs
Didn't exist yet. They would have a prototype board, burn a permanant chip, and swap it in.
> did developers first prototype games in C
No. Impractical with 80s hardware.
> NES's very low hardware specifications
It was quite contemporary until Intel went nuts.

is it true Konami not use VRC2 in US Contra because Nintendo wouldn't let them?

>>6960908
Yes. Early on, Nintendo tried to cut costs in the west: They cut the traces for the sound expansion pins, and only allowed their own mapper chips. Later on (90s) they gave less of AF.

>>6960908
It is a commonly stated myth that Nintendo did not allow third party mappers in US cartridges. This is a half-truth. In Japan, most of the big arcade manufacturers such as Konami and Sunsoft made their own Famicom PCBs. Developers such as Hudson or Square who didn't have access to in-house manufacturing facilities relied on Nintendo to make cartridges for them.

For US NES cartridges, manufacturers could also make their own PCBs but the rules were slightly more strict than in Japan in that the PCB had to include the lockout chip and actual ROM chips (epoxy ROMs weren't allowed in US cartridges). Also they had to use the standard gray NES cartridge shell while in Japan every manufacturer had their own shells. So in the end, nobody bothered with that but Acclaim and Konami. Now I've never heard anything about Nintendo explicitly disallowing third party mappers, so manufacturers most likely didn't bother with it for cost reasons. Konami likely just didn't consider it worth the expense of adapting the VRC2 to a US-spec PCB.

>>6960916
>They cut the traces for the sound expansion pins
They didn't. The sound expansion pins were moved to the expansion slot on the bottom of the console.

British developers repurposed their speccy tools for NES dev.

>>6960945
> It is a commonly stated myth that Nintendo did not allow third party mappers in US cartridges.
Interesting. I thought third party mappers were straight up banned until the 90s. I guess that's what you get for learning things on the internet.

>>6960945
>and actual ROM chips (epoxy ROMs weren't allowed in US cartridges)

Mostly. SMB/Duck Hunt carts are often epoxy ROMs.

>>6959742
Who is they?
>i know
Why do know nothing zoomies constantly insist on saying "i know"? You obviously know nothing and saying "i know" just makes it look like you somehow know less than that.

>>6961634
He's right though

>>6961634
take your meds, schizo

>>6960848
>Didn't exist yet. They would have a prototype board, burn a permanant chip, and swap it in.
Pretty sure EPROM is from the 70's and EEPROM is from the 80's. I don't know if they were commonly used for console dev at the time, but they were available.

>>6959868
>NES games were also heavily influenced by the cartridge hardware. They would have to decide what they needed and this depended on the time period (remember, the thing was out for 10 years) and what the developer was willing to spend.

This is one of the big headaches of NES homebrew development. The guy who coded What Remains said the overall hardest part of the game was dealing with bank switching.

>>6961724
Hmm, you're right. I don't think it wasn't used back then. EEPROM wasn't really utilized until the 90s. Perhaps it was prohibitively expensive or unreliable.

i think they had those oldskool EEPROMs with the window in them and you had to expose it to UV light to erase the contents of the chip

>>6961650
>i'm right though
No you're not. You're a dumb kid who watched or read some shit, probably made by another dumb kid and came down with a terminal case of dunning-kruger. You could find plenty of NES games not written "entirely in 6502 Assembly", if you knew how to google, and weren't convinced you were already an expert on the subject you're asking basic questions about. Even if I wanted to help you I couldn't. Your little zoomie brain is too broken.

>>6962001
>No you're not. You're a dumb kid who watched or read some shit, probably made by another dumb kid and came down with a terminal case of dunning-kruger. You could find plenty of NES games not written "entirely in 6502 Assembly", if you knew how to google, and weren't convinced you were already an expert on the subject you're asking basic questions about. Even if I wanted to help you I couldn't. Your little zoomie brain is too broken.

>>6962001
> You could find plenty of NES games not written "entirely in 6502 Assembly"
Actually no, you can't. Up until N64/PS1 most games were ASM: Like 99% of them. Sonic Spinball and Marble Madness come to mind as games written in C. Many modern homebrew games are written in C as well. I don't think any were in Pascal or anything else.

Some 4th gen RPGs are written in C, for example I'm pretty sure Chrono Trigger and FF6 were, but they didn't really need to be that fast.

>>6962043
if Nasir worked on FF6 (too lazy to google), it was likely 100% assembly. That guy is like Rainman, though

>>6959742
Just get NES maker if you want to make Nintendo games

>>6962057
> NES maker
or wait a few months....

Wanna make an actual NES game? Lrn2 6502 asm and how mappers work. Also enjoy the infinitely superior tools you have now, the ability to use any mapper or ROM size you want, the ability to test code on emulators, and no concessions to commerciality or Nintendo content censorship.

>>6962070
I just got NES maker its easy to make games on

Im not doing anything ground breaking but its fun to add music and backgrounds not normally found on a NES game

>>6962168
yeah nobody can stop you from showing bobs and bagine or saying "fuck" in a game now

>>6962042
>i don't know how to google so i cant
That's what I said zoomie. Ask your grandad to help you with google.

>>6962242
Don't hit reply just because you see a (you).

>>6962168
This. The NES hardware developers intended you code for bare metal. You can't really say you MADE a NES game if you let a compiler do your work for you.

>>6962242
i'm good thanks anyway

the preferred way was for some suits who hated video games to scribble random nonsense and crude drawings about some IP they acquired the rights to on a napkin and mail it to Japan and let them figure the little details out

>>6962276
That must have been how LJN games were made.

>>6962247
ok

>>6962168
The NES is not complicated to code for; there's only something like 30 main registers but stuff is very timing sensitive since your code loop has to be wrapped around the vblank, the PPU color attribute system is not very nice to work with, and memory space is tight. 40k of ROM space and 2k of RAM is all you have and anything more than a simplistic arcade game needs a mapper and that adds a lot more complexity.

>design game
>program game
>playtest game
>"lol it sucks"
>release it anyways

done

>>6962420
you forgot the most important part
>profit

>>6962387
> The NES is not complicated to code for
Disagree. It's convoluted. The hardware is full of strange quirks. Want to read the controller? Poll it 8 times. Want to update video ram? First you load a 16 bit pointer into a flip-flop register and then write to another register that will subsequently increment by 1 or 32 bytes. Want to produce a tone? Write a 16 bit number that divides the oscillator frequency of 1.789773MHz to the closest musical note. Want to play a sound sample? Heh. Have fun with that...
> wrapped around the vblank
Not a problem. NMI will interrupt right at scanline 241 when that happens.
> 2k of RAM
You can have 10k with an additional chip.

>>6959742
a dialect of hubasic was used by nintendo not assembly

>>6962459
No. This is not true. A version of Basic was released by Hudson Soft for the Famicom, with a keyboard, but it was certainly not used in first party games, or any games that i know of.

>>6962420
>design game
>program game
>playtest game
>"lol it sucks"
>cancel game
>40 years later some autist buys the prototype cartridge for $150,000 USD and acts like it's a defining piece of video game history

>>6962463
family basic was a stripped down version of what nintendo used for the early games
as time went on they used NEC systems for development
HAL actually used Family BASIC to develop Kirby games, but I don't know if that was the Game Boy games or Kirby's Adventure

>>6962507
>HAL actually used Family BASIC to develop Kirby games, but I don't know if that was the Game Boy games or Kirby's Adventure

assuming that's even true since I can't be bothered to look it up, I think you're confusing having a scripting engine embedded in a game engine with a game engine being "developed in" a scripting language. you can't really write BASIC that directly interfaces with the hardware in the way that's necessary to write the low level parts of any embedded program including NES games. so basically you have a bunch of assembly modules that implement all the real work and a scripting engine that lets you call on routines written in assembly

>>6962438
>want to read 8 serial bits?
>read a bit 8 times
>want to write to video ram quicker?
>tell the ppu what you want it to do
>want to be able to play more than 256 frequencies?
>use 16 bits
You should be on that "kids react" show

>>6962507
>family basic was a stripped down version of what nintendo used for the early game
I am all but 100% sure this is not true in any way whatsoever. Source?

>>6962534
I RTFM'd the Kim-1 manual and the NESdev wiki for months before any of this made a lick of gaddamn sense to me. 80s hardware is a fuckin trip. I did webdev and flash games before this. I think i'm a man now.

>>6962545
>the Kim-1 manual
Ah. That explains everything. You started off being so retarded you thought learning to program in 6502 machine code would be a good idea and by the time you were done reading a whole box of manuals (it came with at least half a dozen) your brain was so fried it had all kind of melted into a distorted impression of how Munch would paint a book.
You should have just asked, bro. "The First Book of KIM" is probably the single best resource to learn 6502 ML. And you gotta program in 6502 ML, on a hex keypad. Anything less and you're just an assembly language larper. You're not a little girlie boy assembly language larper are you?

>>6962750
>You should have just asked, bro
But whenever anybody asks you act like an asshole

>>6962758
>act

>>6962539
half-remembered junk from reading up on the famicom development environment in the late 90s
hudson had an interesting relationship with both sharp and nintendo and I think it's part of why sharp was able to make their own famicom stuff

>>6962387
2k of RAM is enough for most games. An extra cartridge RAM chip is really only needed for save games or when you want to have maps with a destructable environment like in SMB3.

>>6962438
>First you load a 16 bit pointer into a flip-flop register and then write to another register that will subsequently increment by 1 or 32 bytes

Aside from which the video RAM and PPU registers cannot be accessed while the screen rendering is in progress. It's a lot nicer on the Master System where you can access the VDU during the rendering, although at a slower speed.

>>6962387
And no IRQs without an MMC3 or other later advanced mappers, just a hax trick that uses up one sprite.

Don't forget also that the sprites are tiny and can only cover 64 pixels of screen width without going over the scanline limit at which point the PPU will simply stop rendering them.

>>6961973
Arkanoid is a CNROM game so there's just one PRG bank and two CHR banks. Likely in order to fit the intro, they'd need a larger CHR ROM to fit an additional bank of graphics data and the extra expense couldn't be justified for this one feature.

>>6962420
at least they playtested the things. with ZX Spectrum games I don't think that was even done at all half the time.

>>6963473
Nintendo would have required games to be completed and the player could finish them. They had to at least have no game breaking bugs like happened in the Atari 7800 Impossible Mission. Granted, a game could still be a horribly programmed hunk of shit like every Micronics game ever, but as long as it could be played all the way to the end and beaten by the player then it was enough to pass.

>>6959742
>considering Assembly requires so much more concentration and focus and it's easier to completely mess things up and overlook tiny but crucial details

OP confirmed for retarded zoomer. The 6502 isn't some mystical black box where you write incantations and hope for the best, it's a computer like any other and processes instructions that you give it. If you're not a complete fucking retard you can follow basic OOP principles, the difference is that the IDE isn't there to handhold you. See:
http://c64os.com/post/objectorientation

>>6962545
>I RTFM'd the Kim-1 manual and the NESdev wiki for months before any of this made a lick of gaddamn sense to me. 80s hardware is a fuckin trip. I did webdev and flash games before this. I think i'm a man now.

have you tried on the Atari 2600 where you don't have video RAM at all and your code loop has to redraw the graphics each frame.

>>6963492
Wasn't Battletoads unbeatable with two players?

>>6962387
>and memory space is tight. 40k of ROM space and 2k of RAM is all you have and anything more than a simplistic arcade game needs a mapper and that adds a lot more complexity.

Banking can get tricky because you often have to waste space with duplicate copies of the game engine in different banks and switching them means you need to make sure you "jump" into the next code bank correctly and not crash.

so I've been considering we do a NES homebrew project, probably a port of something. what games would be a good project to undertake that don't have a NES port?

>>6963727
Even a relatively small game will be a lot of work. What were you wanting to do exactly?

Try a simple game like Squish 'Em. It's only 8k.

>>6963727
Custer's Revenge

>>6963796
For that you'd still have to:

>disassemble the game and figure out how everything works
>maybe be able to reuse AI code since is C64 game and same CPU
>completely redraw all graphics for the NES
>recode all sound, graphics, and I/O code
>since it uses split screen scrolling probably also fuck with Sprite 0 hit bullshit

>>6963814
but at least with only 8k there's not a whole lot to figure out

>>6963828
http://www.gb64.com/game.php?id=7286

Actually 7k.

>>6962312

an NES port of Jr. Pac-Man. that'd be great.

>>6963857
Yeah but that's a much bigger more complex game. Can that work in NROM or do we need a mapper?

>>6963871
how complicated can a Pac-Man game be? Neither of the two ports of Ms. Pac-Man on the NES used a mapper IIRC.

>>6963887
Actually it's more the intermission screens. If you don't use a mapper then you can only have 256 bg tiles.

come on, dude. this is all there is of the graphics in Jr. Pac-Man. you absolutely do not need a mapper for this and it can fit in NROM.

>>6963906
You'd probably use at least four sprites for each character because you probably want 16x16 ones, but then the NES can flip sprites anyway so there's no need for separate about faces for everything. Looking at this I'm fairly sure it would fit in a single CHR table and some stuff could just be recycled with palette swaps.

As for the bg graphics, the mazes just use the same couple of tiles, that wouldn't take much space. Maybe you could do away with the separate text fonts for the in-game screens and attract mode/intermissions if you run out of space in the CHR table.

wait a minute why we discussing Jr. Pac-Man? i thought we were doing Squish 'Em.

>>6963936
>>6963906
And now you know what conversations ensued when NES games were developed back in the day. lot of debate over how they could do something and what resources/cartridge hardware would be needed to do it.

Once you've established that the game is small enough to not need banking, that does make your life considerably easier.

>>6963936
And of course disassemble the arcade ROM to find out how it works and recode everything from scratch as the arcade game uses a Z80.

that's why i said Squish 'Em would be easier

>>6963814
>since it uses split screen scrolling probably also fuck with Sprite 0 hit bullshit

You can also use sprites for a floating score counter if you don't want to do that.

>>6962750
>assembly language larper
ASM6F is a godsend. One of us is a larper, and it ain't me.
> Atari 2600 where you don't have video RAM
It's pretty insane. You have to constantly reposition 5 sprites to make things, only 2 of which aren't 1 pixel long. At least you can clone or stretch them i guess. 128 bytes of all-purpose RAM is ridiculous: I don't know how they did anything.
The NES at least has some video RAM and lets you run code while the video chip is drawing the screen. 2600 is the opposite: run your logic in vBlank, and then manually draw the screen.

>>6959742
Programmers really knew what they were doing and could make their own dev tools and refactor code when needed.

>>6959742
They wrote assembly. They used a text editor. They wrote it on pieces of paper. Sticks and stones and reeds.

>>6962750
>assembly language larper
ASM6F is a godsend. One of us is a larper, and it ain't me.
> Atari 2600 where you don't have video RAM
>>6963534
It's pretty insane. You have to constantly reposition 5 sprites to make things, only 2 of which aren't 1 pixel long. At least you can clone or stretch them i guess. 128 bytes of all-purpose RAM is ridiculous: I don't know how they did anything.
The NES at least has some video RAM and lets you run code while the video chip is drawing the screen. 2600 is the opposite: run your logic in vBlank, and then manually draw the screen.
>>6963286
> half-remembered junk from reading up on the famicom development environment in the late 90s
I don't think Basic was used by Nintendo in first party games in any way shape or form. It doesn't sound feasible. I have never read anything about it. I'd be happy to read any info you have on that.

>>6964268
128 bytes is adequate for the typical 2600 game. Some carts had extra RAM in them if they needed more work space.

http://www.classic-games.com/atari2600/bankswitch.html

>2600 is the opposite: run your logic in vBlank, and then manually draw the screen.
However one extremely neat aspect of the 2600 is that games have no input lag since the processing and rendering take place within the same frame. On all other consoles, it takes two frames.

>spend the active rendering phase preparing the next frame of animation
>the frame following that, you read the controller input

The result is that there's a one frame lag between pressing the button on the controller and the game engine responding to it.

David Crane loved the 2600 and the challenge of coding on it. He said the C64 was boring, easy, and not as much fun.

>>6964326
> David Crane
I love his GDC 2011 Pitfall talk.
https://www.youtube.com/watch?v=tfAnxaWiSeE

Pitfall II also used enhancement cartridge chips, it was like an NES with an MMC5. The stock 2600 hardware couldn't do that.

>>6959742
>How did they develop NES games?
the japs used a few things: pc8001, pc88, pc98, hp workstations.
>>6959742
> did developers first prototype games
nes always used assembler. developers used special kit with programmable RAM that acted as ROM or they wrote directly to an eeprom. tedious shit. not sure they even had hardware simulators for real time debugging.

>>6960848
>Didn't exist yet. They would have a prototype board, burn a permanant chip, and swap it in.
eeproms came out in the 1970s

>>6964364
>nes always used assembler
Once in a while some adventure game would use a scripting engine; I believe Koei's did and Maniac Mansion definitely did, that was not written in assembly language--it used a variant of the SCUMM engine with NES libraries.

>>6964375
> Koei
This is true. Supposedly if you DIF roms on different systems, some data is identical. People have done work disassembling this scripting engine, but it has never been completely dissected, to my knowledge.
http://forums.nesdev.com/viewtopic.php?f=2&t=15931

In the later years of the NES games would be written on a PC or Amiga and tools like DeluxePaint used for the graphics. Dev tools came a long way during 10 years on the market.

>>6964375
> scripting
yes. but what do you think those engines were coded with? they were written in assembler. some poor negro had to sit there and count cpu cycles and conform to hardware specs.
> nes libraries
there are no libraries. everyone had to code everything themselves from scratch. nobody shared code unless it was licensed or disassembled & stolen.

>>6964407
dpaint is still being used for things in 2020. it's just that great.

>>6964409
>there are no libraries. everyone had to code everything themselves from scratch. nobody shared code
This isn't entirely true. Games from the same company did share portions of code. Capcom's music engine, for example, is the same throughout many different games.

>>6964420
Isn't that because they developed their own qsound technology

I believe Uemuri or somebody talked about how in the beginning days of the Famicom in 83-84 they had a gadget like a Lite Bright to plot out sprites with.

>>6964429
> qsound
The NES is mono. That isn't related.

>>6962052
>Nasir
I always remembered seeing "Coded by Nasir" on the Secret Of Mana but never gave it much thought (even though I do a bit of coding as hobby). Then on seeing this thread I Googled it - sounds like a legend.

>>6962387
32k of code space is small. when the console came out in the early 80s it probably seemed big enough since most games then were 16k or less.

>>6964625
the Colecovision could support 32k but all of its games were 8k or 16k

>>6964631
The Famicom's 32k ceiling was quickly hit during 1985. The CV however was dropped in 85 after the video game crash caused sales to plunge, so it didn't live long enough to get any 32k stuff. But it was outdated hardware anyway and couldn't have competed with the Famicom/NES had it lasted longer. Its Sega doppelganger certainly couldn't which is why Sega hastily replaced it with the Mark III.

>>6964639
Coleco wasn't a video game company, they were a toy company and like Mattel they opportunistically jumped on the video game bandwagon but didn't have the desire or motivation to stick with it when sales fell off in 83-84 especially when they found that Cabbage Patch Kids were vastly cheaper and more profitable.

Nobody ever really did figure out how the NES lockout chip works; all Flash carts use a clone of the Tengen Rabbit, not the 10NES.

>>6964647
To be fair, Nintendo was also a toy company that jumped on the video game bandwagon.

>>6964736
also really, use a Flash cart to play unlicensed games (if you actually want to experience Color Dreams games and that's a big "if") because those lockout zappers are really not very good for the console and only Tengen carts are safe and can't damage anything since they have a clone lockout chip instead of a zapper.

>>6964296
The "assembly language larper" thing is a /vr/ meme. I wasn't actually saying you're a larper. But your reaction and thinking that name dropping an assembler proves you're not makes me question my original opinion.

>>6964756
>You're not a little girlie boy assembly language larper are you?
$2x yourself

Sort of offtopic but I felt like this question didn't really warrant its own thread. Posted in another NES thread but it's dead.

Anyone familiar with these chinkshit Everdrive clones? Works okay for the most part but a few games behave very oddly like Bugs Bunny Crazy Castle (reserve your judgment I liked it when I was little), and games with custom chips/mappers like Gimmick have glitchy graphics and missing sound effects which probably can't be helped.

Will stock Everdrive firmware updates work for these things? Or is there a different firmware I can use? I wanted to check in before I ended up bricking it.

>>6964781
Bugs Bunny Crazy Castle is a very vanilla MMC1 game, I don't see why that would have problems. As for Mr. Gimmick, that would glitch if you tried to play the Famicom ROM on a PAL NES or the PAL release on an NTSC NES. Also if you're playing the former, there's missing SFX because obviously the toaster NES has no connector for the external cartridge audio.

>>6964809
I suspect I just got a shitty rom for Bugs Bunny, and I've heard newer firmware revisions have mappers that fix Gimmick but I'm still worried about fucking it up if I'm not careful.

http://krikzz.com/forum/index.php?topic=3245.msg31920#msg31920

it appears that the Sunsoft 5B is properly emulated on the latest Everdrive firmware revision, although a stock unmodified toaster NES obviously still can't produce the expansion audio.

>>6964756

uh...just what exactly odd things does Bugs Bunny do and does it also do it on an emulator?

>>6964845
Enemies all stop, collision detection's fucked, kind of hard to explain. I went ahead and replaced the ROM with one that works though.

>>6964831
Thank you, anon. Looks like the tinyupload link is dead though.

>>6963727
>>6963796
yeah best to start with NROM and not worry about mappers just yet

>>6962070
what the hell is this?

>>6964987
a thing that exists on my hard drive

>>6963727
https://www.youtube.com/watch?v=V7XEmf02zEM

I'd love a port of Centipede. The arcade ROM is only 12k in size and it uses a 6502 which makes the job much easier.

>>6965029
tried out the C64 version on VICE. man I hate shmups. my thumb was about ready to fall off after 2 levels.

>>6965029
Some of that is probably taken with the self-test/diagnostic screen. The actual working game code probably not more than 8k.

>>6959742
>How did they develop NES games

on a computer connected to a prototype/debugging cartridge connected to a NES

Where can you get a copy of NESmaker?

>>6959802

isnt metroid and kid icarus the same engine, for example?

>>6965304
Yes it is.

>>6964835
>; NES sound testing program
>; Written by SnowBro <kentmhan@online.no>
>inst_text0 .db "DPAD", 074h, 0ffh, 0ffh, 0ffh, "SELECT", 0ffh, "BIT"
>
>inst_text1 .db "A", 074h, 0ffh, 0ffh, 0ffh, 0ffh, 0ffh, 0ffh, "TOGGLE", 0ffh, "BIT"
>
>inst_text2 .db "B", 074h, 0ffh, 0ffh, 0ffh, 0ffh, 0ffh, 0ffh, "TOGGLE", 0ffh, "UPDATE"
>
>inst_text3 .db "SELECT", 074h, 0ffh, "SWITCH", 0ffh, "CHANNEL"
>
>inst_text4 .db "START", 074h, 0ffh, 0ffh, "UPDATE", 0ffh, "REGISTERS"
You're right. I did catch you. You just changed some text in a program some other dude wrote. Not a single assembly instruction written. How embarrassing.
Again, I wasn't actually calling you a larper. You've proved that all on your own. No doubt you'll come back with a few lines of code changed in another file you downloaded. But there's really nothing you can do to redeem yourself at this point.

>>6965529
The original doesn't have the bottom text. The original doesn't display the register values. The original also doesn't work properly on real hardware. The original also doesn't let you toggle registers or play more than one sound channel at a time. i wrote that update.

>>6965529
> You just changed some text in a program some other dude wrote.
Namefagging: Not even once. That was not some other dude.

>>6964756
No, it's not a meme, it's one specific anon. He's currently posting in this thread, if you're interested in baiting him out.

>>6965529
>>6965602
Aaaaand another kiddo completely and utterly blown the fuck out.

>>6965831
> completely and utterly blown the fuck out.
Yeah man. You got me. You somehow found my post and accused me of ripping off my own code. At least i did something noteworthy enough for you to even find it. What have you ever done?

>>6965831
i like the part where he found my post and accused me of stealing my own code =)

>>6965896
That shit was hilarious, yes. You don't get much more BTFO than that.

>>6965540
>>6965602
>>6965896
If you weren't the one who posted >>6964835 then you aren't the one I didn't accuse of stealing code that's free to modify. Or even the one I accused of only changing some text.
If you're upset about me accusing you of only changing text then you are, by definition, that person. And you're not very good at larping.
This is an anonymous board so there's no way to know who's who unless some faggot wants to trip up. But it's been clearly established someone is larping. It's just a question of who.

>>6965826
I don't see how much better the bait could get. I'm guessing he's the larper or one of the larpers if there are more than one.

>>6965304
they both run on the 'metroidvania' engine.

>>6966130
Just admit you are retarded and we can leave it at that.

And not a single constructive post in the 8 or so in here since I went to bed last night.

>>6966616
Fuck off back to Plebbit then.

>>6966704
Why so sore, assembly language LARPer?

>>6966130
If you Dif Snowbro's original sndtest rom against the update, you'll notice a few things: He checks for the controller with NMI, exits, and uses $2002 polling to run the rest of his loop. This is failure prone and causes double input reads sometimes. I reworked all of that into NMI. He also uses the sprite OAM update registers directly: this seems to fail on console, so i switched it to updating OAM DMA from the $200 region. Those nice red and green update "lights" i wrote the logic for too using background tiles and colors.
It doesn't matter though. I like posting constructive things that are helpful to people. You should try it sometime.

>>6967052
>He also uses the sprite OAM update registers directly

AFAIK the PPU registers are supposed to be write-only but on some chip revisions they can be read from.

Activating $4014 OAM DMA is safer and faster to just do a whole page copy for all of the sprites; rather than using $2004. Definitely best practice.
I think he wrote sndtest in like the NESticle era, so, knowledge wasn't what it is today.

>>6967076
Activating $4014 OAM DMA is safer and faster to just do a whole page copy for all of the sprites; rather than using $2004. Definitely best practice.
I think he wrote sndtest in like the NESticle era, so, knowledge wasn't what it is today.

>>6967098
>whole page copy for all the sprites
You can always tell when a game does this btw, it's when there's a loooong pause between switching screens. Zelda II is notorious for it.

>>6964781
>tfw try for hours to get this fucker to work with different firmwares, mappers, etc.
>tried different SD cards as well
>noticed that jiggling it slightly in the toaster NES helps some games but others like Super Mario Bros. randomly fucking freeze before you can make progress
>tested on another console and had the same issue

The buyer's remorse is real, never again. Don't ever listen to fags on here telling you to buy your Everdrives off AliExpress. Better to take out a loan for the real thing than risk getting a fucking lemon.

>>6967160
the fuck would SMB freeze? it doesn't even use a mapper.

>>6967160
Replacing 72-pin might help a little bit but getting the cart in just the right position still doesn't help the random freezes in Super C, SMB, and other games. Just gonna stick with my Wii for playing NES games I guess.

>>6967178
I suspect it has a defective ROM chip.

http://krikzz.com/forum/index.php?topic=9775.0

>>6967052
If you're even the person I was originally talking to >>6962438 and you're the person who made the code updates to Snobros's old SNDTEST that's cool and it's a shame things out out of hand. And I'll offer you this constructive thing. When you see the word "larp" in a post here don't start shouting "I'm not a larper!" and then offer up silly proof like the name of software or simple text changes. It just makes you look like a larper, as I said in my first reply >>6964756.
If you are that person I sincerely apologize for allowing you to troll me into thinking you were a larper with your very convincing larper impersonation.
10/troll

>>6967217
Guess I'll try FW 1.16 next then.

Chink flash carts are poorly made junk. Just buy the damn real Everdrive. It's $100 but well worth it and your money isn't going to the CCP.

>>6966889
This poster has paranoid schizophrenia.

>>6967116
Like every Micronics game because the idiot who programmed all of those (yes it was mostly one retard) didn't understand how to use DMA so he just did a slow-ass block copy with a LDA $XXXX,X STA $XXXX,X loop.

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

Also in SMB2 it doesn't use the DMA so again, about 3 seconds of blank screen between screen switches.

>>6967116
>>6967370
That is a different issue. Sprite DMA occurs (usually) every frame and takes roughly 4 of the 20 scanlines of vBlank (512 CPU cyc) to copy every sprite from CPU ram to OAM ram. A copy of the entire sprite table is usually stored in $200-$2FF for easy manipulation. Here is it happening in SMB2.

>>6967408
ok so what does cause that long pause in SMB2 and Zelda II? I'm wondering if it's not some artifact of both games being converted from the FDS.

>>6967421
IDK but it may be because MMC1 writes are very slow. Any time you want to bank in something, it takes six instructions to send the MMC1 a command. Zelda II of course is MMC1 and SMB2 is MMC3 but is really just an MMC1 game that happens to use the MMC3's tile animation feature. MMC3 by itself is much faster, it takes only three instructions to switch a bank and discreet logic mappers generally only need two instructions.

>>6967446
maybe. Mega Man 1 is UNROM and there's almost no pauses there, screen switching is almost instantaneous.

>>6967283
>>6967320
lal some chink flash carts don't even have any way to update or change the firmware

>>6963906
>>6963796
>>6965029
Alright, what homebrew port do we want to take on here?

>>6963906
>>6963796
>>6965029
Alright, what port do we want to take on here? It'd just be a fun undertaking like the Zniggy project.

the Mega Drive is so much easier to code for because no fucking banking

>>6967606
is it more like doing real mode on an old PC?

>>6967615
In fact the SNES is more like that than the MD.

>16-bit registers/pointers
>64k memory segments
>separate code/data/stack segment

>>6967606
The games we were talking about would be NROM stuff and not use any banking.

>>6967558
Centipede was converted by Ed Logg but never released due to the dumb fucks at Atari learning that they accidentally sold Tramiel the rights.

>>6967641
They put out Millipede though, but I'm curious if they'd have just made a straight Centipede port or if it got padded out with dumb shit like the NES Boulder Dash because an <10k game would have been unacceptably crude by the late 80s.

>>6967653
Millipede was by HAL and not Atari. Ed Logg did a version of Millipede that was never released, however.
https://atariage.com/forums/topic/305692-existence-of-centipedemillipede-prototypes-for-the-nes/

>>6967662
Interesting how he refers to the NES bg tiles as "stamps" for some reason and makes the same observation anon did earlier that the arcade game was 6502-based which makes porting it much easier (unless of course it used the BCD mode which requires some silly rewriting for the NES).

>>6967676
> NES bg tiles as "stamps"
that's actually not a bad analogy.

it mentions this Atari port of the games would have presumably been Japan-only and used some Famicom 4-player controller add-on.

>>6967676
Most early 80s arcade games used a Z80. Atari used 6502s in theirs but I don't think anyone else did. Too bad of course the NES didn't use a Z80 as it would have made arcade ports a lot easier.

>>6967698
At that time the Famicom was Japan-only, it wasn't released in the West for a couple years (October 85 in test markets). I presume they were going to release it in the West eventually as well.

>>6967718
Some guy did a homebrew Pac-Man for the Colecovision (yes, Atari had an unreleased port from back in the day but it wasn't a source port). Pretty cake. He took the arcade code and just had to redo the sound, graphics, and controller routines, but the basic structure of the game including all ghost AI code could be preserved untouched.

>>6967728
The document is from 86 though.

>>6967728
We almost had an Atari Famicom a couple years earlier: The deal fell through and Atari sunk.

>>6967741
Atari didn't even know that the other Atari had rights to a bunch of arcade games (or home conversions), I don't think they knew that the Famciom was the NES in the West or whatever. Wikipedia tells me the nationwide release of the NES was in September 86 and the memos seem to be from between March and July 86.

https://www.youtube.com/watch?v=907oJWci2HE

The C64 has my favorite port of Centipede. If you made the game for the NES, you'd run into an annoying limitation that doesn't show up here. That being the centipede segments would have to be made with char graphics and not sprites because there's up to 12 of them so too many for the scanline limit. But due to the NES's four colors per tile limit, the centipede and mushrooms would have to share the same palette whereas here they're different colors.

>>6967786
*Shared colors per block of 4 tiles limit I mean

https://www.youtube.com/watch?v=907oJWci2HE

Here's the IBM port of Centipede. The sfx get a little annoying and I tried this on a real XT but the shooter kept drifting to the left of the screen and got stuck there, but it didn't do that on newer PCs. I wonder if the copy I had had some mod to it to be compatible with newer machines? I guess I'd have to find an original disk on Ebay or something. Also this annoys me because there's no joystick support and I'm not a fan of bashing my spacebar to death trying to play it.

But that centipede thing crawling across the title screen is so cool and no other version of the game has that. If we did this for the NES I would totally put that in there.

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

Here's the IBM port of Centipede. The sfx get a little annoying and I tried this on a real XT but the shooter kept drifting to the left of the screen and got stuck there, but it didn't do that on newer PCs. I wonder if the copy I had had some mod to it to be compatible with newer machines? I guess I'd have to find an original disk on Ebay or something. Also this annoys me because there's no joystick support and I'm not a fan of bashing my spacebar to death trying to play it.

But that centipede thing crawling across the title screen is so cool and no other version of the game has that. If we did this for the NES I would totally put that in there.

https://www.youtube.com/watch?v=b-TZ3j--r1w

The Everdrive compatibility list suggests this uses an as-yet unsupported Bandai mapper, although since the game doesn't seem to have been translated yet it's kind of a moot point.

>>6967217
>>6967283
Holy fuck anon I think that actually worked. Not seeing any of the same problems I did earlier so far. I can't thank you enough!

hey if it was just incompatible firmware and your chink Everdrive works without exploding or setting your NES on fire, then...good I guess. it saved you some money over what what's-his-face charges for them.

>>6968151
That's how I feel.

Should work with anything but Taiwanese multicart mappers and maybe 1-2 other oddball things.

>>6968202
I'm thinking about buying one but I don't understand this stuff at all. Does this mean it's just emulation? Any good games that necessitate the pro?

>>6968251
It's a list of mappers the Everdrive supports. Most unsupported mappers are just ones used by chink pirate carts so they're not very important. And one or two other unemulatable things such as Bandai's Karaoke Studio.

And of course Moero!! Pro Yakyuu, the FC version of Bases Loaded. The game itself will play, but the mapper chip had sampled sound chips burned into it and there's no way to emulate this so you won't hear them.

>>6961653
yeah what kind of a lunatic would post cat pictures. Likely the kind of schizo that thinks there are more than two genders. Just madness.

Also beware that some Famicom games also require obscure peripherals to work, eg. the Datach Bar Code Reader.

https://en.wikipedia.org/wiki/Datach

>>6968302
so the pro isn't necessary for me to enjoy all the decent north american releases?
I might just go with wii in the end anyway, however I was entirely dissatisfied with snes emulation on it. hopefully wii is better

>>6968345
for nes I mean

http://nerdlypleasures.blogspot.com/2015/07/the-famicom-microphone-obscure.html

Also a few games can use the Famicom controller microphone. Take note of these since you can't use that feature on a NES.

>>6968313
Sound clips I mean. Yeah it has its own speech synthesis thing and doesn't use the standard PCM channel.

>>6968345
All licensed US NES games will work perfectly fine. But if you're gonna spend money on a Flash cart only to play those and not obscure Famicom RPGs, you're freaking nuts.

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

>>6968375
I read that Grand Master has a bug where it crashes in the final dungeon/palace if you fall into a pit.

>>6964819
as a general rule, you don't update chink shit. it's not warrantied in any way and it could brick it.

>>6968483

>>6968138
Except he did just that, so...

i wrote a small game for the nes where you just dodge blocks. it was tough but you build up tools and standards quick. the likes of capcom and konami are impressive, but they had some sick internal tools i'm sure. either way, scrolling games are 10x harder than single screen games which is why so many of them suck on the nes.

>>6968501
>the likes of capcom and konami are impressive, but they had some sick internal tools i'm sure.
lyl no the tools they had back then were laughably primitive by modern standards. Capcom would have killed to have something like Famitracker.

>>6968375
Just tried this game w translation, it's fun, thx anon

>>6968582
damn I love the music in that thing

>>6964809
https://www.youtube.com/watch?v=lC7FFkgtKkQ

it's a fairly decent low budget licensed game. the thing is short though and easy, clearly intended for children.

>>6968592
agreed. its in the collection now.

In order to use this with a toaster NES you'd have to have a Game Genie+60-72 pin converter sticking way out the front and then this T-shaped cartridge which would be even more ridiculous. I'd love to see a photo of someone actually doing that.

>>6963857
https://www.youtube.com/watch?v=V3W3Cgjlj_0

I like Hart Hat Mack but only three levels, it's awfully short.

>>6968813
I'm not Japanese so I may never understand what, if anything, is fun about karaoke.

>>6968302
>And one or two other unemulatable things such as Bandai's Karaoke Studio

The microphone support would be pretty trivial to handle on an emulator on your PC. If you meant a Flash cart, then yeah.

yeah all the really interesting stuff is for the Famicom. US NES games and peripherals are pretty boring.

>>6969856
social activities can be fun, despite how frivolous they may seem to a loner

>>6968501
How big is the game? Probably only a couple of kb I'd imagine.

>>6968501
>either way, scrolling games are 10x harder than single screen games which is why so many of them suck on the nes

Or why so many of them suck on Amiga, C64, etc.

>>6968501
>>6970726
outside the slower CPU speed C64 is much easier to write games on

As I believe someone in here explained, the NES has only 40k of ROM space and 2k of work RAM. You have 64 very small sprites and can put eight on a row, any more than that and you get sprite dropout. There are no scanline IRQs without a mapper, just scanline poll counters. The color attribute system is a PITA to figure out as it's based around NTSC values and each block of four tiles has to use the same three colors.

Yes, it's limiting. Very very limiting.

>>6969856
Getting drunk and singing with your friends.

>>6971240
> scanline poll counters
The PPU has internal counters, but they aren't accessible with code. Without a mapper, all you can do is count cycles or poll sprite 0 until it hits. There are some insane APU sample channel tricks to sync as well

Scanline IRQs only became available with late period mappers like VRC6; the vast majority of NES programmers never had any access to features like that.

You can do midline color changes or char set swaps but only during the hblank which is a mere 20 cycles on NTSC, so you will have to split up your code for it over multiple hblanks.

>>6971357
> multiple hblanks
You can also just turn background/sprite rendering off and sacrifice a scanline. Many games do. Kirby's status bar for example.

Indiana Jones and the Last Crusade uses mid-line palette swaps on the title screen and Pirates! uses it to change the char set. Other games like TMNT II have parallax scrolling. Not of course counting the games like Return of the Joker that cheat by using a mapper with scanline IRQs.

>>6971394
Indy uses the PPU disable bit to change colors just as Kirby's Adventure does, it doesn't change them during the hblank.

>>6967339
Ah, so that's why it takes Super Pitfall 10 minutes to load every time I warp to another area or start a new life?

>>6971552
Some guys remastered SPF and fixed most of the shitty coding in there including the routines that load the video RAM (since it's an UNROM game so the graphics data has to be copied over from the PRG ROM). As anon said, Mega Man 1 is UNROM and it loads the video data almost instantaneously because it was programmed by actually competent people.

>>6969856
In (((the west))) it's literally the only way to get woo girls to make any other sound. Not saying it's any better monotonous
In (((the east))) it's a totally different thing. But you don't have to be Japanese to understand the fun of having a drunken orgy with half a dozen shemales singing 50s songs in a room the size of your toilet in Ikebukuro. Do you?

https://bytes.vokal.io/4-nes-ppu/

The color attribute system on the NES is bullshit. I can't entirely wrap my head around it.

>>6972058
> color attribute system
Ok. You have 4 background palettes. Each 16x16 metatile can be 1 of those 4 palettes. Each 32x32 area is represented by 1 byte. The top left, top right, bottom left, bottom right are represented by 2 bits in that order. Does that help?

>>6972058
>there are 52 total colors and you can display 25 at once (12 bg and 13 sprite)
>these are divided into four palettes of four colors each
>each tile is 16 bytes and every two bits is a pixel, these bits defining the color (00=color 0, 01=color 1, 10=color 2, and 11=color 3)
>next is the fun part--each 4x4 block of tiles has one of the four palettes assigned to it and all those tiles must use that palette
>sprites work in a similar way with four palettes of four colors, and each sprite is assigned one of the four palettes
>meanwhile, you have the name table which has your tile map--this is arranged like a text mode screen with one byte representing a tile value (0-255)
>the name table can hold four screens worth of tiles
>so if you scroll the screen, you can move one entire screen up, down, left, or right and then it will simply wrap back around
>anything more than that requires you to refill the tile and palette map with a new set of data
>however, the screen wrap also depends on if you have the tile map configured for vertical or horizontal mirroring
>and even funkier configurations like 4-screen mirroring exist
>configuring the tile map requires certain cartridge lines to be connected up a certain way, and sometimes the mapper controls the mirroring configuration instead (but if you're using an emulator or Flash cart, the iNES header in the ROM specifies the mirroring setup the game will use)
>V mirroring means the screen will wrap if you scroll up or down more than one screen and H mirroring means it will wrap if you scroll left or right
>but if your game doesn't scroll at all (eg. many of the early NROM games) then it doesn't matter and you can set the mirroring to anything you want
>and you'll inevitably see glitched graphics data at the edges of the screen depending on what mirroring is used
Neat, huh?

So generally speaking...

>game doesn't scroll--mirroring configuration is irrelevant
>game scrolls vertically with no status bar or only one screen to the left or right--use V mirroring
>game scrolls only horizontally--use V mirroring
>game scrolls only vertically or has 8-directional scrolling--use H mirroring

Games like SMB and Castlevania have V mirroring so they never produce scroll glitches while SMB3 has tons of them since it's H mirrored and has 8 directional scrolling--also to avoid having to deal with refilling the tile map in the vertical axis, the maps are limited to two screens in height.

So if you're scrolling in the direction of the mirroring, you'll get a load of scroll artifacts and you'll need to refill the tile+attribute map each tile you scroll while if you're not in the direction of the mirroring, then you can have a complete screen stored and just scroll that onto the screen (but still have to refill the attribute map). You won't need to refill it until the screen after that, and since it's not the mirrored part of the name table, you'll never get scroll artifacts.

>>6972108
>consider the following:
>animu
It's like you intentionally don't want to be taken seriously

>>6972683
the info is accurate. mostly.
> the name table can hold four screens worth of tiles
ehhhh i mean i'd refer to it at 4 nametables and 4 attribute tables, and the NES itself only has enough memory for 2 of them. you can configure cartridges with RAM to hold the other 2 though.
>and you'll inevitably see glitched graphics data
True, but it is hidable. Somari, of all things, cuts off the bottom 16 pixels and there is no visible garbage or wrong attribute colors with 4 directional scrolling.

>>6973213
In the 80s, they generally didn't worry about graphics glitches as most consumer TVs had a curved screen and would hide them. I used to play NES games on a 90s 27" ProScan with a square screen and you'd see all that shit, but back when those games were made they were assuming you'd have something like this.

>>6973232
This is true. The top and bottom 8 pixels were all but guaranteed to get cut off. Somewhere between 8 and 16 pixels were cut off in all directions, usually. This is why games like Mario 3 and Kirby didn't really worry about the wrong attribute colors happening on the left / right sides of the screen w/ horizontal mirroring.

4-screen mirroring is rare. Gauntlet uses it because it has a Namco mapper; one of the very few third party mappers to appear in a US NES cartridge.

>>6968325
i mean there are 3 genders: male, female, unimportant

So anyway, ASIC mappers generally provide dynamic mirroring. MMC1 would optionally let you disable half the 2x2 nametable, but this feature was removed from MMC3. Discreet logic or NROM games simply have fixed mirroring based on how the cartridge lines are connected up.

>>6959742
I know and have pictures of Nintendo development teams when they were developing exclusively for the disk system.
At that time they mostly used Fujitsu FM hardware.
A lot of third party studios used development tools based on PC-98 at that time

What's the best way to play Gameboy, GBC, and GBA games in a handheld way? I have the original Gameboy and GBA, but the lack of backlighting was always a hassle. Missed out on the GBC but that's another thread for another day. I have a very tiny Nintendo DS Lite that can play GBA games but, as much as I appreciate the backlighting the GBA itself lacked, the screen is so itty-bitty, and it can't play games for the other two systems.

>>6974416
ignore, meant to post a new thread. I really need to get an ad blocker that clears out the empty space left behind

ok

>>6973436
Your post is hate speak against the LGBT community. The "B" in our name stands for bisexual and makes it very clear there are only two genders.