Auto-detect V9938

[Willsy]

Can anyone think of a method to auto detect a V9938 or 58 in code? I seem to remember they had a special register that contained some sort of ID field, but I can't find it after scanning the data book

[John Doe]

Edited February 22, 2014 by Tony Knerr

[RXB]

Can anyone think of a method to auto detect a V9938 or 58 in code? I seem to remember they had a special register that contained some sort of ID field, but I can't find it after scanning the data book

 

Look at page 9. Status register #1 contains the identification number for 9938 or 9958 in bits 1 through 5.

I've got a scribble on my copy that indicates 0 is 9938 and 2 is 9958.

 

Tony

 

 

 

But if you only have a 9918 will that access to a register only on those chips lock up the TI? I remember that that trick was good for seeing if you were on a TIM card (9958) or a Geneve (9938).

 

I would have used CRU bits as you can test a CRU bit and if zero then obviously that device is not there. Also the more bits usually the newer the device is.

[+InsaneMultitasker]

This may not be what you're looking for, but here's one method I've employed...

 

1. set VRAM page to 0 via register 14 (pretty sure this is the right reg - only active on the 9938/58)

2. Save VRAM data at address (ie, 0x0700)

3. Copy test value to 0x0700

4. Set VRAM page to 1,2 or 3 via register 14

5. Save VRAM data at same address (0x0700)

5. Incrememt test value and write to address (0x0700)

6. Set VRAM to page 0 via register 14

7. Read data at 0x0700

8. Doesvalue match incremented value? If yes, probably not a 9938/58. If no, probably a 9938/58.

 

Value 0x0700 selected to stay below 4k threshold and inhibit a vram page flip induced by writing to the last byte of the bank (at least that's what I recall without reviewing any notes).

 

You may wish to download and review the FWEB source code as the MdGovern's made good use of 80 column hardware and wrote for both the Geneve and TI. With luck, I'm not confusing this method with some other routine

[+retroclouds]

Interesting topic. The 9938 really seems to have some nice features (e.g. commands that run entirely inside the 9938: drawing a line, moving memory blocks from VRAM to VRAM, ...).

[Willsy]

Thanks guys. I'll look at status reg #1 first as that is likely a simpler solution. Question though... How does one read a *status* register in 9900 land? We can read *VDP* registers using the normal means... Are the status regs read using the exact same technique, or is there a different address in play for those registers?

 

I have 80 column working just fine. The whole system adapts iteself itself if you go into 80 column mode. Thats been working (and is included) in TF V1.0 - however, I would like the system to auto-detect and just enable 80 column at start-up if the 38/50 is detected. For that though, a reliable detection mechanism is critical. Can't have it trying to sdelect 80 column mode on a 40 column system!

 

Mark

[Willsy]

Er, my mind has gone blank. How do I read the status register on a standard 9918? More to the point, how do I read status register *1* on a 9938? Has anyone got any ideas?

 

Mark

[RXB]

Er, my mind has gone blank. How do I read the status register on a standard 9918? More to the point, how do I read status register *1* on a 9938? Has anyone got any ideas?

 

Mark

 

The problem is that there is no status register in the 9918 as far as I know and even if there was the 9918 has less registers so the program would have to check for each chip.

 

I still think the CRU is the way to go, almost all of the VDP chips we use all are under 4 CRU address and checking each address for a 1 or a 0 indicates if the chip is there.

 

Of course a zero is no chip and a 1 is the chip is there. You would not have to worry about a crash or the size of the memory as the CRU bits will tell you all of this by the return of bits.

 

Using CRU means you could even see if two chips are installed like the 9918 and the 9938 at different CRU and use the one you want. This seems like a better solution then trying to talk to a chip you do not know is there or not.

Edited July 26, 2011 by RXB

[sometimes99er]

How do I read the status register on a standard 9918?

ref.: http://nouspikel.group.shef.ac.uk//ti99/tms9918a.htm#Registers

 

>8802 Read the status byte from the status register, resets it, and clear interrupt.

 

The first 3 bits of this register are automatically reset as 0 when the register is read or when the VDP is reset. It ensues that the status register should only be read when an interrupt is pending, otherwise an interrupt could be missed.

 

Bit 0 (weight >80). This bit is set to 1 at the end of the raster scan of the last line of the display area (i.e. before drawing the bottom margin). If interrupts are enabled (by bit 2 in VDP register 1), the INT* pin is low when this bit is 1 and high when it's 0. This is why the status register should be read after each frame, in order to clear the interrupt and be ready to receive the interrupt at the end of the next frame. Also, if bit 2 in VR1 is cleared and set again while status bit 0 is set, an interrupt is issued immediately.

Bit 1 (weight >40) signals that there are 5 or more sprites on a given pixel row. Only the topmost four will be displayed.

Bit 1 (weight >20) is the coincidence bit. It is set when two sprites or more have at least one overlapping "on" pixel. This occurs even if the sprite color is transparent. Note that coincidence is checked only every 1/60th of second (1/50th of a second for the TMS9929A), thus if you change sprite positions during that time a coincidence could be missed.

Bits 3 to 7 contain the number of the 5th sprite on a pixel line, if any. This number is only meaningfull if bit 2 is set as 1 (else it may contain the number of the last displayed sprite, but no guaranty). If such a situation occurs more than once, the 5th sprite listed is the one closest to the top of the screen.

[Willsy]

>8802 Read the status byte from the status register, resets it, and clear interrupt.

 

Hmmm.... Ok, so, it's memory mapped... (duh! what else could it be )... something tells me that reading status register #1 will not be as simple as reading >8803

[matthew180]

I have 80 column working just fine. The whole system adapts iteself itself if you go into 80 column mode. Thats been working (and is included) in TF V1.0 - however, I would like the system to auto-detect and just enable 80 column at start-up if the 38/50 is detected. For that though, a reliable detection mechanism is critical. Can't have it trying to sdelect 80 column mode on a 40 column system!

 

Mark

 

How are you setting the mode? Register direct, or are you using the bulk-load indirect method through R17? If the former, then TF on the 99/4A with an F18A can use 80-columns; and that would be a good reason to support it. :-) I can also make a definite way to detect the F18A.

