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

It's strange. I have added the driver to mame.lst as required but it can't find it. Please, does anybody have any clues about it? Otherwise the source seems to be compiling correctly.

Sorry again for the hassle

When building, you need to provide the full path to the driver file: src/mame/ibm/system23.cpp

Regarding the machine_config function, refer to this file, it's one of the more straightforward and small drivers that actually displays something: https://github.com/mamedev/mame/blob/master/src/mame/skeleton/600cat.cpp

See the function at line 124? You need a function like that in your own driver, which configures the CPU and any other devices used by the system. Let's go over the one in 600cat.cpp together -

This is the function prototype. It always takes a reference to a machine_config, called config. It's no different from a function in C, it's just namespaced to the class that it belongs to: _600cat_state.

This configures the class member "m_maincpu", which you can see declared on line 51. It's a Hitachi HD6303R CPU, clocked at 4MHz.

This tells our main CPU about the function used to configure its program-space address map.

These plumb various callbacks specific to the Motorola HD6303 to the appropriate functions in the driver class.

This configures the class member "m_screen", which you can see declared on line 53. We configure it as an LCD-type screen, since this was a handheld device with a simple LCD display.

...with a (guessed) 50Hz refresh rate, a (guessed) 2500-microsecond vertical blanking interval, and a resolution of 120x36.

This sets the screen to not have vertical or horizontal blanking periods, due to being an LCD. This means that my call to "set_vblank_time" above is actually an error on my part and could potentially be removed.

Every screen needs to have its contents painted, right? Usually, this would refer to a function in the driver class itself. But since our screen is driven by the LCD controller (see below), we point it at the appropriately-named member function provided by the LCD controller device.

This points the screen at our palette device, in order to have a more realistic-looking LCD palette.

This configures the class member "m_palette", which you can see declared on line 54. palette_device is a device which, as the name implies, is used to provide a palette, for the (many) systems that didn't use direct RGB. The palette is initialized by a function in our driver class called "lcd_palette", and the palette is 3 entries long.

This configures the class member "m_lcdc", which you can see declared on line 52. It is a Hitachi HD44780 LCD controller chip. The implementation is in src/devices/video/hd44780.h (and .cpp). Since we don't know the actual clock used, we go with a relatively safe default of 270kHz.

The LCD is 4 lines tall and 20 characters wide.

The HD44780 implementation uses a function delegate so that drivers using it can have exact control over how the character pixels are drawn, oriented, and so on. So we point it at our driver's function, lcd_pixel_update, which is declared at line 40 and defined starting at line 58.

This system also has a Dallas DS1643 real-time clock, so at this point in the machine configuration function, we configure the class member "m_rtc", which was declared on line 55 in our driver class declaration.

I rechecked with 600cat.cpp and understood what was I doing wrong. I committed some stupid errors, such as naming the namespace and declaring the driver inside it. I get it compiled into an application with the main menu and the only option is this driver. It is a big step for the first day.
I have updated the checksums, but it just doesn't recognize them. I guess I have to tinker with it a little more.

Thank you!

Yesterday I managed to get the driver "working". It now gets stuck during the tests programmed in ROM. With the information I had beforehand and the result of running the program with the -debug flag I found that port A of the 8255 that manages the keyboard is used to test the CPU and the bus. It stucks just two instructions before writing to the LED display for the first time.

I took as an example the IBM Displaywriter (ibm6580.cpp), which also carries this component. At the time being I have tried by creating a private variable that holds the value of the register, then read and write to them using getters/setters and finally setting such methods as callbacks of the 8255. However, it seems that reading from the port always returns 0xff, as if nothing was assigned of that port (or tristated?). Any experience with the usage of this component?

Thank you in advance

It's impossible to guess just based on a verbal description, show how you've hooked up the port callbacks. Either put the current revision on gist.github.com and post a link, or just commit what you have to your existing branch.

My bad. Sorry, I forgot. I will try to be more careful in the future.

system23.cpp at github

You only mapped your PPI to a single address, so:
should be:

PPI is 4 addresses so:

(ppi offset $3 is for mode select and tristate of port C)

At the end this was the solution that solved my problem. So the emulated Datamaster now passes the first test and assigns the LED display for the first time. It now gets stuck in the second test, but I will investigate the issue.
I have seen the 7-segment LED display is directly driven by the values I send to them. Is there some sort of table/array to transform an hexadecimal number into 7-segment display code?

Thank you very much!

You will need to provide the pattern yourself. Here's an example:


(from mwsub.cpp)