search

hoglet67 / AtomBusMon

This project is an open-source In-Circuit Emulator for the 6502, 65C02, Z80, 6809 and 6809E 8-bit processors. See:
https://github.com/hoglet67/AtomBusMon/wiki
GNU General Public License v3.0
99 stars 21 forks source link

ICE-Z80 and the Micro-Professor MPF-1 #4

Closed AFA58 closed 4 years ago

AFA58 commented 5 years ago

Maybe I look wring,but I can not find an index of wikipages that are here. I am going to build a ICE-Z80 with a 500. What I found until now is: https://github.com/hoglet67/AtomBusMon/wiki HOME https://github.com/hoglet67/AtomBusMon/wiki/Compiling-firmware https://github.com/hoglet67/AtomBusMon/wiki/Firmware-Overview https://github.com/hoglet67/AtomBusMon/wiki/Toolchain https://github.com/hoglet67/AtomBusMon/wiki/ICE-T80 Is there more available?

And something else: I like the adapter board that joeyoravec made, see page 21 of stardot.org. Tobe able to contact him, you need to register as a member on stardot.org. The registration has to be approved. I guess there is nobody homeanymore because the registrattion does not proceed, so I can not contact joeyoravec. Any suggestion on this? His adapterboard looks cool

hoglet67 commented 5 years ago

There are 19 pages on the Wiki; all can be seen in the sidebar on the right of the Wiki.

Are you not seeing this navigation aid?

hoglet67 commented 5 years ago

What user name did you register under - I'll get it approved for you.

AFA58 commented 5 years ago

Hi David,

Name is AFA58. Now I see i was using IE. When I use opera I see the sidebar with the content.

I could not understand why I did not see, I guess IE messes it up. (Need it for work though, so what can you do)

Thanks!

Ton

On 2019-04-02 22:14, David Banks wrote:

What user name did you register under - I'll get it approved for you.

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links:

[1] https://github.com/hoglet67/AtomBusMon/issues/4#issuecomment-479180105 [2] https://github.com/notifications/unsubscribe-auth/AEXiv_5rOQ1U-VnkN9VZCBf7Wj3hnJKDks5vc7oPgaJpZM4cY_c0

AFA58 commented 5 years ago

Hi David,

According to the wiki pages you install Xilinx ISE 14.7 on Ubuntu 14.04.

When I do that the USB cable can not work because the windrv6 is not installed.

Checking Google gives many pages but no solution, I knowafter three/four hours.

How didyou get the USB Cable to work in this set up?

Regards, Ton

On 2019-04-02 22:14, David Banks wrote:

What user name did you register under - I'll get it approved for you.

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links:

[1] https://github.com/hoglet67/AtomBusMon/issues/4#issuecomment-479180105 [2] https://github.com/notifications/unsubscribe-auth/AEXiv_5rOQ1U-VnkN9VZCBf7Wj3hnJKDks5vc7oPgaJpZM4cY_c0

hoglet67 commented 5 years ago

You need to compile and install a third-party USB cable driver (called "libusb-driver")

There are lots of instructions for this on the web, but they do var depending on the exact version of Ubuntu that you are using, and whether it's 32-bit or 64-bit.

Try this one: https://www.george-smart.co.uk/fpga/xilinx_jtag_linux/#Using_Xilinx_USB_JTAG_Programmers_under_Linux_.28Installing_Cable_Drivers.29

or this one: https://wiki.archlinux.org/index.php/Xilinx_ISE_WebPACK#Xilinx_Platform_Cable_USB-JTAG_Drivers

I haven't tested either of these recently.

AFA58 commented 5 years ago

The first link worked like a charm, I am able to use the cable now. Thanks!

First I programmed the 500-GODIL with blank.mcs and after that with avrz80cpu.mcs. When I power up the GODIL I receive the startup message on the serial port, free running CPU, and I can get a working prompt.

