Using the Falcon's expansion connector

[Rustynutt]

nice board, too bad it didn't last long
I too have always bad luck when trying electronics, I almost gave up :/

https://youtu.be/cRedET2Mhrc

[Badwolf]

Might as well drop a quick update here.

This hasn't gone away, I've actually been working on a brand new firmware, investigating an alternative way of handling the clock domain crossing using a faster crystal and dividing down.

The idea is to get the firmware fitting into a smaller CPLD to make the boards cheaper and to make mistakes more palatable.

Slow progress at the moment as seem to be hitting a roadblock when the crystal passes 90MHz (and the CPU therefore passes 45).

BW

[Badwolf]

Afternoon all.

I'm at the point of starting planning a new revision (r4).

That means I've come to the end of the r3 development and have a spare board that I'll no longer need. It's not feature complete because of limitations of this development board design, but it is fully working in the features implemented.

More than one person has (very kindly) offered to donate some money/offer some sponsorship to aid the development of this project which I've always turned down as it's all been one-off unreproducible so far and I don't like to take money for something that might never work.

However I now have a surplus functional piece of hardware and wondered if there would be any interest if I were to put it up for sale as a way of recouping some development costs?

DFB1r3b2 -- David's Falcon Booster 1, development revision 3, board B, firmware version 2. An 'external' 68030 booster for the Falcon's expansion slot.

Features:

• 36MHz CPU clock (225% on stock)
• 32MB TTRAM @18MB/s (300% on ST RAM)
• Switchable on-board replacement fast ROM (reflashable, preprogrammed with EmuTOS for full TTRAM support)
• Optional support for existing (motherboard) FPU with a single fly wire
• Floppy, IDE, Blitter, serial, EtherNEC all tested working (blitter should be disabled when using TTRAM. Either by using EmuTOS or NVDI.)
• Keyboard and case can close with accelerator in place but top shielding should be removed
• Comes assembled with all components apart from the CPU which you should supply. Any full PGA 030 rated 33MHz and above should work.
• Runs in 3 modes controlled by jumpers to which switches could be added: Disabled (on-board CPU in use); Enabled with flash ROM; Enabled with motherboard ROM.
• Verilog firmware source included under GPL
• DFBFlash software & sources included
• No soldering required (just plug it in), unless you wish to fit the FPU flylead

dfb1r3b2_800px.jpg

Limitations of the development version:

• DSP is not enabled. For some reason I couldn't make the DSP work with this board. There's nothing in theory to stop it and the firmware source is included if you want to have a go at getting it to work on your system.
• Because of the debug headers and some injudiciously placed pull-up resistors the board is 2mm too wide to fit with the Falcon's PSU in place. No problem if you have a tower mount or a replacement PSU already, otherwise you may be able to shave it down and relocate the pull-ups.
• This is a unique development board, no further firmware developed will work on it. It will not receive upgrades or support.

The value of the components and the board itself comes to around £75. To cover the cost of some of the components that have failed during development of this board (not to mention the best part of my free time for the last 18 months!), I'd be looking to sell at around £100. I'd ask you to accept all the above provisos, although I will take back & refund a board that doesn't work for you providing it still works for me.

I would probably list this on eBay as spares/repair and state that you're buying second hand components that just happen to be still attached to their board.

If anybody thinks this would be of interest to them at around that price, let me know (privately if you prefer) and I'll record a video showcasing it working and set up an auction.

If there's no interest then I might have a go at hacksawing it myself to see whether I can get it to fit with the PSU in place.

Cheers,

BW.

[frank.lukas]

If nobody else is interested, I could test whether a Nova Falcon works with the card ...

[Badwolf]

If nobody else is interested, I could test whether a Nova Falcon works with the card ...

Hi Frank,

Well I've had absolutely no enquiries, so it doesn't look like there's much of an appetite for it yet!

I'll give it a few more days to let people catch up with the forums, but might as well look at alternatives.

