Beginning of very long journey

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, spiny, Greenious, Moderator Team

mikro
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Fri Oct 12, 2018 12:16 pm

mpattonm wrote: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
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Fri Oct 12, 2018 12:29 pm

mpattonm wrote: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
Captain Atari
Captain Atari
Posts: 304
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 1:01 pm

mikro wrote: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.
mikro wrote: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.
Last edited by mpattonm on Fri Oct 12, 2018 1:17 pm, edited 1 time in total.

joska
Hardware Guru
Hardware Guru
Posts: 4148
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Beginning of very long journey

Postby joska » Fri Oct 12, 2018 1:11 pm

mikro wrote: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
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mikro
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Fri Oct 12, 2018 1:14 pm

joska wrote:...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
Captain Atari
Captain Atari
Posts: 304
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 1:16 pm

mikro wrote: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
Hardware Guru
Hardware Guru
Posts: 4148
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Beginning of very long journey

Postby joska » Fri Oct 12, 2018 1:19 pm

mikro wrote: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.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mikro
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Fri Oct 12, 2018 1:21 pm

mpattonm wrote:
mikro wrote: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
Hardware Guru
Hardware Guru
Posts: 4148
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Beginning of very long journey

Postby joska » Fri Oct 12, 2018 1:22 pm

mikro wrote:
mpattonm wrote: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?
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mpattonm
Captain Atari
Captain Atari
Posts: 304
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 1:34 pm

joska wrote: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: )

mpattonm
Captain Atari
Captain Atari
Posts: 304
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 1:35 pm

Anyway, could _this_ be it?
You do not have the required permissions to view the files attached to this post.

joska
Hardware Guru
Hardware Guru
Posts: 4148
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Beginning of very long journey

Postby joska » Fri Oct 12, 2018 1:50 pm

mpattonm wrote: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 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?
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mpattonm
Captain Atari
Captain Atari
Posts: 304
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 2:01 pm

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
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Fri Oct 12, 2018 2:03 pm

mpattonm wrote:
joska wrote: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.

mpattonm wrote: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).
Last edited by mikro on Fri Oct 12, 2018 2:14 pm, edited 1 time in total.

joska
Hardware Guru
Hardware Guru
Posts: 4148
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Beginning of very long journey

Postby joska » Fri Oct 12, 2018 2:11 pm

mikro wrote: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:

mikro wrote: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.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mikro
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Fri Oct 12, 2018 2:22 pm

joska wrote: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
Hardware Guru
Hardware Guru
Posts: 4148
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Beginning of very long journey

Postby joska » Fri Oct 12, 2018 3:29 pm

mikro wrote: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.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mikro
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Sat Oct 13, 2018 7:25 am

mikro wrote:
mpattonm wrote:
mikro wrote: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
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Sat Oct 13, 2018 7:32 am

joska wrote:
mikro wrote: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
Hardware Guru
Hardware Guru
Posts: 4148
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Beginning of very long journey

Postby joska » Sat Oct 13, 2018 5:13 pm

mikro wrote: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%.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mikro
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Sat Oct 13, 2018 5:37 pm

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
Atari Super Hero
Atari Super Hero
Posts: 719
Joined: Sat Oct 26, 2013 11:19 pm
Location: Brasil
Contact:

Re: Beginning of very long journey

Postby Faucon2001 » Sat Oct 13, 2018 6:32 pm

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

Firebee, Falcon, STE, Aranym Box, Hatari Pi Box.
My music http://www.philippeworld.net/
My photography http://phil-67.deviantart.com/
EasyAraMint, BeeKey and BeePi https://sites.google.com/site/beebox68k/

mikro
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Sat Oct 13, 2018 8:14 pm

Faucon2001 wrote: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.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2224
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Beginning of very long journey

Postby calimero » Sun Oct 14, 2018 7:56 am

mikro wrote: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! :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

SteveBagley
Captain Atari
Captain Atari
Posts: 165
Joined: Mon Jan 21, 2013 9:31 am

Re: Beginning of very long journey

Postby SteveBagley » Sun Oct 14, 2018 9:02 am

mpattonm wrote: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


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 4 guests