rm/rm380z.cpp: Add COS 4.0/F firmware #12195

RobinSergeant · 2024-03-30T12:00:55Z

This PR adds support for COS 4.0/F, new romset attached below:

It's basically the same as COS 4.0/M, but with some differences in the FDC code (no motor control and different timing). The 8" disk support is useful as it allows larger CP/M programs to run using the VDU-80 display.

I have also verified that the 4.0/M roms we had are good, and made the machine descriptions clearer by adding "/M" and "/F" postfixes.

cuavas

I’m concerned that this may lead to confusion later, because developers expect a machine configuration function name to represent a distinct machine configuration.

Using a virtual configure member function like this goes against expectations, so people will need to be aware that this system doesn’t follow the common pattern when reading the system definitions.

Making configure_fds also call through to the virtual configure member function compounds it further.

RobinSergeant · 2024-03-30T17:55:11Z

I’m concerned that this may lead to confusion later, because developers expect a machine configuration function name to represent a distinct machine configuration.

Using a virtual configure member function like this goes against expectations, so people will need to be aware that this system doesn’t follow the common pattern when reading the system definitions.

Making configure_fds also call through to the virtual configure member function compounds it further.

I was trying to avoid having multiple 'configure_fds' functions, but would the alternative solution I've just pushed be better? I've renamed the configure functions to match the machine name (as in other drivers), and found another way to avoid too much duplication. How does this look @cuavas ?

rb6502 · 2024-05-20T17:24:23Z

src/mame/rm/rm380z.cpp

-
-	FLOPPY_CONNECTOR(config, m_floppy0, rm380z_floppies, "mds", floppy_image_device::default_mfm_floppy_formats).set_fixed(true);
-	FLOPPY_CONNECTOR(config, m_floppy1, rm380z_floppies, "mds", floppy_image_device::default_mfm_floppy_formats).set_fixed(true);
+	if (bFDS)


A better pattern for this would be to have a base_configure function that sets up all of the non-optional hardware and then call it from each specific machine's configure function and add on the rest.

Look at https://github.com/mamedev/mame/blob/master/src/mame/apple/maclc3.cpp where I do exactly this: maclc3_base() configures the non-optional hardware and the actual machines call it and then do their additional things.

Thanks @rb6502. I'm already trying to do that really and rm380z_state::configure() is my base configure function (maybe it should be called base_configure to make that clearer). This is called by the specific configure functions such as rm380z_state_cos34::rm380z34e(). The bFDS parameter just cuts down on the number of configure functions needed as the FDS versions can then be simple inline functions like this:

void rm380z34e(machine_config &config, bool bFDS = false); void rm380z34d(machine_config &config) { rm380z34e(config, true); }

