Matchbox sized 6502 / Z80 / 6809 Co Pro

discussion of games, software, hardware & emulators relating to the Acorn Atom and Acorn System machines.
User avatar
danielj
Posts: 7305
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by danielj » Mon Feb 02, 2015 1:45 pm

I've had mine dangling off 30cm without any trouble on my Master, running Elite without any flinching (and this is also with a datacenter on the 1MHz bus...). :?

d.

Mike3071
Posts: 44
Joined: Wed Aug 10, 2011 7:53 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by Mike3071 » Mon Feb 02, 2015 2:14 pm

Whoopee!

User avatar
danielj
Posts: 7305
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by danielj » Mon Feb 02, 2015 2:47 pm

The point being that it's odd that yours isn't playing nicely on a longer cable. I was just adding a datapoint.

d.

Mike3071
Posts: 44
Joined: Wed Aug 10, 2011 7:53 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by Mike3071 » Mon Feb 02, 2015 3:48 pm

Okay, I was being mischievous, UPDATE - made up new 30cm lead and
it seems to be working well.

Mike

User avatar
1024MAK
Posts: 8876
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by 1024MAK » Mon Feb 02, 2015 4:48 pm

Getting back to Lee's question...

It's not a power supply or a power feed problem.

I think the problem is actually a mix of two problems:

First the data and control lines and the mix of devices (74LS TTL, NMOS, maybe CMOS and on the modern 2nd processor, modern FAST CMOS) on the bus. In the BBC B, some of the data and control lines are electrically connected to the CPU and not via amplifying buffers.

Second, the cable adds extra parasitic capacitance and inductance.

Add these two together and the system sits near/on/in the grey area. If you are lucky, you may be in the "it normally works" part of the grey area. If you are unlucky, you will find yourself in the non-working area. By grey area, I mean the logic chip switching thresholds for logic zero and logic one.

The official Acorn 2nd processors were designed with this problem in mind. So they can cope. They are also 1980's technology.

The Torch 2nd processor uses 1980's NMOS so again, works okay (as this type of NMOS is slow compared to modern FAST CMOS).

At least, that is what I suspect the problem to be :?

Mark

User avatar
danielj
Posts: 7305
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by danielj » Mon Feb 02, 2015 5:09 pm

So one thing we were discussing at the weekend was whether soldering up the unsoldered grounds would make a difference on the beeb? IIRC this would end up cutting down crosstalk between the lines. Now, I don't know if anyone actually tried this in the end?

d.

User avatar
1024MAK
Posts: 8876
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by 1024MAK » Mon Feb 02, 2015 5:20 pm

Cutting down on crosstalk is always a good idea. However, at the same time, either the stray capacitance will stay about the same, or it may even get a little worst, causing the digital signal rise and fall times to continue to be poor. This is less of a problem with slower low slew rate technology, but still a problem with the modern higher speed chips.

For those that have not heard about slew rate, I'm abusing a term used with op-amps (operational amplifying chips) that defines how rapidly the output can change (or in practical terms, fail to change or "keep up with") over time when the input rapidly changes state by a large amount.

When a digital signal is affected by a heavily loaded bus, stray capacitance, inductance etc, it turns a sharp clean digital edged square wave into a distorted triangular waveform...

Mark

User avatar
daveejhitchins
Posts: 4961
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by daveejhitchins » Mon Feb 02, 2015 5:26 pm

Hmmm! I wonder if a set of 33R series resistors would sort-out the problem. These are used to minimise ringing of fast edges and, to some extent, match impedances. You would just use them on the 'signal' lines.

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
sydney
Posts: 2423
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by sydney » Mon Feb 02, 2015 6:31 pm

danielj wrote:So one thing we were discussing at the weekend was whether soldering up the unsoldered grounds would make a difference on the beeb? IIRC this would end up cutting down crosstalk between the lines. Now, I don't know if anyone actually tried this in the end?

d.
I think Lee's were soldered.

My matchbox works perfectly on my master but poorly on my beeb, crashing at the same point in tube elite. The copro worked with the beeb before I fitted my WE 12 ROM board so Jason seemed to think this confirmed the loading of the bus was causing problems.

On another note I knocked up a (very) quick and dirty test program to compare the speed of the master with and without the matchbox.