[Willsy]

I have 80 column working just fine. The whole system adapts iteself itself if you go into 80 column mode. Thats been working (and is included) in TF V1.0 - however, I would like the system to auto-detect and just enable 80 column at start-up if the 38/50 is detected. For that though, a reliable detection mechanism is critical. Can't have it trying to sdelect 80 column mode on a 40 column system!

 

Mark

 

How are you setting the mode? Register direct, or are you using the bulk-load indirect method through R17? If the former, then TF on the 99/4A with an F18A can use 80-columns; and that would be a good reason to support it. :-) I can also make a definite way to detect the F18A.

 

I'm using the former method.

[matthew180]

Six million dollar question then... How do you change from 40 to 80 (and back to 40) in TF? :-)

[RXB]

I still think the answer is the CRU selection method as once you try to acccess the wrong chip it locks the system.

On the other had using CRU means you detect the correct chip then run the correct program, would never crash this way.

 

Besides the code to detect a CRU bit is one heck of a lot smaller then accessing a chip you are looking for.

 

 

LI R12,CRUBIT address

TB 7

 

The value returned would be the VDP chip you are using, this is about as easy and compact as you can get.

[Willsy]

I still think the answer is the CRU selection method as once you try to acccess the wrong chip it locks the system.

On the other had using CRU means you detect the correct chip then run the correct program, would never crash this way.

 

Besides the code to detect a CRU bit is one heck of a lot smaller then accessing a chip you are looking for.

 

 

LI R12,CRUBIT address

TB 7

 

The value returned would be the VDP chip you are using, this is about as easy and compact as you can get.

how does a single bit tell you anything?

[+InsaneMultitasker]

<snip> once you try to acccess the wrong chip it locks the system.

On the other had using CRU means you detect the correct chip then run the correct program, would never crash this way.

Lockup? Not true. Set the mode to a 9918 mode and you can be off & running.

 

Besides the code to detect a CRU bit is one heck of a lot smaller then accessing a chip you are looking for.

 

LI R12,CRUBIT address

TB 7

 

The value returned would be the VDP chip you are using, this is about as easy and compact as you can get.

Where are you getting the idea that the VDP chip type can be gleaned from a CRU bit in our systems???

[Willsy]

Six million dollar question then... How do you change from 40 to 80 (and back to 40) in TF? :-)

For 40 column type 0 GMODE

For 32 column type 1 GMODE

For 80 column type 2 GMODE

[RXB]

<snip> once you try to acccess the wrong chip it locks the system.

On the other had using CRU means you detect the correct chip then run the correct program, would never crash this way.

Lockup? Not true. Set the mode to a 9918 mode and you can be off & running.

 

Besides the code to detect a CRU bit is one heck of a lot smaller then accessing a chip you are looking for.

 

LI R12,CRUBIT address

TB 7

 

The value returned would be the VDP chip you are using, this is about as easy and compact as you can get.

Where are you getting the idea that the VDP chip type can be gleaned from a CRU bit in our systems???

 

Well becuase every single chip on the bus has to have a CRU address. And when I had my TIM card I could flag CRU bits and it would return a different value for the 9918 then from the TIM that used the 9958.

 

My SCSI hard drive along with my TIM died about 10 years ago but this is what I had discovered and was going to use for RXB 80 column version. If I would have had a replacement TIM I would have finished the project.

 

If I remember correctly it was CRU >0400 for the TIM card and every other VDP card like the Geneve. But there was another device using that address also, so that was a conflict. Do not remember the device but I was never going to buy one.

Edited August 5, 2011 by RXB

[marc.hull]

<snip> once you try to acccess the wrong chip it locks the system.

On the other had using CRU means you detect the correct chip then run the correct program, would never crash this way.

Lockup? Not true. Set the mode to a 9918 mode and you can be off & running.

 

