m68k bus arbitration

[TomS_]

Hi all, looking for any m68k gurus that may be hanging around to help me figure something out.

Im looking at a HP Jet Direct card that has a 68EC000 on it, along with an ethernet controller. The ethernet controller can take over the bus to DMA packets in to/out of memory.

Ive scoped out the arbitration signals, and I feel like Im going crazy.

The datasheet says that BR/ is used to request access to the bus, and the CPU will respond by asserting BG/ once it has given up the bus.

On this board, however, the BR/ signal remains constantly high (yellow trace in the attached image) and it would appear that the BGACK/ signal is asserted in place of BR/.

Does anyone know if this was a valid means of bus arbitration with the 68k? It seems counter to everything that is in the datasheet, unless it has an error and has swapped the BG/ and BGACK/ signals, but then BGACK/ is never being asserted either...

Not 100% sure what to make of it, but there are a few tricks being played on this board so it wouldnt surprise me that they are playing a trick with bus arbitration too...

The sequence of signals are:

HOLD_ is asserted by the ethernet controller (AM79C90), this feeds into an ASIC on the board which would then appear to assert BGACK_ to the CPU which then asserts BG_ back to the ASIC which in turn asserts HLDA_ back to the ethernet controller which is now the bus master.

Appreciate any insight.

Thanks!

[cruff]

From the manual:

3.4 BUS ARBITRATION CONTROL
The bus request, bus grant, and bus grant acknowledge signals form a bus arbitration
circuit to determine which device becomes the bus master device. In the 48-pin version of
the MC68008 and MC68EC000, no pin is available for the bus grant acknowledge signal;
this microprocessor uses a two-wire bus arbitration scheme. All M68000 processors can
use two-wire bus arbitration.

It sounds like you have misidentified the BR ping as BGACK.

[TomS_]

From the manual:

...

It sounds like you have misidentified the BR ping as BGACK.

I am very aware of what the manual/datasheet says, Ive read it several times to ensure that I understand what I am looking at.

Ive triple checked the pins I am probing, and I am absolutely 100% probing the pins as identified in the screenshot and my description above.

The yellow trace is the BR signal. And in fact I have literally just noticed that it is hard wired to the adjacent VCC pin, so there is no way that it can be used to request the bus unless there is an error in the datasheet.

[TomS_]

My apologies. There be errata!! 

I had interpreted the text you quoted to mean there were no BGACK signals on the 48 pin EC device, although there is actually no such thing.

[MK14]

Also, this link seems to say, some of them, had a different pin out, to the datasheet.

https://www.cpu-world.com/CPUs/68000/Motorola-MC68EC000FN10.html

Motorola MC68EC000FN10

10 MHz
68-lead plastic LCC   Motorola MC68EC000FN10
this CPU has a bit odd pinout
2019-08-18 10:34:45
Posted by: Muzamal Baig

The freescale MC68EC000FN10 0F90 has following pinout that does not match the one given in its datasheet
Taken from bboah.com

[cruff]

Good news you found the errata. At work I'm dealing with x86 compatible CPUs with absolutely terrible datasheets, so I can't actually be sure what they implement by reading them and VxWorks has almost nothing in the way of useful informational debug commands. I'm going to have to boot Linux on them to know what is really there.

[DiTBho]

HP Jet Direct card

that looks interesting, can you post a pic of the card? 

[TomS_]

Sure thing

[DiTBho]

wow, neat board, I like it 

[TomS_]

Its a very cool little form factor, and Im using it as inspiration to implement my own board of similar size, but make it more capable.

This board only has 256KB of RAM, and only a single interrupt priority is available because only IPL2 is routed anywhere.

There are also some neat tricks being performed by the ASIC at the bottom. Although there are two ROMs, which you might normally expect in a 68k system, if the CPU requests a word (e.g. an instruction) the ASIC will make two reads from one of the ROMs and latch one of the bytes onto the lower byte of the data bus. So in theory, if your code is small enough, you only need to populate a single ROM on the board.

Same with the RAM, there are only 2x 4 bit wide RAMs, so the ASIC is doing some (de)multiplexing of data.

Im going to try and re-use the single ROM feature, but will put 16 bit wide RAM on the board to reduce some of the complexity.