Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

Davvel

Members
 View Profile  See their activity

  • Posts

    294

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Davvel

  1. Davvel

    Fixing My TI 99 4A

    By Davvel,

    In my Teens I was the lucky owner of a Beige TI 99/4A which my parents bought me for Christmas (1983). I was thrilled with it and in a few weeks I was writing small games and sharing these with my friends. My Software Developer Career started on that day.

    32 years later exactly 6 months ago I joined the local Vintage Computer club and 2 months ago I told them that I would start displaying my TI 99/4A in the shows we do in schools etc... I tried switching it on again but to my dismay a long Tone and a black screen came up on the CRT TV.

    I started looking for solutions on the Internet and happened to hit ATARIAGE, it was like a miracle for me, I could not believe that so many interesting people would congregate onto one forum.

    From the tips I was getting I started the journey to fix my TI.
    I started by checking the voltages of my power supply and found that the 8.5v AC was not coming out correctly, only 2.5V.

    I took the transformer for new copper winding in a factory we have locally and the TI 99/4a booted up properly. The problem was that it only lasted 1 hour and I had the Long Tone and Black screen again. Now all the voltages were correct but TI was still not working.

    I wanted to be bolder and fire up my trusty soldering iron and hand de-soldering tool (2 euro pump). I read that in many cases it is either the Video Chip (TMS9929A) or the VDP RAM (4116). So I purchased a new video chip. Replaced my chip with the new one but to no avail.

    Then I ordered 8 VDP RAM chips, which are still on the way. I will socket all the chips so that I can replace the RAM chips easily if need be.

    Today the 6th of December 2015, I started the de-soldering process and will keep this blog updated with the progress. The VDP RAM is difficult to remove as the solder is double sided and the two white strips interfere with the process of pulling the chips. I really would have finished this in an hour if these were not so in the way, but patiently today I removed 5 chips. More on this soon.


  2. Davvel

    My Nanopeb experience

    By Davvel,

    Yesterday 5th December I ordered a nanoPeb from http://www.stargames.be/shop/101-ti-99-4a a French site, but I used Chrome web browser for on the fly translation from French to English.

    I will be posting my experience with this device as I go along. It should have a 256MB CF card which I can mount as TI Disks.

    As soon as this arrives and I test it that it is OK I will order the XB 2.7 (The Great Gazoo's software Suite)



    12/12/2015

    My NanoPeb Finally arrived. Let the fun begin.

     
     
  3. Davvel
    I do not know Jacques myself, but I am compiling information from all sources to this one central blog.
     
    The following is an excerpt from "orion1052003" :
     
    Jacques Groslouis was a member of the TI99 HOF, or TI-99 Hall of Fame. He was active on the TI groups such as Atariage, TI group #1, TI group #2, etc. He wrote the article "Using RANDOMIZE with seeds" on September 20, 2009 and "Getting There From Here", about connecting the TI to modern computers. He wrote the games SUDOKU and C99 Games and FRUSTRATE. He converted the games Al Capone, Labyrinth Inferno, and TI Sweeper. He dabbled in Assembly Language and was well versed in the Molesworth and Lottrup books. He was very knowledgable about FunnelWeb and wrote and article about that computer environment.

    Jacques was a retired accountant and member of the Rotary Club. He enjoyed visiting with his extended family and taking his wife to their favorite restaurant. He was a person that was always kind and helpful. I couldn't say a bad thing about him, and I couldn't even say the same thing for myself. Not only was he helpful, but he often went out of his way to help. He mentored me in TI, and taught me most all I know about Extended Basic, TI Basic, and was helping begin to learn Assembly Language. He was a very nice man, and a great friend. I sorely miss him, no doubt. I would often Skype him, and look out his snowy window or gaze at his TI setup with computer, PEB, books, and disks. We often stopped talking about computers and begin to chit chat in general. He was a positive role model and an endearing person. Although I never met the man in person, I have talked to him on the phone, Skyped, emailed, mailed letters, and received disks and books from him in the mail. I enjoyed talking to him, often several times a week, and working on programs and problems together. He was a French Canadian who spoke mostly English. He visited a couple of the big TI gatherings throughout the years, such as I believe the Lima fair. He was a proofreader for many a document on the CYC disk, and I think a friend of the venerable Charlie Good.

    Je' t'aime, mon Oncle.

    Je' t'aime.

    GROSLOUIS, JACQUES "JACK" - 1935 - 2014 - Bathurst - Jacques "Jack" Groslouis, 79, of Riverbank Dr., Bathurst, passed away on Tuesday, September 30, 2014, at the Chaleur Regional Hospital, Bathurst. Born in Ottawa, Ont., he was the only son of the late Anita Groslouis. Jack, a retired partner from KPMG with 54 years of service, was elected a fellow of the New Brunswick Institute of Chartered Accountants, past president of the NBICA, life member of the Institute of Chartered Accountants of Ontario, a Junior Achievement Advisor, past Treasurer of the Bathurst Rotary Club and a Paul Harris Award recipient. He is survived by his wife, Charlotte (Montion) Groslouis; three sons: Robert (Helen) of Lower Coverdale, N.B., Peter (Kim) of Orleans, Ont. and Jean Paul (Mandi) of Riverview; two daughters: Lise Costello (Colin) of Lakeville, N.B., and Joanne Groslouis (Michael Lapointe) of Bathurst; seven grandchildren: Robin, Randi, McKenzie, Cassandra, Patrick, Spencer, Isabella and five great-grandchildren: Brynn, Shea, Avery, Rylie and Azlyn.
    The body rested at Elhatton's Funeral Home (www.elhatton.com), Bathurst.
    Funeral service will be celebrated on Friday, October 3, 2014 at 2 p.m. from Elhatton's Funeral Home Chapel, Bathurst. Donation in memory of Jack may be made to a charity of your choice.





  4. Davvel
    I urge anyone reading this blog to post comments and add material that would remind us of great people who shaped the world of TI 99/4A.
     
    I have only recently started to learn about the rich history of the TI as I had put my TI on a shelve for 30 years, but a month ago I wondered why I should not try to turn it on and start reliving my childhood.
     
    In the process I learnt of the late Tony Knerr and his Genius and was shocked to realise how many great people live and die and 99.999% of the world just are oblivious of the loss.
     
    In this blog I hope to capture the best TI 99/4A contributors. I will be brief and reference or copy material where possible, but the mash-up should help those who cannot be bothered googling for the info.
     
    Tony Knerr has given the world a special cartridge which many say is the de-facto cartridge to have in your TI. It is called XB 2.7 (eXtended Basic 2.7). It has much more than XB within. It comes with an Editor Assembler (E/A), the XB, a few games and all that is seen below :
     

     
     
    The following is copied from various sources :

    Tony lived up till the young age of 57. He died on the 22nd September 2015 which happened to be his Birthday.
    Known as the "father" of the Extended Basic v Suite 2.7 as well as
    the Collection of programs on cartridges of 512 KB and 1024 KB.
    Throughout its history the world "Texan" has also programmed
    the MDOS 6.50 of Geneve and presented some cards for
    the Peripherial Expansion Box, here's a quick list of what he has done for us:
    Geneve Boot Eprom v 1.0-HSGPL Loader-Utilities Pgram Pgram-Reloader-Extended Basic v & v 2.6-2.5 TKgrom0-80 track Disk Controller Modification-YOU Pgram Y2K DSR-AVPC-Upgrade Eprom Personality Card Disk Manager Upgrade-Various Music Programs-Scattergories-Extended Basic v 2.7 Suite Cartridge-cartridges 1 through 6 Games-2048 k-512 k cartridge Games Utilities cartridge-512 k Educational cartridge. (http://www.ti99iuc.it/web/index.php?pageid=homepage&artid=165)
    Lived in Downingtown, PA 19335, USA
    His Public Facebook page is still active today - https://www.facebook.com/tony.knerr.3
    He released his masterpiece work in 2015.
    Many talk of him as the ultimate humble genius who shared every single thing he did in a selfless, altruistic manner.

    His work ensured that TI can be enjoyed for many years to come.
     
     
    Today (18th December 2015) I clicked Gazoo's 999 Like. I tried to be the one to hit 1000 but I ran out of likes for the day. I will surely hit a couple of more likes tomorrow.
     

     
     
  5. Davvel

    My Cartridge Collection

    By Davvel,

    Recently (November 2015) I purchase a Silver TI 99/4A given that my Beige TI which I had for the last 31 years broke (black screen + long tone). I am trying to fix it (see my other blog entries) but in the meantime I thought it best to have a spare TI.

    I also purchased 12 cartridges, 2 joysticks and a speech synthesiser.

    The following are my Cartridge Collection as at 6th December 2015. I will update this as I go alone. My aim is to actually find the time to create my own cartridge, hopefully with a decent game or utility to share with the community.

    My collection is:
    TI Invaders Munch Man Burger Time Alpiner Blasto Super Demon Attack Car Wars Othello Parsec Chrisholm Trail Return to Pirates Isle Jawbreaker II




  6. Davvel

    Scott Adams

    By Davvel,

    Scott Adams is a familiar name in the TI community, outside of this community one could mix him up with the other Scott Adams who writes comic strips about Dilbert and although they are both story tellers in some way our Scott is not just a story teller but an expert coder and creator of the adventure style games.
     
    Scott Adams, the genius behind many Text adventure games was brought up in Miami Florida. In 1975 he wrote a computer game on a computer that his brother Richard built a year before, making him the first person on earth to write a computer game on a home computer. The full story of how Richard came to build this machine, well before Steve Wozniac built Apple 1 can be read in great detail in the link below:
     
    http://exoticsciences.com/sa.htm
     
    The following is a writeup given to me directly from Scott Adams himself. At first I intended to polish it up but then I realised that this in itself is a part of history that should remain as intact as possible.
     
    "I grew up in North Miami Beach and always had a love for science, I remember as a child in the early 60s going on a tour of the University of Miami and seeing the computer science department and waiting to go inside. I was active in local science fairs and won some awards as well as being written up in articles in the newspaper. IN high school as an experiment the state of Florida allowed one remote terminal in our high school math lab to the U of M mainframe and it was running APL/360. My first major program was tic tac toe that would always win. I would go into school before it opened and had permission to be let in by the janitors and after school I would stay until late, locking up the school behind me.
     
    My brother build from chip slice cpus a homebrew computer which I then programmed in machine language a game for (more info on my webpage on a sidebar on this). I also had the first ever Sphere computer homekit which I then proceeded to mod with a my own designed graphics card and wrote a tank war game for. I won the first ever “what do you use your Sphere for” contest with the company.
     
    I was working at Stromberg Carlson in lake Mary Fl as a software engineer when I purchased my first “appliance” computer, ie a computer I didn’t have to build to use J I wanted to learn the BASIC language on it and thought the concept of strings was interesting so I wanted to write a game that let you use English language somehow. At work the IT dept got a copy of Crowther and Woods Adventure! And I was able to get a password to play it. I came in all week before work ad stayed at night to play until I beat it. I decided I want to write a similar game for my TRS-80 model I. Other engineers there laughed at me and said this was running on the mainframe and my toy computer could never handle it. I ended up invented my own language which I emulated in BASIC and wrote my first Adventure game.
     
    Before Stromberg, I got my degree in Computer Science for Florida Institute of Technology (now known as Florida Tech). I worked downrange on the Air Force Eastern Test Range as a Space Object Identifier Analyst at radar stations. But there was a mainframe there and I loved to program so I got permission to make some major mods to the software they were using even though I wasn’t hired as a programmer. I got a number of commendations for some things I did. At one radar station on Antigua Island they only ran it for the day shift, so I was able to use the machine in the evenings for myself. I got a copy of a Fortran Star Trek game that played on the teletype. I then proceed to covert it to run on the radar screens instead and in effect turned the multi-millionaire dollar radar tracking station into a giant video game J great fun.
     
    Return to Pirates Island was written in my own proprietary database adventure language like all my adventure games. I wrote them on one machine then transferred the databases to other machines to execute. RTPI was special in it was originally only for the TI and also was the world’s first adventure game to have graphics in a game cartridge. I also developed a special program to be able to get the graphics to fit. Instead of graphical compression as used today I came up with making the pictures of pieces of other pictures and then having an artist make this picture based on these smaller pieces. It ran very fast but was very labor intensive for the poor artist as you might imagine."

     
    I thank Scott for sending me this small Bio. He is a very humble and inspiring person, one who gave us many hours of entertainment and made our world a little better.
     





  7. Davvel
    I was wondering how many active TI 99/4A community members still exist in 2016.
     
    I could not find a simple way of knowing so I thought of having a central dedicated blog entry which we can share with anyone who we know is a TI user and tell them to like this page.
     
    They can then comment on this blog and tell us some details about themselves.
     
    Example: Name, Surname, Age, Country, Year when they first had a TI 99/4A, How many TI 99/4A machines they have, Maybe the entire inventory of TI stuff they have (brag a little), If they use the TI to develop software or play games, if they are just collectors, if they still develop or used to develop, a small personal story related to the machine, etc....
     
     
    Please do NOT like this page if you are not a TI 99/4A fan.
     
  8. Davvel

    TI 99/4A Memory Map

    By Davvel,

    TI-99/4A Memory Map

    >0000 Console Rom;
    Interrupt vectors, XOP vectors
    GPL Interpreter, Floating
    POINT routines, XMLINK vectors,
    >1FFF Low-level cassette DSR etc.
    >2000 Low Memory Expansion Ram;
    Varies according to the loader
    used (Assembly). Generally
    >3FFF not used by XBASIC programs.
    >4000 DSR ROM;
    Device service routines.
    Determined by CRU bit setting
    >5FFF Disk Controller, RS232 etc.
    >6000 Cartridge Port (ROM & MINI MEM)
    12k of XBASIC ROM. Upper 4k
    @ >7000 - >7FFF is flipped to page in another 4k for a
    >7FFF total of 12k.
    >8000 RAM Memory Mapped Devices - VDP,GROM, SOUND, SPEECH.
    >8000 Duplication of scratch pad RAM at >8300 - >83FF
    >8100 Dup. as above
    >8200 again
    >8300 Scratch Pad RAM
    >8400 Sound Chip
    >8800 VDP READ DATA
    >8802 VDP STATUS
    >8BFF
    >8C00 VDP WRITE DATA
    >8C02 VDP READ/WRITE ADDRESS
    >8FFF
    >9000 SPEECH READ
    >93FF
    >9400 SPEECH WRITE
    >97FF
    >9800 GRON/GRAM READ DATA
    >9802 GROM/GRAM READ ADDRESS
    >9BFF
    >9C00 GROM/GRAM WRITE DATA
    >9C02 GROM/GRAM WRITE ADDRESS
    >9FFF
    >A000 HIGH MEMORY EXP RAM XBASIC high memory usage, Free space end pointed to by CPU RAM PAD address >8366
    Numeric Values
    Line Number Table
    XBASIC Program Space >FFFF for a total of 24k bytes.
    Additional Memory Space not in the CPU address space;
    VDP RAM >0000 - >3FFF 16k bytes.
    This is the console RAM space, and is separate from the rest of the CPU memory. Without memory expansion, XBASIC and BASIC programs reside here (BASIC does not use expansion memory.) (Assembly language does not use this area.)

    BASIC does not use memory expansion at all. Only XBASIC, Assembly, FORTH etc. use it.
    Chunks of memory are used by various peripherals as buffers, thus the amount indicated by CALL SIZE is right.

    By using CALL FILES(1) followed by NEW, you can get back some, but disables the disk system. If you don't have it installed, but have mem exp. you will have more memory to use automatically.


    Original Source as posted on July 8th 1984 by Gene Sampieri

    The following is priceless as found in the below address:
    http://www.unige.ch/medecine/nouspikel/ti99/tms9918a.htm#Registers

    VDP memory
    The videoprocessor has 16K of private RAM that it used to store the screen image, the character patterns and colors, and the sprite characteristics. Unless it is used in bit-map mode, only a small portion of this memory is effectively needed. The remaining is therefore available for use by the CPU. However all reading and writing operations must be carried on by the videoprocessor. The CPU passes the required address to the VDP as two bytes at address >8C02, and can then read bytes from >8800 or write bytes at >8C00. The VDP increments an internal pointer after each read/write operation. Contrarily to the GROMs, one cannot retrieve the value of this pointer from the VDP. Instead, address >8802 is used to read the VDP status register. This is definitely a slow way to access RAM, but it probably allowed to market the TI-99/4A at a much lower price, since RAM was fairly expensive in the 80s.


    VDP registers
    The first eight registers are used by the CPU to control the VDP. Very unfortunately, these are write-only registers, which means there is no way to determine the current display mode, unless it has been saved somewhere in RAM by the program that set it. Registers 0 and 1 contains control bits, registers 2 to 6 contains pointers to various tables in the VDP RAM and register 7 encodes 2 colors.
    The VDP also contains a read-only status register that is uses to pass various information to the CPU.
    VDP register 0
    This register contains two control bits. All other bits must be zero. The register contains >00 after a reset.
    Bit 6 (weight >02) selects a bitmap graphics mode when set to 1. VDP register 1 determines which bitmap mode is used.
    Bit 7 (weight >01) enables external video input when set to 1.
    VDP register 1
    This register contains 7 control bits. All are set as 0 after a reset.
    Bit 0 (weight >80) selects the memory size. For 4K of memory the bit is 0, for 16K it is 1.
    Bit 1 (weight >40) enables the screen. When this bit is 0 the screen is blank.
    Bit 2 (weight >20) enables interrupts. When this bit is 1, the VDP issues interrupt signals on the INT* pin each time it resumes refreshing the screen (vertical retrace signal).
    Bit 3 (weight >10) selects text mode when set as 1. Bit 7 of register 0 can be set for bitmap text mode.
    Bit 4 (weight >08) selects multicolor mode when set as 1. Bit 7 of register 0 can be set for bitmap multicolor mode.
    If both bits 3 and 4 are 0, the display is in standard mode (or in bitmap mode, depending on register 0). Bits 3 and 4 should never be set together.
    Bit 5 (weight >04) is reserved and should be 0.
    Bit 6 (weight >02) selects the sprite size. When 0, sprites are 8x8 pixels. When 1, sprites are 16x16 pixels.
    Bit 7 (weight >01) selects sprite magnification. When this bit is 1, each sprite pixel is replaced by a 2x2 pixels box.
    VDP register 2
    Defines the location of the screen image table. Only the last 4 bits are used, thus possible values for this register are >00 throught> 0F. The value is multiplied by >400 to find the location of the screen image table in the VDP memory. This table contains 1 byte for each character position on the screen (left to right, downwards), this byte contains the character number.
    VDP register 3
    Defines the location of the color table. Possible values are >00 through >FF and are multiplied by >40 to find the location of the color table. The table is not used in text mode, nor in multicolor mode.
    In bitmap mode (i.e. when bit 6 in register 0 is set) the meaning of this register changes: bit 0 (weight >80) is the only one used to determine the address of the color table, which means the table has only two possible locations: >0000 or >2000. The remaining bits are used to define the table size, by the way of an address mask. This is done as follows: the righmost 7 bits are shifted left by 6 positions, filling the rightmost bits with 1s. The result will be a number between> 003F and >1FFF, which is ANDed with the address of a character in the table. As a result, the table can have any size between >40 and> 2000 bytes (however, note that the maximal usable size is >1800: 3 times >800 bytes).
    VDP register 4
    Defines the location of the character pattern table. Only the last 3 bits are used, thus possible values are >00 through >07. The value is multiplied by >800 to find the location of the character pattern table. Each entry in the table is eight bytes long and define the pattern of a character, in numeric order. Each byte in an entry defines one line of pixels in the character pattern: bits set as 1 result in foreground color pixels, bits set as 0 encode background color pixels.
    In text mode (i.e. when bit 3 in register 1 is set) the last two bits of each byte are ignored since characters are only 6-pixel wide.
    In bitmap mode (i.e. when bit 6 in register 0 is set) the structure of this register changes: bit 5 (weight >04) is the only one used to determine the address of the color table, which means the table has only two possible locations: >0000 or >2000. The two rightmost bits are used to determine the length of the table, by the way of an address mask. This is done by shifting them 11 positions to the left, filling the righmost bits with 1s. The result will be a number between >07FF and >1FFF that will be used as an address mask. At least, this is what happens in bitmap + text mode (i.e. when bit 3 of register 1 is set). In standard bitmap mode, the righmost bits are not necessarily 1: they are taken from VDP register 3, i.e. the address mask of the color table is used for both the color table and the pattern table addressing.
    VDP register 5
    Defines the location of the sprite attributes table. Only the last 7 bits are used, thus possible values are >00 through >7F. The value is multiplied by >80 to find the location of the sprite attributes table. Each entry in the table is four bytes long and defines a sprite position and color, in numerical order of sprites. See the chapter on sprites for a detailed description of this table.
    VDP register 6
    Defines the location of the sprite pattern table. Only the last 3 bits are used, thus possible values are >00 through >07. The value is multiplied by >800 to find the location of the sprite pattern table. Each entry in the table is eight bytes long and defines the pattern of a sprite, one byte per line. Bits that are set as 1 result on a pixel of the color defined for that sprite in the sprite attributes table, bits that are 0 result in a transparent pixel. If the large sprite size is selected (bit 6 in register 1 is set as 1) each entry is 32 bytes long and define a sprite as a set of 4 characters arranged as:
    1 3
    2 4
    VDP register 7
    The first nibble of this register defines the color of all characters in text mode. It is not used in the other modes.
    The second nibble defines the background color wich is used for all characters in text mode. In all four modes it defines the color of the backdrop plane: this is the color of the screen outside the display area and the color that appears under transparents characters. When this color is set as transparent the external video image appears if it is enabled, black color appears otherwise.
    Status register
    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.
    Summary of the VDP registers contents
    Bit:
    Weight: 0
    > 80 1
    > 40 2
    > 20 3
    > 10 4
    > 08 5
    > 04 6
    > 02 7
    > 01 VR0 0 0 0 0 0 0 Bitmap Ext vid VR1 16K Blank Int on Multic Text 0 Size 4 Mag 2x VR2 0 0 0 0 Screen image VR3
    bitmap Color table Addr Address mask VR4
    bitmap 0 0 0 0 0 Char pattern table 0 0 0 0 0 Addr Address mask VR5 0 Sprite attributs table VR6 0 0 0 0 0 Sprites pattern table VR7 Text color (in text mode) Backdrop color Status Int 5+ sp Coinc 5th sprite number

    Video modes Standard mode (Graphic I)
    This mode is selected by setting all mode bits as 0: bit 7 in register 0 and bits 3 and 4 in register 1. VR0: 0 VR1: 0 0
    In this mode, the screen is divided into 24 rows of 32 characters. Each character is 8x8 pixels and has two colors: one for the "on" pixels (foreground color), one for the "off" pixels (background color). If a color is set as 0, the color of the backplane will be used (defined by register 7).
    The screen image table is thus >300 bytes long (24x32=768). Each byte in the table contains the number of the character to display at the corresponding position on screen. This number is used to locate the character pattern in the pattern table and to look up its colors in the color table.
    The color table is 32 bytes long. Each byte encodes the two colors for a group of 8 consecutive characters in numeric order (i.e. the first byte affects characters 0-7, the second characters 8-15, etc). In each byte, the first nibble encodes the foreground color, the second nibble the background color.
    The character pattern table contains 256 entries, one per character in numeric order. Each entry is eight bytes long, each byte defines the pattern of one pixel row in the character: "1" bits set the pixel to the foreground color used for this character group, "0" bits set the pixel to the background color of this character group.
    --------| | 00000000 = >00| *** | 00111000 = >38| * * | 01000100 = >42| * * | 01000100 = >42| *** | 00111000 = >38| * | 00010000 = >10| *** | 00111000 = >38| * | 00010000 = >10 --------
    The pattern table entry for the above character would be: >00 38 42 42 38 10 38 10
    Sprites can be used in standard mode, see below.
    Text mode
    This mode is selected by setting bit 3 of VDP register 1 as 1. Bit 4 must be 0, as well as bit 7 of register 0. VR0: 0 VR1: 1 0
    In this mode, the screen is devided into 24 rows of 40 characters. Each character is made of 8 rows of 6 pixels. All characters have the same two colors, defined by VDP register 7.
    The screen image table is >3C0 bytes long (24x40=960).Each byte in the table contains the number of the character to display at the corresponding position on screen. This number is used to fetch the character pattern from the pattern table.
    The color table is not used. The foreground color for each character is taken from the first nibble of VDP register 7, the background color is transparent, which lets the backdrop plane color appears. As the backdrop color is encoded by the second nibble of VDP register 7, one can consider that this register specifies both the foreground and background colors for each character.
    The pattern table is organized just as in standard mode, except that the last two bits of each byte are ignored since characters are only 6-pixels wide in text mode.
    ------| | 000000xx = >00| *** | 001110xx = >38| * *| 010001xx = >42| * *| 010001xx = >42| *** | 001110xx = >38| * | 000100xx = >10| *** | 001110xx = >38| * | 000100xx = >10 ------
    Sprites are not available in text mode.
    All this makes text mode the least memory-hungry mode: only a maximum of 3008 bytes (>0BC0) of VDP RAM is required in this mode. This can be further reduced by not using all 256 characters and/or by partly overlapping the tables.
    Multicolor mode
    This mode is selected by setting bit 4 of VDP register 1 as 1. Bit 3 must be 0, as well as bit 7 of register 0. VR0: 0 VR1: 0 1
    In this mode, the screen is divided into 48 rows of 64 boxes. Each box is 4x4 pixel and can be independently assigned a color. The screen image table is still >300 bytes long, but each byte now represent a "character" made of 4 boxes. The boxes are arranged as:
    0 1
    2 3
    The color of the boxes are defined in the character pattern table (!). Each entry in the table is 8 bytes long but only 2 bytes are used to define the colors of the 4 boxes that make up a character: >01 >23. To avoid wasting 6 bytes in each entries, the characters on 4 consecutive rows use the same entry, with an offset of 2 bytes:
    characters on row 0, 4, 8, 12, 16 and 20 use bytes 0 and 1,
    characters on row 1, 5, 9, 13, 17 and 21 used bytes 2 and 3,
    characters on row 2, 6, 10, 14, 18 and 22 used bytes 4 and 5,
    characters on rows 3, 7, 11, 15, 19 and 23 use bytes 6 and 7.
    This reduces the size of this table to 1536 bytes (24 rows x 32 columns x 8 bytes).
    The color table is not used in multicolor mode.
    Sprites can be used in this mode.
    To summarize, the screen organisation is the following:
    Column: 0 1 ... 31
    Row 0: a b q r ... c d s tRow 1: e f u v g h w xRow 2: i j y z k l ...Row 3: m n o p
    The corresponding screen image table could be:
    Column: 0 1 ... 31
    Row 0: >00 >01 ... >1F Row 1: >00 >01 >1F Row 2: >00 >01 >1F Row 3: >00 >01 >1F
    Row 4: >20 >21 >3F
    ...
    And the pattern table would look like this (letters a-z represent the color of a given box, i.e. a digit in the range >0-F):
    Byte: 0 1 2 3 4 5 6 7Row: 0 1 2 3___
    Entry >00: >ab >cd >ef >gh >ij >kl >mn >op
    Entry >01: >qr >st >uv >wx >yz ...
    ...
    This mode is fairly complicated to use (and does not yield very interesting results). A way to simplify it is to fill the screen with fixed character numbers, as shown in the above example. Drawing is then achieved by changing the color values in the character pattern table. Arranging the character numbers as in the example makes easier to calculate which byte must be changed in the pattern table, but there are other solutions.
    Bitmap mode (Graphics II)
    I'm sure every TI user had this great idea one day or the other: "Hey, lets fill the screen with all available characters: 0, 1, 2, etc. Then I can draw pixel-by-pixel by just changing definitions in the character pattern table". If you have tried, you must have realised there is a big problem: with 256 characters, we can only cover 1/3 of the screen. Not to mention the fact that the color table defines 8 characters at a time, which makes color drawings almost impossible. Bitmap mode takes care of these problems (sort of).
    This mode is selected by setting bit 7 of register 0 as 1. Bits 3 and 4 in register 1 should be 0. VR0: 1 VR1: 0 0
    In this mode, the screen is still devided in 24 row of 32 character, just as in standard mode. However, we now have three character pattern tables, one after the other: the first table applies to characters displayed in the top third of the screen (i.e. the first >100 bytes in the screen image table), the second to characters displayed in the middle third (bytes> 100-1FF) and the third to characters displayed in the bottom third of the screen (bytes >200-2FF in the screen image table).
    Now we can fully cover the screen with non-redundent characters, by just writing >00, >01, >02 ... >FF three times in the screen image table. As the three pattern tables are consecutive, it is easy to calculate which byte is to be accessed to modify a given pixel.
    There are also three color tables, arranged in the same way as pattern tables. Each entry in a table is eight bytes long and defines the colors for one character. Each byte in an entry defines the colors of a row in the character: the first nibble sets the pixel color for bits that are set as 1 in the pattern (foreground), the second sets the pixel color for the 0 bits in the pattern (background). The major drawback of this system is that each line of pixels in the display is chopped into 8-pixels clusters for which there is only a choice of two colors. This forces us to pay a lot of attention when drawing complex images, as 3 colors in a given pixel line must be at least 8 pixels appart.
    Sprites are available in bitmap mode and work just as in standard mode.
    Not so surprisingly, bitmap mode is extremely memory-hungry: it requires> 3300 bytes, not counting sprite tables.
    To summarize, here is an example showing the correspondance between screen, pattern table entry and color table entry:
    Screen Pattern table Color table B 1 B B B B B 1 0 1 0 0 0 0 0 1 1 (black) B (l.yellow)B B 7 B B B 7 B 0 0 1 0 0 0 1 0 7 (cyan) BB B B C B C B B 0 0 0 1 0 1 0 0 C (green) BB B B B E B B B 0 0 0 0 1 0 0 0 E (gray) BB B B B 8 B B B 0 0 0 0 1 0 0 0 8 (m.red) BB B B B 5 B B B 0 0 0 0 1 0 0 0 5 (l.blue) BB B B B 6 B B B 0 0 0 0 1 0 0 0 6 (d.red) B2 2 2 2 D 2 2 2 0 0 0 0 1 0 0 0 D (magenta)2 (m.green)
    The VDP register setting could be the following:
    VR0 >02 Bitmap mode on
    VR1 >C0 16K, screen on
    VR2 >08 Screen image at >1800 (we can't have it at >0000 since either the pattern or the color table must be there)
    VR3 >FF Color table at >2000, address mask = >1FFF (full size table: 3 times >800 bytes)
    VR4 >03 Pattern table at >0000, address mask = >1FFF (full size table: 3 times >800 bytes)
    Hybrid bitmap modes
    Note that the trick of covering the screen with three repeats of characters 0-255 is just an easy way to calculate which byte corresponds to which pixel, this is by no means an obligation. You could use the tables just the way you do in standard mode: having fixed pattern definitions (and colors) and placing a character number in the screen image table to display it. The address masking trick becomes very handy in this case. Rather than having three copies of the pattern table one after the other, let's just have one and set the address mask to 0: in the example above, VR4 would become >00. The advantage over standard mode is that we can set different colors for each character (rather than for a group of . In fact, we can even set a color pair for each pixel row in a character: this is a nice way to create iridescent characters!
    Finally, both solutions can be mixed in the various thirds of the screen: the top two thirds could be arranged for easy bitmap drawing, whereas the bottom third could be arranged for rapid character writing. Some games use this solution to display prompts and scores at the bottom (or top) of the game screen.
    You can use the mask bits in register 4 to assign a >800-byte pattern table to each third of the screen:
    > 00 (or >04): only one pattern table, identical for each third of the screen.
    > 01 (or >05): two pattern tables. One at >0000 (or >2000) for the 1rst and 3rd thirds, one at >0800 (or >2800) for the middle third of the screen.
    > 02 (or >06): two pattern tables. One at >0000 (or >2000) for the 1rst and 2nd thirds, one at >1000 (or >3000) for the bottom third of the sceen.
    > 03 (or >07): three pattern tables. One at >0000 (or >2000) for the 1rst third, one at >0800 (or >2800) for the 2nd third and one at >1000 (or >3000) for the bottom third of the screen.
    Then we could do the same for the color table, using bits 1 and 2 (weight> 40 and >20) to select the number of tables. The remaining bits will affect character grouping within a table. Since they also affect grouping whitin the pattern table, we'd better be carefull with these!
    In summary, these would be the addresses of the tables in 8 possible situations:
    VR3 VR4 Mask Top 3rd Middle 3rd Bottom 3rd >1F >00 >07FF >0000 >0000 >0000 >9F >04 >07FF >2000 >2000 >2000 >3F >01 >0FFF >0000 >0800 >0000 >BF >05 >0FFF >2000 >2800 >2000 >5F >02 >17FF >0000 >0000 >1000 >DF >06 >17FF >2000 >2000 >3000 >7F >03 >1FFF >0000 >0800 >1000 >FF >07 >1FFF >2000 >2800 >3000

    To group characters within a table, we could further alter the color table mask:
    VR3 = >0F results in >400-byte tables. This means that characters> 80-FF will have the same colors and definitions than characters> 00-7F. VR3 = >07 results in >200-byte tables. This means that characters> 40-7F, >80-BF and >C0-FF will have the same colors and definitions than characters >00-3F. At the extreme, VR3 = >00 results in >40-byte tables. As there are 8 bytes per characters, this means characters are arranged in 8 groups of 32 identical characters: chars 0-7 are identical to chars 8-15, 16-23, etc. We could even get weird grouping schemes by using values like> 02,> 04, >55, etc.

    The table below lists the six most logical values, plus two gooffy ones (just for fun).
    VR3 Mask Character grouping Chars Repeats >00 >003F 0=8=16...=248
    1=9=17...=249
    7=15=23...=255 8 32 >01 >007F 0=16=32...=240
    1=17=33...=241
    15=31=47..=255 16 16 >03 >00FF 0=32=64...=216
    1=33=65...=217
    31=63=95...=255 32 8 >07 >01FF 0=64=128=192
    1=65=129=193
    63=127=191=255 64 4 >0F >03FF 0=128
    1=129
    127=255 128 2 >1F >07FF Each char is unique 256 1 >02 >00BF 0=8=32=40...
    4=12=36=44... 16 16 >04 >013F 0=8=16=24=64...
    32=40=48=56=96... 16 16



    Bitmap text mode
    This is the mode TI forgot to tell us about. It works just like standard bitmap mode, except that the screen is now 40 columns and that only two colors are available.
    This mode is selected by setting bit 7 of register 0 as 1. Bit 4 in register 1 should be 1. VR0: 1 VR1: 0 1
    The screen is now divided in three, each third is 8 lines high and thus occupies >140 bytes in the screen image table (8*40=320).
    The colors are taken from VR7, just like in regular text mode. There is no color table, and the contents of VR3 is irrelevant.
    Just like in standard bitmap mode, there can be upto 3 pattern tables, located either at >0000 or at >2000. You can use the address mask bits in VR4 to determine which third of the screen uses which table. The main difference is that the color address mask is not used to fill-in the patten address mask: >07FF is always used instead. No character grouping to worry about, then! This mode comes handy for black-and-white drawings.
    Bitmap multicolor mode
    Another undocumented mode. It works as a mixture of bitmap and multicolor mode.
    This mode is selected by setting bit 7 of register 0 as 1. Bit 3 in register 1 should be 1. VR0: 1 VR1: 1 0
    The screen is now divided in three, each third is 8 lines high and thus occupies >100 bytes in the screen image table (8*32=256).
    Just like in standard multicolor mode, there is no color table and the contents of VR3 is irrelevant.
    The color of the boxes are taken from upto 3 pattern tables, located either at >0000 or at >2000. You can use the address mask bits in VR4 to determine which third of the screen uses which table. Since a single table would be sufficient for this purpose, there is no real point in using this combined mode...

    Illegal modes
    It is not allowed to set text and multicolor mode together, whether in bitmap mode or not. VR0: x VR1: 1 1
    If you try, the VDP will display a fixed image, that is not influenced by the contents of the VDP memory, nor by registers VR2 to VR6 (sprites are not available). The screen is 192 pixel lines and 40 columns. Each column is made of 4 pixels in foreground color, followed by 2 pixels in backgroud color. These two colors are taken from VR7.
    Sprites
    Sprites are special characters that can be displayed at any position on screen, i.e they are not limited to a grid or rows/column, instead each sprite position can be defined with a precision of one pixel.
    Sprites can be either 8x8 pixels or 16x16 pixels depending on the setting of bit 6 in VDP register 1: when this bit is 0 all sprites are 8x8, when it is 1 all sprites are 16x16. In addition, bit 7 in VDP register 1 provides a mgnification feature: when this bit is 1 all sprites are magnified by a factor of two. Concretely this means that each "pixel" becomes a 2x2 pixels box.
    Each sprite can have its own foreground color. The background color is always transparent, which lets the underlying image appear under the sprite.
    Upto 32 sprites can be displayed at a time. Each one can be seen as an extra image plane on the top of the screen, overlapping each others, with sprite number 0 at the top. Thus the virtual image planes are:
    - Black
    - External video
    - Backdrop plane (color in VDP reg 7)
    - Image plane (characters)
    - Sprite number 31
    - Sprite number 30
    - etc upto:
    - Sprite number 0
    There is one restriction however: the VDP cannot display more than 4 sprites on a given line of pixels. Thus, if 5 sprites or more must be drawn on the same line, only the topmost four (those with the smallest numbers) can be displayed. The number of the 5th one is placed in the status register together with a flag bit and the others are ignored. This occurs whether or not the sprites are actually overlapping: one could be on the left of the screen, the other on the right with the same result.
    Coincidence is a different condition: whenever two "on" pixels in different sprites occupy the same screen location, a bit is set in the VDP status register. This comes handy for games programming: an easy way to check whether the bullet hits the target. Note however that the VDP does not tell you which are the overlapping sprites...
    Sprites characteristics are defined in two tables pointed by VDP registers 5 and 6: the sprite attributes table and the sprite patterns table.
    Sprite attributes table
    This table is pointed at by VDP register 6. It contains upto 32 entries for the 32 sprites arranged in numeric order. Each entry is four bytes long, thus the maximum size for this table is >100 bytes. The four bytes define sprite characteristics as follows:
    Byte 1 Byte 2 Byte 3 Byte 4 Sprite 0 vertical position -1 horizontal position pattern number clock bit sprite color Sprite 1
    "
    "
    "
    "
    "

    Sprite positions are expressed in pixels relative to the top left corner of the display area. This will be the position of the top leftmost pixel of the sprite (unless the early clock bit is set, see below). Note that the vertical position coordinate in the table is offset by one: therefore the topmost pixel line is >FF, the second is >00, the third is> 01 and the last is >BE. Any sprite whose vertical position is greater than> BE won't be visible on screen, although coordinates close to >FF can result in the bottom of the sprite appearing at the top of the screen. Similarly, row values just under >BE result in partly blending off the bottom of the sprite.
    The same thing is true for sprite approaching the right border of the screen (horizontal coordinates close to >FF): the sprite appears to blend-in from the right. However this won't work on the left of the screen: when the horizontal position is 0 the whole sprite is visible, when it's lower than 0 (i.e. >FF, >FE, etc), the sprite appears at the right of the screen. To allow for sprite blend-in from the left of the screen one can set the "early clock" bit (bit 0, value >80) in the color byte: the horizontal coordinate now refers to a point located 32 pixels to the right of the upper left corner of the sprite. This results in shifting the sprite 32 pixels to the left and allows for partial disappearance on the left side (but not any more on the right).
    The pattern number refers to the entry containing the sprite pattern in the sprite pattern table.
    Finally the sprite color is defined by the right nibble in the byte 4 of the entry.
    The sprite attributes table does not need to define all sprites: if the vertical position of a sprite is set as >D0, the sprite won't be displayed (as it's off-screen), but neither will any of the following sprites. This comes handy to quickly erase all sprites by just changing one byte in the attributes table.
    Sprite pattern table
    This table contains patterns to be used by the various sprites, arranged in ascending order. Each entry is either 8 bytes long or 32 bytes long depending on the sprite size.
    If the sprite size is set as 8x8, entries are 8 bytes long. Each byte defines a row in the sprite: "1" bits result in pixels of the color specified for that sprite in the attributes table, "0" bits encode transparent pixels and are ignored for display purposes.
    If the sprite size is set as 16x16 (VDP register 1, bit 6 set as 1) each entry is 32 bytes long. These bytes define the sprite pattern as if it were made of four "normal sprites" arranged in a 2x2 formation:
    1 3
    2 4
    Thus, bytes 0-7 define the top left quadrant, one byte per line of 8 pixels. Bytes 8-15 define the bottom left quadrant in a similar fashion. Bytes 16-23 define the top right quadrant, one byte per line of 8 pixels (which now corresponds to pixels 9-15 of the sprite rows 0-7) and bytes 17-23 define the lower right quadrant.
    Even wiith a 16x16 pixels size, 32 sprites require at most >400 bytes (32x32). Thus there is room enough for extra sprite patterns and a sprite can be animated by quickly changing its pattern number in the attributes table rather than by modifying the sprite pattern table.

    Timing issues
    The VDP needs 2 microseconds to read or write a byte to its RAM. In addition, it can only communicate with the CPU at precise moments, when it is not too busy with building the screen. Such moments are known as CPU access windows and may arise at various intervals depending on the video mode. In standard or bitmap mode, a window occurs every 16 memory cycles, each cycle being 372 ns long. This means the VDP may have to wait upto 5.95 us before a CPU access window occurs. Adding the 2 us needed for RAM access gives us a maximum delay time of 8 us. Of course, it can be as fast as 2 us if a window just happens to open (even less for reading operations, thanks to the read-ahead buffer). In text mode, a window opens every three memory cycles, i.e. at intervals of 1.1 us. In multicolor mode, a window opens every four memory cycles, i.e. at 1.5 us intervals.
    There are two exceptions to these rules, however:
    When the screen is blank (because bit 1 in register 1 is set as 0) the VDP does not handle the screen and a CPU access window is permanently open. Consequently, there is no wait time. When the VDP is done with drawing a frame and enters vertical refresh mode it issues an interrupt (if enabled) and opens a 4.3 milliseconds (4300 us) window for CPU access.

    Condition Mode RAM access
    delay Time waiting
    for a window Total delay Building screen Standard
    / Bitmap 2 us 0 - 5.95 us 2 - 8 us Building screen Text 2 us 0 - 1.1 us 2 - 3.1 us Building screen Multicolor 2 us 0 - 1.5 us 2 - 3.5 us Vertical retrace Any 2 us 0 2 us Blank screen Any 2 us 0 2 us

    Contrarily to standard memory, the VDP cannot hold the CPU in a wait state until it is ready to accept/send data. This means that the application program must contain appropriate delays to prevent the CPU from going on with the next operation before the VDP has completed the current one. A typical example is passing the two command bytes to the VDP: using two successive MOV instructions is too fast and the second byte won't be read. The program should thus contain another instruction in between the two MOV (such as a NOP or a SWPB).
    Programming examples

    *------------------------------------------------------------* VDP write to register. * Expects register # in R0 MSB and register content in R0 LSB*------------------------------------------------------------VWREG ORI R0,>8000 Set command bits as 1xxx xrrrCMD SWPB R0 Send a command to the VDP MOVB R0,@>8C02 Send first byte (least significant) SWPB R0 Delay MOVB R0,@>8C02 Send second byte (most significant) B *R11*------------------------------------------------------------* VDP set address to write in RAM* Expects address in R0*------------------------------------------------------------VAD2WR ANDI R0,>7FFF Make sure command bits are 01xx xxxx ORI R0,>4000 JMP CMD Send command*------------------------------------------------------------* VDP set address to read from RAM* Expects address in R0*------------------------------------------------------------VAD2RD ANDI R0,>3FFF Make sure command bits are 00xx xxxx JMP CMD Send command*------------------------------------------------------------* VDP write byte to RAM* Expects data byte in R0 MSB and address set by VAD2WR*------------------------------------------------------------VWRBYT MOV R0,@>8C00 Send data to VDP B *R11 Delay*------------------------------------------------------------* VDP read byte from RAM. Assumes address was set by VAD2RD* Result will be in R0 MSB*------------------------------------------------------------VRDBYT MOV @>8800,R0 Get data byte B *R11 Delay*------------------------------------------------------------* VDP read status. Result will be in R0 MSB*------------------------------------------------------------VRDSTA MOV @>8802,R0 Read status register, resets bits 0-2. B *R11 Delay

    http://www.unige.ch/medecine/nouspikel/ti99/architec.htm




AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...