Subject: TMS9918 demo

From: "killroy732000" <[email-masked]>
Date: Thu, 05 Nov 2009 17:23:12 -0000

Check out the below MSX1 demo:
http://www.youtube.com/watch?v=rKqqOcTFVm0

It shows what our TMS9918 is capable of ...

I like the part at 2:05 and 3:07   ;-)

Filip

---

From: Owen Brand <[email-masked]>
Date: Thu, 5 Nov 2009 12:34:33 -0500

Man...  That's amazing.  The video elements are incredible.  That  
music... Was that done on a C64 or something?  The variations of tones  
and frequencies are amazing!  :)

Owen Brand
**Oprysoft**
Opry99er.com

---

From: "killroy732000" <[email-masked]>
Date: Thu, 05 Nov 2009 18:10:06 -0000

Yeah, it sure rocks.

Sound is done on the MSX1 itself by a General Instruments AY-3-8910 sound chip.
I believe it has similar capabilities as the sound chip
in our TI-99/4A.

I think that Tursi's EPGSMOD player should be able to pull something 
off like that on the TI-99/4A as well :-)

Filip

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> vooren@...> wrote:

---

From: "Matthew" <[email-masked]>
Date: Thu, 05 Nov 2009 18:32:24 -0000

Wow, I had not seen that one before.  It is definitely impressive!  It sure would be nice to get some cross interest in the TI from the MSX and Coleco crowds.  It always amazes me to see what other computer systems did with the graphics compared to the TI.  Sad really.  All the TI software is about as amateur and unimpressive looking as it comes, and since TI wanted to control all the software, they set the standard so-to-speak for how things should look on the TI.  Games and 3rd party developers are what really drive innovation of a computer system, and the TI didn't have much of that compared to the other systems of the day.

Heh, makes me think about that embarrassing "Sound and Graphics Demo" cart that TI produced.  Imagine if they had actually produced something like this BOLD video...

Matthew

---

From: "killroy732000" <[email-masked]>
Date: Thu, 05 Nov 2009 18:52:13 -0000

Well the demo is made with todays technology. 
Don't think they could have done this 25 years ago.

I'm pretty sure that 95% of what you see in the demo is pre-calculated on the PC. 

Ofcourse you are right as far as TI is concerned. We only had a few
fine game titles back in the days. A lot was just pure crap.
(Sorry just had to say this).

But it is never too late to start doing our own demos.

I consider Karstens' demos as the first step in the that direction ;-)

Cheers
Filip

--- In [email-masked], "Matthew" <matthew@...> wrote:
> --- In [email-masked], "killroy732000" <filip.van-vooren@> wrote:
> >

---

From: "Tursi" <[email-masked]>
Date: Thu, 5 Nov 2009 14:14:27 -0500

> It shows what our TMS9918 is capable of ...

Very impressive! Was hard to believe it was the 9918A!

I found this page where the fans and creators talk about it (and it 
links to their own page): 
http://www.msx.org/Bold-MSX-demo.newspost5271.html

---

From: Owen Brand <[email-masked]>
Date: Thu, 5 Nov 2009 14:20:35 -0500

I bet we could get some good use out of a MSX support system in an  
I.D.Environment... :)  That might help us get a little further  
along.  :)

Owen Brand
**Oprysoft**
Opry99er.com

On Nov 5, 2009, at 1:52 PM, "killroy732000" <[email-masked]>  
wrote:

> > Wow, I had not seen that one before. It is definitely impressive!  
> It sure would be nice to get some cross interest in the TI from the  
> MSX and Coleco crowds. It always amazes me to see what other  
> computer systems did with the graphics compared to the TI. Sad  
> really. All the TI software is about as amateur and unimpressive  
> looking as it comes, and since TI wanted to control all the  
> software, they set the standard so-to-speak for how things should  
> look on the TI. Games and 3rd party developers are what really drive  
> innovation of a computer system, and the TI didn't have much of that  
> compared to the other systems of the day.
> >
> > Heh, makes me think about that embarrassing "Sound and Graphics  
> Demo" cart that TI produced. Imagine if they had actually produced  
> something like this BOLD video...
> >
> > Matthew
> >
> >

