| |
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 |
|
... 56 posts hidden. Click here to view all posts....
|
| |
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: 3194 |
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: 3194 |
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 |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
