Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


Code (openMSX) Log

Commit Date  
[15dd2d] by Manuel Bilderbeek Manuel Bilderbeek

Use the Yamaha SFG-01 in the Yamaha CX5M machine. This conforms to the first series of the machine. The CX5MII/128 machine already has the SFG-05. With the SFG-01 built in the Digital Music System software also runs on the CX5M.

2013-09-28 18:47:56 Tree
[0b00be] by Manuel Bilderbeek Manuel Bilderbeek

Fixed remaining reference to Subversion.

2013-09-23 19:59:27 Tree
[3fcbc0] by Manuel Bilderbeek Manuel Bilderbeek

Updated setup guide after Wouter's comments and did some general updates as well.

2013-09-23 11:30:44 Tree
[2bc830] by Manuel Bilderbeek Manuel Bilderbeek

Update Setup Guide for hardware configuration files without subdir.

2013-09-20 20:04:47 Tree
[728325] by wouter wouter

Fix lazy tcl scripts in directory-name with spaces

Executing a 'lazy' Tcl script went wrong when it was located in a directory
which has space(s) in its name.

Fixed by properly escaping the arguments in the 'namespace eval' command. I
also quickly reviewed all other uses of 'eval / namespace eval' and all seems

2013-09-18 19:30:22 Tree
[8b7c90] by wouter wouter

Made the MSXYamahaSFG device 'debuggable'.

BiFi reported that the content of the MSXYamahaSFG device wasn't visible in the
debugger (in the 'memory' or 'slotted memory' view). This was because that
device didn't implement peekMem(). So this patch does implement peekMem(),
together with readCacheLine() and writeCacheLine().

2013-09-11 17:22:10 Tree
[b69f5c] by wouter wouter

Added setting 'touchpad_transform_setting`

This allows to specify a 2x3 matrix that transforms the host-mouse-coordinates
to MSX-touchpad-coordinates. More in detail:
| touch-X | | a b c | | host-X |
| touch-X | = | a b c | * | host-Y |
| 1 |
This allows to either:
- allow to access the full 256x256 touchpad resolution
- align touchpad to msx pixels
- .. any (affine) transformation you can think of (rotate, scale, translate,

The default matrix {{256 0 0} {0 256 0}} simply maps the full host window
to the full touchpad range. TODO we should provide some convenience Tcl scripts
that setup this matrix for various MSX applications (e.g. so that touchpad
input is aligned to MSX pixels).

2013-09-09 15:16:10 Tree
[8af6b5] by wouter wouter

Another Tcl command-verifier fix

Entering tas mode triggered an error:
> set mode tas
can't set "mode": invalid command name "tas::space_read"
Activating tas mode (indirectly) sets a watchpoint with as command
'tas::space_read' and the command verifier (wrongly) rejected this.

This is a regression introduced in revision d389e46. The problem was that
'tas::space_read' is neither in the global namespace nor a lazy command:
- pre-d389e46: handled namespaces correctly, but didn't know about lazy procs.
- d389e46: handles lazy procs correctly, but is broken for (non-lazy) commands
that are not in the global namespace.
This patch should handle both correctly.

2013-09-09 14:38:52 Tree
[38824b] by Manuel Bilderbeek Manuel Bilderbeek

Remove remarks about stuff being experimental that is already in for a long time.

2013-09-08 21:01:02 Tree
[7f09d3] by Manuel Bilderbeek Manuel Bilderbeek

Document meaning of memory mapped I/O addresses.

2013-09-07 13:51:03 Tree
[dd6123] by Manuel Bilderbeek Manuel Bilderbeek

Added release years to some Yamaha products.

2013-09-07 13:51:03 Tree
[1c812b] by Manuel Bilderbeek Manuel Bilderbeek

Added Yamaha SFG-01.

2013-09-07 13:51:03 Tree
[b0736e] by Patrick van Arkel Patrick van Arkel

fixed windows compilation

2013-09-05 05:24:16 Tree
[2f638f] by wouter wouter

Basic touchpad support

It seems to work fine (only tested with PAD() in BASIC). Though the host-input
mechanism is very basic. It uses absolute mouse coordinates with (0,0) being
the top-left corner of the openmsx window. Instead we should try to map the
area so that the touchpad coordinates coincide with the MSX pixel positions.
But that's something for a later patch (I'm not actively working on it). Of
course having some touch host input device would be even better.

2013-09-03 17:32:10 Tree
[97e6bc] by wouter wouter

(Also) store absolute x/y in mouse motion events

This will be needed in the next patch.

Thus patch also simplifies the implementation of the lessImpl() methods by
using tuples. And moved the implementation of trivial getter methods to the
header file.

2013-09-03 12:32:51 Tree
[ebeb29] by wouter wouter

Fixed (in a way) bug #498 Mouse emulation lacks arithmetic saturation

Bug #498 complains that mouse X/Y-offsets aren't clipped: if you move the mouse
very fast (and/or if the MSX program reads the mouse very slowly) then a large
positive offset wraps and becomes a (large) negative offset or vice versa. Note
that in practice this will happen _extremely_rarely_.

I verified this on real HW and a real MSX mouse behaves exactly in this way.
There is no clipping done in the mouse hardware. There actually was emulation
code to handle this clipping, but because of a bug it clipped on a too large
range (so by accident it already behaved more like the real HW than originally
intended). Fixed now by completely removing the clipping code.

Also fixed a spelling error (faze->phase) and added some more comments.

2013-09-01 18:46:12 Tree
[fddca3] by wouter wouter

Fix(?) bug #477 Trackball emulation overflow values too easily

See comments in the code and the bug report for more details.
Untested, so I'm leaving the bug report open. (Please verify and close).

