Old thread: >>47563774
>Want to discuss modern consoles?
Yes, I've always been curious about what OSs are the modern console's systems based upon.
For instance, the Wii or PS3 system software. Don't tell me Nintendo or Sony had the ability to build kernels from scratch. Are they Unix based?
>Wii is built from scratch, as with the 3DS and Wii U.
Holy shit! Do you think they developed it internally? Are japanese skilled with this kind of on-metal development? I mean, it's a whole different beast than developing the games themselves.
Has nothing to do with the OS of course just game development for the 3DS. From the very little google results I can only see that Nintendo is really secretive about their software and SDKs.
nintendo always build their os from scratch.
wii is some microkernel nightmare
wii u i have no idea probably based on the wii.
ps3-ps4 is BSD
xbox original to one is based on NT at some point
Interesting. Didn't know that.
>2016 the year of the Nintendo desktop
Laughed. But after their recent announcements, I wouldn't be surprised if they launched an x86 based console and a Steam-like application for DRM for those who want to buy digital copies to play on PC.
>and the wii and 3ds have a filesystem similar to unix
I think so. They have a whole department for console R&D
Never seen a Unity kit before but highly doubt that
That's quite a broad question but, mostly AAA PC games are now released as alpha quality software and if you want to play day 1 prepare to pay 60$/€ to be a beta tester if the game even runs.
Another thing is also pic related.
Not all things are bad though. I'm pretty excited to try Oculus Rift or similar.
I knew about the first thing. That's quite awful. The only decent company I respect honestly is Nintendo, but I'm yet to buy a Wii U since all my money is invested on more important thing but it's not discarded.
What about news from them? Anything special since 2013?
I enjoyed the other threads as well but seriously if you want a general with this subject matter you should move it to /vr/ or /vp/.
"But they have shittier users than /g/!"*
So fix it by transplanting these users.
*false in /vr/'s case
/vp/ is split into mon-fuckers/humanoid-waifu-fuckers, smogonites/karenfags, honorbabbies/exploiters, general autists/niche autists and retrofags who quit after gen1/people who quit yearly
I want to say that the concept designers of the game just said that 6 would be a good number of Pokémon for a team but it's probably really just some limitations that made them do it.
Huum, I always though it was weird that 6 only used 3 bits and it would make sense for the Nips to not want a 7 on it. Always though it could have been something behind it.
>>47592920 (from previous thread)
What's happening to you is you started with an existing save on the cart. That Pikachu's still there, further along in the save than the point where you keep shutting it off. If you delete your save first, you'll lose your Pikachu but you might be able to glitch your way to the Hall of Fame (or perform any other arbitrary code execution).
>>47594328 (previous thread)
Gen 1 has a whole town and tower dedicated to dead Pokemon, and Gary will tell you about how he lost something dear to him, possibly Raticate.
If it's about playing games, it belongs in /v/, etc. But this is more about internals, how stuff on GB works, the GB itself, WHY certain weird glitches happen, even 'jailbreaking' it to get arbitrary code execution.
It's how many fit neatly on the GB screen...? It's also enough to form involved strategies with, but few enough that it doesn't get confusing and battles don't drag on forever. They could easily have fit 8 or 16 and used scrolling, but it would have been annoying. So, combination of gameplay design and what fits on the screen.
*this* belongs on /vp/ or /b/.
They had more space (and more money) so they could put better error handling. Gen 1-2 was extremely space constrained and pushing the limits of the GB.
> with an existing save on the cart
I thought that damaging the save file (with the error message when rebooting before the continue/new game/options interface) made the game delete it as soon as it warns you.
Are you saying that when I try to execute the corrupt save file glitch instead of loading 255 pokemon in my team, it loads some parts of the damaged save file?
How do I delete a save file on the cartridge if damaging it doesn't do shit?
I can't really pick a favorite, but here's more or less what I thought when first playing each one for the first time, compared to the last:
>2: Great graphical improvements, love having more pokes, and 2-way trading with gen 1 is great.
>3: Gorgeous, but... These new Pokemon look like something from Red's acid trip. Why can't I trade with RBYGSC? Why can't I visit Johto or Kanto? What happened to the day/night cycle?
>4: Many improvements but why is the framerate so damn low and the game slower than gen 3?
>5: Finally it's fast again but who fired all the good map designers?
>6: Probably best yet, so much stuff to do, but again with the gen 5 linear map design, and exp comes way too easy.
I doubt Arduino is fast enough to emulate GameBoy. My old 33 MHz 486-DX can barely do it, drops lots of frames and has some slowdowns running it in the asm-optimized No$GMB for DOS.
>I thought that damaging the save file (with the error message when rebooting before the continue/new game/options interface) made the game delete it as soon as it warns you.
No, the corrupted save keeps sitting there. If you write a correct save header at the start and shut off power before it writes the rest, you'll still have some data leftover from the old one.
>Are you saying that when I try to execute the corrupt save file glitch instead of loading 255 pokemon in my team, it loads some parts of the damaged save file?
>How do I delete a save file on the cartridge if damaging it doesn't do shit?
B+Select+Up on the title screen. No, it's not an undocumented thing like ctrl+alt+del, it's mentioned in the original manual iirc.
Not many lately. Thankfully.
I think they're going to try something with mobile, but not full games. They are also closing Club Nintendo and substituting it with said "something mobile"
>you should move it to /vr/ or /vp/
This is a thread strictly about the technical side of these special purpose computers, and
I don't believe it belongs in boards about videogames and it benefits /g/ greatly. Last thread was awesome.
I'm sure /v/ doesn't really care about this type of things. They have more interesting things to discuss, like "videogame journalist" talking about femminism.
Videogames are technology, this is a thread on how videogames work. It fits in this board.
>Gen 3 was the coolest imo
For me Gen3 is the worst. It added almost nothing new other than graphics.
Gen2 is the favorite for me because it improved the most and had the most new features (relevant ones). Colors, breeding, day/night cycle, 2 full regions to explore, 16 badges, gen1 retro-compatibility, hold items, egg moves, new pokemon types and huge changes in game balance, etc.
And Gen6 comes in 2nd place for me. The 3D battles really bring back that Pokemon Stadium nostalgia. And the 3D models actually look pretty good. It's a huge change over the 2D games. The overworld is not the best though.
: Many improvements but why is the framerate so damn low and the game slower than gen 3?
This. Gen4 felt so sluggish and stuttery compared to the smooth 60fps of the previous generation.
>Gen 1-2 was extremely space constrained and pushing the limits of the GB.
This. Pic kinda related. The last sentence at least.
It's some of the feats Satoru Iwata, Nintendo's current CEO, made back when he was a programmer. I wish he would step down and continue programming games.
>that's the reason the locations from red and blue were included
So that's why they never again included 2 areas in the next gen games (except in GL/FR with the fake orange islands).
>I wouldn't be surprised if they launched an x86 based console
>and a Steam-like application for DRM for those who want to buy digital copies to play on PC.
No way, they'll go bankrupt before that. Nintendo is the most locked down of all the consoles. They are the most insistent on using their own terrible consoles.
>The only decent company I respect honestly is Nintendo
Don't. They are as corrupt as anyone else, but instead of pushing dlc, they stick to their old ways.
>I'm yet to buy a Wii U
Good, it's absolutely terrible.
The islands were created solely to pander to animefags with the orange islands, even Bill sends you there on a mission just like prof.Oak does with Ash. Stop being an autist.
>Don't. They are as corrupt as anyone else, but instead of pushing dlc, they stick to their old ways.
I phrased it wrongly. What I meant is that I respect the franchises they have and that's pretty much why I will buy a Wii U. But I'm more of an old schooler so my Wii Library consists of almost all-time franchises and it's always offline since I use it exclusively for emulation.
>Good, it's absolutely terrible.
I'm buying it for Smash and Zelda, pretty much. I never buy handhelds.
One of the recent ones is pokemon ORAS battle frontier.
Battle frontier was a pretty big post game area with many unique gameplay elements(and it was actually challenging unlike the rest of the games). Most players loved it in emerald. Since there was one in HGSS, everyone assumed there would be one in ORAS and were hyped for it. There was magazine pages about it (Later confirmed fake) and lots of references to BF in the actual game. ORAS sold like hotcakes of course, but people noticed rather soon that there was no battle frontier. The deluded fans refused to belived they were scammed, and rumors and ideas about it comming in a DLC later started running wild instead. And of course, still nothing.
Also, in true nintendo fashion lots of features from XY were removed for no reason at all, like character customization.
As for other things, the wii u just started getting adoption, and they have already announced the next console(though little is known about it).
>Also, in true nintendo fashion lots of features from XY were removed for no reason at all, like character customization.
Really hate that shit. Add a nice feature everyone loves in one game and the remove it in the next game.
Yes. They even have the guts to say: "We still haven't decided which of the newly-introduced features we're going to keep; we never distinguish between "experiments" and "features to keep". It all depends on the fans' reaction."
Witch clearly is bullshit. If that was the case they would have kept the features everyone loved and almost no one disliked.
>this due to limitations
No, for most of this stuff there is no such excuse.
>have a unique identity and experience
Maybe, but that's not what they claim. Still, the games can be unique in other ways.
Yeah, sorry for going off-topic. But to be honest, there's loads of threads like this on g all the time.
Nope. Game Boy cartridges were initially extended to contain more memory with simple memory bank controller chips. The camera and tilt sensors were more complicated, but still essentially the same thing, and were interfaced with in an extended memory-like fashion.
Probably. My best guess is that it had a small ROM chip, like a BIOS, so it was only in charge of booting the game. This is probably true since the cartridge was the RAM for the game itself.
I don't know, anything you know that you think is interesting, be it about the hardware or some interesting glitch.
Haven't played pokemon a lot but isn't there a glitch that allows you to run code?
Yeah, maybe that's where I saw it, or maybe it was on youtube.
What about hardware, maybe console hacking, do you happen to know anything about it?
I'm also curious how people manage to crack consoles to make them run pirated games or homebrew.
Yes there is, using the item 8F you can run any code you want as long as it's under 256 bytes or so. You program it by inventory items and moving around. You can make anything you want. Like pong.
There are two ways to do it:
1.- Hardware. You either "jump" the cables on the chip that validates a key on the disk so you can run the game or you entirely replace the chip with another one designed to ignore the key validation.
2.- Software. As far as I know, there are firmware updates or small background program installation to achieve the same effect of the hardware option.
This is becoming increasingly difficult with newer consoles because validation now comes from official servers and account relation.
Old cartridge consoles were an easier target since the console only worked as a bootloader and resource manager (in the case of the gamecube).
No, it did not. Gameboy and GBA have a simple memory map defined by the hardware. There is no virtual address space and the only mapping of memory that occurs is the bank switching cartridges with MBC chips do to page ROM and SRAM, which still isn't proper virtual memory.
No. It's just asm game code running directly on hardware. When a game wants a different page of the game ROM, it makes a predefined sequence of writes the MBC watches for to make it switch banks. The bank switching isn't anything in software apart from that. It's literally a chip that controls the high address lines on the ROM chip.
No, and no. The game itself starts at a predefined address in the ROM (0x100 iirc). The entire game is in ROM. The original GB spec had a max of 32 KB for ROM, so if you want anything larger you have to use custom hardware (MBC) to switch between pages of ROM. IIRC, the MBC always leaves the bottom 16 KB of the ROM at address 0 for interrupt handlers and the like, and switches in whatever page the game requests in the upper 16 KB of ROM space.
The CPU itself does contain a 256 byte boot ROM that runs before the game. It doesn't do much. Really just display the logo, verify that the logo loaded from the cart is the correct Nintendo logo (brilliant trademark-based DRM there). If it's a GBC, it also enables GBC features if the ROM header says it's a GBC ROM; otherwise it lets the player choose a color palette. After it's done executing, it permanently hides itself so the start of the ROM is at address 0, and passes control to the ROM.
Item IDs and quantities are bytes. They didn't think to dummy out unused, unobtainable items, so they have random names and do undefined things. Someone found a way to obtain this 8F item through other glitches, and found that using it results in getting an address partway through the item list data on the stack, and then a return being executed. So, it ends up executing the item list as bytecode.
Depends whether it's an older or newer console.
GameBoy for instance had very little protection. You just had to manufacture a cartridge the right shape with RAM and ROM connected the right way. If you wanted more than 32 KB ROM and iirc 8 KB RAM, you needed some sort of memory bank switcher chip like Nintendo's MBC.
You also had to have a valid GameBoy header at the start of the ROM chip. This is trivial, but if you do it commercially to publish games without Nintendo's permission, they can sue you for putting their trademark in your game.
So, you ended up with flash cartridges that you can write a ROM onto and it functions exactly how a normal cartridge would.
Newer stuff has better protections, so you need more involved exploits to bypass them.
Tell me whatever you feel like writing about, everything related to it is interesting.
I don't really understand some of it, what is MBC, bank switching and high address?
Oh, and does the gameboy run assembly code or by assembly code you mean machine code, I think computers can't run actual assembly?
That's awesome, so you'd "bypass" the actual part of the circuit that did the validation by rerouting it using cables or something?
Cool, any place I can look on how to make a cartridge? I'm not interested in making one myself because it probably requires special hardware to write onto the cartridge and all, but learn more about how to make it.
>That's awesome, so you'd "bypass" the actual part of the circuit that did the validation by rerouting it using cables or something?
It was made on older consoles. That gave ithis practice, at least in my country, the name of "chiping the console". This name carried on and even when doing a software bypass you'd call " chip" to the software application in charge of this.
Which country is that? At mine we say the same.
Also, would anybody be interested in starting a general thread for this kind of stuff, glitches, consoles, hardware "hacking", I guess you can call it that.
These last pokemon glitches thread have been pretty interesting.
>I don't really understand some of it, what is MBC, bank switching and high address?
>Oh, and does the gameboy run assembly code or by assembly code you mean machine code, I think computers can't run actual assembly?
Technically assembly and machine code are not the same thing, but in practice there's more or less a one-to-one correlation between them, so there's nothing wrong with saying a CPU runs assembly code.
MBC = memory bank controller. The Game Boy CPU can only interface with 64 KB of memory, roughly half of which is RAM, with the other half coming from a ROM chip on the cartridge. But 32 KB is only enough for the most basic games, like Tetris. Pokemon GSC were 2 MB each, but as-is the Game Boy can only talk to the first 32 KB of that. The MBC is a chip that (figuratively) splits up the 2 MB into banks of 16 KB each, and switching them out when reading from another one is necessary.
Making a cartridge is pretty easy for the GB. If it's 32 KB or less and doesn't save, you just take a memory chip, store the game program on it, and wire the address/data pins on the chip to the corresponding lines on the cartridge connector.
>Laughed. But after their recent announcements, I wouldn't be surprised if they launched an x86 based console and a Steam-like application for DRM for those who want to buy digital copies to play on PC.
Come on I remembered reading an article on toms hardware about why nintendo should change to x86, but the author of such idiocy was shown in the comments that he didnt knew shit about the vidya industry.
Anyway, nintendo is not having problems about the architecture of the WiiU, but the lack of power that makes no one willing to develop for an gimicky underpowered hardware that does not run the latest engines.
>bubububububut the hardware is of no importance in consoles, its the software
yes many if us believed that, but if you have underpowered enough hardware that not motivate devs, then you have NO software, and you are as good as dead.
How about the 3DS? The first commercially available flashcard use an exploit chain in the system.
It goes like this: A ROP string is written to the DS mode settings memory through the already hacked DS mode. Then you open system settings and open the DS settings. Since the error is improperly handled, the ROP chain executes. This chain then use the RSA verification service to send code to the ARM9 (security coprocessor). Since the service doesn't check for length the code gets executed on the ARM9's Process9. When you have ARM9 you practically have the entire system.
Would love a general like this, but with less emphasis on pokemon.
It's really because the 3rd parties are too cheap to take risks making unique games for the wii u and the wii u doesnt use x86 so the games they make can't easily be ported, since most third parties just make one game that gets ported to each console instead of unique games per console. If the wii u had the same architecture, you'd see it getting ports of games more often.
yes, but what exactly would you want to do that you couldn't in the program?
I could imagine using the Arduino as a pseudo-MBC and having it provide sensor input to the game program. That would be in addition to the flash chip containing the code, though.
You sound like a niontendrone, but lets bait.
>It's really because the 3rd parties are too cheap to take risks making unique games for the wii u and the wii u doesnt use x86 so the games they make can't easily be ported, since most third parties just make one game that gets ported to each console instead of unique games per console. If the wii u had the same architecture, you'd see it getting ports of games more often.
Why would the big ones may want to do unique games for each console? If its excusive games what you want, its beacuse the console manufacturer spent money making one, or because it payed a third party to not to release it in other platforms.
Besides Adapting a game to the wii U implies additional costs in designing, testing mechanics to use the darn pad. Who in their fucking right mind would want the risk of investing on a console with such little installed base. Architecture, again, has nothing to do with it.
Ok, lets bite again!, You successfuly developed a game for the WiiU, that makes excellent use of the pad, its called the most innovative thing ever. If you want to port it to anything else, the first thing you have to think is how to make that unique mechanic that worked charms with the pad, available to consoles with one screen only. That, my friend, costs time and money and you may not implement it well, after all this, the architecture is the last of your worries.
>Why would the big ones may want to do unique games for each console? If its excusive games what you want, its beacuse the console manufacturer spent money making one, or because it payed a third party to not to release it in other platforms.
Unique hardware allows for more unique experiences. Look at some of the stuff Nintendo has came up with for the Wii or Wii U.
>Besides Adapting a game to the wii U implies additional costs in designing, testing mechanics to use the darn pad. Who in their fucking right mind would want the risk of investing on a console with such little installed base. Architecture, again, has nothing to do with it.
Similar architecture would still make it cheaper to port and more likely that they would take a risk. Also, the Wii had the biggest user base of all of the consoles.
>Ok, lets bite again!, You successfuly developed a game for the WiiU, that makes excellent use of the pad, its called the most innovative thing ever. If you want to port it to anything else, the first thing you have to think is how to make that unique mechanic that worked charms with the pad, available to consoles with one screen only. That, my friend, costs time and money and you may not implement it well, after all this, the architecture is the last of your worries.
Don't port it then. Make a new product that targets that platform.
>Cool, any place I can look on how to make a cartridge?
Mostly people take the ROM chip out of an existing cart and wire in an EEPROM or some sort. This avoids having to reproduce MBC functionality.
I doubt it would be fast enough. I thought of doing something like this with a raspi, but 2 problems:
1. Only 17 GPIO pins, GB cart has 32 pins.
2. I doubt I could bitbang data on it fast enough after an address is written to it. It has to be pretty fast since it's wired to the system bus and instructions are fetched directly from the cart as the CPU executes them.
You'd have better luck with an FPGA. You could probably implement an entire GB cart on an FPGA board. Heck, you could even have a custom hardware interface to access an SD card, get a file listing, and tell the cart to read a GB ROM file into a RAM chip, reset the GB and execute that ROM.
>Similar architecture would still make it cheaper to port and more likely that they would take a risk.
This would have been true 20 years ago. Today, if you give a dev an SDK with a C++ compiler and OpenGL, it won't make any difference if it's x86, ARM, PowerPC, etc. You just have to adjust graphics for the console's capabilities and adapt gameplay and controls to what is possible and expected on that system.
No, the bigger issues with porting to Wii U are power and making use of the weird features of the system, like motion controls and the controller display. The general lack of power compared to 360 and PS3 is a big issue -- most big-budget games try to sell on graphics, and they'll look severely degraded on Wii U. Nintendo's games on the other hand go for a cartoony look that works great on the limited hardware.
GB Basic is more a toy / learning tool than something for creating real games. This describes every BASIC, possibly except VisualBasic. If you want power, you use a language like C++ or asm, not fucking BASIC.
You're looking at a 4 MHz Z80 with 32 KB RAM. Of course there's going to be a huge difference between C and asm. On this primitive a computer, every cycle counts, every byte counts.
>Nintendo's games on the other hand go for a cartoony look that works great on the limited hardware.
>tfw playing RE4 on Gamecube and looking at how bad things looked
>tfw playing WW on Gamecube and everything is just as good as over a decade ago
The important thing about graphics is to achieve perfectly what you want. You just can't do this with realistic graphics.
You can if you for styles like WW or SS.
I'm so glad there's a split disassembly for the GB Pokemon games (well, Red, Blue, and Crystal, at least)
I kind of wish I had a handle on z80 asm, I'd like to fiddle with this a bit.
>You also had to have a valid GameBoy header at the start of the ROM chip. This is trivial, but if you do it commercially to publish games without Nintendo's permission, they can sue you for putting their trademark in your game.
The Sega v. Accolade decision made it so that putting the header in (even though it contains a trademark) for purposes of making a game compatible with the system was legal.
Here's the second chain that gives you ARM9 kernel control:
First, you need to take control of an application, this should give you the ability to inject a ROP chain. Now here's the brilliant part: Applications get access to the GPU. So we use GPU DMA commands to write ROPs to the heap (?) of system applets/services. This is possible because the MMU doesn't check where the data is written to, and the GPU have access to this memory section.
Then, data is written to the kernel heap. Since the kernel doesn't check for this, you get code execution as ARM11 kernel.
After this, you can overwrite the headers of the ARM9 OS (point it to your own version for example) and the ARM9 will load it. Then you get ARM9 kernel access.
(I hope someone read these. I found them interesting though I may not fully understand them)
Oops, yeah I got a little confused, no idea what happened.
I was thinking of 2^8 because I thought the address bus was 8 bit and I was mixing KB and bytes, which had me wondering why it couldn't access 256KB, when it would be 256 bytes (if it was an 8 bit address bus).
>that last picture
>poorfags still thinking this is is actually happening
ZOMG GAMEZ ARE RUNINED I WANNA RETURN BACK TO MY CHILDHOOD IN THE 90'S
I read but didn't understand much of it, don't know about ROP, DMA, heap.
What I understood was, applications can access GPU and you somehow use the GPU to write to the kernel?
ROP = Return Oriented Programming. This is a workaround for DEP (Data Execution Prevention). The typical method was to write the code you wanted to run in whatever data buffer you control and then put the address of that buffer on the stack in place of a return address. That way when the current function tries to return, it will return to your code and run that. However, modern CPUs have DEP, which prevents running code in any place that wasn't declared as a code section, in order to prevent exactly this. So, instead we collect short sequences of instructions at the ends of functions, right before a "return" instruction, and string them together into something that does what we want. We then write that chain of return addresses to the stack, and when the current function returns, it'll start running this chain of function-ends that we made.
DMA = Direct Memory Access. A hardware device other than the CPU is given direct access to some memory so it can read and write stuff there without consuming CPU cycles. A GPU would typically have this, especially in an embedded system, so it can access textures in main RAM without the CPU taking time to feed them to it.
The 3DS implements proper memory protection, so an application can't write to kernel memory. The application can tell the GPU to so stuff, including read and write memory; the typical use of this is passing the GPU buffers of vertices, textures, etc. However, they slipped up when they implemented the GPU's DMA. The GPU gets full access to all system memory, not just the parts the application has permission to access. So, we can ask the GPU to read or write kernel memory for us through DMA.
Heap = The part of memory that malloc/new allocate stuff from.
Sonic & Knuckles was a full game that you could play stand-alone. And it even had more content than Sonic 3.
It was also badass as fuck to physically fuse 2 games together back then.
Wow thanks for explaining it so well, but since I'm not a programmer I'm unsure about a few things.
Malloc and new are used in c and c++ to allocate memory, but isn't that done automatically by the operating system? Either way the heap is memory that malloc and new can use right?
DEP is to prevent applications from writing to the kernel right?
One last thing, sometime ago I read about buffer overflow and they sound similar to what you explained about ROP, are they the same thing?
>Malloc and new are used in c and c++ to allocate memory, but isn't that done automatically by the operating system? Either way the heap is memory that malloc and new can use right?
The OS just maps memory into the process's address space, with a minimum allocation size of 1 page (usually 4 KB). Malloc and new manage that memory, handing pieces of it out to functions in multiples of 1 byte. When you malloc/new and there isn't enough memory allocated to the process, malloc/new ask the OS for more.
>DEP is to prevent applications from writing to the kernel right?
No, to keep applications from running code that's in a data area of memory like the stack or heap. Optimally all memory marked as code should be read-only, and anything writable should be no-execute using DEP. This ensures that if there's a vulnerability that lets me try to execute stuff I've dropped in a data buffer, the OS will stop it from happening when the CPU tries to execute in that buffer.
This stops countless code-execution vulnerabilities. On desktop it's mostly used to stop exploits malware uses. On consoles it's mostly there to make it harder to find an exploit to run your own code.
>One last thing, sometime ago I read about buffer overflow and they sound similar to what you explained about ROP, are they the same thing?
Basically. If you find a buffer overflow on the stack, you can use it to overwrite return addresses with whatever you want. Typically you'd write your code in the buffer and overwrite a return address with the address of that buffer. However since DEP would stop you from running stuff in that buffer, you need to instead write a chain of return addresses that string together snips of code that are already in the application's code section.
Cool, so DEP makes so you aren't able to run stuff in buffers so you have to use code already in the program.
So I'll find pieces of code I want on the program, and replace the return address with the location of those pieces of code instead of writing my own code to the buffer and changing the stack pointer to the beginning of the buffer.
What about ASLR, if a console has it how would you use a buffer overflow or ROP, since those memory locations are randomized you can't choose the return addresses.
Anyone else dissapointed with Pokémon X and Y? I was so hyped for that game for months but when I finally played it, it felt "MEH".
Aslo does anyone else feel the developers at gamefreak are not good programmers?
>No 3D-enabled over world.
>Framerate problems in battle.
>No anti-alising which meant jagged outlines.
I know its pokemon and you can't expect the top graphics but Pokemon X and Y looked almost the same as the DS games, only it's renderer in a higher resolution and. The camera perspective is different.
>So I'll find pieces of code I want on the program, and replace the return address with the location of those pieces of code instead of writing my own code to the buffer and changing the stack pointer to the beginning of the buffer.
Yep. You do have a restriction though: those pieces of code you run must be followed directly by a return instruction.
>What about ASLR, if a console has it how would you use a buffer overflow or ROP, since those memory locations are randomized you can't choose the return addresses.
That makes things a lot more difficult. You have to either predict, guess and retry; or discover enough of the layout.
>must be followed directly by a return instructions
Why is that? Do you run the code and overwrite the return address so it goes to another code, where you'll again run the code and overwrite the return address and keep doing that?
>discover enough of the layout
Can you expand on that
>Why is that? Do you run the code and overwrite the return address so it goes to another code, where you'll again run the code and overwrite the return address and keep doing that?
You write a series of return addresses so it'll run one bit of code, then return from that to the next bit you wanted it to run, and so on
>Can you expand on that
If you can obtain, eg, a pointer from the running code, that can tell you quite a lot. Try to trick the code into printing it, returning one over a network protocol, or even displaying something weird from which you can deduce the pointer's value.
If there's some module that doesn't have ASLR enabled but doesn't have all the code snippets you need, you can potentially use that one to search for locations of other modules that would be more useful.
>looked almost the same as the DS games, only it's renderer in a higher resolution and. The camera perspective is different.
What!? The battles are in 3D! All the previous generations used sprites. Agree that the overworld is totally shitty, but the battles in 3D are great, attacks and all. It gives me that Pokemon Stadium nostalgia vibe. And I can't imagine how much work must have gone into modeling and animating all 720 pokemons. Maybe that's why the rest of the game is a bit shallow.
Still better than all the other gens IMO, except the 2nd.
>Anyone else dissapointed with Pokémon X and Y
I wasn't really, since I got the things I really wanted.
>No 3D-enabled over world.
Yes, a bit of disappointment, but 3d is still just a gimmick so i didn't care.
>Framerate problems in battle.
Yup, that sucked.
>No anti-alising which meant jagged outlines.
Dude, the hardware is shit, developers are shit, you shouldn't expect this.
The game gave me most of what I was after, a 3d(as in models not the gimmick) pokemon game, first since gen3. And a new world with new pokemon to find.
>almost the same as the DS games
Can't agree with that at all. pic related.
sry forgot pic.
About the developers being shit, they could, if they were good, have had the generation 5 graphics(basically) in gen3, on the GBA, and 3 models in battle in gen4 on the DS.
Come on, overworld isn't that bad. No, it doesn't have 3D enabled, but that's really just a gimmick. They did do a bunch of little details like making people turn their heads as you walk by or making your character crouch down when talking to little kids. Character models in the overworld are chibi-fied and look different from what you see in battle or in the dressing room UI. This is a design decision made because the screen's low res and faces would be barely visible without it.
Compared to the DS games, it's now all 3D rather than a few 3D things with a bunch of kinda cheesy looking scaled sprites pasted over it.
Yeah there are some framerate lags in battle, but most of them go away if you turn off the 3D slider. Someone judged that it was better to have occasional framerate chugging than to use uglier lower-poly models.
Anti-aliasing? Does the 3DS even do this? I don't recall seeing any properly anti-aliased 3DS game...
>gen 5 graphics in gen 3
The battle ones maybe. The GBA was good at scaling and rotating sprites. I don't know if it could handle as many of them on screen at once as gen 5 battle graphics needed.
Overworld-wise, gen 5 obviously uses the DS's 3D mode, which GBA completely lacked. Best it could do was all-flat-land with simple texture and limited navigation, as in Mario Kart Super Circuit or FZero.
>3 models in battle in gen 4
Of course it could, but they hadn't come up with the triple battle game mechanic yet. Also the gen 4 battle UI had larger, more gen 3-like Pokemon names and HP bars in battle, and 3 of them wouldn't fit. Gen 5 accomplished this by using omg fucking tiny font that they might not have been so willing to use before DSi XL was available.
>They did do a bunch of little details like making people turn their heads as you walk by or making your character crouch down when talking to little kids.
In ORAS when your character pops a squat to talk to sitting characters is cute as heck.
>The battle ones maybe
Yeah that's what I meant. they could have used some mode7/fake 3d in the overworld too though. There isn't that many polygons in the gen4 overworld, a lot of it could have been done with tilted textures.
About the sprites, there was GBA games that did this with 7+ slightly animated sprites. pic related.
>Of course it could
Yes, they could have just done the tiny fonts earlier. I knew no one with a DSIXL and no one even noticed that the fonts were small.
>Anti-aliasing? Does the 3DS even do this?
It does. But just about no game uses it, because performance. Of course the 3ds really needs it due to the terrible screen resolution.
Show me one game that makes convincing 3D Pokemon-type "hills" on GBA. You'd get totally flat terrain. There's also the issue that camera angles cause, with seeing less far behind you, making running backwards a little awkward.
Back when GBA was in, pretty pixel art was valued, and mode 7 scaling "3D" ruins that, so even if it was possible to do reasonably, it would have been judged to be uglier than the top-down 2D solution.
Is there a place I can learn more about this? Maybe a book or a site.
I suppose I should start by learning programming and assembly, but where to learn the "hacking" like the things you explained me.
>Show me one game that makes convincing 3D Pokemon-type "hills" on GBA You'd get totally flat terrain
I can't, because I can't find any games that do just this. Sonic battle has something like it. But the hills are simple, just 3 "wall" sprites scaled and two floor ones. No reason the GBA couldn't do it.
>There's also the issue that camera angles cause
No no reason to change them, just rise the camera as far up as you rise the player sprite. the different camera angles were just added in gen5 to show you different stuff.
>it would have been judged to be uglier than the top-down 2D solution.
Maybe. But then it just makes even less sense to implement it later, when you had the 3d model option available.
sonic and knuckles was completely separate game. There just so happened to be a gimmick that you could plug sonic 3 into the top of the cartridge and you could play seamlessly through all the sonic 3 levels into the sonic and knuckles ones.
What wasn't intended exactly? Playing sonic and knuckles on it's own was perfectly intended. But if you owned sonic 3 already, then there was no real reason not to plug in into sonic and knuckles to continue playing from where you finished in sonic 3. Sonic 3 also had cmos to let you save game files, while the sonic and knuckles cartridge didn't. But if you plugged sonic 3 and sonic and knuckles together you could save your game progress in the sonic and knuckles levels.
You can play sonic 3 + sonic and knuckles combined in an emulator just fine too, just by joining the two rom files together. If you look up "Sonic 3 and knuckles" you'll probably find a rom that's already set up to work like that.
You can also plug sonic 2 into sonic and knuckles and play all the sonic 2 levels as knuckles. It's pretty fucking insane actually because knuckles can't jump quite as high as sonic, and you often need to figure out different ways of defeating bosses or getting through levels because of that. It's doable though. Shit's crazy.
>I can't, because I can't find any games that do just this. Sonic battle has something like it. But the hills are simple, just 3 "wall" sprites scaled and two floor ones. No reason the GBA couldn't do it.
To my knowledge, GBA is limited to scaling, rotation and different scaling per scanline. To have proper fake-3D with perspective and anything other than just one flat plan with sprites sticking up (classic mode 7, like in FZero or Mario Kart Super Circuit), you need to be able to map a sprite into an arbitrary quad and I'm pretty sure GBA can't.
Sonic Battle is sorta 2.5D, which you can do with pre-rendered sprites at fixed angles.
>Maybe. But then it just makes even less sense to implement it later, when you had the 3d model option available.
Gen 4-5 DOES use 3D models. The DS is just crappy enough that it can't handle full 3D models for multiple people on screen plus all the other stuff going on and make it look decent at the sort of size you have in a Pokemon game.
Yes, and actually VBA-M already has a cheat search function.
If it's a good emulator, yes, for the most part at least. SNES emulation for example is incredible, and almost always perfectly cycle-accurate. N64 emulation on the other hand suffers a lot of glitches, mostly graphical. NES emulation is perfected to the point where people work on emulating the look of playing it on an old color TV and getting the color tone just so. GB emulation is just about perfect, though behavior of invalid opcodes is not identical (pops up error message dialog).
Emulators also tend to lack wacko features of some games like plugging one cart into another.
I always thought it was a separate game since I only had played it on emulators.
I thought after they released sonic 3 and sonic & knuckles they decided to release a game with both of them together.
What about hyper sonic, super tails, and super knuckles and the sumer emeralds?
Is tails even playable on sonic & knuckles? Has been a while and I can't remember.
Can you have hyper sonic on sonic & knuckles?
>What about hyper sonic, super tails, and super knuckles and the super emeralds?
yep, those all only in sonic 3 and knuckles. They had a lot of features that only worked when both games were together. Keep in mind, sonic and knuckles was originally meant to just be part of sonic 3, and when they realised they couldn't get it all finished in time they split it into two separate games.
>Is tails even playable on sonic & knuckles?
nope. but he is playable on almost all levels with sonic 3 and knuckles
>Can you have hyper sonic on sonic & knuckles?
I don't think so. Gotta get all the chaos emeralds in sonic 3 and all the super emeralds in sonic and knuckles for that to happen.
>To my knowledge, GBA is limited to scaling, rotation and different scaling per scanline
Yes. But you can still do hills. Look at gameplay of sonic battle, they pretty much make pokemon hills, only that the "walls" of the hills are 90 deg. to the ground instead of ~45. You can do a lot of stuff with the GBA scaling, even make a car that certainly looks complex enough to be a model.
>Gen 4-5 DOES use 3D models
Not in the battles, which I was talking about from the beginning.
>The DS is just crappy enough that it can't handle full 3D models for multiple people on screen
It could, in zelda and mario games. Of course, some designs(Especially newer ones) would have to be toned down though.
It certainly could have been done, but no, it might have not looked that amazing, but anything would have been better than gen5 battle graphics.
Getting a little off-topic here, looking more like /v/ material.
I think these are pre-rendered at the correct angle. Therefore it's stuck being fixed angle, isometric with no perspective.
>car that certainly looks complex enough to be a model
In what? Everything I've seen like this is pre-rendered so it's just a sequence of sprites at a handful of angles.
>It could, in zelda and mario games
Note the zoom. This zoom level would not work in Pokemon, where you need to see further. If you zoom it out, you start running into screen resolution issues, and get more models on the screen. I think it was a combination of too much stuff to render on screen at once, and that it would be hard to do it with models and make it look as good as sprites at that size.
As for 3D battle graphics, I think the DS could have handled it, given that N64 ports like SM64 work well. It just would have required a shitton of Pokemon models and possibly a larger DS ROM size than they had at the time. Not to mention work in implementing it.
This is on DS.
>It just would have required a shitton of Pokemon models
Gen6 on the 3DS has even more models. 720 in total. But yeah, the 3DS maximum ROM size is probably bigger than the DS ones.
Whoa, nice, I assumed it was a hack of Platinum. Still, this is just the intro animation. I bet that rotated view isn't even rendered on the GBA, but just a still bitmap captured from the DS Platinum intro.
Biggest DS ROM I've seen is 256 MB. I think the Pokemon X/Y ROMs are something like 1.4 GB. Anyone who got the digital download version can check the size on their SD card; I have physical carts so I can't.
>I think these are pre-rendered at the correct angle. Therefore it's stuck being fixed angle, isometric with no perspective.
How can you think that? you can see the perspectives changing as they jumps and move, and you can see the sides of them. In a video like this: https://youtu.be/A_LLAEcumjk?t=4m16s
Top Gear Rally. It could be the lag fooling me though, maybe it's prerendered. But it has loads of angles and different versions in that case.
>This zoom level would not work in Pokemon
No need to use that zoom level in pokemon. And you'd only need 4 models at a time, sort of like pic related.
Yea, I don't really see how that rom hack is relevant since it's all 2d.
>Biggest DS ROM I've seen is 256 MB
Biggest NDS rom size possible is 512MB. Seeming how stuff like SM64 is 16MB and that there was only 500-600 pokemon or so, it seems doable.
If you look at his channel and the thread there are other videos and screenshots
You're probably right about the Eterna City part. According to the map on his own site he still has to make it.
Holy shit, that's really impressive for GBA. I hadn't actually played that. I'm not sure what they did to make it render that -- whether it's texture scaling or an oldschool raycaster. Still you can feel that it's pushing the limits, seeing as how the vertical bits wobble as the camera moves. I wonder whether it would be able to handle anything other than flat and vertical.
>Top Gear Rally
That is definitely looking like a primitive 3D model.
>And you'd only need 4 models at a time, sort of like pic related.
You often have more than 4 NPCs on screen at a time, not to mention the other super-simple models needed like buildings, fences and trees. Pokemon's landscape is definitely flatter than SM64, but there's more details visible on screen at a time.
As for zoom level, think about how small the your character's picture is on the screen in gens 1-5. I don't think there's enough pixels there for a 3D model to look really decent.
>Biggest NDS rom size possible is 512MB. Seeming how stuff like SM64 is 16MB and that there was only 500-600 pokemon or so, it seems doable.
Not sure how it would go in terms of size. They'd clearly be really low-poly models since the DS is so limited. It would almost certainly fit fine in a 512 MB ROM, so the real reason is most likely that they didn't have the time to make the engine and all the models for 3D battles in time for DPPt, and gen 5 is just a slightly modified DPPt engine so they didn't rewrite it.
I remember being disappointed that we didn't get Stadium style 3D battles on DS.
And neither of them understand a lick of asm or architecture, which is quite relevant to serious discussion of glitching.
>ps4 doesn't glitch out like this so it's superior, cod4life, pokemon is for kids
>mega missingno when? also which pokegirl would you like to fuck?
Only if you're gay or female.
For straight males, the correct answer is Gardevoir or Lopunny.
Bulbasaur if you're a freak.
Anyhow, glitches... I know there's some sort of broken corrupted save that causes RBY to crash before the title screen, effectively bricking the cartridge. Has anyone actually looked at how this works? Seems to me there ought to be some fun to be had with this bug.
The cable itself has a straight-through clock line, and crossed serial data lines, like a nullmodem cable. It was a duplex serial thing. Each side loads a byte into a register and sets a "go" flag. Then both sides' hardware shift bits out of the register and onto the wire. The flag is cleared when it finishes, and each side's register contains the byte from the other side.
GBA link cables have one mode that works like this, one that's the same but 32 bits at a time, and more different modes for dealing with 3-4 player link.
PS4 is BSD, but the wii.... Holy shit, it's a fucking mess.
Everything is packaged into IOSs, and the individual IOS modules control various things. Had an offline Wii that asked for an update when you inserted a disk? That was because the game supported IOS blocks that your system didn't have yet, say Balance Board support.
Picture the Genesis. Then you strap on the 32X, and then the SCD. That is what you are doing to the OS of the Wii. Yes, it sorta works, buteach block must meet memory constraints. If you've nodded a Wii, you have to replace eondividual IOS blocks with nodded ones. Its a pain in the ass.
Has anyone here successfully built Pokemon Red/Blue?
After installing some Python packages I was missing, I'm getting some PNG error.
Similarly, the GBA contains GB/GBC hardware in it, and the DS has GBA hardware (but not GB/GBC). They wanted backward compatibility but decided against emulation, presumably because it wouldn't be completely accurate or the GBA's CPU wasn't powerful enough.
Well, it's never meant for you to install IOSs anyway.
The Wii uses titles to manage programs like the 3DS or Wii U, however it doesn't have an OS in the background to handle IO, so the use of IOS is necessary. It's not very complicated anyway. You have >200 slots and IOSs have versions.
Almost certainly something like that. I'm not sure how similar ARM7, 9 and 11 are, so it's actually quite possible they've just set some modes and lowered the clock speed.
There's a test someone could do: Write a DS ROM that idles ARM7 and burns all cycles on ARM9. Run that on an opened 3DS and see what chip(s) get warm. Repeat with one that idles ARM7 and burns cycles on ARM9.
Jon snow gets killed at the end of this new season after he is made Lord commander of the wall. By his friends of the night watch.
Kelvin Lannisters also gets killed by Varys at the end.
And Denarys nephew is still alive and plans the reclaim the iron throne.
I notice my 3DS never really gets warm.
Also all processors are in the same SoC, so this will take some work.
Anyway if you stress ARM7 then it might hint if the ARM7 is emulated or not I think, since basic visual analysis shows it's not there.
The chips inside should get a little heat. As for stuff integrated into the SoC, it might be possible to discern between them with an IR camera. You'd need to make a 3DS homebrew that chugs one CPU and then the other in 3DS mode, identify what parts of the SoC get warm, and repeat that in DS mode.
Someone bring up a topic.
I only know 3DS stuff, anyone good with the Wii U?
>And the WiiU contains both Wii and GC hardware
I don't think they have Wii and GC hardware in it. The CPU is just compatible because it has the same kind of cores. Same way a Wii had basically the same CPU as the GC.
Actually not sure myself. Probably just kernel memory pointers?
Different versions of the same arch. Here it means the two CPUs in the 3DS.
Thanks, so the console has several CPUs, I suppose that's what they call coprocessors?
About the pointers, see, I know very little programming, are the pointers in C the same as the pointers that are stored on CPU registers, simply memory addresses stored on variables or when talking about CPUs, stored on the registers?
>CPU is tri core PPC750-based.
But for GC/Wii mode, doesn't the Wii U still use that main tri core CPU? Or are you saying the ARM coprocessor is what was the main GC/Wii processor?
>Let’s go back in time to the Nintendo DS for a minute, that console has two CPUs in it. One is for 3D graphic processing (usually on the top screen), while the second CPU is generally for 2D processing (usually on the bottom screen) but it also had another function. That second CPU was a 32-bit ARM7, literally the same chip that was in the original Game Boy Advance – but just clocked at a higher rate. When players threw in a Game Boy Advance cartridge, said CPU was slowed down so that your DS was essentially a Game Boy Advance.
>Now fast forward to the Nintendo 3DS, it too has a couple of CPUs. It has it’s larger, dual core CPU in it as well as a smaller CPU which is, for all intents and purposes, a “Nintendo DS chip” and is the prime reason why the 3DS can play DS games perfectly – it’s actually is a Nintendo DS. Well, it’s clocked at the same speed as a Nintendo DSi, so it’s technically closer to one of those.
>And if you haven’t already guessed it, guess what, that chip can also be down-clocked to play Game Boy Advance games, so it’s not emulating the hardware – it’s simulating it. This is the reason the 3DS Home menu can’t be reached during the Game Boy Advance Ambassador games, nor the other system functions like the Friends List, Miiverse or Internet Browser. Why is this? Because the CPU is now playing Game Boy Advance games, usually that CPU is performing background tasks like powering the wireless on or checking your friends list to notify you when they come online. While it’s being used as a Game Boy Advance – it can’t do anything else at all.
Want to see some true wizardry? Fucking Asterix and Obelix XXL on a GBA looking better than some NDS games.
I have no idea how the shit they pulled this off.
Not sure about the Wii U exactly, but on the Wii the ARM926 (called Starlet by the homebrew community) was used as a kind of security coprocessor. It executed the boot code and run the IOSses (microkernels), so you could control the main processor via the ARM one. The main PPC processor was used to run the system menu, games, applications etc, so I think the Wii U handles it similar and the ARM processor is mainly used to do security stuff, run the IOSUs manage the PPC etc., while the PPC does the games, application, UI stuff etc., but I'm not sure.
I've seen FPGAs mentioned when talking about hacking consoles does anyone know anything about it?
I've found this:
But don't really understand a lot of it.