The PARIS Forums


Home » The PARIS Forums » PARIS: Main » PSCL update
Re: PSCL update [message #100345 is a reply to message #100335] Mon, 15 September 2008 10:59 Go to previous messageGo to previous message
Aaron Allen is currently offline  Aaron Allen   UNITED STATES
Messages: 1988
Registered: May 2008
Senior Member
I've said it before, but it's worth another round. You absolutely fail to
suck bro. Awesome work, I can't wait to get a multi core rig going with some
EDS's in it to bust a trial off.
AA


"Mike Audet" <mike@....> wrote in message news:48ce6d22$1@linux...
>
> Thanks, Chuck! I've been reading up on volatile variables. I'm thinking
> that some of the delays I'm having to put in might be better handled by
> declaring
> the user mode pointers as volatile given that we're really multitasking
> now.
>
> This is a great learning experience for me. :)
>
> Thanks again!
>
> Mike
>
>
>
> "chuck duffy" <c@c.com> wrote:
>>
>>Lookin good dude. I'm trying to dig up the C16 code for you, I'll bet you
>>could have fun with that :-)
>>
>>Chuck
>>
>>"Mike Audet" <mike@...> wrote:
>>>
>>>
>>>
>>>Looks like I trimmed the timings down too far in one place.
>>>
>>>Here's a newer one.
>>>
>>>
>>>
>>>
>>>"Mike Audet" <mike@...> wrote:
>>>>
>>>>
>>>>
>>>>Hi All,
>>>>
>>>>Here's my latest build of the PSCL.
>>>>
>>>>I thought I should write a bit about what the PSCL is and what it does.
>>>
>>>>
>>>>
>>>>There is a set chain of communication that goes on in PARIS while the
> app
>>>>is running. It looks like this:
>>>>
>>>>PARIS App <--> PSCL <--> scherzo driver <---> hardware.
>>>>
>>>>Basically, the App calls functions in the PSCL in order to tell the
>>>>hardware
>>>>to stop playing, or start, or load the driver for the 8 out cards, or
> whatever.
>>>> The PSCL translates these requests to commands that the cards can
>>>> understand
>>>>and sends the commands to the scherzo driver to pass them down to the
> cards.
>>>>
>>>>
>>>>When the PSCL was first written - which was a long time ago now - there
>>>was
>>>>no way to run PARIS on a multi-CPU machine. Not only was there no need
>>>to
>>>>protect the code from the hazards of a multi-cpu machine, there was no
>>way
>>>>to test if what you had done worked even if you tried.
>>>>
>>>>I've been trying to make the PSCL multi-cpu safe. This has been a huge
>>>challenge
>>>>for me because the PSCL was written in a c-like style. It's all
>>>>structures
>>>>and functions. It's not object oriented at all, which is what is more
>>common
>>>>today and what I'm used to. I'm also still a new programmer. So, more
>>>than
>>>>once I've thought something was broken or messed up when it probably
>>>>wasn't.
>>>> I just didn't understand it correctly.
>>>>
>>>>Anyway, what I have done is put locks on all the resources I can find
> that
>>>>could be affected by two CPUs trying to change them at the exact same
> time.
>>>> I've also discovered that there are certain card resources that the
>>>> PSCL
>>>>tries to change directly without going through the scherzo driver.
>>>>These
>>>>variables seem to need around 3 miliseconds to "take". I think that
>>>>under
>>>>windows 95, the PSCL was directly altering the memory on the cards, but
>>>Windows
>>>>XP doesn't allow that. What I think is happening is that Windows is
>>>>intercepting
>>>>the attempt to alter the variable and passing it down through the
>>>>regular
>>>>mechanisms, and that imposes a delay. If the app moves on and tries to
>>>do
>>>>something that requires the value being set properly, things go wrong.
>>
>>>I'm
>>>>guess that on a single CPU system, Windows is regularly interrupting to
>>>manage
>>>>memory, read files from the disk, update the clock, etc, etc., so these
>>>delays
>>>>were "filled in" by windows. I'm just making them explicit.
>>>>
>>>>Anyway, it seems to be working well for me. I also tightened up the
>>>>start
>>>>up hardware detection timings because some of them seem to work fine at
>>>one
>>>>fifth what they were now that the direct writes are being managed.
>>>>
>>>>There are other small changes, too. Let me know if you have a chance
> to
>>>>try this and how it goes. There may be hardware configurations that
>>>>don't
>>>>like what I've done. But, my IF2 now work, and it wasn't working well
>>as
>>>>of the last build.
>>>>
>>>>I hope this clears up any questions about what I'm doing. I'll try to
>>package
>>>>these changes into a proper installer once I'm done building, which will
>>>>probably be soon. I think we're almost there.
>>>>
>>>>All the best!
>>>>
>>>>Mike
>>>
>>
>
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Paris Flying Faders
Next Topic: CD WRITING SOFTWARE QUESTION
Goto Forum:
  


Current Time: Sun Jun 09 10:05:54 PDT 2024

Total time taken to generate the page: 0.02706 seconds