68030 bootstrapping issue

[Badwolf]

Hi guys,

I'm quite a new member here, but am trying to build some hardware for my Falcon and hope you guys will be the best people to ask for tips.

I'm making a little board for the Falcon -- plugging into the expansion headers -- which carries a PGA 030 chip. On the face of it, this doesn't do much, but the exercise is to build some expertise that will let me later open up the top address bus byte and do a bit of work with the clock.

The present configuration is a 1:1 mapping of the A1-A23 pins and the D0-D15 pins of the expansion header going to D16-D31 of the 030. The control lines are routed via a CPLD. All this is using the onboard Falcon clock, albeit buffered with a Schmitt trigger to avoid overloading it and provide a clean edge. The onboard CPU is deactivate by asserting /XHALT.

The expansion connector is a bit strange in that it presents a 68000-style interface and some control lines aren't present (AVEC, for example). I figured this would be a problem with interrupts down the line, but I've fallen right at the first hurdle: I can't get the damned chip to boostrap itself reading the SSP and PC from ROM.

Monitoring the lines I can see the bus cycles start, reading from 000000, 000002 (the SSP with a 16 bit port) then 000004 and 000006 (the PC). I can see the data lines return what I'd expect to see (the first eight bytes of ROM).

The next bus cycle, however, where I'd expect it to read from E00030 (ie, what it's just read out for the PC), instead reads from 400010. Gibberish. A few dozen cycles continue before the nonsense finally overtakes it and it stops.

The method of failure is consistent. It always requests the same 'wrong' PC on cycle 5 and things always proceed in the same way thereafter. This makes me think it's something systematic rather than a loose connection or marginal voltage.

I'm obviously doing something very wrong here. I'm hoping it might be blindingly obvious to someone and you can put me out of my misery.

Have I read the documents correctly? Is the behaviour I'm anticipating what should be happening? Is there something subtle in the derivation of DSACKx (which is 1:0 a couple of clock cycles after /DS is asserted) that I'm missing?

Any thoughts appreciated.

Cheers,

BW.

[exxos]

The expansion connector is a bit strange in that it presents a 68000-style interface and some control lines aren't present (AVEC, for example).

I don't know much about the 030 or falcon expansion, but you would need to wire all CPU pins from the new CPU to old one before you even try to boot up. I don't know how easy that would be. Also don't forget some lines are bi-directional so you may not be able to simply buffer them. Though AFAIK only rodolphe czuba has built any sort of accelerator for the Falcon. @terriblefire has worked on the 030 here, but I don't think he has even looked at a falcon.

[terriblefire]

The expansion connector is a bit strange in that it presents a 68000-style interface and some control lines aren't present (AVEC, for example).

I don't know much about the 030 or falcon expansion, but you would need to wire all CPU pins from the new CPU to old one before you even try to boot up. I don't know how easy that would be. Also don't forget some lines are bi-directional so you may not be able to simply buffer them. Though AFAIK only rodolphe czuba has built any sort of accelerator for the Falcon. @terriblefire has worked on the 030 here, but I don't think he has even looked at a falcon.

I have done lots of 030... I've owned a falcon but sold it before doing anything with it.

Not sure if falcon uses autovectors (unlikely but possible). I'd expect AVEC to be tied high or low safely enough (CD32 has it hard wired to low). But if the system vectors interrupts its probably not used and set high.

The falcon only has a 16 bit data bus from memory so you'll only have those.

Maybe we need a falcon diagrom...

EDIT: Also verify /XHALT is correct and check the onboard CPU isnt getting hot. In my experience you need to hold 020/030's with BR/BGACK.

[Badwolf]

Thanks for the reply, guys.

The arrangement is actually inspired by @terriblefire 's early boards -- using a CPLD to gatekeeper the control lines through to the Falcon (buffer was the wrong word). The 16 data lines are basically wired directly to the upper 16 on the 030 and the address lines are wired straight through. Most of the other lines go via the CPLD. I don't have a schematic picture to hand, but I can attach one later, to give you an idea what I'm doing.

Annoyingly the Falcon actually presents an emulated 68000 bus on the expansion headers rather than give access to the lines connecting to the onboard 030, meaning I have to go through a lot of the conversions Stephen did in the 53x series, only to have the Falcon convert them back again.

It does use autovector for the HBL and VBL, I believe. Fortunately I'm some way off needing to worry about that as this fails simply reading the initial program counter, even through I can see the data lines are showing the correct values.

f030acc1_nonsense.png (61.94 KiB) Viewed 5990 times

