[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Disk ][ Launcher (was: Late night musings...)



In article <50f1mg$ihd@nyx10.cs.du.edu> wbaguhn@nyx10.cs.du.edu (Will Baguhn)
writes:
}In article <50a5s8$o9f@darla.visi.com>, Nathan Mates <nathan@visi.com> wrote:
}>In article <hu83860@pro-palmtree.cts.com>,
}>Richard Der <rder@pro-palmtree.cts.com> wrote:
}>>nparker@cie-2.uoregon.edu (Neil Parker) wrote:
}>>>You can't just emulate one piece of hardware--you have to emulate
}
}>another), and other fun tricks. What I'd bet the Mac emulators for the
}>Amiga do is run the code at full speed, but have the mac "hardware"
}>memory protected. That way, only when the hardware is hit does the
}>emulator take over and do something special.
}>
}>   The GS has none of that functionality, so the only way to really
}>see if an instruction will cause a reference to the "hardware" (Cxxx,
}>plus the currently displayed screen if you're not running the code in
}>a bank that is displaying the screen) is to verify each and every
}>instruction. Anything involving only registers would be simple--- see
}>if it won't trigger a memory access, and go on from there. Anything
}>hitting an arbitrary memory address would hhave to have that address
}>checked to see if it'll cause a hit on hardware, and specially
}>processed if so.
}
}How about the trace interrupt?
}[...]
}It'd be slow, but using the trace interrupt one could theoretically
}have it run each instruction at full speed, store all the registers,
}check the next instruction and if it was nothing "special" it would
}allow it to continue on processing... if it's something special, it
}could perform the special stuff, advance the PC on stack appropriately,
}and keep going.

Yes, this sounds like a really neat way to do it.  There is, however, one
major problem standing in the way:  The 65816 has no trace interrupt.

Trace interrupts are by no means a unversal feature of CPUs.  Some
architectures (like the 80x86, for example) have them, and some (like the
6502/65816) don't.

The only way to get a true trace interrupt on a 6502 or a 65816 would be
with some kind of external hardware that recognizes opcode fetch cycles.  I
have no idea how easy or hard this would be to do...but it certainly
couldn't be a slot card--it would probably have to be something that
attaches directly to the CPU.

Without a trace interrupt, you're stuck with the methods I outlined in a
previous post:  interpret all instructions "manually," or copy
instructions, one at a time, to a special "execution buffer" like the old
monitor ROM step/trace code does.

               - Neil Parker
-- 
Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker

                     "Bad move, Neil!"  -- The Tick