VBXE - programming, examples, programming queries

[DamageX]

I have updated my tool again and for the purpose of the VBXE 256-color BMPs are possible as well as 24-bit BMPs with 1024 colors. Although there is nothing yet for actually displaying these pics on the A8. I haven't installed my own VBXE yet, as I've been busy working on this, trying to make it flexible/multipurpose. Check the example pics: http://www.hyakushiki.net/bmptool.htm

[Heaven/TQA]

ah, ok...I was skipping palette entry, too as I am setting the values directly for the 16 col font...

[flashjazzcat]

BUMP! Does the VBXE's MEMAC window have precedence over other banks, such as SDX's CAR banks? I'm working on a driver model which leaves an 8KB MEMAC window open at $A000, but trying to get a listing of the CAR: device under SDX is yielding no files at all. I assume MEMAC is messing with what SDX can see at $A000-$BFFF.

[phaeron]

The FX1.20 doc says that it should not override either cartridge or BASIC ROM since the windows are EXTSEL based. I think Altirra may have a bug here as it is emulating the MEMAC windows at too high of a priority (Hardware > ROM).

[candle]

whenever CAS INHIBIT line is active, VBXE will not open the window

so if any of S4 or S5 signals are active in banking area, window stay closed

best for altirra would be to implement that line

[flashjazzcat]

Thanks guys. I think the problem in this case (since it occured on real hardware) is that the destination buffer for the CIO operation was actually (inadvertently) situated under the cart.

[flashjazzcat]

Stand by for a beginners' blitter guide some time soon. Documentation is - IMO - inadvertently misleading, but I think I've finally got to grips with it.

[Rybags]

I've gone to the next level... using blitter to modify the BCB of subsequent blits.

 

I really wish the blit had a NOP and a Jump mode. Would make programming the things so much easier.

[flashjazzcat]

Heh... it's taken me a fortnight to get to ground level. i.e. this:

 

 

My main misconception was that the Y source increment was measured from the beginning of the source data, when in fact it's an extra offset to be used if you want to skip bytes. In the case of the progress bar, it should be set to zero.

 

Anyway, Sebastian spoke to me a while ago about self-modifying blitter lists - it sounds fascinating. Please share when you're done! Any way spring to mind to introduce a delay, so that the progress bar (currently running in the VBL) could actually run independently of the mainline code? Basically you'd just set it away, but it would need to be interrupted when the I/O finished. I doubt it's a realistic proposition.

 

I do seem to have a handle on things now, though. I have a couple of VBXE demo ideas in mind, plus at least one obtuse use for the blitter.

[Rybags]

The problem is that the BCB reads are sequential and there's no jump function, and you need program intervention once a BCB list is completely executed.

 

But I guess you could do something like use the IRQ and have a number of "dummy" BCBs that do a maximal overlay mode operation to chew through cycles. Just use skip (0,0) on the destination so only one address is affected.

 

The biggest possible blit can do a 512*256 area = 128K so that's quite a lot of cycles given 3 cyles per operation. About 1.5 frames + whatever DMA loss occurs.

 

In theory you could do some maths and work it out... it'd probably cost you several BCBs per pixel of your progress bar - 1 to plot the pixel then the remainder provide the delay.

Of course that then relies on having a reasonable estimate of how long the operation (e.g. read disk file) is going to take, then setting up the delays to reflect it.

 

I guess you could benchmark and adjust as it went along, but you might well end up with a bloated bit of code just for the sake of saving some VBlank cycles.

[Rybags]

The self-modifying stuff I'm doing for Moon Cresta is fairly simple.

 

I use the same BCBs for drawing and erasing the sprites. I guess I could as easily have just had 2 sets of BCBs and used a blit to copy the destination addresses etc. but this way saves a little RAM.

 

The modify part changes blit modes (overlay to plot, straight copy for erase), and there's another on that sets the AND/XOR masks. Erase simply needs to zero out the destination so the AND=00 feature comes into it there so that no source read is done on that pass.

 

