0 users browsing Emulation. | 6 bots
Pages: 1
| Near |
Posted on 19-01-27, 00:32 (revision 1)
|
|
Burned-out Genius Developer
Post: #8 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
Originally, bsnes started as a simple emulator: you start the game by passing it a filename. Ah, the good old days. Then support was added for games with cartridges slots on the games themselves: Super Game Boy, BS-X Satellaview, and the dual-slotted Sufami Turbo. A few awkward attempts at custom load dialogs to select all of the carts for these didn't go well, but it worked. Then I added more systems, and to plan for a future with Game Genies and Sonic & Knuckles lock-on carts, bsnes/higan moved to its until recent design: you now start the emulator with no games specified, and the core will ask the GUI to load games as it needs them. This will allow you to chain an infinite recursion of stacking Game Genies if you wanted. It does have the downside that if you load a Sufami Turbo game, you get forcefully prompted for two sub-slots after it, but it worked. Then I added more systems, and now we have the MSX and Neo Geo Pocket. The MSX has two cartridge slots, one of which can be used for audio or RAM expansions. It would be very unfortunate to open two load dialogs in a row on every MSX game. The MSX also has peripherals that can be added to load games from floppy disks or from cassette tapes. The Neo Geo Pocket (and others, like the Sega CD) can be booted with no game inserted (well, the Sega CD BIOS acts like a game cartridge through the expansion port), which leads you to a BIOS. Not pleasant to have to dismiss load dialogs to get to that. We will need to be able to dynamically swap and flip floppy disks, dynamically swap CD-ROMs, etc. So in an effort to support all possible use cases, I need to revise the higan interface yet again. The key observation is that the GUI doesn't know about every possible variation. And some cases are recursive (Sonic & Knuckles & Knuckles & Knuckles & Knuckles & Knuckles ...), and other cases are based on what you've connected to the expansion ports. While we're at it, let's also consider that controllers will be getting more complicated in the future: there are devices like the Super Turbo File that contains multiple save RAM files. The BS-X Satellaview base unit apparently has a CompactFlash-like slot on it. Many CD-based systems have memory cards, and spawning one memory card for every game would limit us on games that want you to migrate your saved data to a sequel. The Voicer-kun needs CD-ROMs. So we need peripherals that also have storage capabilities (eg folders) now. So my new proposal is that we expose everything that can be plugged in as a recursive array. Kind of like an enumeration API that isn't a pain in the ass to use. There will be a base result for an initial state of a system: an SNES will always have two controller ports, one expansion port, and one cartridge port. And as you connect devices, by scanning for ports again, the new ports will be exposed. The GUI can allow us to build our own configurations out of the base hardware plus a pre-configured layout of connected peripherals. For instance, the Sega Genesis with a Sega CD on the expansion port, which will save us from having to load the Sega CD BIOS every time. The Famicom with the Famicom Disk System on the cartridge port, which will save us from having to load the FDS BIOS every time. The Super Game Boy is another good example. But from this configuration interface, the GUI is not going to be able to know that if you select the Super Game Boy, that will expose a new Game Boy cartridge port to the SNES hardware. Because the GUI is generic, and we learn about the slot on the Super Game Boy through parsing the cartridge manifest inside the emulation core. In practice, this doesn't feel like an extreme limitation. You won't be able to make a configuration that direct-boots into Link's Awakening on a Super Game Boy. To allow that functionality, we would have to return to manifests, and the issues they caused with new versions revising their syntax. So then we have a systems configuration dialog where we can build out configurations. Upon loading one, it will initialize the interface for the given hardware, and connect/disconnect all the default cartridges/peripherals as requested. I cannot think of a design that puts all of this into the menu bar. If we tried to make stacking cartridges recursive it would quickly get overwhelming. No, we need a new window with a tree view, that dynamically updates as things are plugged into and disconnected from the various ports (and sub-ports ...) Once we have things connected as we want, we will have to start and stop the system power. It isn't going to be fun to use, but it's worth noting that we've essentially modeled the real world here. Whoops. I might very well have two Sega Genesis units: a model 1 with great sound, and a model 2 that I connect a Sega CD to. Then I have an MSX machine that has a floppy disk drive attached to it. The systems configuration dialog allows us to represent multiple machines in whatever configurations we want. One we decide to play a real machine, we have to plug in our controllers and cartridges. And indeed, the emulator is the same here. After everything is connected, we can turn the power on and off. And while the system is running, every connected device can be forcefully disconnected, even if that means triggering a stop-and-swap behavior. Yep, we can emulate that too, now. And if we want to take all of this to its true logical conclusion, we can only allow the configuration of system profiles from the main higan window. In this way, we can plug in cartridge, etc and dynamically have the ports enumerate, and we can populate even sub-slots. While we're doing this, we can't allow the configuration of a different system, because higan cheats a bit and reuses global objects for the Game Boy core inside the SNES core for Super Game Boy support. But that's really, truly not any kind of serious problem. Once a system is configured and started, then the systems configuration dialog would be disabled, and all the default connections, including sub-ports, would all be connected. Then we can customize that by adding the games we want to play, and finally turning it all on. We can even force the creation of folders for each connected peripheral (say, a game pad), and dump in key assignment configuration files there. This would allow you to model having multiple physical SNES controllers to your multiple physical Xbox 360 controllers. Because that state is going to have to go somewhere. It's definitely going to be massively more complex than any stand-alone emulators. But hey, that's why we have bsnes now, too. The one emulator people actually want to use that I made will continue to work like Snes9X, and higan can spiral into infinite complexity as an experimental project, down to simulating write limits on flash media, battery life on handhelds, etc. Why not? A quick peek at this is here: https://twitter.com/byuu_san/status/1089111967980126208 But you'll notice the controller/expansion ports aren't there. That's because I use writing these posts to think about these things, and I come up with new ideas while doing so. Anyway, I think I have my design now. I'll spend some time designing how I want things to look, and then start on yet another new higan GUI. |
| Screwtape |
Posted on 19-01-27, 05:38
|
|
Full mod
 Post: #95 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
