Gameboy Emulator

It's fine. Honestly I know very little about emulation besides the dumber down version of how it works.

I mean, I've never written a gb emulator, but I'm guessing you haven't either. It's a bytecode (plus headers and data regions and whatever) but "you can't do this" isn't really correct. The work required for an emulator and the work required for a transpiler are very similar in this case, um, and the reason it wouldn't be a good idea is because setting up arbitrary jumps is a dumb hack and you'd just end up writing 7/8ths of an emulator anyway. with emulators the problem isn't really instruction interpretation so much as emulating the timings and quirks of the original machine: running generic z80 code in smilebasic is (probably) not difficult, running "Nintendo GameBoy" needs a lot more attention to all the little quirks or nothing will run correctly. So part of the challenge is doing it right, which is a lot harder if you try to compile to another language. and assembly vs. bytecode doesn't really matter. The point of an assembly language is to map very closely to the bytecode: they encode the same information. You can't read the Demotic part of the Rosetta Stone, but that doesn't mean that it can't be read or isn't useful. Since any assembly syntax you find isn't going to be valid SmileBASIC (if it were, you could approach the problem as "make a library that implements these instructions"), that doesn't help: you're either parsing and interpreting assembly mnemoniccs or interpreting bytecode. Bytecode is easier.

Yttria, are you referencing to my idea or something else? Because emulation is just interpreting, and if you are interpreting javascript from c++ to draw a rectangle, it is much quicker to just draw the rectangle in c++(that isnt what javascript is for, but it shows the point) I'm not saying dont write a working emulator. while slow, it would be impressive. However, I do think the gameboy to smilebasic would be an interesting thing to persue. Someone did an almost exact port of celeste classic doing it manually, and I know this because some of the bugs that are in the original are also in the port.

hi

It’s a family reunion

Hehehe… I haven’t really been working on my emulator much. I need a new battery for my 3DS because my current one is very swollen. Once I return home, I may either work on it some more or post the code to GitHub: I haven’t had much motivation to work on it. Most of the CPU and GPU is finished. I think I really only need to work on special registers, timers, improve interrupt handeling, and implement memory banking.

