Jump to content
IGNORED

The Last Word VBXE Edition


flashjazzcat

Recommended Posts

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

 

Yes, you are right, except that width should be 79 and height 0.

Edited by electron
Link to comment
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???

Yes, you are right, except that width should be 79 and height 0.

Excellent - thanks. Hopefully I'll get the chance to code that up this evening. It should be quite fearsomely quick. With the overheads of screen drawing being so trivial, expanding tabs, etc, should be easy to implement down the line.

Link to comment
Share on other sites

Blitter operation to clear to end of screen is crashing the program: some silly bug in there. I'll write a quick routine to blit scroll the screen up (for viewing files from disk and print preview), and hopefully implement the quick line blitting tonight. My intention is to release a beta version which is to all intents and purposes 99% functionally identical to the non-VBXE versions of LW, then field feature-requests and suggestions and proceed from there.

 

 

 

Link to comment
Share on other sites

Clear to end of screen using blitter works now. However, I can't get the line to blit from OUTBUF to the display RAM using the method we discussed. BCB is like this:

 

bcbrefresh
 .word outbuf-$A000 ; src adr
 .byte 0
.word 0  ;src step y
.byte 1  ;src step x
bcbrefresh_dest
.word VBXE_SCR_AD ;dst adr
.byte 0
.word 160 ;dst step y
.byte 2 ;dst step x
.word 79 ;width
 .byte 0 ;height
.byte $00 ;and mask
.byte $00 ;xor mask
.byte $00 ;collision mask
.byte 0  ;zoom
.byte 0  ;pattern
.byte 0  ;blt control
;

 

OUTBUF is located at $B700 (the MEMAC window is at $A000) and all the offsets at the Atari and VBXE sides appear correct. Calling routine updates the source address to an offset into OUTBUF in VRAM, and the dest address is calculated according to a table of line locations in VRAM. When I try this, I get lines of repeated characters on the screen. They're yellow, too, so the attribute bytes are obviously being corrupted.

Edited by flashjazzcat
Link to comment
Share on other sites

Shouldn't your AND mask be $ff?

Good spot: It probably should be and it was at various stages. I don't think this was the problem, however, but I'll look at at again later. I tried lots of different values in the source and dest parameters but after ninety minutes or so getting the same garbage on screen I decided to turn my attentions elsewhere. The WP is pretty fast without the line blit but I know it's going to be some 200% faster when I get it working.

 

One thing I notice as I revise the code for VBXE is just how much code in a large app like this was previously devoted to converting Internal codes to ASCII and vice versa (in LW 3.x, the text is stored in memory in Internal code format). No need with VBXE, which is big advantage.

Edited by flashjazzcat
Link to comment
Share on other sites

fjc, try with some static data - fixed source and desitination addresses, just to exclude possiblity you're putting wrong addresses in there, or putting wrong address of bcb into blitter's registers

Thanks - that's more or less the tactic I'm adopting. The situation hasn't been helped by my Broadcom WLAN card apparently packing up (typing this on the laptop). It was a special OS X compatible one... groan. Will have to buy a cheap stop-gap in the morning. :(

Link to comment
Share on other sites

Line blit finally works. The problem was resolved by rearranging the BCBs in memory. I don't know why, but the blitter calling mechanism adapted from "TEXTMODE.COM" in the VBXE release package just didn't like the refresh BCB being in position 6. There must be a problem with the blitter calling mechanism which I'll resolve at length when I fully understand it. I swapped the refresh BCB with the scroll/clear last line BCB and refresh now works. There's a glitch with scrolling in print preview now, and that may or may not be linked to the re-jigging.

 

Anyway, things are running just about as quick as you'd expect. I'll cobble together a couple of custom blitter routines to handle LW's usual black status bar during screen clears, tidy up one or two other bits, and we'll have a fully working word processor.

 

More ambitious concepts have plagued my thoughts this morning. It might be possible to have extremely large text buffers held in VRAM, and to get around many of the headaches of bank switching by forcing the main program to interact with the text on a line by line basis. The blitter can easily extract any portion of text from a stupendously large text buffer in VRAM and place it in a buffer for 6502 access. Moving the text around in memory can easily be accomplished with the blitter, and loading and saving text will be a simple matter of sequentially banking in the relevant portions of text for CIO. LW's fancy techniques for high speed editing might be made redundant by such a system, which in turn would greatly simplify many other parts of the program. I don't expect to get around to this for a while, though: although it looks quite logical on paper, it will certainly be a complicated thing to implement.

 

I should get LW 4.0 "VBXE Edition" uploaded in beta form this evening. It will be available without restriction.

 

http://www.youtube.com/watch?v=FtltQw2kNo4

 

post-21964-126382026648_thumb.jpg

 

post-21964-126382027425_thumb.jpg

Edited by flashjazzcat
Link to comment
Share on other sites

