| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Help me!
So I'm coding some EasyFlash stuff so most often the kernel is swapped in ($01 = #$37).
Take a look at the following chis (VICE cpu history): https://i.postimg.cc/sg9xL7xV/temp-Image-Gb-W5z-N.avif
I'm putting a CR to $ffd2 and all goes well until it hits $ed41 where the CPU fetches a JAM-instruction. How's that even possible?! The ROM can't be altered. Comparing to ROM-listings it should do a JSR $EE97 there.
There is a SEI just infront if that matters.
(Only tested in HEAD VICE and some older version like 3.6 and 3.8). Could it be an emulation bug?
((Nevermind the .arbX label, it's just my loaded labels from the assembler. In the ROM it's just BIT $94)).
It happens VERY seldom. |
|
| |
Count Zero
Registered: Jan 2003
Posts: 1943 |
Hm, what does "VERY seldom" mean? Never happened to me AFAIR.
Using $e716 for direct screen printing and $ffd2 for drive things on my EF stuff only though. Never really looking at SEI/CLI. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Hm, what does "VERY seldom" mean? Never happened to me AFAIR.
Using $e716 for direct screen printing and $ffd2 for drive things on my EF stuff only though. Never really looking at SEI/CLI.
Hard to say here. A lot of stuff is happening, but ever so often it just crashes. And according to CHIS the CPU fetches a $02-instruction from ROM where a JSR-instruction should be. The question is really how that's even remotely possible with ROM swapped in (as is the default running carts). |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
I'm just being suspicious on the ROM-coded SEI-instruction just before the "problem", if there's an emulation bug. I guess I have to test on real HW now. |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Virtual device traps are off? I ask because this is one of the serial routines... |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Tested on Vice 3.1 with Virtual Device trap enabled.
break ed40
bread ed47
load"$",8 with a D64 attached gave me this:
ed40 78 SEI - A:00 X:00 Y:01 SP:f1 -B IZ
ed41 02 JAM - A:00 X:00 Y:01 SP:f1 -B IZ
ee97 AD 00 DD LDA $DD00 - A:00 X:00 Y:01 SP:ef -B IZ
ee9a 29 DF AND #$DF - A:1f X:00 Y:01 SP:ef -B I
ee9c 8D 00 DD STA $DD00 - A:1f X:00 Y:01 SP:ef -B I
ee9f 60 RTS - A:1f X:00 Y:01 SP:ef -B I
ed44 20 A9 EE JSR $EEA9 - A:1f X:00 Y:01 SP:f1 -B I
eea9 02 JAM - A:1f X:00 Y:01 SP:ef -B I
eeac CD 00 DD CMP $DD00 - A:1f X:00 Y:01 SP:ef -B I
eeaf D0 F8 BNE $EEA9 - A:1f X:00 Y:01 SP:ef -B IZC
eeb1 0A ASL A - A:1f X:00 Y:01 SP:ef -B IZC
eeb2 60 RTS - A:3e X:00 Y:01 SP:ef -B I
Note the JAM in there!
Without "virtual device traps" then the CPU history looks like this, without the JAM:
ed40 78 SEI - A:00 X:00 Y:01 SP:f3 -B IZC
ed41 20 97 EE JSR $EE97 - A:00 X:00 Y:01 SP:f3 -B IZC
ee97 AD 00 DD LDA $DD00 - A:00 X:00 Y:01 SP:f1 -B IZC
ee9a 29 DF AND #$DF - A:1f X:00 Y:01 SP:f1 -B I C
ee9c 8D 00 DD STA $DD00 - A:1f X:00 Y:01 SP:f1 -B I C
ee9f 60 RTS - A:1f X:00 Y:01 SP:f1 -B I C
ed44 20 A9 EE JSR $EEA9 - A:1f X:00 Y:01 SP:f3 -B I C
eea9 AD 00 DD LDA $DD00 - A:1f X:00 Y:01 SP:f1 -B I C
eeac CD 00 DD CMP $DD00 - A:1f X:00 Y:01 SP:f1 -B I C
eeaf D0 F8 BNE $EEA9 - A:1f X:00 Y:01 SP:f1 -B IZC
eeb1 0A ASL A - A:1f X:00 Y:01 SP:f1 -B IZC
eeb2 60 RTS - A:3e X:00 Y:01 SP:f1 -B I |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
That was my suspicion also. Indeed virtual device traps are on because I wanted speed and this was a simple way to emit a debug log to a file using an emulated printer. |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Yeah, if I'm doing disk stuff I turn off all of those traps and enable true drive. Sometimes the traps will cause problems with turbo loaders, or protection checks. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Yeah, if I'm doing disk stuff I turn off all of those traps and enable true drive. Sometimes the traps will cause problems with turbo loaders, or protection checks.
Normally me too, but in this case I thought what the heck, it’s just ascii output to an emulated printer, what can possibly go wrong. |
| |
Fungus
Registered: Sep 2002
Posts: 695 |
Known bug with true drive emu on older vice, UPDATE. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
I’m using HEAD. Anyway, I got confused by the JAM, but I guess that’s VICE’s way to implement virtual device traps. The problem is actually further down and entierly my own fault. Some memory corruption going on causing my PC to return to oblivion. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11416 |
Indeed traps are implemented via JAM ... should probably say so in the history/disassembly. Another of those thousand things... :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Indeed traps are implemented via JAM ... should probably say so in the history/disassembly. Another of those thousand things... :)
Yep, so I figured deep down the rabbit hole. :D
VDT are very useful for debugging in my case. Getting a quick stdout log to a file is VERY helpful via device #4. Single step in the debugger is too low level, and simple $d020/$d021 writes are not enough in this case. I need a proper history of events (30+ cooperative threads running wild).
Anyways, VICE works fine. I need to submit a patch for a proper fflush() on each $ffd2 though. Currently on my mac it's line buffered which is a bit annoying. |
| |
Count Zero
Registered: Jan 2003
Posts: 1943 |
Salvation!
Now you just need to tease us harder on the next print-on-virtual-paper RPG you seem to be working on, JA! |
| |
Fungus
Registered: Sep 2002
Posts: 695 |
What even are virtual device traps? |
| |
Krill
Registered: Apr 2002
Posts: 2989 |
Quoting JackAsserI need to submit a patch for a proper fflush() on each $ffd2 though. Currently on my mac it's line buffered which is a bit annoying. Line-buffered output is a good thing.
Maybe you just want a way to issue a flush from a guest-side KERNAL call? =) |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: Quoting JackAsserI need to submit a patch for a proper fflush() on each $ffd2 though. Currently on my mac it's line buffered which is a bit annoying. Line-buffered output is a good thing.
Maybe you just want a way to issue a flush from a guest-side KERNAL call? =)
Not when single step debugging and the output has been triggered, and you're watching the debug log file in an external editor. In those situations the external editor visible log file won't reflect the most recent events until they are flushed, which can be several C64 logging calls behind. |
| |
Krill
Registered: Apr 2002
Posts: 2989 |
Quoting Martin PiperNot when single step debugging [...] ... earlier ...
Quoting JackAsserSingle step in the debugger is too low level So then, a way to enable/disable buffering via KERNAL call? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: What even are virtual device traps?
A way for VICE to intercept standard kernel I/O-calls and execute them immediatly instead of doing the full emulation of the $dd00-dance. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: A way for VICE to intercept standard kernel I/O-calls and execute them immediatly instead of doing the full emulation of the $dd00-dance.
So basically, by attaching a raw printer that emits to a file and the do an open 1,4,7 you’ll get an easy debug print interface via $ffd2. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting Martin PiperNot when single step debugging [...] ... earlier ...
Quoting JackAsserSingle step in the debugger is too low level So then, a way to enable/disable buffering via KERNAL call?
Imo it shouldn’t be line buffered at all - ever. When you send a character to a printer connected to a c64, that character is printed directly. And so should it behave when emulated to a file also.
Maybe a toggle switch in the VICE-settings. |
| |
Krill
Registered: Apr 2002
Posts: 2989 |
Quoting JackAsserImo it shouldn’t be line buffered at all - ever. When you send a character to a printer connected to a c64, that character is printed directly. And so should it behave when emulated to a file also. Ok, fair point. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11416 |
Quote:Anyways, VICE works fine. I need to submit a patch for a proper fflush() on each $ffd2 though. Currently on my mac it's line buffered which is a bit annoying.
I believe those extra fflush calls are what screws up your warpmode in windows :=) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quote:Anyways, VICE works fine. I need to submit a patch for a proper fflush() on each $ffd2 though. Currently on my mac it's line buffered which is a bit annoying.
I believe those extra fflush calls are what screws up your warpmode in windows :=)
Highely likely. I wouldn’t use fflush explicitly though now that I think of it.
I’d do a setvbuf to turn off buffering on the stream, and use fcntl() with O_DSYNC | O_RSYNC on the underlying FD. The OS block-level cache should be able to ensure the same speed even if the stream itself is unbuffered.
Will try on my already patched VICE-install. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11416 |
feel free to examine other fflush calls in the log code :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Yeah. Also, would be fun to do a gprof in warpmode to see the bottlenecks. :) |
