Beginning of very long journey

[mikro]

So you are saying that VIDEL can work on asynchronous clock from the rest of components? I mean would scenario where the Videl is fed from 32,08... crystal, while CPU, FPU, exp.port and namely DMA are fed 40 MHz (/2) from (unsynced) PLL work?

SDMA surely shouldn't cause troubles however I'm unsure about the Combel as it contains also the Blitter so it must somehow cooperate with the Videl and RAM (which is accessed via Videl).

On the other hand, if Videl can be overclocked *alone* to 50 MHz via the external pin while Blitter (at 8/16 MHz) works normally, why it shouldn't work?

My impression was that the only reason why people didn't let 32 MHz on VID32 and 50 MHz on its external clock was the difficulty of cutting the VID32 path and replacing it with a separate wire (similarly as done with the SDMA and DSP).

[mikro]

One thing I do not understand well is, why SDMA is fed not only main CPU clock (16,04..MHz CPUCLKA signal), but also 25,175 MHz from VIDEL and especially, 32MHz from DSP.
I mean - CLK8, CLK4, CLK2 and KHZ5000 are derivated from CPUCLKA (correct?), what is the purpose?

As far as I know CLK2 (YM2149), FCCLK (AJAX) and CLK8 (85C30) are derived from DSP's 32 MHz. CLK4 (MFP) most likely too but I'm not 100% sure (isn't MFP derived from the master clock?). KHZ500 from CPUCLKA, yes.

Why there is the need of Videl's 25.175 MHz, that is a very good question.

EDIT: now I see it in the schematics - you've mistakenly assigned CLK4/KHZ500 from the Combel to SDMA. :) So yes, those are indeed derived from the master clock.

EDIT #2: OK, I. Am. Such. An. Idiot. Of course we need 25.175 MHz. Anyone has ever thought of the sound DMA? ;-) That's the sound system base frequency.

[mpattonm]

As far as I know CLK2 (YM2149), FCCLK (AJAX) and CLK8 (85C30) are derived from DSP's 32 MHz. CLK4 (MFP) most likely too but I'm not 100% sure (isn't MFP derived from the master clock?). KHZ500 from CPUCLKA, yes.

Ah, ok, that makes sence. Except for why is KHZ500 derivated from a different source.

EDIT: now I see it in the schematics - you've mistakenly assigned CLK4/KHZ500 from the Combel to SDMA. So yes, those are indeed derived from the master clock.

Oh, right. Shoot.

[joska]

EDIT #2: OK, I. Am. Such. An. Idiot. Of course we need 25.175 MHz. Anyone has ever thought of the sound DMA? That's the sound system base frequency.

...and the pixel clock for VGA 640x480.

http://tinyvga.com/vga-timing/640x480@60Hz

[mikro]

...and the pixel clock for VGA 640x480.

http://tinyvga.com/vga-timing/640x480@60Hz

Of course but that is Videl's job, not SDMA's. They both share the clock for different tasks.

[mpattonm]

My impression was that the only reason why people didn't let 32 MHz on VID32 and 50 MHz on its external clock was the difficulty of cutting the VID32 path and replacing it with a separate wire (similarly as done with the SDMA and DSP).

IDK, I still feel it would be safer to have an option to run an entire system on an unmodified Falcon clock.

[joska]

Of course but that is Videl's job, not SDMA's. They both share the clock for different tasks.

Yes, I did not read the original question, just the "Why there is the need of Videl's 25.175 MHz"-part. My mistake.

[mikro]

My impression was that the only reason why people didn't let 32 MHz on VID32 and 50 MHz on its external clock was the difficulty of cutting the VID32 path and replacing it with a separate wire (similarly as done with the SDMA and DSP).

IDK, I still feel it would be safer to have an option to run an entire system on an unmodified Falcon clock.

Exactly - that is why VID32 would be getting the original 32.08... clock and you would be free to do whatever you want on the *external* clock. Why CENTEK didn't do this I can only speculate.

[joska]

Switching DSP to 56301 will be a little setback, but hey - its a fun project and thats where the fun is. So back to the schematics.

Awesome. Just want to mention it - in this case some minor changes to the TOS are going to be needed.

If TOS needs to be changed to work with the 56301, how would compatibility with games and demos be?

[mpattonm]

If TOS needs to be changed to work with the 56301, how would compatibility with games and demos be?

I wonder that too. But on the other hand, the performance benefit is really high, someone might be tempted to write a new code for it. (I know what you are probably saying now )

[mpattonm]

Anyway, could _this_ be it?

[joska]

But on the other hand, the performance benefit is really high, someone might be tempted to write a new code for it. (I know what you are probably saying now )

I think that when you spend this much work on a project, the goal should be clear first. So is this going to be an improved Falcon030, but still a Falcon030? Or a "next generation" higher-spec'ed Falcon, with the inevitable compatibility issues?

[mpattonm]

Haha, you are completelly right. I guess it could be easily specced as "beafed and improved, but still a Falcon030" if I keep a current DSP in it. Actually, it was always my intention. Baby steps.
But I am so tempted now The fact is, eventually, the compatibility needs to be broken anyway.

[mikro]

If TOS needs to be changed to work with the 56301, how would compatibility with games and demos be?

I wonder that too. But on the other hand, the performance benefit is really high, someone might be tempted to write a new code for it. (I know what you are probably saying now :wink: )

I haven't read the whole DSP56301 UM yet. ;-) It's object code compatible, so that's a very good news (compare with the FireBee/CF situation...). I'm sure stuff like resetting the DSP, loading the bootstrap code, CPU/DSP sync issues will needs some attention. But then again, DSP XBIOS has been already patched for the sync issues and some minor bootstrapping differences are easy to solve.

So as far as games/demos go, if they don't rely on some dirty practices (like writing beyond RAM space relying on the fact it's mirrored or overflowing the stack -- ask Hatari guys!), they should be fine.

In my very humble opinion, you should be fine to get away with a patched TOS instead of the original TOS 4.04 only. CT60TOS literally begs to be used here as the base for the modifications. Compatibility would be naturally much higher than with the CT60.

Anyway, could _this_ be it?

Looks good to me. Only time (or first implementation ;)) will tell whether that VID32 really needs to be multiplexed. Maybe it's fine to have 32.08... there in all cases without any multiplexing.