Code: Select all

10 TIME=0
20 FOR I=1 to 10000
30 PRINT I
40 NEXT I
50 PRINT TIME

Result without matchbox : 10863 
Result with matchbox : 3960
10863/3960=2.74 times faster!
Would some complex calculations in the loop make the difference larger? I might have a play later.

User avatar
1024MAK
Posts: 8876
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by 1024MAK » Mon Feb 02, 2015 7:32 pm

You should not include I/O stuff in the computing loop, as BASIC will be slowed down as the host 2MHz CPU deals with processing the I/O job...

The more complex and varied you make the code, the more you even out differences in the translation of BASIC to machine code.

Remember, you are testing a number of things, the speed of the version of BASIC that is being used (how good the BASIC interpreter is), the coding of your program (including spaces), how good the CPU is with the machine instructions used (6502 CPUs are better than Z80's at some things, but worst at other things, also later versions of 6502's like CMOS versions, are better than the NMOS versions) as well as the overall speed.

Mark

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Mon Feb 02, 2015 7:43 pm

The other thing to appreciate is that so far no-one has really attempted to optimise the 6502 Co Pro for speed. The limiting factor is the external SRAM. The LX9 has 64KB of usable block RAM, so a new design that just used this would allow much higher clock speeds. I think Jason is interested in this area. I'd guess 40MHz would be possible, maybe more, depending on the core. And AlanD's looks pretty efficient.

Dave

User avatar
jgharston
Posts: 3569
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Mon Feb 02, 2015 8:20 pm

1024MAK wrote:You should not include I/O stuff in the computing loop, as BASIC will be slowed down as the host 2MHz CPU deals with processing the I/O job...
ClockSp tests the speed of just the BASIC language processor and compares it with a 2.00MHz BBC B. At Halifax we were getting around 8MHz on the matchbox.
danielj wrote:So just double checked. GEM/Mouse work fine. BBCBASIC bomb is this: (picture)
That's the same program counter address as the previous report, so that's consistent. Can you also do *D (seg):(addr-20) +40 to show what's in memory where it crashed, where (seg):(addr-20) is the CS:IP values in the crash report? Eg, where the above crashed at 4E5C:1A40 do *D 4E5C:1A20+40

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
flynnjs
Posts: 809
Joined: Tue Jul 06, 2010 9:33 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Mon Feb 02, 2015 8:33 pm

I've no idea about the termination that a real Tube IC presents to the Tube bus.
If we could mimic that then we could probably improve reliability.
The level translators used are just a best guess. It might be that better results
could be had but putting a genuine 5v buffer device on the end of the cable and
then putting the translators on the matchbox right next to the 5v buffer.
I might knock up a small board that does that and then use a long cable and see
if that works.
Ultimately, this board was shrunk down to fit under a B so no cable is needed
and this seems to work for the majority of people, especially if they don't have
huge ROM boards or other devices on 1MHz bus.

firthmj
Posts: 230
Joined: Tue May 26, 2009 8:37 am
Location: Ipswich, UK
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by firthmj » Mon Feb 02, 2015 8:45 pm

flynnjs wrote:I've no idea about the termination that a real Tube IC presents to the Tube bus.
If we could mimic that then we could probably improve reliability.
The level translators used are just a best guess. It might be that better results
could be had but putting a genuine 5v buffer device on the end of the cable and
then putting the translators on the matchbox right next to the 5v buffer.
I might knock up a small board that does that and then use a long cable and see
if that works.
Ultimately, this board was shrunk down to fit under a B so no cable is needed
and this seems to work for the majority of people, especially if they don't have
huge ROM boards or other devices on 1MHz bus.
I wonder if any documentation on the I/O cells on the Ferranti ULA exists that might help with that?

One other thing I think it would be useful to do is to look at the signals on both sides of the level translators when attached to a "bad" host, to try and characterise what the misbehaviour looks like - are the switching points moving relative to each other for the different signals, are there "double bounce" effects post level translator, or is it a different issue.

Another thing that would be good to do is to see how the host behaves with the Co-Pro attached, but disabled -i.e. are the issues just on the Tube, or are there corruptions on the host because the Tube is attached.

Regards

