Re: [cc65] VICE/NESICIDE integration

On Wed, Mar 28, 2012 at 11:38:09AM +0200, Groepaz wrote:
> On Wednesday 28 March 2012, you wrote:
> > The external "debugger" (or whatever
> > we want to name it as) must know this too (also what happens with some
> > "exotic" stuffs like cartridge emulation with custom ROM, etc).
> 
> cartridges are one reason for why this can not work with shared memory in a 
> generic way - the debugger would have to know how every single emulated 
> cartridge works and access memory accordingly.
> 
> ie, even the vice builtin monitor has a hard time doing it correctly (its 
> infact still not correct in all cases).

Hmm, that was I had the idea to export all the memory, and then the external
"client" must/should issue a command which makes VICE to list "memory
mapping" based on areas. This way, maybe no need for read every byte etc,
since banking/etc pages larger memory areas usually, not bytes.

Eg, some stupid example (just for example):

monitor command: list_mem

RAM:	shm_id   rw
KERNAL:	shm_id   ro
[...]

monitor command: list_mem_mapping

E000-FFFF  KERNAL 0000 r
E000-FFFF  RAM    E000 w

So the first command lists all memories, this should not change unless VICE
is reconfigured to emulate different HWs, or restarted to have other SHM
ids, whatever.

The second can change, it is used to query memory configuration:

The first is the "C64 memory address range", the second is a reference for
the memories, the third is the offset within that memory, and the last field
is the access type the information is valid for.

This looks really ugly, but still, it's maybe faster then quering the memory
all the time with memory dumping monitor command and parsing the output.

However I am not sure it's a good idea: what happens if memory mapping is
changed, and monitor hasn't queried the memory mapping state since the last
yet. Maybe a better way is to eliminate at least the second command, and
export that data via SHM too! SO it's always availbale! Only some race
condiition can occur here, that external debugger client can use that
information than doing the r/w in the memory while memory mapping is changed
by the program run by VICE between these two steps.

According to these examples, using SHM would mean that VICE can "export"
their internals which can be used by the client any time.

Anyway, it seems to be a bit complex solution, maybe it's even similier and
faster to extend remote monitor protocol for quering information returned
in raw byte stream, it's still true that SHM memory is faster to use, but
since you need to know mapping information etc, I am not sure it will be
faster than, and at least it's quite complex task then ...
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.