I'm currently just running the blits from a DLI near bottom of screen and have a wait loop for the erase phase... at most only losing a few scanlines doing so. The render pass just runs when that's done, no relying on IRQs and the whole thing relies on it finishing well before the next frame's iteration.

 

I've had a few ideas re queueing systems and the like. But not really had anything come up yet that's needed complex handling.

 

I'm thinking for adhoc blits (like doing text and the like), I could just enable the IRQ and have a routine that squeezes those little tasks in.

[candle]

512*256 bytes copy with xdl turned off will take 0.018s which is less than one frame

 

why would want to make delays using blanks copy blits?

there is irq signaling blit is over, there is vbl you can set up for any kind of timing driven events, and displaying a block of pixels for progress bar is certainly the case

[Rybags]

What I meant was the overlay mode copy (command =1) - you have source read, dest read/test, dest write. So that's over 1 frame.

 

I think Jon might be wanting some automation maybe to help with the faster SIO modes? Do too much in VBlank time and they start to not work well.

Edited January 2, 2012 by Rybags

[candle]

with transparency?

you have source read, source compare against 0 (after all these masks - this is done in parallel) and if source is not zero, write to the destination

so it can be faster than mode 0

[Rybags]

I got mixed up... you'd need to use collision mode to slow it down. But still under 1 frame unless the DMA load slows it further.

[flashjazzcat]

Gary's quite correct in saying I was trying to detach the progress bar updates from the VBL in order to avoid conflict with high-speed SIO. However, the intervention (via the VBL) is so minimal in the VBXE driver that it should be far less intrusive than in the standard version (which is also going to be trimmed down). Another reason is quite an obscure one: under SDX, when accessing kernel devices such as CAR: via CIO, the SDX library must be invoked, and therefore the cartridge ROM is intermittently switched in (you can test this by cataloguing CAR using LW's disk menu: the screen will flash and flicker like crazy as the cart ROM collides with the frame buffer). This is all well and good with the standard version, but since the LW's VBXE driver keeps the 8KB MEMAC window open at $A000, VBL progress bar updates will fail if the cart ROM is present at $A000 when the driver tries to call a blit operation at the same address. The solution is to open a smaller MEMAC window at another location during I/O. This is no problem, since the VBL is the only thing running during SIO, so the window can go anywhere but the CIO buffer address.

 

So - the reason for wanting a delay was to simply set the progress bar off at the start of the CIO call, then have no further access to the MEMAC window until I/O was complete.

 

Anyway: slight 3D effect:

 

 

Question: narrow playfield, standard res: each line should be 256 bytes above the previous one, yes? Having a hard time getting things to line up - offsets of 320 bytes work, but this isn't a 320px wide playfield... ???

Edited January 2, 2012 by flashjazzcat

[candle]

screen width and window width are two diffrent things

you may have standard res narrow field screen with 1024 wide window, and you can pan it changing display start parameter of xdl

bottom line - its not enough to set the screen width to narrow, xdl must reflect it

[flashjazzcat]

screen width and window width are two diffrent things

you may have standard res narrow field screen with 1024 wide window, and you can pan it changing display start parameter of xdl

bottom line - its not enough to set the screen width to narrow, xdl must reflect it

 

XDL reflects it: narrow playfield, 256 byte line width. Blits changed to suit - but they're still skewed. If I keep XDL line width at 320 bytes and blit offsets also 320, all is well - despite narrow playfield width.

 

Here's the section of the XDL covering the progress bars:

 

.byte ~01100010 ; set address + graphics + repeat
.byte ~00001000 ; standard-res graphics
.byte 3 ; 4 lines
.word VBXE_SCR_AD2
.byte 0
.word 256 ; line length
.byte ~00000000 ; narrow playfield
.byte ~00000000
.byte ~00100100 ; just repeat
.byte 0
.byte 3 ; 4 blank lines
.byte ~00100010 ; 4 more SR lines
.byte ~10000000
.byte 3

Edited January 2, 2012 by flashjazzcat

[phaeron]