---

From: "Tursi" <[email-masked]>
Date: Thu, 5 Nov 2009 14:22:19 -0500

> I'm pretty sure that 95% of what you see in the demo is pre-calculated 

The authors claim it's not, surprisingly! :) Demogroups pride themselves 
on not using pre-calculated stuff, when it's possible. A top notch 
externally calculated demo beside a not-bad calculated-on-the-fly demo 
will usually lose if the judges know. ;)

The MSX sound chip is similar to the TI's, I've ported music and sounds 
from it before. It does have a simple envelope shaper, but that can be 
faked with software.

I used to think that the Z80 in the Coleco and MSX led to a faster 
system than our 9900... and while that may be true for memory moves in 
RAM, my recent porting work to the Coleco has me thinking we're pretty 
competitive after all (especially when code compiled for old unoptimized 
c99 for the 9900 runs about the same speed as code compiled with the 
newest fully-optimizing SDCC for the Z80... but comparing machines by C 
code is a little questionable. Still -- comparable!) And of course the 
VDP speed is the same across the board.

> I consider Karstens' demos as the first step in the that direction ;-)

Agreed! He has done some nice work and given me plenty of little ideas. 
;)

---

From: Keith Bergman <[email-masked]>
Date: Thu, 5 Nov 2009 14:53:34 -0500

To be totally fair, that sound and graphics demo cartridge was made in what,
1979?

I've said before in other threads that I think, if the 99/4a had hung on in
the marketplace for one more year, and some of the third-party houses that
were reluctantly moving toward supporting it (Broderbund, Epyx, etc) had
gotten in there and started learning, we'd have had a whole lot more
knowledge earlier, and a much higher standard for games and graphics.   Look
at the last stuff to come out (or get written): Tutankham, Fathom, Q*Bert,
even Microsurgeon... those games' look is a whole 'nother level from the
standard TI software.  Then you have stuff like Slymoids and Sneggit, where
whoever was doing the graphics either just didn't care, or had drawing
skills that made mine look good... :/

---

From: mark wills <[email-masked]>
Date: Thu, 5 Nov 2009 20:07:28 -0800 (PST)

<snip>
</snip>

I think the z80 itself is a faster chip overall though, no? And it's not crippled by wait-states to the same degree as the 9900 16/8 bit multiplexer debacle... In fact, I would imagine that the Z80 in the MSX can run *mostly* without any wait-states at all, since it doesn't have to share a bus with the graphics chip. Like the TI, there would be two independant address and data busses, one each for CPU and VDP, so they can both run full chat. Of course, talking to external IO would induce waits, but general processing is possibly wait-state free. This leads me to conclude that there is probably more processing time available on the MSX between video frames.

I stress though, I'm spewing conjecture here... I have *no* MSX knowledge at all ;-)

Mark

---

From: "Tursi" <[email-masked]>
Date: Thu, 5 Nov 2009 23:50:39 -0500

>I think the z80 itself is a faster chip overall though, no? And it's 
>not crippled by wait-states to the same degree as the 9900
>16/8 bit multiplexer debacle... In fact, I would imagine that the Z80 
>in the MSX can run *mostly* without any wait-states
>at all, since it doesn't have to share a bus with the graphics chip. 
>Like the TI, there would be two independant address and
>data busses, one each for CPU and VDP, so they can both run full chat. 
>Of course, talking to external IO would induce
>waits, but general processing is possibly wait-state free. This leads 
>me to conclude that there is probably more processing
>time available on the MSX between video frames.

My point was, I used to think that too, now I'm not so sure. Conjecture 
isn't matching observed evidence.

Conjecture is boring. That's the old list way! Research or nothing! I 
have evidence that says the performance of the machines is comparable. 
Now someone needs to look up why that's right or wrong. ;)

---

From: "Matthew" <[email-masked]>
Date: Fri, 06 Nov 2009 16:01:45 -0000

> Now someone needs to look up why that's right or wrong. ;)

