clang 3.0:

Compiling src/emu/emuopts.cpp...
clang++    -MMD -MP -Dnullptr=NULL -DPTR64=1 -DNDEBUG -DCRLF=2 -DLSB_FIRST -DFLAC__NO_DLL -DNATIVE_DRC=drcbe_x64 -DLUA_COMPAT_APIINTCASTS -I../../../../../src/osd -I../../../../../src/emu -I../../../../../src/devices -I../../../../../src/lib -I../../../../../src/lib/util -I../../../../../3rdparty -I../../../../generated/emu -I../../../../generated/emu/layout -I../../../../../3rdparty/expat/lib -I../../../../../3rdparty/lua/src  -m64 -arch x86_64 --pipe -Wno-deprecated-declarations -O3 -fno-strict-aliasing -Werror -Wno-unknown-pragmas -Wall -Wcast-align -Wundef -Wformat-security -Wwrite-strings -Wno-sign-compare -Wno-conversion -Wno-cast-align -Wno-tautological-compare -Wno-dynamic-class-memaccess -m64 -DINLINE="static inline" -x c++ -std=gnu++98 -Wno-variadic-macros -Wno-long-long -Woverloaded-virtual  -o "../../../../osx_clang/obj/x64/Release/src/emu/emuopts.o" -MF ../../../../osx_clang/obj/x64/Release/src/emu/emuopts.d -c "../../../../../src/emu/emuopts.cpp"
../../../../../src/emu/emuopts.cpp:564:31: error: no viable conversion from
      'emu_file' to 'core_file'
        bool result = parse_ini_file(file, priority, ...
                                     ^~~~
../../../../../src/emu/fileio.h:94:2: note: candidate function
        operator core_file &();
        ^
../../../../../src/lib/util/options.h:142:33: note: passing argument to
      parameter 'inifile' here
        bool parse_ini_file(core_file &inifile, int priority, int ...
                                       ^
1 error generated.
make[2]: *** [../../../../osx_clang/obj/x64/Release/src/emu/emuopts.o] Error 1
make[1]: *** [emu] Error 2
make: *** [macosx_x64_clang] Error 2

Make screen::update_now() actually work properly.

Must handle the "degenerate case" where there's a set of full scanline(s) that need to be drawn to catch up before the current scanline by calling update_partial() first.

Drivers calling this will need to make sure their screen update functions respect the cliprect. apple2e running the "Crazy Cycles" demo will be the initial test case.

(Currently in progress: October 14, 2015, RB)

Change the resampler so that it's better quality and causal.

Make the audio stream update independant of the video update.

Ensure a better consistency of timings between streams and cpus/executable devices.

Maybe best for someone with knowledge of hardware and renderers:
midzeus.cpp in drivers and video
midzeus2.cpp in video

parts of model1, model2 in video

I admit this is something I've played with from time to time, but never got anywhere with. At the moment, we're served relatively well for internal and external layouts for simple titles because of the basic XML layout engine we currently have. My concern is that as the goals of MAME evolve, the ability to layout the necessary art elements via simple calculation will not be sufficient to incorporate everything. Taking the example of the slot machines and similar devices we now include - many of these require hundreds of independent lighting objects, as well as positioning of mechanical devices that we simulate, but not in a manner that makes the layout particularly intuitive.

My proposal is that, in order to assist with making these kinds of layouts, we liaise with those in modding communities like Hyperspin etc, and attempt to develop a cross-platform, open layout creator and editor to enable those whose skills are more art focussed than programming focussed to actually be able to build MAME compatible layouts, and add the potential to include any other objects we ultimately add to the renderer.

Taking the example of the old FME community (as this is the closest in scope to my suggestion), the tools for development are often no more than basic drag and drop tile positioning, with palettes of object types for the more complex materials. In our case, we do represent a bit more flexibility, but still relatively sensible.

I run it this way:
./mame64 -rp ~/nonfree/MAME0164/ROMs/ at386 -board4:lpt:lpt:centronics ap2000 -window

And I get a black screen with the following error message on the text terminal being printed several times:
SDL: ERROR! Unknown video mode: R=00000000 G=00000000 B=00000000

Text pasted with permission from an e-mail by github user awjackson:

MAME only supports one layout for the entire emulated machine, including all slot devices that happen to be connected. If you specify a MCFG_DEFAULT_LAYOUT in a slot device, you're overriding the layout for the entire machine, not adding elements to an existing layout. To [...] plug a printer into a slot and have it display its own artwork and LEDs in addition to the screens and whatnot of the base system, we're going to have to come up with a whole new framework for "layout fragments" and figure out how the core should assemble them into a complete layout.

The reason slot devices with screens work is because in the absence of any layout file (neither user-provided, in MCFG, nor in a GAMEL macro) the core will select a default layout based (solely) on the total number of screens in the machine, including slots. But, again, this only works if there isn't any layout file. So right now, unfortunately, you can't have a machine with a built-in non-4:3 screen that also supports connecting additional screens via slots (e.g. a laptop with an external monitor port)

Add support for XInput on windows OSD

Submission for new MESS driver of spc1500 from Samsung Electronics in 1987
I attached ROM binaries and driver source file with modified mess.lst and mess.lua.

Samsung SPC-1500 driver by Miso Kim

2015-12-16 preliminary driver initialized
2015-12-18 cassette tape supported
2015-12-26 80/40 column mode supported
2015-12-28 double access mode supported for I/O
2016-01-02 Korean character input method and display enabled

TODO:

Recover color palette after list and width command in basic mode
Support user defined char setting
Support floppy disk drive with SD-1500A controller card

spc1500src.zip
spc1500.zip

"Attempt to register save state entry after state registration is closed!
Module M68000 tag :maincpu name REG_D(this)"

Visual Studio 2015, debug mode. genesis platform. save.cpp:

// check for invalid timing
    if (!m_reg_allowed)
    {
        machine().logerror("Attempt to register save state entry after state registration is closed!\nModule %s tag %s name %s\n", module, tag, name);
        if (machine().system().flags & MACHINE_SUPPORTS_SAVE)
            fatalerror("Attempt to register save state entry after state registration is closed!\nModule %s tag %s name %s\n", module, tag, name);
        m_illegal_regs++;
        return;
    }

Essentially make it build as fast (or faster) as it used to before changing to Genie.

-listmedia/slot/device/software/xml (at least)
-- memory leak warning --
Error message spam (nofree) pointing at:
"../../../../../src/emu/netlist/plib/plists.h"
"../../../../../src/emu/netlist/plib/pstring.c"
As show in http://pastebin.com/YRTd47zL

Appears to have broken with this submit on August 27, 2015
bce5387

Introduce libuv (https://github.com/libuv/libuv) as main library for IPC layer.

This one should cover all async communication.

As first step remove mongoose (since it have limited license) and use libuv.

Create osd layer that maps to libuv calls used by our code.

Convert current socket communication to use libuv in osd layer.

Code in devices/video/voodoo.* is the last user of the legacy polygon rasterizing code as well as at least one other legacy MAME construct. A restructuring of the code will make the voodoo emulation more portable and relieve MAME of 2 or more legacy implementations.

Create ability to support audio inputs from OSD.

Simple test case would loading tapes directly from audio input instead of wav file

We just lost a whole bunch of the project's history with the recent commit pushed by @mmicko (1fc48ce). It seems to me that this bulk change should have been performed with the git-mv command to that the history of commits of each file would be preserved.

This can be seen by looking at the commit history of any of the older mess drivers and noticing that now we only see a single commit there. Look at this one as an example:
https://github.com/mamedev/mame/commits/master/src/mame/drivers/ibmpc.c

Previously there used to be a much richer development history as we can see here:
https://github.com/mamedev/mame/commits/5d1376e27ebadb5ced8a6879c3e15bf2006ba871/src/mess/drivers/ibmpc.c

History is still there (it is not _really_ lost) but it is certainly hidden, which is not optimal. Isn't there a way for file moves in git to carry the commit history of a renamed file?

Hi,

I'm currently playing zeldaldxja (Link's Awakening DX, Japanese Revision A). Many pitches in the audio sound a quarter-step off key. I couldn't find any issue listed like this, so I just wanted to make sure it was known.

When using offscreen reload with a Wiimote, one has to aim at the edge of the screen in order to trigger a reload. This is problematic given that the edge of the screen is also the edge of wiimote's usability.

Something useful does happen you aim offscreen with a wiimote though: the cursor doesn't move at all.

Would it be possible to make it so that whenever the cursor hasn't moved at all for a few (configurable) milliseconds, that this sets the lightgun to "offscreen"?

Right now we have a framework for HLE'd I/O boards that's used by Naomi, and various Namco System 12 and 23 games using forced direct-hookup to emulated I/O boards. This needs to be brought together so HLE and fully emulated I/O boards can be freely intermixed. This means making the HLE boards speak a serial bitstream, among other things.

Seems these do different things for each brand. So far I see:

-Taito: Not sure what dip 3 does yet, but dip 4 brings the game's test menu up on boot.
-Video system: Dip 3 brings the game's test menu up on boot, dip 4 purges (disables?) nvram completely and prevents further saving.

I imagine every brand uses one of them for game test menus.

laserbat.cpp is the last user of the former.

Compiling on osx with clang 3.0:

kremvax:~/build/mame: clang --version
Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
Compiling 3rdparty/sqlite3/sqlite3.c...
../../../../../3rdparty/sqlite3/sqlite3.c:66818:7: error: expression result
      unused [-Werror,-Wunused-value]
      getVarint32(&aKey1[idx1], serial_type);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../3rdparty/sqlite3/sqlite3.c:12952:3: note: instantiated from:
  (u8)((*(A)<(u8)0x80)?((B)=(u32)*(A)),1:sqlite3GetVarint32((A),(u32 *)&(B)))
  ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../3rdparty/sqlite3/sqlite3.c:66849:7: error: expression result
      unused [-Werror,-Wunused-value]
      getVarint32(&aKey1[idx1], serial_type);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../3rdparty/sqlite3/sqlite3.c:12952:3: note: instantiated from:
  (u8)((*(A)<(u8)0x80)?((B)=(u32)*(A)),1:sqlite3GetVarint32((A),(u32 *)&(B)))
  ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../3rdparty/sqlite3/sqlite3.c:67019:3: error: expression result
      unused [-Werror,-Wunused-value]
  getVarint32(&aKey1[1], serial_type);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../3rdparty/sqlite3/sqlite3.c:12952:3: note: instantiated from:
  (u8)((*(A)<(u8)0x80)?((B)=(u32)*(A)),1:sqlite3GetVarint32((A),(u32 *)&(B)))
  ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.
make[2]: *** [../../../../osx_clang/obj/x64/Release/3rdparty/sqlite3/sqlite3.o] 

MAME currently has two PCI systems: the older “legacy PCI” system and its successor. A number of drivers are still using the legacy system. This situation has persisted for over half a decade now, and really needs to be addressed. If we’re missing new-style PCI device implementations for any components, they need to be created, and drivers need to be migrated. There is to be no further development on legacy PCI devices – it’s wasted effort.

Drivers using legacy PCI include:

• src/mame/pc/at.cpp (ficpio2 VT82C496G, probably others)
• src/mame/pc/atpci.cpp (i430hx, SiS 85C501, i430tx)
• src/mame/be/bebox.cpp (mpc105)
• src/mame/pc/calchase.cpp (via vpx clone)
• src/mame/misc/comebaby.cpp (i440bx)
• src/mame/konami/cobra.cpp (mpc106)
• src/mame/pc/fruitpc.cpp (ST STPCD0166BTC3 SoC)
• src/mame/misc/funkball.cpp (Cyrix CX5520)
• src/mame/drivers/gamecstl.cpp moved to src/mame/pc/sis630.cpp
• src/mame/misc/gammagic.cpp (i430hx, one of the M55Hi-Plus BIOSes with El Torito BIOS)
• src/mame/misc/magictg.cpp (Galileo GT-64010A-B-0)
• src/mame/atari/mediagx.cpp (P5GX-LG MediaGX)
• src/mame/midway/midqslvr.cpp (i440bx)
• src/mame/sega/model3.cpp (mpc106)
• src/mame/pc/nforcepc.cpp
• src/mame/funworld/photoply.cpp (SiS85C496 + SiS85C497)
• src/mame/midway/pinball2k.cpp (MediaGX + CX5520)
• src/mame/pc/queen.cpp (VIA Apollo VXPro)
• src/mame/misc/savquest.cpp (i440bx)
• src/mame/taito/taitowlf.cpp (i82439TX + i82371AB)
• src/mame/konami/viper.cpp (mpc8240)
• src/mame/misc/voyager.cpp (VIA KT133a)
• src/mame/misc/xtom3d.cpp (i440zx)
• src/mame/konami/gticlub.cpp (k033906 PCI bridge)
• src/mame/konami/hornet.cpp (k033906 PCI bridge)
• src/mame/konami/nwk-tr.cpp (k033906 PCI bridge)
• get rid of bus/lpci

There are relatively few legacy PCI devices, mainly contained within the src/devices/bus/lpci directory.

Create XAudio2 sound interface support for windows osd

Almost every rom I get, It says I need CHD files or something. Please fix this and make more games compatible. Most arcade games like racing and fighting games are my preferences.

These macros would expose to the emulator runtime, useful information for the users. Such information can be displayed when booting a machine and/or within the ui menu (under "machine information" perhaps).
Examples of what the macros would look like in the source code:

DEVICE_DESCRIPTION( zapcomp, "\
    ZAP - Z80 Applications Processor\n
\n
    driver by: Felipe Correa da Silva Sanches <juca@members.fsf.org>\n
\n
    Based on the technical descriptions and\n
    assembly listings of the book:\n
\n
        'Build Your Own Z80 Microcomputer'\n
        by Steve Ciarcia (1981)\n
        published by BYTE/McGRAW-HILL" )

DEVICE_USAGE( zapcomp, "\
Basic usage instructions:\n
    SHIFT + 0: view and edit memory values\n
    SHIFT + 1: view and edit register values\n
    SHIFT + 2: execution mode\n
\n
    For more info, please check chapter 6 'Monitor software' in the book\n
    and/or the assembly listings of the ZAP monitor software\n
    avaliable at appendix D." )

Compared to the kind of great work going on in e.g. Dolphin, our DRCs are giving away significant performance, no matter how much better they are than interpreters. Also, they can't target ARM processors, where the speedup is currently needed most.

I've talked to both Aaron and OG about this, and there's general agreement that the best solution is to adapt the backend to output through LLVM, which has real optimization passes and targets a lot more CPUs than our current DRC backends.

Phase 1, replace current GLSL/HLSL with reasonable cross-platform common denominator.

• Must be data-driven and support multiple passes with multiple shaders
• Support both a built-in pipeline analagous to current HLSL system and a user-supplied pipeline with user-defined shaders

Phase 2, polygonal rasterization support:

1. Ability to render polygonal game screen to an off-screen buffer, then upscale the final image
2. Need ability to pass down triangle strips and fans from the driver
3. Driver should be able to supply a custom pixel shader to get arcade-correct results for more unusual h/w
4. Driver should be able to do some texture management; e.g. Namco S22 on modern video cards will want to upload the entire texture sheet once at the beginning for max performance

This will be involved with the "3D Artwork System" item as well.

Necessary for restoring sound in micro3d.c (http://mametesters.org/view.php?id=5495).

This would be more for Macs and PCs, since their optical drives have such button.

Boilerplate Introduction
At present, the code for handling vector (e.g. Asteroids, Tempest, Star Wars) games is lacking in a number of areas, both in terms of accuracy and in terms of tracking data that would be useful for reproducing the visual peculiarities of a vector display.

Issue Introduction
This particular issue proposes a solution for amending the lack of temporal data pertaining to vectors drawn with the src/emu/video/vector.* subsystem. Without this information about the times across which vector points are issued, certain data is lost that could be used to contribute to the accurate perceptual reproduction of vector monitor displays.

Background
It is well known that in an authentic vector monitor, vectors are drawn by sweeping the electron guns between two X,Y points on the screen. What is not as well-known is that vector monitors did not have a refresh rate, per se, and simply drew vectors in the order in which they were submitted by the underlying arcade hardware. Equally obscure is the fact that depending on the signals sent to the monitor, the electron guns' beams could be allowed to linger on a given point, increasing the intensity of the point by exciting the phosphors on the front of the CRT. It is also relevant to mention that the length of the vector drawn can have an effect on the perceived brightness of said vector, as a beam between two diagonally opposite points on the CRT will naturally be swept much faster, and thus have less time to energize the front phosphors, than a short vector, e.g. the ship in Asteroids, or an enemy shot in Star Wars. The fact that this data is not available in any way to the platform-agnostic (core) vector system in MAME means that there is no way to store this data per-vector, and by induction, that there is no way for a platform-specific front-end, perhaps with shader-based post-processing, to act on said data to enhance the perceived brightness of these vectors.

Solutions
The vector_device class is already an instance of device_t, meaning that it should already be possible for said device to log the time at which a vector point is queued via machine().time(). This function returns an attotime, which should be stored directly in the point structure defined in src/emu/video/vector.h. The simplicity of this is confounded by the fact that some vector devices in MAME are not currently time-sliced by the primary scheduler, but a solution for this issue will be proposed in a separate issue ID.

During vector_device::screen_update, the end and start attotimes of the two point instances that make up a specific vector should be subtracted from each other to calculate the overall time given to drawing said vector. This resulting value should be converted to a double containing milliseconds in the integer portion, and fractions of milliseconds in the fractional portion, should such data be relevant.

This, in turn, reveals a deficiency in the render_container class found in src/emu/render.*. A vector should certainly not be considered a simple line primitive, as it requires pertinent information - the time delta between the start and end points - that is not relevant to a simple line primitive. It is proposed that a related member function, add_vector, be added to the render_container class. Additionally, this new container item will need to be added to the enum found in src/emu/render.c which defines various CONTAINER_ITEM types, with a proposed name of CONTAINER_ITEM_VECTOR. Handling will need to be added for this type in render_target::add_container_primitives in the same source file.

Additionally, a new primitive flag type will need to be defined. We currently find PRIMFLAG_TYPE_LINE and PRIMFLAG_TYPE_QUAD in src/emu/render.h. As it is already assumed that two bits are used for the primitive type, a third type, PRIMFLAG_TYPE_VECTOR should be added. An initial implementation of this primitive type will require a minimal amount of changes to the OS-Dependent ("OSD") layer of code, as until the back-end code which enqueues the vectors is updated to operate synchronously with MAME's scheduler, said primitive type can be naïvely treated as a simple line due to the supplied time deltas not being meaningful until then.

Afterword
The implementation time of this particular task should be relatively low for anyone familiar with the architecture of MAME's code. For anyone not familiar with the architecture of MAME's code, this task should provide a way of gaining initial familiarity both the OSD side of the code and the core side of the code. In either case, once the fundamentals are understood, implementing this should be trivial.

It would be great to add remote debugging features to MAME.
Inner debugger is good, sure, but if you have ability to connect to emu from different machine using gdb protocol, you will be able to use debugger without any dependency from target machine.

Is it possible to implement?

Introduce LUA console in current debugger. with ability to load existing scripts and run commands one by one. Output to standard output should go into console in this case.

Nanosvg is probably what we need for a start. We need to decide whether we want to do complete rendering each frame or image caching and blitting.

zx8* is almost done.

Pack/unpk have the wrong byte order for the uncompressed word being read/written from/to memory.

The following code runs through on uae, but fails on Musashi

move.l  #testword3+2,a0
move.l  #testword4+1,a1 
move.w  #$0102,testword3       ; input test word
    pack    -(a0),-(a1),#$0000

cmp.b   #$12,testword4             ; musashi has stored $21, so this comparison fails
bne fail

move.l  #testword4+1,a0
move.l  #testword3+2,a1
unpk    -(a0),-(a1),#$0000

cmp #$0102,testword3                ; this word is correct again, so unpk "reverts" the error again
bne     fail

The pack/unpk versions operating on registers have been verified to be ok.

A real life test for this is the "LED display" in the Amiga AGA game "SlamTilt". The pinball led display is messed up if pack/unpk is broken.

Error C2065 'error_use_auto_alloc_clear_or_global_alloc_clear_instead': undeclared identifier dasm C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xlocale 755

It happens because of this:
//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//
// Debug Heap Routines
//
//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ifndef _DEBUG

#define _calloc_dbg(c, s, t, f, l)      calloc(c, s)

0156 version 120hz with Vsync is 1x speed
nowday's versions are 2x speed
I want 120hz with Vsync is 1x speed

(edit by @balr0g: unfortunately the deletion of the intermediate comments removes all context from this issue)

Hi,

There is something strange with the clock setting into the 6809 emulation :

The MC6809 chip have an on chip oscillator to generate the E & Q clocks. E & Q frequency = Crystal Freq / 4 (Into the MC6809 / EF6809 datasheet : " On-chip Oscillator (Crystal Frequency = 4 * E) "

The MC6809E doesn't have this on-chip oscillator and the E & Q clocks need to be provided from an external circuit. There is no internal clock divider in this case.

The problem is that the clock divider is set to 4 for the MC6809E and to 1 for the MC6809 into m6809.cpp (see the m6809_device and m6809e_device constructors). For me the MC6809 divider should be set to 4 and the MC6809E divider to 1.

To have the correct software speed execution into the Squale driver, i have to choose the MC6809E CPU. But the Squale use a 6809 CPU with an internal oscillator (EF6809P). The 3.5Mhz clock input was checked on the pcb.

What do you think about this ? Am i missing something ?

Best Regards,
Jean-François DEL NERO

The current CGA bus emulation is a hacky driver from the days of legacy MESS, with improper coding (For example, CGA chipsets are controlled via options, when they should be seperate cards or internal non-changeable hardcoded chips), etc.

(Note: Should the video code be split from the bus driver aswell?)

The composite decoder in isa_cga also needs a complete refactor as well due to problems (colors are completely wrong and colorburst nor text artifacting is emulated right), and better decoder solutions, documentation, including schematics out there.

According to http://mametesters.org/view.php?id=4667,
the PSX GPU dithers graphics, but MAME doesn't.

The instruction
bfset mem{1:32}

writes 32 bits 0x7fffffff and then 8 bits of a fifth byte with 0xff while it should be writing 0x80 (only the last missing bit from the first 32 bit write).

The problem is the fact that the offset isn't take into account at all at several places in m68k_in.c:

    mask_base = MASK_OUT_ABOVE_32(0xffffffff << (32 - width));
  ...
    if((width + offset) > 32)
    {
        mask_byte = MASK_OUT_ABOVE_8(mask_base);
   ...
        m68ki_write_8((mc68kcpu), ea+4, data_byte | mask_byte);
    }

The mask_byte imho needs to be generated like this:

mask_byte = MASK_OUT_ABOVE_8(mask_base) << (8-offset);

This fix is not tested as i am actually not working on Musashi but instead tried to use Musashi to verify another core.

psikyosh.cpp games are crashing when you exit MAME.

Some artwork is most effectively displayed as 3d geometry, sometimes using mirrors to create pepper's ghost effects, etc.

It is cumbersome to toggle on/off the sound of individual audio channels in the slider controls menu by adjusting the values from/to 0.00/1.00

It would be very handy to have a shortcut key to simply mute/unmute the currently selected channel.

For some odd reason, almost every game I play, it does not work. Why is This so?

In process.

The idea is to have a tree of templatized classes. New capabilities expected:

• "Interception" classes that do stuff like bus contention, delays, etc.
• Classes that do watchpoints available fromboth the debugger and the driver.
• Efficient caches/software tlbs
• Views, aka bankdev without the device

Create ability in core to start LUA scripts using internal menu in case there are scripts assigned to all machines (GLOBAL), machine type or specific machine.

Plugins would be stored inside addons/plugins/ there is need for addon.xml that will define visibility of plugin and some brief description, and also name of startup LUA script.

inside addons/scripts/ there will be LUA libraries that can be used by any other plugin or script, note that in addon.xml there will be need to define dependencies.

Currently the debugger memory window lets you view data as 1 2 4 and 8 byte chunks.

Since some of the processors that are emulated in mame support floating point operations natively, it would be useful to show memory contents as floating point values.

A first implementation could show only values in the ieee754 32bit format, but then it colud be expanded with other formats.