- Reworked PMMU/core interface so PMMU now sees all cop 0 instructions
- Improved disassembly of PMMU instructions
- Preliminary 68LC040 support
- Fixed disassembly for EC/LC variants of '030/'040
* Added Nested Task flag, and I/O Privilege flags. They aren't
implemented in any way, but can now be set or reset. Can be used to
detect a 80386 or later CPU.
* Implemented ENTER instruction.
* Made IRQ vectors treated as 8 bytes when in protected mode, and made
the addresses pushed onto the stack 32-bit if the gate descriptor used
is a 386 interrupt or trap gate (also when in protected mode, will
always be 16-bit if in real mode).
---------- Forwarded message ----------
From: Barry Rodewald <bsr@xnet.co.nz>
Date: Tue, Nov 3, 2009 at 10:12 PM
Subject: i386 update
To: submit@mamedev.org
Hi,
Here's a few small fixes for the i386 core, based from the work I've
been doing on emulating the FM Towns in MESS. Mostly based from the
i386 Programmer's Reference Manual.
The fixes are as follows:
* Added Nested Task flag, and I/O Privilege flags. They aren't
implemented in any way, but can now be set or reset. Can be used to
detect a 80386 or later CPU.
* Implemented ENTER instruction, this is used by the FM Towns version of MS-DOS.
* Made IRQ vectors treated as 8 bytes when in protected mode, and made
the addresses pushed onto the stack 32-bit if the gate descriptor used
is a 386 interrupt or trap gate (also when in protected mode, will
always be 16-bit if in real mode).
I've tested a few i386 games (Seibu SPI, PC-AT, and Wolf System) in
MAME 0.135, with no obvious regressions.
Diff is based on MAME 0.135.
Thanks,
Barry Rodewald
mailto:bsr@xnet.co.nz
* Added JF table decode function.
* Added ABS, IMAC, and TFR2 opcodes.
* Fixed various flags for TST, INC24, SUB, CMP, and CMPM.
* Added hack to DO function to accommodate for the CPU core's inaccurate math.
(Polygonet Commanders goes 'ingame' yet again, but it's because of a hack I added
to the hardware DO function to ignore negative values. The do loop, of course, should
not be getting negative values, but that will require accurate math functions with
accurate rounding and limiting, and I'm not there yet. Oddly enough, i've also
broken the sky ROZ layer.)
- Support PMOVE modes from PMMU
- Allow the FPU to be used for both '030 and '040
- Add byte and word FPU loads/stores
- Fixed buggy FPU 64-bit stores in the (An) addressing mode
If anyone has any ideas on how to sanely handle the 68k FPU's 96-bit "take
that, Intel" mode let me know ;-)
> -----Original Message-----
> From: Christophe Jaillet [mailto:christophe.jaillet@wanadoo.fr]
> Sent: Saturday, October 17, 2009 9:00 AM
> To: submit@mamedev.org
> Subject: Speed up emu\cpu\e132xs
>
> Hi,
>
> this patch speeds up the emulation of the CPU e132xs.
>
> For the emulation of this CPU, two structures are used :
> - '_hyperstone_state' which keep track of the state of the
> processor
> - 'regs_decode' which is used when decoding the opcode being
> executed
>
> Both of these structures have a field 'op' but only the one of
> 'regs_decode'
> is actually used.
>
> The emulation of the CPU is done this way :
> - read the opcode
> - call the corresponding function which emulate this opcode. Two
> parameters are passed :
> o a pointer to hyperstone_state
> o the opcode itself
> - the opcode is then stored in the relevant field of a local stack
> stored 'regs_decode' structure.
>
> The field 'op' of '_hyperstone_state' is never used.
>
>
> So the proposed patch does the following :
> - use the 'op' field of '_hyperstone_state' instead of the one of
> 'regs_decode'
> - initialise this 'op' field before calling the function which
> emulate
> this opcode
> - remove the need of the second parameter ('opcode') of these
> functions
> - remove the now useless 'op' field of the structure 'regs_decode'
>
> Doing so removes the need of pushing a parameter on the stack for each
> opcode simulated and give a average speed up of 1 % or 2 % of the
> emulation.
>
> Hope this help.
> Best regards,
>
> CJ
> From: Atari Ace [mailto:atari_ace@verizon.net]
> Sent: Saturday, October 17, 2009 12:14 PM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] Remove dead prototypes
>
> Hi mamedev,
>
> This patch mostly removes dead prototypes, especially in source files
> as opposed to header files which I've previously audited. It also
> migrates a few prototypes to existing header files, and adds missing
> prototypes to segamsys.h.
>
> ~aa
> To: submit@mamedev.org
> CC: atariace@hotmail.com
> Subject: [patch] Eliminate more .data
> Date: Wed, 7 Oct 2009 08:51:56 -0700
>
> Hi mamedev,
>
> Most variables in .data are likely to lead to multisession bugs, so it
> is best to eliminate them and add explicit init/reset code for them
> instead. This patch does that for almost all the cases, with a few
> changes deserving some comments:
>
> z180: cc was global when it should be per-cpu.
> nesapu: the noise table would be different run to run in multisession
> which probably wasn't intended.
> astring: i constified the dummy string to make it impossible to
> modify.
> mediagx: hits was separated from the constant data
> tecmosys: i reduced the number of exports and renamed them to use
> tecmosys_ as a prefix.
> atari: i moved the renderer function into ANTIC.
> naomibd: the array provided to x76f100 was too small and might have
> caused memory corruption.
> n64: i constified the one and zero colors, requiring many more const
> qualifiers to be added.
> ldverify: i encapsulated the audio and video variables to reduce the
> amount of global state.
(Also makes the code prettier in parts)
(The dsp now goes into its calculation loop, but some
opcode doesn't set flags properly, so it never drops
out of the loop).
New games added or promoted from NOT_WORKING status
---------------------------------------------------
Mahjong Gekisha [Luca Elia, Guru, Dyq, Bnathan]
New clones added
----------------
Hana Jingi (Japan, Bet) [Luca Elia, Guru, Brian Troha, Yasuhiro Ogawa]
Types are pretty much unified now.
Multiply operations are handled by eminline.h.
Divide operations were just silly in macros.
64/32-bit combination/extraction macros moved to osdcomm.h and renamed.
Also fixed compile errors in recent 68k changes.
- Added working PMMU address translation (not feature complete, but sufficient
to boot several 68030 Macs in MESS)
- Fixed up disassembly of some PMMU instructions
- Added "68020 with 68851" CPU type
> From: Atari Ace [mailto:atari_ace@verizon.net]
> Sent: Wednesday, September 30, 2009 7:56 AM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] More static qualifiers
>
> Hi mamedev,
>
> This patch makes more of MAME static, primarily targeting functions
> exported by header files that are in fact unused outside their own
> file, and the chip emulators in machine/snes.c. It also degenericizes
> some exported names in archimds, bublbobl, and lucky74.
>
> ~aa
> From: Atari Ace [mailto:atari_ace@verizon.net]
> Sent: Sunday, September 27, 2009 7:58 AM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] More _NAME macros
>
> Hi mamedev,
>
> MAME's idiom for function/data macros is to first implement
> <name>_NAME, then implement the other macros in terms of the _NAME
> macro. Then in principle only a single line needs editing to change
> the naming convention.
>
> This patchset implements this idiom more completely. The first patch
> adds some missing _NAME macros and fixes cases in source files that
> should be using the macros. The second patch then changes header
> files where the macros should have been used, but weren't. This
> required changing the idiom for removing a machine driver function
> pointer from MDRV_<FUNCTION>(NULL) to MDRV_<FUNCTION>(0), to avoid
> problems with NULL being macro expanded. This actually unifies the
> handling of all such cases, as we already had ipt_0 and driver_init_0.
> It also required reworking the devtempl.h implementation in a way that
> triggered a warning on MSVC about using empty macros, so vconv.c
> needed to be updated. The third patch then renames all the _NAME and
> _0 macros to verify that all the cases have been covered, so it isn't
> intended to be applied.
>
> ~aa
> From: Atari Ace [mailto:atari_ace@verizon.net]
> Sent: Sunday, September 20, 2009 9:54 AM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] Eliminate more #ifdef LSB_FIRST
>
> Hi mamedev,
>
> This patch recodes more cases where LSB_FIRST is used to conditionally
> compile separate code for LSB and MSB targets. The atari.h chunk was
> dead code (both in MAME and MESS) so I simply removed it.
>
> ~aa
(Off the record)
I verified this thing against IDA Pro's 56156 disassembler and the docs.
Every time I found a bug in IDA's disassembler, I cross-referenced the
manual. There remain 3 opcodes which are questionably disassembled,
since even the manual is ambiguous on the details, but beyond that,
this thing should be 100% correct.
Whew. This might have actually fleshed out a bug in the
disassembly/execution. Time will tell...
> Sent: Monday, September 07, 2009 8:08 PM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] const/static/include fixes
>
> Hi mamedev,
>
> A result of some code auditing, this patch adds missing static and
> const qualifiers, and fixes up some header files.
>
> ~aa
> Sent: Sunday, September 06, 2009 7:25 AM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] Deglobalize input.c
>
> Hi mamedev,
>
> These patches deglobalize input.c. The first adds running_machine to
> some driver apis. The (large) second patch adds the machine parameter
> to the most input_code_pressed apis (generated by script, not
> compilable). The last patch then actually changes those apis and
> others to take running_machine, and adds struct _input_private to hold
> the input state variables.
>
> ~aa
> Sent: Saturday, September 05, 2009 2:11 PM
> To: submit@mamedev.org
> Subject: I386: fix loop instructions when address_size is 16-bit
>
> Original code always assume address_size to be 32-bit
> The patch will use the correct size based on the status of the
> address_size flag.
>
- Corrected ROM loading behavior for SuperFX games
- Added more ROM mirroring needed by certain SuperFX 2 games
- Corrected the behavior of certain bit-restricted SuperFX registers. Doom, Yoshi's Island, Dirt Trax FX and Voxel Demo show things now.
- Improved S-DD1 emulation, neither game using S-DD1 boots yet
Fixed a register naming issue in the MIPS core [Harmony]
Numerous SuperFX updates: [Harmony]
- Hooked up RAM and ROM buffering
- Inlined several more functions
- Removed debug spew
- Added the ability to define an external IRQ line callback, and hooked it up to the 65C816
- Fixed flag calculation for HIB opcode
- Hooked SuperFX chip up to the SNES machine driver
- Inlined a number of functions for possible speed increase
- Removed some memory buffering cruft, to be re-added later
- Fixed behavior of ASR opcode
- With additional MESS-side changes, Stunt Race FX is playable, and Vortex shows much more.
- Fixed disassembly of LMULT/FMULT ops
- Fixed reads using LDW/LDB
- Fixed writes using STW/STB
- Fixed SBC carry behavior
- Fixed GETC ROM access behavior
- Some SuperFX games begin to show things in MESS
- Indirect addressing was not taking into account special purpose memory mapped locations.
- 'iorlw' instruction was saving the result to memory instead of the W register.
- 'tris' instruction no longer modifies Port-C on PIC models that do not have Port-C implemented.
Also added difficulty DIP to BigTwin
> -----Original Message-----
> From: Gabriele Gorla [mailto:gorlik@penguintown.net]
> Sent: Saturday, August 29, 2009 5:39 AM
> To: submit@mamedev.org
> Cc: Gabriele Gorla
> Subject: Re: i386: fix carry/borrow flag in ADC/SBB
>
> > the original code implements ADC and SBB as 2 consecutive ADDs.
> > This will not produce the correct result when the carry is generated
> by
> > the first addition as it is overwritten by the second operation.
>
> updated patch, fixes a typo.
- Disabled RAM/ROM clocking, going with instant transfer for now
- Understood and re-enabled pipelined instruction architecture, Star Fox runs farther
- Fixed a ridiculous typo in ROL instruction
- Corrected carry flag behavior in ROL opcode
- Corrected BRA target address calculation (maybe still wrong)
- Corrected LOOP target address calculation
- Made sure that FROM sets cpustate->sreg_idx
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=199853&page=0&view=expanded&sb=5&o=&fpart=1&vc=1
I don't know this z80 emulator well enough to look into his first two points. Juergen?
1/ In the cc_xy[] table which lists instructions with DD or FD prefixes, "illegal" combos are returning 4 cycles when they should return 4 + cc_op (the normal instruction being executed). Another way to handle this correctly is to call EXEC(z80,fd,xx) or EXEC(z80,dd,xx) instead of op_xx(z80) when such pair of opcode is detected, to be sure the correct amount of cycles is used.
2/ According to Sean Young, R register is NOT incremented when chaining multiple DD or FD prefixes: [...]
This one was already fixed, dunno when:
2/ In the cc_ed[] table, INI (ED A2) and IND (ED AA) should return 16 cycles, like other instructions from this group, not 12. This seems to be a typo error.
- added unidasm to the tools build
- split the disassemblers out of libcpu and into new libdasm
- ensured the disassembly entry points for all disassemblers are
in the source file for the disassembler (sometimes new generic
versions were created)
Still needs command line options and file loading, but the
fundamentals are present, and it links.
- added cycle tables and cleaned up source layout. This was done very carefully, it should be errorfree.
- removed HLT cycle eating (earlier, HLT after EI could theoretically fail)
- fixed parity flag on add/sub/cmp. Bug was caused by z80 overflow detection accidentally left in
- renamed temp register XX to official name WZ
- renamed flags from Z80 style S Z Y H X V N C to S Z X5 H X3 P V C, and fixed X5 / V flags where accidentally broken due to flag names confusion
- Fixed X/Y flags in CCF/SCF/BIT, ZEXALL is happy now
- Simplified DAA, renamed MEMPTR (3.8) to WZ (same temp register as the officially named WZ in the 8080), added TODO
the cycle fix by Marshmellow, in the 3.9 z80.c comments was already committed in june, just added there for documentation
integers. This is defined to be "I64" on MSVC and recent mingw compilers,
and "ll" for all others.
Updated all instances of 64-bit prints to use the new macro.
Sent: Friday, August 07, 2009 9:33 AM
To: submit@mamedev.org
Subject: z180 daatable removed
Since I removed the daatable from i8085, and the z180 one is exactly the
same, I might as well remove that one too, see attached diff.
hap
Sent: Friday, August 07, 2009 6:45 AM
To: submit@mamedev.org
Subject: spacwalk dips and player2 support
Hello,
Attached is a diff for 0133u1 Space Walk that adds game time and coinage
DIP switches, as well as service mode and input test. DIP switches 5 and 6
are still unknown. It also adds support for the 2nd controller and
coincounter, similar to clowns. I've removed the GAME_NOT_WORKING flag, since
other than a glitch with the CPU controlled pad on the left side, the gameplay
is working fine. The fact that the middle section is inaccessible looks
deliberate: there's probably a vertical-shape object in the original artwork
the clown (astronaut in this case:P) can bump into.
Greets,
hap
Sent: Thursday, August 06, 2009 7:09 AM
To: submit@mamedev.org
Subject: i8080 daa + multiple memreads fix, gottlieb audio, looping log
Hello,
i8080_daa_multiplememreads.zip: diff for 0133u1 i8080/i8085 cpu, removing the
DAA table and fixing multiple memory reads on some opcodes (which would possibly
only trigger on memorymapped I/O), and making M_ANA(R) halfcarry calculation a
bit more straightforward. The functionality is basically the same as before.
i8080_newdaa_test.zip was used to test the new DAA implementation.
src/emu/cpu/i8085/i8085daa.h can be removed in 0.134, or is DIFF capable of
removing files completely?
Greets,
hap
> To: submit@mamedev.org
> CC: atariace@hotmail.com
> Subject: [patch] Introduce tilemap_private to running_machine
> Date: Thu, 23 Jul 2009 18:49:08 -0700
>
> Hi mamedev,
>
> Tilemaps in MAME are currently globally tracked. If multiple machines
> with different tilemaps are ever to be supported, this needs to be
> changed, which this patchset does.
>
> 0. This patch add tilemap_private to running_machine, adds machine to
> a few apis and adds two new apis to replace the convention that tmap =
> NULL => all tilemaps.
> 1. This patch mechanically converts all the uses of ALL_TILEMAPS to
> use the new apis.
> 2. This patch removes ALL_TILEMAPS and makes tilemap_private
> dynamically allocated per machine.
>
> ~aa
I have done Intel 4004 implementation, here is a patch (it also
contain a POC driver for 4004 Nixie tube clock, that runs under MESS).
4004clk is artwork file, and roms file contain needed roms (just rename ZIP).
Regards,
Miodrag
> -----Original Message-----
> From: Micko [mailto:mmicko@gmail.com]
> Sent: Tuesday, August 04, 2009 8:11 AM
> To: Aaron Giles
> Subject: Intel 4004 core
>
> Hi Aaron,
>
> Here is a final version of CPU core for MAME submition.
>
> Regards,
> Miodrag
Probably not harmful currently, but if the UML core ever gets more aggressive
with optimization (e.g. if we spliced in something like LLVM as a code
generator) it could've become an issue.
Date: Sat, 25 Jul 2009 11:57:29 -0700
To: submit@mamedev.org<submit@mamedev.org>
Subject: 68k cpu reset eat cycles fix
Hello,
Attached is a diff for 0133 that fixes a bug related to eating cycles
during 68k cpu reset. Previously, initial_cycles had a wrong value
after reset, and if cycles were < 0, it'd always return 0, .. check
the diff to see what I mean.
This change also happens to fix a scrolling bug in Fantasy Zone,
introduced when that cycle eating thing was added.
Greets,
hap
constants to cpuintrf, as those names are really only applicable to
CPUs. Added new ADDRESS_MAP_0/1/2/3 constants to identify address maps
more generically.
Updated memory system to be more general about address map handling.
Added the concept of default address maps (in addition to the already
existing internal memory maps). The difference between internal and
default memory maps is that internal memory maps always override
everything (including user-specified maps), but default memory maps
simply provide a default that can be overridden.
Converted the okim6295 sound driver to use address maps for access.
By default, it defines a ROM address map that overlays its full
region. As a result, the validity checks require all okim6295 regions
to be at least 256k, unless you provide your own address map. Updated
all regions to meet this requirement.
Updated the atarijsa code to use a custom address space for its
okim6295 accesses (which are banked on the first half and static on
the second half), as an example of configuring a device with a
custom address space.
For now, attempts to use okim6295_set_bank_base() will still work,
though banking for the okim chips should be moved to custom address
maps in the drivers eventually. The first time okim6295_set_bank_base()
is called, it will install a banked memory handler over the region
and use memory_set_bankptr() to change the base on subsequent bank
switches.
Moved address map validity checks to be run for each device instead of
just each CPU.
to devintrf (including endianness). Removed space array from the
CPU class header. Made the memory system much more device-neutral.
Various other cleanups along the way.
The plan is to add the on-chip peripherals on the magicard.c driver then, when I get some consistency, hardwire it to the cpu core.
Please check this modification asap (should be fine, but I haven't compiled with a clean build)
Sent: Monday, June 29, 2009 3:58 AM
To: submit@mamedev.org
Subject: Patch for i86.c to fix an assert
Hello,
attached is a small patch for i86.c that fixes an assert when the
80188 CPU is used.
--Dirk
Fixed internal RAM/internal I/O start-up state, and updated Hit Poker driver to use it like it should.
Taito JC driver seems unaffected by this change.
======================================================================================================
http://mamedev.emulab.it/kale/fast/files/memory_map.png
Added some basic video emulation to Hit Poker, to let it show "9rror / 3hut 5own -achine"
=========================================================================================
http://mamedev.emulab.it/kale/fast/files/0013_1049739007.png
Sent: Tuesday, June 16, 2009 7:09 AM
To: submit@mamedev.org
Cc: atariace@hotmail.com
Subject: [patch] Pointerify minx cpu
Hi mamedev,
I noticed that the minx CPU was never pointerified. It's only used by
MESS, which might be why it wasn't noticed.
~aa
Sent: Sunday, June 07, 2009 9:54 AM
To: submit@mamedev.org
Cc: atariace@hotmail.com
Subject: [patch] "Regularize" some interfaces in MAME
Hi mamedev,
This patch adjusts the code in a few places to be more regular in it
object approach. It recognizes five idioms.
1. device_configs should be passed const. dsp56k.h took a non-const
device_config for no particular reason, necessitating casting where
used. A few other places cast to non-const, in most cases
unnecessarily.
2. running_machines should be passed non-const. A few places used
const in different ways on running_machines, instead of the idiomatic
non-const running_machine.
3. Eliminate passing running_machine explicitly where it can be
computed. esrip.c, m37710.c, sfbonus.c had cases where the machine
could easily be eliminated.
4. Pass the object machine/config first. In some cases this makes
the interface object oriented, in some cases it simply makes it more
idiomatic with the rest of MAME.
5. Prefer (screen, bitmap, cliprect) to (machine, bitmap, cliprect).
Fully implementing this would be a large patch, this patch simply does
it for the one core 'device', tms9928a.c.
fixes up some header files. In particular, I adjusted const char
*DEVTEMPLATE_SOURCE = __FILE__ to const char DEVTEMPLATE_SOURCE[] =
__FILE__ which makes it actually const and saves a little memory.
[Atari Ace]
Sent: Sunday, May 24, 2009 4:11 AM
To: submit@mamedev.org
Subject: Compilation fix for ARM7 core
This fixes the compilation with ARM7_DEBUG_CORE. It was actually
found by Reijo Tomperi from the cppcheck team after I issued a bug
report.
Updated polepos and bosco drivers to use the new 52xx sound
emulation, wiring up the output through the discrete mixer that
Derrick had already plumbed but left disabled.
This required several MB88xx changes/fixes:
- internal timer support now works; prescaler is guessed based
on Pole Position sample playback frequency
- external counter support works
- a basic mechanism for reading serial input has been added; it
is not sufficient for a full implementation, but good enough
to sample the SI pin at startup
- fixed TSTS/TSTV to clear their respective flags
- fixed CI and CYI to compute imm-reg instead of reg-imm
- added masking of the PA register upon RTI/RTS to prevent bogus
PC values
Sent: Friday, May 15, 2009 9:13 AM
To: submit@mamedev.org
Subject: Unused Variables - second try
This is a new version of the patch, that disables some unused
variables. It fixes some warnings, that came up in an optimized build
and adds a few more things.
Sent: Sunday, May 10, 2009 5:41 PM
To: submit@mamedev.org
Cc: atariace@hotmail.com
Subject: [patch] Static qualifier update
Hi mamedev,
Here's my periodic static qualifier patch for MAME, mostly adding
static to new code introduced over the past couple of months.
~aa
* jb int0,<self> loops are now broken out of if int0 comes and is taken
* externally-clocked counters only count when enabled
System 1 changes:
* hooked up 8751 properly
* removed old 8751 hacks
* shuffled Shooting Master sets
New Games Marked Working
------------------------
Choplifter (8751 315-5151)
Shooting Master (EVG, 8751 315-5159a)
This update changes the way we handle memory allocation. Rather
than allocating in terms of bytes, allocations are now done in
terms of objects. This is done via new set of macros that replace
the malloc_or_die() macro:
alloc_or_die(t) - allocate memory for an object of type 't'
alloc_array_or_die(t,c) - allocate memory for an array of 'c' objects of type 't'
alloc_clear_or_die(t) - same as alloc_or_die but memset's the memory to 0
alloc_array_clear_or_die(t,c) - same as alloc_array_or_die but memset's the memory to 0
All original callers of malloc_or_die have been updated to call these
new macros. If you just need an array of bytes, you can use
alloc_array_or_die(UINT8, numbytes).
Made a similar change to the auto_* allocation macros. In addition,
added 'machine' as a required parameter to the auto-allocation macros,
as the resource pools will eventually be owned by the machine object.
The new macros are:
auto_alloc(m,t) - allocate memory for an object of type 't'
auto_alloc_array(m,t,c) - allocate memory for an array of 'c' objects of type 't'
auto_alloc_clear(m,t) - allocate and memset
auto_alloc_array_clear(m,t,c) - allocate and memset
All original calls or auto_malloc have been updated to use the new
macros. In addition, auto_realloc(), auto_strdup(), auto_astring_alloc(),
and auto_bitmap_alloc() have been updated to take a machine parameter.
Changed validity check allocations to not rely on auto_alloc* anymore
because they are not done in the context of a machine.
One final change that is included is the removal of SMH_BANKn macros.
Just use SMH_BANK(n) instead, which is what the previous macros mapped
to anyhow.
function here. Remaining devices have been converted to have
device-specific functions to do the same thing with proper type
checking.
CPUs still have a set_info function but it is CPU-specific now and
no longer piggybacks on the general device function.
