ICE T65/Z80/6809

discussion of games, software, hardware & emulators relating to the Acorn Atom and Acorn System machines.
User avatar
hoglet
Posts: 8598
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet » Tue Oct 22, 2019 10:21 am

obiwanjacobi wrote:
Tue Oct 22, 2019 10:02 am
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)...
Maybe BigEd can confirm this as well, but the pad driver for RFSH is a simple push-pull driver - it cannot go to a high impedence state. In that respect, it's similar to the M1 and HALT outputs.
obiwanjacobi wrote:
Tue Oct 22, 2019 10:02 am
hoglet wrote:
Tue Oct 22, 2019 6:40 am
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...
I do, but only on the Z80 adapter. The 6502 and 6809 adapters have no spare outputs.

I would like to implement trigger-out in a manner that was consistent across all the adapters.

Also, for triggering a logic analyzer it doesn't need to be level shifted, as a 3.3V LVTTL output will work fine.

Dave

User avatar
BigEd
Posts: 2646
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: ICE T65/Z80/6809

Post by BigEd » Tue Oct 22, 2019 10:39 am

hoglet wrote:
Tue Oct 22, 2019 10:21 am
obiwanjacobi wrote:
Tue Oct 22, 2019 10:02 am
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)...
Maybe BigEd can confirm this as well, but the pad driver for RFSH is a simple push-pull driver - it cannot go to a high impedence state. In that respect, it's similar to the M1 and HALT outputs.
Indeed, Dave, the layout is very clear (to those who can read it!) - there's only one input to the pad driver, and the pullup and pulldown signals are simple complements. A tristatable pad looks different, and needs two inputs.

(Hi-Z is the same thing as tristate: it means undriven.)

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

Re: ICE T65/Z80/6809

Post by bprosman » Tue Oct 22, 2019 12:00 pm

There was a discussion going on in one of the FB groups about this as well (maybe the same people :-) ).
What I understand is that :

/RFRSH is not tri-stated but also "not functional" when an external device is taking over the bus by a /BUSREQ signal.
The Z80 datasheet I saw was referring to (long) DMA transfers and there states the refresh process needs to be taken over by the device that is taking over the bus. Maybe I do say the same as you guys.

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

Re: ICE T65/Z80/6809

Post by hoglet » Tue Oct 22, 2019 1:05 pm

bprosman wrote:
Tue Oct 22, 2019 12:00 pm
There was a discussion going on in one of the FB groups about this as well (maybe the same people :-) ).
What I understand is that :

/RFRSH is not tri-stated but also "not functional" when an external device is taking over the bus by a /BUSREQ signal.
The Z80 datasheet I saw was referring to (long) DMA transfers and there states the refresh process needs to be taken over by the device that is taking over the bus. Maybe I do say the same as you guys.
That's good to know. I'm expecting to have to do more work on BusReq, particularly in case where the CPU is paused and the ICE debugger is in control of the bus. I just need to plan for testing this, as few systems use BUSREQ.

Dave

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

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Tue Oct 22, 2019 2:11 pm

Wow. that means that the manual actually suggests something that could potentially blow up the RFSH pin... :shock: :?

My system uses BUSREQ/BUSACK extensively.
I am currently looking into building the adapter board. The board that is in the repo is too big and high for me (stacked design).
I am thinking about doing something with a ribbon cable and a 40-pin dip connector at the end...
My first version will probably be a perf-board prototype. I can control the clockspeed so if it's too noisy I just lower the clock speed.

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

Re: ICE T65/Z80/6809

Post by hoglet » Tue Oct 22, 2019 2:38 pm

obiwanjacobi wrote:
Tue Oct 22, 2019 2:11 pm
Wow. that means that the manual actually suggests something that could potentially blow up the RFSH pin... :shock: :?
Yes, if you tried to pull RFSH low for a long time with a high current driver, then it could potentially damage the Z80.

There is some discussion of this in the comments of this blog post:
http://baltazarstudios.com/arduino-zilog-z80/
obiwanjacobi wrote:
Tue Oct 22, 2019 2:11 pm
My system uses BUSREQ/BUSACK extensively.
I am currently looking into building the adapter board. The board that is in the repo is too big and high for me (stacked design).
I am thinking about doing something with a ribbon cable and a 40-pin dip connector at the end...
My first version will probably be a perf-board prototype. I can control the clockspeed so if it's too noisy I just lower the clock speed.
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 neccessary because I think step (2) mirrors the connections.

Anyway, do keep us posted on your progress.

I have some spare boards if you want one (£5 + postage).

Dave

User avatar
BigEd
Posts: 2646
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: ICE T65/Z80/6809

Post by BigEd » Tue Oct 22, 2019 2:50 pm

I suppose Sinclair would use a resistor to separate the Z80's refresh pin from the external driver, and Amstrad would use a logic gate to combine the two signals.

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

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Wed Oct 23, 2019 4:48 am

