ICE T65/Z80/6809

discussion of games, software, hardware & emulators relating to the Acorn Atom and Acorn System machines.
obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Fri Jan 17, 2020 5:16 pm

Update:
hoglet wrote:
Tue Oct 22, 2019 2:38 pm
One idea to consider...
1 - use my existing adapter board and on the bottom mount a 40-pin SMT DIP socket, like one of these.
2 - make up a short cable with a pair of 40-pin IDC 0.6" DIP Headers and some 40 pin IDC cable. These are hard to find, but do exist.
3 - solder a second CPU socket onto the bottom of your CPU board

Step (3) is necessary because I think step (2) mirrors the connections.
You do have to do (3) but that is because you start out upside down. There is no way to use two 40-pin IDC DIP headers and turn that around. Unless you separate the ribbon cable and swap every 2 wire-pairs... Actually might try that :D I'll put some double sided tape on the cover and stick the wires to that - see how that goes... Edit: went well. 8)

I also found out that the 40-pin DIP headers I've got have pin 1 of the DIP on wire 2 of the ribbon cable. That is so backward. With the same trouble they could have made a saner version... :roll:

The parts for my adapter board are on their way (even had some 100nf laying around, because they are nowhere to be found right now) so it should not be long before I can start on that.

obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Tue Jan 21, 2020 7:25 am

I have assembled Dave's Adapter Board last evening and encountered no problems. The description was clear - I think I made no mistakes (famous last words)

For vNext of the board it might be an idea to make the pads for the (reversed) Z80 DIP40 socket twice as long - that way a normal DIP40 socket with its legs bend over will fit better.

I was planning on seting up a NOP test* to take the Z80 ICE for a spin.
Any recommendations for testing - making sure I programmed the FPGA with the correct version and testing the adapter board?

*) NOP test is where you provide a clock -usually NE555 based- and tie all data lines to GND (using an R) and monitor the Address lines.

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

Re: ICE T65/Z80/6809

Post by hoglet » Tue Jan 21, 2020 9:25 am

obiwanjacobi wrote:
Tue Jan 21, 2020 7:25 am
I was planning on seting up a NOP test* to take the Z80 ICE for a spin.
Any recommendations for testing - making sure I programmed the FPGA with the correct version and testing the adapter board?

*) NOP test is where you provide a clock -usually NE555 based- and tie all data lines to GND (using an R) and monitor the Address lines.
You can program the FPGA with the Z80 specific bitstream (icez80.mcs), but you can also program it with the multi-boot bitstream (icemulti.mcs). This reads the ID resistors on the adapter and then loads the appropriate design.

Regarding the NOP test, I haven't done any testing at very low clock rates. So there may be issues. For example, the reset command asserts reset for 1ms. If the clock speed is very slow, then this could be missed.

Also, with the ICE, there is no need to slow the clock down anyway, as one of the core capabilities is the ability to single step.

Dave

obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Wed Jan 22, 2020 11:02 am

I have used the Z80 bitstream and Adapter assembly instructions (only populated R11 for instance). I am only interested in the Z80 at this time.

After some testing it keeps complaining about a 'missing clock'. Not sure how fast my clock actually is but it is running.

In this mode it also keeps running in single stepping mode. The address lines are active while in single step mode. Repeatedly stepping (enter) gives gaps in the addresses.

Code: Select all

>> s
Stepping 1 instructions
00.011616 : 0B55 : 00          : NOP
*** missing clock ***
>> s
Stepping 1 instructions
00.011690 : 0B68 : 00          : NOP
*** missing clock ***
>> s
Stepping 1 instructions
00.011764 : 0B7A : 00          : NOP
*** missing clock ***
Is this 'User Error' / RTFM or...?

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

Re: ICE T65/Z80/6809

Post by hoglet » Wed Jan 22, 2020 1:06 pm

obiwanjacobi wrote:
Wed Jan 22, 2020 11:02 am
Is this 'User Error' / RTFM or...?
Probably neither of those....

