ICE T65/Z80/6809

discussion of games, software, hardware & emulators relating to the Acorn Atom and Acorn System machines.
bprosman
Posts: 362
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: ICE T65/Z80/6809

Post by bprosman » Fri Oct 04, 2019 1:59 pm

And... we have a lift-off :-)
The 6502 board works nice in an MPS-65 as well as in my Atom :
http://retro.hansotten.nl/6502-sbc/msp-65-2-thaler/

On my board I did not fit the 3 single-signal level shifters , main reason, I did not have them :wink:
Second reason , I never have used the trigger option. I used the jumper to get the RnW signal via 74LVC4245A.
Actually, it would be helpful if you tried this, because I've not been able to test that option yet.
So yes Dave, it works fine for me.
Also changed the header on the EEPizza board to make it accessible when its piggy-backed on the level shifter PCB.

Also in my Atom.
IMG_1063.jpg
IMG_1064.jpg
IMG_1061.jpg
IMG_1062.jpg
Looking forward to the Z80 version :D :D

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Oct 04, 2019 4:57 pm

bprosman wrote:
Fri Oct 04, 2019 1:59 pm
Looking forward to the Z80 version :D :D
Here's some photos of the completed Z80 adapter:
IMG_1783.JPG
IMG_1784.JPG
IMG_1785.JPG
IMG_1786.JPG
I had previously put some notes on the Wiki about testing the GODIL based implementation in various Z80 machines:
https://github.com/hoglet67/AtomBusMon/ ... 80#testing

So I repeated these tests with the new adapter.

With the Spectrum +2, the new adapter seems to work well. I was able to boot the machine, stop, single step, test memory etc. One problem with the GODIL implementation was the 1.5K pullups were raising the clock levels, and a capacitor was needed to supress spurious clock edges. The new adapter works fine without any tweaking.

With the Spectrum 48K (issue 4S), if you recall, the GODIL implementation struggled to read from the far side of the split data bus. That's no longer the case. The machine is fully functional, and I was able to load and play Alien Destroyers.

However, we're not completely out of the woods yet with the Spectrum 48K. Although the CPU side of ICE-Z80 seems stable, the debugger is definitely not. For example, if I try to test memory I get errors. I think there are two seperate issues.

1. When the debugger pauses the CPU, it need to continue to generate refresh cycles. Currently it doesn't. Not doing this is causing the upper 32K of memory to loose it's contents after a while (about 2 minutes).

2. Memory cycles generated by the debugger (e.g. the for RAM test) need to look exactly the same as those generated by the CPU. They need to be exactly three T-states long, and the address needs to be stable right from the start of T1. Currenly this is not the case, and I think it's not playing nicely with the logic in the ULA that resolves contention for the lower 16K of memory.

So I need to do a bit more work to the state machine that interfaces the ICE to the Z80 bus.

Here's a couple more photos of it in the Spectrum 48K:
IMG_1781.JPG
IMG_1780.JPG
Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Fri Oct 04, 2019 5:37 pm

Hi Dave,

Does this mean that in a system with static RAM it is (more) stable ?
In that case I can build the adapter and test it in my MPF-1B.

Kind regards, Bram

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Oct 04, 2019 5:54 pm

bprosman wrote:
Fri Oct 04, 2019 5:37 pm
Does this mean that in a system with static RAM it is (more) stable ?
Yes, because the refresh issue won't apply.
bprosman wrote:
Fri Oct 04, 2019 5:37 pm
In that case I can build the adapter and test it in my MPF-1B.
That would be very interesting.

Eariler this year someone tried the GODIL implementation in an MPF-1 and had some problems.

There is a long issue on github that that is still open:
https://github.com/hoglet67/AtomBusMon/issues/4

