VBXE Bliiter?

[Thelen]

I'm doing some blitter tests with the VBXE and blitter. Since I'm just a hobby programmer I never used any form of blitter before and I'm curious how things can be done.

 

First, when I'm doing a blitter start by writing #1 to VBXE_BLITTER_START, there will be 12 blitterblock done, and I should wait some time till its finished. I see examples which waits for VBXE_BLITTER_BUSY - but in the manual I read that after each blitterblock in the blitlist it will change from 1 to 0, and with the next blitterblock in the blitterlist it will be 1 again, and so on for the 12 blitblock.

Why should I wait for the Busy flag to be 0? The blitlist isn't done completed yet, just 1 blitblock is done. should I count the 11 changes- and then I know the blitlist is done? Or don't I unstand it correctly? ?

Also, if I have multiple sprites which are blitblocks, and these sprites are enemy's - I shoot them randomly... I will remove this sprite(blitterblock) from the blitlist, so it dissapears. Then i need to change the blitlist on the fly. Or should I just change to source/destination of a unused blitblock to something you can't see? What is a good way to remove/add blitterblock to a blitlist and how to keep track of this ? Also, right now I'm doing multiple different blitlist. One for Tiles, One other for sprites etc.

 

Thanks again for the help ?

 

 

 

 

[Rybags]

The busy register has 2 bits - I'm fairly sure I've just tested for 0 value to ensure everything's finished.

Bit 1 = 1 means actual blit is in progress.  Bit 0 = 1 means A BCB is being read.

Given that VBXE can read an entire BCB in under 3 6502 cycles (dependent on losses to higher priority fetches), it'll actually be fairly rare to check the status register and find it in that state.

 

An annoyance can be that there's no skip facility for objects that you want to keep defined by not draw at a particular time.

Just changing to a dummy operation, e.g. write one byte out somewhere can be helpful there - you waste 24 VBXE cycles but in the long run will probably save time vs having to construct the BCB chain for every situation.

 

Another trick you can use - program a BCB chain that sets up the BCBs to do your object draws.

 

From memory with the Moon Cresta conversion I used one BCB chain to draw sprites, another to erase them and had those dummy draws for inactive ones.

I also used had the bitmap setup so that more memory was allocated per scanline than actually used.  I think I used 512 bytes rather than 320.  Doing that makes the address calculations easier since it's a power of 2.  Also it means you don't have to worry about overdraw problems.

[phaeron]

The blitter can both be faster and slower than the 6502. It runs at VBXE speed (8x or 14MHz), but it's also the lowest priority on a separate memory bus. When the local memory bus is free, it can read a BCB very fast, quicker than the 6502 can detect and reliably count each blit. However, when the attribute list is active, it can stall the blitter for more than 172 local cycles (21 computer cycles), which is enough time for the 6502 to race the blitter on the blit list or the source/destination memory. Thus, the safest thing to do is for the 6502 to wait until the blitter is completely done before touching the blit list or source/destination data. BLITTER_BUSY will alternate between $01 and $02 as each blit is loaded and processed, and then return to $00 once the blit list is done.

 

However, this method of synchronization is very inefficient. Spending a hundred cycles on the 6502 to update the blit list can cost almost a thousand blitter cycles while it is idle. A way to increase this parallelism is to update the blit list as soon as the blitter has read it, even before the blit itself completes:

• Waiting for only BLITTER_BUSY bit 0 to clear.
• Update the blit list.
• Wait for BLITTER_BUSY bit 1 to clear (or both bits to clear).
• Restart the blitter.

This minimizes blitter idle time by restarting it ASAP, as long as the 6502 can rewrite the blit list faster than it takes for the blitter to do the blit. This is more likely if only a few bytes are being modified.

 

