esq5505.cpp: Add VFX-family ROM & EEPROM Cartridge support, and improve floppy support. #14444

cbrunschen · 2025-10-31T18:38:54Z

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).

cbrunschen · 2025-10-31T22:03:52Z

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.

MooglyGuy

Looks reasonable to me other than some minor suggestions/requests. Hopefully @rb6502 or @galibert can take the time to give it a look-see as well.

src/mame/ensoniq/esq5505.cpp

MooglyGuy · 2025-11-05T18:12:23Z

src/mame/ensoniq/esq5505.cpp

+
+void esq5505_state::floppy_load(floppy_image_device *floppy)
+{
+	(void) floppy;


Same as above, don't need to explicitly void out unused function parameters.

src/mame/ensoniq/esq5505.cpp

src/mame/ensoniq/vfxcart.cpp

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".

cbrunschen · 2025-11-07T07:37:26Z

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.

MooglyGuy · 2025-11-08T06:55:54Z

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.

cbrunschen · 2025-11-08T08:25:21Z

For hardware keyboards, the aftermarket cartridge multi-cartridge offers two main advantages:

it offers a writable cartridge at all, since the original EEPROM cartridges are rare and hard to come by
it allows access to switching between different "virtual" cartridges, without needing to swap between physical ones, thus reducing the physical wear-and-tear on the cartridge slot and cartridge connectors

Neither of those is important in an emulation context:

acquiring a new cartridge is as easy as using the [create] menu item in the File Manager
there are no physical connectors, so there is no wear-and-tear

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.

cbrunschen · 2025-11-08T21:44:29Z

@rb6502 @galibert @cuavas , @MooglyGuy requests "for RB, OG, or Vas to weigh in".

MooglyGuy · 2025-11-08T21:51:50Z

I pinged them earlier in the thread, they'll still have an e-mail about it. They'll respond when they have the time.

rb6502 · 2025-11-09T18:02:54Z

src/mame/ensoniq/esq5505.cpp

 	required_device<esq_5505_5510_pump_device> m_pump;
 	optional_device<wd1772_device> m_fdc;
 	optional_device<floppy_connector> m_floppy_connector;
+	optional_device<ensoniq_vfx_cartridge> m_cart;


A thought for future work: having more than one optional_device often means it would be cleaner to have a base class with nothing optional and then various inherited child classes that extend that in various ways. Back when I wrote esq5505 originally I wasn't in that mindset and it does show.

It might be worth looking at this for a refactor more generally. The EPS Classic, for example, doesn't really belong here at all: it has no es5510 ESP, and the sound generator is the es5504 "DOC II", not the es5505 "OTIS".

Yeah, for sure.

rb6502 · 2025-11-09T18:06:10Z

src/mame/ensoniq/esq5505.cpp

 void esq5505_state::floppy_formats(format_registration &fr)
 {
 	fr.add_mfm_containers();
 	fr.add(FLOPPY_ESQIMG_FORMAT);


It's probably not a bad idea to add the HFE format too - that's become kind of the standard way to distribute synth floppies with nonstandard physical formats, since a lot of people still using real hardware have Gotek or similar drive replacements that use that format.

Probably a good idea, though the FlashFloppy firmware for Gotek drives explicitly supports the Ensoniq 800 kB format for Ensoniq hosts, so for these keyboards in particular, HFE may be less important. Either way I'd prefer to read up more on that before I make such a change, separately from this PR.

For reading Ensoniq floppies, the GreaseWeazle software also explicitly supports Ensoniq's floppy formats, so they can be directly read to .img files for use with a FlashFloppy Gotek drive, or here in MAME.

rb6502 · 2025-11-09T18:14:24Z

src/mame/ensoniq/esq5505.cpp

+		floppy_image_device *floppy = m_floppy_connector->get_device();
+		if (floppy)
+		{
+			floppy->mon_w(motor_on ? CLEAR_LINE : ASSERT_LINE);  // active low


!motor_on should work too, and is faster to read/interpret.

rb6502 · 2025-11-09T18:16:29Z

src/mame/ensoniq/esq5505.cpp

+void esq5505_state::update_floppy_inputs()
+{
+	// update the "Disk Ready" input
+	int state = (m_floppy_is_active && m_floppy_is_loaded) ? ASSERT_LINE : CLEAR_LINE;


You can just collapse this to m_duart->ip0_w(m_floppy_is_active && m_floppy_is_loaded);

rb6502 · 2025-11-09T18:18:20Z

src/mame/ensoniq/esq5505.cpp

+		LOG("docirq (m68k_irq1) due to disk change = %d\n", floppy_dskchg_irq);
+	if (floppy_dskchg_irq && m_floppy_is_loaded)
+	{
+		// The drives that Ensoniq use only _pulse_ DSKCHG for a brief time, when a disk is in the drive.


Is this 100% verified? Most drives will raise DSKCHG on eject and then lower it the next time a seek happens with a disk in the drive, and MAME emulates that by default with the dskchg_r() method on the floppy image device.

I think so; please see this comment on the previous attempt at these changes:

Are you sure the dskchg is timer-based and not the usual "clear on first track change with a floppy in" that is implemented in floppy_image_device?

I an absolutely sure.

I first found it documented for the EPS in Keir Fraser's FlashFloppy firmware, when people tried to connect it to an Ensoniq EPS and it would not recognize disk changes.

But with this being so strange, I measured it with my cheap Saleae Logic clone logic analyzer on an SD-1/32. After a disk change - so, removed the previous disk, inserted a new disk, then went to try to read something from the disk: pressed the "Storage" button, then selected "Disk" by pressing the middle button below the screen, and then "Load" again with the middle button below the screen) - the keyboard signals (drives low) the DSEL and MO signals (enabling the drive and starting the motor), and the drive responds with a brief pulse: in my measurement with a cheap logic analyzer sampling at 4 MHz, all of two (2) samples were low, so a pulse of 500 nanoseconds and certainly no more than 1000 nanoseconds to 1 microsecond.

I'm including the sigrok trace recorded with PulseView:.

Load from floppy after new floppy inserted.zip

Look at the 335088 mycrosecond timestamp: the MO and DSEL signals both go low, and at the same time, DSKCHG goes low, but only for 2 samples, and with no other signal changing during that very short window.

The DSKCHG signal is actually routed, via a gate and a transistor, into the same IRQ line on the CPU itself that is also used by the ES5505 OTIS sound generator chip. It so happens that on the SD-1, if that interrupt is taken (and I presume after the keyboard has checked the ES5505 interrupt status), eventually the SD-1 will assert (drive low) the DSEL (and MO) lines to the floppy drive and issue a STEP command, which will inturn reset DSKCHG even on a standard drive; but that of course might take longer than it does when the drive itself only briefly pulses the signal.

And while this would technically work on the SD-1, it would not work on the EPS, as documented by FlashFloppy users - where they added a configuration setting precisely to reset DSKCHG after a short time. So including this code is useful, possibly even necessary, to get the EPS and EPS16+ to work in the future.

Huh. That's kind of wild.

Yeah, the floppy signal routing in general and the DSKCHG pulsing behaviour in particular were interesting to trace and track down. Being able to measure on real hardware and seeing the behaviour really helped confirm that was what was actually happening, even after reading about it in the FlashFloppy firmware discussion and documentation.

rb6502 · 2025-11-09T18:20:47Z

src/mame/ensoniq/esq5505.cpp

 	    bits 0/1/2 = analog sel
 	    bit 3 = SSEL (disk side)
-	    bit 4 = DSEL (drive select?)
+	    bit 4 = DSEL (Drive Delect and floppy Motor On)


Delect? :-)

"Select" of course. Fixed.

rb6502 · 2025-11-09T18:21:32Z

src/mame/ensoniq/esq5505.cpp

 		else
 		{
-			floppy->ss_w(((data & 8)>>3)^1);
+			floppy->ss_w(((data & 8) >> 3) ^ 1); // bit 3, inverted -> floppy


floppy->ss_w(!BIT(data, 3)); would do the same thing much cleaner.

rb6502 · 2025-11-09T18:22:08Z

src/mame/ensoniq/esq5505.cpp

 		{
-			floppy->ss_w(((data & 8)>>3)^1);
+			floppy->ss_w(((data & 8) >> 3) ^ 1); // bit 3, inverted -> floppy
+			m_floppy_is_active = (data & 16) != 0; // bit 4 is used to activate the floppy:


Similarly, m_floppy_is_active = BIT(data, 4);

cbrunschen · 2025-11-09T20:14:43Z

Thank you!

cbrunschen marked this pull request as ready for review October 31, 2025 22:01

cbrunschen added 2 commits November 5, 2025 13:30

esq5505.cpp: Add VFX-family ROM & EEPROM Cartridge support, and impro…

6897837

…ve floppy support. Second attempt, simpler and hopefully better.

When the floppy is active (i.e., when the motor is actually on), also…

0fb58f4

… indicate this on the LED on the panel layout.

cbrunschen force-pushed the vfx_cart_and_floppy branch from f2ee5f5 to 0fb58f4 Compare November 5, 2025 13:53

MooglyGuy requested changes Nov 5, 2025

View reviewed changes

cbrunschen added 2 commits November 5, 2025 18:38

Address the first round of comments.

9d13988

Only create writeable cartridge images.

c1ec150

The user can always rename a writable (.eeprom, .sc32) image to .rom or .cart to mark it as read-only.

cbrunschen marked this pull request as draft November 6, 2025 12:47

Restore the previous behaviour when creating a cartridge image - even…

7712060

… ones created with the filetypes that indicate a read-only image are effectively write-once. Also normalize the spelling of to "writeable".

cbrunschen marked this pull request as ready for review November 7, 2025 09:53

cbrunschen mentioned this pull request Nov 9, 2025

Add software lists for the Ensoniq VFX-SD, SD-1 and SD-1/32 keyboards. #14498

Merged

rb6502 reviewed Nov 9, 2025

View reviewed changes

Address comments from R.Belmont.

1455cef

rb6502 merged commit 29ea404 into mamedev:master Nov 9, 2025
7 checks passed

cbrunschen deleted the vfx_cart_and_floppy branch November 9, 2025 20:15

cbrunschen mentioned this pull request Nov 10, 2025

esq5505.cpp: Also support HFE format flopppy images. #14504

Merged

esq5505.cpp: Add VFX-family ROM & EEPROM Cartridge support, and improve floppy support. #14444

esq5505.cpp: Add VFX-family ROM & EEPROM Cartridge support, and improve floppy support. #14444

Conversation

cbrunschen commented Oct 31, 2025

Uh oh!

cbrunschen commented Oct 31, 2025

Uh oh!

MooglyGuy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cbrunschen commented Nov 7, 2025

Uh oh!

MooglyGuy commented Nov 8, 2025

Uh oh!

cbrunschen commented Nov 8, 2025

Uh oh!

cbrunschen commented Nov 8, 2025

Uh oh!

MooglyGuy commented Nov 8, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rb6502 Nov 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cbrunschen commented Nov 9, 2025

Uh oh!

Reviewers

Assignees

rb6502 Nov 9, 2025 •

edited

Loading