ICE T65/Z80/6809

[hoglet]

Hi all,

Sorry I've been a bit quiet of late. I've been a bit distracted by a couple of things that life has thrown at me recently.

Anyway, things are starting to return to normal, and this weekend I've been playing with something new. A few weeks ago I've was quite intrigued by the Acorn Atom 6502 Tracer thread. So much so, I thought I would have a go at something along these lines myself.

I had a spare GODIL, having just reconfigured my original Atom back to to using a 6847. So I thought I would try to make use of this to build an bus monitor / single stepper.

One side of this connects to the following signals on PL6/7:
- Phi2
- A[15:0]
- RNW
- Sync
- nRST
- Rdy

The other side connects to a serial console via a 3.3V RS232 <-> USB cable.

For fun, I also wired in a HD44780 style LCD display.

Here's the results:

This is a sample session over the serial console, which gives you an idea of what is possible.

Code: Select all

Atom Bus Monitor version 0.11
Compiled at 17:53:13 on Jun  7 2015
Tracing every 1 instructions while single stepping
6502 paused...
0000
>> help
Atom Bus Monitor version 0.11
Compiled at 17:53:13 on Jun  7 2015
Commands:
    help
    reset
    interrupt
    address
    step
    trace
    blist
    break
    bclear
    continue
>> s 10
Stepping 10 instructions
FF3F
FF41
FF44
FF47
FF48
FF41
FF44
FF47
FF48
FF41
>> break fe94
Setting breakpoint at FE94
0: FE94
>> c
0: FE94
6502 free running...
Breakpoint hit at FE94
>> break 2800
Setting breakpoint at 2800
0: 2800
1: FE94
>> bclear 1
Removing breakpoint at FE94
0: 2800
>> c
0: 2800
6502 free running...
Breakpoint hit at 2800
>> s
Stepping 10 instructions
2802
2805
2807
280A
2C0E
2C0F
2C11
2C12
2C14
2C16
>> reset
Resetting 6502
>> s 1
Stepping 1 instructions
FF3F
>> s 1
Stepping 1 instructions
FF41
>> s 1
Stepping 1 instructions
FF44
>> s 1
Stepping 1 instructions
FF47
>> c
0: 2800
6502 free running...
Interrupted at FE82
>> reset
Resetting 6502
>> s1
Stepping 1 instructions
FF3F
>> 

I've tried to make it as compatible as I can with the debugger in Atomulator.

The FPGA really just contains two things:
- Some single stepper / break point hardware sitting on the Atom expansion bus
- An AVR8 Soft Core and a bit of firmware written in C

Everything is on github:
https://github.com/hoglet67/AtomBusMon

Here's the top level VHDL:
https://github.com/hoglet67/AtomBusMon/ ... BusMon.vhd
which is surprisingly minimal.

And here's the C code that runs on AVR8 core:
https://github.com/hoglet67/AtomBusMon/ ... omBusMon.c

What's really cool is that this is working with a real 6502 and a real Atom, and just plugs into PL6/7. No other mods are required, nor any special software on the Atom. You can be running any program on the Atom, and with the press of a switch interrupt it and start single stepping.

If it were possible to see the data bus values on PL6/7 (which would need a small mod) then we could even add op-code display functionality.

The other thing I was thinking of trying was to include a 6502 core, so that the whole thing would just plug into the 6502 socket. We could call this variant AtomICE. This also might work on the Beeb as well (if the GODIL can cope with the data bus loading)

If anyone wants to give this a try, I'm happy to help.

Dave

[roland]

This is really astonishing I know the original author of the stepper worked a few months on it and you redo it just in a weekend
Great job again!

[hoglet]

Hi Roland,

I can think of several directions to take this now:

1. Add some more features

1a. Next up would be to add breakr and breakw commands to allow breakpoints to be triggered on reading or writing particular memory addresses.

1b. Another feature would be to store the last N instruction addresses (e.g. in a FPGA block RAM), and provide a command to dump these. This would then act like a mini embedded logic analyzer. Useful for code that crashes the 6502.

2. Make a small PCB that contains a 64 pin IDC connector and a 40 pin DIL socket.

