EmuCR Feeds
Email Us

EmuCR:OpenMSX OpenMSX Git (2017/02/12) 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:
* Fix Windows build (I hope).
* Added emulation of Tecall_MSX_RAMFILE_TM220
This is a cartridge with 16kB ROM (though 2nd half of the ROM is filled with
0xff) and 16kB RAM. The RAM is powered by a battery. It adds BASIC CALL
commands to load/save files to a small RAM disk. See manual for much more
details:
http://www.msxarchive.nl/pub/msx/graphics/jpg/hardware/manuals/
The implementation of this cartridge is relatively straight-forward, EXCEPT for
the /WE signal of the RAM. This signal is computed from 3 output bits of a
shift-register. The data-input of this shift-register is a combination of 2
data-bits of the msx cartridge slot. And the clock-input of the shift-register
is calculated from the M1 and slot-select cartridge slot signals. Short summary
(see comments in code for details): the TM220 monitors which instructions are
fetched from ROM, only after a specific sequence it allows to write to RAM.
So to emulate this cartridge correctly it's important to have an accurate
emulation of the M1 signal. See previous patch for more details on that.
Thanks to 'Quibus' and 'l_oliveira' for measuring and reverse-engineering the
TM220 hardware schematic.
'Quibus' also implemented the initial emulation of this cartridge. I only
tweaked it a little and added the M1-write-enable stuff.
* Implemented accurate M1 cycle emulation
This is a preparation for the next patch which will add emulation of the
Tecall_MSX_RAMFILE_TM220 cartridge. So far the only user of the
MSXCPU::isM1Cycle() method was RomHolyQuran2.cc, and that one was fine with a
crude M1 cycle approximation. Though for TM220 it needs to be accurate.
Roughly speaking the M1 pin on the MSX cartridge slot becomes active on every
fetch of the first byte of an instruction (and also prefix bytes, see code for
full details).
One possible implementation would be to remember the address of the last fetch
which has M1 active. The readMem() method of an MSXDevice can then check
whether the address that's being read matches with the stored M1 address. This
is a very simple change, but it does add some overhead on each emulated
instruction, and most msx devices _by_far_ don't need this information.
Instead the current implementation re-uses the existing PC register as the
address of the last M1 cycle fetch. To make this work, the PC register is now
no longer updated during the execution of an instruction but instead updated
only once at the end of the instruction. (And slightly more complex for
instructions with prefix bytes, see comments in code for details). OTOH the
real Z80 does update PC during the instruction, so to make this difference
invisible we have to be careful in instructions like CALL, RST, JR that make
use of the (updated) PC register value.
It turns out that this new implementation not only doesn't introduce any
overhead, but it is also faster than the old (less accurate) implementation! At
least when measuring the "COMPUTED_GOTO" variant of the Z80 emulation. There
emulating 16700s MSX time now takes 39.5s real time vs 41.2s before (4% faster,
420x real-time speed). When measuring the non-COMPUTED_GOTO variant the results
are less clear, there it goes from 55.4 to 55.1 (1% slower, I did repeat
measurement 5x and took the fastest result for both, but the difference is
still within measurement error margin).
The previous paragraph also shows that the COMPUTED_GOTO variant is a lot
faster than the normal variant. Currently COMPUTED_GOTO is only enabled by the
"super-opt" build flavour. The motivation for this was that older compilers
and/or machines with insufficient memory couldn't handle the COMPUTED_GOTO
variant well. Though that was 8 years ago, maybe it's time to revisit that
decision?

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



Random Related Topic Refresh Related Topic

Random Related Topic Loading...

0 Comments

Post a Comment

Can't post a comment? Try This!