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: 7437
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by danielj » Sat Feb 07, 2015 2:09 pm

That is positively flying. Elite is unplayable at that speed...

I'm just waiting for my Xilinx programmer to arrive in order to test all the fixes and things :(

d.

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Sat Feb 07, 2015 2:58 pm

Dave, I tried your new interrupt sync fix and it all seems fine.

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by firthmj » Sat Feb 07, 2015 4:31 pm

hoglet wrote: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
How easy do you think it would be to put a clock multiplex of some kind in place to allow (for example) 4/8/16/32/64MHz selectable clock versions of the 65c02 design?

Could be instigated by getting the multi-loader to load the same design for multiple different DIP switch settings, and the 65c02 also looking at the DIP settings to select the speed.

I might have a play at creating something like that myself in the next couple of days...

Regards

Michael
Had fun at the
Image
Meeting 13th May 2017

User avatar
TheCorfiot
Posts: 660
Joined: Mon Jan 08, 2007 5:22 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by TheCorfiot » Sat Feb 07, 2015 4:41 pm

Hi Dave

i flashed the mcs file and all appears to work more reliably.

Using a Basic Model B with Watford DFS, in 65C02 mode, when powering up you just get a flashing cursor in the top left corner..CTRL Break boots the system successfully.

one of my copros runs elite for hours on end, the other appears to have a fault as after a few minutes it crashes, corrupting its memory in the process, may send this one back to Jason to invetigate...

Cheers x

User avatar
hoglet
Posts: 8433
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 7:24 pm

Hi all,

Back to the issues with the x86 running V482 BBC Basic.

A quick re-cap.

It's pretty stable, in that you never get hard crashes back to DOS, but something is causing the Basic interpreter to occasionally mess up.

Consider the following program:

Code: Select all

10 REM
20 GOTO 10
30 ?&1000=&1000 EOR 255
40 GOTO 10
I have a test build where writing to memory location 1E54:1000 will also write to the LED. When I run the above program, every few seconds the LED will toggle. Which is clearly wrong, as line 30 should never be reached.

In the test build, I've also configured one of the DIP Switches to disable Interrupts. As soon as I disable interrupts, the LED stops toggling. As soon as I enable interrupts, the LED resumes toggling.

CONCLUSION 1: Interrupts are somehow messing up the operation of the Basic interpreter.

I was pretty sure this had to be because somehow one of the 80x86 registers or flags was not being preserved. So, I wrote a little test program that:
- writes particular values to all registers, including the flags
- waits a few seconds (by executing a number of HLT instructions which halt the CPU until the next interrupt)
- prints the values of all registers to the screen

I was surprised to find no evidence of any registers being corrupted. I repeated this test many times.

CONCLUSION 2: All register/flags state is being correctly preserved during interrupts.

So that begs the question, what's else is left?

I don't really have any answers, and welcome suggestions, no matter how unlikely.

The only line of investigation I am actively pursuing relates to this comment:
8086IntBug.PNG
The bug pertains to the fact the the 8086 instruction set includes a set of prefixes which can affect the operation of subsequent instructions. The 8086 does not properly handle an interrupt colliding with an instruction with multiple prefixes.

I'm wondering if maybe the Zet core suffers from this bug?

I did find one example of multiple prefixes being used in the BBC Basic disassembly, at 1000:4615:

Code: Select all

1000:460e be9b46               mov    si, 469bh
1000:4611 b90700               mov    cx, 07h
1000:4614 loc_00004614:
1000:4614 fc                   cld   
1000:4615 f32ea4               rep movsb cs:
1000:4618 e302                 jcxz   loc_0000461c
1000:461a e2f8                 loop   loc_00004614
But this also seems to contain a workaround which means the code should work even on a 8086.

So all in all, no real progress on this one.

Dave

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Sat Feb 07, 2015 10:17 pm

Unless it's due to an interrupt co-inciding with an instruction
that is modifying a flag and there is a bug whereby the flag
doesn't take on the new value at the end of the instruction
as it enters the ISR.

Rather than setting flags and HLTing can you just toggle
a flag back and forth in a tight loop until an INT happens?
In the ISR the Stacked return address should be related
to the value of the flag you're toggling.

