Home Page Forums MAME MAME Writing a driver from scratch - help, please

Good morning,

I am trying to write a driver from scratch and I have many doubts:

• I do not know how to compile only the source I am working on. I followed the instructions but cannot compile especifically the part I want, something seems to be missing.
• I do not know how to add LED devices into my driver. The computer I am trying to emulate has a diagnostics port whose values are read using a LED probe add-on. Due of the complexity of the computer, it is crucial for this diagnostics port to be readable during the development.
• Under Windows, how could I generate the checksum hashes for the ROMs I want to include in the project?

I do know these are very noob questions, but I am already making an effort to understand C++ and I find MAME documentation is too complex for a newcomer. If you are asking yourselves why I am going through all the trouble with this, I let you know all this hassle is for bringing the first ever emulator for this forgotten machine - so forgotten it's not even in any dump or TO-DO list.

Thank you for your time and patience!

If you don't understand C++, a MAME driver is not the ideal way to learn it, but I'll try to answer your questions.

When you add a completely new source file, the first time you compile with it you must include REGENIE=1 when doing the 'make' so that the build system will re-scan for new files. Also, don't forget to add the new driver to src/mame/mame.lst or MAME will say the driver doesn't exist when it does.

Are these individual LEDs, or a 7-segment display, or some other kind of LED display?

For hashes, a lot of people simply add fictional hashes like "12345678" the first time. When you try and run the driver, MAME will print the hashes it actually found and you can copy and paste those out from your command window.

I do understand C but C++ is not something in which I have had an excuse to deal with. I used to program web applications...

I'll take note on the REGENIE option. This will come useful indeed.

About the LEDs, any of both could be used. The diagnostics port per se expects the probe to be connected, but no probe for this machine has been found to this day. What I have is a homemade device which simply add eight LEDs. The only difference is having to interpret the outcoming signals or having them presented nicely without effort.

[video:youtube][/video]

I'll take also note for the hashes.

Thank you!

If you want to treat it as a pair of 7-segment displays for convenience, the easiest thing to do would be to have two output digits:

Ensure that they're initialized in your driver_device's constructor:

To send an 8-bit value to them:

To see how to display them using MAME's artwork system, refer to src/mame/layout/maxaflex.lay, and take note of the named "digit" element, and the two individual digits - "digit1" and "digit0" - that refer to it.

Give your .lay file an appropriate name and ensure it's in src/mame/layout/, and include the generated layout file as so:

In the machine-configuration function, point the machine config at it:

Build with REGENIE=1 once again, to ensure that the necessary layout-header is generated from the .lay that you created.

If you want to display each individual bit, there should be enough info above, while also referring to the maxaflex layout file, for you to intuit how to do that.

Last, but not least, it might speed up your development process by doing a single-driver build, and also using "lld" to link instead of the usual "ld". You do that like so:

...and take the REGENIE=1 off once you've built. Re-add it if you add any new files.

Make sure that any new drivers are added to src/mame/mame.lst in the appropriate spot, and any new CPU cores or individual devices are added to the appropriate Lua scripts in scripts/src/.

Thank you very much for this information. I am, however, lost when dealing with the layout. I have updated my mame devices list and created the first commit into my private repository. You can find the new source in the following link.

The plan is to have a skeleton that runs the diagnostics steps correctly from the beginning of the work and we keep adding the required parts in the order marked by the tests. I think this way the emulator would self-verify itself.

I am sure I missed something, don't know what because I am still very green at it. Please, could anybody take a look at it?

Thank you very much and sorry for the hassle

1. Should go under `src/mame/ibm/system23.cpp`
2. `MACHINE_SKELETON` is a flag that doesn't exist in bleeding edge.
3. Needs a machine_config that describes what components your motherboard has.
4. `ROM_REGION(0x1800, "ros_unpaged", 0)` will throw a validation failure, what you map below is 0x4000 in length.

To be more explicit about point 3, do a Find In Files in src/mame/*.cpp for (machine_config &config), literally every machine has one, it's what specifies the actual hardware that existed for a machine.

Thank you very much for the insight.

1. Isn't the code already at this directory?
2. Removed the flag.
3. I don't understand this point.
4. Copy-paste issues. Corrected to 0x4000. I am examining both ibm6850.cpp and alphatpx.cpp as references.

Again, thank you for your assistance

I will take a look for it. Thank you very much!

Hm... the source is at this directory, but it's true that it is not finding it for some reason. I have the impression that is what you intended to point out, right?

Again, thank you