* softfloat3: fix msvc build (nw)
Is this how we do these things? I assume we don't touch the library code itself, and have to "fix" any problems via this header instead?
* softfloat3: do we like this better? (nw)
* softfloat3: it gets the hose again (nw)
* softfloat3: sonofa (nw)
This is a pre-usage import so everyone can get things in line for various compilers. GCC/Clang should be OK on most targets as-is;
MSVC may need to edit 3rdparty/softfloat3/build/MAME/build.h to conform. Please report failure/success with various compilers.
* add topcat template
HP topcat was an ASIC used on HP900/300 graphics cards.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
* hook up topcat asic to HP98544
Signed-off-by: Sven Schnelle <svens@stackframe.org>
* topcat: add basic configuration macros for fb planes, height and width
Signed-off-by: Sven Schnelle <svens@stackframe.org>
* hp98544: move logic to topcat video driver
Preparation to support multi plane graphic cards
like the HP98543/98545/98547.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
* xtal: add 35.904MHz XTAL
* interpro: slotify mouse (nw)
Needed to make the mouse a slot device to enable it to be connected to graphics boards under development.
* add validity check (nw)
* bt45x: new devices
Basic implementation of various Brooktree RAMDAC devices. Two of these (bt457, bt458) are used by InterPro graphics boards currently under development, the others are unused/untested at this point.
* bt45x: tweak descriptions (nw)
* start looking at the extra opcodes in the SSD 2000 type XaviX chip (seems some undocumented 6502 opcodes are replaced with more custom ones)
* (nw)
* the xavix memory mapping gets stranger with each piece of new evidence (nw)
- Use device_resolve_objects to resolve callbacks in output_latch_device (nw)
Note that this renaming is not just for human convenience; genie seems to get confused by modifications to a header called latch.h and decides to recompile everything involving gen_latch.h as well.
The 98603A and 98603B cards have different base addresses and sizes
for the rom region. Split up the cards so that we can boot HP BASIC 4
and HP BASIC 5.1.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
* Move around the debugger hooks to get a small but measurable performance increase
* Remove emucore from external tools
* Improve performance of DSP16 interpreter a little by generating six variants of execution loop
* remote488: work started
* remote488: fixed a crash when using socketed bitbangers on Linux machines
* remote488: added ieee-488 remotizer device
* remote488: added remotizer devices to ieee-488 buses of HP9845 & HP85
* remote488: added missing emu.h inclusion
* Revert "remote488: fixed a crash when using socketed bitbangers on Linux machines"
This reverts commit edfeb1768ec332ccdb77584e272d93b756819c41.
* remote488: nudge..
* remote488: no longer use locale-dependent functions, added commas and
semicolons as msg separators, improved use of util::string_format
* Fixed building using system utf8proc
* Fixed building using system portaudio
* Allow using system-wide asio headers (1.11.0 or higher required).
* Allow using system-wide glm headers
* Allow using system-wide rapidjson headers
* create derived 6502 type for XaviX because it has at least one custom 4-byte opcode that doesn't fit any other type.
treating that opcode as NOP for now.
have a feeling it might be something to do with the other integrated hardware, might be 'execute co-processor code chain at this address' or something similar
It isn't a standard JSL (Jump Subroutine Long) like the SNES cpu opcode in the same place as this, it seems to point at some code-like structures tho)
could also be a secondary operation mode with different encoding like ARM's Thumb mode tho I guess.
We currently only have a single XaviX based dump (taitons1) but there are more on the way. I'm going to see if the code flow makes any sense at all with these missing, or if any of it gives a clue as to what they should actually do.
* xavix - let's call these callf and retf then
after further investigation these are some kind of extra 'long jump' subroutine / task handlers, the 0x80 also being a custom opcode was throwing me off trying to identify them before.
looks like they might have been hacking 65816 features into the regular 6502 core?
* prepare for extra address bits (nw)
* better program flow (nw)
- P.R.E.S. Advanced Plus 3/4
- Advanced Quarter Meg Ram
- Cumana Floppy Disk System
- Sound Expansion
- Sound Expansion v3
- Stop Press 64
- Solidisk EFS
New working software list additions
-----------------------------------
electron_cart: Solidisk EFS 2.1E
New NOT_WORKING software list additions
---------------------------------------
electron_cart: Stop Press 64
Software list items promoted to working
---------------------------------------
electron_cart: Advanced Plus 3, Advanced Quarter Meg RAM, Slogger Electron Disk System, Sound Expansion v3
* fix/tidy tvboy driver (nw)
* missed file (nw)
* framework for adding 'gamebooster' (need to figure out how it actually works / maps tho) (nw)
(code based on zx spectrum expansion port code)
* (nw)
* lost a line (nw)
* allow it to run (nw)
* continued work (nw)
* mame64 psj -parallel gamebooster -cart tetris now works
* rm outdated (nw)
* remove unneeded code (nw)
* limit accesses, log unexpected ones, might have custom banking (nw)
* write bytes in an order that keeps the gb code happier , sml boots (nw)
Revert "Removal of voltage_regulator_device (nw)"
This reverts commit 1af133752a.
Revert "New way to provide DAC reference inputs (nw)"
This reverts commit 1c6a7ab40c.
please people, remember to keep source UTF-8 and if you're committing on behalf of others, clean up indents to meet MAME conventions
anyone can run srcclean over a submission and see what will get hit
An implementation of the National Semiconductor DP8510 BITBLT Processing Unit. This is used on the InterPro GT family graphics boards, and this implementation seems to be correct enough to enable me to progress there, hence the PR. While I'd love to have another system to test against, I'm not aware of any other systems that ever used this device other than some NatSemi reference designs, which are not (yet) in MAME.
Disassemblers are now independant classes. Not only the code is
cleaner, but unidasm has access to all the cpu cores again. The
interface to the disassembly method has changed from byte buffers to
objects that give a result to read methods. This also adds support
for lfsr and/or paged PCs.
