Re: All this talk of a new GS...

[Jonas Bevren <jbevren@yahoo.com>]

On Thu, 3 Feb 2000, Phoenyx wrote:

> Date: Thu, 03 Feb 2000 12:03:41 -0600
> From: Phoenyx <quazar@dcnet2000.com>
> Newsgroups: comp.sys.apple2
> Subject: Re: All this talk of a new GS...
> 
> Well, I suppose the next question is, what will it take to
> make the board and who is capable of doing so?
> 
> Phoenyx
> 

Er, uh... um, uh... =)

Sometimes I really wish I had cash for my hardware projects (I'm quite lucky
to be able to afford the ones I do).  I'm no expert on PC hardware tho.

Hooking it all up shouldnt be that large a deal, asice from the difference
in bus widths (which can be compensated for in software).  Hm.  I'm guessing
we'd go in through the 65816's port, since most other accelerators do that
anyhow <grin>.  From there, it's a matter of building a 'proper'
pci->65816-socket interface.  It would be rather nice to be able to have it
friendly to the PCI standard, even though this _is_ an embedded project.

It's not difficult to map a 16M address space through a PCI slot either,
especially when you are running a custom embedded system.  If we bypass all
the standards I'd like to uphold, we could easily just decode the top 8 bits
of the 32-bit address bus on the core CPU, and use that to enable/disable
a set of transcievers on the 65816's socket.  Ya know, if you dont mind
sacrificing some speed, you could have the firmware just copy the GS's rom
data into its local ram and run everything behind an emulated 65816.  I'm
pondering how difficult it would be to emulate the CPU, and I dont think it
would be hard at all, especially considering the (relatively) large number
of registers in the beast.  A few could be dedicated for the 816s own
registers, and the remaining could be used for the emulation engine to
load and decode opcodes. 

Easiest emulation IMHO would be two brute-force interpreters, one for native
mode, and another for emulation mode.  I chose two because each interpreter
cant be all that large, and it makes it significantly faster if the code
doesnt have to check whether its in emulation mode or not on every opcode.

Simple example for brute force interpretation (in a friendly language):

X/A are 16bit of course
coreloop lda [IP] ; fetch opcode from memory
         asl      ; multiply by two for vectored jump
         tax     
         jmp [dispatch,x]
         bcc coreloop
; switch modes here

anyhow, you get the idea =)  256 routines in memory for 256 entries. 
Returning a set carry means its time to switch to the other mode.

Ok, enough babble.  Let's get back to hardware. =)

-Jonas