Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

github.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#21

Post by tsomctl »

eatonphil wrote: post #20

Myself curious to write a GB emulator... how do you get images? After a quick search I see a list of "homebrews" on a collection repo on GitHub [0]. Is there a particularly good place to find games? [0] https://github.com/gbdev/awesome-gbdev#homebrews

Being copyrighted, it's not legal to redistribute them. You're favorite torrent search engine might be able to help, though. Or you can buy them off eBay and dump the image yourself. I'm not sure what the current state of dumping hardware is, but 10 years ago I hacked together one that used a PC parallel port.

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#22

Post by BeefySwain »

p1necone wrote: post #18
userbinator wrote: post #16

Earlier quoted context omitted.

Highly unlikely, given all the other GB emulators that already exist, some of which are far more famous.

Yeah, until you start hosting roms I don't think Nintendo cares (although possibly begrudgingly). Once you do though... bad times. Nintendo has even used existing open source emulators themselves in commercial products.

> Nintendo has even used existing open source emulators themselves in commercial products.

Source? I'd love to read more about that.

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#23

Post by arthurcolle »

jhatemyjob wrote: post #10
furriephillips wrote: post #7

Earlier quoted context omitted.

Interestingly, not for the newer versions of OS X http://osxdaily.com/2018/07/18/get-telnet-macos/

Oh wow, that's terrible.

you can brew install it trivially, but yeah my 2018 MacBook Pro with macOS Mojave didn't have it preinstalled.

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#24

Post by segfaultbuserr »

caprese wrote: post #17
0_gravitas wrote: post #15

Earlier quoted context omitted.

Fork it while you can!

It is more important to clone it, so that you have a local copy on your PC forking is just a gesture, especially for obviously hot repos. a takedown of 1 can takedown all the forks

Yes. I cannot understand the point of those people who kept "forking" repositories on GitHub, but don't do any development on them. They have a long list of untouched forked repositories, like Linux kernel, Apache, nginx, ..., and makes it particularly difficult for me to find the repos of their original works.

Even as a "backup", it's pointless, because it's all Copy-on-Write, there's no backup.

As if they never learned to use the "Star" button to bookmark...

Personally, I don't fork any repos unless I'm working on a derived program, or working for a patch, even so, I'll delete my forked repos as soon as the patches are accepted (if it's a one-time contribution), so these forked repos won't spam my own list.

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#25

Post by cameronbrown »

BeefySwain wrote: post #22
p1necone wrote: post #18

Earlier quoted context omitted.

Yeah, until you start hosting roms I don't think Nintendo cares (although possibly begrudgingly). Once you do though... bad times. Nintendo has even used existing open source emulators themselves in commercial products.

> Nintendo has even used existing open source emulators themselves in commercial products. Source? I'd love to read more about that.

I could be wrong, but I believe they're using one in the NES Classic.

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#26

Post by cududa »

BeefySwain wrote: post #22
p1necone wrote: post #18

Earlier quoted context omitted.

Yeah, until you start hosting roms I don't think Nintendo cares (although possibly begrudgingly). Once you do though... bad times. Nintendo has even used existing open source emulators themselves in commercial products.

> Nintendo has even used existing open source emulators themselves in commercial products. Source? I'd love to read more about that.

I believe the NES classic and Switch use open source emulators?

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#27

Post by hcs »

BeefySwain wrote: post #22
p1necone wrote: post #18

Earlier quoted context omitted.

Yeah, until you start hosting roms I don't think Nintendo cares (although possibly begrudgingly). Once you do though... bad times. Nintendo has even used existing open source emulators themselves in commercial products.

> Nintendo has even used existing open source emulators themselves in commercial products. Source? I'd love to read more about that.

Best example I know of is PocketNES, but that was used by Jaleco in a GBA port:

https://waxy.org/2004/07/jaleco_borrows/

Nintendo has written or contracted a lot of emulators themselves. The grandparent may be thinking of the pervasive use of the iNES header format, which originated with an unofficial (though not open source) emulator:

https://wiki.nesdev.com/w/index.php/INES

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#28

Post by menzoic »

jchw wrote: post #13
userbinator wrote: post #11

A sign of the times: the use of the term "cloud gaming" to describe what would once be called "network play". The emulator will firstly break at the ROM entry point 0x0100 in debug mode, which is the entry point of the game program. That start address is the same as in CP/M, and subsequently DOS 16-bit COM-format binaries. I wonder if Nintendo was inspired by that.

The DMG boot ROM fits into the top 0x100 bytes. To protect it from being snooped, the last instruction shuts off the boot ROM by flipping a register that can’t be flipped back, mapping the top 0x100 back to the cartridge (and allowing the cartridges interrupt vectors to be installed.) So, there is no jump to 0x100 at any point; they just fit the DMG boots ROM perfectly into 0x100 bytes and control flow leaves bootstr…

The fact that it was undumped until recently makes me want to understand this more. Can you ELI5?

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#29

Post by EvanAnderson »

menzoic wrote: post #28
jchw wrote: post #13

Earlier quoted context omitted.

The DMG boot ROM fits into the top 0x100 bytes. To protect it from being snooped, the last instruction shuts off the boot ROM by flipping a register that can’t be flipped back, mapping the top 0x100 back to the cartridge (and allowing the cartridges interrupt vectors to be installed.) So, there is no jump to 0x100 at any point; they just fit the DMG boots ROM perfectly into 0x100 bytes and control flow leaves bootstr…

The fact that it was undumped until recently makes me want to understand this more. Can you ELI5?

There's a description of the particular fault injection used for the Gameboy Color here: https://www.its.caltech.edu/~costis/sgb_hack/

Fault injection is a method to cause microprocessors to execute instructions "incorrectly" by manipulating external factors (clock frequency, input power, etc). Getting the CPU to fail to write to a memory address, or flipping the truth of a comparison instruction, and other "glitches" can influence execution of security-sensitive code and ultimately undermine security mechanisms.

The original Gameboy ROM was dumped by physically de-capping the chip and reading out the bits: https://dot-matrix-game.blogspot.com/2014/01/boot-roms.html

Re: Gameboy.live: A basic Gameboy emulator with terminal “cloud gaming” support

#30

Post by colejohnson66 »

pkaye wrote: post #12
userbinator wrote: post #11

A sign of the times: the use of the term "cloud gaming" to describe what would once be called "network play". The emulator will firstly break at the ROM entry point 0x0100 in debug mode, which is the entry point of the game program. That start address is the same as in CP/M, and subsequently DOS 16-bit COM-format binaries. I wonder if Nintendo was inspired by that.

Probably because the lower addresses are for the interrupt vector table.

No. Execution actually starts at 0x0 like most architectures, but the boot loader fits in the first 256 bytes, so after the last instruction executes, execution continues on at 0x100
Post reply on HN