esq5505.cpp: Add VFX-family ROM & EEPROM Cartridge support, and improve floppy support. #14444
Conversation
|
While I've tried to address the issues that were raised when the previous attempt at this was reverted, I would appreciate feedback on what I have missed, even in small things. |
…ve floppy support. Second attempt, simpler and hopefully better.
… indicate this on the LED on the panel layout.
cbrunschen
force-pushed
the
vfx_cart_and_floppy
branch
from
f2ee5f5 to
0fb58f4
Compare
src/mame/ensoniq/esq5505.cpp
Outdated
|
|
||
| void esq5505_state::floppy_load(floppy_image_device *floppy) | ||
| { | ||
| (void) floppy; |
There was a problem hiding this comment.
Same as above, don't need to explicitly void out unused function parameters.
The user can always rename a writable (.eeprom, .sc32) image to .rom or .cart to mark it as read-only.
… ones created with the filetypes that indicate a read-only image are effectively write-once. Also normalize the spelling of to "writeable".
|
Upon some further reflection, I've restored the "write-once" behaviour: it's useful, and it avoids the situation where the code has to back out of creating an image, leaving an empty file behind. More than that, it is also fairly analogous to some functionality relating to floppy disk images: those can be mounted such that the original floppy image is untouched and changes are written to a separate file, for example. Much like write-once cartridges, such copy-on-write floppy disks don't exist in real life. But in an emulation context, both protect the image files the user is working with from being accidentally written to when they shouldn't, and thus prevent data loss. |
|
I don't have a strong preference here either way, but it would be good to be able to emulate those aftermarket cartridges. This still points me towards believing a slot device is the way to go. I'll wait for RB, OG, or Vas to weigh in. Not the end of the world if this waits a bit, hopefully. |
|
For hardware keyboards, the aftermarket cartridge multi-cartridge offers two main advantages:
Neither of those is important in an emulation context:
So I don't really foresee much need to emulate those; YAGNI seems to apply. If someone wishes to emulate these multi-cartridges in the future, there are other issues to resolve as well: Any multi-cartridge would also require some UI/UX for how to switch between the different "banks" of 32kB each, since that is really not part of the UI of the keyboard itself, and that UI also needs to be connected to the multi-cartridge. In that context, separating the current class into separate slot & cartridge classes at that time would be comparatively trivial (since the slot device literally just passes through read and write requests). Indeed an alternative design choice could be to extend the capabilities of the current class, so that it can handle some multiple of 32kiB in file size, and not requiring a split into separate slot & cartridge classes at all. So on the balance I think that there is much more value in getting this functionality in place than debating a possible future extension for which there is little need in an emulation context, which may not even need the split into two separate classes, and if it does, then that split is easy to make at that time. |
|
@rb6502 @galibert @cuavas , @MooglyGuy requests "for RB, OG, or Vas to weigh in". |
|
I pinged them earlier in the thread, they'll still have an e-mail about it. They'll respond when they have the time. |
2 participants
Second attempt, simpler and hopefully better.
I've tried to address the issues identified in the Revert commit message. Specifically, the cartridge is now represented by a single image device class, and vfxcart.h includes only diimage.h, not emu.h. All indentation should also now be tabs, not spaces, and there should be no trailing spaces (running srcclean changes nothing further).