* emu83
* builds and get rid of wtf this thing is
* multidisk bundler for ti83
* release
* link src
* also put in the commit hash why not
* Nitpicks
* update ""rom"" extensions for ti83
* don't forget to set a preferred core
Co-authored-by: YoshiRulz <OSSYoshiRulz@gmail.com>
(or `Console.WriteLine` if it's in `#if DEBUG`)
bonus wtf: 2 calls in Database were to `WriteLine(string, string)` overload, not
the intended `WriteLine(string, params object[])` overload
If set, only the first preference core (whether it be through gamedb or preferredcore or priority or whatever) will be tried, and a failure for it will immediately fail the entire thing. This is mostly a developer feature to aid in debugging.
* `Game Gear` was used instead of `GGL` for linked GG multi-disk bundles and
core constructor (I assume the latter was a hack to fix loading bundles made
with the former bug in effect)
* `Arcade` was used instead of `MAME` in rom loading ("Arcade" is also assigned
to an out param in the MAME ctor but I assume that's an intentional placeholder)
* `Saturn` was used instead of `SAT` in `GameSharkDecoder.CheatDomainName`,
making it non-functional (a comment said it was probably incorrect, so I'm
assuming that if it runs something will break and putting it in #if false)
* `G7400` was only used in firmware IDs, replaced with `O2`
* `Vectrex` was only used in firmware IDs, replaced with `VEC`
* `uzem` (core name) was used instead of `UZE` for MainForm title lookup, making
it non-functional
* `DNGP` doesn't exist
See #2561. From the point of view of romloader, this is all pretty simple: It asks for a particular settings type. It should either get null back (indicating there was nothing, use defaults), or an object of that type. Providing a completely unrelated type is baloney. So this check here is a stupid defensive check that shouldn't be needed. MainForm cannot be trusted.
When a missingfirmwareexception is encountered, do not fallback. It's presumed that these cases are fixable by the end user.
Absolutely does not in any way fix#2327 - the user was emphatic that they had the BIOS file, so they must have hit some other situation.
Waterbox supports threads now, but they're not real threads on the host side because that's complicated and can be nondeterministic. Instead, everything is scheduled to share one host thread. This means that scheduling is actually cooperative and certain patterns of spinlocks and other nonsense can fail to work at all, but "regular" code probably will.
With this, add DobieStation PS2 core. This core was selected because it has threads and is otherwise simple to port; easy to build and a good core/frontend separation. It's not a wonderful core however, with low speed (made abysmally lower by our lack of real threads) and low compatibility, so it remains a curiosity for now.
Morilli