This only works if the blit list is a single blit, though. This is often still inefficient due to synchronization overhead. If it has more than one blit, the 6502 can't tell if only the first or both BCBs can be read. This can be worked around by using a technique from modern GPUs: a fence. One way is for the blitter to write a byte to VBXE memory that the 6502 polls for a change, after which it knows that the blitter has passed that point. Another way which could be faster is to use the BLT_COLLISION_CODE register, since I think reads from that register don't cost VBXE memory cycles. With this technique, you could concatenate the tile blit list with the sprite blit list so the blitter runs at full speed, and still have the 6502 work on the next tile list as soon as the blitter begins processing the sprites. But honestly, in most cases it's better just to rearrange things so that the 6502 writes everything to a data structure that's convenient for it and then kicks off a big chonky blit list.

 

As for how to omit blits, it should be possible to do a compress operation if you really wanted to do it, by using the blitter to compute destination addresses to copy its own blits in place. Tools for doing this are a partial sum (add mode with dst = src + 1), and treating blit lists as 21xN or Nx21 'images' to copy blit control blocks. It's probably faster to use dummy blits, though, such as by conditionally zeroing bytes 8-15 and forcing the blit to a 1x1 write in VBXE $00000-000FF -- which also has ways to be optimized, like a zoomed AND blit from a set of byte flags. Remember also that the blitter only reads one BCB at a time and can write into the blit list it is processing -- including having one blit set up the next BCB(s) in the list.

 

[Thelen]

Thanks Rybags and Phaeron for your replies- With this I can blit further ? It's fantastic that there is so much knowlegde on AA!

[Rybags]

I'm not sure of phaeron's suggestion - it was my impression that blits are done sequentially, ie read one, perform it, read the next and perform it etc. rather than reading all in sequence and creating a work queue.

Possibly some experimentation needed there.

[Mclaneinc]

 

Just a shame that the VBXE never took off, so much potential, reminds me of the C64 DTV, a C64 joystick looking thing with additional hardware updating the graphics modes. This and the VBXE had some nice demo's, but just never anything much beyond that.

[phaeron]

7 hours ago, Rybags said:

I'm not sure of phaeron's suggestion - it was my impression that blits are done sequentially, ie read one, perform it, read the next and perform it etc. rather than reading all in sequence and creating a work queue.

Possibly some experimentation needed there.

Yes, there is no queue. It does buffer the current blit, so once the BCB has been read for a blit it can be overwritten during the blit. But the fact that it only reads one BCB at a time can be exploited, because a blit list can update later parts of itself before those blits get executed.

 

3 hours ago, Mclaneinc said:

 

Just a shame that the VBXE never took off, so much potential, reminds me of the C64 DTV, a C64 joystick looking thing with additional hardware updating the graphics modes. This and the VBXE had some nice demo's, but just never anything much beyond that.

This is an issue with any add-on that requires software to be specifically written for it. Take the Sega 32X, for instance. That the VBXE requires an internal install and requires a monitor that can take 15KHz RGB doesn't help.

 

If VBXE had some small additional functionality, it could have been used to enhance unmodified programs as well. For instance, if VBXE could map the whole 64K address space and retrigger the blitter automatically every frame, there are some interesting things that could potentially have been done to enhance regular video modes.

[Mclaneinc]

14 hours ago, phaeron said:

This is an issue with any add-on that requires software to be specifically written for it. Take the Sega 32X, for instance. That the VBXE requires an internal install and requires a monitor that can take 15KHz RGB doesn't help.

 

If VBXE had some small additional functionality, it could have been used to enhance unmodified programs as well. For instance, if VBXE could map the whole 64K address space and retrigger the blitter automatically every frame, there are some interesting things that could potentially have been done to enhance regular video modes.

It's only when you understand the underlying technicality of the item, as you and others do, that you see why it didn't fly. People like me see the fancy demo's and think what could have been without understanding just how much hard work is needed to get those results. Now I see why it shot itself in the foot... Thanks, Avery..

[flashjazzcat]

