In theory you should be able to get everything working at once, if you don't mess up somewhere. (when you finish the core + opcodes + graphics)

Not quite, most games use a technique called cart banking whereby they swap in banks of cart data in order to have roms larger than 32KB on a 16Bit address bus. This is a feature not used in Tetris to ensure the Core/Graphics/Interupts are all working as intended.

I'm introducing each feature once the feature done prior to it is 100% working and tested working to make bug hunting easier.

But if you could implement gameboy advanced after you finish that would be fantastic.

I meant that it wouldn't be playable at any kind of decent speed on even very high end systems, the display is almost twice the size of the original Gameboy, this alone is already bordering on prohibitive as we're already "cheating" to get what we can to keep the Gameboy emulator playable. Let alone the obviously considerably more beefy ARM processor running alongside a Z80 co-processor in the GBA.

Perhaps when LuaJIT is implemented and Lua is done in a separate thread than the source engine.

I meant that it wouldn't be playable at any kind of decent speed on even very high end systems, the display is almost twice the size of the original Gameboy, this alone is already bordering on prohibitive as we're already "cheating" to get what we can to keep the Gameboy emulator playable. Let alone the obviously considerably more beefy ARM processor running alongside a Z80 co-processor in the GBA.

Perhaps when LuaJIT is implemented and Lua is done in a separate thread than the source engine.

I see. Well whatever. It'll be a pleasure just to play classic games anyways.

Made some HUGE progress over the last day. The CPU core is now almost complete and boasts superior emulation than Visual Boy Advance. The GPU has been re-written and accurately reflects what a real Gameboy would display. All Interrupts are now emulated. Input is now fully emulated. Tetris now runs flawlessly.

Yes there are currently a few performance issues but they're entirely Lua based and we hope to weed out an additional 2 to 3 x performance by optimising the think() routine based on scanline cycles and converting various else-if stacks to lookups.

a few preliminary optimisations and Pokemon is playing excellently, from 10fps in the video above to now 20-40fps with a 30fps average. Pokemon is essentially realtime on my i3, most Gameboy games should be now too.

a few preliminary optimisations and Pokemon is playing excellently, from 10fps in the video above to now 20-40fps with a 30fps average. Pokemon is essentially realtime on my i3, most Gameboy games should be now too.

So how does the hole rom thing work? Does the server require the rom? Does the client? What if someone has a slow connection and they receive the rom slower then others?

In multiplayer each client runs their own instance of the emulator, there's no syncing at all currently. That's the feature we plan to add after we've finished the first optimisation pass.

However the way it'll likely work is that each "frame" the emulator runs the key-presses will be stored and sent to the server along with a frame ID. The server will store around 3600 frame's at any one time, sending them in packets of 100 or so to the clients (so clients will be a second or two behind the person playing, there's no issue if there's no interaction). Every minute the playing client will upload a keyframe which will be the entirity of the processors current state, a good ~60-70kb.

With little editing, I could make the emulator available client side so that the server doesn't need to have it installed. It'd be a little odd standing in the middle of a server apparently doing nothing (so like an average day in a wiremod server with E2) :P

The server does nothing apart from spawn the entity to render on at the moment.
Soon, it will help in handling key syncing and status checking (regular hashes of the emulator state sent to all clients to make sure they are at the same state), so everyone can see what you see.

In multiplayer each client runs their own instance of the emulator, there's no syncing at all currently. That's the feature we plan to add after we've finished the first optimisation pass.

However the way it'll likely work is that each "frame" the emulator runs the key-presses will be stored and sent to the server along with a frame ID. The server will store around 3600 frame's at any one time, sending them in packets of 100 or so to the clients (so clients will be a second or two behind the person playing, there's no issue if there's no interaction). Every minute the playing client will upload a keyframe which will be the entirity of the processors current state, a good ~60-70kb.

Release Notes:
Speed is still an issue but it should run at real time or close to real time at a decent frame rate on any modern processor.
It'll work in MP kinda, everyone will run their own instance of the emulator with no syncing.
The GPU code is prone to glitches, unless it's something major don't report it.
Only MBC3, MBC1 and ROM games are supported and there's no "bounds", if a game makes a rom banking mistake that a real Gameboy would check for the emulation will likely fail and crash with the stack pointer or program counter overflowing.
Tetris and Pokemon are confirmed to be 100% working, at least at the start. If you find any MBC1, 3 or ROM games which glitch report it to me.
Rom files are currently stored in plain text hex (see below), no rom files are given away in the emulator. Once converted into plain text hex rom files should be stored in GEM/Data/GBZ80 for gameboy.
No saving currently.
Please do not upload this elsewhere.

Rom files are currently read in plain text hex because Lua's binary reading support is incomplete and cannot load roms with the 0D0A character in. a plain text hex file is just that, with each byte being represented by two ASCII hexadecimal character in capitals with no other information. One method to convert to Plain Text Hex is to download the hex editor FlexHex, load the rom there, copy all the hex into NP++ and find replace the spaces. All rom files should be .txt. If someone would like to write a quick python script for the public to convert to plain text hex that'd be great, I'd do it but I'm hoping this is just a temporary measure until binary reading is fixed.