hoglet wrote:
Tue Oct 22, 2019 2:38 pm
I have some spare boards if you want one (£5 + postage).
Really? Yes that would help me out. Thanks.

EDIT: Trying to DM you:
We are sorry, but you are not authorised to use this feature. You may have just registered here and may need to participate more in discussions to be able to use this feature.
I'll guess we'll chat some more first... :D
Or contact me at: obiwanjacobi at hotmail dot com

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

Re: ICE T65/Z80/6809

Post by Elminster » Wed Oct 23, 2019 9:37 am

You can click the 'Contact Us' link at the bottom of the page, and ask an admin to give you DMs.

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

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Wed Oct 23, 2019 10:13 am

Nah, we've got it sorted.

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

Re: ICE T65/Z80/6809

Post by Elminster » Wed Oct 23, 2019 3:10 pm

obiwanjacobi wrote:
Wed Oct 23, 2019 10:13 am
Nah, we've got it sorted.
You still might want to do it anyway.

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

Re: ICE T65/Z80/6809

Post by hoglet » Wed Oct 23, 2019 3:12 pm

I've added some construction notes on the wiki for the Z80 board:
https://github.com/hoglet67/AtomBusMon/ ... PU-Adapter

I'll do the 6502 version next...

Dave

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

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Wed Oct 23, 2019 4:45 pm

I am trying to find information on programming the Xilinx Spartan6 - my board has not arrived yet - so no hurry.
I understand that Xilinx has its own usb to jtag device (Ebay link to platform cable in the wiki) but how special is it really? I have an USB Blaster that I used for programming Altera CPLDs (and Cyclone II) that sort of does the same job...
What software do I need to program the Xilinx Spartan6 with the release binaries (.msc) from github?
What do you guys use?

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

Re: ICE T65/Z80/6809

Post by hoglet » Wed Oct 23, 2019 4:58 pm

obiwanjacobi wrote:
Wed Oct 23, 2019 4:45 pm
I am trying to find information on programming the Xilinx Spartan6 - my board has not arrived yet - so no hurry.
I understand that Xilinx has its own usb to jtag device (Ebay link to platform cable in the wiki) but how special is it really? I have an USB Blaster that I used for programming Altera CPLDs (and Cyclone II) that sort of does the same job...
What software do I need to program the Xilinx Spartan6 with the release binaries (.msc) from github?
What do you guys use?
I have only ever used an£20 Chinese clone of the Xilinx Platform Cable, together with the Xilinx iMpact programming software which is part of ISE 14.7. I'm pretty sure that iMpact will not work with a generic JTAG cable.

When iMpact needs to program the seperate FLASH device, it first loads a design to the FPGA which provides a programming interface to the FLASH. This design is included as part of iMpact. This is needed because the FLASH device is not connected directly to the JTAG pins.

For the Spartan 3 series, there was an open source project called xc3sprog:
http://xc3sprog.sourceforge.net

I've never tried this, but I believe it works with Spartan 6.

Sorry I can't be more help here.

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Wed Nov 06, 2019 4:13 pm

Hi Dave,

Tried to recompile your /Dev version today (using a Windows 10 environment). In general this goes OK but the 65C02 as well as the 6809 version give me a bit of a worrying warning :

Code: Select all

WARNING:PhysDesignRules:2410 - This design is using one or more 9K Block RAMs
   (RAMB8BWER).  9K Block RAM initialization data, both user defined andINFO:TclTasksC:1850 - process run : Generate Programming File is done.

   default, may be incorrect and should not be used.  For more information,
   please reference Xilinx Answer Record 39999.

Process "Generate Programming File" completed successfully
data2mem -bm memory_bd.bmm -bd avr_progmem.mem -bt working/MOS6502CpuMonALS.bit -o b ice65c02.bit
promgen -u 0 ice65c02.bit -o ice65c02.mcs -p mcs -w -spi -s 8192
Release 14.7 - Promgen P.20131013 (nt64)
Copyright (c) 1995-2013 Xilinx, Inc.  All rights reserved.
0x53394 (340884) bytes loaded up from 0x0
Using user-specified prom size of 8192K
Writing file "ice65c02.mcs".
Writing file "ice65c02.prm".
Writing file "ice65c02.cfi".
PROM Generation goes OK now.

Code: Select all