3. Design a cost reduced version that used a CPLD (or two) and a real AVR processor. I'm not sure if this is worthwhile, because a PCB would be needed, and the GODIL is just so much more flexible. I just hope Trenz don't run out again, with all the interest in the new Atom.

4. Change the pinout to match the 6502, and then it could just be plugged into a socket piggy-backed onto a 6502. This would have the advantage that the data bus could also be observed, allowing the single stepping to display the op codes being executed.

5. Include a 6502 core as well, which would allow this to replace the 6502 and act as a 6502 In Circuit Emulator. This could (in principle) be used in any 6502 based computer. The caveat being timing/bus drive might be different to a real 6502. With the 6502 in the GODIL, it would be possible to display the current register values when single stepping.

6. Get some other people playing with this... Much more fun then

Dave

[sirmorris]

Looks like there are no more big Godils. I was tempted 'till I saw that they're nearly 75 quid delivered :/

[hoglet]

Looks like there are no more big Godils. I was tempted 'till I saw that they're nearly 75 quid delivered :/

I agree they are a bit pricey, and Roland seems to have bought up the entire world stocks!

Another option would be to use the Papilio One, which has the advantage of having the hardware for Serial-over-USB already integrated.

You would have to be a little careful with 5V compatibility, but as most of the signals are inputs, just using 390R resistors would be sufficient for these I think. Or you could make a simple wing with some proper level shifters.

Seed Studio have the Papilio One 250K for £24.78 + shipping
http://www.seeedstudio.com/depot/Papili ... p-809.html

Dave

[hoglet]

Hi Kees,

The Atombus monitor looks promising, it would be great if you could add the Watchr and Watchw instructions. I used these a lot in Atomulator to check all AtoMMC registers.

What's interesting/more challenging about the Watch commands in Atomulator is they operate while the 6502 continues to free-run (unlike breakpoints, which stop the 6502).

In AtomBusMon watch events would need to be added into some sort of hardware queue, which would then allow the AVR core to log them to the serial port at it's leisure.

This is possible, but is a bit more involved than breakpoints, which can be dealt with one at a time.

Dave

[sirmorris]

I already have a papilio-1 500k. It has an Atom shield atop right now...

[hoglet]

Hi all,

I've made some good progress on this over the last few days.

The main focus has been adding read/write breakpoints, and also read/write watches.

Here's the latest list of commands:

Code: Select all

Atom Bus Monitor version 0.11
Compiled at 18:17:57 on Jun 11 2015
Commands:
    help
    reset
    interrupt
    address
    step
    trace
    blist
    breaki
    breakr
    breakw
    watchi
    watchr
    watchw
    bcleari
    bclearr
    bclearw
    wcleari
    wclearr
    wclearw
    continue
>>

This is modelled on the debugger command set in Atomulator.

To try to avoid watches being lost, I've made use of a 512x36 bit FIFO in the FPGA, and then to simply the design I also feed breakpoints through this.

This has been a lot of fun, and is the first serious C code I've done in about 20 years.

There still a few glitches to work out, but it was useful enough this afternoon to help Kees debug a problem in Jim Bagley's Atom port of his video player, which worked in Atomulator but not on the real Atom.

Here's an example session, setting some watches on the AtoMMC hardware register, then and hitting break:

Code: Select all

Atom Bus Monitor version 0.11
Compiled at 18:17:57 on Jun 11 2015
Tracing every 1 instructions while single stepping
6502 free running...
Interrupted at FE7D
>> watchw b400
Write watch set at B400
>> watchw b401
Write watch set at B401
>> watchw b402
Write watch set at B402
>> watchw b403
Write watch set at B403
>> watchr b400
Read watch, write watch set at B400
>> watchr b401
Read watch, write watch set at B401
>> watchr b402
Read watch, write watch set at B402
>> watchr b403
Read watch, write watch set at B403
>> bl
0: B400: Read watch, write watch
1: B401: Read watch, write watch
2: B402: Read watch, write watch
3: B403: Read watch, write watch
>> c
6502 free running...
Write watch hit at E09F accessing B400
Read watch hit at E0A5 accessing B400
Write watch hit at E09F accessing B400
Read watch hit at E0A5 accessing B400
Write watch hit at E0AE accessing B400
Read watch hit at E0B4 accessing B400
Write watch hit at E64F accessing B400
Read watch hit at E659 accessing B400
Read watch hit at E659 accessing B400
Read watch hit at E659 accessing B400
Write watch hit at E053 accessing B400
Read watch hit at E059 accessing B400

