The DSP and expansion cards (eg. the CT2 issue)

Hardware, coding, music, graphic and various applications

Moderators: Mug UK, [ProToS], moondog/.tSCc., lp, Moderator Team

czietz
Hardware Guru
Hardware Guru
Posts: 1498
Joined: Tue May 24, 2016 6:47 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by czietz »

Note that such seemingly dramatic ringing can easily be caused by suboptimal scope probing. When you use the ground return lead and connect its alligator clip somewhere, you add a considerable inductance, which results in ringing when measuring fast edges.
Therefore, whenever you're interested in signal integrity, use a better ground connection. For example, the small spring that is provided with your probe.

EDIT: E.g. compare Fig. 2 and Fig. 5 in this article: https://www.analog.com/en/technical-art ... hotos.html
User avatar
mpattonm
Hardware Guru
Hardware Guru
Posts: 580
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by mpattonm »

czietz wrote: Fri May 07, 2021 11:40 am Note that such seemingly dramatic ringing can easily be caused by suboptimal scope probing. When you use the ground return lead and connect its alligator clip somewhere, you add a considerable inductance, which results in ringing when measuring fast edges.
Therefore, whenever you're interested in signal integrity, use a better ground connection. For example, the small spring that is provided with your probe.

EDIT: E.g. compare Fig. 2 and Fig. 5 in this article: https://www.analog.com/en/technical-art ... hotos.html
Very true!
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

Yes, you're probably right. I had an enormous ground loop testing that (clipped to the shielding!) as, to be honest, I was only looking at timing.

Now I need to figure out how I can either slow down the activation of XAS so it doesn't overlap and cause that runt DSACK0 blip, or tighten up my clock timings.

This is my present XAS logic:

Code: Select all

assign _XAS = enabled & busmine ? altram | rom | _AS | ~slow_is_active : 1'bz; // hold off XAS until the fast clock is flagged as inactive
None of altram, rom, slow_is_active are relevant here (it's not ROM or altram and I'm always in slow mode at the moment) and enabled and busmine are true throughout the cycle, so that's about as fast a pass-through of (the 030's) AS as I can manage. Maybe add some kind of latch for EDTACK to have been high one cycle ago, or something? Would probably slow down all ST-RAM access, but getting DSP working at all is the first goal.

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

The signal's not that bad with a shortened probe ground path.

The real problem is more obvious to see too.

DSACK0_v_EDTACK 3.jpeg

BW
You do not have the required permissions to view the files attached to this post.
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
User avatar
mpattonm
Hardware Guru
Hardware Guru
Posts: 580
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by mpattonm »

It illustrates there is a problem of some kind. If there is a TTL gate on input of this signal, it will be skipping to HIGH with that ripple reaching 2V levels. Even if it is CMOS, it is in no mans' lands range. Maybe routing issue, parasitic inductance for instance? Is the IC this signal is coming off properly decoupled?
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

mpattonm wrote: Fri May 07, 2021 5:55 pm It illustrates there is a problem of some kind. If there is a TTL gate on input of this signal, it will be skipping to HIGH with that ripple reaching 2V levels. Even if it is CMOS, it is in no mans' lands range. Maybe routing issue, parasitic inductance for instance? Is the IC this signal is coming off properly decoupled?
I don't think that's ringing, nor do I think it's a signal integrity issue. I think it's a timing issue.

The equations show a clock dependency in the generation of the yellow signal -- it bases its output on input from one clock cycle before. I think because of clock skew, this is active when it shouldn't be, causing a false "runt" signal which goes low, almost immediately releases (causing pull-up) then the real signal drives it low again.

But by then my input signal (XAS) has been released as it's clocked the early false assertion, so now the real signal is released too.

Basically the cycle termination signal activates early, activates again for a second time then is cancelled. Who knows what gets latched?

BW
DSACK0_v_EDTACK 4.jpeg
You do not have the required permissions to view the files attached to this post.
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
neanderthal
Captain Atari
Captain Atari
Posts: 232
Joined: Sun Jul 10, 2016 10:58 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by neanderthal »

Badwolf wrote: Fri May 07, 2021 5:36 pm The signal's not that bad with a shortened probe ground path.

The real problem is more obvious to see too.


DSACK0_v_EDTACK 3.jpeg


