Jump to content
IGNORED

TMS9918 family VDP Programmer's Guide


intvnut

Recommended Posts

I have scanned the first 70 pages of Texas Instruments' SPPU004: Video Display Processors Programmer's Guide. This is everything up through Appendix D.

 

Omitted are Appendix E and Appendix F. Appendix E is about 26 pages of example programs written in 4 different assembly languages (6502, 8088, TMS7000, TMS9995). Appendix F is a sample font.

 

Find the scans here. I've also put a zip file here. I scanned this at 300dpi, so it isn't tiny. I did do some cleanup work too, so it should be fairly clean and easy to read.

 

Enjoy.

 

(Mods: If there's a better place to put this, please feel free to move my post. I'm rather a n00b on this site. :-)

Edited by intvnut
Link to comment
Share on other sites

I have scanned the first 70 pages of Texas Instruments' SPPU004: Video Display Processors Programmer's Guide. This is everything up through Appendix D.

 

Omitted are Appendix E and Appendix F. Appendix E is about 26 pages of example programs written in 4 different assembly languages (6502, 8088, TMS7000, TMS9995). Appendix F is a sample font.

 

Find the scans here. I've also put a zip file here. I scanned this at 300dpi, so it isn't tiny. I did do some cleanup work too, so it should be fairly clean and easy to read.

 

Enjoy.

 

(Mods: If there's a better place to put this, please feel free to move my post. I'm rather a n00b on this site. :-)

 

 

Fantastic!

 

Thanks a lot for this. I'll have to add "write a game for the Colecovision" to my bucket list. Too bad they don't have any z80a code examples.

Link to comment
Share on other sites

I have scanned the first 70 pages of Texas Instruments' SPPU004: Video Display Processors Programmer's Guide. This is everything up through Appendix D.

 

Omitted are Appendix E and Appendix F. Appendix E is about 26 pages of example programs written in 4 different assembly languages (6502, 8088, TMS7000, TMS9995). Appendix F is a sample font.

 

Find the scans here. I've also put a zip file here. I scanned this at 300dpi, so it isn't tiny. I did do some cleanup work too, so it should be fairly clean and easy to read.

 

Enjoy.

 

(Mods: If there's a better place to put this, please feel free to move my post. I'm rather a n00b on this site. :-)

Absolutely awesome, thanks!

 

If you'd like, I can OCR these images and convert them to a single PDF document with searchable text in it, which may prove helpful to some people. Any interest in me doing this?

Link to comment
Share on other sites

Thanks a lot for this. I'll have to add "write a game for the Colecovision" to my bucket list. Too bad they don't have any z80a code examples.

 

While they aren't a model of clarity, these three pages of section 4--1, 2, 3--do at least provide a high level description of what to do.

 

The main thing to keep in mind is you're accessing the VDP's 16K of RAM via a very tiny memory window. You have four different things you can do, and there's a careful dance of reads and writes to the two locations in that memory window to make it work. The four operations of interest are:

 

  1. Write a control register
  2. Read a control register
  3. Write to VRAM
  4. Read from VRAM

The three pages I linked give the steps involved in each.

 

Some day it might be fun for me to learn Z-80 and write a Coleco game. It would be fun to come back home to the VDP and really put it through its paces. I don't own a CV though, and I've got a lot invested in my Intellivision home brew pipeline at the moment. :-)

 

(I say "come back home to the VDP" because I first learned assembly language on a TI-99/4A, and programmed the VDP in TMS9900 assembly directly. Fun days. Didn't do a whole lot with it as I only had 768 bytes of memory to hold my programs in. Can't fit much of a game in that.)

Edited by intvnut
Link to comment
Share on other sites

If you'd like, I can OCR these images and convert them to a single PDF document with searchable text in it, which may prove helpful to some people. Any interest in me doing this?

 

If you do, would you mind terribly sending me a copy for my own archives? Also, if there's interest in scanning the code examples and the sample font, please let me know. I might get around to it this weekend if there's interest.

Link to comment
Share on other sites