I was thinking of adding a cycle counter, so the relative time between accesses could be seen.

Dave

[sirmorris]

Looking awesome That was a great catch you made finding the problem with the un-waited-for joystick configurating..!

[sirmorris]

If I may proffer a suggestion - It would be a real boon to hardware developers if there were a couple of IO inputs available for external triggers. In this way I would have been able to feed the 'busy' strobe on AtoMMC into the debugger to - ooh perhaps log the instruction or address that was being executed at that cycle. Break on a high-low transition, that kind of thing. I expect I'm really asking for the moon on a stick now - but some kind of programmable exception would help there too. It might just be an additional input to the break logic - 'break if you detect a write to xxxx and input y is high' kind-of thing... AND/OR operators come to mind.

C

[hoglet]

Hi Charlie,

This is a good idea - I'll give it some thought. The challenge is getting the right balance between flexibility and usability.

Making watches or breakpoints conditional on the value of one of a small number of external triggers should be very doable.

Some concrete examples of how this might be used would help I think.

Another area to think about is what monitoring would be useful on the IRQ and NMI signals.

Dave

[1024MAK]

This latest bit of discussion reminded me of this over on 6502.org

Although you would need to use a CMOS CPU...

Mark

[sirmorris]

Concrete example:

IO 1 connected to 'busy strobe' on AtoMMC PIC

breakpoint1:
write to b40x AND IO1=true

This would break if you tried to write to AtoMMC whilst it was busy and therefore unable to respond to your write.

[hoglet]

OK, I've thought about this a bit, and here's how I'm thinking of doing it. Feedback welcome

The Atom Bus Mon contains 8 address comparators, allowing 8 in dependant addresses to be monitored.

Currently each address comparator has 22 bits:
- address (16 bits)
- break on read (1 bit)
- break on write (1 bit)
- break on execute (1 bit)
- watch on read (1 bit)
- watch on write (1 bit)
- watch on execute (1 bit)

I think the next version will have 24 bits:
- address (16 bits)
- read (1 bit)
- write (1 bit)
- execute (1 bit)
- break/watch (1 bit)
- external trigger function (4 bits)

I've saved a couple of bits, because it doesn't make sense to have a watch and a breakpoint at the same address.

The address part would only be considered if one or more of the read/write/execute bits were set.

The external trigger function needs to specify a function of the two external trigger inputs (E0 and E1).

I think 4 bits is sufficient to specify all possible functions of 2 inputs:
0 0 0 0 - Never - this would effectively disable the address comparator
0 0 0 1 - E0 and E1
0 0 1 0 - (not E0) and E1
0 0 1 1 - E1
0 1 0 0 - E0 and (not E1)
0 1 0 1 - E0
0 1 1 0 - E0 xor E1
0 1 1 1 - E0 or E1
1 0 0 0 - (not E0) and (not E1)
1 0 0 1 - E0 xnor E1
1 0 1 0 - not E0
1 0 1 1 - (not E0) or E1
1 1 0 0 - not E1
1 1 0 1 - E0 or (not E1)
1 1 1 0 - (not E0) or (not E1)
1 1 1 1 - Always - this would mean the external triggers were ignored

What I'm wondering is if all 8 address comparators should share the same 2 external trigger inputs.

Dave

[hoglet]

Hi Guys,

External triggers are now implemented.

Here's a session showing now how easy it is to find the bug in DLAIR that had us scratching our heads a few days ago.

The external input T0 was connected to pin 7 on the AtoMMC PIC, which I think is the activity strobe. The PIC takes this pin low when it is busy and unable to accept further commands. Any of the watches firing indicate a command will be ignored.

Code: Select all

Atom Bus Monitor version 0.22
Compiled at 13:36:00 on Jun 13 2015
Tracing every 1 instructions while single stepping
6502 free running...
Interrupted at FE81
>> help 
Atom Bus Monitor version 0.22
Compiled at 13:36:00 on Jun 13 2015
Commands:
    help
    reset
    step
    trace
    blist
    breaki
    breakr
    breakw
    watchi
    watchr
    watchw
    bcleari
    bclearr
    bclearw
    wcleari
    wclearr
    wclearw
    trigger
    continue