C:\cygwin64\home\BProsman\AtomBusMon\target\lx9_dave>promgen -u 0 loader/working/MultiBootLoader.bit -u 54000 unknown/working/UnknownAdapter.bit -u A8000 ice6502/ice6502.bit -u FC000 icez80/icez80.bit -u 150000 ice65c02/ice65c02.bit -u 1A4000 ice6809/ice6809.bit -o multiboot.mcs  -p mcs -w -spi -s 8192
Release 14.7 - Promgen P.20131013 (nt64)
Copyright (c) 1995-2013 Xilinx, Inc.  All rights reserved.
0x5327c (340604) bytes loaded up from 0x0
0x5327c (340604) bytes loaded up from 0x54000
0x5327c (340604) bytes loaded up from 0xa8000
0x5327c (340604) bytes loaded up from 0xfc000
0x53394 (340884) bytes loaded up from 0x150000
0x536d0 (341712) bytes loaded up from 0x1a4000
Using user-specified prom size of 8192K
Writing file "multiboot.mcs".
Writing file "multiboot.prm".
Writing file "multiboot.cfi".
Just verifying, but when I dont use the "Loader" and have multiple EEPizza boards I can do with the seperate (CPU) builds can I ?

Kind regards, Bram

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

Re: ICE T65/Z80/6809

Post by hoglet » Wed Nov 06, 2019 6:18 pm

Hi Bram,
bprosman wrote:
Wed Nov 06, 2019 4:13 pm

Code: Select all

WARNING:PhysDesignRules:2410 - This design is using one or more 9K Block RAMs
   (RAMB8BWER).  9K Block RAM initialization data, both user defined andINFO:TclTasksC:1850 - process run : Generate Programming File is done.

   default, may be incorrect and should not be used.  For more information,
   please reference Xilinx Answer Record 39999.
Here's Xilinx Answer Record 39999:
https://www.xilinx.com/support/answers/39999.html

This refers to a hardware bug in the Spartan 6 FPGA concerning block RAM initialization of 9K size block RAMS. A fix was added to bitgen in ISE 13.2 (and later), but that fix is invalid if bitstream encryption is used. So we can safely ignore this.

As you have probably noticed, there has been lots of change over the last week, including today:
  • T65/T80 updated to latest versions
  • 6502 - correctly show SP value in register display
  • 65C02 - correctly show PC value in register display
  • Z80 - correctly show INT/NMI/HALT bus cycles when stepping
  • show ASCII in rd/wr commands
  • lots of refactoring of the VHDL to clean up 5 years of technical debt
  • right button is always reset AVR
  • left button is always reset CPU
  • add reset debouncing to avoid multiple resets
  • added a "next" command (sets a transient breakpoint on the next instruction)
  • breakpoints/watchpoints now work when single stepping
  • fix bug when CPU clock << 1MHz (by adding proper command handshaking with AVR)
  • C type changes (save ~400 bytes in code space). making room for...
  • simple command history (up/down arrows)
  • added a "history" command
So if you notice any new bugs, please do let me know.

One known issue with the new command handshaking is the UI will lock up if the CPU clock is not present. I'm working on fix for this (that will generate a no clock warning).

I've also just got back the MC6809E CPU adapter board. I build one yesterday, and it seems to be working fine in the Dragon 32. I did however, need to fit the clock condition filter: R14=120R and C15=47pF, so I'm glad I made provision for this.

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Wed Nov 06, 2019 6:25 pm

Going to test further tomorrow on the Z80 and 6502 coming weekend.
I wont use the 6809 and 65C02 (for now). Switches are unfortunately not in... packages from China nowadays take 4...5 weeks.

Thanks so far, you're going faster in releasing than I can keep up with building / testing :D

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Nov 08, 2019 12:06 pm

Here's some photos of the 6809E CPU Adapter (version 1.00):
IMG_1805.JPG
IMG_1806.JPG
IMG_1807.JPG
IMG_1809.JPG
So far this has just been tested in the Dragon 32.

As I mentioned a few posts up, I needed to populate the clock filter components (R14=120R and C15=47pF) to get it top operate stably, because the clock on the Dragon was a bit ropey.

On the subject of the Dragon, I've always struggled to get the reset button to work reliably when using the GODIL version ICE-6809. I've looked into this a bit more, and was down to several factors:

1. The Dragon reset circuit involves two seperate RC components, and several 1N914 diodes:
Screenshot from 2019-11-08 11-46-57.png
This is designed so that 6809E is released from reset after the MC6883 SAM.

2. The GODIL 1.5K pullups really mess this up, so that when the ICE-6809 starts running, the MC6883 SAM is stillbeing held in reset. This means the first few writes to the SAM are ignored. These turn out to be quite important, and without these the Dragon startup fails.

3. To try to fix this, I added some reset debouncing to the ICE-6809, to clean up and extend the duration of the reset. Attempt 1 at this didn't work.

4. The reason it didn't work is that the Dragon reset switch operates via a 1N914 diode, so when held down, the 6809 sees a low of 0.7V.

5. When using the GODIL version of ICE-6809, the 1.5K pullups raise this to about 1.0V. There is enough switching noise in the Dragon that even when the reset switch was being depressed, the reset signal was occasionally being seen by the ICE-6809 as a '1'.

6. Attempt 1 at reset debouncing used a symetric debouncing algorithm, so it never saw reset being consistently held low for long enough to register.

