Memory maps, chip documentation

[carlsson]

MADrigal has collected some newsletters and books which contain small tidbits of the apparent creatiVision memory map. However I found it quite incomplete when I looked at it before. Does anyone have a complete map, or perhaps we could collaborate to put together one? It may be useful both for Basic programs and those of us interested in machine code, supposedly only runnable as a cartridge image.

While I'm onto the subject, I expected to find heaps of clear documentation on the TMS 99X9 series video chips. Maybe I looked in the wrong places, but I barely found anything. The least I'd like to see is a register map, but even better a few simple usage examples. For example can the video matrix be read or only written to? I realize both the video and sound chips are addressed through I/O ports on the cV, which is a pain in the *** to me compared to those computers and consoles which have memory-mapped chips. In particular as the creatiVision contains so little RAM and ROM there would've been plenty of space for memory-mapped I/O.

So, some good links to documentation on those TMS and SN chip are also welcome. I already know the 6502 CPU by heart and there are plenty of resources about it too. Looking forward to some good contribution, and the more resources we can put together, the more likely it is that other aspiring developers will find an interest in the creatiVision. After all, it consists of a (somewhat unusual) combination of well known chips. Ever since I read about these systems in the late 1990's, I've been fascinated about a 6502 based computer/video game with rich, flexible graphics and sound. Surely the C64, Atari 8-bit and so on are nice too, but given how many Z80 designs used the 99X9 series video chip to great success, I like to see it paired with a "real" CPU.

[MADrigal]

Anders, send a PM to Kurt_Woloch (pointing him to this thread), he's some replies for your questions!

About the memory maps, I'll do my best to write them, but it may require some time because of my new job, which takes most of my time.

I'm also planning to post a full VRAM map the way BASIC stores/reads data into/from it.

[carlsson]

I am in no hurry, and will let Kurt and others discover the thread by themselves. The same goes for you, whenever you have the spare time, write down what you know and share it.

[Kurt_Woloch]

MADrigal has collected some newsletters and books which contain small tidbits of the apparent creatiVision memory map. However I found it quite incomplete when I looked at it before. Does anyone have a complete map, or perhaps we could collaborate to put together one? It may be useful both for Basic programs and those of us interested in machine code, supposedly only runnable as a cartridge image.

Well, I'm not sure if I have a "complete" memory map. I know for sure that several areas get mirrored in memory. Here is the part of the memory map I remember (which I have used in my demos):

$0000-$03FF... 1K of RAM
$1002... Sound_Write
$1003... Sound_Status
$2000... VDP_Data_Read
$2001... VDP_Status_Read
$3000... VDP_Data_Write
$3001... VDP_Status_Write

Then there's the part from *somewhere* up to $BFFF, which is the cartridge ROM. "Somewhere" depends on the type (size and memory layout) of the cartridge... I think Luca knows more about this. However, all cartridges end at $BFFF.
Some important locations inside a cartridge are:

$BFFE... vector pointing at interrupt handler 1 of the cartridge
$BFEA... vector pointing at interrupt handler 2 of the cartridge
$BFFC... vector pointing at starting address of the cartridge (before title screen gets displayed / circumvents title screen)
$BFF0... table of 8 bytes to initialize the VDP registers on startup

Finally... $F800-$FFFF contain the 2K BIOS ROM. Luca has a documentation of that. The most important thing about the BIOS is the addresses accessed in the cartridge as given above.

I'd recommend you to download the source code of my "Christmas Demo" from this site, which is heavily documented and also goes into some detail about the Creativision's inner workings.

While I'm onto the subject, I expected to find heaps of clear documentation on the TMS 99X9 series video chips. Maybe I looked in the wrong places, but I barely found anything. The least I'd like to see is a register map, but even better a few simple usage examples. For example can the video matrix be read or only written to? I realize both the video and sound chips are addressed through I/O ports on the cV, which is a pain in the *** to me compared to those computers and consoles which have memory-mapped chips. In particular as the creatiVision contains so little RAM and ROM there would've been plenty of space for memory-mapped I/O.

