* Added new driver: HP 3478A Multimeter
WIP, machine not working, skeleton, highly incomplete. Compiles, that's
about all.
* hp3478a: implement ROM banking
code runs "properly" at least to the CAL RAM check (fails, RAM not
implemented)
* hp3478a: some IO work
Interpret CS lines for external accesses (GPIB, CAL RAM, DIP switches).
Also, remove MCFG_ stuff
Also, use logmacro.h stuff
* hp3478a: partial emulation of LCD
The main CPU has a serial link to the LCD module. This WIP splits
commands and data mostly successfully (still some bogus shifting which
would be fairly easy to ignore). None of the commands are implemented
yet, and no actual display is generated yet.
Includes unrelated tweak : only change bank when the A12 line changes.
* hp3478a: added LCD rendering !
code shamelessly stolen from tranz330 and roc10937 drivers.
Not clickable yet.
* hp3478a: implement CAL NVRAM
Finally. IO mapping has provisions for the DIP switches as well as i8291
GPIB interface registers.
* hp3478a: improve LCD rendering
Remove some artifacts: with the LCD "not selected", some data is sent on IWA (probably
to purge a shift register ?) but was parsed with the last m_lcdiwa
state. Reset this everytime PWO is deselected.
Also parse decimal point, comma and "all segments".
* hp3478a: implement keypad
* hp3478a: CAL switch to write-protect NVRAM
* hp3478a: implement DIP switches
* hp3478a: fix self-test reset freeze (missing WDT)
There is an external WDT counter that is periodically reset by the CPU
in normal operation. When forcing a reset from the front panel, this
counter is allowed to overflow (20th bit, clocked at Xtal / 15), giving
a reset time of about 1.3s.
At least on my build, MAME thinks maps are being configured for nonexistent AS_DATA spaces when they clearly aren't. This may be due to some subtle bug with device delegates.
This reverts commit aa0d17757d9e5857bb99887841133045cc530655.
* MU100 isn't really working
* clone relationship is for different versions of the same thing, not different parts of a system
* indentation should follow structure
Used in the high end HP9000/300 machines. Provides a resolution
of 1280x1024 @ 8bpp. It also provides two overlay planes and one
phantom plane. Each plane contains two window movers that are used
for copying characters and tiles on the screen. It also has a RUG
for line/vector drawing. The current state implements everything
that is required to have a working HP Visual user environment in
MAME.
Working:
- window mover
- pixel replacement rules
- window replacement rules
- f0 tripple replacement rule (copy src or keep destination depending on pattern register)
- VRAM bit access mode
- solid line drawing
Not implemented yet:
- drawing circles
- linetype vector/circles
- rectangles
- filling areas
- tripple replacement rules other than f0
This is useful for catching putchar() like functions and printing
the written value to error.log.
On hp9k_3xx, i'm using this with the HP 300 test software, to log
test error messages that get printed on screen to error.log, so i
have the message directly after the debug messages from my driver.
Example:
wpset 0xfffe36be,80,w,1,{ logerror "%c", wpdata; g }
gp 'go privilege' starts execution until the privilege mode
changes. This can be used to break on task switches. I.e on m68k,
one could do:
gp { ~sr & 0x2000 && crp_aptr == 0x1234567 }
which would execute until the privilege mode changes to user mode and
the CPU root pointer is 0x1234567.
for cpu code, all that is needed to make this work is calling
debugger_privilege_hook() when the execution level changes.
NOTE1: namcos22 propcycl always pedals backwards now, will resolve in next commit.
NOTE2: diexec.h MAX_INPUT_LINES had to be increased, even without this commit m37710 was already more than 32 input lines.
* namco checkpoint (including cam900 submission)
* move code into device (nw)
* start splitting DSP support code into devices (nw)
* fix crash (nw)
* prepare for further splitting (nw)
* move code for C67 based DSP PCB into it's own device (nw)
* survive F3 resets without crashing or breaking the 3D (nw)
* less magic numbers (nw)
* optional -> required
don't use fake bootstrap on older type, suspend CPU instead
* restore CPU yield hack for solvalou (nw)
* (nw)
* give galaxian3 some DSPs (nw)
* address hap's concern with a different workaround since MAME is awkward (nw)
* split namco21 driver into 3 drivers as the different configurations really are entirely different boardsets with similar components, not a real 'system'
emulated entire PCB set for driveyes ( http://www.tvspels-nostalgi.com/Bilder/PCB/Namco/driverseye_cage_inside.jpg ) although how the PCBs communicate is not yet known (C139 maybe, which might also be an MCU)
* remove empty file (nw)
* actually thinking about it, this is cleaner (nw)
* mark cybsledj as World instead, there's nothing about this set other than the CY1 code to indicate that it's a Japanese set, and I don't think the Namco codes represent region, just release order.
* newline (nw)
* newline (nw)
- Derive clocks from actual XTALs
- Raw screen parameters
- Character width is 9, not 8
- Separate configurations (different enough now)
- Remove MCFG configuration macros
- Add and map various devices, particularly for esprit3
- Note undumped (though probably unused) R6531 mask ROM
* Separate Microsoft 2-button mouse and Logitech 3-button Microsoft-compatible mouse
* Add Microsoft wheel mouse
* Make Mouse Systems mouse behave more realistically
* Add Mouse Systems "rotatable" mouse
* Simplify code and eliminate timers
(nw) X/Y translation and buttons works for all devices. The wheel on
the wheel mouse seems to be transmitting the right data, and CuteMouse
detects the wheel as being present, but no software seems to support it
properly. Software supporting the Mouse Systems "rotatable" mouse is
very rare - typically people just set the DIP switches on their M-1 for
"non-rotatable" mode. A standard mouse driver will see the "rotatable"
mouse moving two mickeys for each count, and move eratically on
rotation. The "rotable" mouse is poorly tested due to lack of software.
(nw) MAME doesn't have a proper input type for a mouse wheel, and it
doesn't seem to be possible to map the host mouse wheel to an axis when
configuring inputs. The default mapping ends up assigining the wheel or
rotation to one of the translation axes, which is very unhelpful.
* interpro: notworking -> networking
These changes combine to make InterPro networking work on Windows with the TAP-Windows6 driver.
* osdnet: add a receive delay (1 frame) after transmit to avoid a time-travel problem
* taptun: pad short Ethernet frames and append FCS (Windows-only until Linux taptun behaviour is verified)
* clipper: fix bugs in carry flag handling, prefer sign bit for tests
* i82586: fix transmit bug, handle reset
* networking: delayed transmit/receive
A second attempt to fix networking on InterPro systems, by introducing somewhat realistic delays into network transmit and receive paths. This version works by adding functions to device_network_interface which enable a device to be informed when the transmit or receive completes. The delay is only crudely approximated based on the specified bandwidth and the number of bytes being transmitted, but it should be good enough in practice. Existing drivers should not be impacted by these changes; overriding the new functions (and no longer overriding recv_cb) is necessary to obtain the new behaviour.
Changes from the previous commit:
* i82586: improve interrupt handling, implement delayed transmit/receive behaviour
* dinetwork: add transmit/receive delay timers, handlers and logic
* osdnet: remove receive delay, add the ability to start the receive timer
Associated core changes (nw)
- Move definition of address_space_config from dimemory.cpp to emumem.cpp (declaration was already in emumem.h)
- Add getters for more members of address_space_config with future privatization in mind (nw)
- Allow device finder to be used as an argument for set_screen (nw)
screen: Calculate physical aspect ratio whenever required, not in device_config_complete, since the renderer caches the result anyway (nw)
cdp1861, cdp1864: Eliminate the "magic reference" constructors, doing their work in device_config_complete instead (nw)
A standard memory handler has as a prototype (where uX = u8, u16, u32 or u64):
uX device::read(address_space &space, offs_t offset, uX mem_mask);
void device::write(address_space &space, offs_t offset, uX data, uX mem_mask);
We now allow simplified versions which are:
uX device::read(offs_t offset, uX mem_mask);
void device::write(offs_t offset, uX data, uX mem_mask);
uX device::read(offs_t offset);
void device::write(offs_t offset, uX data);
uX device::read();
void device::write(uX data);
Use them at will. Also consider
(DECLARE_)(READ|WRITE)(8|16|32|64)_MEMBER on the way out, use the
explicit prototypes.
Same for lambdas in the memory map, the parameters are now optional
following the same combinations.
* Allow <orientation> and <color> to work on group references
* Fix some corner cases where group bounds could be miscalculated
* Fix a corner case where MAME could incorrectly refuse to instantiate groups
* Add more checks to complay.py
* Document more of the layout format
I'm not sure this API is a great idea - see inline comment on 796abaf7f3
I realise it seems intuitive, but it breaks with a use-after-free (not even a
validity error) if you replace/remove the target device. Implementing it in a
way that isn't fragile and doesn't hurt the performance of -romident,
-validate and -listxml seems impossible. If it causes developer confusing and
things start breaking, back to literal tags we go for this case.
* Clean up some corner cases in layouts with repeating blocks
* Make complay.py validate many more elements and attributes
* Make complay.py easier to use for just validating a layout
* Remove redundant view from Sega VMU layout
* Make buttons visually respond to input in whousetc.lay
* Add view with LED displays as well as terminal for aim65_40 and use repeats
* Clean up some outdated "game" terminology in clifront.cpp
* Initiaise a couple of members in tap/tun network module
* Start documenting layout format
This is damn sensitive code, and generates differences all over the
place we don't really explain. The changes should be justified by
themselves and tested in collaboration with Tafoid to ensure the
differences are not a problem.
* Eliminates the need for the horizontal/vertical/LCD/SVG layout files
* Screens can now have orientation and physical aspect ratio specified
* RASTER/VECTOR defaults to 4:3, LCD/SVG defaults to square pixels at config time
* System orientation is applied on top of screen orientation
Automatically generated single-screen views and orientation flags in XML
output now work correctly for systems with multiple screens in different
geometries/orientations, e.g. housemnq, rocnms, stepstag, or netmerc.
The "core rotation options" only interact with system orientation.
Allowing multi-screen systems to work well with one monitor per emulated
screen is a complex topic. System orientation also affects the GFX
viewer while screen orientation doesn't. The orientation displayed in
the system selection menu is from the system orientation.
Let me know if I've broken any systems or use cases.
Also, add save state support for std::array/C array nested to any depth.
Together, these changes enable softlist CD-ROM media changes for InterPro, and presumably other nscsi_cd systems. Haven't looked into how other CD-ROM devices work, but the romload fix should apply equally to them too.
* nscsi_cd: detect and respond to media changes
* romload: fix disk entry processing
* Make more #include guards follow standard format - using MAME_ as the prefix makes it easy to see which ones come from our code in a preprocessor dump, and having both src/devices/machine/foo.h and src/mame/machine/foo.h causes issues anyway
* Get #include "emu.h" out of headers - it should only be the first thing in a complilation unit or we get differences in behaviour with PCH on/off
* Add out-of-line destructors to some devices - it forces the compiler to instantiate the vtable in a certain location and avoids some non-deterministic compiler behaviours
Input and screen tags are now resolved relative to a layout's owner
device.
Easy way to demonstrate is with: mame64 intlc440 -tty ie15
Previously you'd only get the IE15 terminal's layout and you'd be unable
to use the INTELLEC 4/40 front panel. Now you'll get the choice of
layouts from both the system and the terminal device in video options.
