41 minutes ago, lamb-duh said:
You're right, the hardware is not open and a big part of the core software is not open. There's decades of case law that lays out exactly how to legally clone a closed platform. If someone wants to make a clone of the machine and sell it, they will. Saying "no clones" isn't going to solve the issue. Emulation is legal, by the way.
Thankfully we don't have to delve too deeply into that subject, because the emulator is being made available, for free, and folks are welcome to contribute to it through bugfixes and improvements. I've personally had a lot of pull requests accepted by now, too, so I'm definitely speaking from personal experience contributing to the emulator.
Actually, I've been thinking about starting a subject to discuss what technical shortcomings might be addressed in the emulator... for instance, the VERA is probably no longer faithfully reproducing NTSC graphics. I don't think anyone has tested line IRQs on NTSC, either.
We also need some unit testing for the emulator, either prgs so we can capture the output to compare between real hardware and the emulator, or a unit testing framework in the emulator so we can run tests to compare output state of the machine with known correct examples. (Unit testing is something that
@Michael Steil has directly brought up a couple of times, especially recently.)
...and this is where I blather on for 4 paragraphs about optimizing the emulator, so feel free to stop reading if you're not interested... On the performance side, I know there's interest from multiple folks to try and run the emulator on RPis. I have a brand-new RPi4, and it runs the emulator at about 40% normal speed, or 45% when the new "warp" mode is enabled (it's not in the r37 release, but it's in the github repo and will be in r38). 40-45% is a long ways from running at full speed on an RPi.
Besides the VERA, which will likely always remain a pain point, it looks like there may be some gain to be had from optimizing the PS/2 emulation (comments in the code actually directly point out a couple of places where improvements could be made). Profiling with some specialized tools has also suggested that the basic CPU emulation could be sped up by around 10% if folks found ways to remove branching from various opcodes, such as when we branch between ordinary binary arithmetic and BCD arithmetic. In the the case of BCD, specifically, perhaps we could split the instructions into binary versions and BCD versions, and then alter the function call table whenever we run SED and CLD instructions, so that branching within the instruction itself is unnecessary and we only pay for the cost of flipping contexts. Or, since the memory to emulate an 8-bit machine is hardly a concern even on a meager RPi, we could just keep two instances of the entire instruction table for that case, and choose one as the "current" table. Or I'm sure there are other approaches with varying pros and cons, and I'm sure we'll discover other pain points as we play whack-a-mole with hotspots.
And when it comes to the VERA, there's a lot of work it could choose to do once, and then rely on cached data to speed up the final draw process, and refactoring for that would probably open up more opportunities for multithreading (actually, I've been working in this direction, and there are
lots of opportunities for multithreading when we attempt to do most of the work up-front instead of re-performing work every single line). Also, the VERA emulation makes almost no use of SDL2 functions to try and accelerate any of its tasks, so that's another avenue possibly worth exploring. And then there's sprites. Sprites are hard, and there's no two ways about that, especially if we want to emulate the VERA's work limitations with sprites.
But overall, the VERA is in fairly good shape for now... it's expensive, but even turning it off (effectively what the new "warp" mode all but does) only gets us from 40% to 45%. I mean, sprites are still a major pain point even in warp mode, but that's because warp mode still calculates sprite collisions. But it's not all VERA, all the time, at least not anymore, thanks to the contributions of at least several people, and hopefully more in the future.
