68008

[Alan Cox]

This is my first cut at a 68008 CPU card for RC2014/BP80. It's my first playing with M68K designs so I may well have screwed lots of things up.

In theory anyway

- Most of U2 combines the /DS signal with RW to generate Z80 like RD/WR (much like the E clock on the 6502/680x ones)

- U3 pulls VPA low whenever an interrupt acknowledge appears so that the peripherals don't need to do 68K magic. The rest

  of the time it pulls DTACK low as the RC2014 bus means the hardware has to be fast enough

- U4 generates IORQ for supervisor accesses between 64K-128K otherwise MREQ

- U5 generates a bus error on user accesses below 256K

(I need to add a jumper to make this optional or maybe just a pullup so you can omit the IC)

The memory map is intended to work with 'classic' RC2014 cards like 32K ROM/RAM because they will ignore A16+, the flat 512/512 card and anything I knock up specially for it later. Keeping it simple means traps are in ROM but it's easy enough to have a ROM whose trap handlers just JMP to RAM addresses that can be set.

Alan

[Bill Shen]

IORQ generation is good, but to generate valid MREQ, you need to qualify the address with address strobe (AS), another word, MREQ must be negated (high) when AS is high.

You can qualify R/W with DS to generate nWR as you did, but you can't generate nRD this way.  This is because DS lags AS by half a clock for write operation, but DS and AS asserted at the same time for read operation.  This is particularly problematic with CF access because AS is used to generate CF chip select and nRD is used to generate CF read strobe.  The CF spec requires setup time between CF chip select and CF read strobe.  Without the setup time, the CF disk won't operate reliably.  This is a common mistake with CF interface using 680x0.

Who is pulling up RESET?  RESET is a bidirectional signal in 680x0.  The RESET instruction drives RESET low.
  Bill

[Alan Cox]

On Sunday, 16 February 2020 03:15:50 UTC, Bill Shen wrote:

IORQ generation is good, but to generate valid MREQ, you need to qualify the address with address strobe (AS), another word, MREQ must be negated (high) when AS is high.

In the RC2014 case I am not convinced this is the case because  MREQ high with no RD or WR is a valid Z80 bus state (refresh) so all the cards will check RD and/or WR and those are qualified by AS/DS. It's also what the 6502, 6303 and 6809 cards do.

You can qualify R/W with DS to generate nWR as you did, but you can't generate nRD this way.  This is because DS lags AS by half a clock for write operation, but DS and AS asserted at the same time for read operation.  This is particularly problematic with CF access because AS is used to generate CF chip select and nRD is used to generate CF read strobe.  The CF spec requires setup time between CF chip select and CF read strobe.  Without the setup time, the CF disk won't operate reliably.  This is a common mistake with CF interface using 680x0.

Thanks - I had not really thought about that much. It's the same problem I hit with some of the other CPUs as well - the Z80 happens to have a tiny (not 70ns as it should be for PIO0) delay, the others often don't.

So what should happen - clock \RD through something so it changes the rising clock edge after \AS so that \AS is on S3 and \RD is on S4 ? If so should that perhaps be on the CF interface card not on the CPU board ? I'm thinking that this is a CF adapter problem not an RC2014 bus one. Also I'm really short of spare real estate on the RC2014 form-factor PCB ;-)

I didn't plan to try and design a CF adapter but maybe we finally need one that does the right delays, buffers the data signals and so on.

Who is pulling up RESET?  RESET is a bidirectional signal in 680x0.  The RESET instruction drives RESET low.

The reset on the clock card or the backplane. This is a good point however. I don't know how they will react to someone else pulling reset down. I need to check. I think it's OK.

Alan

[Bill Shen]

MREQ high with no RD or WR valid is indeed a valid Z80 state.  I'm worry about MREQ low while addresses are changing.  MREQ should not assert low when Z80 addresses are changing.

\RD can be delayed one clock through a flip flop and negate when \AS negates by connect \AS to preset of the flip flop.  The problem certainly can be corrected on CF card, but I'm worry about other Z80 peripherals also need setup time from MREQ to \RD.  How problematic depends on the specific implementation of peripheral cards.  If MREQ is going through a long chain of decoding logic to generate chip select for the peripheral device while \RD is connected directly to the device, you may have a situation where \RD asserts before CS assert, i.e., negative setup time, which may be bad.
  Bill

[Mark T]

I think MREQ active is only for memory devices, typically not used for peripherals in z80 systems. All memory devices that I know of would ignore RD active until CS is active, as this would support 6800/6502 type memory interface from R/W signal.

Mark

[Bill Shen]

It should work as long as we recognize addresses can change while MREQ is asserted. Ultimately for static random access memory devices, the signal that is critical is /WR and asserted only when all other signals are stable. Also need to watch out for data contention, that multiple devices are not selected.

Bill

[Alan Cox]

On Sunday, 16 February 2020 18:37:02 UTC, Bill Shen wrote:

It should work as long as we recognize addresses can change while MREQ is asserted.  Ultimately for static random access memory devices, the signal that is critical is /WR and asserted only when all other signals are stable.  Also need to watch out for data contention, that multiple devices are not selected.

  Bill

Ok so rev 2. Hopefully nothing else needs adding because there is no room left and the routing around the 68008 is already so tight that I had to put the decoupling capacitor at 45° to make it all fit. It's not helped by the fact that the Motorola 68008 address pin order is the exact reverse of the RC2014/Z80 bus !

Alan

[Tom Szolyga]

Hi Alan,

What design rules are you using for board layout?  At EasyEDA, I use 6 mil traces with 6 mil spaces.  That makes it possible to run two traces between pins on 100 mil spacing.  For power and ground, I use wider traces--10 or 12 or 15 mil.  Last, I use copper fill to make the back side of the board a ground plane.  It takes care of many of the narrow ground traces.   I have not had a board failure using  these rules.

Tom

[Alan Cox]

On Sunday, 16 February 2020 20:09:00 UTC, Tom Szolyga wrote:

Hi Alan,

What design rules are you using for board layout?  At EasyEDA, I use 6 mil traces with 6 mil spaces.  That makes it possible to run two traces between pins on 100 mil spacing.  I have not had a board failure with these rules.

Tom

Kicad defaults. so 0.25mm tracks, 0.6/0.4mm via, 0.2 clearance with 0.35mm track and 0.6mm via for power rails. I might have to try your narrower ones if I want get more in.

Alan

Alan

[Rob Gray]

I'm guessing that's two layers? I stopped using two years ago and went to four, it makes life a LOT easier, mostly because you can have real ground/power planes and don't need any big fat traces for them.