| |
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. |
|
... 15 posts hidden. Click here to view all posts....
|
| |
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: 11418 |
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: 1945 |
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: 2990 |
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? =) |
| Previous - 1 | 2 | 3 - Next |