I think there were two seperate problems:
(1) A problem with the way ICE-Z80 single steps, that is incompatible with the way the MPF counts M1 cycles to generate NMI (for it's own single stepping)
(2) Some general unreliablility with the RAM accesses

I understand what's going on with (1), and will try to fix it when I rework the ICE Z80 bus interface state machine.

I still don't really understand the cause of (2) so it would be interesting to see if it still happens with the new adapter.

The Z80 machines I have are:
- ZX81
- Spectrum 48K (issue 4S)
- Spectrum +2B
- Cambridge Z88
- Acorn Z80 Co Processor

I don't have an MPF-1 (yet) myself.

Dave

User avatar
Elminster
Posts: 3957
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: ICE T65/Z80/6809

Post by Elminster » Fri Oct 04, 2019 6:53 pm

Is there a BOM for the Z80 board? I see the zipped gerbers, so getting boards made is easy enough.

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

Re: ICE T65/Z80/6809

Post by bprosman » Fri Oct 04, 2019 6:58 pm

Here you are :
z80_adapter_bom.pdf
(29.95 KiB) Downloaded 23 times

User avatar
Elminster
Posts: 3957
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: ICE T65/Z80/6809

Post by Elminster » Fri Oct 04, 2019 7:02 pm

Thanks. If I get time I try to build one, if not I shall bring my rc2014 to ABUG south.

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Oct 04, 2019 7:07 pm

Elminster wrote:
Fri Oct 04, 2019 6:53 pm
Is there a BOM for the Z80 board? I see the zipped gerbers, so getting boards made is easy enough.
I'll start to create some content on the wiki for these new boards in a week or so.

Is it the Z80 you are particularly interested in?

(The table from Kicad contains some mistakes.)

If you can maybe hold off ordering parts for a week or so....

I've got some spare boards that I'll bring to ABUG, about £5 each.

Dave

User avatar
Elminster
Posts: 3957
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: ICE T65/Z80/6809

Post by Elminster » Fri Oct 04, 2019 7:47 pm

Yep Z80 for rc2014 I am interested in, but I am guessing if I put new firmware on pizza board I will also need the 6502 version? Or I will still need to reflash pizza when I swap from z80 to 6502.

But yes I can wait till abug and take a spare board then thanks, I am not in a particular hurry.

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Oct 04, 2019 8:05 pm

Elminster wrote:
Fri Oct 04, 2019 7:47 pm
Yep Z80 for rc2014 I am interested in, but I am guessing if I put new firmware on pizza board I will also need the 6502 version? Or I will still need to reflash pizza when I swap from z80 to 6502.
I'd like to end up with a single multiboot firmware that includes a number of seperate FPGA designs:
- a multiboot loader
- ICE-6502 (Mode jumper = 0) - uses the cycle accurate T65 core
- ICE-65C02 (Mode jumper = 1) - TBD but probably uses the Artet 65C02 core
- ICE-Z80 - uses the T80 core
- ICE-6809E - uses the SYS09 core

Others could be added in the future.

The multiboot loader would work like the one on the Matchbox Co Pro. It would read the 4-bit ID value from the attached adapter board and the mode jumper, and then reload the appropriate design for that adapter (so the Xilinx is actually reconfigured twice).

Once this is done, to change target you just swap the adapter board. No reflashing and no messing with multiple power supply jumpers.

That's a little way off though.

None of this will be compatible with the Jason's level shifer board, but nothing is stopping you still using the builds that aleady exist for that board.

Dave

Budgie
Posts: 91
Joined: Mon Nov 02, 2015 9:14 pm
Location: Manchester, UK
Contact:

Re: ICE T65/Z80/6809

Post by Budgie » Fri Oct 04, 2019 8:28 pm

Great that we now have alternatives to the GODIL and the fact they now work with the Speccy. Will be really useful to be able to play with 5V tolerant 6502 and Z80 in FPGAs. I've produced a couple of boards for the RC2014 using a Xilinx XC95144XL and MACHXO2 FPGAs, to recreate a Speccy but these will add to the flexible options.

Thanks for the info and producing these Dave.

User avatar
Elminster
Posts: 3957
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: ICE T65/Z80/6809

Post by Elminster » Fri Oct 04, 2019 8:41 pm

hoglet wrote:
Fri Oct 04, 2019 8:05 pm
Others could be added in the future.
The 6800 :)

None of this will be compatible with the Jason's level shifer board, but nothing is stopping you still using the builds that aleady exist for that board.
But I assume that would require multiple pizza boards, or I would still be flashing it every time.

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Oct 04, 2019 8:48 pm

Elminster wrote:
Fri Oct 04, 2019 8:41 pm
But I assume that would require multiple pizza boards, or I would still be flashing it every time.
Yes, that's right.

