Using the Falcon's expansion connector

[Badwolf]

Hi guys,

I've been thinking of experimenting a bit with the Falcon's internal expansion connector.

To start with I'd like to try to hanging a PGA 030 chip off it and have it take over bus mastery of the Falcon, disabling the onboard 030. Similar to how the CT60 simply plugs in, but without (for now) offering any acceleration, processor upgrade or memory expansion. Just to walk before I can run, IYSWIM.

This isn't quite as straightforward as I thought it should be as the external connectors don't expose the lines that go into the onboard chip, but instead present more like a 68k control bus. I've had a dig around the net for documentation on the expansion bus, but only really found the service manual and schematic that describe the bus pins, but don't really offer much insight in how to use them.

To that, end before I go through the trial-end-error phase, would anyone be able to offer me any tips on:-

* Is what I propose possible without cutting traces or adding patch wires to the main board (it would seem so to me, given CT60 can do it)?
* Can everything the external 030 chip needs be inferred from the lines that are present on the expansion bus, or will some systems become inaccessible?
* Do I disable the onboard 030 merely by asserting /XHALT, or is this what the CPUBGI and CPUBGO lines are for? I can find no documentation for their use.

The lines I think I need to emulate/infer would be:-

* /DSACK1 and /DSACK0 from /EDTACK and the value of A0 and SIZ[01]?
* /UDS and /LDS from A0 & SIZ[01]?
* /AVEC -- this one had me scratching my head, but AFAICT only Hsync and Vsync interrupts need AVEC on the Falcon and they're the only interrupts at their particular priorities, so this should be synthesisable from the IPL[02] lines. Is this fair?
* BMODE should, I think, be held low for an 030, but since I'm kind-of-sort-of emulating a 68000 interface, I'm not sure.
* Almost certainly others that I've forgotten.

Do I have a reasonable grasp of the requirements or have I missed something fatal?

I'd appreciate any input before I spend many nights staring at a blank screen in a hopeless cause!

Cheers,

BW.

[neanderthal]

Well,,you can check out the Falcon030 dev doc pdf from 1993 to begin with, page 34 about the internal expansion port if not done so already.
Around at https://docs.dev-docs.org/
Has some essential stuff about it there.
Czubas old CT site has some interesting timing diagrams and some stuff aswell.
http://powerphenix.com/index.html

And yes,the falcon systembus(I tend to call it that) is pretty much a 68k bus with some extras and restrictions.
So need to emulate it with what ever bus master you gonna use.I myself used it for my rather odd ISA bus design so never gotten into the bus mastering thing.It's a 'Slave' device with some adress encoding and interrupt.
However if one wants to use the EINT1/3, those are a bit odd since Falcon Rom:s are coded so that CPU Ipl:s upto 3 when booted.Remember that took me a while to figure out how it worked.

And yeah, if you want to build a proper mCpu style bus master for it there is quite a lot to read up on.

[Badwolf]

Well,,you can check out the Falcon030 dev doc pdf from 1993 to begin with, page 34 about the internal expansion port if not done so already.
Around at https://docs.dev-docs.org/
Has some essential stuff about it there.
Czubas old CT site has some interesting timing diagrams and some stuff aswell.
http://powerphenix.com/index.html

Many thanks. I hadn't realsed The CT60 had published specs. That will be very interesting to have a look at the schematic and compare to mine!

I have seen the dev doc before and reading it again, I *think* I need to use CPUBGO for bus grant and disregard the BG line. This would position the expansion at the top of the bus mastery tree (well, just below the disabled onboard CPU). Those are the only few pages I've actually found anywhere dealing with actually using the expansion bus.

However if one wants to use the EINT1/3, those are a bit odd since Falcon Rom:s are coded so that CPU Ipl:s upto 3 when booted.Remember that took me a while to figure out how it worked.

And yeah, if you want to build a proper mCpu style bus master for it there is quite a lot to read up on.

