mfabfz.cpp: Preliminary work to get the CP/M extension included #13388
Conversation
… the MFA Mikrocomputer. The actual ROM/RAM banking mechanism and the FDC setup are still missing.
hash/mfacpm.xml
Outdated
| <softwarelist name="mfacpm" description="MFA Mikrocomputer fuer Ausbildung CP/M disks"> | ||
|
|
||
| <software name="mfacpm"> | ||
| <description>MFA Mikrocomputer fuer Ausbildung original CP/M</description> |
There was a problem hiding this comment.
Did they actually use the spelling “fuer”, or did they use “für”?
There was a problem hiding this comment.
Good thing you opened that can of worms, I wasn't aware of the multitude of names they used for the system over time.
MFA is the abbreviation for "Mikrocomputer für Ausbildung", it's listed as such on Wiki, and this is how it's usually referred to. The system is ASCII only, so no umlauts are on the the original keyboard. This is why I automatically replaced the "ü" with "ue".
Earlier systems are labelled "MFA Mikrocomputer", later ones "MFA Mediensystem" on the power supply.
The MAT ROMs that are already in MAME sign on as "BFZ/MFA Mikrocomputer".
Earlier documentation is for "MFA Mikrocomputer", later one is labelled as "MFA Mediensystem Mikrocomputertechnik".
I'm using the Umlaut now, but I'm keeping the "MFA Mikrocomputer für Ausbildung" as this is what it's known best for.
The "original" CP/M is on a copied disk with a hand printed label, as it came from a sort of distribution service (think shareware houses, but not shareware), with added utilities, so I've marked it as a bad dump.
I'll upload a revision soon.
As an aside: Are umlauts allowed in comments in the source code?
src/mame/skeleton/mfabfz.cpp
Outdated
| class mfacpm_state : public driver_device | ||
| { | ||
| public: | ||
| mfacpm_state(const machine_config &mconfig, device_type type, const char *tag) | ||
| : driver_device(mconfig, type, tag) | ||
| , m_maincpu(*this, "maincpu") | ||
| , m_shared_ram(*this, "shared_ram") | ||
| , m_bootview(*this, "bootview") // see memory map | ||
| , m_uart(*this, "uart2") | ||
| { } | ||
|
|
||
| void mfacpm(machine_config &config); | ||
|
|
||
| private: | ||
| void mfacpm_io(address_map &map) ATTR_COLD; | ||
| void mfacpm_mem(address_map &map) ATTR_COLD; | ||
| void machine_reset() override ATTR_COLD; | ||
| void machine_start() override ATTR_COLD; | ||
| required_device<cpu_device> m_maincpu; | ||
| required_shared_ptr<uint8_t> m_shared_ram; | ||
| memory_view m_bootview; | ||
| required_device<i8251_device> m_uart; | ||
| }; |
There was a problem hiding this comment.
Is it not possible to share a base class for these, or are they completely unrelated systems? If they’re unrelated, do they belong in the same file as each other?
There was a problem hiding this comment.
The system is modular, and I think the OP wants to be able to deliver a machine with the native, low level monitor and another with the optional but higher level CP/M extension.
There was a problem hiding this comment.
RetroAND's interpretation is correct. The system is on an ECB bus like backplane, and you should ideally be able to mix and match your slot options in MAME. Until then it would be great to have CP/M going. In real hardware you modify some cards by setting system parameters via solder bridges, so I think it belongs to the same driver.
CP/M ROMs added - CP/M bootdisk softlist - information to add the floppy interface and memory banking