Occasional lurker, decided to join.

Natorite

New Member
OP
Newbie
Joined
Mar 31, 2017
Messages
4
Trophies
0
Location
USA
XP
21
Country
United States
Hey guys, I've been occasionally visiting this forum for a few years but never decided to join until now.

I'm a CS student with a weird passion about developing retro emulators. I'm currently working on a set of Gameboy (DMG only) tools including an emulator (w/ debugger of course), disassembler, and possible an assembler/compiler for my "Capstone" project at my university. I graduate in about a year and a half.

Note on the Capstone: My school has its students do "Capstone" projects before we're allowed to take our Enterprise Projects courses, in which we get together in teams and do projects for companies to get real-world experience for nearly an entire year before graduating. (New project/company every few months). The point of the Capstone project is to show that we are able to go through with a project and that we are competent with our skills and ready to take on a real-world project.

I work as a Software Engineer Intern with a company in the same city as my university, as well as an Academic Coach for the Freshmen and Sophomores at my university.

My main interests in console hacking and emulation design/development has brought me to join here. It's been a while since I've joined a forum and was active, so I'm excited. Looks like a great community here.
 
  • Like
Reactions: WeedZ

Natorite

New Member
OP
Newbie
Joined
Mar 31, 2017
Messages
4
Trophies
0
Location
USA
XP
21
Country
United States
Welcome to the community
Thanks!

Well, it's a pleasure to have you! Retro emulators today, I find, are very lacking in terms of their input lag, so it'll be great to have someone with a passion in that area joining the community. Cool to have you, and I hope you like it here. :)
Can you explain what you mean by their input lag a little better? It might be something I should look into.

At the moment, I'm still working on getting the processor emulation and the VM running smoothly.
Something interesting that I'm trying to do is step away from the "Fetch->Decode->Execute" cycle where the CPU opcodes are interpreted, over to essentially a Just-In-Time dynamic recompilation. It should look something like this (I'm aiming for O(1) times across the board):
  1. Start execution at usual entry point, $100.
  2. For each instruction up until the next branch/jump, store it in a HashSet of Action delegates and execute the instruction.
  3. Once reaching a branch/jump, store the HashSet and original jump address that brought you there into a Dictionary<Address, HashSet<Instruction>>, if the dictionary does not already contain an entry for the jump address.
  4. If the Dictionary contains an entry for the address the jump you've reached wants to jump to, then retrieve that HashSet of instructions and execute through it.
  5. Else, goto 2.
EDIT: Sorry for the swe jargon. The Dictionary and HashSet data structures all have O(1) lookup/access times, so regardless of how big the data gets, I will have no difference in performance. Retrieving a value from a set of 500000 entries will yield the same performance as only have 1 entry.
 
Last edited by Natorite,

Meteor7

Guess where this thumb goes.
Member
Joined
Jun 9, 2014
Messages
1,334
Trophies
1
Location
a fit of spasms and accidental black magic
XP
4,095
Country
United States
Input lag is the amount of time that passes between pressing a button and seeing the action on screen. It's the only thing that makes them not worth using for me. Regarding the PSX Retroarch emulator on a raspberry pi, for instance, I haven't been able to get input lags below 8 frames, which makes action games (at least for me) completely unplayable. This post has the full record of my measurements across a few emulators.

https://www.reddit.com/r/RetroPie/comments/5g3561/help_with_input_delays/

But this fellow has done a much more in depth and accurate testing of emulator input lag among different pieces of hardware, and he even speculates on from where exactly the lag is coming.

https://retropie.org.uk/forum/topic/2019/an-input-lag-investigation/2

Maybe his hypotheses can spark an idea for you?
 
Last edited by Meteor7,

WeedZ

Possibly an Enlightened Being
Global Moderator
Joined
Jan 13, 2015
Messages
3,729
Trophies
1
Location
The State of Denial
Website
gbatemp.net
XP
4,813
Country
United States
Input lag would be dependent on the hardware. Running them on a pc would be fine, running them on a calculator would cause issues. You just need to optimize your hardware and lower any unnecessary rendering settings that would take up resources.
 

Natorite

New Member
OP
Newbie
Joined
Mar 31, 2017
Messages
4
Trophies
0
Location
USA
XP
21
Country
United States
That's interesting. Perhaps it's an issue of having most things on the same thread? I usually plan for my final design versions to have essentially have the emulation, display, and input handling in their own respective little worlds.
I've seen most emulators on Github and other sources do something like "Fetch -> Decode -> Execute -> GetNewInput -> UpdateInput -> ClearDisplay -> DrawDisplay"
Here's a diagram of how I would like to make my Gameboy emulator designed.
With this design, the program flow will have three different asynchronous processes and will look something like this instead of that long process above, effectively keeping the input lag to <= 1ms, and display to 16ms (60fps). The input actually doing anything is dependent of whether or not the code is actually checking the inputs, which just relies on writing optimized code.

