Jump to content
flashjazzcat

The Last Word VBXE Edition

Recommended Posts

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

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Stephen Anderson

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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! :D

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by flashjazzcat

Share this post


Link to post
Share on other sites

hm, my bad ;)

but still doable with a single blit

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by Rybags

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...