7. Attempt 2 at switch debouncing used an asymettric debouncing algorithm. This works very well, and resetting the Dragon is now 100% reliable.

I've had reset reliability problems on other systems, so I've incorporated this debouncing logic into the common BusMon component of the ICE, so it's now present on all the different CPU targets.

Dave

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Nov 08, 2019 12:14 pm

Here's some photos of the revised 65C02 CPU Adapter (the version is now 1.10):
IMG_1810.JPG
IMG_1811.JPG
IMG_1812.JPG
IMG_1813.JPG
The only change from version 1.00 is to allow for weak (22K) pullup resistors on:
- nSO (R16)
- nRST (R17)
- nRDY (R18)
- nIRQ (R19)
- nNMI (R20)
You can see these underneath, next to the DIP header.

Most correctly designed systems (like the Atom) already include the pullups (usually 3K3) on these signals. However, I found the Beeb Model B doesn't include a pullup on nRDY. [-X

I would recommend fitting them regardless.

Dave

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Nov 08, 2019 1:04 pm

Here's the final ICE update for today.... (probably)

Next up on the ICE test bench we have a Camputers Lynx (kindly loaned by Revaldhino):
IMG_1797.JPG
This is a 4MHz Z80 based machine:
IMG_1798.JPG
Let's replace the Z80 with the ICE-Z80:
IMG_1799.JPG
And take a closer look:
IMG_1802.JPG
This is a very unusual system, in that it uses BusReq/BusAck to stop the Z80 when the 6845 needs to read Video Data out of RAM, which makes it very slow indeed. It also seems to make no use of Z80 INT interrupts, and the only interrupt related instructions in the ROM Disassembly are two DI instructions (at 0000 and 168C).

This is the first test of the ICE-Z80's BusReq/BusAck functionality, so I was expecting problems, and I was not dissapointed.

First boot did not look promising, as I was met with silence and a blank screen. Looking at memory with the ICE, I could find no evidence of ROM at address 0000 (or for that matter anywhere else) in the memory map.

Next I set a break point at 0000, power cycled the Lynx, and took another look:

Code: Select all

>> c
Ex Brkpt hit at 0000
Interrupted
00.000006: 0000 : DI   
>> d 0                          
0000 : DI   
0001 : LD   A,$20
0003 : OUT  ($80),A
0005 : JP   $003B
0008 : JP   $351B
000B : LD   B,H
000C : LD   H,C
000D : HALT 
000E : LD   L,C
000F : LD   (HL),E
That looked better, so I started single stepping, and when the OUT instuction at 0003 was executed, the ROM promply vanished!

On the Lynx, there is a 8-bit register in the IO address space at XX7F that controls the bank switching. This is cleared by the power up reset, and for some reason this was being corrupted by the IO write to XX80.

This register turns out to be IC54, a 74LS273 which is rising edge triggered:
Screenshot from 2019-11-08 12-32-33.png
The clock is generated by NORing two signals:
- nIORQ
- the output of IC63, a 74LS30 NAND gate, that is not(A6 . A5 . A4 . A3 . A2 . A1 . A0)

This part of the design is well dodgy for several reasons:
1. It doesn't use the nWR or the nRD signal, so a read of this location will corrupt the register, as will an interrupt acknowledge cycle
2. If the register is corrupted, multiple banks can be enabled for reading at the same time, causing bus conflicts (oops)
3. The write happens at the start of the IO cycle (on the falling edge or nIORQ) which is not typical

In fact, a Lynx User article I found on the Lynx's bank switching says the following:
Screenshot from 2019-11-08 12-39-55.png
At this point I started to be very careful, as it's not my Lynx.

In spite of the dodgy design, it does work on a real Z80, but not on the ICE-Z80, so there is an issue here to be resolved.

To avoid damaging the Lynx, I temporarly switched to a different system, and carefully checked the ICE Z80's IO cycle timing on a scope.

The best diagrams of the Z80 bus cycles are in more recenty Z80 documentation, such as this version from 1984:
http://www.bitsavers.org/components/zil ... _Feb84.pdf

After studying these for a while, and comparing what the ICE-Z80 was outputing, there were some minor differences. These are inconsequential on most systems, but not on the Lynx.

And after fixing these (in the T80 Core), success:
IMG_1803.JPG
(This actually takes 10 seconds to run)

So the list of Z80 systems that have been tested is now a bit longer:
- ZX81
- ZX Spectrum 48K (Issue 4S)
- ZX Spectrum +2B
- Acorn External Z80 Co Processor
- CPC 464
- Micro Professor MPF-1
- Camputers Lynx

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Fri Nov 08, 2019 1:29 pm

Nice work Dave :-)
Will this be a fix on the 0.90 version or does it get a 0.91 number ?

Kind regards, Bram

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Nov 08, 2019 1:57 pm

