| Author |
Message |
|
|
 Posted: Jun 29, 2012 - 05:28 AM |
|
Joined: Jan 14, 2008
Posts: 1147
Location: San Diego
|
|
Does anyone have any resources like schematics or have knowledge of the z180 and its interrupt zero in mode 2? I'm trying to interface an ARM with a SmartBlock (z180).
I can't get the z180 to respond consistently.
I'm wondering if my latch circuit is correct or if I need to hold the INT0 line low for a certain amount of time or ...
As far as I can tell from the datasheet, when the IOE and M1 lines go low the z180 has responded to the interrupt and grabs the low byte of the interrupt vector from the bus (D0-D7). |
_________________
~~John
TWI C source code
|
| |
|
|
|
|
|
|
Posted: Jun 29, 2012 - 05:44 AM |
|
Joined: Dec 30, 2004
Posts: 8723
Location: Melbourne,Australia
|
|
| This is testing my memory. Without referring to a datasheet, my recollection is that the intack cycle where it reads the vector serves as an acknowlege (intack) so one would have a flip flop set by the interrupt request and reset by intack. It's been some time since I worked with z80/z180. Intack is when M1 and IOR are low which you already derive from your or gate. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 29, 2012 - 07:09 AM |
|
Joined: Dec 30, 2004
Posts: 8723
Location: Melbourne,Australia
|
|
| If the ARM is big enough, you can emulate the z180 at a reasonable speed and bypass the hardware headaches! I've done a bit of migration of z80/z180 apps where the assembler code is undocumented and unstructured enough to make a refactor difficult. So emulation is one way of solving the problem. A 168MHz cortex m4 will emulate a 8mhz z180 easily. You can gain some performance by doing some of the work on the arm side - eg a real time clock. One app had a i2c rtc on the z180 - rather than emulate i2c and the rtc protocol the read and write functions on the z180 side were replaced by instruction traps that would call arm functions to read/write the rtc and populate the results in the emulated regs and ram. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 29, 2012 - 07:40 AM |
|
Joined: Jan 14, 2008
Posts: 1147
Location: San Diego
|
|
|
Kartman wrote:
This is testing my memory. Without referring to a datasheet, my recollection is that the intack cycle where it reads the vector serves as an acknowlege (intack) so one would have a flip flop set by the interrupt request and reset by intack. It's been some time since I worked with z80/z180. Intack is when M1 and IOR are low which you already derive from your or gate.
Thanks, I'll try out the flip flop tomorrow. I couldn't find any info in the datasheets about if the interrupt line should be asserted for any minimum time. |
_________________
~~John
TWI C source code
|
| |
|
|
|
|
|
|
Posted: Jun 29, 2012 - 08:08 AM |
|
Joined: Jan 14, 2008
Posts: 1147
Location: San Diego
|
|
Interfacing the ARM was supposed to be the path of least resistance since the customer is going to need this add-on to the instrument soon. We do plan on using a cortex-m3/m4 to replace the z180 eventually. My boss is starting to port over the z180 code but he didn't think it could be done soon enough for this project.
I don't believe my boss used that much asm in the z180 code so refactoring and porting shouldn't be that difficult. |
_________________
~~John
TWI C source code
Last edited by atomicdog on Jun 29, 2012 - 10:00 AM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Jun 29, 2012 - 09:18 AM |
|
Joined: Nov 09, 2011
Posts: 395
|
|
|
atomicdog wrote:
I can't get the z180 to respond consistently.
I'm wondering if my latch circuit is correct or if I need to hold the INT0 line low for a certain amount of time or ...
Well, that's a blast from the (long) past.
The external interrupt lines are sampled only at certain points in the machine cycle ("at the falling edge of the clock state prior to T3 or T1 in the last machine cycle" says the manual). If your interrupt isn't held low for long enough, the CPU could miss it.
So, as Kartman says, you really need to latch the interrupt request until there's an explicit acknowledgement. Note that there are two ways of doing this - either use the interrupt acknowledgement cycle (M1 and IORQ low), or your interrupt source can continue to hold INT0 low until software has serviced the interrupt source - pretty much like any standard level triggered interrupt source.
- S |
|
|
| |
|
|
|
|
|
|
Posted: Jun 29, 2012 - 09:24 AM |
|
Joined: Jul 18, 2005
Posts: 62220
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
OT: little known fact but because the Sinclair Spectrum mapped ROM to 0 it usually ran in IM1 with a RST 38h being performed when an interrupt occurred. Games running on the machine wanted to take control of the vectors but could not hook into RST 38h. So they switched to IM2 and loaded I with the base address of one of the last pages in the ROM which happened to be full of 0xFF (empty). This meant that the vector then went to 0xFFFF where the developer could catch the interrupt.
Then some idiot (no names, no pack drill) developed the Sinclair +2A/+3 which actually had four 16K ROM sections and needed a place in th eoriginal 48K mode ROM top put some additional ROM bank switching code. Spotting a page of 0xFF in the ROM it looked like the perfect place to put the new code so I (ahem, he) put it there..
When the machine went to market a load of old 48K Spectrum games would not work any more because the random value on the bus when the IM" interrupt occurred meant it could use any entry in the vector page and sometimes it hit non 0xFF and went to the wrong place. Sadly the new machines got a reputation for not being compatible any more.
The perpetrator shall remain nameless  |
_________________
|
| |
|
|
|
|
|
|
Posted: Jun 29, 2012 - 10:11 AM |
|
Joined: Jan 14, 2008
Posts: 1147
Location: San Diego
|
|
|
mnehpets wrote:
Well, that's a blast from the (long) past.
Yeah, and my company is still using it in our main product
mnehpets wrote:
The external interrupt lines are sampled only at certain points in the machine cycle ("at the falling edge of the clock state prior to T3 or T1 in the last machine cycle" says the manual). If your interrupt isn't held low for long enough, the CPU could miss it.
That makes sense and seems to match my experience. Didn't even think about checking how often the INT pin is sampled...Hindsight is 20-20
Thanks. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