There is handshaking in the hardware to ensure commands from the AVR core to the Bus Monitor logic are not lost, and this handshaking involves the target system clock. If this clock is too slow, a timeout will occur in the AVR software, which is fed back to the user as a "Clock Missing" error.

Are you using a 555 to generate the clock? What are the values of Ra, Rb and C?

If the clock is less than 250KHz, this could be the problem, as I haven't tested at all at such low clock rates.

The other possible problem here is if the clock has relatively slow edges, and there is lots of system noise, then it's possible the FPGA is seeing multiple clock edges. [ Somewhat off topic, but the real Z80 specifies maximum rise/fall times. For the Z8400A this is 30ns. The output of a 555 is typically 100ns rise/fall times, so this would not need this requirement. ]

A photo of your current setup would help as well...

Can you try it with a faster clock (~1MHz) from a Crystal oscillator module?

It would be possible to patch the software to extend the timeout. The code is here:
https://github.com/hoglet67/AtomBusMon/ ... Mon.c#L751

The timeout value of 10,000 was somewhat arbitrary, and I don't really have an idea of what speed system clock that would correspond to. I should try to work that out. The reason for the timeout is to avoid the command line hanging (which is not user friendly at all!).

Dave

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Wed Jan 22, 2020 2:22 pm

Also, with the ICE, there is no need to slow the clock down anyway, as one of the core capabilities is the ability to single step.
Was also curious why you would use a "slow clock" when single-step is available.

obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Wed Jan 22, 2020 6:34 pm

hoglet wrote:
Wed Jan 22, 2020 1:06 pm
There is handshaking in the hardware to ensure commands from the AVR core to the Bus Monitor logic are not lost, and this handshaking involves the target system clock. If this clock is too slow, a timeout will occur in the AVR software, which is fed back to the user as a "Clock Missing" error.

[...]

If the clock is less than 250KHz, this could be the problem, as I haven't tested at all at such low clock rates.
This is the info I was after.

I will try with a faster clock later.
On my real Z80 system I also use a variable clock - I will have to (remember to) set that to a high-ish setting.
bprosman wrote:
Wed Jan 22, 2020 2:22 pm
Was also curious why you would use a "slow clock" when single-step is available.
Using a NE555 is a simple way to build a clock generator on a bread board. I usually do this for testing and I usually run things slow to really see what is going on...

obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Sat Jan 25, 2020 6:48 pm

I assembled my Z80 rig and tested out the ICE. I only had time for a quick test run. This is what I have found so far:
At higher clock settings I do not get the 'missing clock' message any more. I loaded a 'hello world' test program that I first tested with the real Z80 in there, just to make sure it all worked - which it did. The text message was send over serial to the PC.

Then I replaced the real Z80 with the ICE and reloaded and ran the test program again. No output this time. I suspect it has something to do with how I do output on my Z80 system. I did not have time to examine it thoroughly, but I think it could be connected to how I use the WAIT signal.

Basically when the Z80 (or ICE) outputs on a specific address -to output a character- the WAIT signal is activated for the logic that passes it onto the PC to have enough time to read the data bus and do its thing. This 'logic' is a PSoC5 btw. If you're interested I can tell you more.

To my mind the use of WAIT this way would be the reason why it exists but perhaps you (Dave) can see a problem with it...?
Any suggestions on how to debug this are very welcome. I can debug the code that is in the PSoC so I can put a break point on where these output characters are handled for instance - just haven't had time to do it yet (perhaps tomorrow)...

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

Re: ICE T65/Z80/6809

Post by hoglet » Sat Jan 25, 2020 7:01 pm

obiwanjacobi wrote:
Sat Jan 25, 2020 6:48 pm
I assembled my Z80 rig and tested out the ICE. I only had time for a quick test run. This is what I have found so far:
At higher clock settings I do not get the 'missing clock' message any more. I loaded a 'hello world' test program that I first tested with the real Z80 in there, just to make sure it all worked - which it did. The text message was send over serial to the PC.