Michael
Had fun at the
Image
Meeting 13th May 2017

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Mon Feb 02, 2015 9:06 pm

I'd like to gather some more data on the register 3 PH problem people encounted at Halifax, and that Daniel mentioned on the 6809 thread.

Is there a situation that will reliably reproduce this?

I've tried just saving a Basic program, and this seems to work fine for me.

Was this problem specific to certain hosts, e.g. Model B's?

When it happened, was it consistent, or it only happens one time in N; what N?

What Co Pro type(s) does it happen with?

What's the pattern of EE's within the file? This will help understand if the parasite is just struggling to keep up, or whether the data transfer has somehow hung completely. EE's mean the PH FIFO has run dry, but the host has read anyway (there is no handshaking on this....)

Dave

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Mon Feb 02, 2015 9:13 pm

flynnjs wrote:Secondly, R3 transfers from parasite back to host start off ok but occasionally write $ee to remainder of a file during saving. This was observed with both RAMfs and ADFS. Until we track this down I would advise not to save to disk if you're worried about corruption.
Was this ever observed with DFS?

Maybe this explains why I have not seen it, as I'm almost exclusively using DFS, apart from with the 80x86.

Dave

RobC
Posts: 2625
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by RobC » Mon Feb 02, 2015 9:20 pm

hoglet wrote: Was this ever observed with DFS?
I'm seeing issues in Flex on the 6809 using OSWORD &7F under DFS to write sectors. Reading works fine but writing sectors sometimes corrupts the disk.

However, I have only just found out about the 'EE' issue so haven't had a chance to check that this is definitely what's causing the corruption.

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Mon Feb 02, 2015 9:22 pm

Rob,

Can you post some disk images, so I can try to reproduce this?

Dave

User avatar
danielj
Posts: 7305
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by danielj » Mon Feb 02, 2015 9:28 pm

You'd get the first bit of the file usually, and then some EEs towards the end. I have a hazy recollection of them appearing towards the end of 256byte chunks in some of the files that were being written. Can't check it with DFS at the moment as I don't have anything set up with drives :(

d.

RobC
Posts: 2625
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by RobC » Mon Feb 02, 2015 9:48 pm

Hi Dave,

It's a bit complicated because you have to use OmniFlop to format and write the Flex disk. Also, I'm not certain that what I'm seeing is definitely caused by the 'EE' problem.

However, a simple test that sort of mimics what I'm doing would be to just call OSWORD 7F to write a single 256-byte sector. This code is adapted from Gordon Horsington's series on OSWORD 7F (which can be found on the excellent MDFS):

You should be able run this on the 6502 co-pro and then check to see what is written to the disk (either in a disk editor or by doing the equivalent read operation).

Code: Select all

   10 REM: WRITE10
   20 DIM MC% 200
   30 osword=&FFF1
   40 page = PAGE
   50 FORpass=0 TO 2 STEP 2
   60 P%=MC%
   70 [       OPT pass
   75 .write
   80         LDA #&7F
   90         LDX #block MOD 256
  100         LDY #block DIV 256
  110         JSR osword
  120         LDA result
  130         BEQ ok
  140         BRK
  150         EQUB 199
  160         EQUS "Write error"
  170         BRK
  180
  190 .ok
  200         RTS           \ Write sucessful
  210
  220 .block
  230         EQUB &FF      \ current drive
  240         EQUD page     \ start at PAGE
  250         EQUB &03      \ 3 parameters
  260         EQUB &4B      \ write data multi-sector
  270         EQUB &01      \ logical track 1
  280         EQUB &00      \ start logical sector 0
  290         EQUB &2A      \ 10 sectors of 256 bytes
  300 .result
  310         EQUB &00      \ result byte
  320 ]
  330 NEXT
  340 CALL write
P.S. Reading the earlier posts, if you want to borrow a genuine M512 mouse, let me know. I'm in Newport so not too far from you...

Cheers,

Rob

User avatar
flynnjs
Posts: 809
Joined: Tue Jul 06, 2010 9:33 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Mon Feb 02, 2015 9:49 pm

The reason ADFS was tried was because I was using a CF card on a
Datacentre and I wanted to try out something other than the RAM
disks and RAMFS. I would expect both of those to write at a higher
rate than DFS so pull data from R3 quicker.

