Subject: How about a little help....

From: "Marc H" <[email-masked]>
Date: Thu, 30 Sep 2010 12:28:18 -0000

All the academics and arguing aside could someone give me a practical example of how to set up the VDP registers for this half bit map mode ?  Code would help.... ;-)

---

From: "Tursi" <[email-masked]>
Date: Thu, 30 Sep 2010 10:33:01 -0700

> All the academics and arguing aside could someone give me a practical 
> example of how to set up the VDP registers for this half bit map mode ? 
> Code would help.... ;-)
>

That VDP Programmer's Guide document gives you suggested values to put into 
the VDP registers, so does Thierry's page.

As I'm fond of saying, there's no magic involved. Set the VDP registers as 
described, and you're done. The only difference between half-bitmap and 
normal bitmap is you only have one table of 256 characters.

"Academics and arguing" is pretty harsh - I didn't see any of that. At risk 
of being accused of things I didn't intend again, I'll drop out of this. But 
I will call out the register values for you.

VDP Register # - value - purpose (sample from VDP Programmer's Guide)
0 - >02 - select bitmap graphics mode
1 - >C2 - 16k, enabled, double-size sprites, you can set the interrupt and 
sprite bits as you like
2 - >0E - put the screen image table at >3800 (>400 * >E). Can put it 
anywhere free, but this works in full bitmap too.
3 - >9F - Color table at >2000, mask of >07FF for 256 chars (ok, a little 
magic here)
4 - >00 - Pattern table at >0000 - mask comes from Register 3
5 - >76 - Sprite table at >3B00 (>80 * >76). Can be put anywhere free.
6 - >03 - Sprite pattern table at >1800 (>800 * 3). Can be put anywhere free 
or overlap other pattern table as normal.
7 - >0F - white background color. Any value is fine.

Load a character set or some graphics at >0000, in the same format as 
graphics 0 or bitmap mode. The associated colors goes at >2000, just like in 
bitmap mode. Then write characters at >3800 as if you were in graphics 0 
mode. The only difference is every character can have a different color on 
every line, instead of groups of 8 characters sharing the same color. What 
you could try to see this is to load the standard character set at >0000, 
and set the color table to a repeating sequence of 
 >10,>20,>30,>40,>50,>60,>70,>80, then just write HELLO WORLD to the screen 
at >3800 -- every character will then be sort of a vertical rainbow. ;)

Note that IIRC, Classic99 does not do the masking correctly (it tries, I 
think it works sometimes, but some settings are way off), so I can't build 
you sample code right now. I think it worked with that rock runner game but 
I haven't tried it for a while. I haven't bothered fixing this due to lack 
of code that uses it, was waiting for the VDP rewrite.

---

From: Marc Hull <[email-masked]>
Date: Thu, 30 Sep 2010 11:10:20 -0700 (PDT)

No offense intended Mike.  Thread just took a bit of a disconcerting turn a while back with the documented/undocumented challenge/answer yada yada yada...

As far as the academics are concerned.  Theirty's site as well as any 
others tend to either quote from data sheets or speak in a manner that 
assumes the reader is fluent in the subject manner which is great for 
you guys who are versed in that sort of techno wizardry but leaves those
 of us who are not a bit high and dry.  I guess what I should have asked for is a bit of a lesson on the why's and where's.  I be sure to fully ask the question next time ;-)

 Your current reply is what I think I need with just a bit of 
clarification So I am sure of what I am doing.

Am I free to put the tables anywhere I wish ?  This factoid appears no where I can find.  Everyone uses examples with no explanation. And they all have the pattern table @ 0 and the color table @ >2000 (IIRC.)  I don't know if this is an integral part of the mode or  just people rehashing others examples.  That is the largest source of confusion on my part and perhaps others who may explore this mode.

Thanks Mike...

Marc

--- On Thu, 9/30/10, Tursi <[email-masked]> wrote:

From: Tursi <[email-masked]>
Subject: Re: [TI994A] How about a little help....
To: [email-masked]
Date: Thursday, September 30, 2010, 12:33 PM

  

sprite bits as you like

magic here)

---