Then I replaced the real Z80 with the ICE and reloaded and ran the test program again. No output this time. I suspect it has something to do with how I do output on my Z80 system. I did not have time to examine it thoroughly, but I think it could be connected to how I use the WAIT signal.

Basically when the Z80 (or ICE) outputs on a specific address -to output a character- the WAIT signal is activated for the logic that passes it onto the PC to have enough time to read the data bus and do its thing. This 'logic' is a PSoC5 btw. If you're interested I can tell you more.

To my mind the use of WAIT this way would be the reason why it exists but perhaps you (Dave) can see a problem with it...?
I can't immediately see a problem with this.

ICE-Z80 has been tested in several different systems that use WAIT.

How long roughly is WAIT being asserted for?
obiwanjacobi wrote:
Sat Jan 25, 2020 6:48 pm
Any suggestions on how to debug this are very welcome. I can debug the code that is in the PSoC so I can put a break point on where these output characters are handled for instance - just haven't had time to do it yet (perhaps tomorrow)...
Yes, I would set a breakpoint on the output routine, and just make sure it's being called as you would expect.

You could also single step through it, and look out how many cycles the OUT with the wait states seems to be taking

In fact, do post an log of this, so we can follow along.

Dave

obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Sun Jan 26, 2020 11:06 am

I went back to the bread board. Got the clock from my Z80 system (no more missing clock).

I can see a difference with how RESET is handled. The Z80 puts its Address and Data bus in hi-Z and the control signals in inactive-state. The ICE keeps the address lines hard-low. I toggle RESET (long time period) to suspend the Z80.

I ran the hello world program with a real Z80 CPU and with the ICE while monitoring control lines like wait, rd, wr, mem and IO req.
The Z80 CPU gave a completely expected picture. Every so often an output instruction was issued to output a character and the WAIT signal was asserted to slow things down for the System Controller (that has to forward it to the PC over serial/USB).

Z80 CPU character output overview.
Image
Each IOReq-WR is a character output.

Z80 CPU Output-Wait Detail
Image

Then I ran the same program with the ICE. A completely different picture emerged. After some investigation I saw that my MMU was not being initialized properly. I have 4k memory pages and most of the mapping was set to 0. That means the first 4k of memory was repeated again and again.
By hot-swapping the ICE I was able to get my MMU initialized correcty and reran the program. Still a completely different picture emerged.

ICE character output overview
Image
Looks like a totally different program is executing...

ICE Output-Wait detail
Image
Wait does not seem to be the problem. But I am missing a WR here... :shock:

I think I first have to investigate why the ICE is interfering with my system initialization.
Then why the execution is so different from using a real CPU. Of course with my MMU I must first make sure the system is setup properly - else I'd be chasing ghosts...
Attachments
Z80 hello-world overall.png
Z80 hello-world output.png
ICE hello-world overall.png
ICE hello-world output.png
Last edited by obiwanjacobi on Sun Jan 26, 2020 5:17 pm, edited 3 times in total.

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

Re: ICE T65/Z80/6809

Post by hoglet » Sun Jan 26, 2020 12:15 pm

obiwanjacobi wrote:
Sun Jan 26, 2020 11:06 am
I can see a difference with how RESET is handled. The Z80 puts its Address and Data bus in hi-Z and the control signals in inactive-state. The ICE keeps the address lines hard-low. I toggle RESET (long time period) to suspend the Z80.
OK, that's definitely a bug that I will fix.

I can't see the images in the above post. Could you edit the post and upload them as attachments.

Dave

obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Sun Jan 26, 2020 2:18 pm

I think I'll wait for your fix then try again.
Images are attached.

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Sun Jan 26, 2020 3:04 pm

Hi Dave,

Today i tried the ICE-T65 my Junior computer clone. Unfortunately a No-Go. Neither with the EEPizza board nor with the Godil version which has confirmed to be working in my Atom.

I also made a small adapter with the "Light pull-ups" though the Elektor design has pull-ups.
Tried a simple memory test but that failed.
Maybe I'm overlooking something.

Doublechecked and the EEPizza version DOES work on my Acorn Atom as well.
schematic_junior_computer.jpg
IMG_1670.jpg
IMG_1671.jpg
IMG_1672.jpg

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