dp11
Posts: 951
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by dp11 » Sun Feb 08, 2015 12:23 am

Can you trigger a logic analyser from your led signal and see if there is a colleration with a preceding interrupt. If there is , add a little extra logic to record the PC when irqs fire. Then when the loop fails print out this recorded PC.

Its not uncommon in microcoded CPUs to have issues with something not being recoverable after an IRQ if the IRQ triggers at certain points in the micro code.

User avatar
TheCorfiot
Posts: 660
Joined: Mon Jan 08, 2007 5:22 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by TheCorfiot » Sun Feb 08, 2015 12:45 am

There is something weird going on with the Bus loading on these copros...

I have one which loves the Electron and works great in a Stock Model B..
Runs for hours...

I have another which I mentioned earlier that falls over when fitted to the above machines after 10mins, as mentioned earlier.

However this unstable copro when fitted to a seriously overloaded Model B, 1770 board, Econet, 12 Rom Board, Speech, 32K Ram card....basically no vacancy whatsoever runs for hours playing Elite copro?????

Tempted to build a special cable with Integrated 74LS245 covering D0 to D7.

It's odd to say the least.
By the way this is not a critiscism but Feedback so we can nail these issues :)

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Feb 08, 2015 6:49 am

Hi Dominic,
dp11 wrote:Can you trigger a logic analyser from your led signal and see if there is a colleration with a preceding interrupt. If there is , add a little extra logic to record the PC when irqs fire. Then when the loop fails print out this recorded PC.
I had already done the first part of this, and there is indeed a clear correlation with the 20ms VSync Event interrupt, which is the only interrupt that occurs.

I really like your idea about internally recording the program counter. It nicely gets around the problem of not enough I/O Pins. I will try this today.
dp11 wrote: Its not uncommon in microcoded CPUs to have issues with something not being recoverable after an IRQ if the IRQ triggers at certain points in the micro code.
The Zet core only checks and responds to interrupts at the end of an instruction. This is indicated by a additional bit in the microcode instruction that is auto-generated by the microcode ROM compiler.

As far as I can tell, because of this an the microcode for an instruction is not interruptable and will always run to completion. This is implemented in the next state logic, line 55.
https://github.com/hoglet67/CoPro6502/b ... t_nstate.v

The microcode is linear, and has no concept of repeating, so the REP prefix must be handled as a special case elsewhere in the design.

In my view, this issue has to be quite blatant. There are 50 interrupts/sec and I'm seeing one failure every 2 secs approx. So 1% of the time it is messing up. As the execution of the Basic interrupt is effectively asynchronous, there must be a lot of places where it is vulnerable.

I an wondering whether the REP instruction is not being properly restarted after an interrupt. I'll also try to write a test case specifically for this.

Many thanks,

Dave

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Feb 08, 2015 7:31 am

TC,

This is good useful data, thanks.
TheCorfiot wrote:Tempted to build a special cable with Integrated 74LS245 covering D0 to D7.
Jason can comment on this as well, but the Co Pro effectively already has one of these, in the level shifter driving the data: a 74LVC4245A (U3) - the last 3 digits of this part are 245.

For reference:
- the Co Pro schematic is here.
- the 74LVC4245A data sheet is here.

This device has very good drive capabilities (page 5). Specifically, it is rated to source or sink 24mA, which is the same or better than a 74LS245.

It's still possible adding an LS245 might help. For example, if the problem was due to severe ground bounce on the Co Pro when all the data lines switch at the same time. Inserting series resistors in the data lines (as suggested by Dave H) might also help.

Dave

dp11
Posts: 951
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by dp11 » Sun Feb 08, 2015 9:01 am

For high speed 6502 can you use the clk 2x output of the DLL to clock the block rams? Some clever multi cycle timing constraints might be needed.

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Feb 08, 2015 9:37 am

dp11 wrote:For high speed 6502 can you use the clk 2x output of the DLL to clock the block rams? Some clever multi cycle timing constraints might be needed.
I'm not how this would be different to what I'm doing at the moment.

Currently, I'm clocking the main clock at about 80MHz (12.5ns), but using a sync clock enable on the 6502 Core so it only changes state once every two cycles 25ns.

