ICE T65/Z80/6809

emulators, hardware and classic software for atom + system machines
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

cyberbarter wrote:
Sun Sep 26, 2021 2:05 am
Do you take donations. I very much would like to reward you for your efforts.
I've sent you a PM.

I hope you manage to get your 6502 ICE working.

What host machine will you be using it with?

Please continue to ask questions in this thread if you need help.

Dave
cyberbarter
Posts: 10
Joined: Wed Aug 18, 2021 7:42 pm
Contact:

Re: ICE T65/Z80/6809

Post by cyberbarter »

Hi ICE friends.

I am having issues with a Pi4B. I have a Pi1B working fine so this is not a high priority for me. It is all about the journey.

OpenOCD Failures programming EEPIZZA FPGA on Pi4B
Note:I have no problems running any of the below on a Pi1B using either the frame_buffer.bit .bin files or the iceT6502.bit .bin files

Pi4B Info:

(I'm using 2020-02-13-raspbian-buster-full.img) on a Pi4B

I downloaded the 32bit Oi OS version from: https://downloads.raspberrypi.org/raspb ... 020-02-14/

I am running OpenOCD 0.10.0-5
sudo apt-get update
sudo apt-get install openocd=0.10.0-5


My local.cfg file contains:
interface bcm2835gpio
bcm2835gpio_trst_num 7
adapter_khz 200


I made changes to /usr/share/openocd/scripts/interface/raspberrypi-native.cfg

bcm2835gpio_peripheral_base 0xFE000000
bcm2835gpio_speed_coeffs 236181 60


My Bscan file is from:
wget https://github.com/quartiq/bscan_spi_bi ... c6slx9.bit

Pi1B .bit file Success example:
When I program the .bit file into the FPGA “ram” using the Pi1B, the EEPIZZA reboots and only the yellow LD10 DONE and blue LD9 PWR LEDs are lit. Everything looks fine.
Here is the output for the Pi1B
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: trst = 7
adapter speed: 250 kHz
Warn : Interface already configured, ignoring
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
xc6s_print_dna
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
Info : clock speed 250 kHz
Info : JTAG tap: xc6s.tap tap/device found: 0x24001093 (mfg: 0x049 (Xilinx), part: 0x4001, ver: 0x2)
Warn : gdb services need one or more targets defined
loaded file frame_buffer.bit to pld device 0 in 11s 536903us


Pi4B .bit file failure example:
When I program the .bit file into the FPGA “ram” using the Pi4B, the EEPIZZA does not seem to reboot and only the blue LD9 PWR and blue LD1-LD8 LEDs are lit. No yellow LD10 DONE LED is lit.
Here is the output for the RP4B
NOTE: There is a considerable time difference loading the .bit file to the pld device between the Pi1B and the Pi4B and this could be indicative of some timing issue.
pi@raspberrypi4B:~ $ sudo openocd -f local.cfg -f /usr/share/openocd/scripts/interface/raspberrypi-native.cfg -f /usr/share/openocd/scripts/cpld/xilinx-xc6s.cfg -c "init; xc6s_program xc6s.tap; pld load 0 frame_buffer.bit; exit"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: trst = 7
adapter speed: 200 kHz
Warn : Interface already configured, ignoring
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
xc6s_print_dna
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
Info : clock speed 200 kHz
Info : JTAG tap: xc6s.tap tap/device found: 0x24001093 (mfg: 0x049 (Xilinx), part: 0x4001, ver: 0x2)
Warn : gdb services need one or more targets defined
loaded file frame_buffer.bit to pld device 0 in 4s 947634us


Pi4B .bin file failure example 1: Error: Unknown flash device (ID 0x00000000)
Most of the time when I attempt to program the .bin file into the FPGA “FLASH” using the Pi4B, the EEPIZZA I get the Error: Unknown flash device (ID 0x00000000)
Here is the output for the Pi4B

pi@raspberrypi4B:~ $ sudo openocd -f local.cfg -f /usr/share/openocd/scripts/interface/raspberrypi-native.cfg -f /usr/share/openocd/scripts/cpld/xilinx-xc6s.cfg -f /usr/share/openocd/scripts/cpld/jtagspi.cfg -c "init; jtagspi_init 0 bscan_spi_xc6slx9.bit; jtagspi_program frame_buffer.bin 0; xc6s_program xc6s.tap; shutdown"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: trst = 7
adapter speed: 200 kHz
Warn : Interface already configured, ignoring
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
xc6s_print_dna
jtagspi_program
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
Info : clock speed 200 kHz
Info : JTAG tap: xc6s.tap tap/device found: 0x24001093 (mfg: 0x049 (Xilinx), part: 0x4001, ver: 0x2)
loaded file bscan_spi_xc6slx9.bit to pld device 0 in 2s 440935us
Info : JTAG tap: xc6s.tap tap/device found: 0x24001093 (mfg: 0x049 (Xilinx), part: 0x4001, ver: 0x2)
Error: Unknown flash device (ID 0x00000000)


Pi4B .bin file failure example 2: contents differ diff 0 address 0x00000100. Was 0xff instead of 0x00
Occasionally/intermittently when I attempt to program the .bin file into the FPGA “FLASH” using the Pi4B, I get the contents differ diff 0 address 0x00000100. Was 0xff instead of 0x00
Here is the output for the Pi4B
Note: below diff errors 1-126 removed for clarity

pi@raspberrypi4B:~ $ sudo openocd -f local.cfg -f /usr/share/openocd/scripts/interface/raspberrypi-native.cfg -f /usr/share/openocd/scripts/cpld/xilinx-xc6s.cfg -f /usr/share/openocd/scripts/cpld/jtagspi.cfg -c "init; jtagspi_init 0 bscan_spi_xc6slx9.bit; jtagspi_program frame_buffer.bin 0; xc6s_program xc6s.tap; shutdown"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: trst = 7
adapter speed: 200 kHz
Warn : Interface already configured, ignoring
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
xc6s_print_dna
jtagspi_program
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
Info : clock speed 200 kHz
Info : JTAG tap: xc6s.tap tap/device found: 0x24001093 (mfg: 0x049 (Xilinx), part: 0x4001, ver: 0x2)
loaded file bscan_spi_xc6slx9.bit to pld device 0 in 3s 2009us
Info : JTAG tap: xc6s.tap tap/device found: 0x24001093 (mfg: 0x049 (Xilinx), part: 0x4001, ver: 0x2)
Info : Found flash device 'win w25q32fv' (ID 0x001640ef)
flash 'jtagspi' found at 0x00000000
auto erase enabled
Info : Found flash device 'win w25q32fv' (ID 0x001640ef)
Info : Found flash device 'win w25q32fv' (ID 0x001640ef)
Info : Found flash device 'win w25q32fv' (ID 0x001640ef)
Info : sector 0 took 862 ms
Info : sector 1 took 108 ms
Info : sector 2 took 108 ms
Info : sector 3 took 128 ms
Info : sector 4 took 120 ms
Info : sector 5 took 106 ms
wrote 393216 bytes from file frame_buffer.bin in 117.956841s (3.255 KiB/s)
Info : Found flash device 'win w25q32fv' (ID 0x001640ef)
read 340604 bytes from file frame_buffer.bin and flash bank 0 at offset 0x00000000 in 8.422829s (39.490 KiB/s)
contents differ
diff 0 address 0x00000100. Was 0xff instead of 0x00
.
.
.
diff 127 address 0x0000017f. Was 0xff instead of 0x00


I saw a thread somewhere that the new Pi4B GPIO lines have configurable Pull Ups. I need to research this and determine if this might be causing SPI transfer issues. I think this boils down to something being different on the Pi4B BCM2711 architecture and the Pi1B.

Any help would be most appreciated.

cyberbarter
Last edited by cyberbarter on Mon Sep 27, 2021 7:15 pm, edited 5 times in total.
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

cyberbarter wrote:
Mon Sep 27, 2021 6:18 pm
Any help would be most appreciated.
I made a couple of comments in this section about the Pi4:
https://github.com/hoglet67/Beeb1MHzBus ... -pi-models

Did you modify these lines in raspberrypi-native.cfg?

Code: Select all

bcm2835gpio_peripheral_base 0xFE000000
bcm2835gpio_speed_coeffs 236181 60
I haven't tried using a Pi4 myself.

Dave
cyberbarter
Posts: 10
Joined: Wed Aug 18, 2021 7:42 pm
Contact:

Re: ICE T65/Z80/6809

Post by cyberbarter »

hoglet wrote:
Mon Sep 27, 2021 6:45 pm
cyberbarter wrote:
Mon Sep 27, 2021 6:18 pm
Any help would be most appreciated.
I made a couple of comments in this section about the Pi4:
https://github.com/hoglet67/Beeb1MHzBus ... -pi-models

Did you modify these lines in raspberrypi-native.cfg?

Code: Select all

bcm2835gpio_peripheral_base 0xFE000000
bcm2835gpio_speed_coeffs 236181 60
I haven't tried using a Pi4 myself.

Dave
I did make those changes and I updated my post to include that bit of missing information. Thanks for the catch. Would it be helpful if I ran this issue by the OpenOCD forums?
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

cyberbarter wrote:
Mon Sep 27, 2021 6:57 pm
I did make those changes and I updated my post to include that bit of missing information. Thanks for the catch. Would it be helpful if I ran this issue by the OpenOCD forums?
Yes, I expect they would be better qualified over there to advise you.

I'm very much a novice user of OpenOCD!
cyberbarter
Posts: 10
Joined: Wed Aug 18, 2021 7:42 pm
Contact:

Re: ICE T65/Z80/6809

Post by cyberbarter »

hoglet wrote:
Mon Sep 27, 2021 7:00 pm
cyberbarter wrote:
Mon Sep 27, 2021 6:57 pm
I did make those changes and I updated my post to include that bit of missing information. Thanks for the catch. Would it be helpful if I ran this issue by the OpenOCD forums?
Yes, I expect they would be better qualified over there to advise you.

I'm very much a novice user of OpenOCD!
Hi Dave. I am in the same boat. This is my first exposer to OpenOCD. I will post an update if and when the OpenOCD forums help with a fix. As always, thanks for your assistance.
cyberbarter
Posts: 10
Joined: Wed Aug 18, 2021 7:42 pm
Contact:

Re: ICE T65/Z80/6809

Post by cyberbarter »

cyberbarter wrote:
Mon Sep 27, 2021 7:17 pm
hoglet wrote:
Mon Sep 27, 2021 7:00 pm
cyberbarter wrote:
Mon Sep 27, 2021 6:57 pm
I did make those changes and I updated my post to include that bit of missing information. Thanks for the catch. Would it be helpful if I ran this issue by the OpenOCD forums?
Yes, I expect they would be better qualified over there to advise you.

I'm very much a novice user of OpenOCD!
Hi Dave. I am in the same boat. This is my first exposer to OpenOCD. I will post a update if and when the OpenOCD forums help with a fix. As always, thanks for your assistance.
I did get a Pi1B AND Pi4B to program the EEPIZZA using OoenOCD with the ice6502.bin and ice6502.bit files.
Both of the Pi1B and Pi4B are running the same OS and OpenOCD.
OpenOCD = 0.10.0-5
PiOS = 32bit version 2020-02-13-raspibian-buster-full

The OpenOCD forums and Google searches turned up nothing.

I decided to scope the JTAG pins. I found that the Pi1B TCK was running at ~250 Khz as configured in local.cfg
adapter driver bcm2835gpio
bcm2835gpio_trst_num 7
adapter speed 250
RPi1B TCK.jpg
The Pi4B TCK was running at ~416 Khz with the adapter speed set to 200 in the local.cfg
Pi4B TCK.jpg
I changed the local.cfg adapter speed = 100 on the Pi4B and the EEPIZZA could be flashed consistently without errors although is was slow.
adapter driver bcm2835gpio
bcm2835gpio_trst_num 7
adapter speed 100

I am going to research the /usr/share/openocd/scripts/interface/raspberrypi-native.cfg
file for the Pi4B specifics.
bcm2835gpio_peripheral_base 0xFE000000
bcm2835gpio_speed_coeffs 236181 60

I am going to see if I can find some detail on the speed coeffs definitions as I have a gut feeling that maybe this might be part of the problem.

Also attached is a word doc with some additional information. Please share if you would like.

Thanks for everyone's help on this issue.

Cyberbarter
Attachments
Programming ice6502 on the EEPIZZA FPGA Board using OpenOCD 0.10.0-5 using a Pi4B 32bit OS.docx
(24.89 KiB) Downloaded 16 times
Last edited by cyberbarter on Mon Oct 04, 2021 4:10 pm, edited 1 time in total.
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

Thanks for the update Cyberbarter.

It does look like bcm2835gpio_speed_coeffs values depend on the ARM clock:

Code: Select all

# Transition delay calculation: SPEED_COEFF/khz - SPEED_OFFSET
# These depend on system clock, calibrated for stock 700MHz
# bcm2835gpio_speed SPEED_COEFF SPEED_OFFSET
bcm2835gpio_speed_coeffs 146203 36
There are some more examples here, some determined experimentally:
https://github.com/bunnie/netv2mvp-scri ... de.cfg#L23

Dave
bluearcus
Posts: 10
Joined: Wed Dec 16, 2020 12:06 am
Contact:

Re: ICE T65/Z80/6809 -

Post by bluearcus »

I'm trying to make up an eepizza 6809 level shifter board... but notice that the single line tri-state level shifters in the BOM are OOS everywhere in the UK and have very long lead times...

Can anyone suggest some alternative part options that have stock?

Kind regards,

Mike
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809 -

Post by hoglet »

bluearcus wrote:
Sun Oct 24, 2021 1:40 pm
I'm trying to make up an eepizza 6809 level shifter board... but notice that the single line tri-state level shifters in the BOM are OOS everywhere in the UK and have very long lead times...
Do you mean the SN74LV1T125DBVR parts?

These are actually not critical and can be omitted.

The Wiki says this:
If you struggle to solder fine-pitch parts, the three 74LVT125 devices (U7-9) can be omitted. You will loose two features:
- the external trigger capability (which allows a breakpoint to be qualified by a function of two external signals)
- the TSC capability (a RnW cannot now be tristated).
If you really need those features NOW you could risk ebay; there are some showing there (in China).

I'm not aware of any alternatives with the same pinout and voltage thresholds.

Dave
bluearcus
Posts: 10
Joined: Wed Dec 16, 2020 12:06 am
Contact:

Re: ICE T65/Z80/6809

Post by bluearcus »

Thanks Dave.

I'd recognised that a build without them was possible, but in order not to stretch my limited assembly skills too much, was hoping to be able to source some to ensure a complete build with all the ICs done before headers etc being in the way... ah well. Might try China as you suggest.

Kind regards,

Mike
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

I played a little bit with the ICE T65 on my es65 Sever (6502 based - see viewtopic.php?f=45&t=23492&p=340184#p340184) and i have two problems:
  • 1: when i stop the CPU the external Timer generates an Interrupt - i think i can mask this with sp 1 or sp 3
  • 2: the external watchdog generates a RESET which i cannot mask
Is there a way to have an output when the CPU is stopped?
I think i could deactivate the watchdog and the timer and do single step.

best regards, robert
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

robert_o wrote:
Sat Nov 13, 2021 9:00 am
  • 1: when i stop the CPU the external Timer generates an Interrupt - i think i can mask this with sp 1 or sp 3
Yes, that will effectively disconnet the IRQ input from the 6502.
robert_o wrote:
Sat Nov 13, 2021 9:00 am
  • 2: the external watchdog generates a RESET which i cannot mask
There isn't currently a similar way to disconnect reset, though it may be possible to add this if you are really stuck.
robert_o wrote:
Sat Nov 13, 2021 9:00 am
Is there a way to have an output when the CPU is stopped?
I'm not understanding what you mean by output here?

Do you mean a external signal that is high when the CPU is stopped, and low other wise?

Does this signal need to be 5V levels? Possibly we could "borrow" pin 5 of the DIP header (and pervert the use of nML)

Otherwise the signal could be output on the spare 2x6 header on the FPGA board.

What would you do with this output?
robert_o wrote:
Sat Nov 13, 2021 9:00 am
I think i could deactivate the watchdog and the timer and do single step.
If it's possible to do this externally, that might be most expedient for you.

Dave
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

Thank you for your reply,
i thought i could use an output from the FPGA and deactivate the watchdog with this signal. It could be any Level. i would use a simple transistor although 5V would also be nice for an analog switch maybe.
best regards,
robert
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

Just to clarify:
I would need a pin which changes its state when the CPU is halted and reverts back when the CPU is in free running mode.
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

robert_o wrote:
Tue Nov 16, 2021 12:02 pm
Just to clarify:
I would need a pin which changes its state when the CPU is halted and reverts back when the CPU is in free running mode.
Is it not possible to just disable the watchdog circuitry while you debug the board?
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

I could try. With the Interrupt another problem arises.
I need the Interrupt masked THE MOMENT the CPU is halted, not before. Is that possible?
best regards, robert.
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

robert_o wrote:
Wed Nov 17, 2021 7:58 am
I could try.
OK.
robert_o wrote:
Wed Nov 17, 2021 7:58 am
With the Interrupt another problem arises.
I need the Interrupt masked THE MOMENT the CPU is halted, not before. Is that possible?
It would be helpful if you could share a few more details of the problem here, rather than just stating the solution you think you need.

Are you trying to have IRQ disconnect automatically when single-stepping, and have it reconnect automatically when free running (after the continue command)

Single stepping a system that uses timer interrupts is always going to be tricky, because the source of the timer interrupts (e.g. a 6522) doesn'' t stop generating them when the ICE is single stepping. The BBC has this problem.

Generally what you have to do:
- special 1 (to disconnect IRQ)
- reset the system
- Single step/debug the main program as much as you like

When you want to test the interrupt handler you do:
- special 0 (to reconnect IRQ)
- step 1 (so the IRQ is seen by the CPU)
- special 1 (to disconnect IRQ)
- step 1 (to enter the IRQ handler)
- Single step/debug the IRQ handler as much as you like

Are you equippped to rebuild the Xilinx firmware from the github sources?

I'm happy to try making experimental changes for you on a branch in git, but it creates more work if I have to package and upload a binary release each time I do this.

Do you have a machine running Linux to hand?

Dave
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

Are you trying to have IRQ disconnect automatically when single-stepping, and have it reconnect automatically when free running (after the continue command)
Yes that would be most helpful.
Are you equippped to rebuild the Xilinx firmware from the github sources?
yes.
Do you have a machine running Linux to hand?
also yes

The machine i am trying to debug is the es65 development system viewtopic.php?f=45&t=23492&p=341178#p341178. It - like the BBC - also has a 6522 as timer to generate a periodic interrupt (50Hz). Furthermore it has a (discrete external) watchdog. I will work on disabling the watchdog tomorrow. The computer is a multi user system. So each time it restarts you have to logon again which isn't possible without interrupts. Single stepping from reset could work but it would probably take a while. Also it has banked rom so a breakpoint without external trigger (the selected bank) would also not work. Unfortunately RS Components doesn't have the SN74LV1T125DBVR so these are not mounted as of now. I will post tomorrow with more info.
thank you,
robert
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

Thanks for the update Robert.

I would like to try to improve the way the ICE works in the presence of interrupts.

Here's what I have in mind...
- replace the SPECIAL <n> command with seperate IRQ / NMI / RST <n> commands
- <n> = 0 means connected
- <n> = 1 is reserved
- <n> = 2 means connected when free-running, otherwise disconnected
- <n> = 3 means disconnected

Hopefully this won't be too difficult; I'll give it a go tomorrow and report back.

Dave
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

robert_o wrote:
Wed Nov 17, 2021 7:58 am
I could try. With the Interrupt another problem arises.
I need the Interrupt masked THE MOMENT the CPU is halted, not before. Is that possible?
best regards, robert.
I've replaced the rather unfriently special command with a set of "x" commands:

Code: Select all

>> help
ICE-65C02 In-Circuit Emulator version 0.997
Compiled at 15:12:54 on Nov 18 2021
8 watches/breakpoints implemented
Commands:
   blist     
...
   xirq      e|c|d|f
   xnmi      e|c|d|f
   xres      e|c|d|f
   xso       e|c|d|f
There is one command for each of the 6502 core's control inputs (IRQ, NMI, RES and SO).

(On the Z80 and 6809 versions they are renamed appropriately)

The commands take four possible options:
- e = Enabled (the default state - connected to the external signal)
- c = Conditionally enabled (connected to the external signal only when free-running)
- d = Disconnected (connected to a logic 1)
- f = Forced (connected to a logic 0)

Here's some examples:

Code: Select all

>> x
xirq = Enabled
xnmi = Enabled
xres = Enabled
xso  = Enabled
>> xirq c
>> x
xirq = Conditional
xnmi = Enabled
xres = Enabled
xso  = Enabled
>> 
The commands can be abbreviated to the first two letters (e.g. xi, xn, xr, and xs)

In addition, I've routed the internal SS_Single signal to J5 pin 1 on the EEPIZZA board. This signal is high when the ICE is paused or single stepping, and low when free running. Note, this is an 3.3V level signal direct from the FPGA, so be careful. Probably best to connect it via a 1K resistor.

All these changes are now commited to the dev branch:
https://github.com/hoglet67/AtomBusMon/tree/dev

I've tested them a bit on the BBC Micro and they seem to work as expected. But bugs are always possible.

Dave
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

Hi dave,
i need to compile the firmware, right?
I never actually compiled for Xilinx, only Altera. I fought quite a bit to get the Impact-Programmer running on my linux machine. I can give it a try tomorrow.
Robert
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

robert_o wrote:
Fri Nov 19, 2021 6:21 pm
i need to compile the firmware, right?
I never actually compiled for Xilinx, only Altera. I fought quite a bit to get the Impact-Programmer running on my linux machine. I can give it a try tomorrow.
See these two pages:
https://github.com/hoglet67/AtomBusMon/wiki/Toolchain
https://github.com/hoglet67/AtomBusMon/ ... g-firmware

If you have installed the Xilinx tools in the default location (/opt/Xilinx/14.7) everything should just work. If not, you'll need to make sure the tools are on your PATH.

If you get stuck, I can upload a new binary build. It's just if we need to keep iterating on this for some reason (bugs or further enhancements), it's easier if you can run the make files yourself.

Dave
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

I compiled the firmware and uploaded it. Everything worked out fine. I can test it tomorrow.

robert
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

Unfortunately the computer stopped working. I need some time to repair it.
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

robert_o wrote:
Tue Nov 23, 2021 10:50 am
Unfortunately the computer stopped working. I need some time to repair it.
No worries; thanks for keeping us in the loop.
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

I tried the new firmware and it works perfectly now. I can single step without interruption of the timer. I can see however a slight chance for further improvement.
The "n" instruction is great to jump over a "jsr" and it works fine for most cases. My computer (or more the OS) uses the brk opcode extensively, it is called "supervisor call" and it is used for nearly everything from printing a character, checking input, converting time and date,...
It is used with a brk followed by a one byte code (there are nearly 100 different codes). If the computer encounters a brk it generates an interrupt (internally) so the masking doesn't work - which is a good thing. I have to singlestep through the handler though or manually set a breakpoint after two bytes. It would be great if the "m" command could be extended for example "m 2" creates a breakpoint after two bytes while the "m" still behaves the way it is intended.
I can see however that this is a very special request and nearly nobody will need a feature like this. I am very happy the way this ICE works. If i ever get the SN74LV1T125DBV i can even trigger on a specific bank (the computer has banked rom 4x8k from A000).
Thank you for a great and very useful product!
User avatar
hoglet
Posts: 10727
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: ICE T65/Z80/6809

Post by hoglet »

robert_o wrote:
Thu Nov 25, 2021 7:30 pm
The "n" instruction is great to jump over a "jsr" and it works fine for most cases. My computer (or more the OS) uses the brk opcode extensively, it is called "supervisor call" and it is used for nearly everything from printing a character, checking input, converting time and date,...
It is used with a brk followed by a one byte code (there are nearly 100 different codes). If the computer encounters a brk it generates an interrupt (internally) so the masking doesn't work - which is a good thing. I have to singlestep through the handler though or manually set a breakpoint after two bytes. It would be great if the "m" command could be extended for example "m 2" creates a breakpoint after two bytes while the "m" still behaves the way it is intended.
Actually, BRK is normally regarded as a two-byte immediate opcode, so it's reasonable to update the disassembler to treat is as such.

(The next command uses the disassembler to work out where to set the breakpoint)

I've just pushed that change to github (version 0.998), if you would like to test it out.

Dave
robert_o
Posts: 43
Joined: Sun Sep 19, 2021 5:52 pm
Location: Vienna
Contact:

Re: ICE T65/Z80/6809

Post by robert_o »

It works so far! I can step over a brk with "n". I did however encounter some brk codes which are more than one byte. But these are not the norm and not all too often used.
I can say it is a great improvement.
I will test further.
robert.
Post Reply

Return to “acorn atom and acorn system series”