exxos's Atari, Amiga & retro forum

Hi,

I'm new to Exxos. I posted a quick intro here: https://exxosforum.co.uk/forum/viewtopic.php?f=14&t=5280

I bought myself a project Falcon a few months ago on ebay. I knew it was broken and thought I'd have a go at fixing it. So far progress is middling. I have had a number of breakthroughs but I could use more experienced opinions and info from electronically minded users who can test on a real Falcon.

So, firstly a summary of what happened so far:
* Case smashed in shipping. Fixed, reasonably well, with Acetone.
* Opened up, clearly contains an upgrade - CenTurbo 1 Evolution 3b. Changes all the clocks.
* PSU tested ok on scope with load resistors from Exxos store.
* PSU recapped using kit from Exxos store (Which was perfect, except it was missing one resistor!). PSU still tests ok after!
* RAM module was installed off by one, so moved that to the right place!
* Replaced a broken switch on the CenTurbo 1
* 4 pins were missing on VIDEL. 3 appear NC. The 4th is Ext clock in. I soldered this on to the remaining metal stub.
* Powered on. No CPU clock. I was pleased, since this should be an easy fix! I traced it to a bad GAL16V8 on CenTurbo 1 evolution 3b, clock goes in, does not come out.
* Reprogrammed/replaced GAL. Clock now present and switching works. Was confused at it being 8MHz for a while until I realised the Falcon powers on like that! Machine does not boot though or output anything with diagnostic cart.
* Got CPU on logic analyser using EXT pins. Did not do anything after coming out of reset. No attempted start to a bus cycle (I think, now I wonder - read on).
* Tried to reflow the CPU in case it was a connection issue. Did a TERRIBLE job. I thought it was simple, go round it and heat each pin. I had the iron by accident on lead free temps and lifted some pads. I think just unused ones fortunately.
* Bought equipment to replace CPU (not arrived yet). New 68030FE33, replacement copper pads, uv curable solder mask and uv lamp. Oh and fitted my USB microscope to a boom arm so I can see chips away from the edge of the PCB!
* Desoldered CPU with preheater and hot air at 280degrees. No further damage.

So, given that I had a non-functional falcon with no CPU, that set of expansion pins kept staring at me. I happened to have a bunch of FPGA equipment and boards from my previous projects. So I decided to wire up the SOCkit as a bus master. The SOCkit is a development board that has a Cyclone V SOC chip on it. This is an FPGA with a hard dual core ARM cpu which allows easy mapping of custom logic in the arm memory map. It also has ~100 io pins broken out. So I wired it up to the Falcon expansion, via some 3.3v quickswitch boards.

I then wrote some glue logic to convert from the arm (well really avalon slave) to 68k. This works now (I had to replace GAL U63 first - to fix DTACK!), I can read the ROM and it matches vs one I downloaded. However I can't read/write to ram. If I write then RXW is low, but WE never goes low. When reading the bus is not driven by the ram. I need to check if CAS is low or not.

Anyway I then thought that perhaps the memory needs to be enabled, as of course there are these half moon wait state settings and 2 bits on the ram expansion board. These are all mapped into a register FF8006, which has its own enable signal from COMBEL. However I'm not sure how COMBEL knows the settings! Does the CPU read it and COMBEL snoops? Or does the CPU read it then write it to somewhere in COMBEL? I've failed to find any decent documentation on this. ff8001 appears unused on the falcon. ff8006 is as far as I can tell read only. I can't find any registers to set to store the wait states etc, except in the non-existent falcon 040. I believe the 030 is more like the Sparrow than that.

So I tried to read from FF8006 and do not see the chip select for FF8006 go low at all (pin 43 COMBEL or pin1 on the 74244). Then it reads 0xffff. Now I'm wondering ... is COMBEL most likely broken?

I could try to replace COMBEL with my hot air/preheater. Though I'd like to do some more checks that this is actually what is broken first. Also perhaps I can try addressing some other devices on the board - PSG, DSP, VIDEL etc.

So... looking for advice really on where would be a good place to go next with this one.

Also while posting is there a trick used to easily attach a logic analyser to these fine pitch SMD chips? Working on the 8-bits I'm spoilt with these large through hole chips. I even got a clip so I just get nice pin headers for them all.

Added a small pic (yeah I know its a mess!)

I have a feeling that @Badwolf will be the most valuable person to give you advice in this field, since he has been working directly with the Falcon expansion interface on his accelerator project. Maybe he will have some ideas for you :D

But I am worried that you've perhaps got 'too much going on' at once, I mean, you're diagnosing a Falcon without a CPU using this interface that you're not 100% about, so how can you be sure that the results you obtain will be correct?

Hi foft. Was following your Facebook post & thanks for the background.

First up, I don't know when COMBEL probes for the memory, but I guess it must be early on as it's the DRAM controller and would need to time its refreshes appropriately, I'd imagine. During or immediately after reset being the obvious.

I will try to have a probe of the R8006 line on my board when I get a chance.

But your test rig confuses me. I can see you're probing/driving the top end of the memory connector, but without any memory in place, I'm not sure what you're expecting to happen here.

Does anything behave differently if you actually populate the memory?

BW

Steve wrote: 29 Mar 2022 12:20 I have a feeling that @Badwolf will be the most valuable person to give you advice in this field, since he has been working directly with the Falcon expansion interface on his accelerator project. Maybe he will have some ideas for you :D

But I am worried that you've perhaps got 'too much going on' at once, I mean, you're diagnosing a Falcon without a CPU using this interface that you're not 100% about, so how can you be sure that the results you obtain will be correct?

@foft I kind of agree with Steve here, I know you are a highly experienced electronics engineer, but sometimes un-complicating things is the way to go, so for example, go back to stock and diagnose the base machine. Up to you of course :)