I made a adapter PCB so the two 50P female connectors on the bottom of the GODIL are connected to a 40P DIP socket. (Aligned by the VCC and GND pins, leaving the top 3 and bottom 2 pinrows of the 50P empty)

I expect the thing to run then. For testing I use a Micro Professor, which is a very basic Z80 system, 1,7Mhz, no buffering of Address or Databus, other than 10K pull-ups on the databus.

But it does not run. The MPF does not start up and I do not see any activity on any pin. When I do a memdump I only see 00 everywhere.

Am I missing something? Is programming with avrz80cpu.mcs all I have to do, or is there more?

hoglet67 commented 5 years ago

Programming with avrz80cpu.mcs is all you should need to do.

When you do a memory dump at location 0 I would expect you would see the ROM.

So something is not right.

In the serial console, can you do the following:

and post a log of the full session.

Do you have access to an oscilloscope?

AFA58 commented 5 years ago

I think I know what is wrong: I expected that the dip40 would follow the pinning of the two 50P connectors.

That leaves 3 empty pins on the top free and two on the bottom.

BUT.. on the schematics, now I see that C13 is connected to pin49, and D13 is connected to pin50. (C13 and D13 being pins on the two 50P female connectors.

That means that the Pin1 to 10 of the z80, and also pin 31 to 40 are wired wrong, they should go to one pin higher of the 50P headers. (C13 and D13 should have been left unconnected). Weird why pin49 and pin50 are put inbetween on the D50 connectors, but not on the DIL40. I should have seen it on the schematics though... But in dutch it is "in hindsight you look the cow in its ass".

Anyway, two options: Solder a new adapter PCB. (but more difficult because of the 1 pin offset on the top-half) Or changing the pinning of the emulated Z80 to include the pin49 and pin50. And rebuild etc. (Need to read into that, whether that is easy)

hoglet67 commented 5 years ago

The symptoms you reported were consistent with the core not receiving a clock.

Changing the pinout in the .ucf file to mach your adaptor should be possible.

Just edit the LOC= values in this file: https://github.com/hoglet67/AtomBusMon/blob/master/target/godil_500/icez80/board.ucf

hoglet67 commented 5 years ago

Table 6 in the GODIL manual details the pin assignments. https://www.trenz-electronic.de/fileadmin/docs/OHO-Elektronik/TE0261-GODIL/archive/UM_GODIL-v090.pdf#page=21

You''ll just need be very careful and methodical.

hoglet67 commented 5 years ago

Any luck with getting this working yet AFA58?

AFA58 commented 5 years ago

Biggest hurdle was to get the wife off the PC that I installed the virtual Ubuntu. I first had issues with libstdc++.so.6 but solved them. Then had an issue with Data2mem, solved that too. Tried to get it to work using pin 49 and 50, but they are the wrong type of pin, so the build failed. Then connected the pins that were on 49 and 50 to the pins that are on the third row from above. (I do not have the exact data here now) So I had to solder a bit, but not too difficult. Built, flashed and into the Micro Professor and I got the UPF-1 startup display! It is still a bit unstable, but from previous measuremenrs with the scope I know the databus looks horrible. I did not have the time yet to connect a terminal to the serial port while in the Micro professor, but that will come. So good progress, and getting there.

AFA58 commented 5 years ago

2019-04-22 21 15 32

Something is going right :-) When I have a command prompt the keyboard and display scanning stops and I have these results. When I "c"ontinue the display starts acting weird and the program loses track..

hoglet67 commented 5 years ago

That's good progress.

Does it run reliably in free-running mode?

What happens if you try the following:

<press enter to get to command prompt>
trace 1
reset
regs
step 100
regs
trace 0
step 10000000
AFA58 commented 5 years ago