I have evidence that the 9918A can take data as fast as the 9900 can push it (the way it is configured in the 99/4A anyway).  So the NOP instructions in all the VDP routines I have seen are unnecessary and a waste of time (no pun intended).

So, if we can push data to the 9918A as fast as it can take it, then we should be able to do some of the same things as in that BOLD demo because no matter how fast the Z80 in the MSX might be, it cannot send data to the 9918A any faster than we can.  *Unless* the MSX has direct access to the VDP RAM?

Matthew

---

From: "Tursi" <[email-masked]>
Date: Fri, 6 Nov 2009 12:26:13 -0500

The Coleco and the MSX have the same video timing limits we do.

> I have evidence that the 9918A can take data as fast as the 9900 can 
> push it (the way it is configured in the 99/4A anyway).  So the NOP 
> instructions in all the VDP routines I have seen are unnecessary and a 
> waste of time (no pun intended).
>

I have code that proves we can push data to the VDP faster than it can 
take it with the 9900. It does take a bit of doing, but it can be done.

Interestingly, I just revisited this concept this week, as I remembered 
the first time that thought came up.

Remember that the way the VDP works is a sort of a "best effort" 
approach. When you write data to the data port, the VDP will copy that 
data to VRAM when it's ready to, and not before. If the CPU writes a new 
piece of data before the VDP does the move, there is no error, 
interrupt, or status bit to check, the old data is replaced and when the 
VDP comes to get it, the new data is moved instead of the old data.

The trick is knowing what's going on, and that means knowing when the 
VDP has a CPU access window.

The datasheet gives us good information on the timing needed to 
communicate successfully with the VDP.

First, addresses. The datasheet does not mention any delays needed when 
writing the address to the VDP! Have not verified this with the 
Coleco/MSX guys or tested on hardware yet, but this suggests that it's 
fine to write to the address port at full speed. (There must be an upper 
limit, but with our hardware, anyway).

After an address is written, the VDP needs 2uS to retrieve the data.

Between reads, the VDP needs 8uS to get the next piece of data.

And now, the variable part - the VDP only provides a CPU access window 
from every 0 to 6uS.

So the data says that it's fine to write the address and even read the 
first piece of data immediately on our hardware, because we will take 
longer than 2uS anyway.

In the vertical blank, and if the blanking bit has disabled the screen, 
there is no wait for a CPU access window - so you can access VRAM at top 
speed. Between reads you need to wait 8uS to guarantee success. If I did 
my math right, our fastest instruction is 8 cycles, which is 2.6uS. 12 
cycles, a more common operation, should be 4uS. Fast code running in 
zero wait-state memory (scratchpad or modified) may be able to send data 
faster than every 8uS (indeed this was what I achieved, managing a write 
roughly every 5uS). This will fail.

When running the worst case, bitmap mode with sprites, during the active 
display area you have 6uS between CPU access windows. This pushes you up 
to 14uS between reads, because you don't know exactly when the window 
occurs (so you just have to leave enough time for it to have happened). 
In this case, even code in slow memory expansion can start pushing the 
limits.

I would like some better understanding of the timing on the 9900/memory 
side. I think I have it and the numbers match experimentation, but still 
not comfortable talking it.

At any rate, the idea is, if you know whether you are in blank or the 
screen is turned off, you can do much faster access. Also, either 
multicolor mode or text mode (need to look up which) has only a 2uS wait 
for CPU access windows, so there you can work more quickly as well.

I know I mixed reads and writes above -- my test code was testing writes 
and my datasheet research was studying reads, but I believe the numbers 
are comparable.