The memory is however clocked at the full 80MHz, and so memory reads happen on cycle where the 6502 is inactive, so the data is there ready for the 6502 on it's next active cycle. Writes happen on the second cycle.

There is probably a lot of slack in the second cycle, but I don't see how I could make use of it. Maybe it would be possible to come up with a multi phase clocking scheme, where the first cycle is 12.5ns, and the second cycle is say 5ns. But then I think timing constraints are harder to specify.

It turns out that the longest path the static timing analysis finds actually involves the 6502 and the tube. It starts at the 6502, includes address bit A15, the tube address decoding, full flag logic, back out to data bus bit D6, and back to the 6502. This path is 16 levels of logic, and is approx 12.5ns. It might help if we could break this path (or tell the router to ignore it, as there is really another 12.5ns in the second cycle for the data to settle.

Dave

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Feb 08, 2015 10:55 am

Bingo!

I tried dp11's (Dominic's) suggestion, and latched the program counter on the interrupt acknowledge cycle, in a way that can be read back.

Here's my test program:

Code: Select all

10 REM
20 GOTO 10
30 PRINT ~!&1008
40 GOTO 10
The address that was consistently being reported was physical address 0x177BC.

Disassmbling at this location gives the following:

Code: Select all

  	.data:0x000177b0	b746   mov    $0x46,%bh	
  	.data:0x000177b2	5e     pop    %si	
  	.data:0x000177b3	8bfe   mov    %si,%di	
  	.data:0x000177b5	b50d   mov    $0xd,%ch	
  	.data:0x000177b7	8ac5   mov    %ch,%al	
  	.data:0x000177b9	fc     cld	
  	.data:0x000177ba	f2ae   repnz scas %es:(%di),%al	
  	.data:0x000177bc	8bf7   mov    %di,%si	 
  	.data:0x000177be	e974ff jmp    0x00017735
So it looks like the offending instruction is probably:

Code: Select all

repnz scas %es:(%di),%al
What's interesting here is that there is only one prefix to this instruction, the f2 byte which is REPNZ. So it's not a bug with multiple prefixes.

I'm guessing that the REP prefix is simply lost during an interrupt.

Dave

User avatar
BigEd
Posts: 2588
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by BigEd » Sun Feb 08, 2015 1:48 pm

hoglet wrote:Currently, I'm clocking the main clock at about 80MHz (12.5ns), but using a sync clock enable on the 6502 Core so it only changes state once every two cycles 25ns.

The memory is however clocked at the full 80MHz, and so memory reads happen on cycle where the 6502 is inactive, so the data is there ready for the 6502 on it's next active cycle. Writes happen on the second cycle.
Arlet's core is capable of running at the same speed as the sync block RAM - but I realise it is only a 6502 core, so some work would be needed to upgrade it to a 'C02.

Ed

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Sun Feb 08, 2015 1:54 pm

That's why I started off with the Arlet core way back.
There might be an option to use the other clock edge somewhere to break the chain.

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Feb 08, 2015 1:56 pm

I've now managed write a test program that will reproduce the bug in a more controlled environment.
IMG_0800.JPG
The SCASB instuction is called Scan String. When used with a REPNZ repeat prefix, it is meant to scan a block of memory, terminating when a particular byte value is found.

This program sets up a block of memory, filled with zeros, except for a couple occurrences of &44 towards the end.

In the run in the photo, the buffer is &40 bytes long, and the byte being searched for is present at location &30 and again at location &38.

This code should always find the first occurrence, and return &31. What I am finding is that very occasionally it is returning the second occurrence, &39.

If I surround the REPNZ SCASB with CLI/STI to disable interrupts, it never fails.

This is actually much more subtle than I was expecting. I'm guessing the interrupt has to happen just as the byte is found. After the interrupt, the instruction is re-executed unnecessarily, causing the first occurrence to be missed. At least, that's what I think is happening...

Dave

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Feb 08, 2015 8:02 pm

One more bug squished :D :D :D

In Zet there are two versions of the microcode for handling an external interrupt. One version pushes current instruction onto the stack and is designed to be used when a repeat prefix is active, so the current instruction is continues to execute after the interrupt. The other version pushes the next instruction onto the stack. The bug was that if an interrupt occurred during the final instruction of a repeat block, then the wrong version was being used, and the instruction was incorrectly repeated.