Re: ICE T65/Z80/6809

Post by hoglet » Sun Jan 26, 2020 6:54 pm

bprosman wrote:
Sun Jan 26, 2020 3:04 pm
Today i tried the ICE-T65 my Junior computer clone. Unfortunately a No-Go. Neither with the EEPizza board nor with the Godil version which has confirmed to be working in my Atom.

I also made a small adapter with the "Light pull-ups" though the Elektor design has pull-ups.
Which PCB version do you have?

Can you confirm there is a pullup on Rdy?

Dave

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

Re: ICE T65/Z80/6809

Post by hoglet » Sun Jan 26, 2020 8:20 pm

One other thought Bram...

The 1MHz oscillator is rather unconventional, as it uses Φin to Φ2 on the 6502 as part of the oscillator.

Can you confirm with a scope whether the oscillator is working, and is running at 1MHz?

Dave

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Sun Jan 26, 2020 10:22 pm

Hi Dave,

I use the V1.0 version PCB but I made an adapter socket with the extra 22K pull-up's on it.
(See picture) , RDY on the Junior does not standard have a pull-up. But measured and now all pins have.
IMG_1635.jpg
Let me check the clock tomorrow.
PHI2 is what i should measure ?

Regards, Bram

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

Re: ICE T65/Z80/6809

Post by hoglet » Sun Jan 26, 2020 10:31 pm

bprosman wrote:
Sun Jan 26, 2020 10:22 pm
PHI2 is what i should measure ?
Measure both Φin and Φ2.

Dave

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Mon Jan 27, 2020 1:35 pm

Hi Dave,

It indeed looks to be a clock issue. When I attached the probes to Pin 37-39 all of a sudden the computer starts.
At that moment the clock is also measurable.
It requires some power on/off actions though until then the clock has some start issues.
Took some snapshots, as I don't know (yet) how to set the color in the screenshot it became 3 screenshots.

PHI_0:
PHI_0.JPG
PHI_2:
PHI_2.JPG
Both:
PHI_0-PHI_2.JPG

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Mon Jan 27, 2020 1:40 pm

They seem to have "borrowed" the as you call it "unconventional" clock generator from the KIM-1
Elektor gave you the choice of mounting the Crystal or run it into RC mode. That might explain the design ?
KIM-1.JPG
I have a 1MHz crystal oscillator, what if I feed that into an isolated Pin37 of the ICE-T65 ?

obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Mon Jan 27, 2020 2:47 pm

Lowering R53 could help it start better...? Put another R parallel to it... [2c]

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

Re: ICE T65/Z80/6809

Post by hoglet » Mon Jan 27, 2020 4:15 pm

obiwanjacobi wrote:
Mon Jan 27, 2020 2:47 pm
Lowering R53 could help it start better...? Put another R parallel to it... [2c]
This is a good suggestion, and worth trying.

I've done a bit more reading, and it does seem that this type of oscillator circuit appeared in the orginal MOS datasheet:
http://www.6502.org/documents/datasheet ... y_1976.pdf