bprosman wrote:
Fri Nov 08, 2019 1:29 pm
Will this be a fix on the 0.90 version or does it get a 0.91 number ?
There should be a 0.92 version on github now:
https://github.com/hoglet67/AtomBusMon/commits/dev

What's been tricky about the Z80 IORQ timings is that sometimes IORQ changes on the falling edge of the clock, sometimes it changes on the rising edge of the clock. This makes generating it correctly (and without glitches) quite involved.

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Fri Nov 08, 2019 3:16 pm

Just realising I have a P2000 under my bed I might be able to add to the list.
Unfortunately health (concentration) wise I'm not up to speed (yet) :(

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

Re: ICE T65/Z80/6809

Post by hoglet » Mon Nov 11, 2019 12:16 pm

bprosman wrote:
Fri Nov 08, 2019 3:16 pm
Just realising I have a P2000 under my bed I might be able to add to the list.
Unfortunately health (concentration) wise I'm not up to speed (yet) :(
That would be good to add to the list, but your health comes first!

I'm continuing to work on the firmware (upto version 0.95 now...)

Several new features in the last week:

1. Detect a CPU missing clock, and generate a warning rather than lock up.

2. Improve the Z80 register display:

Code: Select all

>> regs
Z80 Registers:
  A=7F  BC=0007  DE=3B00  HL=34EF  F=7C (-ZYHXP--)
 'A=29 'BC=0000 'DE=0000 'HL=0000 'F=87 (S----PNC)
  R=41  IX=34EE  IY=3B34  PC=F69D SP=DBF6 I=FF IM=2 IFF1=1 IFF2=1
>> 
3. Add hex opcodes to the disassembly:

Code: Select all

>> dis fa80 fa98
FA80 : F4 DB ED       : CALL P,$EDDB
FA83 : 73             : LD   (HL),E
FA84 : 80             : ADD  A,B
FA85 : FA 31 60       : JP   M,$6031
FA88 : FF             : RST  7
FA89 : CD 93 FA       : CALL $FA93
FA8C : ED 7B 80 FA    : LD   SP,($FA80)
FA90 : FB             : EI   
FA91 : ED 4D          : RETI 
FA93 : F5             : PUSH AF
FA94 : DB 06          : IN   A,($06)
FA96 : CB 7F          : BIT  7,A
FA98 : 20 71          : JR   NZ,$FB0B
4. Increase the AVR clock from 16MHz to 24MHz in the "lx9_dave" targets.

5. Run at 115200 baud in the "lx9_dave" targets.

I've also been spending time reducing the code size, since the GODIL 250 has very little block RAM. I need to limit the 65C02 build to 16KB code and 2KB data, as this is used in other projects (like BeebFPGA). I've saved about 2KB of code by gradually rewriting the logging code, avoiding any use of log0 (which is fprintf). So the 65C02 build is now down to 13.5KB.

I have a question for any of the Z80 experts out there. What's the longest Z80 instruction? I've left space for 5 bytes in the disassembly, but I'm struggling to find a legitimate 5-byte opcode (that doesn't contain redundant prefixes).

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Mon Nov 11, 2019 12:36 pm

Not a Z80 expert at all but I cant find any more than 4.
TASM.ZIP
(16.33 KiB) Downloaded 1 time

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

Re: ICE T65/Z80/6809

Post by obiwanjacobi » Mon Nov 11, 2019 1:38 pm

I know of max 4 opcode bytes and max 6 T cycles.

I have made a definition file that should contain all possible instructions, including the undocumented.
https://github.com/obiwanjacobi/Zingula ... nsZ80.json

[2c]

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

Re: ICE T65/Z80/6809

Post by hoglet » Fri Nov 15, 2019 7:07 pm

Hi all,

There have been quite a few more additions over the last few days...

I now detect (in hardware) that the 512 entry event FIFO is full and track the number of lost events. This is very useful for determining if you have a complete log of watch events, or whether there are some gaps. Here's an example:

Code: Select all

04.753405 : Mem Rd Watch hit at E4E2 reading FFFE:1C  .
04.753405 : Mem Rd Watch hit at E4E2 reading FFFF:DC  .
04.753412 : Ex Watch hit at DC1C
04.757952 : Mem Rd Watch hit at DEF4 reading FFFE:1C  .
04.757952 : Mem Rd Watch hit at DEF4 reading FFFF:DC  .
          : 1 event dropped
04.766263 : Mem Rd Watch hit at E4E2 reading FFFE:1C  .
          : 2 events dropped
04.775350 : Mem Rd Watch hit at DEF0 reading FFFE:1C  .
          : 2 events dropped
04.777926 : Mem Rd Watch hit at E464 reading FFFE:1C  .
There is now also a flush command, to explicitly clear the event FIFO.

I've done a some more code optimization, eliminating usage of sscanf(), which has freed up a further 1,864 bytes (~10%-15%) of the total code size.