From waht I can gather (since I'm going to be providing the processor) I don't think I need to worry about any of the interrupt lines other than the IPL[0:2] set since it'll be other devices wanting to interrupt me, but I agree it looks tricky -- hence why starting with small ambitions!

I appreciate the reply, thanks again.

BW.

[neanderthal]

Many thanks. I hadn't realsed The CT60 had published specs. That will be very interesting to have a look at the schematic and compare to mine!

Well not maybe proper docs as such but stuff that he did when figuring out stuff?,always helpfull
I found the timing diags interesting and the partial GAL/PAL stuff rather interesting,you know the sort of lets glue a 030 on this bus with DSP adress coding thing.

I have seen the dev doc before and reading it again, I *think* I need to use CPUBGO for bus grant and disregard the BG line. This would position the expansion at the top of the bus mastery tree (well, just below the disabled onboard CPU). Those are the only few pages I've actually found anywhere dealing with actually using the expansion bus.

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)

From waht I can gather (since I'm going to be providing the processor) I don't think I need to worry about any of the interrupt lines other than the IPL[0:2] set since it'll be other devices wanting to interrupt me, but I agree it looks tricky -- hence why starting with small ambitions!

I appreciate the reply, thanks again.

BW.

Yeah the lower IPL thing is mostly for folks like me who want to use the expansion for slave devices capable of interupting the standard main CPU for whatever reason

No worries,know that there is not much info about it around so just bobbed in about the stuff that done myself..Cheers

[Badwolf]

Many thanks. I hadn't realsed The CT60 had published specs. That will be very interesting to have a look at the schematic and compare to mine!

Well not maybe proper docs as such but stuff that he did when figuring out stuff?,always helpfull
I found the timing diags interesting and the partial GAL/PAL stuff rather interesting,you know the sort of lets glue a 030 on this bus with DSP adress coding thing.

Well the first experimental board's just gone out for manufacture, so I'll be turning my attention to firmware -- this will be required study, I think!

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)

Yeah, I think experiments will be needed. CPUBGO puts you at number two in the list behind the internal, but I'm not sure what happens if you've requested mastery and never relinquished it! It seemed to me that by holding /HALT low (from start up) nothing else should even realise the internal CPU is there, but we'll see. I've routed most of the system bus to my CPLD -- lots more than the CT60 does, actually -- so I can try out a few things.

Yeah the lower IPL thing is mostly for folks like me who want to use the expansion for slave devices capable of interupting the standard main CPU for whatever reason
No worries,know that there is not much info about it around so just bobbed in about the stuff that done myself..Cheers

Cheers. Time to start researching cheap logic analysers.

BW.

[viking272]

Hi Badwolf, how did you get on with the board?

[Badwolf]

Hi Badwolf, how did you get on with the board?

Hi Viking272,

Development continues, thanks. I'm now onto revision three and am debugging my SDRAM controller. Unfortunately, I keep blowing up CPLDs, which complicates things as I'm never sure what's my bug and what's a failed pin!

There's a little bit more information at https://github.com/dh219/DFB/wiki, although I've not updated the rev3 page very much yet.

populated.jpeg

recognised_128.JPG

SDRAM was working at 40MHz, but became unstable at other frequencies. I've set about building a new SDRAM controller to work asynchronously as I want to squeeze a bit more performance out of it.

PM-Doom went from 1.3FPS on stock to 3.3 at 40MHz, but I'm hoping I can get that up to 5. Maybe not with Rev3, though.

Thanks for asking!

BW.

[viking272]

Nice going! So you've hit all your targets/goals??
So the ram is FastRAM @ 60ns?
Can you run NemBench 2.1? Would be interesting to see the figures. Great work.

[Badwolf]

Nice going! So you've hit all your targets/goals??
So the ram is FastRAM @ 60ns?
Can you run NemBench 2.1? Would be interesting to see the figures. Great work.

Not quite yet. The AltRAM was only stable in a very limited set of circumstances and was only working at half speed.

