Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!apple!oracle!news From: pnakada@oracle.com (Paul Nakada) Newsgroups: comp.sys.apple2 Subject: Re: Xapple2 Message-ID: Date: 8 Mar 90 02:39:48 GMT References: <53040@bbn.COM> <53134@bbn.COM> <14340@phoenix.Princeton.EDU> <22777@pasteur.Berkeley.EDU> Sender: news@oracle.com Organization: Oracle Corporation, Belmont, CA Lines: 56 In-reply-to: fadden@cory.Berkeley.EDU's message of 8 Mar 90 00:52:05 GMT In article <22777@pasteur.Berkeley.EDU> fadden@cory.Berkeley.EDU (Andy McFadden) writes: >2) (the sneaky part) the "instruction" datum is simply an index to >another array of pointer to function! So, each function is an [...] >execute_instruction[x](), go there! Sneaky, yes. Efficient, no. With this method you get procedure call overhead with every single 6502 instruction. Not a good way to go. It's faster to do things like switch (mem[pc++]) { case LDA_ABS: loc = mem[pc++] + (mem[pc++] >> 8); reg[ACC] = mem[loc]; break; case ... } Which automatically increments the PC with each instruction, so that when it hits the "break", a while loop takes it back around to the top of the case statement, and it's ready for the next insruction. >Byron "Bo knows parallel computational geometry" Rakitzis. > (tbrakitz@phoenix.Princeton.EDU) What ought to be fun is writing some $c000 page stuff... Make certain ranges look like an intelligent disk device, then just run standard ProDOS 8. Rewrite the device code to make UNIX system calls, then use a disk image file to actually read from (I did something like this once for some SSI games... changed disk sector read/writes into read/write offsets of a file). You would also have to use something like curses and watch the text page for activity, so that things which stored values directly to the screen actually printed out. Using 128K of RAM would be easily done by just watching accesses to the $c000 page; make memory act just like it would on a //. Doing this, you could boot your Apple II off of a 3.5" disk drive... all under UNIX. Standard, off the shelf programs would work. The more effort, the better they would run. Andy, I think you might want to be careful about those pc++ expressions. I'm, not totally sure about this, but isn't there some problem with the order of evaulation of the expression? In any case, something to consider. On another note, the great thing about prodos is that all calls are made through the prodos entry vector $BF00. So to emulate Prodos, you just have to trap any jsr to $BF00 and execute native code to emulate whatever prodos would do.. No need to steal or have resident ANY Prodos code, or play with the disk I/O softswitches... of course this would only work with programs strictly adhering to Prodos convention. -Paul Nakada pnakada@oracle.com