(But not in later MOS versions, and not in Rockwell's either)

The Junior uses runs the crystal in series resonance mode, so make sure the Crystal you have is speced for operation in that mode

The Acorn System 1 uses a variation of the circuit, with the crystal in a different place:
ClockGen1.PNG
The later Atom used a more conventional external oscillator:
ClockGen2.PNG
There is a interesting thread over on 6502.org on 6502 clocking:
http://forum.6502.org/viewtopic.php?f=12&t=5259&p=62262

If possible, I would look to modify the system to make use of a 4-pin external can oscillator.

If that's not possible (or desirable) then fiddling around with the component values might make start-up more reliable. If the crystal is 30 years old, replacing it with a new one might help.

Dave

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Mon Jan 27, 2020 4:38 pm

If possible, I would look to modify the system to make use of a 4-pin external can oscillator.
Looking at the schematic, then this would be the way to go with the least changes ?
I think we can "save" something in the NAND port area but trying to leave that close to original (for now).
NewClock_2.jpg

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

Re: ICE T65/Z80/6809

Post by hoglet » Mon Jan 27, 2020 5:17 pm

bprosman wrote:
Mon Jan 27, 2020 4:38 pm
Looking at the schematic, then this would be the way to go with the least changes ?
Yes, that looks reasonable.

The only simpler way I can think of would be to bend pin 37 out (so it's not connected to the socket) and connect the oscillator directly to that pin.

It depends if you want this to be a permanent change.

Dave

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Mon Jan 27, 2020 7:29 pm

Hi Dave,

I had a weird idea, isnt it possible to "disconnect" PIN37 in the FPGA design and create an internal 1MHz clock ?

Kind regards, Bram

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

Re: ICE T65/Z80/6809

Post by hoglet » Mon Jan 27, 2020 7:46 pm

bprosman wrote:
Mon Jan 27, 2020 7:29 pm
I had a weird idea, isnt it possible to "disconnect" PIN37 in the FPGA design and create an internal 1MHz clock ?
I had the same thought this morning (i.e. add an internal clock generator feature to the ICE).

This would be useful in certain circumstances (yours is one of them), but I thought of a few problems:
1. In some systems, other logic is driven off Phi0, so this just won't work in those cases.
2. I'd like to avoid doubling the number of builds, so this would have to be software enabled.
3. The frequency would ideally need to be programmable in software as well.

All that rather put me off....

So while it's technical possible, and easily "hackable" as a one-off, it's a lot more work to make general purpose.

Dave

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Mon Jan 27, 2020 7:50 pm

So while it's technical possible, and easily "hackable" as a one-off, it's a lot more work to make general purpose.
Would you be willing to teach me how to implement a "one-off" hack ?
In that case it wont pollute your design but would / could serve my purpose here.

Working on another hack as well to support Intel-hex in addition to the Motorola format.
That part is in the AVR code so sort of understand that.

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

Re: ICE T65/Z80/6809

Post by hoglet » Mon Jan 27, 2020 8:40 pm

bprosman wrote:
Mon Jan 27, 2020 7:50 pm
Would you be willing to teach me how to implement a "one-off" hack ?
In that case it wont pollute your design but would / could serve my purpose here.
I've done what I think is necessary on a new branch called:
hack_6502_1MHz_int_oscillator

You just need to check this branch out, then do a rebuild of the 6502. I think you know how to do that.

The change is quite small:
https://github.com/hoglet67/AtomBusMon/ ... 846acb9f3c

This is completely untested!

Dave

bprosman
Posts: 406
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Mon Jan 27, 2020 8:44 pm

Thanks so much Dave !!!

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

Re: ICE T65/Z80/6809

Post by hoglet » Tue Jan 28, 2020 1:40 pm

Hi Obiwan,
obiwanjacobi wrote:
Sun Jan 26, 2020 2:18 pm
I think I'll wait for your fix then try again.
I've just uploaded a new release package that fixes the Z80 address/data bus tristate during reset issue:
https://github.com/hoglet67/AtomBusMon/ ... /release_3

The firmware revision number is now 0.982.

Dave

obiwanjacobi
Posts: 30
Joined: Mon Oct 21, 2019 9:43 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Tue Jan 28, 2020 8:16 pm

hoglet wrote:
Tue Jan 28, 2020 1:40 pm
Hi Obiwan,
obiwanjacobi wrote:
Sun Jan 26, 2020 2:18 pm
I think I'll wait for your fix then try again.
I've just uploaded a new release package that fixes the Z80 address/data bus tristate during reset issue:
https://github.com/hoglet67/AtomBusMon/ ... /release_3

The firmware revision number is now 0.982.

Dave
Sweeeeet! Thanks.

Meanwhile I did investigate further. I started at the beginning and noticed that my startup (of these control signals) is different between the Z80 and the ICE. I am now trying to change the startup initialization code to tune that down to the simplest thing and start from there adding more complexity. But first I will program the new image.

Post Reply