Now in V482 Basic I can run the Benchmark suite without any errors:
IMG_0801.JPG
JHG's version of BBC Basic still crashes on start up, so this issue must be unrelated. I've double checked, and this works fine in the emulator, so there is still at least one more bug.

Dave

User avatar
sirmorris
Posts: 773
Joined: Wed Feb 11, 2009 12:18 pm
Location: oxfordshire uk
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by sirmorris » Sun Feb 08, 2015 9:02 pm

=D> =D> Another case closed MorseDave!! =D> =D>

dp11
Posts: 951
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by dp11 » Sun Feb 08, 2015 9:26 pm

Well done

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by firthmj » Sun Feb 08, 2015 10:01 pm

firthmj wrote:
How easy do you think it would be to put a clock multiplex of some kind in place to allow (for example) 4/8/16/32/64MHz selectable clock versions of the 65c02 design?

Could be instigated by getting the multi-loader to load the same design for multiple different DIP switch settings, and the 65c02 also looking at the DIP settings to select the speed.

I might have a play at creating something like that myself in the next couple of days...

Regards

Michael
In case it is of interest to anyone, I've now got a version of this design that can be loaded in as designs 8/9/10/11 (or any other 4 locations with the LSBs the same) and will switch between 32MHz,16MHz,8MHz and 4MHz based upon the two LSBs of the DIP switch.

It also seems to switch cleanly enough that you can switch the DIPs while it is running, and it doesn't miss a beat.

So it is easier to see whether the external RAM or multi-speed design is running, I've also switched to using the original 6502 External Co-Pro ROM, so the startup banner is different between the two designs - I'm not sure if there were any significant changes in the ROM that would make it desirable to stick with the Master Internal Co-Pro ROM.

The attached .ZIP is the changes against the latest Git Repo. It also includes my earlier gen_mcs script, modified to load the 6502fast design at the correct location in the flash.

Interestingly, my perception is that the Co-Pro is more stable running this design than the external RAM version - in particular, the ROM transfer seemed a little flaky before, but is now rock solid.

Dave - would you have any objection to me making an MCS of this version available, or would you prefer to prevent "forked" MCS files getting out there?

Regards

Michael
Attachments
6502fast_multisp.zip
(12.41 KiB) Downloaded 21 times
Had fun at the
Image
Meeting 13th May 2017

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by jgharston » Sun Feb 08, 2015 10:09 pm

firthmj wrote:So it is easier to see whether the external RAM or multi-speed design is running, I've also switched to using the original 6502 External Co-Pro ROM, so the startup banner is different between the two designs - I'm not sure if there were any significant changes in the ROM that would make it desirable to stick with the Master Internal Co-Pro ROM.
There are only three differences between the internal and external copro client roms, two are the title display "65C102" and the third is the OSWORD control block lengths for 5, 14 and 15 (read I/O memory, read RTC, write RTC) are the correct length (OSW 5 passes a 4-byte address so you can read all of I/O memory, OSW 14 reads a 25-byte string so you get all of the TIME string, OSW 15 sends a 32-byte string so you can set the clock with a full TIME string).

I would recommend using the internal CoPro ROM client as it has the correct OSWORD control block lengths.

There is one bug that John K discovered in that *GO doesn't correctly check the command is terminated, so, for example, *GOAD doesn't execute a command called GOAD but jumps to memory at &AD.
Last edited by jgharston on Sun Feb 08, 2015 10:11 pm, edited 1 time in total.

Code: Select all

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

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Feb 08, 2015 10:11 pm

firthmj wrote:Dave - would you have any objection to me making an MCS of this version available, or would you prefer to prevent "forked" MCS files getting out there?
No objection at all.

Might be good to follow the same naming convention I used earlier:
e.g. lx9_20150208_firthmj.zip

I'll add your changes and build scripts back into github when I get a moment.

Dave

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by hoglet » Sun Feb 08, 2015 10:18 pm

JGH, or anyone else for that matter...

I'm looking for suggestions for how to go about debugging the BBCBASIC startup crash. It ends up jumping into the weeds, then executing an illegal instruction. All before it gets the chance to print any banner.