From: "Tursi" <[email-masked]>
Date: Thu, 30 Sep 2010 11:29:06 -0700

> Am I free to put the tables anywhere I wish ?  This factoid appears no 
> where I can find.  Everyone uses examples with no explanation. And they 
> all have the pattern table @ 0 and the color table @ >2000 (IIRC.)  I 
> don't know if this is an integral part of the mode or  just people 
> rehashing others examples.  That is the largest source of confusion on my 
> part and perhaps others who may explore this mode.
>

This is nothing to do with "half-bitmap" mode, it's simply a fact of life in 
bitmap at all. Only one bit of the register is used to set the address of 
the pattern and color table. So you get a choice of >0000, or >2000 for each 
table.

---

From: "jhwhite_delphi" <[email-masked]>
Date: Sat, 02 Oct 2010 03:50:34 -0000

Marc,

Sorry I did not get to you sooner.  Here is what I posted on comp.sys.ti and Delphi TI Net in 1993, which Dan Eicher compiled in the TI Hardware Compendium, which is located at:

ftp://ftp.whtech.com/datasheets%20and%20manuals/Hardware/ti%20hardware%20compendium.txt

Jeff White
[email-masked]

40312 10SEP93-1251 Graphics
     bitmap mode explained again
     From: JHWHITE      To: ALL

In article <[email-masked]>, [email-masked]
(Sean McGranaghan) writes:
>
>       VDP Register    Value   Result
>       -------------   -----   -------------------------------------
>           r0          >02     Set Mode bit 3 for bitmaped mode
>       
>           r1          >E0     default value
>
>           r2          >06     Screen image table base address
>                               >06 * >400 = >1800
>
>           r3          >80     Color table base address
>                               >80 * >40 = >2000
>
>           r4          >00     Pattern descriptor table base address
>                               >00 * >800 = >0000
>
>           r5          >36     Sprite attribute list base address
>                               >36 * >80 = >1B00
>
>           r6          >07     Sprite descriptor table base address
>                               >07 * >800 = >3800
>
>           r7          >07     default value
>
>
>     All of this should lead to VDP memory set up as follows:
>
>       VDP Address     Table Name                      Length
>       -----------     ----------                      ------
>       >0000 - >17FF   Pattern descriptor table        >1800 bytes
>       >1800 - >1AFF   Screen image table              >300  bytes
>       >1B00 - >1B7F   Sprite attribute list           >80   bytes
>       >1B80 - >1FFF   free space                      >480  bytes
>       >2000 - >37FF   Color table                     >1800 bytes
>       >3800 - >3BFF   Sprite descriptor table         >400  bytes
>       >3C00 - >3FFF   free space                      >400  bytes

Sean, the E/A manual is wrong, but the 1 page addendum explains many errors
in it.  Included is the correction for bit-map mode register settings.

Pattern descriptor table:  at >0000-17FF,  r4 = >03
                           at >2000-37FF,  r4 = >07

Color table:               at >0000-17FF,  r3 = >7F
                           at >2000-37FF,  r3 = >FF

