68030 bootstrapping issue

[Badwolf]

Quick update and a plea for help.

After busy few months I was able to make progress on my Falcon expansion port board again. The CPLD firmware now does initial bus arb properly and the external CPU takes over the very early stages of the boot sequence. I still haven't got it to the point it can initialise the video (ie white screen) when booting from TOS, but I'm making progress using the diagnostic cartridge.

Having traced some initial spurious interrupt issues to a solder dag on the IACK line and blown up another CPLD (yeah, I know), I'm currently facing the following screen:

IMG_3648.jpg

The bus error message is odd -- sure enough my card only sees one bus error in the first couple of seconds whereas without the card there are two -- but the one that I don't get is the address access error. It's always there. It's always that address and program counter. It doesn't appear with the board jumpered disabled (a purely logical setting on the CPLD to bus arb in the opposite direction to shut down the external CPU).

Can anyone think of a fault that would cause that? I can't see how it can be an address or data line short as it gets a good 3 seconds into boot before that error and with all the same physical connections in place, but set to disabled mode, it goes away.

I know I probably need to do work on the interrupts and on releasing control of the bus for DMA and bitter, but I don't think they're require this early in the boot process and can't see how they'd be connected to that error anyway.

Cheers,

BW.

(gratuitous board shot)

IMG_3649.jpg

[terriblefire]

Can you just grab the code out of the TF330 repo? that should do everything you need

https://github.com/terriblefire/tf330

The EXP_BR, EXP_BG pins are the two wire arb pins that need hooked to the Falcon. This is known working with CD32 CD Drive DMA.

EDIT: One thing i noticed is that your clock will be very delayed if your deriving from the System clock. You'll need to use a reconstruction stunt like I did on the TF330.. (well maybe). Is your clock generated from the CPLD? is it free running?

Have you tried DiagROM for the ST? It should work on the falcon.

[Badwolf]

Thanks TF, dropping in the 330 code is an idea. Will have a goosey at that this evening.

The only clock at the moment is the system clock (run through a Schmitt trigger) split to run in parallel to the external CPU and the CPLD. At this stage of boot it's still at 8MHz. I know you had to do some clock jiggery pokery, but I thought that was when you were up at the faster end of things & trying to sync clock domain crossings. Do you think timing will be an issue with this unaccelerated setup down in the weeds?

I didn't realise DiagROM would work on the Falcon! Cool. I had assumed it didn't from your earlier comment. :D I'll try and source a copy. Alas, having just blown a load of wedge on a new laptop to improve the whole working-from-home experience, I don't think the missus would appreciate me gearing up with a rom burning setup too...

I've noticed that access to that address seems to be after about 2.8 seconds, which is roughly when a period of intense interrupt activity starts. Could still have goofed something there, maybe.

:cheers:

BW.

[terriblefire]

Thanks TF, dropping in the 330 code is an idea. Will have a goosey at that this evening.

The only clock at the moment is the system clock (run through a Schmitt trigger) split to run in parallel to the external CPU and the CPLD. At this stage of boot it's still at 8MHz. I know you had to do some clock jiggery pokery, but I thought that was when you were up at the faster end of things & trying to sync clock domain crossings. Do you think timing will be an issue with this unaccelerated setup down in the weeds?

I didn't realise DiagROM would work on the Falcon! Cool. I had assumed it didn't from your earlier comment. :D I'll try and source a copy. Alas, having just blown a load of wedge on a new laptop to improve the whole working-from-home experience, I don't think the missus would appreciate me gearing up with a rom burning setup too...

I've noticed that access to that address seems to be after about 2.8 seconds, which is roughly when a period of intense interrupt activity starts. Could still have goofed something there, maybe.

:cheers:

BW.

Test it out on a falcon emulator first.

I'm unsure why you need to do anything here? The falcon has an 030 bus.. it should work with a straight wire through. My concern is the clock is too late ..

[Badwolf]

I'm unsure why you need to do anything here? The falcon has an 030 bus.. it should work with a straight wire through. My concern is the clock is too late ..

Infuriatingly it doesn't expose an 030 bus, but an emulated 68k bus! There are a few system derived lines missing (AVEC, notably) and a few 030 ones exposed (like FC2:0) but for the most part it's UDS, LDS and a single DTACK rather than the 030 equivalents. It's like reading an instructional manual that's been through google translate to French and back.

The main aim of my project is to add some Alt RAM. Since the upper byte address lines physically aren't connected on the Falcon's mainboard I figured the easiest way to do it was to put a directly equivalent processor in the expansion slot and take over the system. A side project is that a nice ceramic PGA 030 ought to be able to take a few megahertz more whilst I'm at it, but I'm still miles away from that and in the the cursing-Atari-for-not-simply-providing-the-030-pins-and-done-with-it stage.

I'll have think about the clock. I can't immediately see the issue. Ta. :)

