jason@lakesys.UUCP (Jason) (07/23/88)
Warning: This post contains some really bad puns... (I hope the info presented makes up for 'em :) In article <24361@think.UUCP>, whitney@think.COM (David Whitney) writes: > > derivatives) have real microprocessor instructions, and then something > called 'traps'. Traps are undefined microprocessor instructions. It First, a digression from the main reason for posting this... Uh, minor correction here... TRAP is a valid 68000 instruction. But, instead of doing something fairly normal, it "initiates exception processing." Which basically means (for those unfamiliar with this sort of stuff) that it saves the state of the processor, and then goes to a certain location (in this specific case, it goes through the exception vector table). There are undefined instructions in the 68000, which have their own exception, I believe (going on memory for this one). > instruction. One does COP #<something> to make something interesting > happen. Currently, there is no support for the instruction, but who Umm, there's no builtin software support for it, but there is a way to use it within programs... The COPMGRV (COP Manager Vector), Vector #5 through GetVector and SetVector, lets you point to your own code when it happens (haven't played with it, so I don't know how to get the #). Might be nice to write a soft-coprocessor. Yaknow, with fairly simple math... Maybe some of the stuff in SANE (sorry, couldn't resist!), too, when I get the manual so I can figure it out :) How many people in netland would be interested in a soft-coprocessor? Something like load X with one of the things to be multiplied (I could never remember the proper mathmatical names for those things...), load Y with the other, and then do a COP #0 to do the multiply. If there are people interested, I'll probably write one and then post it - send me suggestions if you have any... > BRK also now takes one parameter - who knows how to use it? The extra byte isn't "really" part of the instruction. However, if you wanted to use it, you'd have to set yourself up for the Break vector (#$1c), and do a GetAddr to get the address of BRK.VAR (#$09). When the break comes, you'd have to get the emulation flag (12 bytes into BRK.VAR) and figure out if the 65816 was in emulation mode. If it was, grab the PC (14 bytes into BRK.VAR) register, subtract 1 from it, and use that as the address of the BRK "parameter". If it wasn't in emulation, follow the same path, but grab the K register (13 bytes into BRK.VAR) and tack it into the address too... Hmm, sounds interesting, eh? Have to try it sometime (could be mighty nice, as long as the program was debugged...). > David Whitney, MIT '90 > whitney@think.com The moral of this post: Never un-bind the Return key... -- Jason - Not your average iconoclast | UUCP: uwvax!uwmcsd1!lakesys!jason