* Sync with bgfx upstream revision b91d0b6
* Sync with bx upstream revision d60912b
* Sync with bimg upstream revision bd81f60
* Add astc-codec decoder
* Rename VertexDecl to VertexLayout
* Rename UniformType enum Int1 to Sampler.
* Add NVN stub
* Fix unused-const-variable error on macOS
* Drop redundant explicit language parameters
buildoptions_cpp are only applied to c++ files and buildoptions_objcpp are only
applied to objective c++ files. As such, hardcoding -x offers no benefit while
preventing overrides (such as one needed by 3rdparty/bgfx/src/renderer_vk.cpp on
macOS) from working.
* Re-introduce -x c++ in places where C code is compiled as C++ to prevent clang from throwing a warning
* Build bgfx as Objective-C++ on macOS
It is needed due to included headers
* Enable Direct3D12 and Vulkan bgfx rendering backends
* Enable building of spirv shaders
* Properly escape /c in cmd call
* Comment out dx12 bgfx renderer
* Honor VERBOSE setting during shaders build
* Only invert hlsl shader XYZ_TO_sRGB matrix for opengl
* Add spirv shaders
* OpenGL ES needs transposed matrix too
* Metal needs transposed matrix as well
* screen: validate crystal values used for set_raw
* driver: get rid of sound start/reset overrides in machine configuration
* vrender0.cpp, nexus3d.cpp: corrected pixel clock crystal value
* mw8080bw.cpp: turned several audio subsystems into devices
* bus/sat_ctrl: don't start subdevices in device_start - the machine does it for you
* mb14241.cpp: simplify handlers
* fgoal.cpp: updated for simplified handlers
* devfind, screen: repair some doxy comments that had rotted with refactoring
* doxygen: disable warnings for undocumented things - it's most of our codebase
* snowbros.cpp: restore an output level setting lost in MCFG removal
There's an outstanding validation error from the HP98543 DIO video card
not using a valid crystal value. Someone needs to find a picture of the
card and confirm or deny the existence of the 39.504MHz crystal.
The various start/reset overrides are bugs waiting to happen. It's not
immediately obvious that the ones run earlier can end up being called
multiple times if subsequent ones throw missing dependencies exceptions.
They're a relic of when everything from the old C-style drivers was
thrown into classes all jumbled together.
* Re-write makedep.py for better performance and better parsing front-end
* Make srcclean deal with kinds of preprocessor abuse I never want to see in real life
(nw) The new parser front-end is better at recognising C++ syntax and
also substantially faster - bootstrapping a single-driver build should
be noticeably quicker. Having a single parser for C++, .lst and .flt
files also gets us a bit closer to making it simpler to create custom
subtargets.
* subhuntr.cpp: S2636 PVI was seemingly uncommented by mistake in 93308b483e - offsets and sound routing seem to be copy/pasted from somewhere
* phi: prettier config
* scramble.cpp, wallc.cpp: avoid some calls to subdevice<...>(...)
* makedep.py: open source files as UTF-8 (GitHub #5482)
* minimaws: be less trusting
(nw) This has been a long time coming but it's here at last. It should
be easier now that logerror, popmessage and osd_printf_* behave like
string_format and stream_format. Remember the differences from printf:
* Any object with a stream out operator works with %s
* %d, %i, %o, %x, %X, etc. work out the size by magic
* No sign extending promotion to int for short/char
* No widening/narrowing conversions for characters/strings
* Same rules on all platforms, insulated from C runtime library
* No format warnings from compiler
* Assert in debug builds if number of arguments doesn't match format
(nw) Also removed a pile of redundant c_str and string_format, and some
workarounds for not being able to portably format 64-bit integers or
long long.
Motorola MC6802 evaluation kit. This emulator implements the Keypad and the
LED display, and the MEK68R2 CRT and parallel keyboard interface with support
from the D3BUG2 ROM, and the RS232 terminal support using the MEK68IO and with
support for this also included in the D3BUG2 ROM. Much of the monitor commands
appear to operate properly.
* MEK6809D4: new machine
Motorola MC6809 evaluation board. This emulation implements the keypad and LED
7 segment display, the RS-232 terminal interface, and the MEK68R2 MC6845 CRT
and parallel keyboard interface. The RAM and ROM banking is not yet
implemented but most of the D4BUG monitor commands are supported.
* MEK6802D5: new machine
Motorola MC6802 trainer board. This emulation implements the keypad
and LED 7 segment display, and the RS-232 terminal interface even
though there is no monitor support for it. All the D5BUG monitor
commands appear to be working.
This will compile, link, and run a driver all the way to the first info screen, provided you use -video bgfx.
However, although there's a valid NSWindow created, it never actually appears on screen for unknown (but likely silly) reasons.
Inputs are not implemented and fullscreen exists but is untried.
* hp9825: fixed a bug in 9825t
* hp9845: TACO driver re-written from scratch, DC100 tape separated into
a new device, various adaptations
* hp9845: "new TACO" renamed to just "TACO"
* Made some experimental work with menghong based HW, allowing crzyddz2 to boot and improving menghong colors;
* Internalize video and audio components inside the SoC;
* Wrote a preliminary UART subdevice;
* Made external video clock to be settable by the host driver;
* spectrum bus : rename beta.cpp to beta128.cpp as the original beta is somewhat different (nw)
* (nw)
* start making a device for the actual original beta disk interfaces (nw)
* flesh out beta stuff a bit (nw)
It appears that it is sufficient to include `-s USE_SDL_TTF=2`, and
emcc links in the SDL2_tff library, and it does not like attempts to
link this twice.
The current Emscripten release is not happy with the use of
"-s ERROR_ON_MISSING_LIBRARIES=0" as a link option, it gives an error
stating that all libraries must now be present, so remove that use.
This leaves a missing 'util' library. This did not appear to be
needed on the few builds I have tried, and this patch avoids adding
this library for asmjs.
* Improved encapsulation between video and machine SoC periperals;
* Split up HWs in individual files where they don't belong to Crystal System HW, makes future development easier;
* Untangled reads/writes to draw/display bankswitches from screen_update, now they can be unthrottled safely;
* Added CRTC screen raw parameters;
* Add DMA hold feature and clear irq on mask writes, specific for P's Attack;
* Improved Cross Puzzle flash loading, currently failing at POST for a SPU error;
nexus3d.cpp: add some preliminary work, currently does some VRender3d pipeline fill with a debug trick [Angelo Salese]
(out of whatsnew)
Some stuff definitely needs fine graining, like removing the few lines that are still necessary to configure the VRender0 from driver files, which I'm gonna do in my next feature branch.
Split out the floppy disk controller from the swtpc09 machine, adding it to
the ss50 interface. The DC5 is compatible with both the SWTPC 6800 and 6809
systems, supporting the 4 and 16 byte I/O interfaces respectively, via a
jumper setting, so can be used on the MAME swtpc and swtpc09 machines. The
DC5, like the DC4, supports double sided and density disks, and claimed
backward compatibility with the DC1, DC2 and DC3.
Split out the PIA IDE hard disk interface from the swtpc09 machine. This
support appears to have been incomplete or to have bit rotten, and has been
updated and tested lightly with FLEX9.
Credits: ClawGrip, Roberto Fresca, Recreativas.org,
Dumping Union, System11, Dirk Best
This is based on an MCS-51 core, like the MK3 bootleg. They are
clearly based on the same code, so the MK3 bootleg was moved to
this driver.
* Enable precompiled header usage in the Visual Studio compiler
But only for libraries emu frontend precompile dasm optional
Also add emu.h include to hpcdasm.cpp
* Include emu.h in some disassembler sources to use precompiled headers
* Remove debug message
The UniFLEX disk format is not compatible with the Flex format. Significantly it
does not use a mix of single density for booting on some double density disks
which makes it simpler - hardware required a new boot ROM to run UniFLEX.
Further, the UniFLEX sector size is 512 bytes versus 256 for Flex, and the
UniFLEX 'SIR' info sector record is completely different to the info on Flex
disk, and the file system format is also not at all compatible.
Thus the UniFlex format can rely largely on the WD17xx format, with an
overload to handle the sector numbering on the second side continuing from the
first side (one feature in common with the Flex format). This gives a quick
'save' capability and shares code.
Support for 8" disks is included as this was the initial distribution format
and the only one found so far.
* gdbstub: added new GDB stub debugger
This debugger can be used to connect to an external debugger that
communicates using the GDB Remote Serial Protocol, such as GDB itself
or many other GDB frontends.
Currently i386 (ct486), arm7 (gba), and ppc (pmac6100) are supported.
* gdbstub: enable GDB stub debugger in mac and windows builds
--------------
Mephisto [hap, Berger]
Mephisto II [hap, Berger]
Mephisto III [hap, Berger]
New working clone added
---------------
Mephisto Amsterdam (older) [Berger]
Mephisto London 16 Bit [Berger]
- Clean up notes, add TODO
- Use pulse_input_line for NMI
- Document coin lockout
- Document attribute RAM layout
- Background layer color is actually 3 bits
--------------------
Hektor III [Nigel Barnes, jltursan]
New machines marked as NOT_WORKING
----------------------------------
Hektor II [Nigel Barnes]
- Replace additional driver RAM with S-100 bus
- Convert Video Terminal Interface into a S-100 bus device
- Add skeleton S-100 bus device for SSSD disk controller
* There is no longer a concept of "layers" - there are only screens and elements.
* Elements are now instantiated with <element ref="...">
* Screens and elements can have explicit blending mode specified with blend="..."
* Default blending mode for screens is "add" and default for other elements is "alpha"
* Other supported modes are "none" and "multiply"
* This removes the options to enable/disable layers individually - use views instead
* Legacy layouts can still be loaded, and support won't be removed for at least a year
The current artwork model is over-stretched. It's based on a Space
Invaders cabinet model, and isn't applicable to a lot of the systems
MAME emulates now. The fact that MAME has to switch to an "alternate"
mode to deal with games like Golly! Ghost! without requiring pre-matted
bitmaps shows that the Space Invaders model wasn't even adequate for
general arcade use. It shows in that for a lot of the systems that
heavily depend on artwork, people just seem to randomly choose layers
for elements until they get something that works. Also, the fact that
MAME will switch to an alternate (Golly! Ghost!) mode depending on the
combination of elements is a trap for people learning to make artwork.
There are cases that the current approach of implying the blending mode
from the layer doesn't work with. Examples include LEDs behind
diffusers (requires additive blending for layout elements), and mutliple
stacked LCD panels (requires RGB multiplication for screens).
For configurability, it's now a lot easier to make multiple views using
groups. For example, if you want to make it possible to hide the
control panel section of your layout, you can put the control panel
elements in a group and create views with and without it.
I will gradually migrate the internal artwork to use the new approach.
I have an XSLT stylesheet that helps with this, but I'm not comfortable
adding it because it isn't a complete solution and it still requires
manul steps.
I wanted to get the re-worked pointer handling done sooner so I could
push them both at the same time, but unfortunately various things have
prevented me from progressing as quickly as I wanted to. Sorry guys,
that stuff's going to have to wait.
* move princ out of prestige.cpp (it should have never been put there) and into a new driver
fix graphic alignment on the salter gym machines, also promote htem both to working (the hang I saw before on cycle doesn't seem to happen now)
made a note in redclash.cpp about possible sets needing rearrangement
note, princ uses a F2MC-16L based CPU, I don't believe we have a core, but there are plenty of docs available should somebody want to write a disassembler at least.
* reparent the RedClash sets, it appears to be a Kaneko game (Cat logo in the corner etc.)
* change guess (nw)
--
Big Karnak (Modular System) [Recreativas.org, ArcadeHacker, ClawGrip, David Haywood]
as with other Modular System things, it's not really very close to original hw at all (and uses different boards in a different configuration to other modular system setups) so new driver
* rad_hnt3 misc improvements (nw)
* better support for alt modes used in rad_hnt3 and rad_foot
* tidy/comments (nw)
* test note (nw)
* actually not a special case (nw)
* document other test modes (nw)
* palette selection improvements (nw)
* switch according to test mode (nw)
* improved palette handling for rad_foot (7bpp mode)
* ramsize (nw)
* exploring the ram based layer (nw)
* ram tile layer in hnt3 is 2bpp, hardcode stuff for now until we've found the proper register bits
* slight refactor (nw)
* some palette fixes (nw)
* fix 2bpp tile colours (nw)
* rename rad_eu to elan_eu
* rework tile pri (nw)
* refactor (nw)
* note updates (nw)
* kludge (nw)
* some weird regs notes (nw)
* new NOT WORKING clones
---
Gals Panic (Modular System bootleg) [Juan Romero, Recreativas.org, ClawGrip, David Haywood]
these things are *ugly* from a hardware perspective (massive 6 board stack just for Gals Panic with many, many code hacks to work around hardware changes) so I felt it best to create a new driver with the background bits copy+pasted; the sprites + sound system specific to these bootlegs will need adding.
* bleah (nw)
