Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!cory.Berkeley.EDU!fadden
From: fadden@cory.Berkeley.EDU (Andy McFadden)
Newsgroups: comp.sys.apple2
Subject: Re: Xapple2
Summary: nope.
Message-ID: <22777@pasteur.Berkeley.EDU>
Date: 8 Mar 90 00:52:05 GMT
References: <53040@bbn.COM> <53134@bbn.COM> <14340@phoenix.Princeton.EDU>
Sender: news@pasteur.Berkeley.EDU
Reply-To: fadden@cory.Berkeley.EDU.UUCP (Andy McFadden)
Organization: University of California, Berkeley
Lines: 53

In article <14340@phoenix.Princeton.EDU> tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis) writes:
>In article <53134@bbn.COM> kanarick@vax.bbn.com (Craig M. Kanarick) writes:
>
>>Basically, I have written, in C, a 6502 emulator.  It has an array of
[snip]
>
>I wrote a rudimentary 6502 emulator in C last summer which I have not
>gotten around to debugging yet. The code is really messy, and I'm not
>very proud of it, but there's a MUCH better way to go about finding
>the next instruction! 
[snip snip]
>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.

-- 
fadden@cory.berkeley.edu (Andy McFadden)
...!ucbvax!cory!fadden