throgh wrote:In general there are emulators out there in need for BIOS-roms to start emulation. Hyperbola has therefore an entry in the Wiki: https://wiki.hyperbola.info/doku.php?id … :emulators
And besides the BIOS to run emulation: There are also programs for emulation out enhancing the "gameplay" through network. So you can play even with others. Best way getting both aside for being a security-risk. The more complex the system is getting there will be more possible ways to attack or having issues in general.
The example with ROM-files out of original modules is the safest way I know to have trustworthy content. Aside I understand for sure: Collecting all those modules is also not very pragmatic. More or less having to compromise emulators is possible at any time for sure.
First of all: Thank you for making things clearer.
I think I got it, now. Cause of my misunderstanding was an insufficint technical insight into the realm of emulators:
1.
There seem to be different ways to make one computer (the host system) emulate another computer or hardware (the guest system):
A computer or hardware running software - this computing setup basically consists of multiple parts, not just one:
The building block 'hardware itself', and the building block 'BIOS firmware'. You need both, otherwise the computing setup will be like a brick or like a TV without input like from a TV station or recorder, instead of being able to run software.
When a computing program (emulator) is developed for making one computer (the host system) emulate another computer or hardware (the guest system), this setup can be ditched - so, within the emulation setup there is just one building block, 'the hardware itself' - or that emulator can be built so closely to the way the guest system is built, that it is built with exactly that much building blocks like the guest system.
So, if the to be emulated computer or hardware consists of the building blocks 'hardware itself' and 'BIOS firmware', the emulator does so, as well.
And that's the catch: How free and trustworthy really is an emulator, consisting of multiple building blocks, which are all needed, but not all free/libre?
For an emulator to be free/libre and even just having a chance to be trustworthy, it needs to be completely free/libre - meaning all parts, not just some.
For that:
If the emulator is built up by just one building block 'the hardware itself', that needs to be free/libre.
If the emulator is built up by 2 building blocks, 'the hardware itself', and the 'BIOS firmware', both need to be free/libre.
The absolute minimum requirement for an emulator to be free/libre up to this point, within this frame so far, is that at least the building block 'hardware itself' must be free/libre,
and if there are additional necessary building blocks at least there needs to be a way to make these additional necessary building blocks as free/libre software. If that prospect of regarding additional necessary building blocks is a dead-end, if it's not possible to have that part of the emulator as free/libre software, then the whole can't be free software, which makes it a non-trustworthy environment, per se.
And one important clarification. ROMs - that's also not just one thing. ROMs encapsulate data of read only memory chips. Games are not the only read only memory chips. The BIOS firmware is one, too.
So, one has to differentiate ROMS: There are GAME-ROMs - containing the data of a video game cartridge - and there are BIOS-ROMs - containing the data of a firmware chip, which is actually a computer program.
You know, if you don't have that distinction in your head, if whenever you read 'ROM', you only think of GAME-ROMs, that one point you've added is not understandable.
2.
With making an emulator the possibility arises to change the to be emulated computing setup, the guest system.
Most retro game systems are offline systems. When building an emulation of that systems one can add network capability, enabling the originally offline system to be able to interact with a system of the same kind over a network connection between both of them - so, opening the door to something similar to online gaming.
But that highens complexity of the system, and in general the more complex, the harder to understand a system is, the more problematic it becomes from an it-security perspective. So, for the sake of it-security, it would be better to not have such additions, which are not part of the original guest system. For the same reason its more favorable, if the emulation consists of less building blocks - being fine with just achieving the main thing (= that the system is running) - and for that purpose if possible reduce the amount of building blocks of the guest system, instead of treating that amount of building blocks the guest system originally consists of as a not to be touched holy grail, which must be kept exactly like that, as if it's not enough for the system to basically run.
So, the ideal way up to this point to sum things up is like this:
A fully free emulator
without fancy extensions for turning originally offline systems into network-capable systems
for which Free dev tools for games/OS exist
and a trustworthy GAME-ROM setup - which can be achieved by:
*Maybe there is another way for having a trustworthy GAME-ROM setup, a lesson learned from a different online community: The music lover/audiophile bubble.
What music lovers want: Perfect digital copy of their beloved physical music - the content of a CD needs to be transfered in the best possible way onto a computer. The end product - that perfect copy - is called an image, as noted by the wiki link you've posted.
But what if the starting material, the CD for example, has a scratch? Or you hear a weird skip on the CD and the resulted image at the same spot? How can you be sure, that you really have what you want - a perfect copy? The answer developed in the music lover/audiophile community is
'standardized double checks locally + checking reproducibility globally by online collaboration'.
If you repetitively get the same image result including a certain checksum, and if you find out via an online data base, to which everyone can upload their own results, that you are not the only one generating checksum X for CD Y, but aside of you 231 other people around the world, then you can be pretty sure, that you've nailed it.
Can't the trustworthiness of GAME-ROMs be solved in a similar way?
By
Could that borrowing of the culture of music lover/audiophile community also create for the retro gaming community trustworthyness in GAME-ROMs created by others?
I mean, this is pretty fancy: In music world that setup has created a world, where you don't need to rip a music CD by yourself for having a perfect digital copy of a music CD with certainty - you simply can look for it on the internet and look for evidence, that what you've found is identical to what a lot of other people independent of you or your source have generated by themselves. Something like that gotta has to be possible for gaming world, as well. I mean, if multiple people have generate the same thing independent from eath other, that makes it pretty unlikely, that said generated object is corrupted, is it?
throgh wrote:For downloaded ROM-files it would be a good way running them first just within a virtual-machine for initial testing. Best performance is not needed, just a first tryout to start and getting information about the content you are loading.
That's one thing I don't understand: Why the restriction regarding the usage of the virtual machine? Why not just letting the whole emulator setup run in the VM all the time, whenever used? Why just for just letting it run first within a VM for initial testing? Is it a performance thing - meaning, outside a VM the system would run better, which is to be prefered once initial testing in a VM turns out that the emulator setup is save to use?
Upto this point I see 2 advantages missing out in doing so:
Think of people, who can't program, who can't do initial testing within a VM: Letting an emulator-'GAME-ROM'-setup run within a VM whenever they are using it is their only option.
Doesn't it make the whole process of playing 'per se'-non-trustworthy GAME-ROMs easier, when you just always put them into a VM whenever used? I mean, upto this point handling it like that looks to me like achieving 'trustworthy GAME-ROM setup' without the additional working step 'testing'.