NekoNoNiaow wrote: ↑
Wed May 16, 2018 5:52 am
ThomH wrote: ↑
Fri Mar 23, 2018 9:41 pm
* doesn't affect the Oric. But, essentially, nowadays if you insert a piece of media for which the correct machine or hardware configuration cannot be determined a priori, the proper machine and configuration will be found empirically. E.g. if you provide a 16kb file with a .bin extension and the emulator can't figure out whether it's meant to be a ColecoVision or an Atari 2600 game, it'll just simultaneously try both with some light instrumentation and show the user whichever seems to be the more likely outcome until the case is so overwhelming that it can drop the improper guess. Which usually happens really quickly.
Interesting, I have been designing a similar idea for an Amiga emulator project of mine.
One of the main annoyances regarding Amiga emulators is that there are so many different configurations that it can be difficult for users to know exactly which game works with which configuration.
My intuition is that it should be feasible to start the emulation with a standard configuration and let it run until it crashes (or reaches a state which can be detected as failure) then branch the emulation into a number of different paths depending on the nature of the failure:
change the CPU if an instruction of another model was encountered, if the CPU crashes while executing ROM code, try switching the ROM version, if the display is not consistent, change the chipset, if memory limits are reached, increase the available memory, etc...
Once the game/program is assessed to be working correctly, the emulator would associate the corresponding media (disk image) with the proper configuration so it can reuse it immediately the next time the game is launched.
This is nowhere near that advanced. The sole original consumer was the MSX. The issue there is cartridge images. There are a bunch of incompatible ways to implement paging on a cartridge but the method for preserving MSX cartridge is conventionally to make an image of the ROM chips and then leave the user or tool to guess at the paging hardware.
I already have a static disassembler that's used to try to ease some of these issues — e.g. for the Oric a disassembly is used to decide whether to boot as BASIC 1.0 or 1.1 when loading a tape. Try File->Open... on either version of Stormlord, both should just work. But it isn't sufficient for this purpose, primarily because it's also a RAM-based machine. One title, Toobin', is the worst possible case: it was originally a tape title, converted to cartridge. So the full extent of code that is obvious to the disassembler is (i) copy a bunch of data from the first page of the cartridge into RAM; (ii) jump into RAM.
So then I briefly considered a disassembler that performs some dynamic execution but thought I'd just reuse the part of the code that already does the dynamic execution.
So if it thinks there are four potential paging schemes that might be in use, it just spawns four MSXs, one running each option, and switches horse as and when the evidence comes in. It will selectively terminate them if they become very obviously the wrong option.
It's very brute-force, and computation costs in principle grow exponentially with the number of unknown selections — supposing it were four potential paging schemes plus, separately, absence or presence of a disk drive (or something), that'd be eight MSXs to run simultaneously. Etc.
The advantage is that the logic sits almost entirely outside of the emulation core, other than it having to tweak a probability of correctness upon certain events. Embracing dynamic selection at the core, presumably being able to spot potential divergence points, snapshot the machine and then make a guess, and regress if the wrong guess was made, would be a much smarter thing than I am doing.
iss wrote: ↑
Wed May 16, 2018 7:45 am
[ emulation (for both - Apple][ and 8DOS).
It helped me already to rescue (partially, because of really bad floppy disks
) some antique software and now I can "close the case" which waited ~15 years
I'm waiting for some "developer extras" like debugger
, but it's not an urgency of course.
Alas a debugger is not currently on the schedule. Which is probably absurd if you think about the strong intersection between people still using emulators of '80s machines and people producing content for '80s machines but I've yet to think of a good way to do it well. And it'd probably never be in the SDL version. But I still want to add a Qt or GTK back-end for Linux types that want a full real application out of their emulators rather than just a discreet thing that runs a DSK but doesn't otherwise announce itself.