Essentially, with a bit of 9900 cycle counting, and knowing in your code 
whether it's safe to do fast access or not, you could write a set of 
tuned routines to get maximum performance. This is exactly what the MSX 
and Coleco guys do. (The Coleco library is open source if anyone wants 
to look at that code - 
http://www.colecovision.eu/ColecoVision/development/libcv.shtml)

---

From: "Matthew" <[email-masked]>
Date: Fri, 06 Nov 2009 18:29:50 -0000

> http://www.colecovision.eu/ColecoVision/development/libcv.shtml)

Yes, what you did (cycle counting) is exactly what I also did.  Any access to the 8-bit memory will almost always take longer than the maximum delay required by the 9918A.  Only when we get into running code from the 256 bytes of scratch RAM do we potentially have a problem.  And then, if you need to write a screen worth of data, unless you are generating the data, you will need a source buffer to copy from which will have to be in 8-bit memory.

However, something else you have to consider is that you have instruction fetches in addition to fetching data to write to the VDP.  So even in a tight loop in scratch RAM you have 4 to 6us just fetching an decoding the movb instruction, then you have the fetch of the data itself, plus the write.  I'd very curious to see the code you have that will saturate the 9918A.

The emulator I'm writing works at the mirco instruction level, so I spent a lot of time looking at the instruction timings and the factors that affect memory read and write timings.  When I was deep in the development I realized the maximum values of the VDP were almost always less than the timings of the instructions needed to communicate with the VDP (generally mov and movb).

I think I'll do some VDP hacking on my real TI tonight to see if I can push data to the VDP faster than it can take it.

Matthew

---

From: tursi <[email-masked]>
Date: Fri, 6 Nov 2009 10:54:42 -0800 (PST)

> However, something else you have to consider is that you have 
> instruction fetches in addition to fetching data to write to the VDP. 
> So even in a tight loop in scratch RAM you have 4 to 6us just fetching 
> an decoding the movb instruction, then you have the fetch of the data 
> itself, plus the write.  I'd very curious to see the code you have that 
> will saturate the 9918A.

Unfortunately for this, my code was neither theorhetical, paper based, 
cycle counting nor emulated - on real hardware I got a throughput of 
approximately 5uS per write - copying from 8-bit memory to the VDP. The 
math worked out to 4.6uS, the offset due to looping.

I did the code first. I then had to spend the time to understand how I got 
there. The cycle counting is the afterthought. You can check my math, the 
code got 3600 bytes from 8 bit memory to the VDP data port in one frame 
(1/60th of a second). This was just a burst test, it was not paying 
attention to whether the VDP accepted the data.

I don't quite see your figures -- how do you figure that it takes 12-18 
cycles to fetch and decode an instruction from scratchpad RAM? 4-6uS 
sounds high.

> I think I'll do some VDP hacking on my real TI tonight to see if I can 
> push data to the VDP faster than it can take it.

Check my test thread at 99er.net 
(http://www.99er.net/cgi-bin/ikonboard/ikonboard.cgi?act=ST;f=3;t=23) -- 
the whole reason I posted that back in the day was to have someone confirm 
or deny my results experimentally, instead people just talked about their 
theories. :) I'd love to see hard evidence one way or the other.

---

From: "Matthew" <[email-masked]>
Date: Fri, 06 Nov 2009 19:54:45 -0000

> math worked out to 4.6uS, the offset due to looping.

Yeah, well, I've seen your 99/4A console...  ;-)  I assume you were running on an unmodified console?

> cycles to fetch and decode an instruction from scratchpad RAM? 4-6uS 

I can't remember for sure right now, I'll have to wait until I get home tonight and look some things up so I can talk somewhat intelligently.

> theories. :) I'd love to see hard evidence one way or the other.

Heh, I remember that thread.  I'll run some real unmodified hardware tests this weekend.

Matthew

---

From: tursi <[email-masked]>
Date: Fri, 6 Nov 2009 13:51:09 -0800 (PST)

> Yeah, well, I've seen your 99/4A console...  ;-)  I assume you were running on an unmodified console?

Hehe, I told you, I did that three days before the TI Faire. :)

Yes, completely unmodified console, code developed in Editor/Assembler 
with floppy disk. ;)

> Heh, I remember that thread.  I'll run some real unmodified hardware tests this weekend.

Please do! I'd be happy to see someone else's results.

---

From: mark wills <[email-masked]>
Date: Fri, 6 Nov 2009 20:44:12 -0800 (PST)

I think you are right, you can push data to the VDP as fast as you like, you just need a small delay (NOP) between setting up the VDP address for the first time, and sending the first byte of data.

I must admit I've never tried omitting the NOP between address and data. I work in an emulation environment so it would always work, but I worry it wouldn't work on real hardware. For example:

MOVB R1,@VDPWA
SWPB R1
MOVB R1,@VDPWA
NOP
MOVB R2,@VDPWD

Now, if you remove the NOP, you *might* (conjecture again!) find this works on USA consoles, but not on European. Why? The NTSC console VDPs are clocked faster than the PAL ones...

Mark.

________________________________
From: Matthew <[email-masked]>
To: [email-masked]
Sent: Fri, 6 November, 2009 17:01:45
Subject: [TI994A] Re: TMS9918 demo

Matthew

---

From: "Tursi" <[email-masked]>
Date: Sat, 7 Nov 2009 03:20:53 -0500

>I must admit I've never tried omitting the NOP between address and 
>data. I work in an emulation environment so it would >always work, but 
>I worry it wouldn't work on real hardware. For example:
>MOVB R1,@VDPWA
>SWPB R1
>MOVB R1,@VDPWA
>NOP
>MOVB R2,@VDPWD
>Now, if you remove the NOP, you *might* (conjecture again!) find this 
>works on USA consoles, but not on European. >Why? The NTSC console VDPs 
>are clocked faster than the PAL ones...

The datasheet tells use the VDP only needs 2 microseconds after setting 
the address to get the first byte. That means in your example there, 
none of the delays are potentially necessary. Even though E/A tells us 
this, the 9918 datasheet says we don't. So we're all more or less in 
agreement there (more or less because we haven't proven it yet).

When reading subsequent bytes, the datasheet tells us that more time is 
needed. That's where I suspect there may be issues.

I guess this is something we could automatically test, though.. when I 
finish my emulator updates, if Marc hasn't beaten me to it, I'll try 
some test programs too. A read test could simply be to "carefully" write 
incrementing values to VRAM, then as fast as you can, read them back, 
then see if you dropped any.

The opposite test is valuable, too -- write data as fast as you can, 
then "carefully" read it back and see if you dropped any.

Naturally in both tests, to make the worst case, you need to enable 
bitmap mode and a full sprite table. Doesn't have to be any meaningful 
data in either of those, as long as they aren't disabled. If that passes 
all tests, we don't have to go any further.

What I find, though, is on the TI console you have to be really careful 
for performance, because it's really easy to write slow code. Since we 
are testing this way, we should test worst case - tightest possible code 
in scratchpad (which is why I referenced my thread at 99er.net, I 
haven't seen faster anywhere). If that succeeds, then we know we're 
pretty safe just about anywhere, potentially excluding overclocked 
consoles. Even consoles like mine with RAM on the 16-bit bus will be 
fine, since that RAM is the same speed as scratchpad.

We know that any instruction /between/ accesses to the VDP is enough 
time for it to be ready, so we're talking pretty tight loops here. Once 
we know the true limits, of course, we can put together a 
performance-based library for VDP access. :)

---

From: "Matthew" <[email-masked]>
Date: Sun, 08 Nov 2009 17:00:13 -0000

> performance-based library for VDP access. :)

Okay, I finally got my PC to TI transfer issues worked out and I compiled and ran your (Tursi) test code from the 99er forum thread.  I have only run 1 test so far and after about 20 or 30 seconds of runtime the screen displayed 610.  I assume that is a hex value based on the quick review of the display code.  I'm not quite sure what that number is telling me though?

I was thinking of writing a different test program based on this original code, but doing a few other things to better automate finding the failure point.

1. Start with an initial count of like 512 (decimal)
2. Display count
3. Do a "careful" initialization of the VDP memory to be written to
4. Wait for vsync and write as fast as possible
5. Test vsync and if not set, read back "carefully" to ensure all data was written correctly
6. Display pass / fail based on vsync and valid data
7. If test was 100% successful, increase count, jump to step 2

The program stops at the point the test fails.  I'd like to test a few different ways in the optimized write loop, both with the code running from scratchpad RAM as well as from 8-bit RAM:

1. write from scratchpad
2. write from 8-bit RAM
3. indexed and symbolic variations on both types of writes
4. word and byte variations of both types of writes
5. single instruction in a loop vs. unrolling 4 and 8 times

