The Last Word VBXE Edition

[flashjazzcat]

Strangely exciting this... Short video of first working version of LW 4.0 running on real hardware for the first time:

 

 

Should be able to use the blitter creatively to speed things up quite a bit; i.e., put the line buffer in VBXE RAM and blit it straight to the display memory after word wrapping, etc.

Edited January 13, 2010 by flashjazzcat

[Heaven/TQA]

cool...

[dwhyte]

I'm drooling...

[candle]

my mouth is watering when i'm watching this

now do this with blitter

[Rybags]

Cool.

 

The ironic thing is that we may well have a WP that's quicker than the current M$ offering.

 

Gotta say, Office seems to get worse with every release.

[+Stephen]

Awesome! Looks nice and fast already, can't wait to see how the blitter will speed it up.

 

Stephen Anderson

[phaeron]

The funny thing about the VBXE blitter is that it is much faster than the 6502, even when you ask it to do really crazy stuff like tons of one-pixel blits. At 21 bytes per blit and 8 VBXE cycles per machine cycle, the blitter can setup blits at the rate of about every 1-2 instructions. That means that in order to really utilize the blitter, you need to either do large blits, reuse blit lists, or just find a way to set up blit lists very rapidly.

 

For some reason, I love abusing blitters. I think it'd be possible to both layout and draw proportional text entirely on the blitter -- use a bunch of one-byte blits in add mode to generate the x coordinates for each character, another one to copy text characters into a blit list, execute that as a third pass to copy bitmap pointers for each character into another blit list, and then execute that to finally blast them onto the screen. Pad the passes with degenerate blits and you can run the whole thing in one big list. The annoying problem is that the blitter doesn't have a numeric compare mode, 16-bit addition, or addition with carry, so it's hard to do this for cases where a byte quantity doesn't suffice.

 

Another fun use for the blitter might be to generate 6502 code....

[flashjazzcat]

The funny thing about the VBXE blitter is that it is much faster than the 6502, even when you ask it to do really crazy stuff like tons of one-pixel blits. At 21 bytes per blit and 8 VBXE cycles per machine cycle, the blitter can setup blits at the rate of about every 1-2 instructions. That means that in order to really utilize the blitter, you need to either do large blits, reuse blit lists, or just find a way to set up blit lists very rapidly.

 

For some reason, I love abusing blitters. I think it'd be possible to both layout and draw proportional text entirely on the blitter -- use a bunch of one-byte blits in add mode to generate the x coordinates for each character, another one to copy text characters into a blit list, execute that as a third pass to copy bitmap pointers for each character into another blit list, and then execute that to finally blast them onto the screen. Pad the passes with degenerate blits and you can run the whole thing in one big list. The annoying problem is that the blitter doesn't have a numeric compare mode, 16-bit addition, or addition with carry, so it's hard to do this for cases where a byte quantity doesn't suffice.

 

Another fun use for the blitter might be to generate 6502 code....

The fun part about the blitter will surely be finding abstract uses for it. I still haven't gotten my head around your suggestion for mapping out proportional text using the blitter: I'll have to read that again half a dozen times! If I can use the blitter in the manner I described, though, it will cut out the whole second-pass loop which "standard" versions of LW required lots of fancy optimisation code to avoid. Because of the layout of the VBXE attribute bytes, I'm hoping I can program the blitter to copy the visible portion of the 256 byte "plain" line buffer to the display RAM, skipping every other character to avoid the attribute byte. Keeping lots of buffers in VRAM like this in order to use the blitter is a good argument for using the MEMAC_A buffer and keeping it permanently switched in for the CPU (as things are at the moment). It's more RAM hungry, but since LW's text buffer occupies $4000-$7FFF, it's a little more flexible to use an 8K VRAM window at $A000. I think blitting the screen RAM up and down for scrolling will be more or less redundant when the refresh routine uses the blitter: it will be so blisteringly fast at redrawing the screen that hopefully no further optimisation will be needed. It will certainly keep up with the fastest useable key repeat rates.

 

From being a little sceptical in the early days about the "ethics" of a hardware upgrade like VBXE, I must say it's a real thrill to write my first program using the device. It's great for Atari-8 only programmers like me who wouldn't otherwise get access to blitter lists and other such delights. As for comparisons with MS Word, I have absolutely no doubt whatsoever that a virtually full version of MS Word for DOS would be possible using VBXE. I'm already looking into possible ways of running LW's code from an extended bank or banks, so we could be well on the way to having the most powerful WP on any 8-bit computer, period!

 

Other ideas - such as having the text buffer itself held in VRAM, might be possible in future but as ever the logistics of creating virtual buffers using a pool of extended banks is very expensive, particularly given LW's text buffer model. I think it's a case of one step at a time here.

 

Anyway - because it will take a long time to complete this app in a way which fully exploits VBXE's capabilities and because I know a text editor which uses the device will be useful to a lot of people, I see no reason not to release a "seat of your pants" version at the weekend. Save for a few visual glitches, the thing works fine as is.