What's the Nova's requirement? Does it need this board to have a passthrough (it's not been built with long leads), or does it have its own passthrough?

BW

[frank.lukas]

I would have to solder pin headers to your accelerator card and the nova would then come on top. No problem ...

Gembench 4.03 is with Magnum Falcon 8MB (6MB) Alternate Ram Card and Nova Falcon.

Falcon_Nova_klein.jpg

magnum+nova_klein.jpg

NOVA_FAL_8bit.gif

[Rustynutt]

I've used the NOVA on a Mighty Sonic with fast ram, no problems at all.
Didn't catch which ram kart David uses, the stock 4mb "can" show VIDEL artifacts, but that's not an issue with the NOVA. Or at stock bus speed.
Maybe David can send a new TOS ROM too allow the wait state removed on the bus.
Use to use ROM speed, but read from Doug Little it's not the best way.
It never bothered me.
Then David's card has a flash ROM too

[Rustynutt]

Yeap,havent found any more deeper stuff myself so why I sort point it out.
And yea to be real top bus master it is CPUBGO/I that needs to be used as far as I gather.ie,,onboard CPU never gets bus mastery
which of course in itself is a rather tricky thing if using onboard 030 for boot(like the CT) and later in boot sequence relinquish system
to new bus master.But there are some upgrades that do just that what you are going for so with upspeed 030 should go fine?
Just loads of timing and such issues to figure out.That is they most likely sit on top of as main CPU from boot,,never letting onboard to even start so to speak.(no need for halt or anything afaik)
[/quote]

Sorry to wean off this thread

Are you sure the CT relies on the main 030 to bootstrap?

Actually, just learned it now has TOS stored in flash, rather then (legally ) load it from ROM.
Can the CT boot without a ROM physically in place, or is there a hardware interconnect issue with that?

Mainly, I'd thought with the Afterburner, wired as bus master, could boot without clock to the CPU, however it doesn't.

It will boot with the CPU physically removed.

Though too, I'd read a few CT owners had their machine repaired by Rodolphe and the 030 smt was removed.

So, how can the CT require the 030 to bootstrap of it's removed? Are we just talking bus stuff here.

Just now this stuff is beginning to make sense

[Badwolf]

Mainly, I'd thought with the Afterburner, wired as bus master, could boot without clock to the CPU, however it doesn't.

It will boot with the CPU physically removed.

Though too, I'd read a few CT owners had their machine repaired by Rodolphe and the 030 smt was removed.

So, how can the CT require the 030 to bootstrap of it's removed? Are we just talking bus stuff here.

Just now this stuff is beginning to make sense

Which CT?

Anyway, a board hanging off the expansion port can work one of two ways, as far as I can tell:

1) Ask for permission to use the bus from a higher device (bus arbitration);
2) Become the highest device by removing the competition (you now have to perform bus arbitration for other devices).

1) needs a working on board CPU, 2) needs it removed.

A board configured for 1) won't work in mode 2) and vice versa unless great lengths have been taken by the designers.

I suspect this is why you're seeing a problem with removing the onboard 030 -- your card is asking for permission from a chip that's not there (or disabled). You may be able to work around this by (for example) shorting the CPU's BG (bus grant) pin to ground. This is the bus arbitration equivalent of a jobbing actor's answerphone message: it says 'I'll do it' before anyone's even asked.

The equivalent pin on the expansion header would be CPUBGI (one of the two that's normally shorted when no expansion is in place). Pulling this to ground might get you started, but whether it's long-term safe depends on the design of the card.

BW

[Badwolf]

If nobody else is interested, I could test whether a Nova Falcon works with the card ...

Hi Frank,

I don't think there's any interest in me selling this at the moment, so how would you look to do this?

I'm in the UK, you're in DE, IIRC. Unfortunately on account of some dreadful government decisions dating back to around 2016, me sending this to you and you sending it back is no longer remotely simple nor inexpensive.

I'd say the monetary value of the card is about €80 and I wouldn't want you to have to pay VAT (and handling!) on that on the way out and then the same on the way back. If I under declare then there's no insurance on loss.

I've had a look at your Nova schematic and to be honest, I can't see that the bus arbitration lines are used at all (you thought they were, I believe). I presume the card is therefore just acting as memory between 0x400000 and 0xe00000?

If so, I think it probably ought to work without modifications.

BW

[frank.lukas]

I would like to donate some money and maybe after the card is finalized I could get one? Send me a PM ...

[Rustynutt]

Mainly, I'd thought with the Afterburner, wired as bus master, could boot without clock to the CPU, however it doesn't.

It will boot with the CPU physically removed.

Though too, I'd read a few CT owners had their machine repaired by Rodolphe and the 030 smt was removed.

So, how can the CT require the 030 to bootstrap of it's removed? Are we just talking bus stuff here.

Just now this stuff is beginning to make sense

Which CT?

Anyway, a board hanging off the expansion port can work one of two ways, as far as I can tell:

1) Ask for permission to use the bus from a higher device (bus arbitration);
2) Become the highest device by removing the competition (you now have to perform bus arbitration for other devices).

1) needs a working on board CPU, 2) needs it removed.

A board configured for 1) won't work in mode 2) and vice versa unless great lengths have been taken by the designers.

I suspect this is why you're seeing a problem with removing the onboard 030 -- your card is asking for permission from a chip that's not there (or disabled). You may be able to work around this by (for example) shorting the CPU's BG (bus grant) pin to ground. This is the bus arbitration equivalent of a jobbing actor's answerphone message: it says 'I'll do it' before anyone's even asked.