Well, I have a datasheet of the VDP, which you can find here:

http://www.bitsavers.org/pdf/ti/_dataBooks/TMS9918.pdf

I don't know if you'd call that "clear", however. But I also know a good documentation on the web, here:

http://bifi.msxnet.org/msxnet/tech/tms9918a.txt

For the sound chip, you can find the datasheet here, as a zipped series of TIF images:

http://www.atarihq.com/danb/files/SN76489.zip

As for the memory map, well... the video chip, in this case, has its own 16K RAM, which is seperated from the main system's memory map and can be written to and read from through the VDP itself. The advantage of this is that the VDP doesn't hold up the CPU when it needs to access screen memory. The downside, however, is that VDP accesses are somewhat slower than if the memory area could be accessed directly, like it's done on the C-64 and the Atari 8-bits.

But I think it's somewhat of a moot point discussing about how the Creativision could have been produced differently. It has been designed the way it has been, and it's been 25 years now. Today's systems, of course, are designed much differently...
but I think every system using that TI video chip was designed that way. The CPU never has direct access to the VDP's video RAM. But it definitely can be written AND read, since it's also often used as storage, for instance, Creativision BASIC (and also TI Basic on the TI-99, which has the same video chip) stores your BASIC program in VDP RAM, since there's only 1K of direct CPU RAM. The unexpanded TI-99, by the way, has even less than that, only 256 bytes.

[carlsson]

Yep, I know about the VDP's own memory. A few questions to clarify the basics:

For each byte of VRAM data you want to send, you need to write three times to $3000 ?
Ditto for reading VRAM, three reads from $2000 ?

To change a register, two writes to $3001 ?
To read a register, one read from $2001 ?
If you want to read a different register, two writes to $3001 and one read from $2001 ?

I will look at the documents you linked to. It seems the VDP internally is fully reconfigurable to which parts of its memory are used for character definitions, screen matrix and so on? Those would be registers 2-6:

Register 2 - Name Table = screen matrix, which character should be displayed at each position
Register 3 - Color Table = which colour should be used at each position
Register 4 - Pattern, Text or Multicolor Generator = character definitions, how the graphics look like
Register 5 - Sprite Attribute Table
Register 6 - Sprite Pattern Generator

Graphics Mode I = 32x24 "text" mode, one foreground color per 8x8 pattern
Graphics Mode II = 256x192 bitmap mode, two colours per 8x8 pattern
Multicolor Mode = 64x48 block mode, four colours per 8x8 pattern (i.e. one per block)
Text Mode = 40x24 text mode with 6x8 characters, no sprites

I will continue this at a later moment, but so far most concepts seem familiar to me. It is only a matter of setting up the data and send to the VDP.

[Kurt_Woloch]

For each byte of VRAM data you want to send, you need to write three times to $3000 ?

No, wrong. First you write two bytes to $3001, which acts as a "command" to change the read/write address.
Then you write the actual data at $3000.
If you want to write consecutive bytes, however, you don't have to access $3001 again... just write any further bytes to $3000, the VDP auto-increments the write address. You only need to access $3001 again if you want to write to a different address than the next one from the one you just wrote to.

Ditto for reading VRAM, three reads from $2000 ?

No, that's wrong too. Again, you have to write two bytes to $3001 to set the read/write address and change the mode to reading. (as far as I remember, haven't tried that actually) Then you can read your bytes from $2000.

To change a register, two writes to $3001 ?

Yes, that's correct.

To read a register, one read from $2001 ?

Well, yes, but... there's only one readable register, which is the status register. You get the content from that register on each read from $2001. The VDP registers 0-7, which you can write to, are write-only, they can't be read.

If you want to read a different register, two writes to $3001 and one read from $2001 ?

No. There is no different register to read from.

I will look at the documents you linked to. It seems the VDP internally is fully reconfigurable to which parts of its memory are used for character definitions, screen matrix and so on? Those would be registers 2-6:

Register 2 - Name Table = screen matrix, which character should be displayed at each position
Register 3 - Color Table = which colour should be used at each position
Register 4 - Pattern, Text or Multicolor Generator = character definitions, how the graphics look like
Register 5 - Sprite Attribute Table
Register 6 - Sprite Pattern Generator

Yes, that's true.

Graphics Mode I = 32x24 "text" mode, one foreground color per 8x8 pattern

No, wrong. You have one foreground and one background color per 8x8 pattern. However, these can't be set freely on the screen grid like on other video chips, rather they're tied to the graphics patterns you use. There's 32 "character sets" (in official TI slang) of 8 characters each which will share the same background and foreground colors. Character set 0 contains patterns 0-7, character set 1 contains patterns 8-16 and so on. So each time a character (or pattern) appears on screen, it does so with the same background and foreground colors. There's no way of having it appear in different colors, except for defining it twice with different pattern numbers.
By the way, that mode is called "Graphics mode" in official TI slang.

Graphics Mode II = 256x192 bitmap mode, two colours per 8x8 pattern

No, here you get more colors. Each pattern consists of 8 lines which are 8 pixels wide, and each line has its own foreground and background color. This mode, in official TI slang, is called "Bitmap mode".

Multicolor Mode = 64x48 block mode, four colours per 8x8 pattern (i.e. one per block)
Text Mode = 40x24 text mode with 6x8 characters, no sprites

Yes, those are correct. And the text mode has only one foreground and background color for the whole screen (defined in VDP register 7).

[carlsson]

Ouch!

What you write about 32 character sets of 8 characters seem vaguely familiar. I may have read about this before but forgot it. So is the Color Table in Graphics Mode I used to define the colours of each character set?

In any case, I'm not in the process of any programming right now so I think I'm set for the moment. One day when I'm deep into it, I will read the specs even more closely and possibly will get back with some new questions.

[MADrigal]

The fact of the 32 character sets of 8 chars each is well documented even on the creatiVision BASIC manual. There's a specific "color" command to set the colours to each bloch of 8 chars.

[Kurt_Woloch]

OK. Don't know if anybody will read this, but anyway, I wanted to write this somewhere, and I think it fits here best...

After already having succeded in programming the Creativision graphics- and soundwise, the question still remains how to poll the joysticks and keyboard on the controllers.

I took a deep peek into 3 sources, the MESS driver, the Creativision BIOS and the binary of "Crazy Chicky", and I think I've made considerable steps forward in this field...

According to the MESS driver, the controllers get read through the PIA, which is available on addresses $1000-$1003. You already may know $1002 and $1003 from accessing the sound chip, but $1000 and $1001 also come into play if you want to read the controllers.
I checked the source of "Crazy Chicky" for accesses to these addresses, and there are NONE, which means that this game must do all those reads through the BIOS. So I checked the BIOS for reads from this addresses and found one routine that does this... it starts at $FA00, right after the charset.

Now "Crazy Chicky" doesn't call this routine as well, but it gets called on every interrupt by the BIOS' interrupt handler. This routine reads the controllers, translates the results via a table and stores them in the zero page area from $10-$1F.

Out of those addresses, "Crazy Chicky" only uses $11, $12, $13 and $14, which seem to contain the most useful data.

Now, by analyzing the contents of those locations in different cases, I've come to the following conclusion:

;Bytes $18-$1B contain the direct input from the controllers; the other bytes contain a somewhat translated version of it.
;The meaning of bytes $18 and $1A (for controller left and right) are:
;Bit 7.... fire button 2
;Bit 5... left
;Bit 3... up
;Bit 2... right
;Bit 1... down
;The meaning of bytes $19 and $1B (for controller left and right) are:
;if only bit 7 is set, the fire button 1 is depressed.
;Other buttons are represented by a combination of 2 bits that get set.

[carlsson]

Great info I'm sure. While I don't really have the time to study the creatiVision as much as I would like, some day people may.