summaryrefslogtreecommitdiffstatshomepage
path: root/src/devices/cpu/m6502/m6502d.cpp
Commit message (Collapse)AuthorAgeFilesLines
* m740: Fix calculation of destination address for disassembly of BBC/BBS n, ↵ AJR2021-02-161-1/+1
| | | | A, rel
* r65c19: (IND), X rather than (IND, X); give L2800 more internal RAM (nw) AJR2019-12-021-0/+5
|
* New machines marked as NOT_WORKING AJR2019-11-251-0/+15
| | | | | | | ---------------------------------- Speedcom VD56SP [ClawGrip] Add disassembler and basic execution core for Rockwell R65C19 [AJR]
* Amiga keyboard overhaul: Vas Crabb2018-08-231-1/+1
| | | | | | | | | | | | | * Implement Mitsumi Amiga 500, 600, and 2000/3000/4000/CDTV keyboards * Add unlabeled keys to UK layout * Restrict available keyboards depending on system type * Note that C-A-A reset is now broken on "big box" Amigas as MAME doesn't implement it properly, and the hack providing a fake dedicated reset line has been removed 6502 MCU: fix execute loop 6500/1: implement as device with onboard peripherals Fix some bogus comments
* create derived 6502 type for XaviX because it has at least one custom… (#3154) David Haywood2018-02-021-0/+5
| | | | | | | | | | | | | | | | | | | | | * 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)
* fix building with Visual Studio 2017 & clang 5.0.0 (also tested with gcc ↵ smf-2017-11-281-0/+1
| | | | 7.2.0) (nw)
* dvdisasm: Overhaul [O. Galibert] Olivier Galibert2017-11-261-0/+192
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.