If you'd like, I can OCR these images and convert them to a single PDF document with searchable text in it, which may prove helpful to some people. Any interest in me doing this?

 

If you do, would you mind terribly sending me a copy for my own archives? Also, if there's interest in scanning the code examples and the sample font, please let me know. I might get around to it this weekend if there's interest.

 

Not at all. Heck, the main effort is scanning the stuff in to begin with! I'll let you know when I'm done with it.

Link to comment
Share on other sites

The four operations of interest are:

 

  1. Write a control register
  2. Read a control register
  3. Write to VRAM
  4. Read from VRAM

 

I would have described the operations as:

  1. Set an address for reading
  2. Set an address for writing (control register or VRAM)
  3. Write data to previously-set address (or byte after last one written)
  4. Read from previously-set address (or byte after last one read)
  5. Read status

 

Reading or writing the address following the last address read/written will take about 1/2 to 1/3 the time of reading or writing an arbitrary address, so it makes sense to recognize the 'address set' operations as distinct.

Link to comment
Share on other sites

The four operations of interest are:

 

  1. Write a control register
  2. Read a control register
  3. Write to VRAM
  4. Read from VRAM

 

I would have described the operations as:

  1. Set an address for reading
  2. Set an address for writing (control register or VRAM)
  3. Write data to previously-set address (or byte after last one written)
  4. Read from previously-set address (or byte after last one read)
  5. Read status

 

Reading or writing the address following the last address read/written will take about 1/2 to 1/3 the time of reading or writing an arbitrary address, so it makes sense to recognize the 'address set' operations as distinct.

 

Fair enough. I was just breaking it down into the same four operations as the VDP Programmer's Guide does.

 

