Date   : Wed, 05 Mar 2008 00:13:26 +0100
From   : dw@... (David Warrington)
Subject: TUBE chip, accessing 'Parasite' side - 16Mhz 65C02S

> The Master CoPro is 4 MHz!

The *internal CoPro* upgrade is 4Mhz. The external cheesewedge is 3Mhz. I've 
been keeping my eyes open for a 4Mhz board on ebay as a donor board to 
upgrade/replace an EXTERNAL 3Mhz 6502 CoPro.

>
> Actually I did give it a thought, but with these high speeds you must know
> something more about electronics I suppose, wiring it all up and/or making 
> a
> PCB layout. It's defenitely more than glueing some logic together I 
> recogn.
>
>> If this all sounds *too easy* and not enough *fun*, one could think about
>> paged memory on the CoPro rather than just a single memory map... and
>> therefore run a modified BASIC with one 64K bank for program, and another
>> 64K bank for variables.
>
> Then I find a 65816 more acctractive, with 16 MBytes of SRAM! :-)
>
>
> Johan
>

The 65816 is a bit more tricky:

1./ No software of "beeb" nature to take advantage of such memory map, so 
would require quite a lot of work to utilise this in any existing software 
we are familiar with

2./ The memory address bus is latched, ie. 32bit data over 16bit pins. That 
needs a bit more work and logic to get up and running. While do-able, its 
adding to the complexity of the project :-(  In fact, once you start doing 
this, you might as well just "page" memory banks and use existing software 
like BASIC128.

3./ On the 65816, the machine code is "state dependent", meaning depending 
on the state of a register, an opcode, e.g.  #&AA, would mean ONE thing one 
time,and possibly SOMETHING ELSE another time, depending on various 
status/register flags. It makes debugging and disassembly a complete 
nightmare. ie You CANNOT disassemble WITHOUT "step through virtual execution 
" of the code to understand the "state"of these register flags and therefore 
give the correct decode. What is worse is that the length of an instruction 
can be different, e.g. 2, 3 or 4 bytes.  So if you do a wrong decode, not 
only do you make ONE mistake on the single instruction, but you also screw 
up the disassembly of the next instruction, because you've mistaken a 3 byte 
instruction for a 2 byte instruction, etc. :-(

HORRIBLE. An architectural mistake for a general purpose computer like the 
been IMO. OK for embedded device with just "one" preprogrammed function.

David