| |
Compyx
Registered: Jan 2005
Posts: 631 |
VICE: attach disk image and run .prg file from OS filesystem
With VICE (2.4.27 on Linux), I'm trying to figure out how to attach a D64 image to drive 8 (with TDE) while running a .prg file from my OS file system.
I've tried a wide variety of command line options, but I either get a message about extra arguments on the command line, or VICE tries to load the .prg file from the attached disk image, which obviously fails as well.
Does anyone know how to do this? I'm trying to keep my assemble-run-debug cycle as fast as possible.
/Compyx |
|
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
why not inject that prg into the d64 as well? |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
That was my next option. I think c1541 is fast enough for that. I was just curious why VICE doesn't seem to allow this. I've looked through all the command line options (thank fuck for `less`), but no luck so far.
I'm probably trying to do something backwards, as usual ;) |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
Because when you're loading a prg from host filesystem Vice is already faking a virtual device 8 (prg will turn virtual device traps on and true drive emulation off), and you can't have both a virtual and "real" device 8 at the same time.
You can simply build your d64 with the needed files prior to launching vice. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I just did, and that works fine. Although VICE seems to have the `autostart-handle-tde` options backwards:
-autostart-handle-tde
Handle True Drive Emulation on autostart
+autostart-handle-tde
Do not handle True Drive Emulation on autostart
When I use `+autostart-handle-tde` VICE uses TDE to load my file, which takes quite a while for a 202 blocks file (even with warp). When I use `-autostart-handle-tde`, TDE is skipped and my file is loaded pretty much immediately.
Normally VICE uses +<option> to invert that option's behaviour, or am I slowly going insane? ;) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
the + - owls are not always what they seem |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Indeed. Well, at least I got the stuff working the way I wanted.
Can't find any weird stuff in the VICE sources when it comes to handling those autostart settings after a quick glance. Seems to behave the way the docs state, just not when actually running VICE. |
| |
markus sinalco
Account closed
Registered: Sep 2005
Posts: 112 |
btw, is there any ".d64 Editor" for linux based systems ?. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Not that I'm aware of.
I'm working on one, already got most of the backend working (C library that handles D64, D71, D81, T64, ARK, ZipCode and a few other images/containers). Just need to decide on a GUI toolkit for the frontend, I'm probably stuck with Gtk3 since Qt needs C++, and I really don't like C++.
You could always use c1541 which comes with VICE, but that's of limited use if you want to do BAM manipulation or dir art. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quoting markus sinalcobtw, is there any ".d64 Editor" for linux based systems ?.
If you mean a tool to create .d64, CC1541 works as well:
http://csdb.dk/release/?id=69964&show=goof#goof
Take a look at the goofs! |
| |
Hypnosis
Registered: Mar 2015
Posts: 36 |
Quote: btw, is there any ".d64 Editor" for linux based systems ?.
DirMaster works in Wine. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: Quoting markus sinalcobtw, is there any ".d64 Editor" for linux based systems ?.
If you mean a tool to create .d64, CC1541 works as well:
http://csdb.dk/release/?id=69964&show=goof#goof
Take a look at the goofs!
People actually use that? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting CompyxPeople actually use that? Obviously. And why shouldn't they? It creates disk images optimised for demos, while C1541 emulates the KERNAL save behaviour, which is not suited so well for demos. And yes, similar tools exist, and everyone who can rolled their own. But still... (My loader comes with its own incarnation of CC1541, Jackasser and i are still bickering over the details of the merge settlement. Well, not really :D) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
That, I understand, fastloaders need a different sector interleave and such. I guess I was a bit surprised by the code itself, such as calling strlen() in a loop and an uncomfortable mix of C and C++.
I'm pedantic, I know ;) |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting CompyxI'm trying to keep my assemble-run-debug cycle as fast as possible.
I can recommend the use of snapshot files combined with the remote monitor. As the final steps in your build pipeline, inject the updated code and/or data into the snapshot (very straightforward to do), then send commands to the remote monitor of the running emulator to reload the snapshot and jump to the start of your code:
echo 'undump "snapshot.vsf"' | nc localhost 6510
echo 'load_labels "labels.txt"' | nc localhost 6510
echo 'goto .Start' | nc localhost 6510
I don't think it's possible to detach/reattach a disk image using the monitor though, so if you need to do that you must do it manually in the emulator or make your build system kill and restart the emulator when necessary. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i dont recommend using snapshots for development - as the whole snapshot thing is highly complex and almost impossible to test properly, you'll get unexpected results sooner or later....
and yes, attaching a disk in monitor is possible:
$ attach disk.d64 8 |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting Groepazi dont recommend using snapshots for development - as the whole snapshot thing is highly complex and almost impossible to test properly, you'll get unexpected results sooner or later....
Build by copying then modifying a known working base snapshot image, and you should be fine. Works well for me, at least.
Quoting Groepaz
and yes, attaching a disk in monitor is possible:
$ attach disk.d64 8
Duh, I must have been looking at the documentation for an old version, didn't notice that. Thanks! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
its not an undocumented feature at all (try "help" in the monitor, for example :=))
Quote:Build by copying then modifying a known working base snapshot image, and you should be fine. Works well for me, at least.
the problem is that snapshot loading alters the entire machine state - and how it does that exactly. the only way to have a defined proper machine state after it is resetting the machine.
i went through a couple iterations of different ways of starting my binaries in emu - and now i am back to plain old autostart, and that with enabled "copy file to d64" - because everything else gave me unexpected results at least once. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
It very seldom leads to unexpected results that are not obviously wrong, though. In which case a simple rebuild will solve it. It works close to 100% of the time, and lets me see the results about .1 seconds after I start building. If it fails a rebuild helps in most cases, and if not I can always quit the emulator and start normally. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:It very seldom leads to unexpected results that are not obviously wrong, though.
really depends on what you are doing. and it may not be so obviously wrong afterall - and thats when the trouble starts. i gladly trade a second wait time for that uncertainty :=) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I'll stick to injecting my program into a disk image with other test files and then running VICE. I need a 'clean' machine state to properly test my code. My code does a lot of IRQ setup/teardown and $01 manipulation (it's a custom graphics editor)
I'll check out the remote monitor feature, might be interesting if I can get it to work from within VIM. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
Check this article I wrote a while ago, should be useful in your case, it's got d64 creation in the full example.
http://codebase64.org/doku.php?id=base:cross_development_using_.. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I already read that article a while ago ;)
My makefile looks similar to the one in the article, including image creation with c1541. I'm skipping the exomizer bit for now, both crunching and decrunching take way too long for a fast assemble-run-debug cycle. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
thats why i use pucrunch while deving :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Didn't try that one. I'm going to assume it's faster than exomizer. Exomizer is as fast as shit going through a coffee filter (Dutch figure of speech). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yes, it packs a LOT faster (instant on my box) and depacking is also a bit quicker.
that said, i wonder why noone made a simplier (crossdev)packer that is optimized for speed only (and the only purpose would be being able to make RUNable programs from stuff that loads outside 0801-cfff). something to put on the never ending TODO list, i guess =) |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
simple crossdev packer? cld by tlr
cbmtools 0.6 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yay, missed this. thx :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: simple crossdev packer? cld by tlr
cbmtools 0.6
I'll assume you're talking about pucrunch.
Personally I've found that simply injecting a 202 blocks file into VICE (or a d64 image) is a lot quicker than whatever crucher/decruncher solution. Even RLE doesn't beat loading the full data while skipping TDE. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
as long as 202 blocks works, sure - however in demo you often want to use d000-ffff too, and then the problem starts :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Well, I'll handle that when I need to. Already have something planned that's going to need the full 64K stuffed with data, so it might be sooner rather than later.
In the old days I would simply code in the ML monitor of my cartridge when I needed all the memory, which is something I'm going to avoid at all cost ;) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting CompyxThat, I understand, fastloaders need a different sector interleave and such. I guess I was a bit surprised by the code itself, such as calling strlen() in a loop and an uncomfortable mix of C and C++.
I'm pedantic, I know ;) Granted, it's not pretty. Just a tool quickly hacked together to do its job. And at some point it will read and write that 50x fastload format i have yet to actually turn into working code. :)
But back on topic: Wouldn't it be possible to pipe commands and files into a running VICE instance, such as a reset-load-run combination? For me, VICE startup times themselves feel pretty long already, no matter if auto-running a program or not. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I think the remote monitor feature of VICE could be useful, I haven't looked into that yet. If I could inject the new code and data into a running VICE instance from VIM (:make x64) that would seriously cut down on start-up time.
The assembler I use is very fast (64tass), c1541 is also pretty quick, starting VICE is the biggest bottleneck.
Guess I'll have to grep my way through the gazillion command line options x64 has ;) |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
long time on startup is mostly taken by the ram test at $fd50. use a cart like TFR or patch your kernal rom like this (fc /b output)
00001D60: 3C 00
00001D69: 03 9F |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: long time on startup is mostly taken by the ram test at $fd50. use a cart like TFR or patch your kernal rom like this (fc /b output)
00001D60: 3C 00
00001D69: 03 9F
Please forgive my ignorance, but what is TFR, my guess would be something like 'the final replay'? |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
exactly that |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Yup, a google search had already answered my own question ;)
I will check it out after I come back from work.
I also managed to get the remote monitor working, with telnet I can inject data into memory, attach disk images, and much more.
Some serious hacking for a simple graphics editor :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
After putting together some of the advice here, I managed to come up with a solution that works for my specific use case:
* Edit with, and run make from, VIM.
* Inject prg file(s) into VICE, attach disk images, start prg
* Edit source, rebuild and run
All this with VICE running as a 'server'
Part of my Makefile now looks like this:
ASM=64tass
ASM_FLAGS=-C -a -I src -I data
X64=/usr/local/bin/x64
TARGET=bdp6.prg
$(TARGET):
$(ASM) $(ASM_FLAGS) -o $(TARGET) src/main.s
c1541 -format bdp6,focus d64 bdp6.d64 -write $(TARGET)
c1541 -attach bdp6.d64 -write data/sentinel-bob.koa sentinel.koa
c1541 -attach bdp6.d64 -write data/druid.ami "[b]druid"
inject: $(TARGET)
echo 'l "bdp6.prg" 0' | nc localhost 6510
echo 'attach "focusgfx.d64" 8' | nc localhost 6510
echo 'g 080d' | nc localhost 6510
.PHONY:
session:
$(X64) -remotemonitor -chdir `pwd`
I had to install the 'vim-dispatch' plug-in to get asynchronous behaviour for VIM when running :make (actually :Make!)
So now I just do (inside VIM):
# just once:
:Make! session
# every time I need to run my code:
:Make! inject
That `:Make! inject` now takes less than a second, including assembling my code and generating the d64.
Of course the Makefile needs some cleaning, but I got a very quick assemble-run-debug cycle. Even quicker when I remap some keys in VIM ;)
So thanks guys, I just managed to turn VIM into something of a C64 IDE.
Edit: well, it almost works, need to find a way to stop/reset the emulation before injecting data and running it. Perhaps a custom kernal to speed up the 'reset' command. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Didn't try that one. I'm going to assume it's faster than exomizer. Exomizer is as fast as shit going through a coffee filter (Dutch figure of speech).
Use the -m flag with a small value to speed up exomizer significantly (at the cost of compression efficiency):
$ time exomizer sfx 0x1000 -q -o test.exo efloader.prg
real 0m2.120s
user 0m2.097s
sys 0m0.019s
$ stat -f %z test.exo
23203
$ time exomizer sfx 0x1000 -q -m 4096 -o test.exo efloader.prg
real 0m0.732s
user 0m0.722s
sys 0m0.007s
$ stat -f %z test.exo
24176
$ time exomizer sfx 0x1000 -q -m 256 -o test.exo efloader.prg
real 0m0.487s
user 0m0.476s
sys 0m0.009s
$ stat -f %z test.exo
26778
Decrunch is still slow, but I'm too lazy to keep two packers around. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Wouldn't it be possible to pipe commands and files into a running VICE instance, such as a reset-load-run combination? For me, VICE startup times themselves feel pretty long already, no matter if auto-running a program or not.
like a codenet -like program that uses the remote monitor interface? yeah, i also wonder why noone did that yet, its trivial afterall :) |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting Groepazas long as 202 blocks works, sure - however in demo you often want to use d000-ffff too, and then the problem starts :)
Works fine with option -autostartprgmode 1 |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Well, after adding `echo 'g fce2' | nc localhost 6510` before any load commands to my Makefile, everything seems to work fine.
When I issue 'reset 0' (soft reset) through the remote monitor using netcat I need to `sleep 3` to allow the reset to finish, otherwise VICE hangs on subsequent monitor commands.
Never knew how easy it was to use the remote monitor ;)
And -autostartprgmode 1 does indeed work with files over $cfff, so that takes care of the $d000-$ffff problem. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
however, injecting to RAM does introduce its own set of quirks. been there :) |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
You should be able to do a reset without sleep (or at least with a much shorter sleep duration) using a patched kernal like iAN CooG described in post #34. |
| |
Slajerek
Registered: May 2015
Posts: 63 |
You can use my just released C64 Debugger, I copy PRG directly to RAM not using virtual devices there.
Something like this should work:
C64Debugger -prg "full path to file.prg" -d64 "full path to disk image.d64" -jmp x0810 -wait 500
Will wait 500ms to ensure kernel settle, then attach disk, then load PRG into RAM and finally JMP to $0810.
By the way I have included a patch for fast kernel boot, but forgot to add command line setting :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Looks promising, I'll check it out.
But what I'm after is controlling VICE from my editor of choice, VIM, without having to boot x64 every time I change some code. I now have that working using a Makefile, netcat, telnet and a VIM plugin. Still need to patch the kernal like iAN suggested though for quicker reset.
So far it's working fine, but I still kind of expect it to blow up in my face at any moment ;) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
After patching the kernal like iAN suggested, I now have an assemble & run time of less than a second. Pretty sweet!
If it still works fine after a few days, I might as well put my findings in an article on codebase64. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
After playing around with the remote monitor some more, I noticed that by ignoring the BASIC interpreter, any code I run that doesn't set up IRQ's results in the code executing with a nice blinking cursor on screen (the BASIC interpreter's IRQ is still in edit mode).
This of course has to do with skipping the interpreter, so I now inject a BASIC program with the remote monitor and set the proper pointers in $2b/$2c (can probably be omitted) and $2d/$2e. I can now LIST the program and RUN it in VICE. But I don't seem to be able to find the correct location in BASIC/KERNAL to execute a proper RUN from the monitor.
So my question is, how do I properly hook into the BASIC interpreter so I can RUN a program as if I typed 'RUN' and, after executing my program, get the interpreter back in edit mode? |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
jsr $a659
jmp $a7ae |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Compyx: Yes, please write something about it for Codebase! Should go into the cross development part of the wiki I suppose:
https://codebase64.org/doku.php?id=base:crossdev |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Nope, I get a nice READY prompt, but my program isn't executed, nor is it there any more when I do a LIST.
You might be onto something though, I don't get stuff like ?undef when I tried jumping straight into the handlers for GOTO, GOSUB and RUN. Probably need to set a few more pointers. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: Compyx: Yes, please write something about it for Codebase! Should go into the cross development part of the wiki I suppose:
https://codebase64.org/doku.php?id=base:crossdev
I will, already working on it mentally ;) |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
well I dunno mate, I was just guessing ;)
but why all the basic-fuckage? |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I enjoy it :)
Well, not really. Basically (pun intended) I need VICE to act as if it was doing an auto-start, without actually doing an auto-start since I use a running VICE session, if that makes any sense.
My VICE session works fine with 'demo' code: code that sets up IRQ's and never returns. The problem is code that returns to the interpreter and doesn't alter IRQ's. Since I inject code into VICE and use a 'g $xxxx', BASIC has no idea I just executed a program and remains in interactive mode. With a bloody blinking cursor as result, even for 'jmp *'. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
if you want to behave it like autostart, then you HAVE to issue a reset, and then load/run the program (eg by putting the respective commands into the keyboard buffer). anything else will behave subtle different (unless you put massive effort into putting the machine into the same state). |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Using the keyboard buffer might just work! Last time I did that was in Fisher-Price OS, and since BASIC V2 is also made by that same company, who knows? ;) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Amazingly, filling the keyboard buffer with 'RUN\r' and setting its length to $04 works.
My little BASIC program executes and returns properly.
Thanks Groepaz! |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Right, put my findings so far into an article on codebase64:
http://codebase64.org/doku.php?id=base:using_a_running_vice_ses..
Unfinished as of now. Any comments and (constructive) criticism are welcome. Especially the Makefile stuff can do with some optimizing, but I didn't want to alienate readers with too much variable substitutions and other make features, it should be readable even for people just above 'lamer' level. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
nice article :) I didnt know about xxd yet, nice!
# x64 binary
X64 = /usr/local/bin/x64
# Assemble program and output VICE labels file
demo.prg: demo.s
$(X64) -a -C -o demo.prg demo.s --vice-labels -l labels.txt
uhh, u compile with vice? :P |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Haha, good catch. Some parts of the Makefile snippets I copied from various projects, some I just typed in when writing the article, that one is obviously the latter case.
Should be $(ASM) of course, I'll change that. The article isn't finished yet, the Makefile bits need some cleaning and testing, as you've discovered ;) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I also noticed that setting the BASIC begin/end pointers isn't needed when loading a file. VICE does that, the problem was my 'reset 0' command followed by 'l demo.prg': Even with a patched kernal the reset still runs while the program is loaded, resulting in the reset doing a 'NEW' of sorts after the program has already loaded.
Using `netcat -q 1` to tell netcat to wait one second after EOF from VICE makes the load command work properly.
Wonderful feature, that remote monitor, you just have to be very careful. Good fun :) |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Nice writeup! This is very close to my own workflow.
I have never had a need of adding a delay between doing a reset and loading a new prg into memory. How often does not having a delay cause problems for you? Strange that I haven't seen it if it happens quite often, since I have used it with prg files large and small hundreds of times without any issues.
If you do need a delay, reset with the patched kernal is so fast it would probably be sufficient to do a "sleep 0.1" after (the -q option to nc doesn't seem to allow decimal numbers.) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Doing a reset and loading a program doesn't cause any problems as long as you don't load and run a BASIC program, or any program that doesn't rely on proper BASIC intialization.
The problem starts with code that relies on BASIC pointers being correct. Even with a patched KERNAL, issuing a 'reset' and a 'load' fails:
When I issue a 'reset 0', the machine calls the reset at $fce2.
Immediately I load my 'foo.prg' program.
Reset is not finished yet, so when it finishes at some point, it invalidates any BASIC pointers you may have set. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
I see. Does it still need to wait anywhere near as long as a second, though? Better safe than sorry I guess, but still. :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Well. 1 second is the smallest unit telnet or netcat can handle, which works.
Smaller delays might work, but my experience tells me you're just going to get into more trouble. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
thanks for the kernal patch tip, works like a charm. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: thanks for the kernal patch tip, works like a charm.
Thank iAN CooG for that, he came up with it. And it does save a lot of time, that little patch ;) |
