summaryrefslogtreecommitdiffstatshomepage
path: root/src/emu/addrmap.cpp
Commit message (Collapse)AuthorAgeFilesLines
* emumem: First try at wait states Olivier Galibert2023-02-221-0/+3
|
* Fun with flags: Allows handlers to have user-defined flags set on Olivier Galibert2021-11-281-2/+4
| | | | | | them, which can them be picked up on access with the {read,write}_*_flags variants of the accessors. Example use with the i960 and its burstable rom/ram.
* Initialize m_config in all situations. Aaron Giles2021-06-261-0/+2
|
* Eliminate many unnecessary c_str calls AJR2020-12-211-3/+3
|
* Fairly significant overhaul of Lua engine and some cleanup. Vas Crabb2020-11-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The things that were previously called device iterators are not iterators in the C++ sense of the word. This is confusing for newcomers. These have been renamed to be device enumerators. Several Lua methods and properties that previously returned tables now return lightweight wrappers for the underlying objects. This means creating them is a lot faster, but you can't modify them, and the performance characteristics of different operations varies. The render manager's target list uses 1-based indexing to be more like idiomatic Lua. It's now possible to create a device enumerator on any device, and then get subdevices (or sibling devices) using a relative tag. Much more render/layout functionality has been exposed to Lua. Layout scripts now have access to the layout file and can directly set the state of an item with no bindings, or register callbacks to obtain state. Some things that were previously methods are now read-only properties. Layout files are no longer required to supply a "name". This was problematic because the same layout file could be loaded for multiple instances of the same device, and each instance of the layout file should use the correct inputs (and in the future outputs) for the device instance it's associated with. This should also fix video output with MSVC builds by avoiding delegates that return things that don't fit in a register.
* Work around GNU libstdc++ wanting to stack large temporaries when vector ↵ Vas Crabb2020-11-231-4/+4
| | | | elements can be trivially constructed.
* Implement views, which are essentially bankdevs integrated into the Olivier Galibert2020-11-221-39/+38
| | | | memory map system. [O. Galibert]
* emumem: Simplify memory management. [O. Galibert] Olivier Galibert2020-11-021-4/+19
| | | | | | | | | | | | | | | | | | | | API impact: - install_ram/rom/writeonly now requires a non-null pointer. If you want automatically managed ram, add it to a memory map, not in machine_start - install_*_bank now requires a memory_bank *, not a string - one can create memory banks outside of memory maps with memory_bank_creator - one can create memory shares outside of memory maps with memory_share_creator Memory maps impact: - ram ranges with overlapping addresses are not shared anymore. Use .share() - ram ranges touching each other are not merged anymore. Stay in your range Extra note: - there is no need to create a bank just to dynamically map some memory/rom. Just use install_rom/ram/writeonly
* Got rid of global_alloc/global_free. Vas Crabb2020-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The global_alloc/global_free functions have outlived their usefulness. They don't allow consistently overriding the default memory allocation behaviour because they aren't used consistently, and we don't have standard library allocator wrappers for them that we'd need to use them consistently with all the standard library containers we're using. If you need to change the default allocator behaviour, you can override the new/delete operators, and there are ways to get more fine-grained control that way. We're already doing that to pre-fill memory in debug builds. Code was already starting to depend on global_alloc/global_free wrapping new/delete. For example some parts of the code (including the UI and Windows debugger) was putting the result of global_alloc in a std::unique_ptr wrappers without custom deleters, and the SPU sound device was assuming it could use global_free to release memory allocated with operator new. There was also code misunderstanding the behaviour of global_alloc, for example the GROM port cartridge code was checking for nullptr when a failure will actually throw std::bad_alloc. As well as substituting new/delete, I've made several things use smart pointers to reduce the chance of leaks, and fixed a couple of leaks, too.
* emu: correct some file headers (nw) hap2020-06-191-1/+1
|
* Enforce that width and endianness of directly-mapped ROM regions should ↵ AJR2019-12-111-0/+33
| | | | | | match those of the address space (nw) All of the once-numerous validation failures that this change induced have been fixed in preceding commits. Unmerged drivers may need to be modified to comply with this.
* Make devdelegate more like devcb for configuration. This is a Vas Crabb2019-10-261-69/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fundamental change to show device delegates are configured. Device delegates are now aware of the current device during configuration and will resolve string tags relative to it. This means that device delegates need a device to be supplied on construction so they can find the machine configuration object. There's a one-dimensional array helper to make it easier to construct arrays of device delegates with the same owner. (I didn't make an n-dimensional one because I didn't hit a use case, but it would be a simple addition.) There's no more bind_relative_to member - just call resolve() like you would for a devcb. There's also no need to cast nullptr when creating a late bind device delegate. The flip side is that for an overloaded or non-capturing lambda you'll need to cast to the desired type. There is one less conditional branch in the hot path for calls for delegates bound to a function pointer of member function pointer. This comes at the cost of one additional unconditional branch in the hot path for calls to delegates bound to functoids (lambdas, functions that don't take an object reference, other callable objects). This applies to all delegates, not just device delegates. Address spaces will now print an error message if a late bind error is encountered while installing a handler. This will give the range and address range, hopefully making it easier to guess which memory map is faulty. For the simple case of allowing a device_delegate member to be configured, use a member like this: template <typename... T> void set_foo(T &&...args) { m_foo_cb.set(std::forward<T>(args)...); } For a case where different delegates need to be used depending on the function signature, see src/emu/screen.h (the screen update function setters). Device delegates now take a target specification and function pointer. The target may be: * Target omitted, implying the current device being configured. This can only be used during configuration. It will work as long as the current device is not removed/replaced. * A tag string relative to the current device being configured. This can only be used during configuration. It will not be callable until .resolve() is called. It will work as long as the current device is not removed/replaced. * A device finder (required_device/optional_device). The delegate will late bind to the current target of the device finder. It will not be callable until .resolve() is called. It will work properly if the target device is replaced, as long as the device finder's base object isn't removed/replaced. * A reference to an object. It will be callable immediately. It will work as long as the target object is not removed/replaced. The target types and restrictions are pretty similar to what you already have on object finders and devcb, so it shouldn't cause any surprises. Note that dereferencing a device finder will changes the effect. To illustrate this: ... required_device<some_device> m_dev; ... m_dev(*this, "dev") ... // will late bind to "dev" relative to *this // will work if "dev" hasn't been created yet or is replaced later // won't work if *this is removed/replaced // won't be callable until resolve() is called cb1.set(m_dev, FUNC(some_device::w)); ... // will bind to current target of m_dev // will not work if m_dev is not resolved // will not work if "dev" is replaced later // will be callable immediately cb2.set(*m_dev, FUNC(some_device::w)); ... The order of the target and name has been reversed for functoids (lambdas and other callable objects). This allows the NAME macro to be used on lambdas and functoids. For example: foo.set_something(NAME([this] (u8 data) { m_something = data; })); I realise the diagnostic messages get ugly if you use NAME on a large lambda. You can still give a literal name, you just have to place it after the lambda rather than before. This is uglier, but it's intentional. I'm trying to drive developers away from a certain style. While it's nice that you can put half the driver code in the memory map, it detracts from readability. It's hard to visualise the memory range mappings if the memory map functions are punctuated by large lambdas. There's also slightly higher overhead for calling a delegate bound to a functoid. If the code is prettier for trivial lambdas but uglier for non-trivial lambdas in address maps, it will hopefully steer people away from putting non-trivial lambdas in memory maps. There were some devices that were converted from using plain delegates without adding bind_relative_to calls. I fixed some of them (e.g. LaserDisc) but I probably missed some. These will likely crash on unresolved delegate calls. There are some devices that reset delegates at configuration complete or start time, preventing them from being set up during configuration (e.g. src/devices/video/ppu2c0x.cpp and src/devices/machine/68307.cpp). This goes against the design principles of how device delegates should be used, but I didn't change them because I don't trust myself to find all the places they're used. I've definitely broken some stuff with this (I know about asterix), so report issues and bear with me until I get it all fixed.
* (nw) removed every remaining AM_ macro I could find in comments, but one in ↵ Ivan Vangelista2019-10-101-1/+1
| | | | emu\memarray.h cause I didn't want to cause a full recompile for this (nw)
* Make osd_printf_* use util/strformat semantics. Vas Crabb2019-09-261-3/+3
| | | | | | | | | | | | | | | | | (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.
* Make submaps work with address-shifted spaces (nw) AJR2019-06-091-7/+40
| | | | Note that submaps are now assumed to use an address shift of 0. It is possible, though unlikely, for this to cause some breakage.
* (nw) Clean up the mess on master Vas Crabb2019-03-261-6/+0
| | | | | | | | | | | | | This effectively reverts b380514764cf857469bae61c11143a19f79a74c5 and c24473ddff715ecec2e258a6eb38960cf8c8e98e, restoring the state at 598cd5227223c3b04ca31f0dbc1981256d9ea3ff. 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.
* Revert "conflict resolution (nw)" andreasnaive2019-03-251-0/+6
| | | | | This reverts commit c24473ddff715ecec2e258a6eb38960cf8c8e98e, reversing changes made to 009cba4fb8102102168ef32870892438327f3705.
* Eliminate the default address map member of address_space_config (nw) AJR2019-02-171-6/+0
| | | | | | Since all device address maps are now class methods defined in ordinary C++, default RAM maps can be provided more simply with an explicit has_configured_map check in an internal map definition. A number of default address maps that probably weren't meant to be overridden have also been changed to ordinary internal maps.
* -keyboard/a1200, changela, goldnpkr, m68705prg, mexico86, pipeline, pitnrun, ↵ mooglyguy2018-12-141-1/+1
| | | | | | | | | | qix, quizpun2, stfight, tigeroad: Removed MACHINE_CONFIG. [Ryan Holtz] -m68705, m68hc05: Removed MCFG. [Ryan Holtz] -qix: First-pass cleanup. [Ryan Holtz] -core: Fixed spelling of "nonexistent". [Ryan Holtz]
* memory,devcb: Put capabilities at parity [O. Galibert] Olivier Galibert2018-08-101-18/+210
|
* I did say it would be dreafully stupid (nw) Olivier Galibert2018-08-031-11/+11
|
* memory: Allow simplified versions of handlers [O. Galibert] Olivier Galibert2018-08-021-34/+315
| | | | | | | | | | | | | | | | | | | | | | | A standard memory handler has as a prototype (where uX = u8, u16, u32 or u64): uX device::read(address_space &space, offs_t offset, uX mem_mask); void device::write(address_space &space, offs_t offset, uX data, uX mem_mask); We now allow simplified versions which are: uX device::read(offs_t offset, uX mem_mask); void device::write(offs_t offset, uX data, uX mem_mask); uX device::read(offs_t offset); void device::write(offs_t offset, uX data); uX device::read(); void device::write(uX data); Use them at will. Also consider (DECLARE_)(READ|WRITE)(8|16|32|64)_MEMBER on the way out, use the explicit prototypes. Same for lambdas in the memory map, the parameters are now optional following the same combinations.
* emumem: Backend modernization [O. Galibert] Olivier Galibert2018-06-291-21/+0
|
* Move ROM loading macros to romentry.h and remove romload.h from emu.h (nw) AJR2018-06-241-0/+1
|
* as if millions of this pointers suddenly cried out in terror, and were ↵ Vas Crabb2018-06-081-6/+3
| | | | | | | suddenly silenced * streamline templates in addrmap.h * get rid of overloads on read/write member names - this will become even more important in the near future
* Remove some machine().device usage from the core (nw) AJR2018-05-201-5/+3
|
* Relax constraints on address mirroring/global mask combinations. Mirror bits ↵ AJR2018-04-111-0/+6
| | | | | | are now allowed to fall outside the driver-specified global mask, though memory map validation requires that they cover the entire masked-out portions of the address space if any do. This change is intended to expedite debugging of software written for the TMPZ84C015 or similar Z80-based controllers which use 8-bit I/O addressing for the on-chip peripherals but may use either 8-bit or 16-bit addressing externally.
* Some corners of C/C++ are just a pain (nw) Olivier Galibert2018-03-141-1/+1
|
* addrmap: Fix subtle bug with nonsubtle effects, also ensure initialization (nw) Olivier Galibert2018-03-141-1/+2
|
* Rename some memory stuff (nw) Olivier Galibert2018-03-141-6/+23
|
* Generalized support for byte-smeared accesses (nw) (#3207) ajrhacker2018-02-151-2/+5
| | | The new cswidth address map constructor method overrides the masking normally performed on narrow-width accesses. This entailed a lot of reconfiguration to make the shifting and masking of subunits independent operations. There is unlikely to have any significant performance impact on drivers that don't frequently reconfigure their memory handlers.
* emumem: Fix extra-large device map (nw) Olivier Galibert2018-02-121-6/+9
|
* API change: Memory maps are now methods of the owner class [O. Galibert] Olivier Galibert2018-02-121-187/+200
| | | | | Also, a lot more freedom happened, that's going to be more visible soon.
* address_map: Internal maps must now be constructed last to have priority (nw) AJR2018-02-011-6/+6
| | | | This fixes sound in mpatrol.
* memory: Deambiguate handlers, also a hint of things to come (nw) Olivier Galibert2018-01-191-26/+26
|
* Pet peeving with extreme prejudice (nw) Olivier Galibert2017-11-301-2/+2
|
* remove debug code (nw) smf-2017-11-291-1/+0
|
* emumem: API change [O. Galibert] Olivier Galibert2017-11-291-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * direct_read_data is now a template which takes the address bus shift as a parameter. * address_space::direct<shift>() is now a template method that takes the shift as a parameter and returns a pointer instead of a reference * the address to give to {read|write}_* on address_space or direct_read_data is now the address one wants to access Longer explanation: Up until now, the {read|write}_* methods required the caller to give the byte offset instead of the actual address. That's the same on byte-addressing CPUs, e.g. the ones everyone knows, but it's different on the word/long/quad addressing ones (tms, sharc, etc...) or the bit-addressing one (tms340x0). Changing that required templatizing the direct access interface on the bus addressing granularity, historically called address bus shift. Also, since everybody was taking the address of the reference returned by direct(), and structurally didn't have much choice in the matter, it got changed to return a pointer directly. Longest historical explanation: In a cpu core, the hottest memory access, by far, is the opcode fetching. It's also an access with very good locality (doesn't move much, tends to stay in the same rom/ram zone even when jumping around, tends not to hit handlers), which makes efficient caching worthwhile (as in, 30-50% faster core iirc on something like the 6502, but that was 20 years ago and a number of things changed since then). In fact, opcode fetching was, in the distant past, just an array lookup indexed by pc on an offset pointer, which was updated on branches. It didn't stay that way because more elaborate access is often needed (handlers, banking with instructions crossing a bank...) but it still ends up with a frontend of "if the address is still in the current range read from pointer+address otherwise do the slowpath", e.g. two usually correctly predicted branches plus the read most of the time. Then the >8 bits cpus arrived. That was ok, it just required to do the add to a u8 *, then convert to a u16/u32 * and do the read. At the asm level, it was all identical except for the final read, and read_byte/word/long being separate there was no test (and associated overhead) added in the path. Then the word-addressing CPUs arrived with, iirc, the tms cpus used in atari games. They require, to read from the pointer, to shift the address, either explicitely, or implicitely through indexing a u16 *. There were three possibilities: 1- create a new read_* method for each size and granularity. That amounts to a lot of copy/paste in the end, and functions with identical prototypes so the compiler can't detect you're using the wrong one. 2- put a variable shift in the read path. That was too expensive especially since the most critical cpus are byte-addressing (68000 at the time was the key). Having bit-adressing cpus which means the shift can either be right or left depending on the variable makes things even worse. 3- require the caller to do the shift himself when needed. The last solution was chosen, and starting that day the address was a byte offset and not the real address. Which is, actually, quite surprising when writing a new cpu core or, worse, when using the read/write methods from the driver code. But since then, C++ happened. And, in particular, templates with non-type parameters. Suddendly, solution 1 can be done without the copy/paste and with different types allowing to detect (at runtime, but systematically and at startup) if you got it wrong, while still generating optimal code. So it was time to switch to that solution and makes the address parameter sane again. Especially since it makes mucking in the rest of the memory subsystem code a lot more understandable.
* Start adding stuff for iterating ROM entries in a more C++ way without ↵ Vas Crabb2017-09-221-3/+5
| | | | needing to allocate everywhere, improve performance of -listxml by another 10% or so
* dimemory: Lift the cap on the number of address spaces per device [O. Galibert] Olivier Galibert2017-07-031-3/+3
|
* Improve validation checking for address ranges (nw) AJR2017-06-221-11/+10
| | | | arcompact: Attempt at fixing I/O space (nw)
* Sorry test, it's not that I don't like you anymore, but there's this Olivier Galibert2017-06-211-4/+1
| | | | AM_IMPORT_FROM guy there, and it's real love this time (nw)
* NPOT subunit compromise (nw) AJR2017-04-281-7/+2
| | | | Handlers with a non-power-of-2 number of subunits are allowed once again. However, the offset multiplier will be rounded up to the nearest power of 2.
* Perform unitmask checking during validation in non-debug builds (nw) AJR2017-04-261-7/+31
|
* Memory unit masking and address mirroring fixes (nw) AJR2017-03-251-1/+25
| | | | | | - Fix a bug which effectively treated AM_MIRROR as AM_SELECT when applied to a single-address range mirrored into a contiguous block. The automatic expansion of zero address masks now only applies to those stemming from (default) configuration, not from optimization. (This allows the assertion in latch8_device to be reinstated.) - Fix a bug where AM_SELECT applied to narrow-width handlers with a submaximal number of subunits would select the wrong address bits or none at all. (This allows rpunch_gga_w to be WRITE8 as intended.) - Add more stringent appropriateness checking of unit masks for narrow-width handlers.
* Adds a new addrmap.cpp validation intended to catch AM_REGION declarations ↵ Nathan Woods2017-03-091-0/+4
| | | | not tied to anything meaningful
* Address map fixes (nw) AJR2016-12-251-3/+5
| | | | | | - tms32025: Correct space of internal data maps - mc1000: Separate out opcodes map - addrmap.cpp: Replace a few debug asserts with friendlier error messages (makes validation less dangerous in debug builds)
* srcclean (nw) Vas Crabb2016-11-271-3/+3
|
* Introduce u8/u16/u32/u64/s8/s16/s32/s64 Vas Crabb2016-11-191-25/+25
| | | | | | | | | | | | * New abbreviated types are in osd and util namespaces, and also in global namespace for things that #include "emu.h" * Get rid of import of cstdint types to global namespace (C99 does this anyway) * Remove the cstdint types from everything in emu * Get rid of U64/S64 macros * Fix a bug in dps16 caused by incorrect use of macro * Fix debugcon not checking for "do " prefix case-insensitively * Fix a lot of messed up tabulation * More constexpr * Fix up many __names
* addrmem: Obvious renames and helpers [O. Galibert] Olivier Galibert2016-11-101-4/+4
|