To use up this space, I've added the following commands:
- memory copy
- memory compare
- binary load
- binary save

Here's an example of copy and compare:

Code: Select all

>> mem 8000
8000 C9 01 F0 1F 60 EA 60 0E 01 42 41 53 49 43 00 28  ....`.`..BASIC.(
8010 43 29 31 39 38 32 20 41 63 6F 72 6E 0A 0D 00 00  C)1982 Acorn....
8020 80 00 00 A9 84 20 F4 FF 86 06 84 07 A9 83 20 F4  ..... ........ .
8030 FF 84 18 A2 00 86 1F 8E 02 04 8E 03 04 CA 86 23  ...............#
8040 A2 0A 8E 00 04 CA 8E 01 04 A9 01 25 11 05 0D 05  ...........%....
8050 0E 05 0F 05 10 D0 0C A9 41 85 0D A9 52 85 0E A9  ........A...R...
8060 57 85 0F A9 02 8D 02 02 A9 B4 8D 03 02 58 4C DD  W............XL.
8070 8A 41 4E 44 80 00 41 42 53 94 00 41 43 53 95 00  .AND..ABS..ACS..
8080 41 44 56 41 4C 96 00 41 53 43 97 00 41 53 4E 98  ADVAL..ASC..ASN.
8090 00 41 54 4E 99 00 41 55 54 4F C6 10 42 47 45 54  .ATN..AUTO..BGET
80A0 9A 01 42 50 55 54 D5 03 43 4F 4C 4F 55 52 FB 02  ..BPUT..COLOUR..
80B0 43 41 4C 4C D6 02 43 48 41 49 4E D7 02 43 48 52  CALL..CHAIN..CHR
80C0 24 BD 00 43 4C 45 41 52 D8 01 43 4C 4F 53 45 D9  $..CLEAR..CLOSE.
80D0 03 43 4C 47 DA 01 43 4C 53 DB 01 43 4F 53 9B 00  .CLG..CLS..COS..
80E0 43 4F 55 4E 54 9C 01 44 41 54 41 DC 20 44 45 47  COUNT..DATA. DEG
80F0 9D 00 44 45 46 DD 00 44 45 4C 45 54 45 C7 10 44  ..DEF..DELETE..D
>> mem 3000
3000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
3090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
30A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
30B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
30C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
30D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
30E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
30F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> crc 8000 bfff
crc: 4274
>> crc 3000 6fff
crc: 0000
>> copy 8000 bfff 3000
>> crc 3000 6fff
crc: 4274
>> compare 3000 6fff 8000
>> wr 4567 aa
Wr:  4567:AA  .
>> compare 3000 6fff 8000
Compare failed: 4567:AA  . /= 9567:B0  .
The help command is also greatly improved. Commands are listed in alphabetical order, and now include the argument syntax.

Code: Select all

>> help
ICE-6502 In-Circuit Emulator version 0.981
Compiled at 18:13:16 on Nov 15 2019
8 watches/breakpoints implemented
Commands:
   blist    
   breakr   <address> [ <mask> [ <trigger> ] ]
   breakw   <address> [ <mask> [ <trigger> ] ]
   breakx   <address> [ <mask> [ <trigger> ] ]
   clear    <address>
   compare  <start> <end> <to>
   continue [ <reset> ]
   copy     <start> <end> <to>
   crc      <start> <end>
   dis      [ <start> [ <end> ] ]
   fill     <start> <end> <data>
   go       <address>
   exec     <op1> [ <op2> [ <op3> ] ]
   flush    
   help     [ <command> ]
   history  
   load     <address>
   mem      [ <address> ]
   mode     [ <value> ]
   next     
   rd       [ <address> [ <count> ] ]
   regs     
   reset    
   save     <start> <end>
   special  [ <value> ]
   srec     
   step     [ <instructions> ]
   test     <start> <end> [ <test num> ]
   trace    [ <instructions> ]
   trigger  [ <address> <trigger> ]
   watchr   <address> [ <mask> [ <trigger> ] ]
   watchw   <address> [ <mask> [ <trigger> ] ]
   watchx   <address> [ <mask> [ <trigger> ] ]
   wr       <address> <data> [ <count> ]
You can also get help on individual commands, in a couple of ways:

Code: Select all

>> help breakx
   breakx   <address> [ <mask> [ <trigger> ] ]
>> breakx ?
   breakx   <address> [ <mask> [ <trigger> ] ]
And if you use a command incorrectly, you get prompted with the required arguments:

Code: Select all

>> fill 7c00 7fff
usage:
   fill     <start> <end> <data>
I've also been experimenting with executing specific opcodes, by forcing values onto the processor data bus (internally in the FPGA). This is currently just available on the 6502/65C02 versions, because it's quite processor specific.

The first application of this is a go command, that works by injecting a JMP instruction:

Code: Select all

