ICE T65/Z80/6809

discussion of games, software, hardware & emulators relating to the Acorn Atom
User avatar
fordp
Posts: 922
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: ICE T65/Z80/6809

Postby fordp » Sun Oct 22, 2017 3:14 pm

I have a Basic ROM! This Beeb was working fine until I tried to add my MaxRAM board. I then broke it and even after I took my board out it still does not work. It will be down to me physically damaging something. I have my MSO on it and the Data bus does not look good. Also A14 is at a funny voltage level. I will keep trying thanks for your help.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: ICE T65/Z80/6809

Postby hoglet » Sun Oct 22, 2017 3:22 pm

fordp wrote:I have a Basic ROM!

As in that's the only extra hardware? Or you can see the Basic ROM?
fordp wrote:This Beeb was working fine until I tried to add my MaxRAM board. I then broke it and even after I took my board out it still does not work. It will be down to me physically damaging something.

Ah, so the Beeb was already broken, that changes things a bit....

Is it worth trying the ICE T65 in another Beeb just to confirm it's working properly?
fordp wrote:I have my MSO on it and the Data bus does not look good. Also A14 is at a funny voltage level. I will keep trying thanks for your help.

The data bus on the Beeb always looks pretty rubbish as it's way overloaded.

Maybe worth starting a new trouble-shooting thread for this sick Beeb?

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

Re: ICE T65/Z80/6809

Postby hoglet » Sun Oct 22, 2017 3:54 pm

hoglet wrote:Maybe worth starting a new trouble-shooting thread for this sick Beeb?

In the mean time...

Comparing your memory dump of D9xx with mine, all of the lower nibbles match exactly.

So the problem seems to be something is dragging down the upper (I think) three bits of the data bus: D7, D6 and D5.

Can you unplug IC14 (which will isolate the data bus to the RAM), and see if ROM reading becomes any more reliable?

In fact, why not unplug anything that's socketted and connected to the data bus!

Dave

User avatar
fordp
Posts: 922
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: ICE T65/Z80/6809

Postby fordp » Mon Oct 23, 2017 11:35 am

Funny you should say that I already unplugged that '245 but broke a pin on my ICE in the process :(

(That chip is under the ICE).

It may be next weekend before I get back on to it. Thanks again for your efforts.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: ICE T65/Z80/6809

Postby flynnjs » Mon Oct 23, 2017 6:13 pm

fordp wrote:I am pretty sure Jason did that for me.


Actually, it was probably configured for the power jumpers CLOSED as I was not connecting the USB
so it needed power from the Beeb.

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

Re: ICE T65/Z80/6809

Postby flynnjs » Mon Oct 23, 2017 6:15 pm

The other thing is the pull-ups on one board are in on the other side to the other board.
This shouldn't make any difference.

User avatar
fordp
Posts: 922
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: ICE T65/Z80/6809

Postby fordp » Mon Oct 23, 2017 8:35 pm

flynnjs wrote:The other thing is the pull-ups on one board are in on the other side to the other board.
This shouldn't make any difference.

That's what I said, earlier.

I got the board working, if not the Beeb :(

Well until I snapped a pin.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: ICE T65/Z80/6809

Postby flynnjs » Mon Oct 23, 2017 8:53 pm

The intention always was to have the pullups the same side as the pins and the ICs leaving the other side purely for strapping pings high or low.

However, you had one of the early board which for some reason I put the resistors on the other size.

All new boards shipped since last week have the intended population!

Prime
Posts: 2347
Joined: Sun May 31, 2009 11:52 pm

Re: ICE T65/Z80/6809

Postby Prime » Fri Nov 17, 2017 9:37 am

Right going to try and program converted Godil at ABUG , I removed the sockets and replaced them with a 40 pin plug (to plug into DIP socket) and 2x50pin jumper blocks. If that doesn't work I've just ordered one of the Spartan 6 boards but will need to get a level converter for it.

Has someone made the level converter boards or are a schematic / board layout available that I could use?

Cheers.

Phill.

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

Re: ICE T65/Z80/6809

Postby hoglet » Fri Nov 17, 2017 10:01 am

Prime wrote:Has someone made the level converter boards or are a schematic / board layout available that I could use?

Jason Flynn has, and if you ask quickly he might be able to bring one to ABUG.
http://www.xeropage.co.uk/shop/index.ph ... er=product

Dave

Prime
Posts: 2347
Joined: Sun May 31, 2009 11:52 pm

Re: ICE T65/Z80/6809

Postby Prime » Sat Nov 18, 2017 11:46 am

Yep Jason has been making them up :) and I have one now.

