Rybags Posted November 23, 2009 Author Share Posted November 23, 2009 Executable file to display the Millenium Falcon interlaced picture (320 x 480 pixels, single palette of 256 colours). falcon1.zip The picture displays progressively as it loads - the interlace mode isn't enabled until loading completes. I didn't bother using a proper 16 pixel high font for the text. Just wanted to get this loader/display routine finished. File should load fine from practically any DOS or menu loader. Just press Reset when finished - the program uses XL RAM around $5800-$5C00 and $7000-$72FF, the picture itself is loaded direct to VBXE memory. Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 23, 2009 Author Share Posted November 23, 2009 I just had another idea for the zoomer (using Attribute Map). To save memory, just reuse the same data, offsetting the pointer by 0, 1, 2, 3. Of course, this will mean that palette selection, priority etc. will be read from colour data, but all we need to do there is have all 4 palettes the same, priorities the same. I reckon that with combined use of standard XL graphics + attribute map + VBXE overlay, we could do 3 layer scrolling... or possibly make that 4 layer if you count the PM graphics. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 23, 2009 Share Posted November 23, 2009 Looks really impressive. Are you going to try for 640x480? I forget what the bit depth is at that horizontal resolution. Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 23, 2009 Author Share Posted November 23, 2009 That's 16 colours (4-bit) So, we'll really need to dig into the bag-o-tricks there... But we can use attribute maps to increase the colours. Or just use the attribute map to do the bulk of the picture and just use the 640 pixels to enhance detail in specific areas. Not to mention using the legacy hardware. Then there's always stuff like dynamically reloading palettes or parts of them. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 23, 2009 Share Posted November 23, 2009 (edited) Wasn't sure about the colour depth: thanks. Just had to take a couple of photos of this on the Flatron TFT. Wasn't sure it would work well with this TV but it looks stunning: I kind of miss the "smoothness" of CRT: the TFT quality is totally different. Blockier but extremely sharp. It's rather like emulator output (or it would be, if we had one! ). And of course there's the upscaling. Edited November 23, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
candle Posted November 23, 2009 Share Posted November 23, 2009 atribute map won't work with overlay mode but you have 64 colors at your disposal, and you could reuse them as you do with DLI we really need Simonl converter here and his format we all need some motivation (used as another word for pressure ) from time to time Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 23, 2009 Share Posted November 23, 2009 (edited) I don't think the 4 bit colour is a biggie, since I envisaged that mode being most useful in a GUI context. 320x480x256 seems to me ample definition for photo display at the moment. Of course, we'll want to see how far we can push things. Edited November 23, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 23, 2009 Author Share Posted November 23, 2009 I think it should work... just some creative juggling of priorities and stuff needed. How much scope is there for new features in later cores? I was thinking along the lines of stuff like line draw, and possibly something like decompression assist. Quote Link to comment Share on other sites More sharing options...
candle Posted November 23, 2009 Share Posted November 23, 2009 0 fpga is 100% full, if we would like to add something, we had to revert to the starting point and build new core from the grounds Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 24, 2009 Author Share Posted November 24, 2009 Another interlaced pic. Executable: crysis1.zip Maybe not the best example pic to use... it's mostly shades of white and blue. But, it loses very little in comparison to the 24-bit colour original. Original pic stolen from here http://www.biocookies.com/bio-center/crysis-bio-center/crysisimages/miscellaneous/crysis-726116.jpg Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 24, 2009 Author Share Posted November 24, 2009 ivb2.zip Source code for interlaced pic loader in ivb2.asm It's for AtAsm. It is also a little messy, but it works. Or, you can just use the loader code, but it will have my title text in it. To use the loader code, create a file as follows: 1. File ivb2.65o at start. File has the necessary binary header for load address already. 2. Append an init segment (2e2,2e3) with init address $5800 3. Create a data segment of 768 bytes that loads at $7000-72FF. Palette data is loaded into PAL1, should be stored as byte sequence of RGB,RGB.. etc - 256 entries covering colour 0-255. 3. Create an init segment with INIT address $5803 - loader program has code to setup VBXE bitmap and load palette data into registers. 4. Next up, the picture data. The loader program clears enough VBXE RAM such that smaller pics will display OK, although won't be centred. Since we're dealing with interlace, potentially the picture can be 320x480 bytes. The picture data should be split into data segments of exactly 4K which are loaded to $8000-8FFF. Each segment should be followed by an INIT segment which calls $5806. Routine at $5806 increments VBXE bank so the picture loads sequentially. Last segment of picture can be truncated without problems. 5. After picture data, an INIT segment to $5809. This sets up interlace. 6. Finally, RUN segment. This can be your own program, e.g. to play music etc. If you just want static pic, use $580C (endless loop). For creating the palette and picture data from a BMP file, I've just written a quick/dirty Basic program. I could tidy them up a bit and upload them. They're also somewhat slow, but I just run them in the emulator and hit the turbo button. Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 25, 2009 Author Share Posted November 25, 2009 Yesterday I thought of another use for VBXE. Since the RAM window looking into VBXE RAM is so flexible, we should in theory be able to run banked cartridge copies, although of course the cart code itself would need it's banking code to be altered. OSS ROMs, carts that switch all 8 or 16K, carts with fixed 8K and banked lower 8K - all of them could be covered. It would also come in handy for doing cart development - just use a banking routine adapted for VBXE during dev, then switch to the one applicable to your banking hardware in production. Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 26, 2009 Author Share Posted November 26, 2009 Question here, not trivial (you could probably work out what I'm aiming to do) : If I set the MEMAC such that it's base address is $D000 and a window size of 4K, will VBXE RAM appear at $D800-DFFF (of course with PORTB set such that the OS ROM is disabled) ? Quote Link to comment Share on other sites More sharing options...
candle Posted November 26, 2009 Share Posted November 26, 2009 vbxe ram is not visible if CASINH signal is active Quote Link to comment Share on other sites More sharing options...
electron Posted November 26, 2009 Share Posted November 26, 2009 Question here, not trivial (you could probably work out what I'm aiming to do) : If I set the MEMAC such that it's base address is $D000 and a window size of 4K, will VBXE RAM appear at $D800-DFFF (of course with PORTB set such that the OS ROM is disabled) ? Yes, It is visible in range d800-dfff, bot NEVER in range d000-d7ff. In this case you have access only to the upper half of every bank area ... Quote Link to comment Share on other sites More sharing options...
candle Posted November 28, 2009 Share Posted November 28, 2009 (edited) I finally had some time to add music (done by Born/La Resistance) to 1200xl Atari logo screen. Since i have another 2kb at my disposal im thinking about adding something else i suppose 80 column scroller is an obious choice for credits and some instructions (as press b for basic, or esc to reboot) maybe shadebobs of some kind? if i use system fonts there are lots of options what i could do with whole 2k [changed attachment, it works only with vbxe at d6xx] 1200xl.zip Edited November 28, 2009 by candle Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 28, 2009 Author Share Posted November 28, 2009 This is a test version of the Interlaced Falcon pic, requested by candle. It allows use of the function keys once the pic has fully loaded to turn the interlace on/off, swap fields, and hold on one field. falcon1t.zip Quote Link to comment Share on other sites More sharing options...
candle Posted November 29, 2009 Share Posted November 29, 2009 here you can download newest version of 1200xl logo screen some facts: 35kb of compressed data approximatly 30kb is graphics fonts for credits line were taken from really nice font page and are avaivable there under number 024 they were converted to VBXE Hi-Res(640xX) mode what it shows is how to use palette animation, and how to do simple fades on separate palette - this allows to display 266 colours simultanously on screen (256 colours of atari logo, and 10 colours for fonts) the picture was taken at wierd angle to get rid of flash blob, and composition is far from beign perfect, but i don't have more time right now Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 29, 2009 Share Posted November 29, 2009 Hello Candle, good test app... now I know that my VBXE works... the font is one of the best... need to get my test vbxe code done earlier this year to the real machine now! Quote Link to comment Share on other sites More sharing options...
+Stephen Posted November 29, 2009 Share Posted November 29, 2009 Wow - I can't wait to see (and hear) this on a real machine! That looks amazing. Stephen Anderson Quote Link to comment Share on other sites More sharing options...
DamageX Posted January 18, 2010 Share Posted January 18, 2010 I just updated my BMP tools and am plugging them here since they may be useful for reducing 24-bit bitmaps to 256 color bitmaps for VBXE (also does resizing, different color depths and palette sizes). When a VBXE native picture format is finished I can add an option to save that file type. Win32 command-line binaries are included and FreeBASIC source (probably easy to compile for Linux) http://www.hyakushiki.net/bmptools.zip Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 19, 2010 Share Posted January 19, 2010 vbxe native format is simple... R,G,B byte per pixel... palette should be in a separate file as we need to copy that directly into the palette registers. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 19, 2010 Share Posted January 19, 2010 btw... in theory we can abuse the blitter to draw vertical lines? Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 19, 2010 Author Share Posted January 19, 2010 Horizontal, 45 degree and vertical lines will be straightforward. I thought about other types - I don't think it can be done such that the calculations required would make it any faster than just using the traditional method. Possibly gradients such as 1/3, 1/4, 1/5, 1/6 etc could be done via multiple blits as those types should always have exact step sizes. Although there might be some way of doing a table-based approach where you have 2 or more blits that get repeated to do lines based on what angle you want. The preliminary setup would employ part of the traditional process (calculating the number of pixels needed). But you'd not end up with quite the same lines as with traditional methods - the normal method gives you matching end pieces. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 19, 2010 Share Posted January 19, 2010 LineMode Using blitter for line drawing: Besides copying data and filling areas, the blitter has one more talent: drawing lines. In line mode, almost all of the blitter registers change their functions. The blitter draws lines at incredible speeds, much faster than the 68000. Unfortunately, you can't just give the blitter two points and then tell it to connect the dots. You need to perform some calculations first. Let's say that you want to draw a line from point (x1,y1) to (x2,y2). From these coordinates you need to figure out the horizontal and vertical distance between the line's two end points. This is easily calculated using the following two formulas: dx = abs(x1-x2) dy = abs(y1-y2) Now you're ready to give the BLTCON1 register at $dff042 some information about the physical orientation of the line. If (dx >= dy) and (x1 >= x2) set bit 2. If (dx < dy) and (y1 >= y2) set bit 2. If (dx >= dy) and (y1 >= y2) set bit 3. If (dx < dy) and (x1 >= x2) set bit 3. If (dx >=dy) set bit 4. Together, these bits define the octant (position relative to the line's starting position) in which the line will appear. The following shows how the Amiga divides the screen into octants: \ | / * = x1,y1 \3 | 1/ Note: The numbers shown in this figure 7 \ | / 6 represent the combined value of BLTCON1's \|/ bits 2-4. If the line appears on the border ----X---- of two octants, it does not matter which of /|\ the two octants you select. 5 / | \ 4 /2 | 0\ / | \ Next, you need to determine which value is larger: dx or dy. Let dmax equal the greater value, and dmin the lesser value. Now use these values to set the following registers: dmax = max(dx,dy) dmin = min(dx,dy) BLTBMOD = 4* dmin BLTAMOD = 4 * (dmax-dmin) BLTAPTL = (4 * dmin) - (2 * dmax) These formulas define the line's slope. If the result of the last calculation BLTAPTL is negative, you must store a 1 in the SIGN bit (6) of the BLTCON1 register. Besides holding the line's octant number and the negative/positive status of the line's slope, BLTCON1 affects the line's physical appearance. If you're drawing lines to enclose an area that you plan to fill later using blitter fill mode, you should set the ONEDOT bit (1) equal to one. This tells the blitter to draw lines using only one pixel per raster, thus providing a single pixel border for your object. To create textured lines, BLTCON1's bits 12-15 work in conjunction with the BLTBDAT register ($dff072). The bit pattern found in BLTBDAT defines the pixel pattern used to draw lines. For normal solid lines, set all of BLTBDAT's bits to one. (i.e. $ffff) Other values create dotted or dashed lines. Bits 12-15 in BLTCON1 allow you to specify which bit in BLTBDAT, 0-15, defines the status of the first pixel in the line. For most practical purposes, BLTCON1's bits 12-15 should be set equal to the value of x1's lower 4 bits. (i.e. x1 AND $0f) This informs the blitter to start the line off with the value found in BLTBDAT's MSB (15). IMPORTANT: ALWAYS SET BLTCON1 PRIOR TO BLTBDAT! BLTCON1's bit 5 should always be set to zero, as should bits 7 through 11. To tell the blitter that you want to draw lines instead of copy data, the LINE bit (0) must be set to 1. The Amiga needs certain information about the size and location of the screen's bitmap before it can draw a line. First, store the byte-width (number of pixels divided by of the bitmap in the BLTCMOD and BLTDMOD registers ($dff060 and $dff066). Next, you must put the address of the word containing the starting point of the line into the BLTCPT and BLTDPT registers. ($dff048 and $dff054) Only one bitplane can be written to during a single blitter operation. So, to draw a line of a particular color on a multiple bitplane screen, it may be necessary to perform two or more line blits. In these cases, you set the registers up for the first bitplane as usual, and perform the blit; then for subsequent bitplanes, you simply reinitialize the registers with the same values EXCEPT for the registers BLTCPT and BLTDPT, which must contain the address of the line's starting point within the new bitplane. As with blitter copy mode, you must set bits 0-7 in the BLTCON0 register ($dff040) to choose a miniterm. Usually, you should store $ca here, but if you prefer to XOR your line onto the screen (invert all the pixels found on the line), store a $4a here. BLTCON0's bits 8-11 should be set equal to $b. (This activates blitter source A and C, and destination D.) Store x1's lower four bits (x1 AND $0f) into BLTCON0's bits 12-15. The blitter uses this value to determine the bit position of the line's starting point within the bitplane memory location specified by registers BLTCPT and BLTDPT. Now, set BLTADAT ($dff074) equal to $8000. (Set this register only AFTER you've set BLTCON0) Only two more registers must be set before you can activate the blitter: BLTAFWM and BLTALWM. ($dff044 and $dff046) Store a $ffff into both. Finally, you're ready to start the blitter by writing to the BLTSIZE register ($dff058). Use the following formula to determine the value that you should store into this register: BLTSIZE = (dmax * 64) + 66 Because writing to BLTSIZE turns on the blitter, this should be the last register that you set. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.