Setting a R/W address is pretty expensive relative to the actual access unless you're moving a a linear block and can rely on the auto-increment mode. I don't know how much CPU addressable RAM the CV has, but it would seem to me this argues for shadowing data structures that tend to get accessed sparsely when updated and which see lots of read-modify-write type behavior on individual fields of a structure. (I'm thinking sprite coordinates, for example.) Doing a block copy of an updated structure, even if some of the fields haven't changed, can be faster than doing "smart" accesses, updating only the individual bytes that need it.

 

I do something similar with the STIC registers on the Intellivision. There, it's much more necessary, since they're only accessible during the vertical retrace interval anyway.

Link to comment
Share on other sites

If you'd like, I can OCR these images and convert them to a single PDF document with searchable text in it, which may prove helpful to some people. Any interest in me doing this?

 

If you do, would you mind terribly sending me a copy for my own archives? Also, if there's interest in scanning the code examples and the sample font, please let me know. I might get around to it this weekend if there's interest.

 

Not at all. Heck, the main effort is scanning the stuff in to begin with! I'll let you know when I'm done with it.

 

intvnut, here's the OCR'd PDF of the guide thus far: RapidShare of VDP Guide PDF

 

Please keep in mind that this was run through an OCR engine, which while pretty accurate, isn't going to capture every word 100% correctly. I did a brief quality control check on it, and it should be good, though. The PDF is fully searchable, and all text is selectable.

 

If you decide to scan the other appendices, I'll toss up another version of the PDF.

 

Thanks again!

Link to comment
Share on other sites

The four operations of interest are:

 

  1. Write a control register
  2. Read a control register
  3. Write to VRAM
  4. Read from VRAM

 

I would have described the operations as:

  1. Set an address for reading
  2. Set an address for writing (control register or VRAM)
  3. Write data to previously-set address (or byte after last one written)
  4. Read from previously-set address (or byte after last one read)
  5. Read status

 

Reading or writing the address following the last address read/written will take about 1/2 to 1/3 the time of reading or writing an arbitrary address, so it makes sense to recognize the 'address set' operations as distinct.

 

Fair enough. I was just breaking it down into the same four operations as the VDP Programmer's Guide does.

 

Setting a R/W address is pretty expensive relative to the actual access unless you're moving a a linear block and can rely on the auto-increment mode. I don't know how much CPU addressable RAM the CV has, but it would seem to me this argues for shadowing data structures that tend to get accessed sparsely when updated and which see lots of read-modify-write type behavior on individual fields of a structure. (I'm thinking sprite coordinates, for example.) Doing a block copy of an updated structure, even if some of the fields haven't changed, can be faster than doing "smart" accesses, updating only the individual bytes that need it.

 

I do something similar with the STIC registers on the Intellivision. There, it's much more necessary, since they're only accessible during the vertical retrace interval anyway.

 

 

Wow. I'll have a lot to learn!

Link to comment
Share on other sites

Wow. I'll have a lot to learn!

It's not too bad really. I remember not having too much trouble with it back in my teenage years. If you can read C code, then perhaps some model C code (well, pseudo-C code) might be helpful. Here's some off the top of my head. I'll probably get *something* wrong, so watch for falling bits. ;-) (In case the forum eats it or munges the formatting, I've put a copy here.)

 

typedef unsigned short u16;
typedef unsigned char  u8;

volatile u8 *VDP0 = (volatile u16*) /* put addr of VDP's MODE=0 loc here */;
volatile u8 *VDP1 = (volatile u16*) /* put addr of VDP's MODE=1 loc here */;

/* Read the VDP status register */
u8 vdp_read_status(void)
{   
   return *VDP1;
}   

/* Write to a VDP write-only control register */
void vdp_write_register(u8 value, u8 reg)
{   
   *VDP1 = value;                  /* Write value first                */
   *VDP1 = (reg & 7) | 0x80;       /* Write reg # second, w/ MSB set.  */
}   

/* Read a single byte of VRAM via the VDP */
u8 vdp_read_byte(u16 vdp_addr)
{
   *VDP1 = vdp_addr & 0xFF;        /* Send lower 8 bits of VRAM address */
   *VDP1 = (vdp_addr >> 8 ) & 0x3F; /* Send upper 6 bits of VRAM address */
   return *VDP0;                   /* Read the data byte */
}

/* Read a block of bytes from VRAM via the VDP */
void vdp_read_block(u16 vdp_addr, u8 *dst, int len)
{
   *VDP1 = vdp_addr & 0xFF;        /* Send lower 8 bits of VRAM address */
   *VDP1 = (vdp_addr >> 8 ) & 0x3F; /* Send upper 6 bits of VRAM address */

   while (len-- > 0)
       *dst++ = *VDP0;             /* Copy out the next data byte.      */
}

/* Write a single byte of VRAM via the VDP */
void vdp_write_byte(u16 vdp_addr, u8 data)
{
   /* Send lower 8 first, followed by upper 6.  Must also force upper 2 */
   /* bits of second write to be "01" to indicate "write".              */
   *VDP1 = vdp_addr & 0xFF;
   *VDP1 = (vdp_addr >> 8 ) & 0x3F | 0x40;

   *VDP0 = data;                   /* Send the data */
}

/* Read a block of bytes from VRAM via the VDP */
void vdp_write_block(u16 vdp_addr, u8 *src, int len)
{
   /* Send lower 8 first, followed by upper 6.  Must also force upper 2 */
   /* bits of second write to be "01" to indicate "write".              */
   *VDP1 = vdp_addr & 0xFF;
   *VDP1 = (vdp_addr >> 8 ) & 0x3F | 0x40;

   while (len-- > 0)
       *VDP0 = *src++;             /* Copy out the next data byte.      */
}

Now, this does handwave a couple minor details:

  1. Interrupts: If an interrupt can occur near where this code runs, you'll want to disable interrupts temporarily while performing one of these operations. Also, you probably only want to read the status register from within your interrupt handler. (Presumably the CV has vertical retrace interrupts triggered by the VDP, does it not?)
  2. Timing: If you try to access the VDP during active display, you might need to put some NOPs in various places to keep from accessing it too quickly. I don't know enough about the CV's Z80 speed to comment intelligently.

I suppose it wouldn't hurt to also scan the TMS9118/TMS9128/TMS9129 Data Book I have, since it goes into much greater detail about these low-level issues. I guess I'll scan that this weekend.

 

Any CV coders see major issues with my C pseudo-code above?

Edited by intvnut
Link to comment
Share on other sites

intvnut, here's the OCR'd PDF of the guide thus far: RapidShare of VDP Guide PDF

 

Please keep in mind that this was run through an OCR engine, which while pretty accurate, isn't going to capture every word 100% correctly. I did a brief quality control check on it, and it should be good, though. The PDF is fully searchable, and all text is selectable.

 

If you decide to scan the other appendices, I'll toss up another version of the PDF.

 

Thanks again!

 

Awesome! I've spot checked it and it looks pretty good! I'll see about scanning those appendices this weekend.

 

I also have this Data Manual here. If I scan that, do you mind OCRing it?

Link to comment
Share on other sites

intvnut, here's the OCR'd PDF of the guide thus far: RapidShare of VDP Guide PDF

 

Please keep in mind that this was run through an OCR engine, which while pretty accurate, isn't going to capture every word 100% correctly. I did a brief quality control check on it, and it should be good, though. The PDF is fully searchable, and all text is selectable.

 

If you decide to scan the other appendices, I'll toss up another version of the PDF.

 

Thanks again!

 

Awesome! I've spot checked it and it looks pretty good! I'll see about scanning those appendices this weekend.

 

I also have this Data Manual here. If I scan that, do you mind OCRing it?

Not at all. You scan 'em, I'll OCR 'em. :D

Link to comment
Share on other sites

Wow... I've been gaming almost since birth and emulating systems nearly as long. Yet I'd still never heard of emu-docs.org. All aboard the S.S. Failboat, captain G_P_T-0_1.

 

Still, it'd be nice to have some of those docs searchable and such.

 

Thanks for the link 5-11under!

Link to comment
Share on other sites

Wow... I've been gaming almost since birth and emulating systems nearly as long. Yet I'd still never heard of emu-docs.org. All aboard the S.S. Failboat, captain G_P_T-0_1.

 

Still, it'd be nice to have some of those docs searchable and such.

 

Thanks for the link 5-11under!

 

That scan is pretty similar to my data book. I'll still scan mine, though, in case there are any updates or clarifications. If nothing else, it'd be nice to have it in the historical record.

 

As far as Intellivision goes, though, emu-docs.org has nothing truly useful whatsoever. :-) That's ok, we've managed to put together a pretty comprehensive set of docs anyway.