Also I got my Godil converted(desoldered bottom connectors, soldered on jumpers & socket). I've got it plugged into my Apple IIe, and it's not working properly :( Any reads from ROM work fine, and writes to ram are OK, but reads are coming back corrupt. I tried it in an Atom board to make sure I had not damaged the Godil with the connector swapping, and it works correctly in the Atom, which is odd.

Cheers.

Phill.

User avatar
oss003
Posts: 2550
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: ICE T65/Z80/6809

Postby oss003 » Sat Nov 18, 2017 12:23 pm

Prime wrote:Yep Jason has been making them up :) and I have one now.

Also I got my Godil converted(desoldered bottom connectors, soldered on jumpers & socket). I've got it plugged into my Apple IIe, and it's not working properly :( Any reads from ROM work fine, and writes to ram are OK, but reads are coming back corrupt. I tried it in an Atom board to make sure I had not damaged the Godil with the connector swapping, and it works correctly in the Atom, which is odd.

Cheers.

Phill.

Maybe a 6502 - 65C02 issue?

Greetings
Kees

Prime
Posts: 2347
Joined: Sun May 31, 2009 11:52 pm

Re: ICE T65/Z80/6809

Postby Prime » Sat Nov 18, 2017 12:46 pm

[quote="oss003]
Maybe a 6502 - 65C02 issue?
[/quote]

Possibly, but this Apple has had both an NMOS and WDC CMOS cpu in it and workes fine.

Cheers.

Phill.

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

Re: ICE T65/Z80/6809

Postby hoglet » Sat Nov 18, 2017 1:08 pm

Can you point me at a schematic for your Apple II?

Prime
Posts: 2347
Joined: Sun May 31, 2009 11:52 pm

Re: ICE T65/Z80/6809

Postby Prime » Sat Nov 18, 2017 2:14 pm

hoglet wrote:Can you point me at a schematic for your Apple II?


Here you go.....

ftp://ftp.apple.asimov.net/pub/apple_II ... ematic.pdf

I suspect it may be a slight timing issue as for some things the Apple seems to use an externally generated phi1 rather tha the one generated by the CPU.

Cheers.

Phill.

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

Re: ICE T65/Z80/6809

Postby hoglet » Sat Nov 18, 2017 4:12 pm

Prime wrote:I suspect it may be a slight timing issue as for some things the Apple seems to use an externally generated phi1 rather tha the one generated by the CPU.

That's the only slightly unusual thing I can spot as well, and it's used in the RAM control signals.

There is lots of scope for tweaking the internal clocking of the ICE-T65 (in units of ~20ns).

Phi0 coming in is resampled by a fixed ~50MHz clock:
https://github.com/hoglet67/AtomBusMon/ ... n.vhd#L191
to generate Phi0_a, Phi0_b, Phi0_c, Phi0_d (each being 20ns further delayed)

Currently:
- Phi0_b is used to register read data from the data bus
- Phi0_c is used to as an output enable for writing data back to the data bus, and gives ~40ns data hold time
- Phi0_d is used to clock the internal 6502 core, and generates the external Address and RnW signals 70-90ns after Phi0

These "taps" were picked largely by trial an error, using a scope to try to match the timings with a real 2MHz 6502A in a Beeb.

Unfortunately, it's not possible to use a PLL for clock generation in this application because the clock into the CPU is often gated or cycle-stretched, which causes the PLL to loose lock.

Can you work out whether it's RAM reads or RAM writes that are failing? e.g. are reads (of the random initial data) consistent? The ICE-T65 has a CRC command for this sort of test.

Does filling RAM with 00 vs FF (using the f command) have any effect at all?

Dave

Prime
Posts: 2347
Joined: Sun May 31, 2009 11:52 pm

Re: ICE T65/Z80/6809

Postby Prime » Sat Nov 18, 2017 5:13 pm

hoglet wrote:
Prime wrote:I suspect it may be a slight timing issue as for some things the Apple seems to use an externally generated phi1 rather tha the one generated by the CPU.

That's the only slightly unusual thing I can spot as well, and it's used in the RAM control signals.

Indeed :)

Can you work out whether it's RAM reads or RAM writes that are failing? e.g. are reads (of the random initial data) consistent? The ICE-T65 has a CRC command for this sort of test.

Does filling RAM with 00 vs FF (using the f command) have any effect at all?


Oddly I know filling with a value seems to successfully write the value, if I do a fill of the screen RAM the display clears to the used character, reading them back however results in random data. Though it seems slightly better now :) it is still corrupting For example scrolling the screen results in random characters changing. So I suspect the problem is more likely with reads than writes.