This is all well and good with the standard version, but since the LW's VBXE driver keeps the 8KB MEMAC window open at $A000, VBL progress bar updates will fail if the cart ROM is present at $A000 when the driver tries to call a blit operation at the same address. The solution is to open a smaller MEMAC window at another location during I/O. This is no problem, since the VBL is the only thing running during SIO, so the window can go anywhere but the CIO buffer address.

 

So - the reason for wanting a delay was to simply set the progress bar off at the start of the CIO call, then have no further access to the MEMAC window until I/O was complete.

 

I don't think you even need the MEMAC window. You should be able to set up a self-modifying blit list so that you only need to write to BLITTER_START to post a new block: have a 2-entry list where the second entry offsets the destination pointer of the first. The blit list pointer resets every time the blitter starts, so you just have to keep restarting it.

[flashjazzcat]

I don't think you even need the MEMAC window. You should be able to set up a self-modifying blit list so that you only need to write to BLITTER_START to post a new block: have a 2-entry list where the second entry offsets the destination pointer of the first. The blit list pointer resets every time the blitter starts, so you just have to keep restarting it.

 

Brilliant idea - thanks yet again! Actually the VBXE driver works out very nicely with SDX library access, since the screen display is not disturbed at all.

[Rybags]

Altirra is good for working out XDL problems.

 

.vbxe_xdl

 

A potential pitfall is to get parameter blocks mixed up... I can remember having bitmap screens not work because I'd put in parms for Attribute Map rather than Overlay screen.

[flashjazzcat]

Altirra is good for working out XDL problems.

 

.vbxe_xdl

 

Heh... I've typed .vbxe_xdl and .vbxe_traceblits on more times than I care to remember over the past couple of weeks. Altirra's debugging facilities are stupendously good.

 

These self-modifying blitter destination addresses: how to bump them using only bitwise operators, or have I missed a trick somewhere?

[Rybags]

Don't forget the Add mode.

 

Although problem there is only 8-bit numbers.

 

16-bit could be done using a LUT method to deduce the high byte, but then it's costing a whole bunch of memory.

 

But for a progress bar you can essentially keep it within a page boundary for origin in narrow mode. And of course don't forget the 160x mode.

 

For Moon Cresta I'm just using 6502 to convert the 7800 X co-ords to address offsets. Costs a shift/rotate per object. To keep things simple I just use 512 as the line offset for the bitmap. Dual benefit in that I just allow offscreen objects to render, so saves clipping and having to do checks for stuff that doesn't need rendering.

[flashjazzcat]

Totally missed the add mode... I'll get into trouble from Candle. Thanks.

 

8-bit precision is no problem at all. In the standard version, which uses mode 4 for the progress bar (80px), I use the middle 64 pixels (8 bytes) of the screen line and downscale the increments from a 256 byte counter. This is why I'm using a narrow playfield in the standard VBXE resolution, and it has a nice 1-1 mapping to the counter. Reason for 256 increments: tagged file operations use simple division so that the upper progress bar increments proportionally to the number of selected files processed.

 

The easy-clipping's a nice bonus in Moon Cresta. Since we're brainstorming here, in a couple of years when I have time to produce a VBXE version of the GUI, is there any way to blit bitmapped fonts without first converting the 1bpp information to explosively huge 8bpp bitmaps? 24pt fonts in the GUI will be up to 16KB in size at 1bpp - that's 128KB at 8bpp. VBXE's VRAM is not unlimited in size...

[Rybags]

I've thought up a bit of a method, it's mainly related to doing C64 sprite conversion and is kinda wasteful too.

 

If we sacrifice number of availble colours then we can use masking to create copies of 1bpp objects.

 

So, e.g. input font is 1 bpp and we want to display in 256 colour mode:

 

First mask is $80, then $40, $20 ... 2, 1. Essentially we use 8 palette entries which are all set to the single RGB value.

 

Like I said - a bit wasteful. I thought it out a bit and thought maybe we could use masks + add mode, but it just won't work.