I'm developing entirely new SDRAM controller code now to hopefully work around that. I don't think this board is capable of getting the best speed out of the RAM unfortunately (would need to drive it at 100MHz and this revision isn't 'clean' enough for that), but I was getting 16-17MB/s in that previous 'slow' mode.

Maybe I can get that up to 20MB/s, with luck.

When (if) I get the AltRAM stable, the last big headache is the DSP. Currently it's simply disabled as I haven't yet had time to fully investigate how it communicates. I know there are issues with its interrupts, but I'm not sure what they are yet. I did fix a bug where I hadn't realised it was an 8 bit bus to the DSP, but that wasn't sufficient to get it working.

Cheers,

BW

[frank.lukas]

very very nice

I hope you sell one of these when all is ready and work well ...

[Orion_]

very nice job !
could be a cool alternative to the ct60e shortage and expensive 060

[MegaSTEarian]

Excellent work, keep us posted.

[alexh]

Very interesting work. Well done. I wonder why you keep blowing up CPLDs/FPGAs? Wrong voltages on some pins?

Any chance of releasing the physical data for the PCB? Not so much to make clones but you've measured everything and got everything to fit and that could be very useful.

I've been considering making an Falcon 030 adapter for PiSTorm the Raspberry Pi based 680x0 hardware emulator.

[viking272]

Also that's a nice write up on Github for your wiki

[Badwolf]

Very interesting work. Well done. I wonder why you keep blowing up CPLDs/FPGAs? Wrong voltages on some pins?

Lack of protection on some inputs, or fights with the rest of the bus when being programmed, maybe? I've killed the pin I use for the enable flag on two now! The pin next to it seems to have bitten the dust too. My cheap-arsed logic analyser (doubt there's any buffering going on with it) probably doesn't help, either.

Any chance of releasing the physical data for the PCB? Not so much to make clones but you've measured everything and got everything to fit and that could be very useful.

The whole shebang will be open source when I can get it to work. I'm not into manufacture.

I've been considering making an Falcon 030 adapter for PiSTorm the Raspberry Pi based 680x0 hardware emulator.

I agree that looks very cool and something I had mused about in the past as 68030 emulation is far head of 68030 FPGA implementation.

Good luck with it!

BW.

[neanderthal]

Cheers. Time to start researching cheap logic analysers.

BW.

But hey missed this back around a year ago?,,Oh yes now I remember did a Cpp course then.Must have been cause of that.
Head full of software things and distractions

Nice to see about the progress,have to check out the githubby page.

[neanderthal]

When (if) I get the AltRAM stable, the last big headache is the DSP. Currently it's simply disabled as I haven't yet had time to fully investigate how it communicates. I know there are issues with its interrupts, but I'm not sure what they are yet. I did fix a bug where I hadn't realised it was an 8 bit bus to the DSP, but that wasn't sufficient to get it working.

Ah yeap there the thing of the onboard GAL/PALs comes in since it is the only thing that does proper 030 IO on the falcy.
That is uses dynamic portsizes full out,thats why the DSP can be accessed as a 32-bit device even if physical io-port is only 8-bit.

So a combo of reading how the dynamic bus access works and figuring out how the GAL/PALs do the job.
Cant remember how Bmode was described but there could be thing there aswell if it changes some io-timing or so?

[Cyprian]

When (if) I get the AltRAM stable, the last big headache is the DSP. Currently it's simply disabled as I haven't yet had time to fully investigate how it communicates. I know there are issues with its interrupts, but I'm not sure what they are yet. I did fix a bug where I hadn't realised it was an 8 bit bus to the DSP, but that wasn't sufficient to get it working.

Ah yeap there the thing of the onboard GAL/PALs comes in since it is the only thing that does proper 030 IO on the falcy.
That is uses dynamic portsizes full out,thats why the DSP can be accessed as a 32-bit device even if physical io-port is only 8-bit.

So a combo of reading how the dynamic bus access works and figuring out how the GAL/PALs do the job.
Cant remember how Bmode was described but there could be thing there aswell if it changes some io-timing or so?

is'nt that DSP port seen as 16bit from 68030 side and as 8 bit from DSP side?