CPU free running...
Interrupted
02.634980 : E466 : BD D8 02 : LDA $02D8,X
>> dis 4000
4000 : A9 AA    : LDA #$AA
4002 : 4C 00 40 : JMP $4000
4005 : 00       : BRK 
4006 : 00       : BRK 
4007 : 00       : BRK 
4008 : 00       : BRK 
4009 : 00       : BRK 
400A : 00       : BRK 
400B : 00       : BRK 
400C : 00       : BRK 
>> regs
6502 Registers:
  A=00 X=00 Y=0A SP=01EE PC=E466
  Status: ---B-IZC
>> go 4000
02.634987 : 4000 : A9 AA    : LDA #$AA
>> step 4
Stepping 4 instructions
02.634989 : 4002 : 4C 00 40 : JMP $4000
02.634992 : 4000 : A9 AA    : LDA #$AA
02.634994 : 4002 : 4C 00 40 : JMP $4000
02.634997 : 4000 : A9 AA    : LDA #$AA
>> regs
6502 Registers:
  A=AA X=00 Y=0A SP=01EE PC=4000
  Status: N--B-I-C
The implementation actually allows a single arbitrary instruction to be injected, using the exec command. So you can do pretty much anything, for example setting registers:

Code: Select all

>> regs 
6502 Registers:
  A=AA X=00 Y=0A SP=01F1 PC=E584
  Status: N--B---C
>> exec a9 00
03.339284 : E584 : F0 B3    : BEQ $E539
>> exec a2 11
03.339295 : E584 : F0 B3    : BEQ $E539
>> exec a0 22
03.339304 : E584 : F0 B3    : BEQ $E539
>> regs
6502 Registers:
  A=00 X=11 Y=22 SP=01F1 PC=E584
  Status: ---B---C
>> 
And finally, as there is still plenty of code space, especially in the 6502 build, I've started working on some Beeb specific test commands.

The first one I've implemented is a mode command that does the following:

Code: Select all

  // Initialize System VIA
  writeReg(0xfe42, 0x0f);
  // Initialize addressable latch
  for (i = 15; i >= 8 ; i--) {
    writeReg(0xfe40, i);
  }
  // Initialize SN76489
  for (i = 0; i < sizeof(soundinit); i++) {
    writeSoundByte(pgm_read_byte(soundinit + i));
  }
  // Initialize 6845
  for (i = 0; i <= 15; i++) {
    writeReg(0xfe00, i);
    writeReg(0xfe01, pgm_read_byte(reg_data++));
  }
  // Initialize Video ULA
  writeReg(0xfe20, pgm_read_byte(video_ula + mode));
  // Initialize Palette
  for (i = 0; i <= 15; i++) {
    writeReg(0xfe21, pgm_read_byte(pal_data++));
  }
  // Generate a ^G beep
  writeSoundTriple(0x92, 0x8f, 0x0e);
  Delay_ms(500);
  writeSoundTriple(0x9f, 0x9f, 0x9f);
}
So even if the Beeb is not able to execute any MOS code (in my case because the OS ROM is unplugged), the ICE-6502 can initialize the video and sound hardware, so you can see the effects of other commands (like memory tests).

I'm now hoping some broken Model B's will turn up at ABUG!

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Sun Nov 17, 2019 10:49 am

Hi Dave,

Trying to keep up with your changes and compiling myself. All well except the 65C02 version.
The 9K block you explained. But running into an error later on (incorrect number of bits in bitstream).

Regards Bram

Code: Select all

Started : "Generate Programming File".
Running bitgen...
Command Line: bitgen -intstyle ise -f MOS6502CpuMonALS.ut MOS6502CpuMonALS.ncd
INFO:Bitgen:341 - This design is using one or more 9K Block RAMs (RAMB8BWER).
   9K Block RAM initialization data, both user defined and default, requires a
   special bit stream format.  For more information, please reference Xilinx
   Answer Record 39999.
INFO:PhysDesignRules:1861 - To achieve optimal frequency synthesis performance
   with the CLKFX and CLKFX180 outputs of the DCM comp
   wrapper/inst_dcm0/DCM_INST, consult the devINFO:TclTasksC:1850 - process run : Generate Programming File is done.
ice Data Sheet.
WARNING:PhysDesignRules:2410 - This design is using one or more 9K Block RAMs
   (RAMB8BWER).  9K Block RAM initialization data, both user defined and
   default, may be incorrect and should not be used.  For more information,
   please reference Xilinx Answer Record 39999.
[b]FATAL_ERROR:Bitstream:stanbsbitfile.c:3408:1.57 - Incorrect number of bits in
   bitstream (18) for FDRI write.   For technical support on this issue, please
   visit http://www.xilinx.com/support.[/b]

Process "Generate Programming File" failed
data2mem -bm memory_bd.bmm -bd avr_progmem.mem -bt working/MOS6502CpuMonALS.bit -o b ice65c02.bit


