From simple AZERTY Falcon project to custom ARM bus master - advice needed please

[Badwolf]

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!

Goodo.

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

Ah, cool. It wouldn't have crossed my mind that that second reset would be important. I don't even know if the diagnostic cart does that.

Sounds like real progress now, though.

BW

[foft]

Actually I thought today that I did a 2nd change at once (always a bad idea!). I changed the function code from ‘user data’ to ‘supervisor data’. So might also be that.

Also the ‘reset’ instruction is before it starts executing the cart.

[Badwolf]

Actually I thought today that I did a 2nd change at once (always a bad idea!). I changed the function code from ‘user data’ to ‘supervisor data’. So might also be that.

Also the ‘reset’ instruction is before it starts executing the cart.

I know the FC[x] lines are important, but haven't tracked how yet (does anyone know? Could be useful to know what we can get away with when we start tackling PiStorm). On my rev4 board I forgot to connect them up and saw similar problems now you come to mention it.

I then set a series of fixed FC[x] configurations but couldn't get anything to actually run with a fixed configuration. I didn't try them all, just decided to bodge wire it in the end.

If there's a combination (eg. your 'sup data') that works as a lowest common denominator for motherboard access, that could be very handy to know.

BW

[foft]

So, some slow progress...

I finally have some working ram, after buying 5 SIMM sticks!

Now the diagnostic cart no longer sends me RAM instability over the serial port. It no longer sends anything else though! I get some corrupt looking screens where it seems to be stepping through/moving some stuff. Then it turns the screen off, possibly just a resolution my monitor doesn't like.

I didn't yet implement interrupts plumbing, so perhaps that is needed for the diagnostic to work. I was figuring it wasn't since a lack of interrupts would be a fault that I'd expect the diagnostic cart to handle.

Other than that - did anyone disassemble the cart or find the source? That would be super-helpful to see what its up to. I have a trace of instructions run by musashi so can see what is going on.

I should add that I just didn't solder the real new CPU yet since I'm waiting for some solder mask to arrive from China... Wishing I could also test the CPUs without soldering them on, I couldn't find any sockets except super expensive custom test ones.

[mikro]

As for the source code, go to https://docs.dev-docs.org and search for "Falcon030 Production Diagnostic source code v1.21 [Oct 14 1992]"

[Badwolf]

I didn't yet implement interrupts plumbing, so perhaps that is needed for the diagnostic to work. I was figuring it wasn't since a lack of interrupts would be a fault that I'd expect the diagnostic cart to handle.

Hi foft,

Sorry -- I've haven't had both my Falcon and my scope (or logic analyser) in the same place since I promised to have a look at your register's decoding timing. Do you still need to know that?

I'm not sure about which interrupts are needed for the diag cart. I remember in my early days of expansion development SPURIOUS INTERRUPT was an issue I saw a lot if AVEC wasn't properly handled.

I've a sneaking feeling you may need to support the autovectored VBL (and/or) HBL for the diag cart to be completely happy. Does Musashi support AVEC/VPA? I've never managed to get a build working.

The cart shouldn't really be filling the screen with nonsense unless you've run a RAM test, so something's gone awry early on, I'm afraid.

Just to be completely sure: it is the Falcon's diag cart you're using? Screen initialisation gibberish would likely happen with an STE cart, for example.

BW

[foft]

Sorry -- I've haven't had both my Falcon and my scope (or logic analyser) in the same place since I promised to have a look at your register's decoding timing. Do you still need to know that?

I thought this was the root cause of not being able to access ram. With a different function code I can access ram and also that ff8006 register just fine. I am still curious about when its initialized/updated though, so I should take a look at that at some time.

The cart shouldn't really be filling the screen with nonsense unless you've run a RAM test, so something's gone awry early on, I'm afraid.

Uh oh! Hopefully just because I don't have interrupts yet.

As for the source code, go to https://docs.dev-docs.org and search for "Falcon030 Production Diagnostic source code v1.21 [Oct 14 1992]"

Awesome, with this I can at the very least check that I am running the correct diagnostic cart! Serious this is super useful. I have a function and memory access trace from Musashi so it'll be very useful to see where it gets up to.

[foft]

So looked through the trace. It spent half the time looking for a keyboard, then timing out. Then it decided not to jump to 'start' but ran some other code that isn't in the dev docs. It seemed to be copying the cartridge to RAM then executed from there. Which is an odd strategy since it didn't test ram yet as far as I can see!

Though it seems to liberally be doing bsr/rts etc and that is using the stack which is in ram anyway right? Perhaps safe since its cache?

bsr xkeyres
PC:fa048a:bsr $fa04a4
... timeout, no keyboard -> D0=0
...
PC:fa048e:tst.w D0
PC:fa0490:bne $fa0008 -> (don't) jump to start

-> jump to unknown
PC:fa0494:bsr $fa1a9a

Which does a whole bunch of
PC:fa1ade:bcc $fa1ada
PC:fa1ada:move.w (A1)+, (A2)+
PC:fa1adc:cmpa.l A1, A4

Then jumps to the copy
PC:fa0498:jmp ($a,A5)

Which seems to be what happens at the start label.
PC:e000a:move #$2700, SR
PC:e000e:clr.l D0
...

[foft]

Think ram is still not entirely stable, not getting repeatable results. Probably too long wires to the FPGA!

Oh well, should have the remaining parts I need to put back a real CPU after next week...

...
arg:
grep 'l.ffc=' diag2.log
W.l:ffc=fa048a
R.l:ffc=fa048a
W.l:ffc=fa048e
R.l:ffc=fa048e
W.l:ffc=fa0498 - write to ffc
R.l:ffc=fa049a -read from ffc !!

[foft]

So cheating a bit, using ram on my arm device instead of the falcon ram, I start to get a bit more over RS232.

"
Checking FPU...Ok
Initializing PSG...Ok
I6 Checking exception handling...
I7 Bus error not detected
"

Which makes sense since I didn't yet wire up interrupts. So guess I need to do that next.

Also if I plug in the keyboard I see it follow the alternative code path: I see two RESET instructions rather than one. Which I think is a good sign that the keyboard is 'seen' to some degree.