[Badwolf]

Ah yeap there the thing of the onboard GAL/PALs comes in since it is the only thing that does proper 030 IO on the falcy.
That is uses dynamic portsizes full out,thats why the DSP can be accessed as a 32-bit device even if physical io-port is only 8-bit.

So a combo of reading how the dynamic bus access works and figuring out how the GAL/PALs do the job.
Cant remember how Bmode was described but there could be thing there aswell if it changes some io-timing or so?

is'nt that DSP port seen as 16bit from 68030 side and as 8 bit from DSP side?

Not sure. The DSP only has 8 lines connected -- that's no problem, I assert DSACK0 instead of DSACK1 when receiving XDTACK -- but reading Miro's notes at https://mikrosk.github.io/ct2/NOTES.html#dsp-irq-signal it would appear there is something else afoot involving interrupts. Unlike the narrative around the CT2 there however, I'm not seeing 'spurious interrupt' errors.

To be honest, the SDRAM is causing me enough headaches* at the moment that DSP is filed firmly in the 'later' camp!

BW

* SDRAM works fine when both it and the CPU are clocked at 16MHz. If either are clocked differently to each other it fails. I don't understand why, it should work with asynchronous access AFAICT. It can be made to work at 40MHz too, with a bit more clock buffering, but at 50MHz it brings the system down even when it's not being accessed! I think there are actually two issues at play -- the first (lack of asynchronous success) being with my firmware and the second (failing at the higher speeds) being a combination of load on the clock and poor board design. Investigations are ongoing.

[neanderthal]

When (if) I get the AltRAM stable, the last big headache is the DSP. Currently it's simply disabled as I haven't yet had time to fully investigate how it communicates. I know there are issues with its interrupts, but I'm not sure what they are yet. I did fix a bug where I hadn't realised it was an 8 bit bus to the DSP, but that wasn't sufficient to get it working.

Ah yeap there the thing of the onboard GAL/PALs comes in since it is the only thing that does proper 030 IO on the falcy.
That is uses dynamic portsizes full out,thats why the DSP can be accessed as a 32-bit device even if physical io-port is only 8-bit.

So a combo of reading how the dynamic bus access works and figuring out how the GAL/PALs do the job.
Cant remember how Bmode was described but there could be thing there aswell if it changes some io-timing or so?

is'nt that DSP port seen as 16bit from 68030 side and as 8 bit from DSP side?

Well that is sort of where the dynamic sizing comes in and why the entire 030 can be operated with only 16bit physical bus,tho one has to use the slower async style with DSACK1/0 and SIZ1/0.
Mostly from my memory..
The 030 can try to get any size legit operand and if the hardware(ie the GALs in falcon) supports it will try to fill the destination with the sized data undepending of io-port size.
So like a Move.l DspHostport,d0
Seen inside the DSP as a 24bit reg (HRX/HTX)
Will in one instruction shuffle in 4x8bit real accesses from DSP hostregister(HTX) into d0,including a dummy fill 8bits as zeros,thats a design choice to do it in one 32bit host io instruction and let the hardware to do the job instead.
Much faster than trixing around separate 8/16 io instructions where one would have to do reg swapping and other time consuming stuff.
But otherwise afaik the rest of system uses the GAL:s 68k bus emulation since the system is designed around a 68k bus with UDS/LDS,sort of why the expansion port is pretty much 68k stylish with some extras.Main memory and video subsystem is of course full 32bit.
Well that was a bit fun,had to peek into the old books and all ..Think got it somewhat right there?..its wednesday after all

[neanderthal]

To be honest, the SDRAM is causing me enough headaches* at the moment that DSP is filed firmly in the 'later' camp!

BW

* SDRAM works fine when both it and the CPU are clocked at 16MHz. If either are clocked differently to each other it fails. I don't understand why, it should work with asynchronous access AFAICT. It can be made to work at 40MHz too, with a bit more clock buffering, but at 50MHz it brings the system down even when it's not being accessed! I think there are actually two issues at play -- the first (lack of asynchronous success) being with my firmware and the second (failing at the higher speeds) being a combination of load on the clock and poor board design. Investigations are ongoing.

