Re: [openMSX-devel] Found some showing stopping errors

[David H. <dh...@sc...>]

On Mon, Sep 22, 2008 at 07:46:30PM +0200, Wouter Vermaelen wrote:
> David Heremans wrote:

*snippety snip*

> This is just the VRAM interleaving. The VRAM debuggable gives a 'stable' 
> view on the VRAM content, I mean one that doesn't change depending on 
> the VDP screen mode.
> 
> Maybe it's useful to provide another view on the VRAM that does depend 
> on the mode. But, at least for now, it's also very easy to work around 
> it in your viewer.

Ok, I  didn't know this was in effect the intended behavior.

Actually, for my viewer this is great!
One of the "advanced" stuff I was planning to was in effect seeing if it
was possible to show the effect of this interleaving when switching
between modes while assuming that the vram will not be changed only the
VDP regs. For instance between screen 0 and screen7 this has some nice
effects, a problem mth once takled in one of his demo parts.

Now that I know I have this stable vram view I get my 'advanced' option
for free :-)
So "no problemo" anymore for me with regards to my viewer.



HOWEVER,

imho we definitely need this mode-dependend-vram debugable.
If some developer is going to use the debugger to see why is program is
behaving the way it does, and he wants to see how the program interacts
with the VDP/VRAM then the result of simply writing/reading vram with
I/O instructions will not correspond to what he sees in the VRAM
debugable hexviewer (assuming he is in such a high-bandwidth mode of
course). I think one should not assume in such case that the developer
will manually re-interleave wat he sees in the hexviewer with wat he was
expecting there.
The argument that one could rewrite the hexviewer for this is imo not
valid, since the problem remains if the developer simply wants to use
the openMSX console itself, to quickly check one or two facts.

There are other things that one could think of that could benefit from
such a VDP-mode-sensitive-output, like special cheats triggered by vram
content fi. 
And trying to capture this mode-dependend behavior in some tcl
contraption seems the wrong place for it.

Well, those were my 2 cents.

rgds,

David H


-- 
openMSX - the open source MSX emulator that aims for perfection
http://openmsx.sf.net/