Cheers.

Phill.

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

Re: ICE T65/Z80/6809

Postby hoglet » Sat Nov 18, 2017 6:47 pm

Prime wrote:Oddly I know filling with a value seems to successfully write the value, if I do a fill of the screen RAM the display clears to the used character, reading them back however results in random data. Though it seems slightly better now :) it is still corrupting For example scrolling the screen results in random characters changing. So I suspect the problem is more likely with reads than writes.

So is the Apple II able to boot?

i.e. is the issue only with using the ICE-T65 debugger to read memory?

Prime
Posts: 2347
Joined: Sun May 31, 2009 11:52 pm

Re: ICE T65/Z80/6809

Postby Prime » Sat Nov 18, 2017 7:08 pm

hoglet wrote:
Prime wrote:Oddly I know filling with a value seems to successfully write the value, if I do a fill of the screen RAM the display clears to the used character, reading them back however results in random data. Though it seems slightly better now :) it is still corrupting For example scrolling the screen results in random characters changing. So I suspect the problem is more likely with reads than writes.

So is the Apple II able to boot?

i.e. is the issue only with using the ICE-T65 debugger to read memory?


About 1 time in 5 :( Like I say reading from ROM seems absolutely fine, it's just the RAM. Was going to send a link to the Apple IIe tech ref manual as chapter 7 shows the required RAM timing, but the internet's so flakey I can't access the site it's on :). And it's too big to upload here.

should be here : ftp://ftp.apple.asimov.net/pub/apple_II ... ines/Apple IIe Technical Reference Manual.pdf

Cheers.

Phill.

Prime
Posts: 2347
Joined: Sun May 31, 2009 11:52 pm

Re: ICE T65/Z80/6809

Postby Prime » Sun Nov 19, 2017 11:03 am

hoglet wrote:Phi0 coming in is resampled by a fixed ~50MHz clock:
https://github.com/hoglet67/AtomBusMon/ ... n.vhd#L191
to generate Phi0_a, Phi0_b, Phi0_c, Phi0_d (each being 20ns further delayed)

Currently:
- Phi0_b is used to register read data from the data bus
- Phi0_c is used to as an output enable for writing data back to the data bus, and gives ~40ns data hold time
- Phi0_d is used to clock the internal 6502 core, and generates the external Address and RnW signals 70-90ns after Phi0


Bingo! Getting it to sample data on Phi0_a has fixed the problem it's now accessing memory correctly, and boots, running the RAM test passes too now which is good.

Next up I want to implement a a command on the AVR section that will "free run" but log so run as fast as it can but still log executed instructions to the terminal, saves pressing step a million times and will hopefully speed finding the crash points in my code.

Cheers.

Phill.

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

Re: ICE T65/Z80/6809

Postby hoglet » Sun Nov 19, 2017 11:21 am

Prime wrote:Bingo! Getting it to sample data on Phi0_a has fixed the problem it's now accessing memory correctly, and boots, running the RAM test passes too now which is good.

Excellent!!
Prime wrote:Next up I want to implement a a command on the AVR section that will "free run" but log so run as fast as it can but still log executed instructions to the terminal, saves pressing step a million times and will hopefully speed finding the crash points in my code.

You should be able to do that already:

Code: Select all

tr 1
s 1000000

This will trace (i.e. output to the console) every instruction, and then single step for 1,000,000 instructions.

See the manual section here:
https://github.com/hoglet67/AtomBusMon/ ... e#trace-tr

If you log the terminal output to a file, you can then review it in an editor.

Read/Write watchpoints (e.g. on I/O addresses) can also be a very powerful debugging aid.

Dave

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

Re: ICE T65/Z80/6809

Postby flynnjs » Sun Nov 19, 2017 12:37 pm

I note the latest MCS file for the LX9 mini board supports the UART on pins 51/55
where my board has it on 46/47. So I have a booting board but no UART right now :-)

[EDIT] As Phill has his build environment set up he's spinning me a different version.
Thanks!

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

Re: ICE T65/Z80/6809

Postby hoglet » Sun Nov 19, 2017 12:45 pm