Link to comment
Share on other sites

  • 2 months later...
That scan is pretty similar to my data book. I'll still scan mine, though, in case there are any updates or clarifications. If nothing else, it'd be nice to have it in the historical record.
Several people (including me) of MSX communities are interested in this too. Since it's newer than the available TMS9918 datasheet, it's very likely to contain additional and more accurate information, including details about the TMS9118. Belated thanks for scanning that programmer's guide btw.:)
Link to comment
Share on other sites

That scan is pretty similar to my data book. I'll still scan mine, though, in case there are any updates or clarifications. If nothing else, it'd be nice to have it in the historical record.
Several people (including me) of MSX communities are interested in this too. Since it's newer than the available TMS9918 datasheet, it's very likely to contain additional and more accurate information, including details about the TMS9118. Belated thanks for scanning that programmer's guide btw.:)

 

*doh* I never did get around to scanning this. Since I have this next week off from work, I'll try to get this done and out of the way. The databook is specific to the TMS9118/19/29, and so doesn't really contain much information for the TMS99x8 variants. I'm sure any register programming quirks that are documented in this book apply to both the TMS9918 and TMS9118 equally though.

Link to comment
Share on other sites

  • 1 month later...

I guess you did things that week less boring than scanning a databook. ;)

 

The databook is specific to the TMS9118/19/29, and so doesn't really contain much information for the TMS99x8 variants. I'm sure any register programming quirks that are documented in this book apply to both the TMS9918 and TMS9118 equally though.
The fact that it's 91xx and not 99xx is what actually makes it interesting.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...