Date   : Wed, 05 Mar 2008 10:32:27 +0100 (GMT)
From   : johan@... (Johan Heuseveldt)
Subject: TUBE chip, accessing 'Parasite' side - 16Mhz 65C02S

David,

On Wed 05 Mar, David Warrington wrote:

> > 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.

It can be a bit confusing. A CoPro is internal for the Master. A Second
Processor is therefor external by defenition. That is, the name Co-Processor
was new when the Master Series came out. Before that it was only Second
Processor.

In general 'we' treat the names as equal, needing further descriptions as
internal/external. That way we make it harder than necessary! :-)

My reference to the Master CoPro being 4 MHz, should be unambiguous. :-)


About the replacement; the internal one is quite different in PCB layout,
as it has two smaller connectors far apart from each other. An extarnal
has a single connector, 40 pins flatcable for the TUBE connector.
So you /do/ need something here to do ypursel. Or...

There is a(n external) CoPro case - by CC I think, specificly designed to
do exactly that!


> > 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! :-)
> 
> 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 

That's a bit too enthusiastic I suppose; it's 24 bits, the additional 8 bits
multiplexed with the data bus.

> 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.

Latching the address lines A16-23 in an transparent 373 latch is sufficient,
clock input is the clock 1 phase. (Elektors EC65K design)

> 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. :-(

That is correct. Two bits are significant, creating four states! But change
of this state is done by opcodes, so should be possible to keep track off.
But I agree, when a subroutines are nested more than once, it can be quite
difficult to keep synchronized!

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



Greetings,
Johan

-- 
Johan Heuseveldt <johan@...              >
  aka  waarland

  The best place is a Riscy place
 
Avoid commas, that are not necessary.