OpenMSX Git (2015/09/20) is complie. OpenMSX is an open source MSX emulator which is free according to the Debian Free Software Guidelines, available under the GNU General Public License.For copyright reasons the emulator cannot be distributed with original BIOS ROM images. OpenMSX includes C-BIOS a minimal implementation of the MSX BIOS, allowing to play quite some games without the need to have an original MSX BIOS ROM image. You can also use your own BIOS ROM image if you please.

OpenMSX Git Changelog:
* add MSXHiResTimer to the visual stdio build
* Added high-resolution-timer MSX device
In doc/internal/r800-call.txt I describe a MSX peripheral Alex Wulms once build
for me. It's a MSX cartridge containing a high resolution 32-bit counter. The
counter ticks at 3.57MHz. It reacts to IO ports 0x20-0x23. Writing to any port
resets the counter. Reading port 0x20 makes an internal copy of the value of
the counter and returns the 8 lower bits of that copy. Reading ports 0x21-0x23
returns the other 3 bytes (from low to high) of this copy.
I'm working on improving the emulated R800 timing. To do this I want to compare
my measured values on the real hardware with the emulated values using the same
hardware. So I need an emulation model of this high resolution timer.
I already had this emulated timer in a private branch for a very long time
(several years). Since there only exist one corresponding real hardware device
I never merged this to the master branch. Though the emulated device is useful
by itself. It's a bit like our DebugDevice, there are also no real hardware
equivalents of it, but still people use it. So I'm now also adding this timer
device.
* [3/3] decode inplace
The first patch in this series changed the return type of the decode()
functions from std::string to Membuffer. In both cases the decode()
function allocates a new memory block for the decoded data. In some (but not
all) cases the only thing we do with this memory block is copy it to another
buffer and deallocate the returned memory block. It's more efficient to
directly decode the data to the final destination.
So this patch adds an extra decode_inplace() function (the existing decode()
function is kept as well). This new function takes a pointer to the destination
buffer and the size of this buffer. It returns an error if the size of the
decoded data is not exactly the same as the size of the destination buffer.
This error check has a cost (because we only know the size of the decoded block
after we've decoded it, and during decoding we cannot accidentally write past
the end of the destination buffer), but this cost is less than the cost of
allocate+copy+deallocate.
So far this new decode_inplace() function is only used when loading blobs from
XML savestates.
* [2/3] avoid copy on passing string to decode()
Avoid an unnecessary copy when passing an hex- or base64-encoded string from
the XML savestate to the HexDump:: or Base64::decode() function.
To a lesser degree the same was true for loading int's from an XML savestate.
Also improved now.
* [1/3] return 'MemBuffer' instead of string
This patch series fixes a few inefficiencies in hex or base-64
encoding/decoding. This is used for storing binary blobs (e.g. memory mapper
content) in XML savestates or for storing initial memory patterns in machine
configuration files.
--
In this first step we change the decode() functions in the HexDump and Base64 classes
to return a MemBuffer instead of a std::string. The latter was
inefficient because:
- (in Base64) we first needlessly zero-initialize the memory
- (in HexDump) we reallocate the memory a few times (while growing)
Both could be fixed by using std::string::reserve(), but using
MemBuffer instead of std::string is an equally good solution and it
more closely matches what's actually meant (return a buffer of bytes).
To be more consistent, the input side (the encode() function) now takes a
uint8_t* as input instead of a void*.
* Fix(?) LessTupleElement for vs2015
Visual studio 2015 triggered errors like
C2338: tuple_element index out of bounds
on compiling our LessTupleElement utility. Hopefully this patch fixes that.
--
It's not 100% clear whether this was a bug in the vs2015 library or whether our
code relied on a non-standardized implementation detail. Here's some background
info:
Part of the old implementation of LessTupleElement went like this:
template struct LessTupleElement {
template
bool operator()(const TUPLE& x, const TUPLE& y) const { ... }
template
bool operator()(const typename std::tuple_element::type& x,
const TUPLE& y) const { ... }
template
bool operator()(const TUPLE& x,
typename std::tuple_element::type& y) const { ... }
};
So we have a LessTupleElement struct with three overloaded function-call
operators. The 1st takes 2 tuples, the latter 2 take a tuple and a parameter
with as type the N-th element of that tuple. We rely on SFINAE to deduce the
correct type for the 'TUPLE' template parameter and select the correct
overload. E.g. when you call this functor with a 'int' and a 'tuple' parameter the 2nd overload should be selected and TUPLE should be
deduced to be 'tuple'. Also in this example it's impossible to
find a type for TUPLE so that the 1st and 3rd overload don't generate some
error (and we actually do want these to be SFINAE failures).
At least this is the story for gcc (libstdc++), clang (libc++) and visual
studio up-to vs2013. In visual studio 2015 the tuple_element utility is
implemented so that it can be instantiated with any type. For 'correct'
instantiations it gives the expected result. For all other instantiations it
triggers a static_assert 'tuple_element index out of bound'. Often this is a
useful error message (e.g. when asking for the 4th element in a tuple with only
two elements), but in our case it prevents SFINAE from working (because
tuple_element can now be instantiated with anything).
So again, it's not clear to me whether the visual studio 2015 implementation is
conforming to the c++ standard. According to this it isn't
http://en.cppreference.com/w/cpp/utility/tuple/tuple_element
but that's not an authoritative source. And I didn't check the actual standard.
--
This patch changes the implementation of our LessTupleElement utility to no
longer require std::tuple_element. Instead we now need c++11 variadic
templates. Fun fact: LessTupleElement was originally implemented without
variadic templates because an older version of visual studio didn't support
those yet.

Download: OpenMSX Git (2015/09/20) x86
Download: OpenMSX Git (2015/09/20) x64
Source: Here