| |
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....
|
| |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
