We lost a lot of speed in running the emu since b49f76f .

After doing some research, the PR #38 was not the culprit, but rather #40 , I suspect that doing all the jumping between JS and Wasm to grab constants is adding a huge overhead, so we should simply cache these constants in function calls on initialize :).

Should also investigate PRs beyond #38 as well

• Channel 1 sweep sometimes starts way too low. For instance, try jumping down a cliff in Links Awakening 2.
• Channel 4 sounds a little too spray-y like almost if the noise is fanned out. Also, lightning isn't very loud in links awakening 2, but waves are.
• Audio starts on all games very loud with a random noise.
• A lot of TODOs, Especially applying master volume
• Audio Has trouble keeping up

Create a seperate set of tests that can run the gameboy, and test how long it takes to run X frames on Y rom.

Demos are good because they don't require input.

Such as the "Demo in your pocket", and the awesome-gb dudes recommended "Demotronic"

Continuation of #42

Identify Gameboy games and rooms by their header (either titles or checksums)

http://gbdev.gg8.se/wiki/articles/Gameboy_ROM_Header_Info

https://www.google.com/amp/s/amp.reddit.com/r/EmuDev/comments/6bettn/list_of_all_gbgbc_rom_cartridge_information_with/

Read that catridge ram is battery powered. May just want to save the catridge ram in memory. Which equates to about 50 games of ram being able to be saved in memory :)

http://gbdev.gg8.se/wiki/articles/Memory_Bank_Controllers#A000-BFFF_-_RAM_Bank_00-03.2C_if_any_.28Read.2FWrite.29

https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/offline-for-pwa

https://developers.google.com/web/fundamentals/app-install-banners/

Ionic handles app resources caching we just gotta save save files again pico deploy style with idb-keyval, which supports saving arrays and objects :)

https://www.google.com/amp/s/blog.ionicframework.com/how-to-make-pwas-with-ionic/amp/

• Run the bootrom, get some pixels drawn, and scroll the logo
• Code Cleanup
• Make a more legit debugger
• Run the cpu_instructs test rom, and fix bugs
• Move opcode feeding into wasm. And have js poll for when it should render. (Maybe a flag in memory?)
• Get Tetris to play
• Wasmboy memory map
• Rom Banking
• Joypad support
• Fix Graphical Bugs
• Get Sound
• Get In-game saves (Cartridge RAM -> IndexedDB)
• Get Save States (Everything -> IndexedDB)
• Beta Gameboy Color Support
• Cry tears of happiness
• More Optional Performance Hacks
• Code Cleanup
• Update the README
• Get ready for publish to npm
• Publish to npm
• Make "frontends" for the Wasmboy lib
• Improve Accuracy / More Test Roms (With maybe some help from the community? :) )

That way we can render our scanlines and respect any changes as we go along our cycles, rather than waiting until X cycles, and then drawing the entire scanline.

One thing to keep in mind:

As suggested by ISSOtm:

Possible allocation strategy :

• Allocate one page
• Dump ROM0 and ROM1, which always exist, in the first 32kB
• Check cart header
• Grow() accordingly, and dump ROM
• Grow() by one page for the rest of the memory (2 pages if it turns out more is needed, though)
  (Btw, 1 page spans 4 ROM banks)

After referencing the Wasmboy memory map

It is quite odd, and can't seem to figure out why. As Joypad interrupts happen whenever a button is pressed. And in Dr. Mario, the interrupt causes an opcode that doesn't exist :p

Found by @ISSOtm

https://github.com/torch2424/wasmBoy/blob/f32b85f27999ba756e6ea0276dcade02b6434fea/wasm/memory/dma.ts#L51-L60

It makes more sense this way in the whole architecture of the application. and makes it easier to distinguish between the "frontend Js lib api", and the "backend web assembly core"

https://www.nintendo.com/corp/legal.jsp#roms

https://www.howtogeek.com/262758/is-downloading-retro-video-game-roms-ever-legal/

https://www.reddit.com/r/emulation/comments/6at4bm/best_way_to_rip_cartridges_in_2017/

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

As the title states, see the opcodes.ts TODO