Thanks! :D

 

Still coding away till the wife gets back. :) I keep running into time-wasting bugs, mainly down to not fully checking the original code I'm modifying. For instance, TEXTMODE.COM uses a 2-byte pattern for screen/line clears and it took me a good 45 minutes to figure out that my expanded collection of BCBs had overwritten the char/attribute pattern. That's how I found out that a BCB which inadvertently addresses its own memory space won't run. Then there was the BCB set-up loop which used BPL instead of BNE in a Y register countdown. Didn't spot that for a long time, which meant the BCBs weren't being copied once they occupied more than 128 bytes.

Link to comment
Share on other sites

Totally failing to understand how to use the attribute bytes to change the background colour of certain lines. For example, I want two lines of white text on a black background at the foot of the screen. The description of background attributes in the docs leaves my head aching.

 

I assumed setting the high bit of the attribute byte meant that the background colour was attribute value & 127, but it isn't working. Clearly I have a fundamental misunderstanding of the attribute system. Surely it would have been easier to split the attribute byte into two nibbles (foreground and background) and allowed fifteen opaque colours (customisable via the palette) and $0 to signify transparency?

 

Well - that's it for tonight. Hopefully all will be revealed in the morning.

Edited by flashjazzcat
Link to comment
Share on other sites

Totally failing to understand how to use the attribute bytes to change the background colour of certain lines. For example, I want two lines of white text on a black background at the foot of the screen. The description of background attributes in the docs leaves my head aching.

 

I assumed setting the high bit of the attribute byte meant that the background colour was attribute value & 127, but it isn't working. Clearly I have a fundamental misunderstanding of the attribute system.

 

When bit 7 of the attribute is set, the foreground color should be (att & 127) and the background color should be (att).

Link to comment
Share on other sites

Check your XDL - make sure the step value OVSTEP is what it should be. Remember it should be the absolute value, not (value -1).

 

High bit of attribute (text map ones, not Attribute Map ones) controls whether background is transparent (show GTIA stuff) or uses VBXE Palette entry 128.

 

Of course if you're also using VBXE Atrribute Map, that can override things and potentially cause confusion.

Link to comment
Share on other sites

Check your XDL - make sure the step value OVSTEP is what it should be. Remember it should be the absolute value, not (value -1).

 

High bit of attribute (text map ones, not Attribute Map ones) controls whether background is transparent (show GTIA stuff) or uses VBXE Palette entry 128.

 

Of course if you're also using VBXE Atrribute Map, that can override things and potentially cause confusion.

 

That's not what the fx1.20-en docs say -- the docs say that the behavior you describe is controlled by the no_trans bit. The way I read the docs, the behavior is as follows:

 

  • If attribute bit 7 is set, the background is always opaque (background = attr).
  • If attribute bit 7 is clear, the background depends on no_trans.
    • no_trans=1 (transparency disabled): background color is $80
    • no_trans=0 (transparency enabled): background is transparent
    • Additionally, if trans15 is set, then all color indices $xF are also transparent.

Link to comment
Share on other sites

Maybe I'm not approaching this issue from the right direction, but this seems the most horribly convoluted way to get colour on the screen in text mode. I know a lot of data is packed into a small space with the attribute system, but I'd have rather had two attribute bytes than a system like this. Is it actually the case that the background colour index is fixed at 128 plus the foreground (assuming the background isn't transparent)? Even the "other" suggested behaviour makes no sense to me. If bit 7 is set, background = attr? In that case, surely foreground must equal attr&127, otherwise it has no value at all. So I need to redesign the palette so that black is exactly 128 entries ahead of white, turqoise is 128 entries ahead of pale turq, etc? And then to allow the user to customise the colour scheme, everything has to be done via palette adjustment?

 

Doable - but not at all what I expected!

Edited by flashjazzcat
Link to comment
Share on other sites

The other bugbear is that Attribute Map isn't totally useful in 80 column mode, since the smallest size is 8 pixels (at 320 res) across.

 

But really, the +128 mode still gives plenty of scope for text-based apps. You could just settle on something like 16 available Foreground colours, and pair them up with 8 possible Background colours each.

Link to comment
Share on other sites

But really, the +128 mode still gives plenty of scope for text-based apps. You could just settle on something like 16 available Foreground colours, and pair them up with 8 possible Background colours each.

 

Exactly. And additionally you have possibility to use 128 independent letter colors - everything depends on palette. In my opinion this system is good and better than 4 bit for char color and 4 (3) bits for background color.

Link to comment
Share on other sites

OK, the no_trans bit in VIDEO_CONTROL is SET. There are no attribute maps. I'm setting the attribute byte for a given cell to a number of values, all with bit 7 set. There's no change in the character's background colour - just the foreground colour is changing. I'd be happy for ANY change to occur in the background colour before I proceed to start setting up the palette.

Edited by flashjazzcat
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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