Using a C++ default value means that rm380z_state_cos34::rm380z34e() can be called with just the machine_config reference and it will then call rm380z_state::configure() with bFDS as false for the MDS (5.25" disk) config.

The FDS COS 3.4 config function rm380z34d simply calls the MDS version with bFDS set to true resulting in only the floppy drive config being different. The other configs follow the same pattern.

Does this seem ok? It would be nice to get this change delivered as being able to use 8" disks with COS 4.0 is useful.

galibert · 2024-05-21T14:48:36Z

You could have a fds(machine_config &config) method which adds what's in if (bFDS) and have void rm380z34d(machine_config &config) { rm380z34e(config); fds(config); }

…

On Tue, May 21, 2024 at 4:18 PM Robin Sergeant ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/mame/rm/rm380z.cpp <#12195 (comment)>: > @@ -268,30 +268,28 @@ void rm380z_state::configure(machine_config &config) RAM(config, RAM_TAG).set_default_size("56K"); /* floppy disk */ - FD1771(config, m_fdc, 16_MHz_XTAL / 16); - - FLOPPY_CONNECTOR(config, m_floppy0, rm380z_floppies, "mds", floppy_image_device::default_mfm_floppy_formats).set_fixed(true); - FLOPPY_CONNECTOR(config, m_floppy1, rm380z_floppies, "mds", floppy_image_device::default_mfm_floppy_formats).set_fixed(true); + if (bFDS) Thanks @rb6502 <https://github.com/rb6502>. I'm already trying to do that really and rm380z_state::configure() is my base configure function (maybe it should be called base_configure to make that clearer). This is called by the specific configure functions such as rm380z_state_cos34::rm380z34e(). The bFDS parameter just cuts down on the number of configure functions needed as the FDS versions can then be simple inline functions like this: void rm380z34e(machine_config &config, bool bFDS = false); void rm380z34d(machine_config &config) { rm380z34e(config, true); } Using a C++ default value means that rm380z_state_cos34::rm380z34e() can be called with just the machine_config reference and it will then call rm380z_state::configure() with bFDS as false for the MDS (5.25" disk) config. The FDS COS 3.4 config function rm380z34d simply calls the MDS version with bFDS set to true resulting in only the floppy drive config being different. The other configs follow the same pattern. Does this seem ok? It would be nice to get this change delivered as being able to use 8" disks with COS 4.0 is useful. — Reply to this email directly, view it on GitHub <#12195 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4I3QAG4MJZSXVAIBS3ZDNJSTAVCNFSM6AAAAABFPP4IHGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDANRYG44DCOJUHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

RobinSergeant · 2024-05-21T15:30:11Z

You could have a fds(machine_config &config) method which adds what's in if (bFDS) and have void rm380z34d(machine_config &config) { rm380z34e(config); fds(config); }

Thanks @galibert. That is another way of doing it and I've just pushed a commit with that method! Although it's more a question of switching the MDS config to FDS config than adding anything, i.e.

void rm380z_state::fds_configure()
{
	// FDS drives require a 2 MHz square wave clock frequency
	m_fdc->set_unscaled_clock(16_MHz_XTAL / 8);
	// change media type for floppy connectors
	m_floppy0->set_default_option("fds");
	m_floppy1->set_default_option("fds");
}

@rb6502, do you prefer this solution? I guess you can choose either commit now.

rb6502 · 2024-05-21T15:59:36Z

I like @galibert 's solution. I'll give this a read-through and see if it's ready now.

RobinSergeant · 2024-05-21T16:14:38Z

I like @galibert 's solution. I'll give this a read-through and see if it's ready now.

Great, thank you

rb6502 · 2024-05-23T11:31:08Z

Ok, going back to Vas' original note, we generally use the -bios/ROM_SYSTEM_BIOS functionality for different ROM versions on the same hardware. Having completely separate machine names for that is an old MESS anachronism from before that capability existed.

So for this, you'd want (at least for now) base, HRG, and cassette as the drivers, and each would use -bios to select an older version.

RobinSergeant · 2024-05-23T14:52:55Z

Ok, going back to Vas' original note, we generally use the -bios/ROM_SYSTEM_BIOS functionality for different ROM versions on the same hardware. Having completely separate machine names for that is an old MESS anachronism from before that capability existed.

So for this, you'd want (at least for now) base, HRG, and cassette as the drivers, and each would use -bios to select an older version.

I think Vas was talking about my use of the same virtual function name for every configure function which he thought was confusing (they were all called "configure" originally).

The hardware is actually different though because the FDS machines had a different floppy controller (with different clock frequency) and of course the drives themselves were different (8" external instead of 5.25" internal). On a real FDS machine you cannot use the MDS firmware and vice versa. Hence the need for the fds_configure() function. Is it possible/wise to change the hardware based on the -bios flag? At one time I had code to change the floppy clock frequency depending on the inserted media, but Vas made me remove that as the real hardware could only read one type of disk.

To reduce the number of drivers we could get rid of the non HRG COS 4.0 machines as I cannot think of any reason to not have HRG. The only reason originally was cost, but virtual hardware is free!

rb6502 · 2024-05-23T16:57:24Z

-bios can't change the hardware, only the firmware. For the base machine, rm380z, there are 3 variants that at a glance are just the base machine with 4.0F, 3.4M, and 3.4F. Those can all just be a -bios selection for the base machine. Similarly, for the HRG machine, which I gather you need 4.0 to run, 4.0M and 4.0F can be -bios options. Ditto for the FDC.

At some point in the future we'll want to make this all configurable in the way that other machines in MAME with expansion cards are, but for now I'm OK with just reducing things via -bios where it makes sense. That's still forward progress, and I'm sort of the unofficial cheerleader for MAME supporting more CP/M machines than anything else ;-)

Regarding non-HRG, it's always useful to support very basic configurations in case someone wants to verify that some new software works. We're not always perfect on that stuff (and particularly on how/why things would fail in that case) but we do attempt it since it's largely free for us to do so.

RobinSergeant · 2024-05-23T20:52:53Z

-bios can't change the hardware, only the firmware. For the base machine, rm380z, there are 3 variants that at a glance are just the base machine with 4.0F, 3.4M, and 3.4F. Those can all just be a -bios selection for the base machine. Similarly, for the HRG machine, which I gather you need 4.0 to run, 4.0M and 4.0F can be -bios options. Ditto for the FDC.