Once it crashes, I'd like to hit break and use the monitor to see if the code has somehow been corrupted.

I started trying to work through the initialization code in the disassembly, but soon got lost. But it didn't look like there was much code before the banner.

Any idea what segment DOS will be loading the program to, or how to find out?

I've tried using the D86 debugger, but that just seems to clear the screen then hang.

I never was very comfortable on a DOS or Window machine :lol:

Dave

firthmj
Posts: 231
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 09, 2015 12:40 am

hoglet wrote:
firthmj wrote:Dave - would you have any objection to me making an MCS of this version available, or would you prefer to prevent "forked" MCS files getting out there?
No objection at all.

Might be good to follow the same naming convention I used earlier:
e.g. lx9_20150208_firthmj.zip

I'll add your changes and build scripts back into github when I get a moment.

Dave
Hi,

Here's an appropriately named MCS link for anyone who wants it. Following JGH's comments, I've swapped to having the original external RAM 6502 image use the old host ROM - given the new image seems to run reliably at 4MHz, this image is probably close to being redundant.

While doing that, I found a couple of things I'd got wrong in the previous ZIP file, so here's a new version that fixes those, and updates the code as per the above change.

This MCS file also includes the ZET fix Dave mentioned earlier, so the 80186 mode should run one of the BBC Basic versions.

Regards

Michael
Attachments
lx9_20150208_firthmj.zip
Zipped MCS file
(855.79 KiB) Downloaded 28 times
6502fast_multisp.zip
Updated code
(20.84 KiB) Downloaded 25 times
Had fun at the
Image
Meeting 13th May 2017

User avatar
jgharston
Posts: 3628
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 09, 2015 1:46 am

hoglet wrote:I'm looking for suggestions for how to go about debugging the BBCBASIC startup crash. It ends up jumping into the weeds, then executing an illegal instruction. All before it gets the chance to print any banner.
When something gets that far into the weeds I end up doing a moving quit-and-dump, I used this technique at Halifax to debug somebody's 6502 code (the thing that translated a *command into a CHAIN string poked into the keyboard buffer).

What this technique is is adding/patching in some sort of jump to a debug exit into the code, starting at the first location, then progressively just advancing the patch through the code one instruction at a time. (You can optimise the technique by binary chopping back and forth.) This at least tells you where the code bombs out.

The 80x86 environment does a debug register display on an illegal opcode, so what I'd do is copy BBCBASIC.EXE to BBCTEST.EXE, then OPENUP"BBCTEST.EXE" (using vanilla DOS BASIC) and BPUT an illegal opcode into the code, then try running it, or doing the similar process from D86/DEBUG.

If it doesn't even get as far as displaying the startup banner, then I'd suspect the initialisation code, one of the subroutines called around CS:003F, specifically the 'Check we can run on this hardware' call to CS:3E10. (See updated disassembly)
hoglet wrote:Any idea what segment DOS will be loading the program to, or how to find out?
DOS will load it to wherever DOS thinks is the next free area of memory, which could change from run to run.
hoglet wrote:I've tried using the D86 debugger, but that just seems to clear the screen then hang.
I've never used D86, but from the manual you can single-step through the code, so doing the above incremental debug test.

Edit: remember, a DOS binary has a 256-byte header, so if patching a file you need to add 256 to the addresses. So, for example:

Code: Select all

1000:001b loc_0000001b:
1000:001b bb0000               mov    bx, 00h                  Point to start of workspace at SS
1000:001e bc0003               mov    sp, 300h                 Initial startup stack
1000:0021 36c7070a09           mov    word ptr ss:[bx], 090ah  Set @% to &xxxx090A
1000:0026 83c302               add    bx, 02h                  Step past @% low word
1000:0029 32c0                 xor    al, al

1000:002b loc_0000002b:
1000:002b 368807               mov    ss:[bx], al              Clear workspace byte
1000:002e fec3                 inc    bl
1000:0030 75f9                 jnz    loc_0000002b             Loop to clear workspace