trace 1 Tracing every 1 instructions while single stepping reset Resetting CPU 00.000003: 0000 : LD B,$00 regs Z80 Registers: AF=FFFF BC=0008 DE=E062 HL=1FE6 'AF=FFFF 'BC=6906 'DE=F9C2 'HL=05E6 IX=1F01 IY=18CD PC=0000 SP=FFFF I=00 R=00 IFF=00 Status: SZIH-P-C step 300 Stepping 300 instructions ### Did 300 because of the DJNZ at 0002 00.000010: 0002 : DJNZ $0002 00.000023: 0002 : DJNZ $0002 00.000036: 0002 : DJNZ $0002 00.000049: 0002 : DJNZ $0002 00.000062: 0002 : DJNZ $0002 +Took some out here 00.003325: 0002 : DJNZ $0002 00.003333: 0004 : LD A,$90 00.003340: 0006 : OUT ($03),A 00.003351: 0008 : LD A,$C0 00.003358: 000A : OUT ($02),A 00.003369: 000C : LD SP,$1FAF ++ Here NMI kicks in. there is a circuit that generates NMI's every 5 MI's,controlled by in IO line. ++ I guess that does something 00.003382: 0066 : LD ($1FE7),A 00.003395: 0069 : LD A,$90 00.003402: 006B : OUT ($03),A 00.003413: 006D : LD A,$C0 00.003420: 006F : OUT ($02),A 00.003431: 0071 : LD A,($1FE7) 00.003444: 0066 : LD ($1FE7),A 00.003457: 0069 : LD A,$90 00.003464: 006B : OUT ($03),A 00.003475: 006D : LD A,$C0 00.003482: 006F : OUT ($02),A 00.003493: 0071 : LD A,($1FE7) 00.003506: 0066 : LD ($1FE7),A 00.003519: 0069 : LD A,$90 00.003526: 006B : OUT ($03),A 00.003537: 006D : LD A,$C0 00.003544: 006F : OUT ($02),A 00.003555: 0071 : LD A,($1FE7) 00.003568: 0066 : LD ($1FE7),A 00.003581: 0069 : LD A,$90 00.003588: 006B : OUT ($03),A 00.003599: 006D : LD A,$C0 00.003606: 006F : OUT ($02),A 00.003617: 0071 : LD A,($1FE7) 00.003630: 0066 : LD ($1FE7),A 00.003643: 0069 : LD A,$90 00.003650: 006B : OUT ($03),A 00.003661: 006D : LD A,$C0 00.003668: 006F : OUT ($02),A 00.003679: 0071 : LD A,($1FE7) 00.003692: 0066 : LD ($1FE7),A 00.003705: 0069 : LD A,$90 00.003712: 006B : OUT ($03),A 00.003723: 006D : LD A,$C0 00.003730: 006F : OUT ($02),A 00.003741: 0071 : LD A,($1FE7) 00.003754: 0066 : LD ($1FE7),A 00.003767: 0069 : LD A,$90 00.003774: 006B : OUT ($03),A regs Z80 Registers: AF=90FF BC=0008 DE=E062 HL=1FE6 'AF=FFFF 'BC=6906 'DE=F9C2 'HL=05E6 IX=1F01 IY=18CD PC=006B SP=FFF1 I=00 R=2C IFF=00 Status: SZIH-P-C trace 0 Tracing disabled step 1000000 Stepping 1000000 instructions # did some less no change 12.028907: 0637 : DJNZ $0637 ++ 0637 is right in the middle of the display scan routine

hoglet67 commented 5 years ago

Something is definitely going wrong early in the reset sequence. It looks like for some reason the NMI handler is being called re-entrantly, which will end up overflowing the stack.

On a power-on reset, would you expect any NMIs to be generated?

I'm not familiar with the MicroProfessor, but it seems NMI is used by the monitor to support:

It might be worth checking the level on the 8255 PC6 output, before and after the instruction at 000A is executed.

Do you know of a MicroProfessor clone or replica? I would need to get hold of some hardware myself to try to better understand why this is failing.