EDIT: Ha, look at this: You can also configure it to operate in a special sixteen-bit compatibility mode that allows the chip to use DSP56000 object code without any change; this can result in higher performance of existing code for applications that do not require a larger address space. The bad news is that you have to set this bit manually, it's not by default (understandably).

[joska]

So as far as games/demos go, if they don't rely on some dirty practices (like writing beyond RAM space relying on the fact it's mirrored or overflowing the stack -- ask Hatari guys!), they should be fine.

What about software that does not use TOS functionality but handles this itself:

I'm sure stuff like resetting the DSP, loading the bootstrap code, CPU/DSP sync issues will needs some attention. But then again, DSP XBIOS has been already patched for the sync issues and some minor bootstrapping differences are easy to solve.

As Atari users we know that a *lot* of developers knew better than Atari and bypassed the OS. A few weeks ago I was playing around with a DSP modplayer and it uploads it's own DSP bootstrap code.

[mikro]

As Atari users we know that a *lot* of developers knew better than Atari and bypassed the OS. A few weeks ago I was playing around with a DSP modplayer and it uploads it's own DSP bootstrap code.

As I person who used to do the same ;) I can tell you it's not that bad. The most known example is NoCrew's MP2 bootstrapping code. Yes, they indeed really reset the DSP and upload their own code. But this is easy to detect in Pexec(): the bootstrapping routine is always the same.

Frankly, I'd be interested to know about other cases. Are you sure you are not confusing it with a software bootstrap? I.e. that you use either Dsp_ExecBoot() or NoCrew's bootstrapper to install your code instead of the one by Atari but that is not the same problem. In the former case you'd be using a patched XBIOS so no problem there and in the latter, well, see above - the patched TOS would detect this situation, CT60TOS does similar tricks.

[joska]

Frankly, I'd be interested to know about other cases. Are you sure you are not confusing it with a software bootstrap? I.e. that you use either Dsp_ExecBoot() or NoCrew's bootstrapper to install your code instead of the one by Atari but that is not the same problem.

I'm specifically talking about DSPMOD 3.4 which resets the DSP and writes DSP bootstrap code to it by accessing hardware directly. No XBIOS is used. Of course, since I know virtually nothing (yet) about how the DSP and DSP interface actually works this might not be a problem at all.

[mikro]

My impression was that the only reason why people didn't let 32 MHz on VID32 and 50 MHz on its external clock was the difficulty of cutting the VID32 path and replacing it with a separate wire (similarly as done with the SDMA and DSP).

IDK, I still feel it would be safer to have an option to run an entire system on an unmodified Falcon clock.

Exactly - that is why VID32 would be getting the original 32.08... clock and you would be free to do whatever you want on the *external* clock. Why CENTEK didn't do this I can only speculate.

Ten speculations are worse than one fact checking so I did exactly that, asked the creator. :)

Your gut feeling was right, it can not work like that. I even guessed it, Videl is indeed using VID32 to sync with the Combel (for ST-RAM access). So *that* is the reason why they put 32.08... for compatibility on the external pin when master clock was changed. You are free to modify 25.175 or external clock (they work independently from the system bus) but not VID32, must be the same as master clock.

