Rewrite about gameboy-online HOT 12 OPEN

That was 2 years ago, I'm not as skilled at making an emulator as I had hoped but wouldn't mind collaborating with someone on this idea, I'm just not able to do it all from scratch like I had hoped plus I've gotten busy with other stuff in life.

Basically if anybody is wanting to start this I'd be happy to work with them closely on it but can't do it all alone which is why I dropped it earlier. Just let me know ^_^ But I am still all for this idea

from gameboy-online.

Why I wanted to write an emulator

One thing that prompted me to write an emulator was to implement stuff I just never see in any emulator today. Emulators today only focus on making "old gameboy roms" work as in just the rom code itself (which is essentially the game), and while you may be thinking "well that's why we call it an emulator" a true emulator goes a bit deeper and as a result really pays off.

Cartridges can have small or big modifications to them

Like for example, it's nice to read the cartridge type and just load some class, piece of code, or whatnot to work with the ROM accordingly so we know if the cartridge has a memory bank or what kind of memory bank or what other features like RTC timer, SRAM, etc etc... But all of these are predefined (How the RTC time works in MBC3) max capacities of each MBC3, many emulators just battery back all SRAM.

In reality though this is a pretty rigid system and one of the most focal points that would set a publishers game apart from the competition is the only thing the publisher can control, their cartridge. I've heard of amazing crazy stories of publishers in the past getting insanely creative for their cartridges even up to linking it to a computer (back then) and providing downloadable roms to play until you get bored and download new ones. I'm pretty sure that's outside the boundaries of the cartridge type in the header. I've heard some carts even left out cartridge features like non battery-backed RAM which emulators battery back anyways because it can't hurt. If it doesn't fit into one of the preset cartridge header type model or it's not fully supported then it's just not properly emulated and the cartridge header type defines the entirety of the cartridge itself for all games with the same header type code.

A cartridge needs to be seperate

The cartridge is a piece of hardware, it's a circuit board, a literal old-fashioned hardware "plugin" to use a modern term. It can be built however the publisher wants it to be built, and while existing carts or pieces were bought from companies that mass made them the cart itself could still be modified if needed. What if I want to leave out the battery on SRAM to save cost and just have extra RAM? What if I want to wire things up differently or get creative?

The cartridge needs to be separate (I'm sure through planning we can easily figure it out, it was more the emulator itself proved more a daunting task for my busy life especially then lol) and I'm not suggesting to emulate the bare wires and all but by inserting a cartridge into the emulator rather than a rom code into the emulator your rolling this out really how it should be especially if it's open source since cartridges are now self-contained "plugins" that contain rom code and any number of other stuff while the emulator itself doesn't care at all, it just follows normal Game Boy operations and the cart behaves independently making collaboration on the old preset cartridges easier such as with bug fixes or stuff not implemented well.

I mean don't forget about those cartridges that were in, and of, themselves also cartridges like Gameshark for example (Even though yes I'm familiar that "Gameshark" is a feature, usually a GUI window, in emulators).

It would also allow a deeper debugging of the cartridge and it's internals in a debugger which makes sense to have (many emulators don't have it) and also makes sense it's somehow detangled from the gameboy system

It brings more life, creativity, and fun competition to homebrew

The homebrew community gets the same opportunities publishers did

But of course apart from advantages you gain with a proper emulation you have the next advantage, homebrew games (By the way I'm not a homebrew game maker, too much goes into making a game and I'd rather make an emulator instead lol). But just like everyone wants to write an emulator to kind of delve deeper into the device they used all the time reliving their childhood nostalgia on a more technical level, many also want to write a gameboy game to kind of walk in the shoes of publishers back then, another way of reliving childhood nostalgia on a more technical level.

Homebrew games are popping up quite a lot and I was surprised to find a "store" of them, it's not quite fair to constrain hombrew development to a list of common cartridge presets dependent entirely on the implementation level of them in the emulator. Like what if I want to implement the wiring a bit different (different rom or ram usage), or MBC a bit differently, perhaps a bigger or smaller MBC or one with interesting features. I would want the same opportunities now (if I were to make a homebrew game) that publishers did then because as I said earlier the cartridge is the only thing the publisher can control to give an edge on their game from other games.

Anyways that was the focal point of my emulator I was attempting because it's a feature I never see but very much want to see as an option in the homebrew community.

Some rough ideas

A general plan I had worked out is the following in case your wondering how in the world can this be done sanely and well.

