VBXE ideas

[Shawn Jefferson]

Just started getting into the programming manual for the VBXE, and doing some messing with it. It's pretty easy to program for and very flexible, which is nice.

 

A couple of ideas I had for applications for VBXE (probably already discussed somewhere):

 

1. There is a Rambo core, but what about a 130XE core that gives the XL models true 130XE compatibility (ie, ANTIC and CPU access to 4 extended ram banks?)

 

2. Fast task switcher, should allow 4 simultaneous tasks, and make switching between them much faster than previous attempts (Snapshot for instance).

 

Possible Approach:

• Map a 32k VBXE ram window starting at $0000.
  
• Initialization app would preload a "almost booted" environment to each of the 4 (or less depending on configuration), and setup the ability to toggle between environments. I'm assuming that putting the OS into RAM and modifying the keyboard routine would be the way to do this.
  
• The toogle code (stashed somewhere where it hopefully won't get clobbered) would then use the VBXE blitter to copy the ram from $8000 to $BFFF to VBXE memory, and then copy in the correct $8000 RAM, swap in the $0000 memory, restore the PC, SP, etc.. and jump back to the correct place in memory (taken off the stack earlier I guess?) The toggle code resident in regular memory would just be a small stub that maps in VBXE ram and jumps to the real toggle routine there, of course.
  

 

I'm assuming that the blitter is faster than using the 6502 to copy, and that enough software would be compatible with this scheme to make it remotely useful.

 

Some general VBXE questions:

 

Is there a way to define 3 blank lines in the XDL, like there is with the DLIST?

 

I guess since you can't read the color registers, you'd need to have a "standard" palette stashed somewhere to restore if you overwrite palette #0?

 

Are there any utilities to convert standard picture formats to that required by the VBXE? (maybe a dumb question, since some of these formats may be basically what is already being used. )

Edited February 7, 2011 by Shawn Jefferson

[Rybags]

I have that same idea floating around for a multi-tasking system. With 512K, we could have a number of "virtual machines" - just a slight shame that we can only override a 32K window at a time.

The way I figured is to just leave the base 32K of main RAM alone, it holds the initial task-switching program, since that bank will be the default when the user hits RESET, you want your control program there.

Then you just map VBXE RAM into the 0-32K region, and have to manually move the remaining RAM into the 32-64K area.

Of course with some extra work, a 128K VM would be possible as well.

The other use I've found is we can simulate some banked cartridges - e.g. I made a Mac-65 hack that runs the cartridge within VBXE RAM, leaving the 40K user area free.

 

130XE compatible mode - I guess it could have been implemented since the VBXE has all of Antic's signals available to it, although I'm not sure that there were enough inputs on the AVR to cater for it.

 

I'm assuming that the blitter is faster than using the 6502 to copy, and that enough software would be compatible with this scheme to make it remotely useful.

Way faster. To begin with, VBXE operates 8 times quicker than the 6502 @ ~ 14 MHz vs ~ 1.8.

To move a byte from one place to another costs 8 6502 cycles, or 6 if you "brute-force" move by LDA #xx / STA $yyyy.

In the simple blit/copy operations, it's 2 cycles per byte (1 read, 1 write).

So, in that 8 cycles of the 6502 for one byte, VBXE has 64 cycles for 32 bytes.

Of course, there's DMA contention in both cases. VBXE loses a cycle for each byte of graphics, XDL or BCB data it has to read, but the 22 cycles overhead per BCB is nothing really. VBXE also loses a cycle if the 6502 needs to access RAM that's being provided by a VBXE RAMAC window.

Naturally, the XDL and graphics takes precedence always. There's always cycles to spare though since the 6502 can only request one access every 8 VBXE cycles, and the most demanding VBXE graphics fetches only steal half the available cycles during their onscreen area. "6502 accesses" in these cases can also mean Antic.

Not sure what happens with Antic Refresh cycles, whether VBXE ignores them or they cause a cycle drop, but in the context of a 14 MHz part, they're pretty inconsequential.

 

Is there a way to define 3 blank lines in the XDL, like there is with the DLIST?

The Repeat bitsetting takes care of multiple occurrences of modes or lack of within the XDL.

 

I guess since you can't read the color registers, you'd need to have a "standard" palette stashed somewhere to restore if you overwrite palette #0?

Best practice is - don't ever touch palette #0, just leave it at default.

There's no way to get VBXE to reload it other than powering off/on. You're better off just using the other 3 palettes if you want custom colours and leaving #0 as is.

 

Are there any utilities to convert standard picture formats to that required by the VBXE?

Not that I know of, when I want something I just create a BMP in Photoshop and save it as 8 bpp. Select the option to invert it, by default BMPs are stored upside down.

You can then read the pic, IIRC you skip something like 1074 bytes to get to the bitmap data. With 256 colour indexed BMPs, the palette data is also stored, so if you want you can get the RGB for loading into a set of palette registers.

[phaeron]

You can't use the VBXE blitter to access Atari memory -- it can only copy within VBXE memory. It's a shame, because otherwise it could be used for other things like MyIDE DMA.

[Shawn Jefferson]

Yes, of course, I read that, but for some reason still wrote it above... We'd have to copy using the 6502 then, but only about 16k.

 

Rybags: are you suggesting hooking the RESET vectors instead of patching the keyboard routines in the OS?

[Rybags]

Task switching you could have a two-pronged approach - CASINI vector for when the user presses RESET, and a keyboard IRQ intercept.

 

Problem with the keyboard approach is you then have to allocate some piece/s of RAM that handle the IRQ. No matter what you do, it's going to clash with something.

Could always have it as an option per task, I suppose.

 

VBXE being able to access Atari RAM would have been nice. But the main problem is the non-deterministic nature of Antic DMA.

 

You can't even rely on a "simulation" of what Antic's doing because changes to H/Vscrol registers can alter what happens, and the nature of that alteration can vary depending on when those registers change, if the particular scrolling is enabled etc. Not to mention DMACTL.

 

I guess all that could have been shadowed and simulated but it seems the core is full as it is - better to have the features we've already got than to make sacrifices just to achieve this ability.

 

If some space did come up and there was room for another minor feature, my biggest wants by far would be a Translate function for the blitter where Dest data was transformed according to indexes within the Source lookup table, and some 16-bit maths abilities (just ADD would be a huge gain).

 

Translate would mean you could have tables with all the predefined bit rotate results, which could improve the way VBXE can enhance legacy graphics generation.

[candle]

vbxe won't be able to write to atari memory because it won't act as bus master under any circumstance - simply halt is output only (totem-pole - either on or off, no hi-z state) from antic chip, and thus vbxe driving it would clash whole system

true dma system can be implemented on '816 because of vda and vpa lines, on 6502 this can be done using sync line (unconnected inside atari) and lookup table with cycle counts for any given opcode - some additional logic would cut off cpu from the bus and replaced address lines and data lines with apriopriate values

but this is another story

[+davidcalgary29]

Can anyone please post a link to the manual? Perhaps I’m just dense, but I can’t seem to find it.

[Rybags]

Bottom of this page http://spiflash.org/node/10

 

Might be elsewhere but that's where I get them.

[+davidcalgary29]

Great — thanks!