So you can rewire it a bit - instead of switching between 32.08.../custom clock on VID32 you keep the line from the master clock on VID32 and put the exact same switch on the external clock pin.

[mikro]

Frankly, I'd be interested to know about other cases. Are you sure you are not confusing it with a software bootstrap? I.e. that you use either Dsp_ExecBoot() or NoCrew's bootstrapper to install your code instead of the one by Atari but that is not the same problem.

I'm specifically talking about DSPMOD 3.4 which resets the DSP and writes DSP bootstrap code to it by accessing hardware directly. No XBIOS is used. Of course, since I know virtually nothing (yet) about how the DSP and DSP interface actually works this might not be a problem at all.

See the "Additional patches and fixes by Noring/NoCrew" header? NoCrew's MP2 bootstrap, next please. :)

As I said before, only thing needed is to detect this payload and perhaps patch a couple of bytes in there.

[joska]

next please.

Don't get me wrong, I'm not trying to "prove" that there will be problems with a 56301. It's just that whenever something's updated and improved it's *never* as easy as one thinks. There are *always* unexpected problems that can't be solved by the "easy" fixes one thinks of ahead. Especially in this case we're talking about an irreversible change and basically no way to actually test it before the motherboard has been created and assembled. Careful investigation has to be done to avoid costly mistakes.

So if the goal is to recreate the Falcon030 and run Falcon030 software on it, it has to actually be compatible with existing Falcon030 software. There will be very little new software made in the future (how much software have you seen that take advantage of the Firebee hardware seven years after it's release?), so IMO compatibility will have to be 100%.

[mikro]

Joska: I sure know what you mean. But we have some history to build on - AB040, Nemsis, graphics cards, CT2, CT60 etc. So we can see what worked and what didn't.

And I absolutely agree with your argument about existing software. So if a couple of DSP-based demos wont work with the new Falcon, it's a price I find acceptable. If 50% of them wont work without manual (per-binary) patching, then it is definitely not acceptable.

Don't forget we're not talking about mass producing from day one. I'm sure mpattonm will prepare a board or two for testing, we'll see what works out of the box, what needs patching and whether we can patch it easily (and automatically). Maybe we can even prepare a solution which would allow swapping both DSPs easily? Who knows. I don't live so far away from him and we speak the same language so be sure we can figure out a lot of things before going 'to the market'. As mpattonm is making my all time dream coming true, I am really prepare to offer him as much software support as I possibly can. :)

Also don't forget one more important thing - unless someone figures out an easy process to replace at least the SDMA, Videl and Combel, this new board definitely is not going to be produced (and used) by thousands. So compatibility can be less important than we think.

[Faucon2001]

I have been following this thread from far and I am very excited by this project. Congratulations for this amazing work..

DSP compatibility goes farther than demos. In my case, my center of interest is music. So a Falcon clone for me MUST be able to run Cubase Audio and all DSP based music programs to be interesting. Is this new DSP will allow that? it should be taken into consideration at least one 100% compatible Falcon mode without the need to patch every program.
Falcon are dying little by little, and mine is actually going through a resurrection process, at least I hope so. So a substitue to it is more than welcome. If this object goes to a production stage,I’ll by one for sure.

[mikro]

So a Falcon clone for me MUST be able to run Cubase Audio and all DSP based music programs to be interesting.

Both CT2 and CT60 needed a patch to run Cubase. :)

Of course, it's up to mpattonm to decide, I will support anything which makes the project closer to a successful end, be it a 100% compatible Falcon or only a 90% one.

I just find the idea of having a kind of CT2+Deesee+Nemesis hybrid 'built-in' as super exciting. For some reason I wouldn't want to see a 060 or TT RAM built-in by default. If I had to choose a next step from the base, it would definitely be either 32-bit ST RAM or ST RAM shared with the DSP.

[calimero]

So you can rewire it a bit - instead of switching between 32.08.../custom clock on VID32 you keep the line from the master clock on VID32 and put the exact same switch on the external clock pin.

So 25/32 MHz and external clock are only pixel clocks. Videl always work at 32.08 MHz.


Regarding DSP and ST ram: DSP can only work from it's own RAM, right? What kind of hardware should be designed to allow sync. betwen ST ram and DSP memory?! By design, DSP can access external memory only over slow mechanism.
But if you manage to make this, then it will be single most important thing regarding Falcon boosting!

[SteveBagley]

Another question came to my mind - what would you find more benefitial fo SCSI - an external (Falcon type) connector, or rather an internal pinheader? When I think about it, I am inclined to go for an internal PH. An external connector could be added via riser card, afterall.
What do you think?

Could you not do what the C-Lab falcons did? Keep the SCSI2 socket and replace the termination resistors with a pin header? The termination resistors can then be attached to the pin header by default or removed if an internal scsi chain is needed?

Steve