I don't think VBXE 'didn't fly' or 'shot itself in the foot', at least in terms of sales and boards in machines. It's been selling since 2009 (with a hiatus after that, before Lotharek started selling them), and although I don't have sales figures here, I've had enough boards through my hands these past few years to know it's sold well (if we take the number of boards I've installed and extrapolate it to encompass other installers around the world, and users who installed their own boards). If the expectation or hope was that VBXE would become a completely ubiquitous video upgrade, then - IMO - this was half-achieved, so the only criticism is presumably that there weren't a huge number of games written for it. But it's impossible to predict whether developers will write software for a given piece of hardware, no matter how good the hardware is (since time, ability and motivation also need to be available). If game authors with time on their hands consider a user-base of (surely) up to four figures too small of a market in a community which is small to begin with, it may not be shortcomings in VBXE's design which are to blame for the dearth of games.

Edited May 16, 2022 by flashjazzcat

[Rybags]

It's about half the price now vs when I got it (fairly early ~ 2009 I think).  So, a whole lot more affordable.

[Thelen]

Probably when choosing to make a 'new' game for the Atari 8 bit you should decide (if you have a VBXE) to make something that all A8 users can play, or just a selection of people who have the VBXE installed.. I did doubt about this too, but I think the VBXE is a really nice product and that it should be fair(13 years later) to program something dedicated for it. I always dreamt about Super-Nes GFX on my Atari when I was young(who didn't ? ), like my little brother had on his SNES, I alway tried to program those games in Basic, but it never worked out that way ? - and now I can with VBXE ?

 

Either way, I was suprised by the making of Commando for VBXE. As you can see, there are not that many reactions about this new release in comparison to other new native A8 releases - and when I'm seeing that I'm hoping that the author(s) will stay motivated....   Some encouragion is important ?

 

 

Edited May 16, 2022 by Thelen

[Meadow Glen]

The VBXE is still the best upgrade in my view.  Truth is for my machine it has perfect output whether via retrotink to modern display or a 15khz monitor… until I hook up problem peripherals and then snow.  for me this is solved with clean power.  like 5v drives are powered from battery.  crazy but true.   but if using a simpler setup even that is not necessary.  

 

ok but notwriting about that.  the comment was made enhance known modes

 

absolutely.  in altirra flicker modes dont flicker, unless you want.

 

take a look at 8 bit unity project.  if flicker modes didnt flicker you would essentially have more colors.

 

this is where someone corrects my words.  me no use words good…my point is the games are there like8bit slicks.  the tools are there.  if thise flicker modes were enhanced by hardware to have altirra like frame blending…effectively more colors with nothing new to learn, coding wise

 

no real hardware is known to eliminate flicker in flicker modes

[Mathy]

Hello guys

 

The VBXE probably suffers from the same problem memory extensions have been suffering from for decades: "nobody has an upgrade, so let's not write software for it" and "nobody writes software for upgrades, so why install them?"

 

Sincerely

 

Mathy    (who really, REALLY, hates that kind of thinking as it gets us nowhere)

 

 

[_The Doctor__]

like many upgrades key items that would have cost little to nothing to include for this or that get left out. This leads to some big challenges later on. It works, it's great, but something always gets in the way of performance and usefulness as Phaeron very judiciously and diplomatically points out. Sort of thing happens all the time, maybe the let's go for it barrier needs to be broken for all future upgrades, though the current chip situation is really a pain in the *SS

Edited May 16, 2022 by _The Doctor__

[+Stephen]

41 minutes ago, Mathy said:

Hello guys

 

The VBXE probably suffers from the same problem memory extensions have been suffering from for decades: "nobody has an upgrade, so let's not write software for it" and "nobody writes software for upgrades, so why install them?"

 

Sincerely

 

Mathy    (who really, REALLY, hates that kind of thinking as it gets us nowhere)

 

 

I've finally been doing some VBXE coding, but nothing great and I have limited free time so I won't be putting out any "killer apps".  I'm also struggling mightily learning not only new hardware, but trying to do things in 100% assembly so learning that, and MADS - wow, steep learning curve for many of the features it provides.  I'm trying though.  Keeping everything in a GIT repo so I can share it when it's worth doing so.