Trigger Codes:
    0 = Never
    1 = ~T0 and ~T1
    2 = T0 and ~T1
    3 = ~T1
    4 = ~T0 and T1
    5 = ~T0
    6 = T0 xor T1
    7 = ~T0 or ~T1
    8 = T0 and T1
    9 = T0 xnor T1
    A = T0
    B = T0 or ~T1
    C = T1
    D = ~T0 or T1
    E = T0 or T1
    F = Always
>> watchw b400 5
Write watch set at B400
>> watchw b401 5
Write watch set at B401
>> watchw b402 5
Write watch set at B402
>> watchw b403 5
Write watch set at B403
>> bl
0: B400: Write watch (trigger: ~T0)
1: B401: Write watch (trigger: ~T0)
2: B402: Write watch (trigger: ~T0)
3: B403: Write watch (trigger: ~T0)
>> c
6502 free running...
Write watch hit at 32CE accessing B400
Write watch hit at 3271 accessing B403
Write watch hit at 3271 accessing B403
Write watch hit at 3271 accessing B403
Write watch hit at 3271 accessing B403
Write watch hit at 3271 accessing B403
Write watch hit at 3271 accessing B403
Write watch hit at 3271 accessing B403
Write watch hit at 3271 accessing B403
Write watch hit at 3271 accessing B403
Write watch hit at 327E accessing B403
Write watch hit at 28D0 accessing B400
Write watch hit at 328D accessing B401
Write watch hit at 28D0 accessing B400
Write watch hit at 32C6 accessing B400

The updated code is pushed, and the change to the VHDL was very small:
https://github.com/hoglet67/AtomBusMon/ ... 00e6508484

Dave

[bprosman]

Now that the Godil's indeed seem to be hard to get, any other board you could recommend ? As this doestn have to fit in the Acorn case footprint/size is not so critical.

[hoglet]

Now that the Godil's indeed seem to be hard to get, any other board you could recommend ? As this doestn have to fit in the Acorn case footprint/size is not so critical.

I think there are a couple of options.

1. There are stocks of the bare GODILs:
http://shop.trenz-electronic.de/en/TE02 ... are-module
and they sell a 48 pin DIL connector separately:
http://shop.trenz-electronic.de/en/2531 ... plug?c=128

There is also a bare GODIL with USB, which would then connect directly to a laptop/PC for the console:
http://shop.trenz-electronic.de/en/TE02 ... 3S250E-USB

2. The Papilio One uses the same FPGA:

http://www.seeedstudio.com/depot/Papili ... p-809.html
and is pretty cheap at the moment.
Edit: Out of stock, a few left here:
http://store.gadgetfactory.net/papilio-one-250k/
I hope these aren't being discontinued.

But this would need a custom wing designing that contains:
- 5V to 3.3V level shifters
- MAX232 RS232 interface (or USB variant)
- a couple of push buttons
- a couple of LEDs
- an optional LCD display (or connector for one)
- a 64 way IDC connector to the Atom

The problem is there aren't that many FPGA boards that are 5V tolerant out of the box. I think for inputs you might get away with 390R series resistors.

Anyone else got any ideas?

Dave

[oss003]

Nice job Dave ........ now, let's create some problems ...

Greetings
Kees

[hoglet]

Maybe another reason to stick with the GODIL is I was eventually going to try to embed a 6502 core as well, so this could actually replace the processor in the target system.

The advantage of this would be two fold:
- access to the databus as well as the address bus
- the ability to display the 6502 registers when paused

I have no idea if this will actually work, or indeed whether there is sufficient space remaining in the 250K FPGA, but worth a go.

Roland, have you had any recent communications with Trenz about the long term availability of GODILs?

Dave

[roland]

Roland, have you had any recent communications with Trenz about the long term availability of GODILs?

Dave

I will send them a message on Monday. I think they produce some godils if they have some orders for them.

[hoglet]

Hi all,

Today I've created a second version of Bus Mon, with the following changes:
- Pinout updated to be compatible with the 6502
- GODIL power jumpers changed to match 6502
- Added a T65 6502 core