INTERNAL_ERROR:Data2MEM:45 - Memory allocation leak of 136 bytes at 0x00E343C8 for a 'fileIODescriptorType' record.
    Total memory in use at allocation was 3313 bytes.
    Source file "FileUtils.c", line number 1853.

Memory contents:

 00E343C8:   00 00 00 00 00 00 00 00 FF FF FF FF 01 00 00 00   ................
 00E343D8:   60 C6 D7 62 00 00 00 00 18 97 E3 00 00 00 00 00   `..b............
 00E343E8:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00E343F8:   00 00 00 00 FF FF FF FF 00 00 00 00 00 00 00 00   ................


INTERNAL_ERROR:Data2MEM:45 - Memory allocation leak of 52 bytes at 0x00E34878 for a StrDup.
    Total memory in use at allocation was 3449 bytes.
    Source file "FileUtils.c", line number 1858.

Memory contents:

 00E34878:   01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00E34888:   77 6F 72 6B 69 6E 67 5C 4D 4F 53 36 35 30 32 43   working\MOS6502C
 00E34898:   70 75 4D 6F 6E 41 4C 53 2E 62 69 74 00 00 00 00   puMonALS.bit....
 00E348A8:   00 00 00 00                                       ....


INTERNAL_ERROR:Data2MEM:45 - Memory allocation leak of 3 bytes at 0x00E39718 for 'char' data.
    Total memory in use at allocation was 3501 bytes.
    Source file "FileUtils.c", line number 1919.

Memory contents:

 00E39718:   00 00 00                                          ...

make: *** [../../common/Makefile.inc:43: ice65c02.bit] Error 127

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

Re: ICE T65/Z80/6809

Post by hoglet » Sun Nov 17, 2019 11:32 am

bprosman wrote:
Sun Nov 17, 2019 10:49 am
Trying to keep up with your changes and compiling myself. All well except the 65C02 version.
The 9K block you explained. But running into an error later on (incorrect number of bits in bitstream).
Hmm, I can't reproduce that one:

Code: Select all

Started : "Generate Programming File".
Running bitgen...
Command Line: bitgen -intstyle ise -f MOS6502CpuMonALS.ut MOS6502CpuMonALS.ncd
INFO:Bitgen:341 - This design is using one or more 9K Block RAMs (RAMB8BWER). 
   9K Block RAM initialization data, both user defined and default, requires a
   special bit stream format.  For more information, please reference Xilinx
   Answer Record 39999.
INFO:PhysDesignRules:1861 - To achieve optimal frequency synthesis performance
   with the CLKFX and CLKFX180 outputs of the DCM comp
   wrapper/inst_dcm0/DCM_INST, consult the device Data Sheet.
WARNING:PhysDesignRules:2410 - This design is using one or more 9K Block RAMs
   (RAMB8BWER).  9K Block RAM initialization data, both user defined and
   default, may be incorrect and should not be used.  For more information,
   please reference Xilinx Answer Record 39999.

Process "Generate Programming File" completed successfully
INFO:TclTasksC:1850 - process run : Generate Programming File is done.
data2mem -bm memory_bd.bmm -bd avr_progmem.mem -bt working/MOS6502CpuMonALS.bit -o b ice65c02.bit
promgen -u 0 ice65c02.bit -o ice65c02.mcs -p mcs -w -spi -s 8192
Release 14.7 - Promgen P.20131013 (lin64)
Copyright (c) 1995-2013 Xilinx, Inc.  All rights reserved.
0x53394 (340884) bytes loaded up from 0x0
Using user-specified prom size of 8192K
Writing file "ice65c02.mcs".
Writing file "ice65c02.prm".
Writing file "ice65c02.cfi".
rm -f ice65c02.cfi ice65c02.prm
Can you confirm that you are building version 0.981 (commit 0f1bab1)

Is the error consistent?

What's the last verion that did work for you?

i.e. if you do "make clobber build" does it happen every time?

It seems you might be hitting a Window 10 specific Xilinx issue:
https://forums.xilinx.com/t5/General-Te ... d-p/676305

You might try experimenting with compatibility mode, as described in that link.

As far as I understand, the only "supported" way to run ISE on Windows 10 is to use the Xilinx provided VM Image (which I think is actually running Linux).

Dave

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

Re: ICE T65/Z80/6809

Post by bprosman » Sun Nov 17, 2019 12:09 pm

Hi Dave,

The 0.90 version (which I last compiled last week) did work for me.
All other CPU's are compiling fine just the 65C02 doesnt.
Not really a pain as I actually never use it , the normal 6502 and Z80 do work.

I indeed use version 0.981
#define VERSION "0.981"

Yes it is reproducible with Make Clobber
What Unix/Linux version do you use yourself ?

Let me play with the compatibility mode.

Kind regards, Bram

Post Reply