| VICE TCPIP server [message #143350] |
Sat, 09 December 2006 03:03  |
|
|
Originally posted by: xlar54
Hey folks,
Ive modified VICE 1.19 to include a TCPIP server which will allow you
to connect to VICE and issue some commands like PEEK and POKE to read
and modify the emulated machine's memory. I have a project that Im
working on to create a PC development environment to step through, and
debug BASIC code, and needed a hook into VICE for it. I can see other
uses for it as well, and was interested in your thoughts. Having access
in real time to VICE's "inards" makes for some interesting integration
projects. For example, one could write a C# or VB (or any other
language) application that automatically imports a text BASIC program
into the 64 or 128's keyboard buffer and tokenizes it. Or (for whatever
reason) network an emulated 64 with an emulated 128. Any command we
want could be added.
Let me know your thoughts.
Thanks
|
|
|
|
| Re: VICE TCPIP server [message #143351 is a reply to message #143350] |
Sat, 09 December 2006 12:20  |
iAN CooG
Messages: 613
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
xlar54 <scott.hutter@gmail.com> wrote:
> Ive modified VICE 1.19
Just for curiosity: current version is 1.20, there was a particular reason
to apply your mods to the previous one?
--
-=[]=--- iAN CooG/HokutoForce ---=[]=-
RAM = Rarely Adequate Memory
|
|
|
|
| Re: VICE TCPIP server [message #143353 is a reply to message #143351] |
Sat, 09 December 2006 23:21 |
|
|
Originally posted by: xlar54
I already had the source code for 1.19, so I just worked from it. The
code for the server is modular though, and can be moved up to 1.20.
Just haven't downloaded the new version source yet. BTW, Ive sent off
an email to the vice team to see if they'd be interested in including
this in an upcoming version. Id like to see something like this as
part of the project because I can alot of interesting uses for it.
iAN CooG wrote:
> xlar54 <scott.hutter@gmail.com> wrote:
>
>> Ive modified VICE 1.19
>
> Just for curiosity: current version is 1.20, there was a particular reason
> to apply your mods to the previous one?
>
> --
> -=[]=--- iAN CooG/HokutoForce ---=[]=-
> RAM = Rarely Adequate Memory
|
|
|
|
| Re: VICE TCPIP server [message #143354 is a reply to message #143353] |
Thu, 14 December 2006 01:33 |
|
|
Originally posted by: xlar54
For those interested, Ive pushed the executable out to
www.commdore128.org. You can get it here (you may have to log in
first):
http://landover.no-ip.com/128/olate/details.php?file=984
With it, you can connect to VICE, via port 6400, and issue the
following commands:
peek <memlocation>
poke <memlocation> <value>
mem <startinglocation> <endinglocation>
quit
help
Try it out, and let me know your thoughts. Be sure to read the readme
file first.
|
|
|
|
| Re: VICE TCPIP server [message #143355 is a reply to message #143354] |
Thu, 14 December 2006 12:29 |
christianlott1
Messages: 1852
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
xlar,
Is there a way to go about Listening or Watching a memory location?
Would be very useful. Right now I'd need to keep peeking the location.
Maybe being able to open up an extra set of ports to listen for
changes:
listen <port> <memory location> [<byte value>]
- where byte value is optional parameter, maybe an array of values to
listen for at that address.
Simply having a
listen <port> <memory location>
would be good enough since I could use it to wait for a change then
evaluate it on my side. I am just thinking of listening directly to $CB
and registering it as a <keydown>.
Thanks,
Christian
|
|
|
|
| Re: VICE TCPIP server [message #143356 is a reply to message #143355] |
Thu, 14 December 2006 14:08 |
christianlott1
Messages: 1852
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Naturally I am implying with my last post that your 'peek' command
would not be as fast as pulling bytes off a dedicated socket to a
static memory location inside x64 ram.
I'd just have a loop that listens to the created port(s), debouncing
keystrokes and parsing the bytes if necessary. This would be in
contrast to issuing a steady stream of 'peek' commands then
interpreting the incoming bytes.
|
|
|
|
| Re: VICE TCPIP server [message #143357 is a reply to message #143356] |
Thu, 14 December 2006 14:24 |
christianlott1
Messages: 1852
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
christianlott1@yahoo.com wrote:
> Naturally I am implying with my last post that your 'peek' command
> would not be as fast as pulling bytes off a dedicated socket to a
> static memory location inside x64 ram.
This should have said:
"pulling bytes off a dedicated socket FROM a static memory location"
If you were able to only send CHANGES from the memory address, this
would be preferable. That would save me from sampling the port as fast
as I could and parsing all results.
I don't know what's possible and I apologize for posting three times.
Maybe this is not possible.
|
|
|
|
| Re: VICE TCPIP server [message #143358 is a reply to message #143357] |
Thu, 14 December 2006 15:38 |
|
|
Originally posted by: xlar54
Yes, this is definitely needed. Trying to think up the best way to do
it though...
Part of the problem is that Im not currently pausing the emulation. A
watch list would be easy to implement, but if a "watched" location is
frequently changing, you would get many messages out of the server
constantly. Therefore the best way would be to pause the emulation
(which means a pause and resume command). I need these commands anyway
for something else, so yeah, might as well add it.
So could you live with:
pause
- pauses the emulation
addwatch <memlocation> <operator> <value>
- pauses emulation when a memlocation condition is true (will
return an ID)
resume
- resumes the emulation
removewatch <id>
- removes a watch from the list
step
- processes the very next CPU instruction and then pauses again
These should allow you to watch for a certain value, pause the
emulation, poke to wherever you need to, then resume. Let me know your
thoughts. I don't really want to build a full fledged monitor - i
think thats overkill and the VICE team does much better at managing the
system and resources during paused emulation, but these commands might
be useful in integration projects, so lets give it a try. Will keep you
posted.
christianlott1@yahoo.com wrote:
> christianlott1@yahoo.com wrote:
>> Naturally I am implying with my last post that your 'peek' command
>> would not be as fast as pulling bytes off a dedicated socket to a
>> static memory location inside x64 ram.
>
> This should have said:
> "pulling bytes off a dedicated socket FROM a static memory location"
>
> If you were able to only send CHANGES from the memory address, this
> would be preferable. That would save me from sampling the port as fast
> as I could and parsing all results.
>
> I don't know what's possible and I apologize for posting three times.
>
> Maybe this is not possible.
|
|
|
|
| Re: VICE TCPIP server [message #143359 is a reply to message #143358] |
Thu, 14 December 2006 16:07 |
christianlott1
Messages: 1852
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
xlar54 wrote:
> Yes, this is definitely needed. Trying to think up the best way to do
> it though...
>
> Part of the problem is that Im not currently pausing the emulation. A
> watch list would be easy to implement, but if a "watched" location is
> frequently changing, you would get many messages out of the server
> constantly. Therefore the best way would be to pause the emulation
> (which means a pause and resume command). I need these commands anyway
> for something else, so yeah, might as well add it.
>
> So could you live with:
>
> pause
> - pauses the emulation
> addwatch <memlocation> <operator> <value>
> - pauses emulation when a memlocation condition is true (will
> return an ID)
> resume
> - resumes the emulation
> removewatch <id>
> - removes a watch from the list
> step
> - processes the very next CPU instruction and then pauses again
>
Yes, that's great. I would still like the ability to monitor the input
without pausing in some circumstances. Say I have a routine in the 64
that's moving some sprites around and I simply want to monitor
keypreses at $CB. I'd only want to get a message on keydown/change from
the defined watch port. I'm pretty sure I can parse keys and write to
64 memory in adequate time for my users without having to pause. I'm
just afraid if I keep pausing and unpausing any animation on the screen
(etc.) will become jerky. This is all depending on cicumstance, so I
like the idea of being able to pause but I'd also like that to be an
option and not a rule.
(I'm still trying to gather VB2005 code for asynchronous port
listening.)
See, my first insticts on this is not using it as a monitor at all! I
want the 64 to be a parallel processor and terminal for my PC so I can
program both on the PC side and 64 side and pass bytes back and forth -
hopefully without pausing emulation.
|
|
|
|
|
|
|
|
| Re: VICE TCPIP server [message #143362 is a reply to message #143361] |
Sun, 17 December 2006 15:11 |
christianlott1
Messages: 1852
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
What might be easier....
Instead of using tcp on a bunch of ports you could just pass me the
base memory address of x64 memory when I first connect. I could then be
the one responsible for polling all the addresses I needed byte to byte
instead of tcp_header&byte to tcp_header&byte.
Is there no way to attach a selectable address as an interrupt source
(on change in this case)? SW polling bites it. 64k of interrupt
sources....
|
|
|
|
| Re: VICE TCPIP server [message #143363 is a reply to message #143362] |
Sun, 17 December 2006 17:11 |
christianlott1
Messages: 1852
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
OK. I hope this is the last seemingly good idea -
This limits what can be done but it would work for me if it was
reliable:
Poll the Program Counter.
If I wanted to call a couple of procedures outside x64:
Watch: $1000
$C000 JSR $1000
.........
$1000 RTS
That is of course if you have access to the program counter and it
wouldn't slow emulation to keep checking it for a list of watch
addresses.
> From that point, there would have to be a program already waiting in
memory to accept a message. I don't know how to call a procedure from
one program to another (in this case calling .net program subroutine
from C) but that's what it would need to do in order to avoid a second
level of sw polling and be extensible.
(xlar, you still there? ;)
|
|
|
|
| Re: VICE TCPIP server [message #143364 is a reply to message #143363] |
Sun, 17 December 2006 22:44 |
|
|
Originally posted by: xlar54
Hehehe, yes, still here. Just got sidetracked with the Christmas thing.
I think I can help you with where you are trying to go - give me
another day or so and Ill let you know where we are with it.
christianlott1@yahoo.com wrote:
> OK. I hope this is the last seemingly good idea -
>
> This limits what can be done but it would work for me if it was
> reliable:
>
> Poll the Program Counter.
>
> If I wanted to call a couple of procedures outside x64:
>
> Watch: $1000
>
> $C000 JSR $1000
> ........
> $1000 RTS
>
> That is of course if you have access to the program counter and it
> wouldn't slow emulation to keep checking it for a list of watch
> addresses.
>
>> From that point, there would have to be a program already waiting in
> memory to accept a message. I don't know how to call a procedure from
> one program to another (in this case calling .net program subroutine
> from C) but that's what it would need to do in order to avoid a second
> level of sw polling and be extensible.
>
> (xlar, you still there? ;)
|
|
|
|
| Re: VICE TCPIP server [message #143365 is a reply to message #143364] |
Mon, 18 December 2006 11:37 |
christianlott1
Messages: 1852
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Another enhancement -
To find out what the instruction was that did a read or write to the
memory location. It would monitor the instruction operands.
If I wanted to monitor $1000 I could select monitor for reads, writes,
or 'on access' (reads and writes). Then program notifies by passing the
full address and instruction that did the r/w/a ( $C000 LDA $1000).
You know, whatever's easiest. I know you said you weren't looking to
replace the VICE monitor, but if you can - by all means ;)
This would usually be a pause and resume type scenario.
Depending on if the watchpoint list is dynamic....
....setup the watchpoint list in c64 memory and tcp in it's base address
(or pull it from a config file).
Not sure how useful that would be. Allows the c64 to call the shots
(more).
|
|
|
|
Members
Search
Help
Register
Login
Home