BW
So that is DSACK0 and EDTACK compared still? ie Yellow and Blue..And yes that seems oddish however I thought about the timing and adressing of bytes via the expansion.
Since the first approx 150nS ? cycle works,could it be that if the GAL:s do the entire 68k bus dance with uds/lds, for on write the UDS/LDS is supposed to select size and or half of bus to be used and is actually on proper 68k output later on write cycle than read.
In fact on write not until S4,where as on read at same time as /AS,so could be that the GAL:s never properly asserts xdsp_cs for DSP to latch in data and actually consider cycle as a write on the 3 remaining bytes.
Maybe test the delay idea on writes,that is hold of external CPU for a clock or so on triggering on EDTACK?

How did Bmode work again on expansion?,Think it was something about where /AS is sampled,maybe it does something with the 68k-bus emulation more than that?Nah wait that is in combel only?..I need to consult the old trusty schematics there..heh

And about the ringing,,I didnt even think about since used to see it..lol
And yea depending on what probe is used and grounding etc,,it can look really horrible specially on old analog ones when some high-peaks actually leaks in between the channels and odd stuff like that.
One of the places where probing really messes up the falcy is on the PAL-synchro clock circuitry,a probe around the crystal and main clock is sqewed off so heavily that machine just freezes.
Most likely the main clock jumps so far that all synchro just fails,it normally toggles a bit (around 400hz toggle or something like that?)to be in sync with PAL-line clock.
Fun fact,only needed for composit video that almost none uses ;)
I have a machine where I disabled the synchro,gonna test some heavy audio on it some day to test out a theory of mine.
neanderthal
Captain Atari
Captain Atari
Posts: 232
Joined: Sun Jul 10, 2016 10:58 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by neanderthal »

Look at that, U68 pin 13 Bmode,interesting,how does the equations for that pin look?(for those that are good at that).
And one of the chips that mainly does DSP decode.
neanderthal
Captain Atari
Captain Atari
Posts: 232
Joined: Sun Jul 10, 2016 10:58 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by neanderthal »

Badwolf wrote: Fri May 07, 2021 7:09 pm
mpattonm wrote: Fri May 07, 2021 5:55 pm It illustrates there is a problem of some kind. If there is a TTL gate on input of this signal, it will be skipping to HIGH with that ripple reaching 2V levels. Even if it is CMOS, it is in no mans' lands range. Maybe routing issue, parasitic inductance for instance? Is the IC this signal is coming off properly decoupled?
I don't think that's ringing, nor do I think it's a signal integrity issue. I think it's a timing issue.
neanderthal wrote: Most of that stuff is just things that we see on the scopes,at least with 1:10 probes,for everytime I have to use a old 'bad' probe it really looks disturbing even if I know that it most likely wont affect timing that badly.Then again there are stuff that dont like too much interference and actually bugs out due to probing.
The equations show a clock dependency in the generation of the yellow signal -- it bases its output on input from one clock cycle before. I think because of clock skew, this is active when it shouldn't be, causing a false "runt" signal which goes low, almost immediately releases (causing pull-up) then the real signal drives it low again.

But by then my input signal (XAS) has been released as it's clocked the early false assertion, so now the real signal is released too.
neanderthal wrote: Yea,something like that sounds reasonable,could be just that you release the XAS so fast that the GAL logic does it by the internal clock which looks like a 3-state just to be quickly activated again for a real short period before proper deactivation.
A bit interesting would be seeing the xdsd_cs in comparison there,for I am not that sure how the latching on the HI is timed.
for io timing wise the last 3 seems ok approx 100nS or so like the internal?,,if one ignores the in between stuff.
Basically the cycle termination signal activates early, activates again for a second time then is cancelled. Who knows what gets latched?

BW

DSACK0_v_EDTACK 4.jpeg
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

neanderthal wrote: Fri May 07, 2021 8:13 pm Look at that, U68 pin 13 Bmode,interesting,how does the equations for that pin look?(for those that are good at that).
And one of the chips that mainly does DSP decode.
I've already identified the equation of interest and, yes, it's U68:

Code: Select all

 DSPDS.e    = VCC;
 DSPDS      = AS * DSP * DL1AS * /A5 * /A4 * /A3;
 
The DL1AS term is the culprit causing that errant transient low at the start of the second, third and fourth cycles. It's because AS is high one cycle before (because of the clock skew from my CPU).