[+bf2k+]

I guess I need to finish my VBXE install - just need to do the cable...

[Heaven/TQA]

I was thinking about using the blitter, too, for different things than gfx...

 

and generating unrolled loops could be done easily... I even thought of using it for scrolling as you could simply copy map data into vram quicker than setting up f.e. 25x2 lms adresses in the displaylist (assuming f.e. 48x25 line playfield).

[Rybags]

Proportional text in VBXE bitmap is a gimme thanks to byte sized pixels in 160/320 mode.

 

640 mode almost as easy, probably just keep 2 copies of the font or something to save needing to shift a nybble over.

 

Add with carry, and other maths operations would have been nice - think 3D calculations here.

 

Another nice feature would have been some sort of planar to chunky conversion... thinking along the lines of being able to store sprites as 1, 2 or 4 bytes per pixel to save memory, then have the blit convert them to byte pixels with an offset added.

[JamesD]

Cool.

 

The ironic thing is that we may well have a WP that's quicker than the current M$ offering.

 

Gotta say, Office seems to get worse with every release.

You must have a slow PC.

[Ransom]

Cool.

 

The ironic thing is that we may well have a WP that's quicker than the current M$ offering.

 

Gotta say, Office seems to get worse with every release.

You must have a slow PC.

 

Microsoft's office building full of employees working on MS-Office can't write code as efficient as that turned out by one Flashjazzcat.

[Rybags]

I don't have a slow PC. I do have probably 3 or 4 versions of Office from '97 forwards.

 

Each one is rediculously slowed down compared to the one before. '97 feels like lightning compared to the later ones. Suppose we can thank feature-creep/bloat as well as the tendancy for stuff to be written these days in crappy scripting languages or one of the .NET variants.

[AtariNerd]

Fantabulouser and fantabulouser.

[Shawn Jefferson]

From being a little sceptical in the early days about the "ethics" of a hardware upgrade like VBXE, I must say it's a real thrill to write my first program using the device. It's great for Atari-8 only programmers like me who wouldn't otherwise get access to blitter lists and other such delights.

 

You might get a kick out of the Atari Lynx, it contains sort-of "blitter" sprite hardware that is very powerful and also sports a 6502 running at 4Mhz. Not much use for a WP on the Lynx though, I imagine!

[flashjazzcat]

I hope I'm reading the blitter docs correctly, but it doesn't look as if there's an easy way to do copy this:

 

[char1][char2][char3][char4]...

 

to this:

 

[char1][atr1][char2][atr2][char3][atr3][char4][atr4]...

 

Basically the 6502 builds the output buffer for a line (up to 240 characters long) from the non-linear text memory, scans back to do word-wrap, handles block highlighting - yielding a line of known length. The idea was to keep this 240 byte buffer in VRAM, and blit the visible portion of the line straight to the display RAM, skipping the attribute bytes (which - for the moment - will only change when the user colour scheme is altered). As I read the situation, in order to employ the blitter like this, the output buffer would have to be populated with the attribute bytes present, then blitted across. This creates problems with indexed addressing, unless we slash the permissible (windowed) line length down to 120 characters.

[candle]

there is special blitter mode for this...

[flashjazzcat]

To copy a byte, inc source ptr by 1 and dest by 2, then copy next byte, inc source ptr by 1 and dest by 2, etc?

Edited January 15, 2010 by flashjazzcat

[candle]

hm, my bad

but still doable with a single blit

just treat source as 1x240 pixels blit, and destination as 2x240

[flashjazzcat]

So we treat each character as a separate line and thus gain control over how many bytes to skip between elements?

[candle]

why not? there is no moral guide to help us not to abuse blitter

[Rybags]

You can just use Dest_Step_X of 2. Height is limited to 8 bits which would be very restrictive if moving text as 1 byte/line.

 

Since Width parm is 9 bits, means you should be able to do ~ 128K moves in a single move. So, just store low byte of block size in Width_0, AND high byte with #1, store in Width_1, then LSR high byte of block size and store in Height.

[flashjazzcat]

Is Dest_Step_X added in between each copied byte? The docs are unclear about this. I only need to individually blit twenty odd eighty character lines to the screen RAM. So a blit operation with source as the line buffer, dest as the line in screen RAM, width as 80, height as 1 and dest_step_x as 2 would do the job, copying the line and not disturbing the attribute bytes???

[Rybags]

That should be it - remembering too that the step x/y parms are signed. I'd assume VBXE always blits in the logical order you'd expect, so e.g. if you wanted to do something like Move $1000-$1FFE to $1001-$1FFF, you'd need to setup the blit to work backwards so as not to just get a repeated copy of what's in $1000.

 

ed - also remember, at "end of line", Dest_Step_Y is added to the initial address of the line, not the current blit address.

Edited January 16, 2010 by Rybags