No Fragments Archive 10: Diskmags

home *** CD-ROM | disk | FTP | other *** search

/ No Fragments Archive 10: Diskmags / nf_archive_10.iso / MAGS / CHOSNECK / CHOS2.ZIP / CHOSNECK.2ND / STUFF / DATAS.ZIP / ART51.SCR < prev next >

Wrap

Text File | 1989-06-08 | 25.3 KB | 583 lines

<head> <title="...forever..."> <font=monaco10.fnt> <font=newy36.fnt> <font=time24.fnt> <image=back.raw w=256 h=256 t=-1> <buf=9025> <bgcolor=-1> <background=0> <link_color=000> <module=console.mod> <pal=back.pal> colors: 251 - black </head> <body> <frame x=0 y=0 w=640 h=9025 b=-1 c=-1> -- -- --------------------------------------- <f1><c000> Videl in practice <f0> -------------------------------------- - - -- Maybe you're wondering 'why another Videl guide'? There's a good Videl overview by Chris/Aura, there's the english translation by Tat/Avena, there's software called Screenpain where you can set any resolution you want... And still a lot of ppl don't know how to set any resolution 'by hand' I was very surprised by an answer on dhs board in the style of 'we are using Screenpain, why waste time in studying Videl regs'... Just for fun and the good feeling you know a little bit more than yesterday! =) Second reason to write may be the fact in BOTH docs I've got were some typing errors (esp. in Tat's one - global using of copy&paste isn't very good practise :-) and a last reason - it's always a good exercise for an author to write any tutorial :-) (I'm not joking - you can't imagine how much I learned while typing that ST RAM timing guide) ...3...2...1...go! Raster line =========== x---------------------------------------------------x | 1st halfline 2nd halfline | |<-----------------------><------------------------>| | | |---------------------------------------------------| | | | | | | | | | | gfx display area | | | | | | |<----------------->| | |<->| | | | hsync| | | | | |<-->|<------------------------------------->|<---->| left visible screen area right border border We see every raster line (including top/bottom border) is divided into 2 halflines. Duration of left/right border, hsync impulse and position of gfx display can be defined by user. Every raster line consists of a certain number [(HHT+2)*2] of CYCLES, not pixels. You can tell Videl how many cycles should be used for 1 pixel. Videl operates with every halfline, not raster line. If you keep some cycles between left/right borders and gfx display area, you will see border with colour taken from $ffff9800 register. I think these halflines are here becoz of TV construction (TV screen consists of 625 halflines) and on VGA are lines divided 'manually'. But who knows, I'm not a hardware freak.. Screen ====== x-------------------------------- | | ^ | | | | | | top border | | | | | v | |------------------------ | | ^ | | | | | | | | | | |--------------- | | | ^ | | | gfx | | | | display| | visible screen area | | area | | | | | | | | v | | |--------------- | | | | | | | | | | | | v | |------------------------ | | ^ | |---------------- | | | ^ | bottom border | | |vsync | | | v v x-------------------------------- From the horizontal point of view, the screen is divided into a certain [VFT] number of halflines. The number of 'real' (raster) lines is [VFT]/2. A TV is able to do 625 halflines, so we can use 312.5 raster lines. Again, if you keep some halflines between top/bottom border and gfx area, you will see border with colour taken from $ffff9800 register. Basic stuff =========== Hz frequency ~~~~~~~~~~~~ Number of lines that can be drawn in one SECOND. Imagine you have a monitor capable of displaying 31500 lines, you've got screen of 31500 lines with refreshing rate of one second. But we don't want refreshing every second, but every 1/60 of second (for VGA 60 Hz) -> 31500/60 = 525 lines. That means our screen will 'wrap' after 525 lines and during VBL the ray will come back to upper corner of the screen. V frequency ~~~~~~~~~~~ Is that 60 number of example above. It says number of VBLs per second. So, for TV for example, we are able to draw max 312.5 lines, right? 15625/312.5 = 50 Hz. We can see that Hz frequency number of raster lines = ------------ V frequency We also can see if we increase number of VBLs per second (for less eye- stressing picture), we have to decrease number of lines (for VGA 100 Hz: 31500/100 = 315 raster lines instead of 525); if we don't want to decrease number of lines, we have to increase hz frequency; if we increase hz frequency, our lines will be 'bigger', so you have to decrease cycles per pixel; if you can't decrease cycles per pixel, you have to decrease cycle-time by increasing Videl clock... shit, what magic! :o) Back to hz freq: the number 31500 also means the line has to be drawn in 1/31500 = 0.031 ms (vga) and 1/15625 = 0.064 ms (rgb) one 25.175 MHz Videl cycle = 1/25175000 = 0.040 us one 32.000 MHz Videl cycle = 1/32000000 = 0.031 us rgb uses 2 32 MHz cycles per pixel for 640xYYY resolution vga uses 1 25.175 MHz cycle per pixel for 640xYYY resolution (for more info about cycles/pixel see below) time for drawing one pixel: rgb: 2 cycles * 0.031 us = 0.062 us vga: 1 cycle * 0.040 us = 0.040 us time for drawing 640 pixels: 0.062 us * 640 pixels = 0.040 ms (rgb) 0.040 us * 640 pixels = 0.026 ms (vga) remaining time in one line: rgb: 0.064 - 0.040 = 0.024 ms for borders vga: 0.031 - 0.026 = 0.005 ms for borders We see there's a lot of space on rgb screen; in compare to vga&25 MHz, rgb&32 MHz screen don't fit perfectly. Exactly the same numbers you'll get in 320xYYY modes, since by 320 pixels/line Videl uses 4 cycles (rgb) and 2 cycles (vga) per pixel, which is 2 times more. And 320 is two times smaller than 640 => differences are eliminated. From these formulas you see there isn't any information about color-depth of one pixel. The reason why we can't set 640x480xtc on vga for example is a slow data bus. Really, if you have Nemesis/Phantom [24/25 MHz bus], there's no problem to set this resolution. If you switch accelerator off, you will see how Videl isn't able to catch next 17 longs of video data, nice thing, really ;-) So why is it possible to set it on tv/rgb? If you want visible 640xYYY pixels on screen, you have to set 2 (rgb) or 1 (vga) cycles per pixel. And here is that problem - 1 cycle per pixel is unrealisable on 16 MHz databus, simply, there's a need to transfer data from st-ram two times faster than on rgb. For BP modes it's enough, but in TC Videl needs probably more time to catch one pixel from st-ram. Maybe you're asking, why we need 1 cycle per pixel. We don't need it :-) It's "cosmetic need" - really, if you set 2 cycles/pixel, 32 MHz (pixels are smaller), you're free to set around 440x480xtc without ANY problem. 440 pixels are visible maximum on my monitor with 30 kHz/60 Hz frequencies. I think there's no problem to set 640x480xtc on 50 MHz Videl WITHOUT bursting the databus to >16 MHz (decreasing of CPU performance is another thing) Some additional info about cycles/pixel is with divider table some pages below. When we're talking about frequencies, why don't take a look at VGA 100 Hz. An advantage of this mode is in decreasing some kind of "wait states". In standard VGA/60 Hz XXXx240 modes the screen is drawn like this: 1st line: Videl takes data from st-ram and draws it on screen (CPU waits) 2nd line: Videl copies data from 1st line and CPU is still waiting 3rd line: Videl takes data from st-ram and draws it on screen (CPU waits) 4th line: Videl copies data from 3rd line and CPU is still waiting : : etc. This isn't 100% correct, but it shows us the problem: every second line CPU don't do anything, data bus is free and we're wasting time. Logical solution is switching off the double line, right? OK, click-click, done :-) But hey, our vga screen isn't a screen, but some kind of tube! (???) Hm, hm, hm, we have to do something with this small screen. Do you remember meaning of vertical frequency? It's the time after which the screen is wrapped, right? With single lines, our screen looks like this: top border clear area : : 320 single lines clear area : : : bottom border You can play with moving display up and down, but in 60 Hz you have still 50% of screen filled with nothing. So let's move display up. Done? Now you have: top border 320 single lines clear area : : : : : bottom border Now you probably know, what will be the next step - we don't need 320 lines of nothing, so we say to Videl that screen can be wrapped 320 lines earlier. How to get the exact frequency? 31500/525 = 60 Hz We know that our resolution has 480 lines: 525-480 = 45 lines for borders. Now we want only 240 lines: 240+45 = 285 lines at all. 31500/285 = 110.5 Hz 110.5 Hz? That isn't 100 Hz! With 110.5 Hz you'll get perfect screen without any borders. Why to use 100 Hz screen with stupid white borders? (I know, I know, clr.l $ffff9800.w isn't a problem in TC, but what about bitplanes ?) Only reason in my mind is the same picture size as in rgb/50 Hz modes. If your fx is able to run in 110 fps and you decrease vertical frequency to 100 Hz, your fx WILL run slower. But how many fxes are able to do so? Very few I guess. And, if you have any fx slower than 1 vbl, vertical frequency isn't important anymore since you will use triplebuffer and triplebuffer isn't depend on VBL (ok, ok, screens are swapped in VBL, but I think the difference between 100 and 60 hz with 34 fps fx can be ignored) It's true 60 Hz double-line mode takes SOME time against single-line mode, but I really doubt it's more than catching 320*240 words from st-ram with two times bigger frequency (than rgb/50). Remember 320x240/tc/vga/60 takes about 16% of CPU time and vga/100 takes 26% !!! I compared 320x240xtc mode with and without double-lines, speed difference is maybe 2%-3% (Videl don't read same lines again from st-ram but from its buffer). For future: if you're coding slower fxes, lower value of vertical frequency is always better since more VBLs means more loading screens by Videl = more bus halting. OK, I think I could stop to bore you with this theory, the name of this article is "Videl in PRACTISE", isn't it? :) Let's look over some standard values for rgb/tv and vga: rgb/tv vga -------------------------------------------------------- Hz frequency: 15625 Hz 31467 Hz Duration of HSync impulse: 4.7 us 3.81 us Duration of right border: 6.2 us 4.45 us Duration of left border: 5.145 us 1.91 us V frequency: 50 Hz 59.58 Hz Duration of VSync impulse: 0.192 ms 0.064 ms Duration of top border: 1.504 ms 1.008 ms Duration of bottom border: 0.384 ms 0.416 ms As Chris has written, these values aren't hard and fast. But they're good start values at least :-) Before we start with making our own resolution, a little overview of important Registers is in order: ------------------------------------------------------------------------------- $FFFF820E [R/W] W _______876543210 Line Offset How many words are added to the end of display line, i.e. how many words are 'behind' the display. ------------------------------------------------------------------------------- $FFFF8210 [R/W] W ______9876543210 Line Width (VWRAP) Length of display line again in words. Or, how many words should be added to vram counter after every display line. Maybe you're asking what is the difference between these registers. length of logical line = width + offset So if you want virtual screen of 512 pixels width in 320x240xTC: $ffff820e = 512 - 320 = 192 $ffff8210 = 320 A little help about calculating word values: line width = (hz resolution/16) * bitplanes Colours Bitplanes ----------------- 2 1 4 2 16 4 256 8 65536 16 ------------------------------------------------------------------------------- $FFFF8260 [R/W] B ______10 ST Shift Mode || || || || others vga || $FF8210 $FF82C2 $FF82C2 00--4BP/320 Pixels=> $0050 $0000 $0005 01--2BP/640 Pixels=> $0050 $0004 $0009 10--1BP/640 Pixels=> $0028 $0006 $0008 11--???/320 Pixels=> $0050 $0000 $0000 Writing to this register does the following things: - activate STE palette - sets line width ($8210) - sets paramaters in $82c2 (double lines/interlace & cycles/pixel) Before writing to $8260 you have to: - set correct values (hdb, vdb, ...) for 320x200 or 640x200 or 640x400 - clear $8266 register = setting Falcon 16 color mode; if you don't do it, you will get strange resolutions ------------------------------------------------------------------------------- $FFFF8266 [R/W] W _____A98_6543210 Falcon Shift Mode (SPSHIFT) ||| ||||||| ||| |||++++- 0..15: Colourbank setting in 8BP ||| ||+----- 0: 8 Bitplanes (256 Colors) off ||| ||+----- 1: 8 Bitplanes (256 Colors) on ||| |+------ 0: internal Vertical Sync ||| | 1: external Vertical Sync ||| +------- 0: internal Horizontal Sync ||| 1: external Horizontal Sync ||+--------- 0: True-Color-Mode off || 1: True-Color-Mode on |+---------- 0: Overlay-Mode off | 1: Overlay-Mode on +----------- 0: 2-Color-Mode off 1: 2-Color-Mode on Writing to this register does the following things: - activate Falcon palette - if you set Bits A/8/4 == 0, it selects 16-Color-Falcon-Mode (NOT the same as ST LOW since Falcon palette is used!) - $8260 register is ignored, you don't need to write here anything Note: as you can see, 4-Color-Mode isn't realisable with Falcon palette. ------------------------------------------------------------------------------- $FFFF8280 [R/-] W ______9876543210 Horizontal Hold Counter (HHC) It's set after writing to HHT, it counts cycles since HHC reaches HHT+1 value. Then is 1st halfline finished and HHC starts to count 2nd halfline (again to HHT+1) ------------------------------------------------------------------------------- $FFFF8282 [R/W] W ______9876543210 Horizontal Hold Timer (HHT) Number of cycles minus 2 per halfline (not gfx line!). Both halflines use this value. | video base clock | HHT = int|--------------------- - 2| |Hz freq * divider * 2 | ------------------------------------------------------------------------------- $FFFF8284 [R/W] W ______9876543210 Horizontal Border Begin (HBB) On which cycle in SECOND halfline should start right border to the end of raster line. If HBB > HHT+1, no border is present. |right border dur in us * video base clock| HBB = HHT + 1 - int|-----------------------------------------| | divider | ------------------------------------------------------------------------------- $FFFF8286 [R/W] W ______9876543210 Horizontal Border End (HBE) On which cycle in FIRST halfline should end left border from the start of raster line. If HBE > HHT+1, border over whole raster line is present. |left border dur in us * video base clock| HBE = int|----------------------------------------| | divider | ------------------------------------------------------------------------------- $FFFF8288 [R/W] W ______9876543210 Horizontal Display Begin (HDB) | +---------- Display will start in: 0: 1. halfline 1: 2. halfline On which cycle in FIRST OR SECOND halfline should start gfx display. This value took 90% of the time of my Videl studying... There's a need of some detailed explanation. Falcon's screen is created in this way: 1. We define in which halfline Videl should start the raster line 2. Videl waits in this halfline until HHC reaches HDB value. 3. Wait state goes here (hdb offset) 4. Videl is drawing until HHC reaches HDE value 5. Wait state goes here (hde offset) If you draw it on paper: hdb-off hde-off ------+-------+-------------*------------+-------+------- hbe=hdb ...active display area... hde hbb "*" means begining of 2nd halfline. Now you calculate HDB offset: | |8 words*16 pixels | | |64 + |----------------- + 16 + 2| * Cycles/pixel| | | No. of planes | | HDB offset = int |------------------------------------------------| + 1 in F030 BP mode | divider | | |8 words*16 pixels | | |128 + |----------------- + 2| * Cycles/pixel| | | No. of planes | | HDB offset = int |--------------------------------------------| + 1 in STE BP mode | divider | |64 + 16 pixels * Cycles/pixel| HDB offset = int |-----------------------------| + 1 in TC mode | divider | The question for me was the relationship between the HDB and HDB offset. After two months I finally scored a goal, yeah !!! :-) I didn't understand one thing: how can HDB be nearly the same as HDE, that isn't logical! But imagine we will create a line in system listed above: after border end we will wait some (hdb offset) cycles and then drawing can begin. But hey! We reached border end, we're in visible area already! To avoid a next "border" we have to move backward in line with horizontal display begin; in some cases we'll get into negative values (HBE - HDB offset < 0). But this is no problem since we can define 2nd halfline for HDB, too! Drawing our line will begin in 2nd halfline and after hdb-offset will start EXACTLY at horizontal border end. Cool, eh? Once again, formula for calculating HDB: HDB = HBE - HDB offset; if you get negative value: HDB = HBE - HDB offset + HHT+2 and set bit 9 of HDB register ------------------------------------------------------------------------------- $FFFF828A [R/W] W ______9876543210 Horizontal Display End (HDE) On which cycle in SECOND halfline should end gfx display. ||8 words*16 pixels | | ||----------------- + 2| * Cycles/pixel| || No. of planes | | HDE offset = int |--------------------------------------| in F030/STE BP | divider | mode HDE offset = 0 in TC mode HBB = HDE + HDE offset => HDE = HBB - HDE offset When calculating the HDB and HDE it should be noted, that the number of horizontal pixels cannot be defined arbitrarily, except in Truecolour mode. We can arrive at the allowed pixel multiple using the following formula: 8 Words * 16 Pixels Horizontal pixel multiple = ------------------- No. of planes In truecolour mode a fine definition of 1 pixel is possible. ------------------------------------------------------------------------------- $FFFF828C [R/W] W ______9876543210 Horizontal Sync Start (HSS) On which cycle in SECOND halfline should start hsync impulse to the end of raster line. If HSS > HHT+1, no vsync impulse is present. |hsync impulse dur in us * video base clock| HSS = HHT + 1 - int|------------------------------------------| | divider | ------------------------------------------------------------------------------- $FFFF82A0 [R/-] W _____A9876543210 Vertical Frequency Counter (VFC) It's set after writing to VFT, it counts halflines since VFC reaches VFT value. VFC is increased if HHC = HHT+1 ------------------------------------------------------------------------------- $FFFF82A2 [R/W] W _____A9876543210 Vertical Frequency Timer (VFT) Number of halflines per screen. |Hz freq| VFT = int|-------| * 2 (+1) |V freq | ^ \_when not interlaced ------------------------------------------------------------------------------- $FFFF82A4 [R/W] W _____A9876543210 Vertical Border Begin (VBB) On which halfline should start bottom border to the end of screen. VBB = VFT - int|bottom border dur in ms * Hz freq * 2| ------------------------------------------------------------------------------- $FFFF82A6 [R/W] W _____A9876543210 VBlankOff / Vertical Border End (VBE) On which halfline should end top border from the start of screen. VBE = int|top border dur in ms * Hz freq * 2| + 1 ------------------------------------------------------------------------------- $FFFF82A8 [R/W] W _____A9876543210 Vertical Display Begin (VDB) On which halfline should begin gfx display. If VDB > VFT, no display is present. If VDB > VDE, display is present from VDB to VFT. ------------------------------------------------------------------------------- $FFFF82AA [R/W] W _____A9876543210 Vertical Display End (VDE) On which halfline should end gfx display. If VDE < VFT, no display is present. If VDE < VDB, display is present from VDE to VFT. ------------------------------------------------------------------------------- $FFFF82AC [R/W] W _____A9876543210 Vertical Sync Start (VSS) On which halfline should start vsync impulse to the end of screen. Impulse starts from VSS+1. VSS = VFT - int|vsync dur in ms * Hz freq * 2| ------------------------------------------------------------------------------- $FFFF82C0 [R/W] W _______8765_3210 Video Control (VCO) |||| |||| |||| ||++- same as bit 7&6 in $ffff0006 |||| |+--- 0: Video base clock 32 MHz |||| | 1: Video base clock 25.175 MHz |||| +---- 0: No Half-line-HSyncs |||| 1: 15 Half-line-HSyncs from start of |||| bottom border |||+------ 0: negative VSync-Impulse (5V > 0V) ||| 1: positive VSync-Impulse (0V > 5V) ||+------- 0: negative HSync-Impulse (5V > 0V) || 1: positive HSync-Impulse (0V > 5V) |+-------- 0: 16 Bit-Videobus | 1: 32 Bit-Videobus (Falcon) +--------- Hz base offset 0: 128 cycles (ST Low/Mid on RGB and ST Hi on SM124) 1: 64 cycles (all the others) Bits 1 and 0 are set same as bits 7 and 6 in $ffff8006: 00 Monochrome 01 RGB - Colormonitor 10 VGA - Colormonitor 11 TV ------------------------------------------------------------------------------- $FFFF82C2 [R/W] W ____________3210 Video Mode |||| |||+- 0: Double lines off ||| 1: Double lines on ||+-- 0: Interlace off || 1: Interlace on ++--- 00: 4 cycles/pixel 01: 2 cycles/pixel 10: 1 cycle/pixel 11: n/a ------------------------------------------------------------------------------- Phew, finally we reached the end ! :-) I tried to write it in a more efficient/clear way than Chris/Tat did. <link=art51b.scr>Go to NEXT PART</l> </frame> </body>