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.

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

Last edited by hoglet on Sat Aug 29, 2015 5:38 pm, edited 1 time in total.

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.

sirmorris wrote: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.

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:

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.

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.

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

Last edited by hoglet on Sat Jun 13, 2015 3:17 pm, edited 1 time in total.

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.

hoglet wrote: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.

1024MAK wrote: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

Last edited by hoglet on Mon Jun 15, 2015 6:07 am, edited 1 time in total.

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.