• The GUI would say something like "Load Game..." and "Load Custom Cartridge..." (Problem solved in making things not complicated for the end-user while also getting the attention of the more developer oriented people). Load Game would do like any other emulator (Read the rom cart type header code and load up a preset cartridge based on that, it would still be a fully independent cartridge, just one of many internal presets ) - Load custom cartridge would load the full cartridge (Containing ROM and/or RAM) or whatever else directly

• The cartridge would be written like a plugin using a good plugin language like Javascript, LUA, Java, or similar (Anything cross-compatible compiled or doesn't need compiling) (Obviously Javascript in the case of this project)

• Since the universal SAV and ROM files are important and we don't want to forgo that since any other emulator can just pick them back up. The cartridge API can reference them externally. Some things may be a bit complicated especially if using a custom MBC and exporting to a flat ROM and SAV file to be used in other emulators, but I'd say provide the API and let the individual cartridge maker figure things out either for old published cartridges or for homebrew cartridges. Both can have custom components or modifications that make porting to the old universal ROM and SAV format have their individual challenges.

• The emulator would send the plugin the same signals the cartridge would get in the Game Boy and the cartridge would have to make do but have room to do whatever it wanted to "in-house" using whatever hardware components it internally had like MBC, a custom MBC, etc... All could be easily implemented using a common and simple API the emulator offers and constrains to keep things realistic to the Game Boy hardware

• Also since cartridges become independent from the code, depending on how their modeled they may be able to be universal to a degree to other emulators especially in the same language or at least adaptable to other emulators so that we can have a more unified cartridge implementation instead of it being iffy between different emulators (We'd rely less on the emulator creator being awesome at implementing them and the creator could just take an existing implementation rather than make one from scratch)

It's just some rough ideas but maybe this can happen and I'd love more than anything to be a part of it

On a last but separate note

Apart from accuracy I was also aiming for features. I love the BGB debugger but would want to make it much more modern and more capable such as delving into the MBC controllers and stuff or offering more capabilities. Basically kind of bringing back good features strolled across several emulators that people love.

So sorry for long post but figured I'd share that and why I wanted to do all this. It's something I've been wanting to do, just can't do alone but I'm also not looking to make "Yet another emulator" ^_^

from gameboy-online.

Here is an example file of ideally how the cartridge code (outlined in my long post above) should be in a Javascript emulator. It's something I came up with after lots of research, a bit rough, but thinking about trying my hand at an emulator again so at least this is laid out for now.

https://pastebin.com/uTYNzBn5

from gameboy-online.

I'd like to ask you some questions about your project to help speedup my rewrite but if your uninterested in my rewrite or pull-request back to your project when I'm done then good luck with the project when you get a chance and awesome job on it.

from gameboy-online.

The rewrite is interesting. I am interested, although not sure on final direction.

Please note on some performance best practices before you continue further though:

• In IonMonkey it has been proven that switches are faster than function jump tables.
• Function jump tables are always faster than if/else chains.
• Probably should remove all string handling and error checking within the code, and run raw.
• Use bitwise operators for local scope integer type validation, and to assist type inference.

In addition, I am working on the audio backend being rewritten to support Audio Workers in the web audio API and the existing XAudioJS API is being thrown out completely with a multi-threaded ring buffer based API. The Audio Worker support necessitates the API change.

Accuracy wise, GameBoy Online sucked hard. Recent developments by other people has resulting in intra-instruction timing being documented. Therefore, a rewrite should clock within the instructions rather than once after each. GameBoy Online's handling of DMA and mid-scanline rendering was a total hackjob as well. Those systemic issues should be cleared up before continuation.

from gameboy-online.

Also a rewrite should look into asm.js, since older browsers can just use the original deprecated version.

from gameboy-online.

Hey Guys, any updates on this? :)

Or have the rewrite efforts been discontinued? I recently gotten back to homebrew gb development and noticed that the original repository had moved.

A year or two back I tried to add debugging capabilities to GameBoy Online but that turned out to be a rather hard thing to do due to the current state of the code base.

I would definitely be happy to help out in the efforts since a more modular design should make it possible to add a debugger "interface" of sorts so one could build a nice debugging / development app around the emulator.

from gameboy-online.

Progress is still active for my rewrite its just painstakingly slow as I've moved and have gotten quite busy with a new job. On my rewrite i welcome any additional help but overall in general i hope to see a good rewrite finished as this is a great project.

from gameboy-online.

Recently AudioWorklet spec has gained traction, so I might actually care to wrap up the xaudiojs redo.

from gameboy-online.

Sounds very interesting, is there any updates ? The link to /js2/system no longer works?

from gameboy-online.

@junebug12851

from gameboy-online.

@junebug12851 I'm also not good at writing an emulator, but maybe I can help with JavaScript and NodeJS?

from gameboy-online.