Here's the proof. Here I force XAS through a flip-flop:
DSACK0_v_EDTACK_flipflop.jpeg
Perfecto!

I can confirm Mikro's test program works nicely. I even ran BadMood. :)

However this is not the solution. It incurs a 18% speed hit in accessing the Falcon's bus.

18%_slowdown.jpeg

and WinREC crashes hard.

So I've proved one theory on the issue but now I need to come up with an efficient way to avoid it and now figure out why WinREC crashes in this configuration.

Thanks all for the help so far... now what? :lol:

:cheers:


BW
You do not have the required permissions to view the files attached to this post.
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
neanderthal
Captain Atari
Captain Atari
Posts: 232
Joined: Sun Jul 10, 2016 10:58 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by neanderthal »

Well,,progress,,thats good and isolating causes why.
So very likely that you have to do parts of DSP decode onboard via adresses and clever HW programming.
After all thats what the mobo GALs does in both emulating a plain 68k-bus(tho up-speeded for falcon) and the 030 style DSP access.
But very cool to see stuff happening :)
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

DSP working! :-)

I've had to selectively slow down bus access when the DSP is being accessed to ensure a full clock between end of the previous bus cycle and the start of the next.

This, if applied across the board, would lead to a 15-18% slow down on all ST-RAM accesses, so I only do this for the DSP (it's because of the way the DSP's XDTACK signal is generated by the GALs, so doesn't apply to anything but the DSP).

Technically there's probably a better way to do this that causes less slowdown, but this is quite simple if I can get away with it.

BadMood, Frac and DSPBench run happily.

Sadly, only the ST-RAM based BadMood works as the AltRAM enabled on requires an FPU & I don't think the sources are available.

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
User avatar
dhedberg
Atari God
Atari God
Posts: 1277
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by dhedberg »

Awesome progress! Congrats! Sounds like the next natural step would be to add a socket for a 68882? ;-)
Daniel, New Beat - http://newbeat.atari.org.
Like demos? Have a look at our new Falcon030 demo It's that time of the year again, or click here to feel the JOY.
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

dhedberg wrote: Tue May 11, 2021 10:03 am Awesome progress! Congrats! Sounds like the next natural step would be to add a socket for a 68882? ;-)
Yes, I'd love to.

I'm a bit in awe of the routeing jobs people have managed in the past.

I mean look at these:

Image
Image
Image

So I'm sure it's possible, but I'm not sure how! :lol:

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
User avatar
dhedberg
Atari God
Atari God
Posts: 1277
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by dhedberg »

Yes! Routing a board can easily become a never ending task! :-)
Daniel, New Beat - http://newbeat.atari.org.
Like demos? Have a look at our new Falcon030 demo It's that time of the year again, or click here to feel the JOY.
User avatar
DoG
Captain Atari
Captain Atari
Posts: 215
Joined: Sun Apr 01, 2018 11:02 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by DoG »

dhedberg wrote: Tue May 11, 2021 11:07 am Yes! Routing a board can easily become a never ending task! :-)
Never ending fun :D
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2216
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Cyprian »

great project
Badwolf wrote: Tue May 11, 2021 9:58 am DSP working! :-)

I've had to selectively slow down bus access when the DSP is being accessed to ensure a full clock between end of the previous bus cycle and the start of the next.

This, if applied across the board, would lead to a 15-18% slow down on all ST-RAM accesses, so I only do this for the DSP (it's because of the way the DSP's XDTACK signal is generated by the GALs, so doesn't apply to anything but the DSP).

Technically there's probably a better way to do this that causes less slowdown, but this is quite simple if I can get away with it.
does it mean, an access to the HostPort will be slower than in the stock Falcon?
Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

Cyprian wrote: Tue May 11, 2021 2:10 pm does it mean, an access to the HostPort will be slower than in the stock Falcon?
I suspect so, but I have no idea how to measure this.

My guess is longword writes which usually take around 10 clock cycles now may take around 14, but I've not measured it accurately.

If the DSP is reliant on constant 030 input, that could be an issue. If the 030 is normally waiting on the DSP it probably wouldn't be.

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
Rustynutt
Atari God
Atari God
Posts: 1194
Joined: Wed Mar 21, 2012 7:38 am
Location: Oregon

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Rustynutt »

Throwing this out for discussion.
You mention clock skew several times between the card and mobo clock.
Also, not really one to decrypt your scope timing images :)
Is the timing as tight between your clock and the mobo clock as tight as if it was distributed by an MC88915?
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

