4 ms·

Sure, and for hardware this old the FPGA could re-implement the CPU (which ran at <4MHz) and the shift register at almost the exact frequency (or whatever frequ

by blihp 6y ago

Sure, and for hardware this old the FPGA could re-implement the CPU (which ran at <4MHz) and the shift register at almost the exact frequency (or whatever frequency is necessary to reproduce the original behavior) of the original as necessary. Then you can run the original software without modification and get much closer to identical behavior and performance characteristics with much lower resource utilization. Granted, it won't be nanosecond perfect, but it will be a lot closer than you'll get on any current CPU.

klodolph 6y ago
I don’t think reproducing the exact behavior here is necessary, useful, or even interesting. You could use a USB gamepad and get behavior that is close enough that humans can’t tell the difference.
- Uberphallus 6y ago
  While I don't know the current status, with MAME in the mid 2000s, an update that added support for certain games usually involved changes... that broke a different set of previously working games. I remember having 3 MAME versions installed to play all the games that I wanted. That kind of emulation hell is greatly reduced when you simulate every bus and chip of the original hardware. To give you an example: I don't remember which game it was, but it was a platformer, and when the character jumped, the game put the starting pitch of the jumping sound effect in the sound chipset, with the DSP doing the loss and pitch change on each cycle. The game moved the character according to certain value in some register of the DSP, so the game was working normally until you jumped, then the DSP emulation code did something like returning the original value or 0 (because 99.9% of the games just write there), and the game crashed.
  - CmdrKrool 6y ago
    That's because MAME is distributed as a single executable which combines support for all the machines it emulates. If there was a mega 'multiple arcade machine FPGA core' that supported thousands of machines in one then you would need to do the same kind of installation management as different parts of that codebase matured. But when using FPGAs you normally have a seperate core for every machine being simulated. By the emulation analogy, you're actually switching between many different 'MAME versions', or single-game emulators when you switch between games on your FPGA.
- boomlinde 6y ago
  For me as an occasional hobby developer for old platforms it's interesting. Subtle differences in how emulators work compared to the original hardware has sometimes resulted in nasty surprises. In the best world, I could use an emulator as a reference, but for now I have to keep the old hardware around for that reason and always make sure to test my code on it regularly. Even differences that have no impact on the entire software library are important in that sense. For example, if I write an address to an OPL chip I normally have to wait a few cycles for the address change to be effected before I write a value. You can remove that limitation in an emulator and all software written for the original platform will still work, but the emulator will no longer be useful as a reference, because now I can write software that works in the emulator but not on the real system. There's of course a use case for emulators that take these kinds of shortcuts for the purpose of running an existing software library, and that's how people were able to play SNES games on Pentium class hardware, but as a point of reference and complete functional preservation of the hardware platform itself, that isn't good enough.

by blihp 6y ago

klodolph 6y ago

I don’t think reproducing the exact behavior here is necessary, useful, or even interesting. You could use a USB gamepad and get behavior that is close enough that humans can’t tell the difference.

Uberphallus 6y ago
While I don't know the current status, with MAME in the mid 2000s, an update that added support for certain games usually involved changes... that broke a different set of previously working games. I remember having 3 MAME versions installed to play all the games that I wanted. That kind of emulation hell is greatly reduced when you simulate every bus and chip of the original hardware. To give you an example: I don't remember which game it was, but it was a platformer, and when the character jumped, the game put the starting pitch of the jumping sound effect in the sound chipset, with the DSP doing the loss and pitch change on each cycle. The game moved the character according to certain value in some register of the DSP, so the game was working normally until you jumped, then the DSP emulation code did something like returning the original value or 0 (because 99.9% of the games just write there), and the game crashed.
- CmdrKrool 6y ago
  That's because MAME is distributed as a single executable which combines support for all the machines it emulates. If there was a mega 'multiple arcade machine FPGA core' that supported thousands of machines in one then you would need to do the same kind of installation management as different parts of that codebase matured. But when using FPGAs you normally have a seperate core for every machine being simulated. By the emulation analogy, you're actually switching between many different 'MAME versions', or single-game emulators when you switch between games on your FPGA.
boomlinde 6y ago
For me as an occasional hobby developer for old platforms it's interesting. Subtle differences in how emulators work compared to the original hardware has sometimes resulted in nasty surprises. In the best world, I could use an emulator as a reference, but for now I have to keep the old hardware around for that reason and always make sure to test my code on it regularly. Even differences that have no impact on the entire software library are important in that sense. For example, if I write an address to an OPL chip I normally have to wait a few cycles for the address change to be effected before I write a value. You can remove that limitation in an emulator and all software written for the original platform will still work, but the emulator will no longer be useful as a reference, because now I can write software that works in the emulator but not on the real system. There's of course a use case for emulators that take these kinds of shortcuts for the purpose of running an existing software library, and that's how people were able to play SNES games on Pentium class hardware, but as a point of reference and complete functional preservation of the hardware platform itself, that isn't good enough.