Subject: Practical application of the VDP throughput experiment...

From: "Marc H" <[email-masked]>
Date: Wed, 11 Nov 2009 15:38:28 -0000

VDP test wizards (Mike & Mathew...)

I understand now why you guys are getting seemingly fantastic numbers but I think they are still a little misleading (read as: prove me wrong)....

The code you posted seems to write the same value to VDP memory over and over and has been heavily weighted towards achieving high speed (I realize that was the point.) 

Perhaps you could alter your routine to flash a table(just memory contents is fine) in a loop that uses 1: MOV *R13+,*R12  VS 1 MOV *R13+,@VDPWD And then in a loop that uses 8 of each variety. The MOV R13,*R12 should not be used as it would require a second MOV to load R13 initially there by negating any speed increase.

I'm not trying to be a Prick in fact I do have a need for speed in one of my bit-mapped projects and am very interested in your results.  I understand the academic nature of your testing but I'd like to see a practical application if you don't mind.

I'll now get off my soap box and hopefully await your results (if I haven't pissed you off too much ;-)

Thanks in advance....

Marcus

---

From: "Tursi" <[email-masked]>
Date: Wed, 11 Nov 2009 11:26:30 -0500

I don't think you've actually addressed the main issue, which is "why is 
there such a massive difference between absolute and indirect mode?"

To that end, changing it to copy a table (ie: changing the source of the 
data) will slow it down, but I'd be really shocked if it changed the 
issue.

As for the test being academic versus practical, the goal was to test 
the speed reading from a hardware device which provides different data 
each read, so the point was not merely to achieve high speed, but to 
find the best combination of instructions for doing that. Thus the 
source address did not need to change. (At some point the source changed 
to scratchpad, I never intended to post it that way, but it didn't 
really matter).

Your suggested tests are interesting and worth a try, but unless the 
ratios between the tests are very different I don't expect to learn 
anything new. It'll be slightly slower.. Matt, you got a chance to run 
it up? ;)

----- Original Message ----- 
From: "Marc H" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 11, 2009 10:38 AM
Subject: [TI994A] Practical application of the VDP throughput 
experiment...

> I understand now why you guys are getting seemingly fantastic numbers 
> but I think they are still a little misleading (read as: prove me 
> wrong)....
>
> The code you posted seems to write the same value to VDP memory over 
> and over and has been heavily weighted towards achieving high speed (I 
> realize that was the point.)
>
> Perhaps you could alter your routine to flash a table(just memory 
> contents is fine) in a loop that uses 1: MOV *R13+,*R12  VS 1 MOV 
> *R13+,@VDPWD And then in a loop that uses 8 of each variety. The MOV 
> R13,*R12 should not be used as it would require a second MOV to load 
> R13 initially there by negating any speed increase.
>
> I'm not trying to be a Prick in fact I do have a need for speed in one 
> of my bit-mapped projects and am very interested in your results.  I 
> understand the academic nature of your testing but I'd like to see a 
> practical application if you don't mind.
>

---

From: Marc Hull <[email-masked]>
Date: Wed, 11 Nov 2009 09:08:58 -0800 (PST)

Your right.  I didn't address the issue as to why.  I leave that for you smart guys.

I'm more interested in how much than how.  Makes me a bit of a leach I know but hey....why change now ;-)

Like I said I have an app that could use a little kick in the pants and this non intuitive addressing method just may be the ticket.  How come you didn't bring this up long ago mike ?? (ducking under my desk right now...)

--- On Wed, 11/11/09, Tursi <[email-masked]> wrote:

From: Tursi <[email-masked]>
Subject: Re: [TI994A] Practical application of the VDP throughput experiment...
To: [email-masked]
Date: Wednesday, November 11, 2009, 10:26 AM

  

issue.

really matter).

it up? ;)

----- Original Message ----- 

From: "Marc H" <marc.hull@sbcglobal .net>

To: <TI994A@yahoogroups. com>

experiment.. .

> I'll now get off my soap box and hopefully await your results (if I 

> haven't pissed you off too much ;-)

---

From: "Matthew" <[email-masked]>
Date: Wed, 11 Nov 2009 17:28:27 -0000

> Like I said I have an app that could use a little kick in the pants and this non intuitive addressing method just may be the ticket.  How come you didn't bring this up long ago mike ?? (ducking und…

Right now we are trying to determine:

1. if the 9900 can over-run the the 9918A in a stock 99/4A

2. the absolute most amount of data we can push to the 9918A in a given amount of time (currently a single frame at 16.6mS)

Once we know how much data we can push reliably to the 9918A and which method is absolutely the fastest, my plan was to then set up a few more tests to determine the best way to do other more practical operations like block moves, running from 8-bit memory, etc..

Things were going along well until this whole problem of symbolic addressing being more than twice as slow as register indirect.  Without understanding what is going on there, testing is just trial and error - which sucks IMHO.

Matthew

---

From: tursi <[email-masked]>
Date: Wed, 11 Nov 2009 12:08:39 -0800 (PST)

> Like I said I have an app that could use a little kick in the pants and this non intuitive addressing method just may be
> the ticket.  How come you didn't bring this up long ago mike ?? (ducking under my desk right now...)

My 9900 based missiles are waiting, ready for when you come out. They use 
the new addressing mode discovery so are capable of tracking /extremely/ 
fast moving objects. >:)