Jump to content
Sign in to follow this  
cdoty

TMS 9129 question.

Recommended Posts

I recently picked up a BBC Bridge Companion to see if I could get my code running on it. But, I'm having some issues with the TMS 9129.

 

I am using Mode 2, and the code runs on all known TMS 99x8 based systems, but doesn't run correctly on the TMS 9129, or this particular system.

 

The problem I am seeing is that writes to $2000-$3800 range go to $0000-$1800, but writes to $3800 work fine.

I've been able to verify this by writing the color data first and then writing the pattern data. The sprites work fine, so writes to $1800 and $3800-$3C00 work fine.

I've tried the exact delay they use when writing to the registers and VRAM.

I've also changed the black color, as I've seen that cause problem on one system. The external VDP bit also doesn't make a difference.

The code does run fine under Mame, and I've double and triple checked all of my register settings, and they are correct.

 

The system itself only uses Mode 1 for it's software.

I've tried piggybacking RAM on top of the two 4416 chips and that didn't work. I ordered a replacement TMS 9129. The existing one looks like it might have overheated at some point, and does get fairly warm in a particular spot. The system has no power switch, so it could have been left running for an extended period of time.

 

Is there anything I'm missing, or does this sound like a damaged chip?

Share this post


Link to post
Share on other sites
1 hour ago, cdoty said:

I recently picked up a BBC Bridge Companion to see if I could get my code running on it. But, I'm having some issues with the TMS 9129.

 

I am using Mode 2, and the code runs on all known TMS 99x8 based systems, but doesn't run correctly on the TMS 9129, or this particular system.

 

The problem I am seeing is that writes to $2000-$3800 range go to $0000-$1800, but writes to $3800 work fine.

I've been able to verify this by writing the color data first and then writing the pattern data. The sprites work fine, so writes to $1800 and $3800-$3C00 work fine.

I've tried the exact delay they use when writing to the registers and VRAM.

I've also changed the black color, as I've seen that cause problem on one system. The external VDP bit also doesn't make a difference.

The code does run fine under Mame, and I've double and triple checked all of my register settings, and they are correct.

 

The system itself only uses Mode 1 for it's software.

I've tried piggybacking RAM on top of the two 4416 chips and that didn't work. I ordered a replacement TMS 9129. The existing one looks like it might have overheated at some point, and does get fairly warm in a particular spot. The system has no power switch, so it could have been left running for an extended period of time.

 

Is there anything I'm missing, or does this sound like a damaged chip?

The TMS chips can be configured with either 16k or 4k of video ram.  When in 4k mode the addresses get mirrored, that sort of sounds like the behavior you are seeing.

Share this post


Link to post
Share on other sites
6 hours ago, cdoty said:

The problem I am seeing is that writes to $2000-$3800 range go to $0000-$1800, but writes to $3800 work fine.

I've been able to verify this by writing the color data first and then writing the pattern data. The sprites work fine, so writes to $1800 and $3800-$3C00 work fine.

What do you mean by the above?  How does order of operation affect verifying where bytes went?  It seems to me that a better verification would be to write 00-3F into memory at 256-byte intervals, then read them back to see what ends up at each location.

 

Anyway, the TMS chips allow you to specify where in memory colors, patterns, sprites, and the name table all go.  So programming the mode registers isn't enough.  Do you also program the buffer location registers?  Different systems may set them up with different values, so to ensure that it works across the board, you should program those values yourself.

Share this post


Link to post
Share on other sites
3 hours ago, ChildOfCv said:

What do you mean by the above?  How does order of operation affect verifying where bytes went?  It seems to me that a better verification would be to write 00-3F into memory at 256-byte intervals, then read them back to see what ends up at each location.

 

Anyway, the TMS chips allow you to specify where in memory colors, patterns, sprites, and the name table all go.  So programming the mode registers isn't enough.  Do you also program the buffer location registers?  Different systems may set them up with different values, so to ensure that it works across the board, you should program those values yourself.

It's writing to $0000, so the last write to that location is the final value.

 

Yes, they are all set:

    ld        b, 02h        ; Disable external VDP, set M3 for Graphics mode 2
    ld        c, 0
    call    writeVDPReg

    ld        b, 82h        ; Enable 16K VRAM, NMI interrupt, and 16x16 sprites. Disable screen.
    ld        c, 1
    call    writeVDPReg

    ld        b, NameTable / 400h    ; Set Name Table location.
    ld        c, 2
    call    writeVDPReg

    ld        b, (ColorTable / 40h) | 7Fh    ; Set Color Table location.
    ld        c, 3
    call    writeVDPReg

    ld        b, (PatternTable / 800h) | 3    ; Set Pattern Table location.
    ld        c, 4
    call    writeVDPReg

    ld        b, SpriteAttributes / 80h    ; Set Sprite Attribute Table location.
    ld        c, 5
    call    writeVDPReg

    ld        b, SpritePattern / 800h    ; Set Sprite Pattern Table location.
    ld        c, 6
    call    writeVDPReg

    ld        b, 00h        ; Set background color to black
    ld        c, 7
    call    writeVDPReg

 

writeVDPReg ors the c value with $80.

 

Share this post


Link to post
Share on other sites
8 hours ago, Tony Cruise said:

The TMS chips can be configured with either 16k or 4k of video ram.  When in 4k mode the addresses get mirrored, that sort of sounds like the behavior you are seeing.