If I had a magic wand: - a Component has zero-or-more Slots, and each slot has a Type. For example, the Super Famicom component has a slot of type Super Famicom Cartridge, a slot of type Super Famicom Expansion, a slot of type Super Famicom Controller Port 1, and a slot of type Super Famicom Controller Port 2 (since some kinds of controller only work in one port or the other). It might even have a slot for the IPL ROM, CPU and PPU revisions, just for completeness. - For some slot types, there's a specific, fixed number of possible components (like PPU revisions, or kinds of game controller); other slot types are unlimited (like game carts) - a Configuration is one or more Components wired together. - in a Configuration, each available slot must be in one of these states: forced empty, forced to contain a particular other component, required at runtime, or over-ridable at runtime with a default. For example, a Super Game Boy configuration would force the Super Famicom Expansion slot to be empty, force the Super Famicom Cartridge slot to contain the Super Game Boy cart, require a component to fill the Game Boy Cartridge slot at runtime, and have the controller ports default to controllers but over-ridable at runtime. - There should be a tree-based editor for creating configurations of whatever complexity - It should be possible to save configurations to a menu or something, like the v107 WIPs. - When choosing a configuration from the menu, if there are zero required-at-runtime slots, the system can just boot. - If there's exactly one required-at-runtime slot, and it's an unlimited type, open a file-picker and once the user picks an appropriate file, the system can boot. - If there's more than one required-at-runtime slot, or there's a required-at-runtime slot with a fixed number of options, construct a dialog box with drop-down lists (for fixed-number slots) or file-picker buttons (for unlimited slots) and an OK button. Once the user has filled all the boxes, they may proceed (higan may remember the values picked and use them as defaults next time) - If there are any over-ridable-at-runtime-with-default slots, higan should have a menu for them. Fixed-number slots have a submenu, unlimited slots open a file-picker. However, once you have configuration of this complexity, you're going to really, really need a way to separate "configuration that comes with higan" from "user configuration", so user configuration can override defaults without replacing the whole thing. The ending of the words is ALMSIVI. |
| KingMike |
Posted on 19-01-27, 07:30
|
|
Post: #2 of 36
Since: 12-21-18 Last post: 1207 days Last view: 115 days |
For systems with memory card support, not sure if it would be possible to choose between a separate memory card per game or a single card shared, as one might be more desirable than the other on different games. (I can remember going to Best Buy and it using fear-mongering to sell more PS2 memory cards for like Madden 2005, saying the game wanted the whole 8MB card to itself. I later looked it up and I think it wanted only like 1MB or something. But the idea of what if it did? I think that was a reality on some N64 games, though. Again, I don't think N64 is in the plans, but if we're speaking hypothetical future-proofing ideas.) Reading on MSX which used "PAC" carts for SRAM support, it sounds like some games would expect to use a certain bank on the cart or a limited number. I can imagine it being a pain when games conflict with each other. But I don't have as much experience in that. I only had to look at it when working on a fan translation of a (MSX2) cart game which used the PAC as its save file storage media. (MSX also has the issue that there are several distinct variations of the hardware. What is it, MSX, MSX2, MSX2+, MSX2 Turbo?) |
| Near |
Posted on 19-01-27, 17:00 (revision 2)
|
|
Burned-out Genius Developer
Post: #9 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
Screwtape, interesting ... pretty similar to what I put into the latest WIP, hopefully you'll like it then ^-^; My takeaway was that I was trying to join two distinct concepts into one before: SNES { Port1=Gamepad, Port2=Gamepad, Cart=SGB ( Cart=Zelda DX) ) A better modeling needed for a tree-view hierarchy is to separate connectors from things connected to them. The SNES has an expansion port even if something isn't plugged into it. And a Satellaview is a Satellaview even if it's not plugged into an expansion port. As for what to call the base system and all things connected to connectors, well ... I had to go with object. It could be a console, a handheld, a controller, a cartridge, a floppy disk, a CD-ROM ... literally anything. So any name I chose other than object (or thing) would not cover all cases. The system needs to be an object visible in the hierarchy, because for handhelds (and some consoles), the system itself is a type of controller. At least, it has inputs. Be it a Game Boy D-pad and buttons, or a Master System pause button. And really, the reset button should be here too. The only thing every system in existence will have to have is a power switch ... and even then, it's not always a switch. It's a button on the Neo Geo Pocket that sends games an interrupt. Currently, I'm grappling with how to handle the spiraling complexity. If everything is an object (the system, controllers, etc), then everything should get a folder for data. That's a good thing ... a Super Turbo File needs a place to write its save games to. But how do we design this? You can't (yet) download controllers from the internet :P Including a bunch of pre-made folders seems silly. So when connecting an object to a connector, we'll evaluate the context of: which system is this? Ask the system what connects to that port ... a list of controller strings, or a folder. If it's the controller type, then we'd open a different kind of dialog, a controller manager, that lets you create a compatible controller folder or use an existing one. The complexity is straight up horrifying, I know, but ... if we only have one fixed controller in one fixed place, then we limit ourselves a bit. You might want different Super Turbo File devices for different games. You might want to use this same kind of UI as a memory card manager. And once we've gone this far ... we have to ask ourselves about games themselves, too ... do we really want games in ~/Emulation/<system name>? We have a chance here to do away with a really ugly kludge: game folder extensions. What if the connectors were configurable in the same way the connected devices were? What if I said, "the SNES cartridge connector here will look in this directory for games"? Or what if I said, "the SGB cart port will look in the GB (gray) + GB (black) directories, but not the GB (clear) directory"? We could then allow people to have a different configuration entry for "SNES RPGs" and "SNES Shmups" (but not "RPGs for all systems"), if they wanted to, of course. Connectors could also include filters for the scanned directories. "SNES PAL" would have a filter for "*(PAL)*", for instance. This is so far beyond anything I've ever planned ._. |
| creaothceann |
Posted on 19-01-27, 21:40 (revision 1)
|
 Post: #54 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