[ Sorry for the massive misinformation, I guess. Guess I had some information mixed up or something.

.gb files hold machine code, which is the assembled form of assembly, as well as data of the ROM.

I have an idea for how you could "emulate" a gameboy on smilebasic. Instead of reading the ROM of a game and converting it in real time, you could create a script to convert the entire thing into smilebasic code and sprites/backgrounds(in smilebasic of course). You wouldn't be truly emulating a gameboy, but it would(in theory) truly emulate a gameboy game, and it would run very well. You could potentially totally so this for nes/SNES games, but I'm not the one making emulators here.

Like a "Virtual Gameboy", NOT a "Gameboy Emulator".

Impressive. Hope you get it working. So my idea, is people make ports to the game, and it is run by this virtual gameboy?

Window and MBC1 implemented

so like uh i don't quite wanna go way back through this thread, how's this intended to work?

It's just supposed to be a gameboy emulator. I just recommended a gameboy-to-SmileBASIC converted so that the framerates would be playable, but they want true emulation, which is probably fun to program, but not supposed to be playable.

I have an idea for how you could "emulate" a gameboy on smilebasic. Instead of reading the ROM of a game and converting it in real time, you could create a script to convert the entire thing into smilebasic code and sprites/backgrounds(in smilebasic of course). You wouldn't be truly emulating a gameboy, but it would(in theory) truly emulate a gameboy game, and it would run very well. You could potentially totally so this for nes/SNES games, but I'm not the one making emulators here.

What about QIX?

What about QIX?

Well I don't know why you quoted what Vakore said, but yes if the emulator is done you will probably be able to play it on there.

What about QIX?

Well I don't know why you quoted what Vakore said, but yes if the emulator is done you will probably be able to play it on there.

That's because it's my favorite game, thats why I'm asking to.

I always liked Qix too, anyone know how the fill algorithm in that game works?

I always liked Qix too, anyone know how the fill algorithm in that game works?

I was thinking to make a port of it.

Reason:

Because it's addictive

Reason 2:

And fun

Reason 3:

And cool

Maybe this will help. https://youtu.be/_5W5sYjDBnA I look forward to your QIX port.

@SaladFingers, which things haven't been implemented yet, that you still need to do? (Other people might be able to help you with those things)

Compiling GBz80 machine code to SmileBASIC code isn't as viable as you'd think for several reasons:

• Executable code is not always aligned. Instructions on the GBz80 are variable width, and the code might also come after data the program might read. You might end up compiling completely incorrect code.
• Programs that execute from non-ROM areas won't work. A lot of software more than likely at some point will run code from WRAM/VRAM/HRAM/OAM. For example, Pokémon Red/Blue/Yellow store the current map script in External RAM. This also means that Arbitrary Code Execution won't work.
• The memory map is not static. The Game Boy can access up to 32KB ROM at a time, so by telling the Memory Bank Controller cartridges have to swap banks, the latter 16KB bank is swapped out for another bank. This also applies to External RAM on the cartridge (usually battery packed), you can only access 8KB of External RAM at a given time. Additionally, the Game Boy Color includes extra VRAM and WRAM. (8KB VRAM on GB, can be swapped for another 8KB, and 8KB WRAM, latter 4KB can be swapped for 6 other 4KB banks)

Compiling GBz80 machine code to SmileBASIC code isn't as viable as you'd think for several reasons:

• Executable code is not always aligned. Instructions on the GBz80 are variable width, and the code might also come after data the program might read. You might end up compiling completely incorrect code.
• Programs that execute from non-ROM areas won't work. A lot of software more than likely at some point will run code from WRAM/VRAM/HRAM/OAM. For example, Pokémon Red/Blue/Yellow store the current map script in External RAM. This also means that Arbitrary Code Execution won't work.
• The memory map is not static. The Game Boy can access up to 32KB ROM at a time, so by telling the Memory Bank Controller cartridges have to swap banks, the latter 16KB bank is swapped out for another bank. This also applies to External RAM on the cartridge (usually battery packed), you can only access 8KB of External RAM at a given time. Additionally, the Game Boy Color includes extra VRAM and WRAM. (8KB VRAM on GB, can be swapped for another 8KB, and 8KB WRAM, latter 4KB can be swapped for 6 other 4KB banks)

You obviously know more than me, but allow my lac-of-knowledge to give some ideas that probably wont work at all and I'm miss g something completely. A: I'm sure someone could figure that out. Doesnt even have to be I. SmileBASIC, could be in Javascript. B:Functions and arrays to handle that maybe? Easy, no, possible, eh? C: So... have separate script files?

Compiling GBz80 machine code to SmileBASIC code isn't as viable as you'd think for several reasons:

• Executable code is not always aligned. Instructions on the GBz80 are variable width, and the code might also come after data the program might read. You might end up compiling completely incorrect code.
• Programs that execute from non-ROM areas won't work. A lot of software more than likely at some point will run code from WRAM/VRAM/HRAM/OAM. For example, Pokémon Red/Blue/Yellow store the current map script in External RAM. This also means that Arbitrary Code Execution won't work.
• The memory map is not static. The Game Boy can access up to 32KB ROM at a time, so by telling the Memory Bank Controller cartridges have to swap banks, the latter 16KB bank is swapped out for another bank. This also applies to External RAM on the cartridge (usually battery packed), you can only access 8KB of External RAM at a given time. Additionally, the Game Boy Color includes extra VRAM and WRAM. (8KB VRAM on GB, can be swapped for another 8KB, and 8KB WRAM, latter 4KB can be swapped for 6 other 4KB banks)

You obviously know more than me, but allow my lac-of-knowledge to give some ideas that probably wont work at all and I'm miss g something completely. A: I'm sure someone could figure that out. Doesnt even have to be I. SmileBASIC, could be in Javascript. B:Functions and arrays to handle that maybe? Easy, no, possible, eh? C: So... have separate script files?

A: Sounds theoretically feasible B: It wouldn't be convenient for compiled code to depend on runtime stuff. C: No. Sometimes code gets executed dynamically, meaning you can't simply put 'scripts', as it's behavior isn't usually deterministic.