Thoughts?

Matthew

---

From: Barry Boone <[email-masked]>
Date: Sun, 8 Nov 2009 12:24:53 -0500

One thing to remember... I recall playing with this pretty extensively and while the stock speed 9900 won't generally run quite fast enough to overflow the VDP buffer, an overclocked 9900 will.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Matthew
Sent: Sunday, November 08, 2009 11:00 AM
To: [email-masked]
Subject: [TI994A] Re: TMS9918 demo

1. write from scratchpad
2. write from 8-bit RAM

Thoughts?

Matthew

---

From: "Matthew" <[email-masked]>
Date: Sun, 08 Nov 2009 17:52:22 -0000

> One thing to remember... I recall playing with this pretty extensively and while the stock speed 9900 won't generally run quite fast enough to overflow the VDP buffer, an overclocked 9900 will.

That is true, however, even TI's routines will eventually fail if the CPU is overclocked enough.  While personally I like messing with the hardware and doing things like overclocking, the number of systems out there that are actually overclocked is probably *very* small, and those people know they have made mods that might make their computer unstable.

We can only do our tests based on unmodified systems since that is what most people have and what the emulators will try to replicate first.  I also like seeing how far we can push the original equipment.

Matthew

---

From: "Tursi" <[email-masked]>
Date: Mon, 9 Nov 2009 01:26:42 -0500

> Okay, I finally got my PC to TI transfer issues worked out and I 
> compiled and ran your (Tursi) test code from the 99er forum thread.  I 
> have only run 1 test so far and after about 20 or 30 seconds of 
> runtime the screen displayed 610.  I assume that is a hex value based 
> on the quick review of the display code.  I'm not quite sure what that 
> number is telling me though?
>

I had to look again, heh! That's the number of bytes the program managed 
to write to the VDP address in one frame (ie: starting when the VDP 
marks a frame, and finishing BEFORE the next frame is marked). So 0x610 
is 1552 bytes in one frame.

Basically, the program starts with a count that is expected to be too 
high. Then it starts to loop - first, it waits for the VDP to set the 
end of frame bit in the status register. When this happens, the program 
starts writing as fast as it can for the number of loops indicated. When 
the copy is finished, it checks the VDP again. If the status bit is set, 
then we know the copy took longer than 1 frame (it could have been set a 
long time ago for all we know! We don't check during the copy loop 
because that would slow it down!) So if it took longer, we decrement the 
loop count, then go back and try again. We repeat until we can complete 
the copy before the VDP marks the frame complete. Then we display the 
number of bytes we managed to push.

Of course, you are probably running the slow version of the code on the 
first page of the thread. If you make the change I mention a couple 
messages further down:

>When I replaced MOV *R13,@VDPWD with MOV *R13,*R12 (with R12 loaded 
>with VDPWD), performance nearly doubled!

You should push over 3600 bytes per frame to the VDP port. Which, 
according to most of the information I can find online, is going to be 
too fast.

But these tests were aimed at getting the CPU the push to the VDP as 
fast as possible, and didn't test whether the VDP accepts the data. 
That's the next phase!

Your suggested programs are definately the next correct step, I think. 
:)

---

From: "Matthew" <[email-masked]>
Date: Mon, 09 Nov 2009 12:59:31 -0000

> Your suggested programs are definately the next correct step, I think. 

That's what I thought it was doing, but I could not figure out how an initial count of 0x200 (512) could fail.  But as I was reading your post I remembered that you multiply the count by 8 (or however many times the critical loop is unrolled).  That makes sense now, I should have realized that sooner.

I did see the variation in the later post about using mov instead of movb, I just didn't have time to modify it yet. ;-)  Soon!  Today I hope.

Matthew

---

From: "Tursi" <[email-masked]>
Date: Mon, 9 Nov 2009 11:25:39 -0500

> I did see the variation in the later post about using mov instead of 
> movb, I just didn't have time to modify it yet. ;-)  Soon!  Today I 
> hope.
>