flynnjs wrote:I note the latest MCS file for the LX9 mini board supports the UART on pins 51/55
where my board has it on 46/47. So I have a booting board but no UART right now :-)

I'm not sure how best to deal with this, and I guess you are the only person with an original board....

I'd rather not create a whole new folder hierarchy just for that one tiny difference.

Any thoughts?

What about a sed script that patches the .ucf files?

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

Re: ICE T65/Z80/6809

Postby flynnjs » Sun Nov 19, 2017 12:53 pm

Er.... maybe I'll just cut and strap my mini board to be the same as the ones everyone else has... ?

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

Re: ICE T65/Z80/6809

Postby hoglet » Sun Nov 19, 2017 1:04 pm

flynnjs wrote:Er.... maybe I'll just cut and strap my mini board to be the same as the ones everyone else has... ?

Great idea :D

Prime
Posts: 2347
Joined: Sun May 31, 2009 11:52 pm

Re: ICE T65/Z80/6809

Postby Prime » Tue Nov 21, 2017 1:14 pm

Right just to help other people on windows, I managed to get the build system working under cygwin on windows with a few minor changes.

What you'll need :

Cygwin installed and working.
The Atmel AVR 8 command line gcc compiler available at : http://www.atmel.com/tools/atmelavrtool ... ndows.aspx
Srecord for windows availabe at : https://sourceforge.net/projects/srecord/files/
The windows version of webback installed and licensed, pretty much the same procedure as for Linux.

You'll need to extract the AVR command line tools to a folder and add it's 'bin' directory to your windows search path. Likewise you'll need to extract srecord to a directory and add it's directory to your windows search path (you could drop it in the AVR compiler's bin folder).

Open up a cygwin window and clone the repository with :

git clone https://github.com/hoglet67/AtomBusMon.git

You'll need to edit Makefile.inc in target/common

And change XILINX to point to the cygwin path of your webpack installation e.g. :

XILINX := /cygdrive/c/Xilinx/14.7

Likewise you need to update path :

PATH := $(PATH):${XILINX}/ISE_DS/ISE/bin/nt64

I found that the shell needed to be changed to

SHELL := /bin/bash

Save the makefile, then change into the targety directory of the version you want to compile and then do a make clobber / make to build.

Cheers.

Phill.

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

Re: ICE T65/Z80/6809

Postby sirmorris » Tue Nov 21, 2017 2:40 pm

You're a star, Phill!
=D>

vorosmokus
Posts: 4
Joined: Thu Nov 09, 2017 7:28 am

Re: ICE T65/Z80/6809

Postby vorosmokus » Wed Nov 29, 2017 11:55 am

Firstly, thanks to hoglet for this great project.

I ordered the Spartan 6 mini board and a level shifter from xeropage.

I ordered the mini-board on the 7th of November and it arrived on the 27th of November.

Just in case anyone is interested in which XC6SLX9 Mini Board "eepizza" has been shipping recently, they have been shipping the type with a single row of JTAG pins (that I bent myself into a right angle) and not the 14 pin connector that is pictured in the eBay item and U3 uses an FT230X instead of the listed FT232RL, so if you are ordering, keep that in mind.

There has been discussion previously in this thread on how to deal with this board, but I just thought I'd post this for clarity.

Here are a few photos of mine.

photo5258484415506524215.jpg


photo5258484415506524218.jpg


photo5258484415506524219.jpg

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

Re: ICE T65/Z80/6809

Postby bprosman » Sat Dec 02, 2017 9:00 am

I ordered a 2nd one so curious what i get. My first one was the same as yours.

Regards, Bram

joeyoravec
Posts: 4
Joined: Tue Dec 05, 2017 12:47 am

Re: ICE T65/Z80/6809

Postby joeyoravec » Thu Dec 07, 2017 1:22 am

I just discovered this project and I'm trying to understand the current status of hardware. The GitHub wiki states "the godils are no longer made so a new fpga board was needed to continue the project"

Unfortunately I ordered the GODIL50 with IDC headers, and days later a small quantity of the bare board became available.

I had started working on an adapter PCB to convert the 50-pin female to a 40-pin DIL footprint. Now that the bare board has become available I'm considering ordering a bare version, so I can reduce the effort. Does anybody have info on on-going availability? Is it worth continuing with the PCB or should I give-up and order?

Work in progress is posted: https://circuitmaker.com/Projects/Detai ... onOverview


Return to “acorn atom”

Who is online

Users browsing this forum: No registered users and 2 guests