NOTE: There may be an issue with this design that I have not encountered yet, but it's the way that I would aim for to design it. I'm also bad at making diagrams, so sorry.
  • Execution:
  • If executing cached code, invoke the delegates until the next jump.
  • If running JIT algorithm, fetch the next opcode from the VM, translate/execute/repeat until next jump.
  • Input:
  • Compile byte (array?) of the input states and send them off to the VM to get written to memory.
  • Display:
  • Grab the data needed (sprites, vram, etc) and draw the next frame.

pAPEohs.png
 

Meteor7

Guess where this thumb goes.
Member
Joined
Jun 9, 2014
Messages
1,334
Trophies
1
Location
a fit of spasms and accidental black magic
XP
4,095
Country
United States
Input lag would be dependent on the hardware. Running them on a pc would be fine, running them on a calculator would cause issues. You just need to optimize your hardware and lower any unnecessary rendering settings that would take up resources.
The other guy I linked to was testing on a Windows 10 gaming PC. Additionally, I optimized the settings in RetroPie when doing my tests.
 
  • Like
Reactions: WeedZ

Natorite

New Member
OP
Newbie
Joined
Mar 31, 2017
Messages
4
Trophies
0
Location
USA
XP
21
Country
United States
Welcome to GBAtemp! I'm Master Dimentio and I hope we see more of you now around here. :P

Thanks for the warm welcome! I'm currently out-of-state right now visiting with my parents since I'm on break. They don't have cable/internet at the moment, so I'm having to tether my phone over USB which doesn't really provide a reliable enough connection for my to be decently active. I'm flying back in a few days and should be back in my apartment soon, though!
 
General chit-chat
Help Users
  • Julie_Pilgrim @ Julie_Pilgrim:
    not any
    Gift
  • kenenthk @ kenenthk:
    From scratch yeah
    Gift
  • Julie_Pilgrim @ Julie_Pilgrim:
    you can make some basic non-interactive sites like a blog or a newspaper or something
    Gift
  • felix.200 @ felix.200:
    you don't, you can just use html or js
    Gift
  • Julie_Pilgrim @ Julie_Pilgrim:
    dont forget css
    Gift
  • felix.200 @ felix.200:
    that's just styling
    Gift
  • kenenthk @ kenenthk:
    If you're designing from the ground up you'll need php to store registration information into mysql databases
    Gift
  • felix.200 @ felix.200:
    you don't need php you just need some backend if you need registrations
    Gift
  • kenenthk @ kenenthk:
    If you use a service it's still technically not your coding unless it's open source
    Gift
  • felix.200 @ felix.200:
    The backend code can be written in a lot of languages
    Gift
  • Julie_Pilgrim @ Julie_Pilgrim:
    " that's just styling" fair but styling is important
    Gift
  • kenenthk @ kenenthk:
    Yeah but you still need to know more then css html and js
    Gift
  • felix.200 @ felix.200:
    it certainly is
    Gift
  • kenenthk @ kenenthk:
    Styling is not important lol
    Gift
  • felix.200 @ felix.200:
    but css is for designers or full stack devs
    Gift
  • kenenthk @ kenenthk:
    If you have enough information stored users could care less if it's black and white
    Gift
  • kenenthk @ kenenthk:
    Plenty of phpbb themes are set to default and have 50k members
    Gift
  • Julie_Pilgrim @ Julie_Pilgrim:
    yeah but i would prefer websites to not look like dogshit
    Gift
  • felix.200 @ felix.200:
    Why would you need more than js, html and css for a basic website? You might need sql for your database but thats about it
    Gift
  • kenenthk @ kenenthk:
    If you want to truly call it your work that's why lol
    Gift
  • Julie_Pilgrim @ Julie_Pilgrim:
    actually that makes me think what's the line between "tolerably bad" and "this is so dogshit i won't even think of using it"
    Gift
  • felix.200 @ felix.200:
    what? lol
    Gift
  • felix.200 @ felix.200:
    If I write all my js css and html why would the work not be mine?
    Gift
  • kenenthk @ kenenthk:
    A basic site sure doesn't need it but if you want a community it's important
    Gift
  • kenenthk @ kenenthk:
    But still style isn't everything when it comes to websites
    Gift
    kenenthk @ kenenthk: But still style isn't everything when it comes to websites