exxos's Atari, Amiga & retro forum

So I checked the schematic:
XROM2 from COMBEL -> OE on EPROM.
Expansion BG (pin 15) is XCMBLBG0 which is directly wired to pin 115 of COMBEL.
XBK and XBR are also directly wired from expansion to COMBEL.

I need to look at U68 equations too ... though one for this evening!

foft wrote: 31 Mar 2022 14:47 Now this is interesting. My understanding of BR, BG and BGK is:
i) BG driven by the CPU.
ii) BR and BGK driven by the system logic (e.g. combel).

Correct BG is daisychained (serial) through all possible bus masters but starts at the CPU.

BR and BGK are shared (parallel) amongst all possible bus masters and is only driven low by open drain pins on each, being pulled high.

The CPU 'owns' the bus and clients need to request it. They do this by asserting BR, the CPU then 'pretty soon' asserts BG. In the the client acknowledges this by asserting BGK. It then uses the bus until its done then de-asserts BGK. The CPU then takes back over.

Again, correct. Even though your CPU is not there, it's still the ultimate bus master and sits at the top of the BG chain.

My handling of BG is as follows:
a) expansion connector: CPUBGO and CPUBGI wired together

That's fine if you're taking your grant from the other (low priority) BG line (XBG).

b) BG driven by bus master always. When BR requested I go through the process above - at the end of state S7 (or when idle).

What do you mean by this? Only the absolute top dog bus master drives the top of the BG chain. In this case the missing CPU. Everything below cascasdes down (like your shorted BGI/BGO lines).

If you're pulling the expansion port's XBG line low, you're driving an input and possibly shorting the next chip up the chain (in this case Blitter -- ie. COMBEL).

Though this is interesting. I had two failed GALs (power spike?) so perhaps I have more and BG on the expansion doesn't make it through U68 to the COMBEL.

COMBEL drives XBG on the expansion port (blitter BG out, expansion [low priority] BG in).

I've recently written some words on this topic: https://github.com/dh219/DFB/wiki/Bus-a ... on-and-DMA

BW

foft wrote: 31 Mar 2022 14:47 a) expansion connector: CPUBGO and CPUBGI wired together

Oof! That sounds like the infamous W11 jumper. Leave it open if you want to talk to Combel. :)

sety wrote: 31 Mar 2022 15:30 Oof! That sounds like the infamous W11 jumper. Leave it open if you want to talk to Combel. :)

I leave it closed on my board and use XBG instead. I found it simpler if you're not concerned about being bottom of the chain -- only one line to deal with.

BW

Thanks, I'm trying to be top dog, as per the original CPU. So I'm definitely using the wrong pin.

I don't think I ever see BR go low, so I'm fortunately not driving COMBEL pin 115 output low (I hope...).

So I wonder if with no CPU there is low or floating on pin 124, hence it doesn't know the CPU has the bus.

Wow, 7 layer board! I thought it was 2 layer, or possible 2 layer + ground plane. Did anyone make a replacement PCB yet or put the schematics in kicad or eagle?

Ok, I see the chain!

XBG030: 68030 pin 16 -> U68 pin 4
XCPUBG: U68 pin 12 -> EXPB pin 22
XEXPBG: EXPB pin 20 -> DMA pin 41
XSDMABG: DMA pin 43 -> CMBL pin 124
XCMBLBGO: CMBL pin -> EXP pin 15

So yeah, now I see!

foft wrote: 31 Mar 2022 18:24 Ok, I see the chain!

XBG030: 68030 pin 16 -> U68 pin 4
XCPUBG: U68 pin 12 -> EXPB pin 22
XEXPBG: EXPB pin 20 -> DMA pin 41
XSDMABG: DMA pin 43 -> CMBL pin 124
XCMBLBGO: CMBL pin -> EXP pin 15

So yeah, now I see!

Cool.

Now, the thing is you cannot be the top dog on the expansion port. You're not sharing the same lines the CPU has. You're using the translated 68k-style expansion interface so you must request permission from the (non-existent) CPU so the GALs are switched into expansion mode and UDS/LDS switch from outputs to inputs.

So, ground the 68030's pin 16 (or U68 pin 4, if it's a direct shot) and request the bus nicely. ;)

BW

OK, we signs the first signs of life! :D

I implemented 'chain style' bus grant in the fpga instead of trying to present to be the master CPU. I also grounded pin 4 of U68 since I have no FPGA. Without this I indeed never get a grant!

Unfortunately, while of course better, that didn't allow me to access ram or FF8006. :(

I then checked to see if I could access other things. I could indeed access the diag cart rom as well as tos rom.

I then read through the service manual looking for inspiration. I saw that one of the first instructions executed on the 68030 is RESET. This does a long 512 clock period reset pulse. I implemented this and then ... I seem to be able to read and write memory. Also FF8006 is read. :D

So I built musashi to try to execute the diagnostic card. On VGA I get a corrupted screen. On RS232 I'm getting some output:
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111101100000000 00000A
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111011100000000 00000E
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016
I2 RAM disturbance 0000000000000000 1111111100000000 000016

Now I thought RAM read/write was working so not sure why it says ram disturbance. Though I should see what that means in the manual and also write my own memory test code...

Should EDO ram be ok?

I think my original SIMM is iffy. I replaced it and the replacement (EDO stick) also fails - but with a much clearer pattern.

This is with a simple ram test I wrote that literally writes 1MB then reads it back to check.

A better RAM check is to write the address into the memory locations and then read that back. In that way you can often pick up address errors.