What are /r/EmuDev's favorite Products & Services?

From 3.5 billion Reddit comments

I came across this book not too long ago:

https://www.amazon.co.uk/Hacking-Xbox-Introduction-Reverse-Engineering/dp/1593270291

​

Not sure how good it is tho.

Shameless plug: if you're looking to test on either a modern Mac or a Linux-based system, you can just use my emulator, Clock Signal, out of the box. I've been a bit lazy with regards to the SCC but that aside it's a full hardware emulator just as PCE is (and very much unlike Mini vMac).

Mac binaries are here, and that's a GitHub link so your Linux options are to download from there and build either for SDL or for Qt as you prefer, or if you use a Snapcraft-linked distribution such as Ubuntu then just grab it directly from the relevant app frontage.

The Mac Plus is fully supported. Possibly the only oddity you'll see is that I've tried to be compatible with Mini vMac's concept of a hard disk image, so the emulator will take whatever is actually in your file, chuck it into a suitable partition, and prefix that with the standard Mac OS SCSI driver. Overwrite it at runtime if you want, but it won't be retained.

If you're using Windows then apologies; I haven't quite made that leap yet.

I'm not sure what you mean. Can you please explain what kind of software architecture (and underlying hardware platform) you have in mind where your argument would apply?

I'm thinking of CPU virtualization, and GPU emulation (because, as explained in this comment, GPU virtualization is usually impossible).

Page-fault-handlers are part of the CPU or the CPU virtualization API. And MMIO is either a CPU feature, or a feature of the memory controller (which is also part of the CPU virtualization APIs). See KVM_EXIT_MMIO in https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt for example.

(There's also standard IO ports of-course, but GPUs usually switch to command rings and MMIO for performance reasons)

I'm successfully using these techniques in many of my projects (or projects I've worked on).

As for mapping GPU memory space: Vulkan and OpenGL have APIs for this. I assume Direct3D also has APIs for this.

From the looks of this:
https://realboyemulator.wordpress.com/2013/01/03/a-look-at-the-game-boy-bootstrap-let-the-fun-begin/

The boot rom appears to simply clear the VRAM, set some audio register values, then do the checksum. Which begs the question, on an actual game boy, what sets all the other initial values (such as 0x01 for reg A) on power up?

For the time being, I will go ahead and set these initial values (from pan docs) myself and skip the boot rom entirely.

BGB (http://bgb.bircd.org) appears to do it in the same way. It doesn't have a boot rom, and instead launches games at 0x100 with everything set.

It may be too late but you could try a DCPU-16 emulator. It's the virtual CPU that Notch came up with for his now abandoned game 0x10c. It should be pretty simple to get up and going and there was a large community of people creating software for it.

You can't read both P14 (the D-Pad) and P15 (the other buttons) at the same time. Setting Bit 4 and Bit 5 of P1 to zero is how GB software communicates with the SGB. I'm not 100% sure what the value of P1 is if P14 and P15 are set to LOW, but iirc, it's something like 0xFF. Anyway, some games will read out P1 twice and combine the results into a single byte, but you can't read P1 once and get the results for all input.

To me, it might be a problem with how you poll any input in SFML. It looks like any input continuously goes from key-press to key-release. Key-release seems fine, so pressing is probably the culprit event. The problem may be that multiple key-press events are being generated. Check out this page on SFML's events, specifically:

> If a key is held, multiple KeyPressed events will be generated, at the default operating system delay (ie. the same delay that applies when you hold a letter in a text editor). To disable repeated KeyPressed events, you can call window.setKeyRepeatEnabled(false). On the flip side, it is obvious that KeyReleased events can never be repeated.

It says key-release events can never be repeated, but I wonder if the docs only mean key-release events aren't continuously repeated once a key is done being pressed. Use some print statements to see if you really are bouncing between key-press and key-release events when a key is being held down. I dealt with a similar issue with Qt recently. I suspect disabling key repeating would solve this issue. I've gone over your code, and it looks sound. In my opinion, most likely an API issue with SFML rather than any emu core error.

Maybe is my lack of experience but it looks like there is always some kind of issue or additional step on MacOS. Check this example from pygame:

https://www.pygame.org/wiki/GettingStarted

Is nothing major but it gets annoying when it happens many times setting your toolchain.

The timer value is incremented by whatever is driving it. So in the case of the system clock, you can increment the timer by however many ticks an instruction takes to execute. Same way you drive the GPU timing for vertical blank.

Timer 1 is used by many games with hblanks as a source. Here, you increment the timer after each line rendered by the GPU. I haven't seen anything which relies on timer 0 being driven by the dot clock (I skipped it in my emulator for now).

For synchronization, if you're running everything in lockstep, no additional synchronization is needed. Just return the counter value. In my emulator, I run components separate from each other, each accumulating "pending ticks" which is flushed when needed. So, when a counter is read (or an interrupt is needed), the ticks are added then. I'd go with the former approach until you have a better understanding, and then look into something more efficient.

My emulator's source might be of some help: https://github.com/stenzek/duckstation/blob/master/src/core/timers.cpp

Also happy to answer questions on the emudev discord in the #playstation channel. There's a few of us there who have written emulators to varying degrees of completion. :)

the DS GPU?

​

hah :)