Rustynutt wrote: Tue May 11, 2021 4:36 pm Is the timing as tight between your clock and the mobo clock as tight as if it was distributed by an MC88915?
Currently I think there's about a 20-30ns delay from clock edge to the signal, which is probably just about enough to need an extra cycle of sleep between accesses else the GALs will return the signal from the previous cycle.

If the clock was directly coupled and I was only responding to processor actions then there'd be only about a 10ns delay and there probably wouldn't be an issue.

There also wouldn't be an acceleration.

I looked into a multiplicative PLL for generating an in-sync higher frequency, not for clock switching, though. It was slower than my current method. You'd want something that'd run at about 3-3.2x the source frequency and be able to switch down on demand without glitching.

Ultimately, I don't think this is going to be a big issue and if it turns out to be, there are other options to pursue too.

Cheers,

BW.
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
mikro
Hardware Guru
Hardware Guru
Posts: 2365
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by mikro »

Fun trivia: all the CENTEK products (up to the CT2B) had been routed on Atari Falcon in Platon. :)
User avatar
dhedberg
Atari God
Atari God
Posts: 1277
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by dhedberg »

mikro wrote: Wed May 12, 2021 8:23 am Fun trivia: all the CENTEK products (up to the CT2B) had been routed on Atari Falcon in Platon. :)
Wow! Just wow! :-)
Daniel, New Beat - http://newbeat.atari.org.
Like demos? Have a look at our new Falcon030 demo It's that time of the year again, or click here to feel the JOY.
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

dhedberg wrote: Wed May 12, 2021 10:11 am
mikro wrote: Wed May 12, 2021 8:23 am Fun trivia: all the CENTEK products (up to the CT2B) had been routed on Atari Falcon in Platon. :)
Wow! Just wow! :-)
What patience!

I'm so tempted to try that for a (small!) project in the future and see how I get on.

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
neanderthal
Captain Atari
Captain Atari
Posts: 232
Joined: Sun Jul 10, 2016 10:58 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by neanderthal »

Badwolf wrote: Wed May 12, 2021 2:07 pm
dhedberg wrote: Wed May 12, 2021 10:11 am
mikro wrote: Wed May 12, 2021 8:23 am Fun trivia: all the CENTEK products (up to the CT2B) had been routed on Atari Falcon in Platon. :)
Wow! Just wow! :-)
What patience!

I'm so tempted to try that for a (small!) project in the future and see how I get on.

BW
So there was a router/PCB design thing for that kind of stuff on atari?missed out on that,,gotta check that one out some day.I used some way too over-complicated pc-crack thingy(really for pro industrial use) to make my old adapter thing,was mostly for the printing since got a fancy expensive inkjet then.Most stuff before that I made by hand since prototypes only.Used a special ink-pen..Hehe
Think gotta pop up pics/stuff somewhere some day just for historical reasons..lol
Badwolf
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 145
Joined: Thu Mar 16, 2017 12:09 pm

Re: The DSP and expansion cards (eg. the CT2 issue)

Post by Badwolf »

neanderthal wrote: Thu May 13, 2021 8:24 pm So there was a router/PCB design thing for that kind of stuff on atari?missed out on that,,gotta check that one out some day.I used some way too over-complicated pc-crack thingy(really for pro industrial use) to make my old adapter thing,was mostly for the printing since got a fancy expensive inkjet then.Most stuff before that I made by hand since prototypes only.Used a special ink-pen..Hehe
Think gotta pop up pics/stuff somewhere some day just for historical reasons..lol
I had seen references to Atari PCB CAD software in the past, but nothing concrete. I spent an afternoon with OrCAD on DOS around 1994, there's no reason the Falcon couldn't have been up to what that did.

I've just knocked together a new board design, actually. I wasn't brave enough to try sourcing Platon yet, though. :lol: Welcome to the future, eh?

Screenshot 2021-05-13 at 22.37.42.png
Can you guess what it is, by the way? :wink:

BW
You do not have the required permissions to view the files attached to this post.
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)
Post Reply

Return to “Professionals”