1000:0032 36c606fe0037         mov    byte ptr ss:[00feh], 37h
1000:0038 36c706ee009700       mov    word ptr ss:[00eeh], 97h
1000:003f e8ce3d               call   loc_00003e10             Check we can run on this hardware
1000:0042 891ee400             mov    [00e4h], bx
1000:0046 8916dc00             mov    [00dch], dx
I'd poke an illegal opcode (a quick skim suggests &F1 is an illegal opcode) into &42 (so PTR=&142), and try running it to see if it gets to the call 3E10. If it doesn't, poke into &38 (ie PTR=&138) and see if it gets that far. If it does, the problem is in the code at &3E10. Rinse and repeat. This is the level where debugging gets down to the metal.

Code: Select all

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

User avatar
TheCorfiot
Posts: 660
Joined: Mon Jan 08, 2007 5:22 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by TheCorfiot » Mon Feb 09, 2015 8:40 am

@firthmj

Thanks so much for your build, much appreciated.
Would it be possible for you guys to add a switch description diagram along with your updated mcs files please so it is clear what the dip switch settings actually select.

Many thanks to you all
:)

firthmj
Posts: 231
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 09, 2015 11:28 am

TheCorfiot wrote:@firthmj

Thanks so much for your build, much appreciated.
Would it be possible for you guys to add a switch description diagram along with your updated mcs files please so it is clear what the dip switch settings actually select.

Many thanks to you all
:)
I did realise after posting that I should probably have detailed this!

The settings for mine are the same as previously:

1 2 3 4
0 0 0 0 65C02 (Original 4MHz using external RAM)
0 0 0 1 Z80
0 0 1 0 6809
0 0 1 1 x86
0 1 0 0 BIST

Plus the following 4 new options:

1 2 3 4
1 0 0 0 65C02 Internal RAM, 32MHz
1 0 0 1 65C02 Internal RAM, 16MHz
1 0 1 0 65C02 Internal RAM, 8MHz
1 0 1 1 65C02 Internal RAM, 4MHz

If you can access the DIP switches while the board is plugged in (i.e. if you have an extension cable) then for the "DIP switch 1 set" design you can change DIP switches 3 and 4 on the fly to change the clock speed. Any other DIP switch changes require a power cycle to reload the firmware.

I think JGH has already proposed a DIP switch address reshuffle - I guess that may be looked at if it is decided that the original 4MHz external RAM 6502 Co-Pro is obsolete.

Regards

Michael
Had fun at the
Image
Meeting 13th May 2017

User avatar
TheCorfiot
Posts: 660
Joined: Mon Jan 08, 2007 5:22 pm
Contact:

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by TheCorfiot » Mon Feb 09, 2015 4:09 pm

Thank you very much for taking the time

Much appreciated
:)

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

Re: Matchbox sized 6502 / Z80 / 6809 Co Pro

Post by flynnjs » Mon Feb 09, 2015 6:51 pm

Note that the 6502 that uses the external RAM can actually
page it all in, so if you need lots of RAM it might still be
applicable.

User avatar
jgharston
Posts: 3628
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 09, 2015 8:44 pm

firthmj wrote:I think JGH has already proposed a DIP switch address reshuffle - I guess that may be looked at if it is decided that the original 4MHz external RAM 6502 Co-Pro is obsolete.
I certainly remember the ROM type bytes more easily than the current DIP settings - and it would be useful if we ever got the ability for the host computer to tell the matchbox what CPU to run, then the host can select the right CPU for the code it wants it to run by just writing the ROM type byte to it.

Is the CoPro speed hardwired into the specific CPU implementation - could it not be selectable independently of the CPU selected?

Three of the Tube status registers are read-only, so they could be used to write control information to - I'd recommend only using the bottom 6 bits to match Status1. For example, for example, LDA #ROMTYPE:STA &FEE6 could over-ride the DIP switches until the next power cycle(*), LDA #SPEED:STA &FEE4 could specify clock speed.

(*)Programatically, you'd have to put the matchbox CPU in the reset state by setting the RST bit in the control register at &FEE0, the change the CPU, whereupon the new CPU would be held in the reset state, then release the reset state to allow the CPU to start up.

Though, while typing this, it occurs to me - could the "deselected" CPU just hibernate until it is reselected? I admit I haven't delved too deeply into the hardware implementation of the matchbox.

Code: Select all

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

Post Reply