VBXE - programming, examples, programming queries

[Rybags]

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.

 

[Rybags]

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.

[flashjazzcat]

Looks really impressive. Are you going to try for 640x480? I forget what the bit depth is at that horizontal resolution.

[Rybags]

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.

[flashjazzcat]

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

[candle]

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

[flashjazzcat]

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

[Rybags]

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.

[candle]

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

[Rybags]

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

[Rybags]

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.

[Rybags]

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.

[Rybags]

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) ?

[candle]

vbxe ram is not visible if CASINH signal is active

[electron]

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 ...

[candle]

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

[Rybags]

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

[candle]

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

 

[Heaven/TQA]

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!

[+Stephen]

Wow - I can't wait to see (and hear) this on a real machine! That looks amazing.

 

Stephen Anderson

[DamageX]

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

[Heaven/TQA]

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.

[Heaven/TQA]

btw... in theory we can abuse the blitter to draw vertical lines?

[Rybags]

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.

[Heaven/TQA]

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.