Thema:	RE: Yea...!
Datum:	18.10.96  14:42:59
From:	wilki1k@nectech.co.uk (Wilkins, Keith)
To:	Chrissalo@aol.com (Chrissalo)



> Funny... it seems to depend on which Video mode I chose
> (which is really curious!?!?!)

I think it may be dependant on CPU caching and the linking order and size   
will effect things.

> Yesterday I played scramble with an average of 99.6% YEAH!!!!

Nice. What type of PC do you have ??

> Is it correct that an interrupt is only recognized during
> CPU_FETCH?

Yes.

> If so I can probably change the multi-cputick routine that ways it
> runs really most of the time...

You still have the problem of the shift register and more importantly   
when Timer 1 operating it has full control over the RAMP signal so it   
must be expired on the exact cycle otherwise you'll get positional errors   
on the vectors.

> You know I'm virtually an illiterate if it comes down to hardware...
> I heavily rely on your source code... I never knew how a PIA
> worked befor I looked at your code...
> So if some of my suggestions sound stupid don't be too alarmed...

Dont worry. Make the suggestion and if its wacko I'll tell you.

> ... integrators
> You see... I didn't really know how they worked...
> You think if one can come up with a correct e-function and
>'correct' the integrator with that it would be OK?

You'd need to model it with either lookup tables or floating point, the   
problem is the ramp rise profile is dependant on the start position which   
makes things a little more complex for lookup tables.


V =Vstart+( Vtarget-Vstart)* (1-pow(e,-z*Time))

Where e=2.71828 and z is the RC time constant of the circuit   
(approximates to R/C or C/R (can't remember)). Nice equation eh !! I   
think I've got it right, I'd need to get some of my old textbooks out to   
prove it.

> Would one function be enough? Or one for every DAC value?

Possibly not because of the dependancy on the start value. In electronics   
its usually assumed that V will get to 90% of Vtarget within 1 time   
constant.

> (boy I feel stupid)...

boy I hope I've remembered the maths right.

> But I can send you the one I got now... so it is still sort of
> prerelease...

Thanks, although I havent found time to decode it yet.

> Have you tested different hashing calculations?
> I wrote a hashing some time ago from an algorithm book...
> I just played with that calculation routine and doubled
>the efficiency...
> What I mean if you took you hashing from the same kind of book
> it might be not all that efficent (didn't really look into it yet...)

Hahahaha. Nope I just made the hashing function up on the spur of the   
moment. You need a function that gives a good spread over the hashing   
range for your particular data. The improvement was fairly dramatic, so   
my thoughts were "Seems OK" so I havent changed it. You may find a better   
hashing function.

Regards

Keith