- Restore some 8052 SFR and bit names that were inadvertently omitted for more advanced models
- Add a few more T2-related names
- Add i8xc51fx and i8xc51gb disassemblers with additional SFR and bit names
- Remove i80c51 from unidasm (actual differences from i8051 are not significant)
Change device names from "Intel I8xxx" to "Intel 8xxx" (nw)
scm_500: Identify CPU type as 80C51GB (specific differences obviously not emulated) (nw)
unidasm: Realphabetize mips1 (nw)
This effectively reverts b380514764 and
c24473ddff, restoring the state at
598cd52272.
Before pushing, please check that what you're about to push is sane.
Check your local commit log and ensure there isn't anything out-of-place
before pushing to mainline. When things like this happen, it wastes
everyone's time. I really don't need this in a week when real work™ is
busting my balls and I'm behind where I want to be with preparing for
MAME release.
* hphybrid: major overhaul to add the 09825-67907 variant
* hphybrid: adapted hp64k & hp9845 to revised hphybrid CPUs
* hp9825: first release of HP9825B emulator
* hphybrid: added 09825-67907 to unidasm
* hp9825: improved appearance of blinking cursor
* hphybrid: minor changes
* 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)
* 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
* 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)
- Separate disassembler for i802x (including unemulated 8022 instructions)
- Provide separate (though mostly just more limited) 8021 opcode table
- Writes to 8021 P0 no longer go through memory space
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
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.
What works:
* HP85A machine with 16K of RAM
* Capricorn CPU works
* Keyboard works (with minor issues)
* CRT text / graphics modes work (correct speed is not emulated yet so service ROM complaints)
* BASIC is usable
What is missing (and I'll have hopefully working soon):
* HW timers
* Beeper
* Integral printer
* DC100 cassette drive
* Extension ROMs
* I/O modules (especially the HPIB interface so that we can hook up floppy drives)
* Other models in the family (e.g. HP86)