The hardware for all the machines is actually different. Here is a quick summary:

COS 4.0B/M = (VDU-80 display, MDS floppy controller, 5.25" drives, sound)
COS 4.0B/M with HRG = (VDU-80 display + HRG, MDS floppy controller, 5.25" drives, sound)
COS 4.0B/F = (VDU-80 display, FDS floppy controller, 8" drives, sound)
COS 4.0B/F with HRG = (VDU-80 display + HRG, FDS floppy controller, 8" drives, sound)
COS 3.4D/F = (VDU-40 display, FDS floppy controller, 8" drives, cassette)
COS 3.4E/M = (VDU-40 display, MDS floppy controller, 5.25" drives, cassette)

On real hardware you needed COS 3.x to drive the VDU-40 display, COS 4.x to drive the VDU-80 display, /F for FDS drives, and /M for MDS drives etc.

So I don't think -bios can be used here unless I'm misunderstanding something? I've had a quick look at some drivers that use ROM_SYSTEM_BIOS and it seems to only allow different ROM files to be loaded and the state class or configure functions cannot be changed. I can see it would be useful if we had dumps of other compatible versions (e.g. COS 3.0/M), but I don't think I can use it at the moment?

At some point in the future we'll want to make this all configurable in the way that other machines in MAME with expansion cards are, but for now I'm OK with just reducing things via -bios where it makes sense. That's still forward progress, and I'm sort of the unofficial cheerleader for MAME supporting more CP/M machines than anything else ;-)

Sounds like something to look into in the future then. The CP/M era was quite special I think.

Regarding non-HRG, it's always useful to support very basic configurations in case someone wants to verify that some new software works. We're not always perfect on that stuff (and particularly on how/why things would fail in that case) but we do attempt it since it's largely free for us to do so.

True, I guess it's useful for that reason. Currently somebody is porting a new Infocom text adventure engine to the 380Z and they have been asking me for the 8" disk support as it's difficult to fit game data files onto the tiny 5.25" disks and they only want to support the VDU-80 display.

RobinSergeant added 2 commits March 30, 2024 11:43

add COS 4.0/F

4392c90

fix clone of clone validate error

69c03ab

cuavas reviewed Mar 30, 2024

View reviewed changes

alternative configure approach

0780007

RobinSergeant requested a review from cuavas April 1, 2024 15:09

rb6502 reviewed May 20, 2024

View reviewed changes

simplify fds configuration

9456087

rb6502 merged commit 7074cdf into mamedev:master May 24, 2024
5 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rm/rm380z.cpp: Add COS 4.0/F firmware #12195

rm/rm380z.cpp: Add COS 4.0/F firmware #12195

RobinSergeant commented Mar 30, 2024 •

edited

cuavas left a comment

RobinSergeant commented Mar 30, 2024

rb6502 May 20, 2024 •

edited

RobinSergeant May 21, 2024

galibert commented May 21, 2024 via email

RobinSergeant commented May 21, 2024

rb6502 commented May 21, 2024

RobinSergeant commented May 21, 2024

rb6502 commented May 23, 2024 •

edited

RobinSergeant commented May 23, 2024

rb6502 commented May 23, 2024 •

edited

RobinSergeant commented May 23, 2024 •

edited

rm/rm380z.cpp: Add COS 4.0/F firmware #12195

rm/rm380z.cpp: Add COS 4.0/F firmware #12195

Conversation

RobinSergeant commented Mar 30, 2024 • edited

cuavas left a comment

Choose a reason for hiding this comment

RobinSergeant commented Mar 30, 2024

rb6502 May 20, 2024 • edited

Choose a reason for hiding this comment

RobinSergeant May 21, 2024

Choose a reason for hiding this comment

galibert commented May 21, 2024 via email

RobinSergeant commented May 21, 2024

rb6502 commented May 21, 2024

RobinSergeant commented May 21, 2024

rb6502 commented May 23, 2024 • edited

RobinSergeant commented May 23, 2024

rb6502 commented May 23, 2024 • edited

RobinSergeant commented May 23, 2024 • edited

RobinSergeant commented Mar 30, 2024 •

edited

rb6502 May 20, 2024 •

edited

rb6502 commented May 23, 2024 •

edited

rb6502 commented May 23, 2024 •

edited

RobinSergeant commented May 23, 2024 •

edited