Besides the code to detect a CRU bit is one heck of a lot smaller then accessing a chip you are looking for.

 

LI R12,CRUBIT address

TB 7

 

The value returned would be the VDP chip you are using, this is about as easy and compact as you can get.

Where are you getting the idea that the VDP chip type can be gleaned from a CRU bit in our systems???

 

Well becuase every single chip on the bus has to have a CRU address. And when I had my TIM card I could flag CRU bits and it would return a different value for the 9918 then from the TIM that used the 9958.

 

My SCSI hard drive along with my TIM died about 10 years ago but this is what I had discovered and was going to use for RXB 80 column version. If I would have had a replacement TIM I would have finished the project.

 

If I remember correctly it was CRU >0400 for the TIM card and every other VDP card like the Geneve. But there was another device using that address also, so that was a conflict. Do not remember the device but I was never going to buy one.

 

 

The VDP (as well as most "chips" in the 99) is/are a memory mapped device and has nothing to do with CRU..... YAFUS here my friend.

[+InsaneMultitasker]

<snip> once you try to acccess the wrong chip it locks the system.

On the other had using CRU means you detect the correct chip then run the correct program, would never crash this way.

Lockup? Not true. Set the mode to a 9918 mode and you can be off & running.

 

Besides the code to detect a CRU bit is one heck of a lot smaller then accessing a chip you are looking for.

 

LI R12,CRUBIT address

TB 7

 

The value returned would be the VDP chip you are using, this is about as easy and compact as you can get.

Where are you getting the idea that the VDP chip type can be gleaned from a CRU bit in our systems???

 

Well becuase every single chip on the bus has to have a CRU address. And when I had my TIM card I could flag CRU bits and it would return a different value for the 9918 then from the TIM that used the 9958.

 

My SCSI hard drive along with my TIM died about 10 years ago but this is what I had discovered and was going to use for RXB 80 column version. If I would have had a replacement TIM I would have finished the project.

 

If I remember correctly it was CRU >0400 for the TIM card and every other VDP card like the Geneve. But there was another device using that address also, so that was a conflict. Do not remember the device but I was never going to buy one.

 

Rich, no, not every chip on the bus has a CRU address. I think you might be confusing peripheral cards (such as a disk controller or video card) with the integrated circuits they are built from.

 

There are books & articles at our disposal which provide overviews and details about the TI, its memory and CRU devices, and how they all fit together. The TI does a good job of hiding what's under the hood so I'm not surprised that it is easy to apply specific observations to the whole system.

 

You may indeed have been accessing specific CRU bits related to your TIM video card. However, you were not accessing the video chip directly. It's late and a proper analogy escapes me. Perhaps some of the readers could offer a few suggestions that will bridge the hardware/software divide for those wishing to learn.

 

Ultimately, you don't need to understand the 9918 theory of operation but you *should* know that it is a memory mapped device.

[+InsaneMultitasker]

Copied from Jeff White's recent post to the TI994a Yahoo group.

 

Preserved in the TI Hardware Compendium, compiled by Dan Eicher:

DTIHM027

CPUID & VDPID 
by Jeff White


40176 2SEP93-2117 Communications
RE: PC99 and TELCO (Re: Msg 40175)
From: JHWHITE To: MARKVC

To clarify that a bit, V14 is used to change the 16K page of VRAM used by the
V9938/V9958. If data is written to page 0, which is all that exists on the
stock 99/4A, and the page is changed (only possible with V9938/V9958), the
data will not be there. However, since the page does not change on the
9918A, the data will be found. The 9918A may mask V14 to V6, and V6 sets
the sprite generator table base address. Because sprites are inactive in
the text modes which Telco uses, changes to V6 do not affect the video
display.

I have a more innocuous routine, called VDPID, that works on a different
principle. The only side-effect is that the text mode and background colors
are changed, but the routine does change them to what the programmer gives
the routine.

Jeff

-*-

---------------------------------------------------------------------------
> *  VDP identification routine by Jeffrey H. White
> *  (c) Copyright 1991
> *
> *  Usage:  BLWP @VDPID
> *
> *  Returned values in R1:  if 9918A, = 1
> *                          if V9938, = 2
> *                          if V9958, = 3
> *
> VDPWS  BSS  32
> VDPID  DATA VDPWS
>        DATA VDPPC
> VDPPC  LI   R10,1
>        LI   R0,>0F04
>        BLWP @VWTR
> VDPST  MOVB @VDPSTA,R12
>        JGT  VDPST
>        JEQ  V9918A
>        MOVB @VDPSTA,R12
>        JLT  V99X8
>        JMP  V9918A
> V99X8  LI   R0,>0F01
>        BLWP @VWTR
>        MOVB @VDPSTA,R12
>        SLA  R12,5
>        JLT  V9958
>        JMP  V9938
> V9958  INC  R10
> V9938  INC  R10
> V9918A LI   R0,>0F00
>        BLWP @VWTR
>        LI   R0,>07F4
>        BLWP @VWTR
>        MOV  R10,@>0002(R13)
>        RTWP
> *