I set register 1 to $82 initially, and then $E2 to turn on the screen.

 

The sprite patterns are at $1800 and the attribute table is at $3B00, and those do work. I can also write to $800, and $1000 and see the effects on the different areas of the screen.

 

Edited by cdoty

Share this post


Link to post
Share on other sites
On 11/20/2020 at 6:13 AM, Tony Cruise said:

The TMS chips can be configured with either 16k or 4k of video ram.  When in 4k mode the addresses get mirrored, that sort of sounds like the behavior you are seeing.

It wasn't the TMS9129, I replaced it with no change.

 

I did some testing and found out the chip is only seeing 8k, instead of 16k. It's using two 4416s, so that doesn't make a lot of sense.

But, I was able to move the sprite stuff to either $3800 to $1800, etc. and it works the same regardless of the setting. Moving it to $800 overwrites the screen, so it is definitely seeing 8k.

 

There is something about 8k or 16k memory mapping, but I can't find anything in the documentation dealing with that.

Edited by cdoty

Share this post


Link to post
Share on other sites
1 hour ago, cdoty said:

It wasn't the TMS9129, I replaced it with no change.

 

I did some testing and found out the chip is only seeing 8k, instead of 16k. It's using two 4416s, so that doesn't make a lot of sense.

But, I was able to move the sprite stuff to either $3800 to $1800, etc. and it works the same regardless of the setting. Moving it to $800 overwrites the screen, so it is definitely seeing 8k.

 

There is something about 8k or 16k memory mapping, but I can't find anything in the documentation dealing with that.

So two 16 x 4 bit ram chips, so yes you would expect that you would have the full 16k.  Have you followed the address lines from the ram chips to the VDU, maybe they didn't wire one of them for some reason or you have a faulty trace perhaps.

Share this post


Link to post
Share on other sites

Yep, especially check AD0 and AD7.  I don't know which is which because TI has a tendency to count bits in reverse order.  But one of those is probably not connected fully between the VDC and its memory.  Looks like pin 10 from 9128 should go to pin 14 of each 4416, and pin 3 from 9128 should go to pin 10 of each 4416.

2017502913_ScreenShot2020-12-02at9_17_20PM.thumb.png.093c7eeab6ffd98514bd33eab2acf6f5.png1521529921_ScreenShot2020-12-02at9_18_31PM.thumb.png.74a01331b4d0b5df4fdc14dc68882fe7.png1079118501_ScreenShot2020-12-02at9_20_00PM.png.3a4fa87911ca9ffb869805b9429080b8.png

Share this post


Link to post
Share on other sites
19 hours ago, ChildOfCv said:

Yep, especially check AD0 and AD7.  I don't know which is which because TI has a tendency to count bits in reverse order.  But one of those is probably not connected fully between the VDC and its memory.  Looks like pin 10 from 9128 should go to pin 14 of each 4416, and pin 3 from 9128 should go to pin 10 of each 4416.

 

 

Yeah that was it. I convinced myself that it needed all address lines to set both the low and high values of the address. But, yesterday I read the sc3000.txt document which indicates it would only need 6 address lines to access 8k.

 

The A7 pins are connected to Pin 10 (A4) on the Z80 PIO chip.

Share this post


Link to post
Share on other sites
1 hour ago, cdoty said:

 

Yeah that was it. I convinced myself that it needed all address lines to set both the low and high values of the address. But, yesterday I read the sc3000.txt document which indicates it would only need 6 address lines to access 8k.

 

The A7 pins are connected to Pin 10 (A4) on the Z80 PIO chip.

..... that's weird.  The 4416s should be exclusive to the 9129.  The CPU has to use the VDC's memory read/write commands to access it.

 

The data sheet for the 4416 says it uses A0-A7 for 8 bits of the address space, then only A1-A6 for the additional 6 bits.  It is not specific about which are intended to be the high or low half of the address (and indeed, it is completely up to the designer to choose).  But the A0-A7 pins of each 4416 should be connected to each other, and they should be connected to one of pins 3-10 of the 9129, and nothing else.  At least, that's what the 9129 expects.

 

If they are doing something different, then programming it will be far different than expected for normal 9x2x-based systems.

Share this post


Link to post
Share on other sites
1 hour ago, ChildOfCv said:

..... that's weird.  The 4416s should be exclusive to the 9129.  The CPU has to use the VDC's memory read/write commands to access it.

 

The data sheet for the 4416 says it uses A0-A7 for 8 bits of the address space, then only A1-A6 for the additional 6 bits.  It is not specific about which are intended to be the high or low half of the address (and indeed, it is completely up to the designer to choose).  But the A0-A7 pins of each 4416 should be connected to each other, and they should be connected to one of pins 3-10 of the 9129, and nothing else.  At least, that's what the 9129 expects.

 

If they are doing something different, then programming it will be far different than expected for normal 9x2x-based systems.

Problem solved.. Thank you.

 

That's all it needed was A6 and A7 split out and A7 connected.

 

And, the pins, from the VDP to the SRAM were wired backwards, AD7 goes to A0, etc, as was the Z80 PIO.

So, I wonder if the diagram uses AD0 as the MSB, like the documentation does for the registers?

 

Edit: it is shown that way on the TMS9918 document. AD0 (MSB)..

 

 

Edited by cdoty

Share this post


Link to post
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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...