The equivalent pin on the expansion header would be CPUBGI (one of the two that's normally shorted when no expansion is in place). Pulling this to ground might get you started, but whether it's long-term safe depends on the design of the card.

BW

Both the Afterburner, and CT60 (according to a user here), when installed "normally" will boot and function without the onboard CPU in place. BG is tied low off one of the Bus Gals on the CT60, as well as the AB just as you say.

While the CT60, as well as your DB board do so much differently than the AB, it can bootstrap the Falcon with it's additional 8 flywire to the bus and no 030.

Maybe that's what neanderthal meant, that with the 030 installed, taking hold of the bus is slightly different than with it removed.

What lead me to query, there is a discussion, in German, from back in the day about the 030 possibly yet toggling some bus lines, even though it's no longer the master, and removing it resolves possible conflicts with an AB installation.

Mine functions fine with the 030 in place, pondering removing it as at 25MHz bus, it gets smoking hot. Pavel suggested removing the clock, which then caused it not to boot.

So something very early on with BG, and how the hardware is brought up before TOS executes between the two situations.

[Badwolf]

Maybe that's what neanderthal meant, that with the 030 installed, taking hold of the bus is slightly different than with it removed.

If the CPU is removed and the board expects it to be removed, you don't need to negotiate at all: you are bus master.

If the CPU is in place and the board expects it to be, the board have to negotiate with it.

If the CPU removed, but the board expects it to be there, you'll need to trick the board into thinking it's negotiating (eg. tie BG [CPUBGI] low).

What lead me to query, there is a discussion, in German, from back in the day about the 030 possibly yet toggling some bus lines, even though it's no longer the master, and removing it resolves possible conflicts with an AB installation.

Providing BGK is held low (nb. NOT BG. Nolding BGK low is what you do after you've received BG), the onboard CPU should keep mum. It thinks DMA is going on.

Although a note of caution: COMBEL gets involved, annoyingly. You can't just assert BGK throughout and ignore the onboard CPU (which according to the data sheet should work). You have to go through the BR/BG/BGK dance.

Mine functions fine with the 030 in place, pondering removing it as at 25MHz bus, it gets smoking hot. Pavel suggested removing the clock, which then caused it not to boot.

So something very early on with BG, and how the hardware is brought up before TOS executes between the two situations.

Tying BG low only works if the onboard CPU is removed.

If the CPU's still there it needs a minimum of about 4MHz to function. It's a dynamic core. Disabling the clock will make things worse as it'll be in an undefined state.

CT2, IIRC, sets the CPU speed to half master clock (as your TOS mod did for the blitter) to mitigate against overheating. That might be an option?

BW

[neanderthal]

Oh,got quoted there,,heh,and a older one at that.
But the topic is interesting,since never actually checked how many cycles the CPU does with the BG-Jumper removed on the expansion.
First DMA access or something?,,have to check next time have the board free.

A couple of things,as noted by BW not having a Clock on the CPU most likely has its internal state machine in odd not known state.
So it could do strange stuff even if not maybe lethal to hardware,like answering to busrequest or something?
After all its a input thats supposed to toggle all the time,left open it could 'selfswing' I quess and set things in odd states.

And the /BR /BGACK /BG is a 3 line dance where some timings are requiered with the /BG being daisy chained..(and as noted again dont ground with CPU in place,its a output)
In theory like the documentation says,,CPU-> expansion -> DMA,,etc
But the physical seems to go CPU-/BG -> U68(GAL) -> Expansion(thru when not using it) -> DMA -> Combel -> Expansion again, lowest prio for dma devices not in a hurry(pin 15 at J16).
Interesting with the GAL there,otherwise can follow the theoretical if thinking about it.
Must be for the HIGHZ signal generation,so the pseudo 68k signals go thri state?

[viking272]

Hi BW, your wiki on this project is very informative and very well written, thanks for taking the time to write it.

[Badwolf]

Hi guys,

The DFB1r4 has gone off for board manufacture today.

I've thrown a lot into this one and gambled on no debug headers but it should fit in the case with the PSU in place.

Fingers crossed this will be the one.

BW

dfb1r4render.jpg

[viking272]

Congratulations Badwolf, loved this project of yours.
Is it just the one or a batch? Is it a few months lead time?

[Badwolf]

Congratulations Badwolf, loved this project of yours.
Is it just the one or a batch? Is it a few months lead time?

Thanks. I've had boards that simply haven't worked at all because of terrible design mistakes. I hope this isn't one of them as it's cost 4x the previous prototypes!

This is the standard, unpopulated, batch of five circuit boards. I have the parts to build one full board and one partial.

If I can get all the basics working with a processor at 40MHz or above and AltRAM clocking at least 15MB/s (300%), I'll publish it all and hope improvements can come from crowdsourcing. The hope is processor at 50, AltRAM beyond 20MB/s, FPU and DSP working -- but I've only had one heavily modded board that made those specs so far.

I might sell spare boards or full boosters I've built up to recoup some of my losses, but not commercially.

Cheers,

BW.

[Badwolf]

A quick update. All the main discussion is over on the Exxos forum, but I know there are one or two people here who are interested.

I had some terrible trouble getting the DSP to work reliably with my board: it was all down to how the Falcon's expansion port doesn't have A0 and derives it from UDS which I was terminating at the 'normal' time. Things work better when it's delayed so A0 is properly asserted when AS goes high.

Anyway, I've mostly been testing since.

Today, six hours of AltRAM-heavy running has been fairly reliable (once it's up it tends to stay up, but there's one or two boot problems occasionally, normally related to the Ethernec variant I have attached).

Here's a couple of pics showing it running and the board itself.

IMG_4880.jpeg

IMG_4882.jpeg

Next up is FPU work.

BW

[Rustynutt]

Excellent progress. Dammitall, bought a 50MHz PGA 882 for this assuming you'd of went that direction Still have plenty of PLCC 40MHz units.

Question on your Exxos patch, did you enable the additional DMA clock delay, and install Exxos's recommended resistor patch?

[alexh]

Nice work. Looking forward to seeing more of your developments

[Badwolf]

Excellent progress. Dammitall, bought a 50MHz PGA 882 for this assuming you'd of went that direction Still have plenty of PLCC 40MHz units.

Haha, sorry. Most of the 40MHz PLCCs overclock nicely so 50MHz isn't a stretch. Bloody thing is *half* working at the moment, though. Draws lovely fractals. Fails all the tests. I think it's bad connections on this shitty socket. I need to reflow it all then rip it off and replace if that doesn't work.

Question on your Exxos patch, did you enable the additional DMA clock delay, and install Exxos's recommended resistor patch?

No, it's as it came out the packet from Exxos. I considered the new 150k pull-down, but I haven't had any DMA issues yet so haven't applied it.

BW

[czietz]

I had some terrible trouble getting the DSP to work reliably with my board: it was all down to how the Falcon's expansion port doesn't have A0 and derives it from UDS which I was terminating at the 'normal' time. Things work better when it's delayed so A0 is properly asserted when AS goes high.

Congratulations on finding this, by the way! This is one of these things that seem crystal-clear in hindsight; but I would not have thought of this. Makes you wonder what Atari was thinking when they gave the expansion connector a "68000-style" bus interface...

[stormy]

Excellent progress. Dammitall, bought a 50MHz PGA 882 for this assuming you'd of went that direction Still have plenty of PLCC 40MHz units.

Haha, sorry. Most of the 40MHz PLCCs overclock nicely so 50MHz isn't a stretch. Bloody thing is *half* working at the moment, though. Draws lovely fractals. Fails all the tests. I think it's bad connections on this shitty socket. I need to reflow it all then rip it off and replace if that doesn't work.

Question on your Exxos patch, did you enable the additional DMA clock delay, and install Exxos's recommended resistor patch?

No, it's as it came out the packet from Exxos. I considered the new 150k pull-down, but I haven't had any DMA issues yet so haven't applied it.

BW

Guys, you're assuming you have to enable the delay, this assumption is incorrect. Exxos clock patches ship with the DMA clock delay enabled by default. You have to physically disable it if you don't want it (It is needed for accelerators, but works fine for stock falcons too, so best left on)

[Rustynutt]

Excellent progress. Dammitall, bought a 50MHz PGA 882 for this assuming you'd of went that direction Still have plenty of PLCC 40MHz units.

Haha, sorry. Most of the 40MHz PLCCs overclock nicely so 50MHz isn't a stretch. Bloody thing is *half* working at the moment, though. Draws lovely fractals. Fails all the tests. I think it's bad connections on this shitty socket. I need to reflow it all then rip it off and replace if that doesn't work.

Question on your Exxos patch, did you enable the additional DMA clock delay, and install Exxos's recommended resistor patch?

No, it's as it came out the packet from Exxos. I considered the new 150k pull-down, but I haven't had any DMA issues yet so haven't applied it.

BW

Guys, you're assuming you have to enable the delay, this assumption is incorrect. Exxos clock patches ship with the DMA clock delay enabled by default. You have to physically disable it if you don't want it (It is needed for accelerators, but works fine for stock falcons too, so best left on)

That seems like a clear answer, but got into a tissy (with all due respect) with Exxos and a forum member asking for clarification of the instructions.

I compared it to "my way of interpretation " and another's way of documenting the install.

What was clear to them, was not to me, and it wasn't worth the effort to continue the discussion.