Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
4Activity
0 of .
Results for:
No results containing your search query
P. 1
Discussion About the MSX VDP TMS9918A

Discussion About the MSX VDP TMS9918A

Ratings: (0)|Views: 269 |Likes:
Published by 65c02
Where Paul Urbanus explain how the MSX VDP processor works.
Where Paul Urbanus explain how the MSX VDP processor works.

More info:

Published by: 65c02 on Oct 19, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/25/2013

pdf

text

original

 
Subject: Re: Z80 emulator to learn assembly?From: Paul Urbanus <urb@onramp.net>Date: 1997/01/31Message-ID: <32F28691.2ADC@onramp.net>References: <32edd486.3490767@news.airmail.net> <5cgr4r$nqb@hecate.umd.edu> <5cipc6$ra9@dinkel.civ.utwente.nl>Content-Type: text/plain; charset=us-AsciiOrganization: OnRamp Technologies; ISP; Dallas/Ft Worth/Houston, TX USAMime-Version: 1.0Newsgroups: comp.emulators.misc,comp.os.cpmX-Mailer: Mozilla 3.01 (Win16; I)Marcel de Kogel wrote:>> On 26 Jan 1997 23:59:23 GMT, marat@Glue.umd.edu (Marat Fayzullin)> wrote:>> >Rogers Cadenhead (rcade@airmail.net) wrote:> >: I am learning Z80 assembly language programming so that I can write> >: some new Colecovision games and figure out how some of my old> >: favorites were written.> >> >: What's the best Z80 emulator I can find for DOS or Win95 that I can> >: use to run the programs I'm writing? I've read that CPM emulators are> >: the best choice.> >As you are going to write Colecovision programs, a crossassembler+ColEm> >combination will probably be the best. Also, check AdamEm, the Coleco> >Adam emulator by Marcel de Kogel.> >> >Marat>> I'm working on some as well, and while writing them I found some very> interesting features in the VDP design (e.g. there's no such thing as> truly seperate read and write addresses) I didn't find described> anywhere. While I've implemented most in ADAMEm, I didn't find out how> some of this really works (e.g. I get mixed results when reading VRAM> after setting a new write address). This is why I prefer using Mission> and an MSX for testing purposes; In fact, it's why I wrote Mission in> the first place. Of course, final testing is done on the CV itself,> and you'll need an MSX to run Mission natively>> MarcelMarcel,The VDP (Video Display Processor) chip used in the Colecovision and inthe early (MSX-1?) systems was the Texas Instruments TMS9918A, which wasalso used in the TI99/4A Home Computer. This machine came onto themarket in 1980, in the midst of the video game/home computer boom.During that time, I worked for TI as a student, and in 1982 Ico-authored (along with Jim Dramis) a game for the 99/4A called PARSEC,among other things. All of us game programmers always lamented the factthat the VDP memory was 'indirectly' mapped instead of direct, which ofcourse limited the amount of raw bit pushing we could do. Anyway, Ithink the following will (hopefully) clear up your confusion regardingaccessing VDP memory. Note that later versions of the MSX systems(MSX-2?) used a superset of the TI9918A, the YM9938, which was made byYamaha. The following discussion applies only to the TI9918A VDP chip.You are correct when you stated that there is only ONE memory addressregister in the VDP, and this is used for both reading and writing data.Thus, there must be a way to indicate to the VDP whether the addresswhich has been written is to be used for reading or writing data. Thisis done by using one of the upper address bits in the 16 bit address.Since the 9918A can only address 16k bytes of memory, the upper two bitsin the address (A14-A15) will always be zero. While bit 15 (the mostsignificant) is always set to zero, bit 14 is used to distinguishbetween a read and a write address. The following shows how this bitaffects subsequent VRAM data accesses.VRAM address bit 14 | VRAM data access function------------------------------------------------------------------------0 | VRAM address specifies location to read| (initiate the read/increment the address counter)------------------------------------------------------------------------1 | VRAM address specifies location to write| (wait for data write to VDP before actual write| to VRAM, then increment address counter)If you are simply calculating the address for writing data, then usingthat address as the write address without setting bit 14=1, this mightcause some unexpected behavior. If bit 14=0, this will cause the VDP toinitiate a read cycle and then increment the address counter, thusgiving the impression that the "write address" has been set to(address+1). As I stated before, there really is only one addressregister, so when you perform data reads/writes you are affecting thesame register.
http://bifi.msxnet.org/msxnet/tech/tmsposting.tx1 sur 5 18/10/2009 21:33
 
I'm sure that the VDP designers (at TI, anyway) didn't expect people tointerleave data reads and writes without resetting the address, so anyundocumented operation may or may not be supported on all revisions ofthe chip. As will any 'undocumented bugs/features', I'd be concernedabout the implementation of these 'features' in 9918A clones, such asthe Yamaha 9938.Another thing you should be aware of is the timing constraints placed onaddress and data accesses to the VDP RAM. Actual reading/writing of theVDP RAM (VRAM) by the CPU can only occur when the VDP is not reading thememory for the purpose of generating the screen image. In some displaymodes, most of the memory bandwidth is utilized for generating theimage, leaving little time (unfortunately) for the CPU to access memory.The worst case scenario is in graphics modes I,II, where the VDP usesalmost all of the memory bandwidth to generate the screen image. In thismode, only 1 memory access out of 16 is designated for the CPU - therest are allocated for screen refresh.According to the 9918A (VDP) Data Manual, there are two timingconstraints to be followed when access VRAM.1. After the second address byte (MSByte) has been written to the VDP,there must be a 2 microsecond wait before any data read/write accessescan occur. This constraint ALWAYS applies, no matter which display modeis in effect or which part of the screen (active video, verticalsync/blanking) is being displayed. In the table below, this is referredto as 'VDP Delay'.2. The second timing constraint depends on which display mode is activein the VDP, and which part of the screen (active video, verticalsync/blanking) is being displayed. The following table shows thesetiming constraints. In the table, this second delay constraint isreferred to as 'Time waiting for an access window'.| | VDP | Time waiting for | TotalCondition | Mode | Delay | an access window | time------------------------------------------------------------------------Active Display Area | Text | 2 us | 0 - 1.1 us | 2 - 3.1 us------------------------------------------------------------------------Active Display Area | Graphics | 2 us | 0 - 5.95 us | 2 - 8 us| I,II | | |------------------------------------------------------------------------4300 us after | All | 2 us | 0 us | 2 usVertical Interrupt | | | |------------------------------------------------------------------------Register 1, bit 1=0 | All | 2 us | 0 us | 2 us(display is blanked)| | | |------------------------------------------------------------------------Active Display Area | Multicolor | 2 us | 0 - 1.5 us | 2 - 3.5 us------------------------------------------------------------------------Examination of the above access window table yields the followingobservations.1. Always try to do massive VRAM moves during the vertical retraceperiod, since that is when max memory bandwidth is available to the CPU,theoretically 500 Kbytes/sec. This is especially important in Graphicsmodes I & II, which will be used for almost ALL games. Theoretically,one can move (4300 us/2 us) 2150 bytes to/from the VRAM in one verticalblanking time.2. If you need to move lots of data, such as completely changingscreens, set the blanking bit it VDP register 1 to 0, then read/writethe data.WHY DOES THE VDP NEED SO MUCH BANDWIDTH TO REFRESH THE SCREEN,AND OTHER STUFF YOU REALLY DON'T NEED TO KNOW ABOUT THE 9918A?--------------------------------------------------------------The following is provided as additional background information, and maybe considered excess, but I give for it those who might want tounderstand how the bandwidth is used in Graphics modes I & II.First, consider the overriding considerations for the guys who did the9918A chip design. Of course, the part must function, but moreimportantly, the die size must be as small as possible to keep the costdown. After all, this chip was targeted toward a consumer market.Now, a little background on VDP memory and pixel timing. The masterclock for the VDP is the color burst frequency X 3. All subsequentcalculations are for the NTSC version of the part, although the PALnumbers will be similar. The color burst frequency is 3.579545 MHz.While I don't know pi to this many digits, the color burst frequency isvery handy to know when working with NTSC video. So, the master clockfrequency is given byFmaster = Fcolorburst * 3
http://bifi.msxnet.org/msxnet/tech/tmsposting.tx2 sur 5 18/10/2009 21:33
 
= 3.579545 MHz * 3= 10.7386 MHzThe period of the master clock is given byTmaster = 1/Fmaster= 1/10.7386 MHz= 93.12 ns (nanoseconds)Each memory access takes four master clock times, so the memory accesstime is given byTmem = Tmaster * 4= 93.12 ns * 4= 372.5 ns = 0.3725 usThe horizontal line time, or the amount of time from the start of onehorizontal display line to the next horizontal display line is specifiedin the data sheet as Thorz = 63.695 us. So, the total number of timeswhich VDP memory can be accessed in a single horizontal scan line isgiven byMhorz = Max number of memory accesses in a horizontal line= Thorz/Tmem= 63.695 us/0.3725 us= 171 memory access per horizontal line, maxWe now know how many memory accesses are available to be allocated fordisplay refresh and CPU accesses combined.Next, let's find out how many memory accesses are requied to build up asingle horizontal scan line in Graphics modes I or II. Any unusedaccesses can theoretically be allocated to the CPU.Any one active scan line is composed of up to six layers of graphic data(listed in back to front hierarchy):1. Background color (from VDP register #7)2. Character pattern/color info3. Sprites (min number=0, max number=4)NOTE: there may never be more than 4 sprites on a horizontal scanlineLet's see how many memory accesses are required to get the data for thethree different 'planes' described above.First, the background color requires zero memory accesses, as it is heldthe lower 4 bits of VDP register 7.Next, is the character data. There are 32 characters per scan line, andeach character in the scan line requires the following memory accessesto retrieve the data required to generate the pixel data for thatcharacter.1. Read character number from Pattern Name Table (PNT)2. Read character bitmap data from Pattern Generator Table (PGT)3. Read character color info from Pattern Color Table (PCT)As you can see, it takes three memory accesses for each character, andso the total number of memory accesses required per scan line to buildup the character display plane is given byMchar = 32 characters/scan line X 3 mem accesses/character= 96 memory accesses per scan line for character planeFinally, the sprite planes must be processed. The 9918A allows up tofour sprites (out of 32) to be displayed on a scan line, and sprite #0has the highest priority - that is, it will be the frontmost.To determine which sprite will be visible on any given scan line, theY-position of all 32 sprites must be read from the Sprite AttributeTable (SAT) in VRAM and compared against the current scan line number.When doing the compare, the Mag bit from VDP register 1 must be takeninto account, since the magnification is in both the x and y directions.If the Y-location of the sprite is such that it is to be displayed onthis scan line, then the sprite number (0-32) is placed in one of fourtemporary holding registers (SR0-SR3), if all four registers are notalready filled. SR0 fills first, SR3 fills last, and SR0 specifies thefrontmost sprite plane and SR3 specifies the rearmost sprite plane.While the Y-locations of these active sprites may be saved inside theVDP, I suspect they are not. Keeping these Y-locations would require 4extra holding registers, which can be eliminated by refetching theY-locations later, albeit at the 'cost' of more memory access. However,4 registers affects the chip die size, but it is not clear that the VDPuser even knows about the 'cost' of these extra memory cycles.In the worst case, the first 28 sprites, 0-27, are not displayed on agiven scan line, but sprites 28-31 will be displayed. In this case, the
http://bifi.msxnet.org/msxnet/tech/tmsposting.tx3 sur 5 18/10/2009 21:33

Activity (4)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
net6907 liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->