Posted by byuu Object is too broad, imo. You're emulating a computer - specifically, (in Pascal parlance) a TVideoGameSystem - consisting of several instances of TDevice (which has at least one connector). My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| Near |
Posted on 19-01-27, 22:53 (revision 1)
|
|
Burned-out Genius Developer
Post: #10 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
A CD-ROM disc isn't a device. Now granted you don't technically "connect" a CD to a CD drive, but it's at least a reasonable thing to say. |
| creaothceann |
Posted on 19-01-28, 14:26
|
|
Post: #55 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
Posted by byuu I would represent a disk simply as a string property (file name) of the CD reader device. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| Screwtape |
Posted on 19-01-29, 11:56
|
|
Full mod
Post: #98 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Posted by byuu ...okay, that's pretty cool. I could get behind that. The ending of the words is ALMSIVI. |
| KingMike |
Posted on 19-01-30, 02:26
|
|
Post: #3 of 36
Since: 12-21-18 Last post: 1207 days Last view: 115 days |
SGB technically can read GBC-exclusive games. If only to generate error screens. (a couple years ago, someone actually made an image gallery of all the "GBC required" error screens. Though I don't think any went to the effort of that Dracula X PCE error screen minigame. :D |
| CaptainJistuce |
Posted on 19-01-30, 04:22
|
|
Custom title here
 Post: #212 of 1164 Since: 10-30-18 Last post: 63 days Last view: 13 hours |
Posted by KingMike Yeah, it reads them in the same manner a regular monochrome GameBoy does. --- In UTF-16, where available. --- |
| Near |
Posted on 19-01-30, 05:11 (revision 1)
|
|
Burned-out Genius Developer
Post: #11 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
I understand we can do things like: * show Game Boy Color games for the regular Game Boy * show WonderSwan Color games for the regular WonderSwan * show Neo Geo Pocket Color games for the regular Neo Geo Pocket And we should definitely allow it to be possible if someone really wants that, but ... 99% of the time, it's just going to be visual clutter. If we give people the option to add both GB + GB (black), then they can add GB (clear) or just decide that it's probably better to run GB (black) carts on GBC (I would. SGB features aren't impressive enough to lose GBC coloring.) |
| CaptainJistuce |
Posted on 19-02-02, 07:57
|
|
Custom title here
Post: #218 of 1164 Since: 10-30-18 Last post: 63 days Last view: 13 hours |
Posted by KingMike Arguably, one went BEYOND Castlevania X: Rondo of Blood, offering an actaully-functional(but still incomplete) game. https://tcrf.net/Pokémon_Puzzle_Challenge#Panel_de_Pon_GB --- In UTF-16, where available. --- |
Pages: 1