Dave

hoglet67 commented 5 years ago

I've been thinking about this issue some more.

The sequence in the trace you reported that's concerning me is:

00.003333: 0004 : LD A,$90
00.003340: 0006 : OUT ($03),A
00.003351: 0008 : LD A,$C0
00.003358: 000A : OUT ($02),A
00.003369: 000C : LD SP,$1FAF
<NMI happens here>

The instruction at 000A should set PC6 to 1, holding the 74LS90 counter in reset, and disabling the NMI function. Instead, it looks like the earlier OUT ($03),A instruction is releasing the 74LS90 counter, but the NMI happens only 4 instructions later. It seems the OUT ($02),A is not having an effect, or is not having time to have an effect.

What I suspect is happening is there is a bug in the ICE Z80 in the way that M1 is generated when single stepping, that results in multiple transitions on M1. This would cause the NMI to happen earlier than expected when single stepping.

Looking at the VHDL, I can see one possibility for how this might happen, if the Z80 core happens to be stopped on a T state where M1 is low.

I'll see if I can replicate this behaviour locally.

In the mean time, there are a couple more simple experiments you could try that will help support the above hypothesis:

  1. Does it run normally from power up (if you do nothing in the ICE Z80 command line)?

  2. Does it run normally if you do the following:

    <press return to enter interactive mode>
reset
c

  3. What do you see if you do the following:

    <press return to enter interactive mode>
reset
watch 0066
c

    (i.e. do you see any NMIs happening)

  4. Can you set a breakpoint after the code to disable the BREAK function, and then single step without NMIs happening:

    <press return to enter interactive mode>
reset
watch 0066
break 000f
c
<hopefully a ICT Z80 will happen>
s 100

    Many thanks for feeding back this issue. We'll definitely get to the bottom of it one way or another.

Dave

hoglet67 commented 5 years ago

Incidentally, there is a nice description of how the NMI system in the MPF-1 works here: http://www.math-cs.gordon.edu/courses/cs222/lectures/MPFI-lab-intro.html (search for NMI:)

AFA58 commented 5 years ago

Hi Dave,

From your questions, number 1: No it does not run normally, it is unstable.

To avoid the NMI problem, I (temporarily) cut the trace of the BREAK, so PC6 is not in control anymore. I checked with the Z80 in place and have a normal operating MPF except for the STEP key.

When I step with 100 or 200 or so steps while in the display loop, I can see the digits one by one light up. When I press a key,(which are read by the same loop) the speaker burps for a while (the beep is spoiled by the stepping) and then basically things get lost. Sometimes the message Err-SP appears, sometimes just spurious data on the display. I do not think RAM data is well read/written. But I did not have time to investigate more tonight.

I do not know of a clone. I bought mine on ebay. There is a french guy who has (had?) some.

hoglet67 commented 5 years ago

The general instability is not good news, and is a bit unusual. In one of your earlier posts I think I saw you run a RAM test, and there were failures. That's probably worth further investigation.

Can you repeat the RAM test, say 10 times, and post the results.

With the ICE Z80 running, is the 5V rail good, i.e. close to 5V with minimal noise?

Dave

AFA58 commented 5 years ago

Hi Dave,

Progress.. There are two static rams in my board. On the location 1800-1fff there was a AM9128-20, and on the 2000-27ff expansion area there was an MSM5128-15. I took out the -20 and put the -15 in the 1800-1fff socket because there is the stack. Now it is much more stable. On the normal clockspeed I can operate the MPF with some problems:

The MPF that I bought has a hardware modification built in where the clockspeed can be divided by 4. So instead of the 1.79MHZ it will be 1.79/4 = 447Khz In that mode the MPF works ok. (But too slow scanning and beep)

So there seems to be an issue with ram-timing. I noticed in the schematics that the RAM is wired without RD. Would that cause this behaviour?

Regards, Ton noread

hoglet67 commented 5 years ago