Just saving a BASIC program would trigger it very often. Around
50% or maybe more. JGH resorted to saving a program by opening
a file and BPUTting byte by byte which did the trick.

This was on my B using an LX9Co running your latest git release
which I pulled on Saturday morning.

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Mon Feb 02, 2015 11:06 pm

I've just managed replicate the EE issue on my Master, with the 6502 Co Pro, saving a large Basic file to Datacentre's RamFS disc.

As a sanity check, I tried the same with a real external 6502 second processor, and, not surprisingly, this did not have the problem.

I'm pretty sure the problem is a synchronization issue on NMI (and IRQ). I actually fixed this on the other Co Pro designs, but neglected to add it to the 6502. :oops:

I've just committed a fix to github that looks like it fixes the problem for me.
https://github.com/hoglet67/CoPro6502/c ... 52a6eddc97
I was able to save a large Basic file 5 times in a row without corruption.

In my defence, the earlier core we were using must have been internally synchronising these signals (like a real 6502 does). AlanD's core doesn't do this, hence the need for a couple of external flip flops.

If this was indeed the cause, it only affects the 65C02 Co Pro, as the others already contained the fix.

Was anyone seeing the same issue with the Z80 or 6809, and was able to verify it was the same by looking for EEs in the file contents?

Dave

User avatar
jgharston
Posts: 3569
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Tue Feb 03, 2015 1:32 am

hoglet wrote:
flynnjs wrote:Secondly, R3 transfers from parasite back to host start off ok but occasionally write $ee to remainder of a file during saving. This was observed with both RAMfs and ADFS. Until we track this down I would advise not to save to disk if you're worried about corruption.
Was this ever observed with DFS?
No, because almost all the testing we've been doing so far has just been loading programs/data.

We've not seen problems with 2-byte transfer before now because DFS only ever uses 1-byte transfers, and ADFS uses 256-byte transfers - which are actually 256 1-byte transfers - for whole sectors, and 1-byte sectors for sub-sector data. NFS uses 2-byte transfers because the network hardware has a 2-byte FIFO so presents two bytes to the network interrupt routine, so the simplest programming option is to send both of them across the Tube with a 2-byte transfer, dropping to 1-byte transfer for the final byte if an odd total number of bytes.

In summary:
1-byte Host-Tube: ok 1-byte Tube-Host: starts ok, but gradually fails
2-byte Host-Tube: fails 2-byte Tube-Host: fails
256-byte Host-Tube: ok 256-byte Tube-Host: starts ok, but gradually fails

To test the transfers, code in the Host has to initiate a transfer and then attempt to do a transfer, then examine the results to see what happened. I wrote the following code at Halifax. I may misremember bits of it, but (insert name) has it on his DataCentre, so he could correct my typos.

Code: Select all

REM > TTEST/SRC
REM Test Tube transfers
DIM mcode% &100
FOR P=0 TO 1
O%=mcode%:P%=&900
[OPT P*3+4
.claim
LDA #&C0+31:JSR &406:BCC claim
LDX #addr AND 255
LDY #addr DIV 256
LDA #3:JSR &406:\ Start 2-byte Host->Tube
NOP:NOP:NOP:NOP:NOP:NOP :\ Initial delay
NOP:NOP:NOP:NOP:NOP:NOP
LDX #0
.loop
TXA:STA &FEE5:\ Send a byte 1
INX:TXA:STA &FEE5:\ Send byte 2
NOP:NOP:NOP:NOP:NOP:NOP :\ Transfer delay
NOP:NOP:NOP:NOP:NOP:NOP
INX:BNE loop
LDA #&80+31:JMP &406:\ Release
.addr:EQUD &00004000
]NEXT
OS."SAVE TTEST "+STR$~mcode%+" "+STR$~O%+" FFFF0900 FFFF0900"
Then, doing *TTEST will try to transfer 256 bytes &00 to &FF to the CoPro at &4000 to &40FF. Doing:
FOR A%=&4000 TO &40FF:PRINT " ";~?A%;:NEXT:PRINT
will show what actually got sent over. It should be 00 01 02 03 04 etc.

Changing the transfer start to LDA #1:JSR &406 and removing the "Send byte 2" line will do a 1-byte transfer. Changing the transfer start to LDA #7:JSR &406 will do a 256-byte transfer.