As far as I can tell, MOV versus MOVB should make no difference to the 
VDP, the way it's wired, instruction timings, etc, all seems to work out 
the same. The important change in that comment is to replace the 
absolute address (@VDPWD) with a register indirect address (*R12).

---

From: "Matthew" <[email-masked]>
Date: Tue, 10 Nov 2009 21:44:36 -0000

> absolute address (@VDPWD) with a register indirect address (*R12).

Okay, here my initial numbers.  I ran 3 versions of the program (VDP1, VDP2, VDP3) 5 times each and took an average.  The second two versions have R12 loaded with the VDPWD address.

VDPWD >8C00
LI R12,VDPWD

MOV *R13,@VDPWD
VDP1: 1576 1576 1584 1608 1608 = 1590

MOV *R13,*R12
VDP2: 3728 3728 3768 3840 3856 = 3784 2.37x (237.98%) faster than VDP1

MOV R13,*R12
VDP3: 3896 3904 3920 3928 3968 = 3923 0.03x (  3.60%) faster than VDP2

What I want to know is, why is the indirect addressing so much faster than the symbolic (direct) access?  The datasheet indicates that the only difference should be about 4 clock cycles per instruction:

 14   +4   +8
MOV *R13,>8C00

 14   +4   +4
MOV *R13,*R12

How do we get such a huge discrepancy?  Writing to the VDP aside, this is a big deal as it greatly affects the ability to write an accurate emulator.  According to the 9900 datasheet, the time difference between VDP1 and VDP2 should be similar to the difference between VDP2 and VDP3.

Matthew

---

From: mark wills <[email-masked]>
Date: Tue, 10 Nov 2009 23:05:43 -0800 (PST)

<snip>
Okay, here my initial numbers. I ran 3 versions of the program (VDP1,
VDP2, VDP3) 5 times each and took an average. The second two versions
have R12 loaded with the VDPWD address.

VDPWD >8C00
LI R12,VDPWD

MOV *R13,@VDPWD

MOV *R13,*R12

MOV R13,*R12

What I want to know is, why is the indirect addressing so much faster
than the symbolic (direct) access? The datasheet indicates that the
only difference should be about 4 clock cycles per instruction:
</snip>

Ok, do we need to start thinking about wait-states? How does the "console" interact with the processor to inject wait-states, and under what circumstances?

I am wondering if symbolic mode addressing is triggering the wait-state generator, while other address modes do not. Having said that, I can't see how the wait-state generator could differentiate. Is there an IAQ (instruction aquisition) line on the 9900, so that external hardware knows when an instruction is being fetched (and conversely, knows when DATA is being fetched)?

Just to be clear Matthew, EVERYTHING in your program operates inside the 256 byte RAM yes?

It is very strange, and very interesting!

Mark

---

From: "Tursi" <[email-masked]>
Date: Wed, 11 Nov 2009 02:13:25 -0500

>Ok, do we need to start thinking about wait-states? How does the 
>"console" interact with the processor to inject wait->states, and under 
>what circumstances?

Go have a read of Thierry's website, the page on removing wait states. 
He goes into extreme detail.

To summarize, wait states should only be occuring on the write to the 
VDP. It's entirely based on the address bus and has no idea what 
instruction the CPU is executing.

We don't really need to guess our way through this. Give me a little 
time till the weekend and I'll sniff the busses and see if I can see it. 
:)

---

From: "Matthew" <[email-masked]>
Date: Wed, 11 Nov 2009 14:35:10 -0000

> time till the weekend and I'll sniff the busses and see if I can see it. 

Awe, come one, what fun would that be to not try and guess with wild ideas and theories??  :-)

I can't wait to see what you come up with via the analyzer!

Matthew

---

From: "Matthew" <[email-masked]>
Date: Wed, 11 Nov 2009 14:37:21 -0000

> It is very strange, and very interesting!

I'm using Tursi's code as posted here:

http://www.99er.net/cgi-bin/ikonboard/ikonboard.cgi?act=ST;f=3;t=23

You should read it over in case we missed something.  But unless the assembler or linker has a bug, the critical loop code and workspace are all in the 16-bit scratch pad RAM.

Matthew