2013-08-31 10:57:41 Tree
[607480] by wouter wouter

Copied write-to-unused-registers behavior from Burczynski core

Writes to YM2413 registers 0x[123][9ABCDEF] actually end up 9(!) registers
lower. The Burczynski core implemented this from the start, even with a comment
that it's tested on real HW. Though because this is such weird behavior (from a
hardware point of view) I did re-test this myself (on a turbor machine).

So now it's also implemented for the Okazaki core. Though I doubt there exists
MSX software that actually makes use of this stuff.

2013-08-31 08:57:30 Tree
[e8b7c1] by Manuel Bilderbeek Manuel Bilderbeek

Added Wouter's VDP busy script.

2013-08-24 21:39:23 Tree
[6d130f] by wouter wouter

Remove CPU base class

The previous patch made CPUCore non-virtual. Because of this, the base class
(called CPU) became almost empty. The only remaining stuff was the definition
of the registers (inside the CPURegs class). Though the code structure becomes
simpler if we remove the CPU base class and instead inherit from CPURegs.

An alternative could be to not inherit from CPURegs, but instead have it as a
member variable. I choose inheritance because it allowed many small syntactic
simplifications in the implementation of the CPUCore members (and this code
is already quite complex, so every simplification helps).

Another alternative is to also remove CPURegs and instead integrate it into
CPUCore directly. This would even allow to better optimize the difference in
the handling of the 'R' register between Z80 and R800. I didn't pick this
alternative because the debugger code currently still needs to access the
registers in a z80/r800-independent way, and this is only a very small
optimization anyway (only the 'LD A,R' and 'LD R,A' instructions on R800 would

2013-08-24 16:06:11 Tree
[8bfce0] by wouter wouter

Slight CPU emulation speedup: put PC at offset=0

The PC register is the most often accessed member variable in the CPUCore
class. For each emulated instruction, this variable is accessed at least twice
(read + write), many instructions access the PC register even more. If we place
the PC variable as the very first variable in the CPUCore class, then it can be
accessed by only dereferencing the 'this-pointer' (so without first having to
add an offset to the pointer).

Practically all modern CPU architectures have addressing modes that allow to
load/store data from a register+offset in a single instruction. So at first
sight the above transformation may not seem like a win. Though on x86 if the
offset is zero, then the load/store instruction can be encoded shorter. Also
keep in mind that the Z80 PC is a 16-bit value and 16-bit load/store
instructions on modern CPUs are typically more limited than their 32-bit
counter-parts. So also on non- x86 CPUs this transformation may have benefits
(but I didn't test).

There is one hidden problem: simply putting the PC variable as the first
variable in CPUCore does not put it at offset zero. At least not when the class
has virtual methods (because then vptr is put at offset=0). So this patch also
makes CPUCore non-virtual and instead moves the dynamic dispatching to the
MSXCPU class. Because we only need to dispatch between two possible classes
(Z80 and R800) this is a reasonable transformation.

Benchmark results, only modest improvements:
- code size got about 4kB smaller
- cpu emulation got about 1% faster (on x86-64)

2013-08-24 16:06:11 Tree
[9d0677] by Manuel Bilderbeek Manuel Bilderbeek

Update required gcc version in Compilation Guide.

2013-08-24 16:03:44 Tree
[5da631] by wouter wouter

Removed workarounds for bugs in old gcc versions

Now that we use c++11 we require at least gcc version 4.6.

2013-08-24 09:59:09 Tree
[214cf9] by wouter wouter

Speedup VDP command execution / re-enable cmdtiming=broken

Revision 618ccb implemented a cycle accurate VDP command engine. But it also
caused a massive slowdown in the emulation speed of the commands. Revision
a8451e improved the emulation speed a lot, but it still remained quite a bit
slower than the old code. Rev 618ccb also disabled the 'cmdtiming=broken'

This patch re-enables 'cmdtiming=broken' and at the same time speeds up the
command engine emulation speed. Though the speed is not back at the original
level. (It can certainly still be improved, but I doubt it's possible to get
all speed back).

Some very quick benchmark results:
- command engine emulation speed is improved by a factor ~1.7x
- very much depending on what and how exactly you measure this translates to
2%-10% faster total emulation speed (for code that heavily uses VDP commands)

The main idea for the speedup is to instead of searching for the next access
slot, have a lookup table that immediately tells where the next slot is for
each possible cycle (within a display line). The total size of this LUT is about
150kB, though each command only accesses a few chunks of ~3kB continuous
memory, so it should be OK for memory cache behaviour (and benchmarks confirm
it's indeed significantly faster).

2013-08-24 09:25:15 Tree
[d389e4] by wouter wouter

Fixed Tcl command-verifier (e.g. on set_bp) and lazy loading

A command like
debug set_condition {[vpeek 0] == 0}
was no longer accepted. This was because we do some basic verification on the
given expression (and command) (useful to catch simple typos). And this failed
when the script that defines the 'vpeek' proc was not yet loaded.

Note that this bug did not trigger when interactively typing this command, only
when source'ing a script that contained this command. (Though this was actually
caused by another bug. This is also fixed in this patch).

Fixed by reusing the 'isProc' from TclParser (already used by the console to
correctly highlight names of not yet loaded procs). Reusing common code is a
good idea anyway.

There have been a lot of (small) lazy-Tcl loading related bugs lately. It seems
that implementing this feature fully correct was (is?) more difficult than I
originally thought. Though I still think it's worth the effort because it
resulted in measurable faster startup performance on Dingoo (~20%) with also
less memory usage (~1MB).

2013-08-20 09:30:09 Tree
Older >