The Parasite (to CoPro) should be interrupted at the start of:
* each 1 byte transfered (ie byte 00, 01, 02, 03 etc)
* each 2 bytes transfered (ie byte 01, 03, 05, 07 etc)
256-byte transfers uses polling.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

RobC
Posts: 2625
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by RobC » Tue Feb 03, 2015 6:03 am

hoglet wrote: Was anyone seeing the same issue with the Z80 or 6809, and was able to verify it was the same by looking for EEs in the file contents?
I've just done a file comparison on the good and corrupted Flex system disks but there are no EEs in the corruption.

Sorry for the red herring.

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Tue Feb 03, 2015 8:38 am

Hi all,

For anyone who has the Xilinx programmer and wants to try the 6502 "EE bug" fix, here is an updated multiboot .mcs file:
lx9_20150203_dmb.zip
(718.73 KiB) Downloaded 33 times
This also contains a fix to allow the 80x86 to detect 896K of RAM.

Change log can be seen here:
https://github.com/hoglet67/CoPro6502/commits/master

Note, it does not address the Register 3 2-byte mode bug, which will need more work. As far as I am aware, this only impacts Econet installations.

regards

Dave

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Wed Feb 04, 2015 9:35 pm

I've been doing a bit of overclocking :shock:
IMG_0796.JPG
Not quite stable enough to run Elite yet, but close I think.

Dave

User avatar
roland
Posts: 3230
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by roland » Wed Feb 04, 2015 9:49 pm

This is the first system that I see with floating point faster than integers or do I miss something =D>
256K + 6502 Inside
MAN WOMAN :shock:

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Wed Feb 04, 2015 10:01 pm

roland wrote:This is the first system that I see with floating point faster than integers or do I miss something =D>
This is an artefact of the benchmark being relative to a model B.

Look at the data here:
http://mdfs.net/Software/BBCBasic/Testing/Speeds

There is a bug jump between the model B (Basic II) and the Master (Basic IV) that is down to a more efficient implementation of the Floating Point operations, rather than clock speed.

I'm testing on the Master so will benefit from this as well.

Dave

User avatar
jgharston
Posts: 3569
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Thu Feb 05, 2015 7:57 pm

hoglet wrote:
roland wrote:This is the first system that I see with floating point faster than integers or do I miss something =D>
There is a big jump between the model B (Basic II) and the Master (Basic IV) that is down to a more efficient implementation of the Floating Point operations, rather than clock speed.
Off the top of my head, 65xx BASIC stores floating point numbers high-to-low in memory, so the exponent is at float+0 in memory. 6502 BASIC manipulates floating point numbers with (zp),Y addressing mode, so to address the exponent has to first do LDY #0. 65C12 BASIC is able to use (zp) addressing mode for the exponent, so doesn't have to do LDY #0 first.

Integers are stored in the "natural" order of low-to-high, and there is nothing special about the zero'th byte of an integer, so when accessing integers (zp),Y addressing mode is always used as all four bytes are accessed with LDY #0, blah blah INY:CPY #4:BNE loop.

All other versions of BBC BASIC store floats low-to-high, so the exponent is at float+4, and by setting the exponent to zero the 5-byte value is actually an integer. If num is an integer and stored with |addr=num, then |addr=!addr. This follows from the pre-existing case where if num is a byte, and stored with !addr=num, then !addr=?addr. All stored numbers resolve down to the size of the number they fit in.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 8275
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sat Feb 07, 2015 1:51 pm

Hi all,

I've done a few tweaks that have increased the stability and speed of the new Fast 65C02 Co Pro. It is now stable enough to run Tube Elite.

The 65C02 Core is running at 77.33 MHz, but the internal block ram is registered, so the effective clock rate is half of this, i.e. 37.66MHz.

I tried hard to push it to 80MHz, but it didn't meet timing, and the resulting design failed to run Elite in practice.

Here's the result of JGH's CLOCKSP test:
IMG_0797.JPG
The design is on github, if anyone wants to have a play: LX9Co-6502fast.xise

Did anyone else try the new .mcs file that fixed the EE's on SAVE issue discovered at Halifax. I'd like someone to verify the fix if possible.

Dave

Post Reply