Any ideas what would cause an 030 to latch xx 40 00 10 when presented with 00 E0 00 30? I'm thinking perhaps it's a marginal physical issue and I ought to wire up another board. That said, when measuring the data lines in the unpopulated socket and letting the onboard CPU run, I get the correct values above. So I'm stumped.

Cheers,

BW.

[Badwolf]

EDIT: Also verify /XHALT is correct and check the onboard CPU isnt getting hot. In my experience you need to hold 020/030's with BR/BGACK.

Ah! That's an idea.

/XHALT is held low (and measured low) when the card's enabled, but perhaps that doesn't do what I think it does.

I'm a bit hazy on how the CPUBGI and CPUBGO (sometimes called XCPUBG and XEXPBG -- the two pins that are normally jumpered on an unexpanded Falcon) are supposed to be used, so that may be worth more investigation.

Aha again:-

When the processor completes a bus cycle with the HALT signal asserted,
the data bus is placed in the high-impedance state, and bus control signals
are driven inactive (not high-impedance state); the address, function code,
size, and read/write signals remain in the same state The halt operation has
no effect on bus arbitration (refer to 7.7 BUS ARBITRATION). When bus
arbitration occurs while the MC68030 is halted, the address and control signals are also placed in the high-impedance state.

That's as close to a smoking gun as I've seen! I've screwed the pooch by taking a shortcut, I reckon.

I appreciate the help, guys! Will try a new firmware spin.

BW.

[exxos]

Could you disable 030 with RESET signal ?

But as TF suggests, I think the "normal" method is to request the bus from the 030 and just never release it as the new 030 will take over as the main bus master. I assume thats how the CT60 does it.

[Badwolf]

Could you disable 030 with RESET signal ?

But as TF suggests, I think the "normal" method is to request the bus from the 030 and just never release it as the new 030 will take over as the main bus master. I assume thats how the CT60 does it.

I think the reset on the expansion header (/XRESET) is actually the system reset line, so no.

You and he are right and I've been bit cavalier with my application of /XHALT. Time to Git Gud with the mysterious CPUBGI and BGO lines.

[rpineau]

The CT60/63 uses the bus grant signals as well as the halt signal.
The reason for the use of the bus grant signals use is that when the DMA request the bus the "new" CPU has to release the bus and at that point this invalidate the halt state of the on board 68030, so the new CPU (actually the CPLD) need to retake the bus from the onboard 68030 once the DMA is done and release the bus (this is from the top of my head from a conversation I had with Rodolphe a few years ago).

[Badwolf]

The CT60/63 uses the bus grant signals as well as the halt signal.
The reason for the use of the bus grant signals use is that when the DMA request the bus the "new" CPU has to release the bus and at that point this invalidate the halt state of the on board 68030, so the new CPU (actually the CPLD) need to retake the bus from the onboard 68030 once the DMA is done and release the bus (this is from the top of my head from a conversation I had with Rodolphe a few years ago).

Hi @rpineau ,

Thanks for this -- this is exactly what I was thinking about last night.

I don't think releasing the bus invalidates /HALT, but since /HALT doesn't actually affect the bus arb lines it would be handing the bus back to the onboard CPU when DMA finishs.

I think what I probably ought to do is /HALT both CPUs when relinquishing my hold of the bus (so the two CPUs don't fight) until I can reclaim it after DMA.

busarbstate.png (44.41 KiB) Viewed 5913 times

Annoyingly, from the state diagram, holding /BGACK and /HALT would be sufficient to shut down the onboard CPU for good, but whilst I've a dedicated /BG line (CPUBGI), /BGACK is shared with the whole system, so repeated arbitration will be necessary.

Even more annoyingly, because I had missed this subtlety in the design phase, /BGACK is the only arbitration line I have routed directly from the expansion headers to the external CPU with only a tap to the CPLD to monitor it. I'm going to have to get the bodge wire out!

Cheers,

BW.

[Badwolf]

Hi guys,

Quick follow up to let you know the state of play, since you've been so helpful:

Holding /BGACK via the expansion header seems to have improved things -- or at least postponed the failure mode!

The first couple of dozen bus cycles now act exactly as the onboard one does, but how long bus activity continues for is now a variable. It can run for around a second at worst and ten or more seconds at best, although in that case, /RESET gets asserted every couple of seconds so something is awry and it never seems to get to the point of receiving a bus request. I conclude therefore it's losing its way before it can initialise any on board chips properly.

I think my next line of investigation has to be the interrupts. To my surprise the IPL lines (2:0) seem to start up with a non-zero interrupt level and I'm not sure at what point that's meant to be serviced.

I've just ordered an Exxos diag cartridge (since my home-made one seems to have its own issues and I only want to work on one problem at a time!), hopefully that will simplify startup a bit.

Fun and games!

Cheers,

BW.