I was then able to replace the 6502 in my Atom with the GODIL, and get an Acorn Atom prompt quite quickly.

But then it took me the rest of the day to get AtomMMC working. With Bus Mon I could see it was getting stuck at #E09D which is the heart beat code. But when I wrote a BASIC version of the heartbeat, this worked fine.

In the end it turned out to be a clock timing issue. It's quite hard in an FPGA to generate Phi1 and Phi2 in the same way that the real 6502 does, as the FPGA is much faster. What was happening was the address bus was changing too quickly, and AtomMMC ended up latching the next bus address rather than the current one.

The fix was to use the GODIL's 49MHz clock to re-sample the 1MHz 6502 clock, allowing Phi1 and Phi2 to be shifted in 20ns units. Shifting by 40ns was sufficient to make it all work.

The next step with Bus Mon is to add support for the following:
- data bus observation in watches/breakpoints
- display of the 6502 registers when single stepping
- read and write host memory when the 6502 is paused

I'm also going to try this in a couple of other systems:
- Roland's New Atom
- a Beeb model B

I'd be very surprised if it worked in the Beeb, given the data bus loading.

Dave

[sirmorris]

amazeballs

[1024MAK]

amazeballs

^^^ what he said



Mark

[1024MAK]

I'm also going to try this in a couple of other systems:
- a Beeb model B

I'd be very surprised if it worked in the Beeb, given the data bus loading.

Well, last year (early 2014) I bought some 4MHz UM6502CE CPUs from Dave H. and tested them in one of my Beebs. Most of them worked fine.

I keep meaning to test a CMOS CPU (as the issue 7 Beeb still has ZIP socket mounted on a normal socket which is still plugged into the PCB socket).

So you may find that it does work okay. The only thing I would say, is having the bus and cycle timing correct is a lot more Important in a Beeb due to the video system accessing the DRAM in between the CPU accesses.

Mark

[hoglet]

The only thing I would say, is having the bus and cycle timing correct is a lot more Important in a Beeb due to the video system accessing the DRAM in between the CPU accesses.

I've just taken a look at the Beeb schematic, and I'd wager it's not going to work.

On the Atom nothing else uses the signal driving Phi0 (the 6502 clock input), and so it's not important maintain the correct timing between Phi0 and Phi1/2. This allows me to safely re sample with a chain of flip-flops and not worry about the overall delay.

Oh, and it's also running at 2MHz.

Edit: Also, although the Xilinx FPGA contain some very clever DCMs (smart phase locked loops for clock generation), these aren't usable on the Beeb because the input clock Phi0 is too slow, and also the jitter caused by the Beeb slowing this clock to 1MHz at times causes them to loose lock.

On the other hand, I could use one to increase the 49.152MHz clock on the Xilinx to 200MHz, and that would allow me to position the Phi1/2 clock edge with a 5ns resolution.

Dave

[Multiwizard]

amazeballs

^^^ what he said



Mark

What they said...


Greetings, Wim...

[hoglet]

Well, I just tried it in the New Atom, and it kind-of works. At least, there was no magic smoke.

It starts up fine at both 1MHz and 2MHz, and loads the AtomMMC menu reliably.

But when you try to actually load a program from the menu you get a "NO PATH" error. Which is a bit weird.

Dave

[BigEd]

If only you had a tracer!

[hoglet]

If only you had a tracer!

In the end I didn't need to use the tracer.

It seemed very likely to be a clock timing issue, so I brought Phi2 forward by one additional 20ns chunk, and now it's pretty reliable.

What I have ended up with is a synchronous T65 core clocked of an internal clock, and an external Phi2 clock that is 40ns earlier that this.

This should give ~40ns hold time on signals like address, R/W etc following the falling edge of Phi2.

Looking at the data sheets for the various 6502 I have:
- SY6502 - tADH = 30ns (min)
- R65C02 - tHA = 15ns (min)
(all wrt falling edge of Phi2)

It's surprising that 20ns was not sufficient. I'll take a look on the scope this evening.

Maybe in practice there is much more hold time than the datasheet specifies.

Dave

[BigEd]

Does the T65 go high-impedance on the databus for the first half of the cycle? If so, bus capacitance should help with late readers. If not, then it's more important that it doesn't drive the new value too soon.