"Now why did TI do this?" you may ask.  The simple explanation is that the bits
in the registers correspond to video RAM address bits.  Bit 2 (bit 5 in TI's
big-endian numbering scheme) of r4 corresponds to the most significant bit of
the video RAM address.  Bit 7 (or TI's bit 0) of r3 corresponds to the most
significant bit of the video RAM address as well.

The value of the pattern descriptor table base address is the value in r4
of the meaningful bits shifted by 11 (or multiplied by 2048).  The color table
base address is the value in r3 of the meaningful bits shifted by 6 (or
multiplied by 64).

For bitmap mode, the meaningful bit of r4 gives a value of 0 or 4.  Multiply
by 2048 and you get 0 or 8192 (>0000 or >2000), respectively.  The meaningful
bit of r3 gives a value of 0 or 128.  Multiply by 64 and you get 0 or 8192
(>0000 or >2000), respectively.

Designing the TMS9918A (and V9938/V9958) this way simplifies the routing of the
register values to address lines on the die.  The other option would require
routing different bits of r3 and r4 as the most significant bit of the video
RAM address.

The "unused" bits of r3 and r4 less significant than the used bits should be
set to 1.  This is so that the address lines these less significant bits
correspond to do not have their values masked to 0.

When you put >00 into r4, you were making A13, A12, and A11 of the pattern
descriptor address always 0.  This meant when the VDP was fetching >0000-07FF,
it fetched the first 2048 bytes.  Also, when the VDP was fetching >0800-0FFF,
it was fetching >0000-07FF.  Likewise with >1000-17FF.

For the 9918A, the video address bits correspond to register bits as follows:

  r3 = A13 A12 A11 A10 A9 A8  A7  A6
  r4 =  0   0   0   0   0 A13 A12 A11

Now you can do some weird things if you know that when you set one of the
"unmeaningful" bits of r3 or r4 during bitmap mode to 0 you are in fact ANDing
the corresponding address lines when said registers are used for a display
fetch with 0, or effectively masking them to 0.  So, you can cut the color
table to 2048 bytes by setting A12 and A11 of r3 to 0, or putting the values
>1F or >9F into it depending on where you want the base address to be.

Using this undocumented functionality is what our good friend Eric Lafortune
did in "Rock Runner" to get great graphic effects.  I have also used this
functionality to write a 64-column terminal emulator.  With a full 6K pattern
descriptor table, and 2K color table, there is 8K of video RAM left.  This is
enough to hold 8 screen image tables which can be quickly flipped for a scroll
effect, with only the patterns for lines 7, 15, and 23 (new line) needing to
be re-drawn in the pattern descriptor table.

Of course, I could cut the color table down to 1K by masking an additional
address bit (A10) to 0.  In fact, I can cut it down to 64 bytes by making all
of A12 to A6 bits in r3 to 0.  Load all 64 bytes with the same two color code,
such as >1F, and the entire screen will be black and white.  However, just
defining those 64 bytes is actually just defining the colors for 8 pixel lines
of each 8 characters.

Isn't this all very interesting?  You can have a complete monochrome bitmap
display with 6K for patterns, 64 bytes for colors, and 768 bytes for pattern
position (screen image table).  With the fast scroll, I was using in my 64x24
column terminal emulator eight separate screen image tables which must be put
on 1K boundaries non-conflicting with pattern descriptor table or color table.

The pattern descriptor table is put at >0000-17FF by loading r4 with >03.  The
color table is put at >2000-203F by loading r3 with >80.  Two screen image
tables are located at >1800-1AFF (r2=>06) and >1C00-1EFF (r2=>07).  Six more
can be located at >2400-26FF (r2=>09), >2800-2AFF (r2=>0A), >2C00-2EFF (r2=>0B),
>3000-32FF (r2=>0C), >3400-36FF (r2=>0D), and >3800-3AFF (r2=>0E).

To do the scroll takes some fairly complex programming, but setting up the
eight screen image tables is a big and easy part of it.  The first screen
image table has >00-FF repeated three times.  The second screen image table
has >20-FF,>00-1F repeated three times.  The third screen image table has
>40-FF,>00-3F repeated three times.  See the pattern?  The eighth and last
screen image table has >E0-FF,>00-DF repeated three times.

The tricky part, and the part that slows the code down, is re-drawing the 8th,
16th, and 24th lines after a screen image table page flip.  This is because
the first line in the middle third of the screen must be scrolled to the
last line of the top third of the screen.  The first line of the last third
of the screen must be scrolled to the last line middle third of the screen.
The last line of the last third of the screen must be drawn over with the
new line.

Of course, I have written complex code to handle all this special scrolling.
The 64 columns looks quite good with the right font.  There is sufficient
memory left of the 16K video RAM for disk I/O buffers and limited sprites.  A
TE can do without sprites (none in text mode TE's).  There would be 256 bytes
after each of the first seven alternate screen image tables.  After the color
table would be 960 contiguous bytes.  After the eighth alternate screen image
table would be 1280 contiguous bytes.  A CALL FILES(2) equivalent would have
room in that 1280 bytes to handle disk I/O.

Jeff White    

p.s.: I typed this online in the VAX/VMS line editor, so any mistakes are not
my fault.  :^)