It's possible this instability is related to OE being tied low. In this configuration, bus conflicts can arise in the periods either side of the write pulse: image With OE held low, the RAM and the Z80 will both be driving the bus at the same time.

The period after the write is less of an issue, as both should be driving the same value. But before the write is more of a problem, because the values could differ.

During these conflicts, quite large currents can flow. The FPGA design (in the .ucf file) deliberately limits the drive to 8mA per I/O. But that's more to prevent damage than to guarantee correct operation.

I'm not really an expert on Z80 designs, but I would have expected OE to be connected to the Z80 nRD signal. But possibly this would need faster RAM.

AFA58 commented 5 years ago

Ok, a quick test (bending out of socket pin 20, wiring it to RD) with the slow RAM IC did not give a better result. Did not want to do that with the -15, I wil find a way to test with that one without bending.

hoglet67 commented 4 years ago

@AFA58

Sorry it has been a long time, but I now have a Micro Professor MPF-1B.

  1. RAM Instability

The RAM fitted is a Sharp LH-5116-15. I also tried a Hitachi HM6116LP-3 (150ns) and a Mostek MK4118A-4 (250ns). All worked perfectly and I was able to run the RAM test program 10 times without any failures.

However, my MPF 1B was manufactured in 1989, and the schematic is slightly different to the one you posted above. It seems to match the one in this scan of the manual: http://www.1000bit.it/support/manuali/multitech/MPF-I-User's-manual.pdf

Most notable, OE on the RAM is connected to CE.

As a test, I bent out pin 20 (OE) of the LH-5116-15 and connected it to 0V, replicating I think how the memory is wired on your board. With that change in place, I do see a memory test failure:

>> test 1800 1fff
Memory test: Fixed 55: passed
Memory test: Fixed AA: passed
Memory test: Fixed FF: passed
Memory test: Fixed 00: passed
Memory test: Checkerboard: passed
Memory test: Inverse checkerboard: passed
Memory test: Address pattern: passed
Fail at 1DDE (Wrote: FF, Read back 00)
Memory test: Inverse address pattern: failed: 1 errors
Memory test: Random: passed
Memory test: Random: passed
Memory test: Random: passed

I also tried this same change with the HM6116LP-3, but did nor see any memory failures.

The fact that Multitech updated the design does suggest there were issues with the earlier version with certain RAM devices.

  1. Single Stepping bug

Earlier in the issue I suggested a possible cause for this:

What I suspect is happening is there is a bug in the ICE Z80 in the way that M1 is generated when single stepping, that results in multiple transitions on M1. This would cause the NMI to happen earlier than expected when single stepping.

Looking at the VHDL, I can see one possibility for how this might happen, if the Z80 core happens to be stopped on a T state where M1 is low.

I verfied that this is indeed the case. The version of ICE-Z80 you are have uses WAIT internally to pause the Z80 in M1/T2. In this state M1, is low. When the ICE makes memory accesses during single stepping, these to end up raising and lowering M1. This is why NMI on the MPF-1 is being triggered early.

There is a new version of ICE-Z80 in the dev branch that addresses this issue, and also addesses many other problems. In particular, it stops the Z80 in M1/T3 when M1 is high. So there are no extra M1 transitions when single stepping.

With this version, single stetting (on the ICE) no longer crashes when the single step function (on the MPF) is used.

13.430491: 02DC : OUT  ($02),A
13.430503: 02DE : LD   A,($1FBD)
13.430517: 02E1 : JP   $1FEB
13.430528: 1FEB : DI   
13.430533: 1FEC : RET  
13.430544: 1800 : LD   A,$05
13.430552: 1802 : LD   B,$04
13.430564: 0066 : LD   ($1FE7),A
13.430578: 0069 : LD   A,$90
13.430586: 006B : OUT  ($03),A
13.430598: 006D : LD   A,$C0
13.430606: 006F : OUT  ($02),A