Once you load a game, if you try to reload another game after starting playing, it will not work :(

continuation of #42

Would make breakpoints and stepping much more visual and easier!

Optimizing has been a ton of fun. But here's what I'm learning (shoutout to @binji):

Ask yourself these things:

"What can I pull out of the main loop?"
"What can I assume will not change?"
"What can I assume has not changed until a write to memory?"
"What can be cached to speed up.individual loops?"

Some Quick ideas:

• Interrupts enabled/requested registers. If both are less than or equal too zero, skip.

• Tile caching. Would require Assembly script maps to be completed. Could cache tiles, and discard them if we find that they changed.

• Add more checks in memory.

Watch the ultimate Gameboy talk, with performance in mind

http://papers.traustikristjansson.info/?p=486

https://developer.mozilla.org/en-US/docs/Web/API/AudioBuffer

https://stackoverflow.com/questions/26068249/appending-data-to-an-already-existing-audiobuffer-object

https://developer.mozilla.org/en-US/docs/Web/API/AudioScheduledSourceNode/start

http://webaudioapi.com/samples/

https://stackoverflow.com/questions/37459231/webaudio-seamlessly-playing-sequence-of-audio-chunks

https://github.com/brion/audio-feeder

Chrome mobile lags, mobile firefox does not

You can try turning off some of the other sound channels in another emulator so you know what your channel is supposed to sound like

Super Mario Land has a bit of a tune on ch2 I think

https://binji.github.io/2017/02/27/binjgb-on-the-web-part-2.html

By exporting the constants making up the memory map, both the JS and Rust emulator can just make use of the AssemblyScript constants.

I just tested it and you can just export them as such:

export const BLA: usize = 5;

(global $BLA (export "BLA") i32 (i32.const 5))

Still can't figure out why I am getting no pixels :'(

Continuation of #42

This was libraries using wasmboy will not have constant logging in their application

Right now, it is a little bit slower, and found the following:

https://stackoverflow.com/questions/48173979/why-is-webassembly-function-almost-300-time-slower-than-same-js-function

Therefore, me repetedly calling Wasm in my loop has a good amount of overhead, and should really look into moving the "emulation loop", entirely into Wasm. Probably just run the number of cycles, and wait for the loop call again before starting back up.

Can get super far ahead or behind while switching games

Run Blargg tests and screenshot:

https://www.npmjs.com/package/puppeteer-screenshot-tester

Or do it like this

https://github.com/binji/binjgb/blob/master/src/tester.c#L26-L45

Need to use Rollup Which not only does cool tree shaking and stuff, but I guess is the best way to build ES6 modules, for both browsers and node :)

And then also need to use Rollup Wasm and probably some other plugins

This issue is not a general compatibility table, but for now, is just a personal reference of games that do or do not work to help with general compatibility and in determining beta vs. stable status of the core in general

Compatibility Notes

• Donkey Kong Country - Really messed up graphically, and can't get past the level select screen without crashing. The game tries to do an OAM within 0xFFXX, but IO am assuming it does not correctly get written and breaks. Fixed with #75

• Bionic Commando - Sound does some weirdness, game play fine however

• GBC Spongebob - Level Background loads incorrectly, and looks super weird

• Wario Land 3 - LYC is checked too late, and Palettes are messed up

• Crystalis - Same situation as bionic commando

• Kirby's Dreamland - We get an opcode crash after the first level intro cutscene. Was a timing issue, fixed with #193

• Link's Awakening - Intro "Cha-Ching" is incorrect. Thanks @Malax 😄

May need to also store somewhere all of the keys currently in memory, so we know how to retrieve everything.

BUt this would be handy for backups with google drive that automatically sync or something :) Could be utilized by a frontend

As the title states, makes sense that is why the test roms didn't show at first

This commit changed the memory base to 0, causing it to only preallocate 1 page: eec0552

JS / Rust shouldn't need to grow the memory though. This can either be changed back or AssemblyScript can just grow the memory itself. This also means that the call can be removed in JS altogether.

See: AssemblyScript/assemblyscript#17

Seems like Maps may already be in the project?

Need to do some logging to make sure that we are passing the correct configuration params.

Also, may want to run an (3 runs per option) average, because I am noticing that results can vary kind of wildly at times.

https://stackoverflow.com/questions/36908427/webgl-vs-canvas-2d-hardware-acceleration?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

https://medium.com/@andrewimm/writing-a-game-boy-emulator-in-wasm-part-1-1ba023eb2c7c

Similar to BGB, continuation of #42

This would allow for things like TAS (Tool Assisted Speedruns)

https://git-scm.com/docs/gitattributes

# .gitattributes
* text=auto
*.js text
*.css text

# help to Github linguist determine this code as AssemblyScript mostly
*.ts linguist-language=AssemblyScript

In order to get the repo to recognize assemblyscript :)

So, the only good way I could think of handling the Sprite vs. BG/Window priority weirdness, was to keep track of what we drew on our Bg/Window Layer.

So, we need to update the memory map for a 160 x 144 2d array type thing, where 1 byte represents one pixel.

Bits 0 & 1 will represent the color Id drawn by the BG/Window
Bit 2 will represent if the Bg/Window has GBC priority.

Not going to do this per tile, juuusssttt in case there is some craziness that can happen in between drawing a tile

Found this to be most supported / easiest:
https://www.npmjs.com/package/jszip

Right now, it's just hard coded. We should allow adjusting this, as I'm having a hard time determining approximately how many fps I am getting compared to enabling/disabling them on other devices

This will allow us to run tests for something like all audio, or all graphics 😄

Would be a good/easy way to get the emulator working with homebrew, and more stable in general. would be a lot of fun since @ISSOtm and I hang out in the discord often 😄

Also! All of the emulator quality checks are here: https://github.com/ISSOtm/Aevilia-GB/blob/master/home.asm

Should go through and try to pass some of these, just so we can hopefully pass other homebrew tests in the future 👍

Also related to #65

Since we are about to start wrapping things up. We should try to write docs for the API that we should have, and then refactor the code accordingly. That way we can get some other eyes on the API, and names and things, and then implement all at once.

The old current API, can be preserved in the index.ts, by exporting the new API with the old naming :)

Also, decided to use github wikis for docs. Since, it is probably most well know, git books are kind of confusing for me to navigate (personally), and doing the monolithic/documentation directory approach
that create-reat-app follows is kind of awkward for navigating, and sometimes finding things.

Similar to BGB, continuation of #42

Saving on exit does not always work. Sometimes it will save and load the cartridge ram, but other times it will not :(

587897a

Blargg Tests

• 01-special - Get stuck in an infinite loop without saying passed
• 02-interrupts

See #49 , Super simple fix, just need to add support for tile flipping/mirroring when rendering the entire tile at once 😄

Look into Link Cable Emulation

Goal would to be have it done over WebRtc with a peer to peer connection, using something like simple-peer or PeerJs

Similar to Bgb, would be helpful for Gb Game Devs :)

Currently using: https://www.npmjs.com/package/rollup-plugin-webassembly

Since https://www.npmjs.com/package/rollup-plugin-wasm was giving a weird index error