? Gameboy Emulator (Page 7) ● SmileBASIC Source Forums

Sign In

*Usernames are case-sensitive
Forgot my password

Gameboy Emulator

1 2 3 4 5 6 7
  • #121 ✎ 67 Vakore It's fine. Honestly I know very little about emulation besides the dumber down version of how it works. Posted
  • #122 ✎ 1020 Yttria 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. Posted
  • #123 ✎ 67 Vakore 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. Posted
  • #124 ✎ 48 SaladFingers
    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.
  • #125 ✎ 161 the_squat1115 Minecraft Is Awesome! I love Minecraft! Express Yourself Intermediate Programmer I can make programs, but I still have trouble here and there. Programming Strength Video Games I like to play video games! Hobbies
    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".
  • #126 ✎ 56 Zypher Impressive. Hope you get it working. So my idea, is people make ports to the game, and it is run by this virtual gameboy? Posted
1 2 3 4 5 6 7