With regards to the diag cart, you mentioned no output. Was that on screen? Did you try hooking up a terminal to the serial port?

Firstly many thanks for all the replies. I would have replied straight away but I've been out for two evenings.

@Steve
Re: 'too much going on'. Yes I agree, not knowing if my bus master is correct adds another variable. However I do have much more control of this than the soldered on cpu. I'm not trying to emulate a 68k too, just making 68k bus master accesses by accessing a memory mapped region from the arm (in linux).

I did finally receive a replacement 68030FE yesterday (unfortunately with a few bent pins - gah!) though I'm waiting until I get the uv solder mask so I can try to fix the missing pads first.

@Badwolf
For probing R8006, its easiest to take from pin1 of U42. I've tried it with and without memory populated and noticed no difference. I removed the memory in order to attach my logic analyzer to the memory connector, to see what was reaching that 2nd bus. I wasn't seeing WE even when doing writes. I thought this was possibly because the ram wasn't attached thus the size lines were not correct. Then I started looking into the schematic to see how the half moon settings and the size lines were connected, which of course are by this register at FF8006. Those its not evident how the settings get from there to the COMBEL. I was thinking the 68k would read FF8006 then write to the MCU config regs - but there do no seem to be any!

@rubber_jonnie
I wouldn't say I'm a highly experience electronics engineer. I did a microelectronics degree then worked in software for a few decades. This is just hobby stuff and I have a lot more to learn.

Regarding the diagnostic cart I was using the serial port. Though since the CPU didn't seem to do any proper bus master cycles after coming out of reset its not surprising that it didn't do much :-) I'm pretty sure it didn't even assert AS. I guess the broken GAL wouldn't have impacted the cycle since U63 generates XDTACK, but isn't involved in DSACK I think - maybe. I should double check that.


I'll double check my timings of 68k write cycles again on my bus master. I know the read ones work since I can read the TOS rom ok. So I'm curious if R8006 should drive low on every read of FF8006 - or just the first one.

Apologies if I'm off track, but have you told combel that you want to use the bus? I don't think it'll let you do much until you do. I'm not sure where it is on the expansion connector but you can access it from pin 4 of u68. It'll be in the schematics

foft wrote: 30 Mar 2022 21:58 For probing R8006, its easiest to take from pin1 of U42.
...
I was thinking the 68k would read FF8006 then write to the MCU config regs - but there do no seem to be any!

Will see what I can see next time the lid's off.

I would think it needs to be established long before that, TBH.

sety wrote: 31 Mar 2022 05:20 Apologies if I'm off track, but have you told combel that you want to use the bus? I don't think it'll let you do much until you do.

This is cruical, actually, and I didn't think to dig any deeper since you said you were in bus master mode (which I took to mean had perform bus arbitration sucessfully). The problem is, with no CPU in place, I don't know what successfull bus arbitration looks like!

BG comes from the CPU, but it's not there. COMBEL won't let you do much on the expansion port until you've asserted mastery. Also the FC[x] lines play a part as I found to my cost when I omitted them from my revision four expansion board!

It could be as simple as asserting BGK, although I couldn't make this work. I have seen accelerators that remove the onboard CPU tie the CPU's BG pad to ground. Doing that should let you perform full bus arbitration:

* Assert BR, see BG asserted (always is), assert BGK. This is likely enough to convince COMBEL you're genuine. Accessing certain ranges may require proper FC[x] emulation too.

I would do all this with memory in place and worry about the whys and wherefores once you've been able to talk to it!

BW

Yep yep! I picked on pin 4 u68 because it's right next to the tinned chassis rail that runs around the board. You can just solder a jumper wire to tie it low and you have bus arbitration for testing, etc.

It's not a permanent solution as the expansion port was never intended to have a single master. It was meant to be shared with whatever other cool stuff people can make.

foft wrote: 28 Mar 2022 19:43 I could try to replace COMBEL with my hot air/preheater. Though I'd like to do some more checks that this is actually what is broken first. Also perhaps I can try addressing some other devices on the board - PSG, DSP, VIDEL etc.

Please don't do this. Combel can be a bit of a mystery, but I have never even heard about one failing in routine operation. They're pretty robust. If you do, use ChipQuik. It's a 7 layer board that's almost 30 years old. :shock: Also, there are only two sources for Falcon ASICs in the world and both of them are quite eccentric.

Come to think of it, next month should be the Falcon's 30th birthday. I'll ask Phil (former Australian Atari dealer) about this. :)

Badwolf wrote: 31 Mar 2022 11:14 This is cruical, actually, and I didn't think to dig any deeper since you said you were in bus master mode (which I took to mean had perform bus arbitration sucessfully). The problem is, with no CPU in place, I don't know what successfull bus arbitration looks like!

BG comes from the CPU, but it's not there. COMBEL won't let you do much on the expansion port until you've asserted mastery. Also the FC[x] lines play a part as I found to my cost when I omitted them from my revision four expansion board!

It could be as simple as asserting BGK, although I couldn't make this work. I have seen accelerators that remove the onboard CPU tie the CPU's BG pad to ground. Doing that should let you perform full bus arbitration:

* Assert BR, see BG asserted (always is), assert BGK. This is likely enough to convince COMBEL you're genuine. Accessing certain ranges may require proper FC[x] emulation too.

I would do all this with memory in place and worry about the whys and wherefores once you've been able to talk to it!

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).
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.

My handling of BG is as follows:
a) expansion connector: CPUBGO and CPUBGI wired together
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).

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.

I need to check the schematic here - clearly ROM reads are working, though perhaps that is just direct decoding to ROM rather than an enable from COMBEL. Also if BG is direct from the expansion to COMBEL or via U68 etc.