​

that being said, the base features are close enough to standard 3D APIs that you can rather easily get most games to render correctly. but, if you want to take it further, it's quirk city.

​

then again other consoles probably have their piles of quirks too. would be fun to hear about some.

Adding on to this to explain why some games just simply don't work or have substantial bugs on existing emulators:

Emulators are extremely complex programs trying to provide a cozy environment for equally complex programs. Understanding hardware well enough to mimic it in software is tough, and the assumptions and tricks people use are not always accurate.

When creating an emulator, you need documentation. Sometimes, there's public documentation that explains the more common hardware components. Maybe it's the CPU instruction set, or maybe someone did some work for you. Everything else though... you're going to need to figure that out yourself through clean room (i.e. legal) reverse engineering. That takes significant time and skill, and it comes with absolutely no guarantee of correctness.

For every possible input to some circuit (e.g. GPU), someone has to determine through trial and error how it influences the circuit's output. An analogy to that would be like like leaving a toddler and a dog in a room full of cookies and raw chicken, and then trying to figure out which one ate what without actually witnessing what happened.

 

And then, once that's done, you're still not free from compatibility issues. Some consoles have completely documented hardware, yet the software developed for the console actively uses undocumented but reproducible bugs in the hardware implementation. If you're lucky, it's something easy to debug that can be fixed with a clever trick. But when you're not, you end up with something like this that requires luck and a lot of knowledge about the system.

This mGBA post about cycle counting and instruction prefetch might be worth a read. All in all cycle counting on the GBA is a really hard topic and there are few people out there which are qualified to answer your question. If you are still in early development I suggest focusing on other parts of the system. GBA games don't require a cycle accurate emulator to run well (just make sure your CPU isn't running too fast).

Sorry this bad answer but better cycle accuracy is still on my own todo list and I couldn't leave your question unanswered :)

Per MAME's about page: >MAME is strictly a non-profit project. Its main purpose is to be a reference to the inner workings of the emulated arcade machines. This is done both for educational purposes and for preservation purposes, in order to prevent many historical games from disappearing forever once the hardware they run on stops working. Of course, in order to preserve the games and demonstrate that the emulated behavior matches the original, you must also be able to actually play the games. This is considered a nice side effect, and is not MAME's primary focus.

An emulator that plays games "as a side effect"... heh,heh no.

Thanks! For the CPU, there are a lot of different references online for the instruction set. I also had the 8086 datasheet.

For the Intel chipset stuff, it was mostly the official datasheets I used and sometimes programming references found on Google. wiki.osdev.org is also a decent reference for chipset components, but it usually doesn't go into all of the details.

Another great general reference for I/O ports is this: http://bochs.sourceforge.net/techspec/PORTS.LST

For the various other components like mouse protocol, Sound Blaster or whatever else, I typically could find most of what I needed by googling "sound blaster programming" or "microsoft serial mouse protocol" and stuff like that.

One that I really liked is for my dear Zx Spectrum, "The ZX Spectrum ULA" https://www.amazon.com/ZX-Spectrum-Ula-Microcomputer-Computer/dp/0956507107, but in general you will find more information in blogs/forums/discord/documentation of the emulators/wikis... One very interesting old blog is from the creator of mame, Nicola Salmoria where he describes the reverse engineering of protections used in the arcade machines. http://mamelife.blogspot.com