BW.

[frank.lukas]

With some CPU Speeder cards the Onboard CPU must be remove. Read that article by use the google translator

-> http://tho-otto.de/hypview/hypview.cgi? ... &index=364

[terriblefire]

I'm unsure why you need to do anything here? The falcon has an 030 bus.. it should work with a straight wire through. My concern is the clock is too late ..

Infuriatingly it doesn't expose an 030 bus, but an emulated 68k bus! There are a few system derived lines missing (AVEC, notably) and a few 030 ones exposed (like FC2:0) but for the most part it's UDS, LDS and a single DTACK rather than the 030 equivalents. It's like reading an instructional manual that's been through google translate to French and back.

The main aim of my project is to add some Alt RAM. Since the upper byte address lines physically aren't connected on the Falcon's mainboard I figured the easiest way to do it was to put a directly equivalent processor in the expansion slot and take over the system. A side project is that a nice ceramic PGA 030 ought to be able to take a few megahertz more whilst I'm at it, but I'm still miles away from that and in the the cursing-Atari-for-not-simply-providing-the-030-pins-and-done-with-it stage.

I'll have think about the clock. I can't immediately see the issue. Ta. :)

BW.

Ok instead look at the TF534 implementation then. The TF330 assumes an 030/020 style bus. has all the arb and i think there is a known working Atari Fork @agranlund

I strongly recommend you change your clock setup though. I had *alot* of issues with clocks on early TF boards and since i moved to the TF330 model they all went away. The issue is your edge will be delayed up to 10ns by the schmitt trigger and it will probably ring. Especially if you have a star clock topology. So your clocks will be all over the place.

[Badwolf]

With some CPU Speeder cards the Onboard CPU must be remove. Read that article by use the google translator

-> http://tho-otto.de/hypview/hypview.cgi? ... &index=364

Hi Frank,

That's interesting, thanks.

They've gone for the 'easy' (if you consider unsoldering your main CPU and hotwiring lines to it's tiny tiny bus as 'easy'!) method of tapping into the real 030 bus beneath the expansion card. I'm hoping to apply modern technology (ie. CPLDs) to avoid having to do that, but it does involve inferring the value of those lines that card is intercepting.

It's also interesting that it mentions the onboard chips still being active on the interrupt lines -- I wonder if that's a conflation of the interrupt and the bus arbitration lines? I made the mistake of thinking HALT was enough to fully deactivate the onboard CPU, but with a bit more reading it was certainly not the case: the symptoms sound like perhaps they made the same mistake.

Anyway, thanks for that but I wouldn't go that far with mangling my Falcon. I've already made a right mess of the FPU footprint!

BW.

[Badwolf]

Ok instead look at the TF534 implementation then. The TF330 assumes an 030/020 style bus. has all the arb and i think there is a known working Atari Fork @agranlund

Alright, grand. Will do. Ta.

I strongly recommend you change your clock setup though. I had *alot* of issues with clocks on early TF boards and since i moved to the TF330 model they all went away. The issue is your edge will be delayed up to 10ns by the schmitt trigger and it will probably ring. Especially if you have a star clock topology. So your clocks will be all over the place.

OK, I see what you mean. I'm part way through a kind of 1.5 revision ATM so I'll put that on hold and have a dig about in your code & video history for the clock chat before carrying on.

I was probably trying to be a bit too clever with the Schmitt trigger. I could likely bypass it safely enough at 8MHz and see if that has any effect.

:cheers:

BW.

[Badwolf]

Slow progress yesterday. I spent a couple of hours reading TF's verilog & thoroughly confusing myself. :lol: Well above my level. Need to git gud.

I tried out the binary images of DiagRom to run as a Falcon on Hatari without luck -- it keeps rejecting them as not Falcon compatible and reverting to an STE. I cheated and simply padded them to 512k, but still it rejected them. Didn't have time to investigate that further. I did try the cartridge version, though. That didn't work, providing some lovely beeping and messed up screen, but then again the Atari test cartridge doesn't boot in Hatari either, so I'm not ruling out that it would on real hardware.

The rest of my evening was thoroughly productive: first I bypassed the Schmitt trigger to check for any variations in behaviour. None found, but I will have to keep in mind the likely delay and ringing issued caused by that sharp edge going forward;

Then I spent an hour with the loupe looking for solder point failures when, after changing some logic analyser probe points, my Falcon started generating a corrupted screen even with the board jumped off. Turns out it was the clock jumper I'd moved to bypass the Schmitt trigger. It wasn't making contact after I replaced it! Works with a Dupont wire, not with the jumper. I now know *exactly* how @GadgetUK164 felt with that A4000...

Tonight: more adventures with AVEC emulation -- I'm pretty sure the error I'm seeing is when the HBLANK interrupt is unmasked and I'm not handling it.

Cheers, everyone!

BW.