Reading up on some of the earlier stuff up here,wonder if you are experiencing the out of sync (even if using async style) with the system thing.
Cause had these ideas myself to speed up and maybe use TT-ram with built in CPU,a even more cheapish speeder,and maybe use the 030 in real speed style and not as throttled as it is in a standard falcy.
For even if on top of BG-chain one has to think of that system was built with system-bus speed of 16Mhz as max.
So everything else in the system is expected to work with those timing constraints,and there are a bundle of them.
Things like if /AS comes very fast in time after last bus-cycle does combel even register it,not to mention all interrupt/cpu space stuff?
Anywho a bus synchro clock is what I thought of,,that is using the expansion port clock output (system bus clock or CPU Clock as named)as restrainer for too fast signals so main system dont get confused and lockout and so forth.

Tho the clocking sdram and cpu differently is somewhat confusing,do you have a mem io buffer in the design or something(like the combel/videl combo sort of does)?

[Badwolf]

...
So everything else in the system is expected to work with those timing constraints,and there are a bundle of them.
Things like if /AS comes very fast in time after last bus-cycle does combel even register it,not to mention all interrupt/cpu space stuff?
Anywho a bus synchro clock is what I thought of,,that is using the expansion port clock output (system bus clock or CPU Clock as named)as restrainer for too fast signals so main system dont get confused and lockout and so forth.

At the moment I just slow the external CPU to 16MHz when accessing the bus. That's stable and reliable without SDRAM. Experiments in masking cycles to match the expected time didn't get very far, but that would certainly be one for the future.

When accessing altram (and the onboard ROM), the CPU can run at full speed. This has shown to been work in rev2b, which used SRAM:

rev2b.jpeg

rev2b_withNVDI.jpeg

Tho the clocking sdram and cpu differently is somewhat confusing,do you have a mem io buffer in the design or something(like the combel/videl combo sort of does)?

No latches, but deactivating the RAM clock one half cycle before output is valid holds the data. That lets me assert DSACKx at leisure. STERM also works and would let me provide a little speed boost when it's stable, but at the moment if I run it at 16MHz with the CPU it will pass all the RAM tests, but then I'll get freezes, bus errors and privilege violations when in real use.

It's very frustrating as I know the theory is sound (rev2b's SRAM demonstrated that) and SDRAM controller appears to be behaving from all my probing. Rev 2b was Altera, this is Xilinx and there have definitely been some problems from the switch, though.

BW

[Badwolf]

No latches, but deactivating the RAM clock one half cycle before output is valid holds the data. That lets me assert DSACKx at leisure.

Embarrassed to say this was actually causing my locking up. I must have misunderstood the data sheet. Delaying the clock hold by one cycle stopped the hangs at 16MHz.

Only works at 16MHz so far, but at least that means I can work on the accelerated logic tonight instead.

BW

[Fletch]

This project looks promising. I'd be very interested in a faster 68030 for the Falcon if that is where this is headed.

[neanderthal]

No latches, but deactivating the RAM clock one half cycle before output is valid holds the data. That lets me assert DSACKx at leisure.

Embarrassed to say this was actually causing my locking up. I must have misunderstood the data sheet. Delaying the clock hold by one cycle stopped the hangs at 16MHz.

Only works at 16MHz so far, but at least that means I can work on the accelerated logic tonight instead.

BW

Ah great,so now you have at least own ram access and normal falcon ram+io access sorted out?
Nice breakpoint,one of the reasons why I thought of tweaking with the built in so dont have to worry about io at normal speeds.

And about embarrassement,that is just things that happen when designing, one gets something backwards or misses thinking about it.
Myself did a temporary fix on a ISA design of mine and almost forgot about it,just to later realize everything had been ok from the beginning..lol
It was really a software thing at the unlocking of the device that was wrong,,well that cost me several weeks later on,luckily had made notes of the temp revision fix