OpenMSX Git (2017/04/02) 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:
* Make DeltaBlock-compression handle changing blob-sizes
This fixes an assert when using certain .dmk disk images.
When creating an in-memory savestate, we delta-compress the binary blobs (e.g.
the content of the RAM). Because most often only a fraction of the blob has
changed between two consecutive savestates, and we gain both speed and reduce
memory usage by only storing the difference.
Before this patch, the code didn't expect the size of the blob to change from
one savestate to the next. (E.g. the size of the RAM always remains the same).
But it can happen when serializing a RawTrack class. Typically the size of a
track is 6250 bytes, but when using .dmk images that were extracted from a real
disk, there can be some variation in the exact size.
Fixed by identifying the blobs not only on their location in memory (a pointer)
but also on their size. That is if a blob changes in size we now see it as a
separate entity, so we don't attempt to calculate difference with the previous
smaller/bigger blob.
* Small improvements on record_chunks_on_framerate_changes
- bug fix: missed variable statement in main command proc
- inlinded 'disable_watchpoint' proc, as it was only used once and very short
- demand the -prefix option to prevent the user from making a mistake with this
(i.e. getting all videos with the same name, overwriting each other)
- made texts a bit more consistent
* Added record_chunks_on_framerate_changes command.
Thanks to BiFi and FiXato for writing the original script in
https://www.msx.org/news/emulation/en/frame-rate-record-script-openmsx
* More detailed timing for write-to-disk emulation on WD2793
This fixes writing sectors with CRC errors in dsk-pro. Actually it already
worked fine before this patch on machine with a Philips WD2793 connection
style, but not yet on machines with a Microsol connection style.
Some background info. When the WD2793 executes a write-sector command, it will
first locate that sector in the track, so it searches for the sector header.
After that header is found (and after some short pause) the WD2793 will write
some synchronization bytes (12 x 0x00) and the start of sector-data-marker (A1
A1 A1 FB). Then it writes the actual sector data (typically 512 bytes). And at
the end it writes 2 CRC bytes followed by one final 0xFE byte.
Before this patch the emulation of these write were executed in 3 chunks:
pre-data, data and post-data. All the writes in the pre- and post-parts were
emulated atomically. That is from an emulation-time point of view during most
of pre and post period there are no writes, only at the end of the period the
writes for that period happen all at once. Only during the actual data period
the writes were emulated at (mostly) the correct time, so 512 individual writes
instead of 1 atomic batch of 512 writes.
This patch improves the emulation so that also the bytes in the pre and post
period are handled individually.And the exact timing of the writes in the data
period has also improved.
Normally this difference in timing doesn't matter at all. However in dsk-pro we
have the following scenario:
- Dsk-pro starts a write-sector command.
- It writes the 512 data bytes (or whatever the length of the sector is).
- But shortly after the last data byte is written, the disk-drive motor is
turned off (actually the drive is (also) de-selected).
- The idea is that the 2 CRC bytes don't get written, and you get a sector with
a CRC-error (with high likelihood).
- Soon after the motor was turned off, it gets turned on again. On Philips
machines the duration that the drives is off is 234 Z80 cycles. On Microsol
machine that duration is only 213 cycles (because dsk-pro needs different
code paths for both of course).
- A 3.5" disk rotates at 300rpm and the data-rate is 250kbps, so the duration
of 2 bytes on disk is 230 Z80 cycles. So on Philips machines the motor-off
period is slightly more than 2 bytes, while for Microsol it's slightly less.
- This timing difference (together with some implementation details of the old
implementation which I won't go into now) caused writing CRC errors to work
on Philips but not on Microsol.
- That's because on Microsol, in the post period, when the emulation actually
wanted to write the CRC bytes the motor was already turned on again (remember
the old implementation wrote all bytes of the post period atomically at the
end of the period).
After this patch the timing of the writes is much more accurate, so the
CRC-error trick keeps working with the shorter motor-off Microsol timing.
And as a bonus, this patch also makes the timing of the write-track command
byte-accurate.

Download: OpenMSX Git (2017/04/02) x86
Download: OpenMSX Git (2017/04/02) x64
Source: Here