| |
Digger
Registered: Mar 2005 Posts: 437 |
VICE (x64) hot reloading
Does anyone know a way to pass a .prg file to already running x64 instance on macOS?
I am trying to optimize the launch time after compilation, killing and respawning x64 takes some time, even with memory injection enabled. |
|
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Its not superstable but use remote monitor and the netcat in monitor args like:
echo -e bank ram\nf 0000 ffff 0\nl\file.prg\ 0\ng c000\n | nc localhost 6510
Your start code (in this case at $c000) should clear timers and ack pending irqs to increase stability |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Shouldit JAM which it will, simply run the cmd again |
| |
Digger
Registered: Mar 2005 Posts: 437 |
@JackAss: Thanks! I will check this out.
I've also found a similar thread here: http://csdb.dk/forums/?roomid=11&topicid=117433&showallposts=1#.. with some good suggestions.
And a CodeBase64 article by Compyx: http://codebase64.org/doku.php?id=base:using_a_running_vice_ses.. |
| |
oziphantom
Registered: Oct 2014 Posts: 490 |
Its in Compyx's article, but Ian's Fast Kernal really helps ;) |
| |
MagerValp
Registered: Dec 2001 Posts: 1078 |
As long as you have prg files associated with x64sc, just use:
bash$ open file.prg It'll reset and load in an already running x64sc, or launch x64sc if necessary. open basically does the same thing as double clicking a file in the Finder. |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Quote: @JackAss: Thanks! I will check this out.
I've also found a similar thread here: http://csdb.dk/forums/?roomid=11&topicid=117433&showallposts=1#.. with some good suggestions.
And a CodeBase64 article by Compyx: http://codebase64.org/doku.php?id=base:using_a_running_vice_ses..
My "injection" method, while a tiny bit unstable, gives you instant test turn around. I've added an inject-target in my Makefile and directly from Sublime assemble and inject then alt-tab to Vice for immediate check. It's a really sweet and fast setup. |
| |
Perplex
Registered: Feb 2009 Posts: 255 |
I'm using this bash script to communicate with x64sc through the remote monitor:
#!/bin/sh
# Reload program and label definitions into a running x64sc session
# Send command to emulator's remote monitor
send () {
echo "$1" | nc -N localhost 6510 >/dev/null
}
# Verify command line parameters
if test "$#" -lt 2; then
echo "Usage: $0 <program-file> <labels-file> [start-address]"
exit 1
fi
PROGRAM=$1
LABELS=$2
ADDRESS=$3
# Reset emulator
send "reset"
# Wait a bit for reset to finish when starting via RUN
# Assumes a kernal patched to bypass memory test
if ! test -n "$ADDRESS"; then sleep 0.1; fi
# Load new program file into memory
send "load \"$PROGRAM\" 0"
# Update labels
send "clear_labels"
send "load_labels \"$LABELS\""
if test -n "$ADDRESS"; then
# Start using supplied address
send "g $ADDRESS"
else
# Start by issuing RUN command using keyboard buffer
send "f 0277 027a 52 55 4e 0d"
send "f 00c6 00c6 04"
fi
Like it says in a comment, you need a kernal patched to bypass the memory test on reset (which is useless in an emulator anyway),
otherwise you'll have to extend the sleep delay argument to at least a couple of seconds. You can find info about patching the kernal
and loading code into a running emulator here: http://codebase64.org/doku.php?id=base:using_a_running_vice_ses.. |
| |
Kruthers
Registered: Jul 2016 Posts: 21 |
Quote: As long as you have prg files associated with x64sc, just use:
bash$ open file.prg It'll reset and load in an already running x64sc, or launch x64sc if necessary. open basically does the same thing as double clicking a file in the Finder.
I'm assuming that works on the mac b/c "finder", would love to find a way to do this under linux. Tried for hours one day to figure out how to script a "drag and drop" into an already-running vice but to no avail... |
| |
soci
Registered: Sep 2003 Posts: 480 |
I use this in Makefiles usually. It does an autostart through remote monitor or starts a new VICE if it's not listening yet. Of course everything is directly runnable or can be compiled so for testing.
XFLAGS := -autostartprgmode 1 -autostart-warp +truedrive +cart -remotemonitor
all: demo
-echo 'autostart "$(PWD)/$<"' | nc 127.0.0.1 6510 -q 1 2>/dev/null >/dev/null || (x64 $(XFLAGS) $< </dev/null 2>/dev/null >/dev/null) &
|
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
noone made a codenet clone for the remote binary interface yet? why? |
| |
Frantic
Registered: Mar 2003 Posts: 1648 |
My guess is that this is because you sort of have to be a VICE developer to even be aware of it. With that said I guess it may be a really good idea though.
Also, a bit off topic as it doesn't relate to VICE, but I just wanna mention that there is a special version of the 1541U2 firmware out there somewhere that allows you to send code straight into C64 ram, and do things like remotely resetting the C64, over ethernet. I find it very useful so I just wanted to mention that, as I guess people aren't widely aware of it. I use it from macOS. |
| |
Fred
Registered: Feb 2003 Posts: 285 |
Quoting Perplex
# Load new program file into memory
send "load "$PROGRAM" 0"
@Perplex: Thanks for your post. In order to load a program that loads at address $D000-$DFFF you need to set the bank to ram before loading it, like:
send "bank ram"
send "load "$PROGRAM" 0"
send "bank rom" |
| |
oziphantom
Registered: Oct 2014 Posts: 490 |
Quote: noone made a codenet clone for the remote binary interface yet? why?
Because the Binary interface only has 1 thing in it. And it lets you grab data from VICE not put data into VICE. To which our remote debuggers are probably the only thing to use it at the moment. Once Hunters Moon is done, I have a list of things to add the binary interface so I can improve the debugger. If you have anything in particular you want let me know.
Binary Upload
Binary Register
Binary Memory trace
Binary Breakpoint setting
Binary Breakpoint triggered
Binary Breakpoint control
Binary Bank
Is the current list. |
| |
Martin Piper
Registered: Nov 2007 Posts: 722 |
Yeah, at the moment we have to have a nasty mixture of binary query and the other mostly text based monitor commands to be able to do useful stuff. Plus the weird connection problems causing lots of slow down and flickering of the windows don't help. |
| |
MagerValp
Registered: Dec 2001 Posts: 1078 |
Quoting oziphantomBinary Upload
Binary Register
Binary Memory trace
Binary Breakpoint setting
Binary Breakpoint triggered
Binary Breakpoint control
Binary Bank
Trigger reset.
Jump to address.
Read I/O state without side effects like acking IRQs. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
Quote:Because the Binary interface only has 1 thing in it. And it lets you grab data from VICE not put data into VICE.
sure. and it'd take almost a couple minutes to add binary upload?
making a list doesnt help btw. i also already know exactly what it would need, it wouldnt be the first remote debugger thing i am writing :) |
| |
oziphantom
Registered: Oct 2014 Posts: 490 |
The list isn't for you, the list is for me ;) |
| |
Perplex
Registered: Feb 2009 Posts: 255 |
Quote: Quoting Perplex
# Load new program file into memory
send "load "$PROGRAM" 0"
@Perplex: Thanks for your post. In order to load a program that loads at address $D000-$DFFF you need to set the bank to ram before loading it, like:
send "bank ram"
send "load "$PROGRAM" 0"
send "bank rom"
@Fred: Good call, thanks! |