Although it appeats that two user instructions are executed before the NMI kicks in, that's not actually the case. In the above example, 1802 : LD B,$04 is not actually executed (it's replaced by the NMI entry sequence). Unfortunately, it's not easy for the monitor to detect this case.

I've also been working on a new hardware platform to replace the obsolete GODIL, using a cheap XC6SLX9 board and an active level shifter design: https://github.com/hoglet67/AtomBusMon/wiki/Z80-CPU-Adapter

So far this has been tested on the following systems:

You can also build the version for the GODIL-500.

Unfortunately, due to the latest version of the T80 core being 10% larger, it no longer fits in GODIL-250. I'll be getting a GODIL-500 tomorrow, so should be able to confirm that it works in the MPF as well.

Dave

hoglet67 commented 4 years ago

NMI cycles are logged now, so it's a bit clearer what's going on:

>> br 1feb
Ex Brkpt set at 1FEB
>> d 1800
1800 : LD   A,$05
1802 : LD   B,$04
1804 : ADD  A,B
1805 : LD   ($1830),A
1808 : HALT 
1809 : RST  7
180A : RST  7
180B : RST  7
180C : RST  7
180D : RST  7
>> c
CPU free running...
Ex Brkpt hit at 1FEB
Interrupted
04.012903: 1FEB : DI   
>> s8
Stepping 8 instructions
04.012908: 1FEC : RET  
04.012919: 1800 : LD   A,$05
04.012927: 1802 : **NMI**
04.012939: 0066 : LD   ($1FE7),A
04.012953: 0069 : LD   A,$90
04.012961: 006B : OUT  ($03),A
04.012973: 006D : LD   A,$C0
04.012981: 006F : OUT  ($02),A
>> c
CPU free running...
Ex Brkpt hit at 1FEB
Interrupted
09.417163: 1FEB : DI   
>> s8
Stepping 8 instructions
09.417168: 1FEC : RET  
09.417179: 1802 : LD   B,$04
09.417187: 1804 : **NMI**
09.417199: 0066 : LD   ($1FE7),A
09.417213: 0069 : LD   A,$90
09.417221: 006B : OUT  ($03),A
09.417233: 006D : LD   A,$C0
09.417241: 006F : OUT  ($02),A

INT cycles are also logged

>> br 1800
Ex Brkpt set at 1800
>> d 1800
1800 : EI   
1801 : NOP  
1802 : JP   $1801
1805 : RST  7
1806 : RST  7
1807 : RST  7
1808 : RST  7
1809 : RST  7
180A : RST  7
180B : RST  7
>> c
CPU free running...
Ex Brkpt hit at 1800
Interrupted
00.278795: 1800 : EI   
>> s 16
Stepping 16 instructions
00.278800: 1801 : NOP  
00.278805: 1802 : JP   $1801
00.278816: 1801 : NOP  
00.278821: 1802 : JP   $1801
00.278832: 1801 : NOP  
00.278837: 1802 : JP   $1801
00.278848: 1801 : NOP  
00.278853: 1802 : JP   $1801
00.278866: 1801 : **INT**
00.278878: 0038 : PUSH HL
00.278890: 0039 : LD   HL,($1FEE)
00.278907: 003C : EX   HL,(SP)
00.278927: 003D : RET  
00.278938: 0066 : LD   ($1FE7),A
00.278952: 0069 : LD   A,$90
00.278960: 006B : OUT  ($03),A
hoglet67 commented 4 years ago

Just to clarify something I said eariler regarding updated MPF-1 schematic in this version of the manual: http://www.1000bit.it/support/manuali/multitech/MPF-I-User's-manual.pdf

Looking at the schematic, pin 20 (OE) appears twice on U8:

Measuring the actual board, pin 20 is connected to the Z80 RD signal.

This make sense, as otherwise there will be brief periods of bus conflict around writes.

Dave