I'm currently up to three eepizza boards
- one permenantly in Atom 2K18 (with reversed headers so the buttons/LEDs are accessible)
- one notionally for Beeb 1MHz Bus Fpga
- one notionally for the new ICE stuff

There are currently £25, so not too expensive.

Dave

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Oct 04, 2019 9:00 pm

Elminster wrote:
Fri Oct 04, 2019 8:41 pm
hoglet wrote:
Fri Oct 04, 2019 8:05 pm
Others could be added in the future.
The 6800 :)
The 6800 has a very similar pinout to the 6502, so it would be pretty easy to knock out an adapter board.

(I've just done a 6809E board, and that took about a day.)

So maybe I will do a 6800 board, and send them both off at the same time. They would then be back in time for ABUG.

Do you known of any cheap and/or interesting MC6800 SBCs?

Dave

User avatar
Elminster
Posts: 3957
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: ICE T65/Z80/6809

Post by Elminster » Sat Oct 05, 2019 12:02 am

That would be good. I only know of an expensive one.

https://www.corshamtech.com/product/ss- ... te-system/

Which I was going to get to help with debugging my swtpc, but I am sure there must be some cheap SBC about.

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

Re: ICE T65/Z80/6809

Post by hoglet » Tue Oct 15, 2019 5:45 pm

Hi Guys,

I've been working on the ICE Z80 over the last couple of days, using new level shifter and the eepizza LX9 FPGA board.

The latest work is in the dev branch (and comes up as version 0.80)

Code: Select all

ICE-T80 In-Circuit Emulator version 0.80
Compiled at 18:01:10 on Oct 15 2019
4 watches/breakpoints implemented
Tracing every 1 instructions while single stepping
CPU free running...
I've been developing and testing this against four different test systems, each of which had different problems:
  • Spectrum 48K (Issue 4S) - this needed the memory read/write cycles generated by the debugger to look exactly like those of the Z80, otherwise the contention logic in the ULA didn't stop the Z80 on the right cycle. The fix here was a big re-write of the memory access state machine. In doing this I managed to break the single stepping, which took a while to get right again.
  • Spectrum +2 (Issue 2B) - this needed continuous RFSH_n cycles to allow the ULA to refresh the full 64K of memory. This fix was a small addition to the above state machine.
  • Acorn Z80 Co Processor - this had two issues. IM2 Interrupt cycles were unreliable, because of a "fix" someone had made to the T80 core. And single stepping was broken, due to an omission in my memory access state machine. Both of these were small fixes once the bugs had been found.
  • ZX81 - this was getting stuck on the first HALT in the display list in high memory. After much debugging, on a real Z80 this HALT is resumed with an INT (caused by the bit 6 of the refresh address). The version of the T80 I was using didn't allow INT to resume a HALT instruction. This has been fixed in the latest version of T80 I could find - version 350.
You can see all of these changes in the commit log:

Code: Select all

4c746994f z80: major rewrite of memory access state machine
d9d55247c z80: rework wait state / break point logic
50658b35b z80: generate RFSH_n cycles when stopped
9bcea5659 z80: CLK_n timing constraint now 8MHz
584540990 z80: added a resume state
975ba2283 z80: temporarily disable IORQ_inhibit
f710f7a2a z80: updated T80 to version 350
ddaa266ce z80: fix a T80 build error on Spartan 3
833471b31 z80: version now 0.80
With these changes in place, all four of the above systems appear to be stable, and all features of the debugger seem to work.

I've done most testing on the Acorn Z80 Co Pro - I've even been able to run CP/M.

What's very encouraging here is that all of the issues were "digital" issues, either with my state machine to share the host bus between the T80 core and the debugger, or with the T80 core itself. All of the "analog" issues that seemed to plague the previous GODIL implementation seem to have gone.

I'm planning to test this on a couple more systems in the near future:
- the Micro Professor MPF-1B (thanks to a very generous donation from Bram)
- the Amstrad CPC 464/6128 (which Revaldhino owns)

The next thing I want to work on is the multi-boot loader, so a single build of the FPGA firmware will support all of the targets.

Dave

P.S. The only downside of all this is that version 350 of the T80 is somewhat larger than the old version I was using, and unfortunately this no longer fits in the GODIL 250 target (which was 99% full anyway). That's the reason this work is still in the dev branch. Hopefully I can find some way to make everything a bit smaller....

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

Re: ICE T65/Z80/6809

Post by bprosman » Tue Oct 15, 2019 6:35 pm

Is the EEPizza board bigger (core wise) than the Godil Dave ?

Kind regards, Bram

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

Re: ICE T65/Z80/6809

Post by hoglet » Tue Oct 15, 2019 7:07 pm

bprosman wrote:
Tue Oct 15, 2019 6:35 pm
Is the EEPizza board bigger (core wise) than the Godil Dave ?
Yes:
- the GODIL 250 uses the Xilinx XC3S250E (5,508 logic cells, 24KB Block RAM)
- the GODIL 500 uses the Xilinx XC3S500E (10,476 logic cells, 40KB Block RAM)
- the EEPizza board uses the Xilinx XC6SLX9 (9,152 logic cells, 64KB Block RAM)

At the moment, the ICE Z80 uses 100% of the resources of the GODIL 250 (hence the recent changes in dev have made it overflow).

But the design will easily in the GODIL 500 and the EEPizza board. There even room for more code and a larger event FIFO.

Which GODIL do you have?

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Tue Oct 15, 2019 7:22 pm

Which GODIL do you have?
The 500's so I'm good anyway.

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Oct 18, 2019 12:08 pm

A bit more progress to report....

I've now got the multi boot firmware working: a boot loader design reads the ID and Mode links on the adapter board, and loads one of the following designs:
  • ICE-6502
  • ICE 65C02
  • ICE Z80
  • Unknown adapter
All of these are packaged into a single firmware image, so there is no need to keep reprogramming the FPGA board.

At the moment fitting only R10 (ID0) indicates a 6502/65C02 adapter, and fitting only R11 (ID1) indicates a Z80 adapter.

I've also been doing some more work on the 6502 variant. There are now seperate ICE-6502 and ICE-65C02 builds, and the boot loader selects between them based on the Mode jumper. ICE-6502 uses the T65 core and ICE-65C02 uses the AlanD core.

I've added support for Rdy on both flavours, which was quite interesting (thanks to BigEd for his help yesterday).

Testing on the Beeb showed the first a problem. The system booted but then immediately froze, and not even BREAK would work. It turns out on the Beeb, the Rdy input (pin 2) of the 6502 is basical just left floating. I'm actually surprised this has not been noted before. It's certainly bad practice, and might be an additional source of unreliability when 65C02 processors are fitted.

Anyway, to get it working I added a weak pullup to the bottom of the level shifter, between pins 2 and 8:
IMG_1791.JPG
(I could have fitted this to the Beeb instead, as technically it's the Beeb that's at fault)

But based on this experience, I've reved the PCB to add weak pullups on all of the optional 6502 control inputs (R15-R20):
Screenshot from 2019-10-18 12-26-56.png
I'll order some more 6502 boards shortly when I send off the 6809E design.

Testing on the Acorn External 65C02 Second Processor was also interesting:
IMG_1790.JPG
Two aspects of the External 65C02 Second Processor design are unusual; both relate to DRAM refresh:
  • To make time for DRAM refresh cycles, the 65C02 is paused (using Rdy) for one cycle 3MHz cycle every ~14us. So effectively the 65C02 is only running at 2.93MHz, rather than 3MHz. Not something Acorn ever advertised! I've often wondered why ClockSP didn't show exactly 3MHz.
  • DRAM refresh is triggered by the Sync signal (along with a counter). So when the ICE was paused, after about 10 seconds DRAM would become corrupted. The fix for this was the same as for the Z80 - adding a small state machine to generate Sync cycles when paused (as if NOP was executing).
With these fixes in place, ICE-65C02 runs perfectly and I've been able to play Tube Elite in slow motion using the single stepping feature!

Next up will be finishing the 6809E design.

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Sat Oct 19, 2019 2:38 pm

Today I finished my board for the Z80, the core that has been loaded is the multi-CPU version.
For now I only did the basic testing :

1. Put in an MPF1-B, that boots fine. Did some single stepping but that ran into an SYS-SP error, that might be me though, as it was 35 years ago I used a MPF1-B
2. Put it in a Z80 system im currently debugging. A "Grant Searle" design, Z80, EPROM/RAM, 68B50. There I noticed then when I reset the system the Red LED flashes quickly and then the Yellow and Green turn on (honestly didnt check that on the MPF1-B).

The switches are "In transit" from China to Holland so resetting is a bit tricky.

As mentioned, for now the very basic test passed, will use it on my Eurocard system to debug that.

IMG_1107.jpg
IMG_1108.jpg
IMG_1109.jpg
IMG_1110.jpg
IMG_1112.jpg

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

Re: ICE T65/Z80/6809

Post by hoglet » Sat Oct 19, 2019 2:48 pm

bprosman wrote:
Sat Oct 19, 2019 2:38 pm
1. Put in an MPF1-B, that boots fine. Did some single stepping but that ran into an SYS-SP error, that might be me though, as it was 35 years ago I used a MPF1-B
Single stepping using the ICE, or single stepping using the MPF monitor?

It would't surprise me if there is still an issue with the ICE single stepping on the MPF, because of the MPF's use of NMI and M1 cycle counting.
bprosman wrote:
Sat Oct 19, 2019 2:38 pm
The switches are "In transit" from China to Holland so resetting is a bit tricky.
You could try the reset command in the ICE, followed by the continue command (this will reset the CPU only).

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Sat Oct 19, 2019 3:25 pm

Single stepping using the ICE, or single stepping using the MPF monitor?
It would't surprise me if there is still an issue with the ICE single stepping on the MPF, because of the MPF's use of NMI and M1 cycle counting.
Single stepping on the MPF-1B.
Let me play with the other system first.

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

Re: ICE T65/Z80/6809

Post by bprosman » Sun Oct 20, 2019 11:36 am

More some general github questions.
If they pollute this thread too much I can move it (or open a seperate one).

I'm working on a Windows (10) environment. How can I keep up with Dave's latest developements ?
Is that just a matter of running : git clone https://github.com/hoglet67/AtomBusMon.git ?

And how can I keep older (working) versions, by renaming the AtomBusmon directory that is already there to *.OLD ?

And finally, if I edit files.. e.g. the Makefile.inc in target/common, how can I avoid that one to be overwritten ?

Kind regards, Bram

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

Re: ICE T65/Z80/6809

Post by hoglet » Sun Oct 20, 2019 12:25 pm

bprosman wrote:
Sun Oct 20, 2019 11:36 am
I'm working on a Windows (10) environment. How can I keep up with Dave's latest developements ?
Is that just a matter of running : git clone https://github.com/hoglet67/AtomBusMon.git ?
Using clone multiple times is not really the right approach.

First, check if you have made any local changes using:

Code: Select all

git status
To refesh a repository (assuming you have no local changes), I would recommend using:

Code: Select all

git pull --rebase
If you have local changes, you need to stash them, see below.
bprosman wrote:
Sun Oct 20, 2019 11:36 am
And how can I keep older (working) versions, by renaming the AtomBusmon directory that is already there to *.OLD ?
That would certainly work.

But you can also go back to an earlier version with:

Code: Select all

git checkout 1234567
Where 1234567 is the first part of the hexadecimal commit ID.

You can find commit IDs using:

Code: Select all

git log
Or using the graphical tool "gitk", or looking on github (e.g. here)

To get back to the latest commit on, say, the dev branch, you do:

Code: Select all

git checkout dev
bprosman wrote:
Sun Oct 20, 2019 11:36 am
And finally, if I edit files.. e.g. the Makefile.inc in target/common, how can I avoid that one to be overwritten ?
That's where stashing helps:

Code: Select all

git stash
git pull --rebase
git stash pop
This will be painless as long as the same lines have not been edited by both of us.

Note, apart from git clone, all git commands should be issued from within the repository directory.

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Mon Oct 21, 2019 10:49 am

Thanks Dave,

With some (script) tweaking I was able to generate the new files myself now and with a Windows batch file generate the PROM file (instead of the shell script).

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

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Tue Oct 22, 2019 5:28 am

Hi, I'm new here. I registered so I can say what an awesome project this is.
I ordered at eepizza at once - I understood from the previous pages you get this working on the Spartan6.

I am not entirely sure how to compile the HDL and program it on the Spartan6, but then I haven't been through all the docs (wiki?) yet.
I have some minor experience with VHDL, Quantus and programming Altera CPLDs.

One thing that stood out to me, when looking at the adapter board for the Z80, was that Refresh was not 3-stated with the other control signals when BUSACK is active. I remember reading that somewhere (for when long DMA operations have a chance to keep the DRAM alive), but I can't find it anywhere! #-o
EDIT: Z80 CPU Manual (pdf) page 11:
If long DMA cycles are used, and dynamic memories are used, the external controller also performs the refresh function.
Page 12 timing diagram shows RFSH floating during BUSACK.

Also there are some unused pins left over on the FPGA board as well as on one of the 254's. Would it be an idea to route those to a separate header? That way you could trigger your logic analyzer on internal CPU events...

Oh and my project is Zalt, a homebrew Z80 system I have been working on for years now.

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

Re: ICE T65/Z80/6809

Post by hoglet » Tue Oct 22, 2019 6:40 am

obiwanjacobi wrote:
Tue Oct 22, 2019 5:28 am
I am not entirely sure how to compile the HDL and program it on the Spartan6, but then I haven't been through all the docs (wiki?) yet.
The Wiki will need to be updated to reflect the new boards.

The build process is quite complicated, so I will be providing regular binary releases.
obiwanjacobi wrote:
Tue Oct 22, 2019 5:28 am
One thing that stood out to me, when looking at the adapter board for the Z80, was that Refresh was not 3-stated with the other control signals when BUSACK is active. I remember reading that somewhere (for when long DMA operations have a chance to keep the DRAM alive), but I can't find it anywhere! #-o
EDIT: Z80 CPU Manual (pdf) page 11:
If long DMA cycles are used, and dynamic memories are used, the external controller also performs the refresh function.
Page 12 timing diagram shows RFSH floating during BUSACK.
The information about this is inconsistent.

Elsewhere, in the signal descriptions on page 7, it says:
RFSH. Refresh (output, active Low). RFSH, together with MREQ, indicates that the lower
seven bits of the system’s address bus can be used as a refresh address to the system’s
dynamic memories.
(i.e. no mention of tristate),

For other outputs, like RD, it says:
RD. Read (output, active Low, tristate). RD indicates that the CPU wants to read data from
memory or an I/O device. The addressed I/O device or memory should use this signal to
gate data onto the CPU data bus.
I did look into this quite carefully, by looking at what happens inside the Z80.

If you look at the refresh PAD in Visual Z80, you'll see there is only one control signal.
http://visual6502.org/JSSim/expert-z80. ... &zoom=13.0
z80_rfsh_pad_driver.PNG
So I'm 90%100% sure that RFSH cannot be be tristated.
obiwanjacobi wrote:
Tue Oct 22, 2019 5:28 am
Also there are some unused pins left over on the FPGA board as well as on one of the 254's. Would it be an idea to route those to a separate header? That way you could trigger your logic analyzer on internal CPU events...
The eepizza board contains a seperate 12-pin header that are currently un-unsed. I was intending to use that for extensions like this.
obiwanjacobi wrote:
Tue Oct 22, 2019 5:28 am
Oh and my project is Zalt, a homebrew Z80 system I have been working on for years now.
It would be nice to see some photos of this (probably in a new thread).

Welcome to the forum!

Dave


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

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Tue Oct 22, 2019 10:02 am

hoglet wrote:
Tue Oct 22, 2019 6:40 am
If you look at the refresh PAD in Visual Z80, you'll see there is only one control signal.
http://visual6502.org/JSSim/expert-z80. ... &zoom=13.0
z80_rfsh_pad_driver.PNG
So I'm 90%100% sure that RFSH cannot be be tristated.
Sorry, I don't read die speak... :roll:
And tristated is not correct either (as you said: docs are inconsistent) - it's high-z (output enable)...
hoglet wrote:
Tue Oct 22, 2019 6:40 am
obiwanjacobi wrote:
Tue Oct 22, 2019 5:28 am
Also there are some unused pins left over on the FPGA board as well as on one of the 254's. Would it be an idea to route those to a separate header? That way you could trigger your logic analyzer on internal CPU events...
The eepizza board contains a seperate 12-pin header that are currently un-unsed. I was intending to use that for extensions like this.
But then those signals will not be level shifted...
You have the unpopulated pins on the 245...

Post Reply