The Last Word VBXE Edition

[flashjazzcat]

I'm using the laoo palette exactly as in TEXTMODE.COM on the distribution disk. I don't know if that helps to track down what's going on. Is there any known example of the background colour of a cell being changed independently and some source code for same? Stuck here because I follow instructions and manual exactly but things don't behave as expected. Is this implemented properly in Altirra, for instance? That could be a source of wasted time.

 

...nope - it's not the emulator. Same on real hardware.

 

A little ways back it was suggested that setting bit 7 of the attribute byte makes the background adopt colour 128. This is how it behaves for me, even with no_trans set. I have a grave feeling something doesn't work as it should.

Edited January 19, 2010 by flashjazzcat

[flashjazzcat]

Sorted the attribute issue: it was palette related (whole second half of palette was same colour). And so, onwards...

[flashjazzcat]

First beta copy to play with:

 

The Last Word 4.0 for VBXE Beta 1

 

Full of small bugs, I realize (mostly unwanted garbage on screen). Much optimisation still possible, especially in editor (I wrote a quick kludge to handle text selection).

 

Comments and suggestions welcome.

 

 

 

[tebe]

with Altirra work OK, but not with real hardware, display list is wrong - like $02,$70,$02,$70,$02,$70 - empty rows

[+CharlieChaplin]

Sorted the attribute issue: it was palette related (whole second half of palette was same colour). And so, onwards...

 

 

Well,

assuming you have a PAL Atari, why not use OlivierP (P = PAL palette) then ?!? This palette was presented here at atari-age and *in my eyes* it is much better than Laoo palette and much closer to the colours of my real Atari 800XL... just a thought...

 

Attached all the palettes I am using from time to time (all except two of them are PAL palettes; LarryN and OlivierN are NTSC palettes)... -Andreas Koch.

[phaeron]

with Altirra work OK, but not with real hardware, display list is wrong - like $02,$70,$02,$70,$02,$70 - empty rows

 

Can you post a picture? I'd like to fix the emulator to match the hardware. The XDL looks OK, so I'm not sure what the problem is:

 

Altirra> .vbxe_xdl
01600: 74 09      ; mode off
                 ; map_off
 17              ; repeat      24
 00 00 00 A0 00  ; load_ovl    $00000, $0A0
 03              ; load_chbase $01800
 51 F0           ; ovatt ovwidth=normal, ovpal=1, pfpal=1, pri=$F0
0160B: 21 00      ; mode text
 07              ; repeat      8
0160E: 24 00      ; mode off
 00              ; repeat      1
01611: 21 00      ; mode text
 9F              ; repeat      160
01614: 24 00      ; mode off
 00              ; repeat      1
01617: 21 80      ; mode text
 0F              ; repeat      16
; end

Edited January 20, 2010 by phaeron

[Rybags]

The display looks fine on my machine. Appears to match the XDL phaeron's listed there.

 

Top line has tab-stops, bunch of lines for the document then 2 black bg status lines down the bottom. Tabs + editing area using normal default bg colour.

 

Maybe he's still got Antic DMA going and if the right stuff is <wherever> in RAM, some corruption could crop up?

Edited January 20, 2010 by Rybags

[flashjazzcat]

XDL problem comes as a surprise. I did a last minute test on my 130XE with the finalized build and all was OK. DMA is off, by the way.

 

I ended up using colours 1/129, 2/130 and 3/131 for the display. These are "picked" from the laoo palette and the rest of the custom palette is just null. The selection will doubtless expand over time as more colours are used, and I'll probably allow RGB adjustment for user colour customisation (note that CTRL+K "change colours" at the moment is not a useful feature).

 

One job is to extend the XDL to allow 22 or 24 text lines for the edit window. How high dare I go? Are there any limitations with regard to XDL height when using NTSC? Since memory isn't at a premium now, we might as well enlarge the screen.

 

I've also been talking to Mr Fish about the title screen: it's totally incongruous now, given the lack of dual text modes and the absence of the 3-bit wide character sets. I was considering knocking something together in PhotoShop (possibly in 640 x 200 res) and maybe using a splash of colour, such as a green progress bar or something, with 16 colour graduated shading. We could also have nice anti-aliasing on the text.

[Rybags]

XDL goes 240 scanlines, same as standard Antic screen.

 

Most of us are probably using C= 1084 monitors or similar, so V-height isn't an issue as it's adjustable by the user.

 

But, LCDs can be a different matter. Even though you can have 1:1 pixel mapping with Digital TV, DVD etc. you don't get that with analog display or older computers.

 

PAL shouldn't be an issue since you're talking only 480 of 576 but NTSC it could be a different story. I'd imagine 28 text lines of a possible 30 shouldn't present any issues on an LCD but you never know.

[flashjazzcat]

XDL goes 240 scanlines, same as standard Antic screen.

 

Most of us are probably using C= 1084 monitors or similar, so V-height isn't an issue as it's adjustable by the user.

 

But, LCDs can be a different matter. Even though you can have 1:1 pixel mapping with Digital TV, DVD etc. you don't get that with analog display or older computers.

 

PAL shouldn't be an issue since you're talking only 480 of 576 but NTSC it could be a different story. I'd imagine 28 text lines of a possible 30 shouldn't present any issues on an LCD but you never know.

Good info - thank you. With TFT testing will be key. A 25 line edit window would be nice to aim for, plus one tab line and two status lines. I wouldn't want to condense the text vertically, since I think it would look cramped. It'll be interesting to see such a dense text display on the Atari. It wasn't possible to add more lines in version 3.x purely because of lack of memory.

 

Updated front page with download link here.

[Rybags]

I reckon you could probably condense the Tabs line down a bit (maybe to 5 pixels high) and probably knock the status line down to 6 or 7.

 

Since you're using blank lines between regions anyway, you're essentially making the blank scanlines that the normal Atari character set has redundant, on the Tabs line at least.

 

Getting back 5 or 6 scanlines overall might make it possible to add one extra text line over whatever final "safe" figure you come up with.

[flashjazzcat]

I reckon you could probably condense the Tabs line down a bit (maybe to 5 pixels high) and probably knock the status line down to 6 or 7.

 

Since you're using blank lines between regions anyway, you're essentially making the blank scanlines that the normal Atari character set has redundant, on the Tabs line at least.

 

Getting back 5 or 6 scanlines overall might make it possible to add one extra text line over whatever final "safe" figure you come up with.

Only thing to watch out for is custom fonts which maybe define 8-pixel high arrow chars, etc. (font loading works, BTW, so you should be able to try all Mr Fish's character sets on the 3.1 font disk).

 

The more I look at this, the more it's starting to look like ProText for the 8-bit. That was always my favourite word processor on the ST. It had a nice condensed text mode as well, using the ST's 400 line resolution. It would be nice to maybe implement a menu structure and reorganize the status info at some point, bearing in mind that the current layout was designed to work in both 40 and 80 column modes.

 

Re: loading screen. Wondering whether to use existing ANTIC hi-res RLE encoded mono logo (or an updated version thereof), and blit the decoded bits onto bytes in VBXE 320x200 (thus storing 1 bit per pixel instead of 8 ), then just rendering coloured areas separately to spice the design up a bit.

Edited January 20, 2010 by flashjazzcat

[candle]

fjc, when i was doing "atari logo" animation i found that using inflate/deflate on 8bpp picture with only one colour used compressed better than the other way around

[Rybags]

I reckon the loading screen might look cool with an Attribute Map checkerboard through it, e.g. alternating PF1 luma between a bright and darker colour.

 

Just have a quick VBlank routine that scrolls it around - VBXE is versatile to the point where you could probably knock it out in a couple of hundred bytes of code and data.

[flashjazzcat]

Still thinking about the title screen and that will probably be the last thing to be done. I've started a topic over at atarionline and some suggestions for changes to the editor will hopefully start filtering through shortly.

 

Immediate issues I can think of include:

 

• Changing the default cut and paste shortcuts to windows compatible ones (Draco's suggestion)
• Possibly remapping a couple of CTRL+SHIFT keystrokes which are "stolen" by the MyIDE ROM OS
• Revamping the colour editor
• Possibly allowing reverse paging on the file viewer (thus allowing for large, browsable help screens)
• Redesigning the help screens for 80 column formatting
• Redesigning parts of the interface to maximize use of the 80 column display
• putting a couple of extra lines in the editor
• Making "doc" mode support proper expanding tabs

If anyone comes up with any other recommendations, I'd be pleased to hear about them. Hoping to do more work on the new GUI OS next week.

Edited January 24, 2010 by flashjazzcat

[flashjazzcat]

I've just received a few suggestions from the Polish contingent, and there are some interesting ideas there which may keep me rather busy for a few months. My favourite is the introduction of a menu system. I always wanted to do this in LW 3.x, but I ran out of RAM and it wasn't easy to draw the necessary characters on the screen. However, with VBXE it's a cynch to use the colour attributes to represent reverse video characters, thus releasing the entire upper half of the 256 entry character set for definition as graphics characters that won't be "type-able" from inside the editor. Using this and the colour capabilities, I envisage some rather nice menus and screen elements, reminiscent of the old text-based WIMP systems of the MS-DOS days.

 

These are not trivial undertakings, but with VBXE the Atari should have no problem running a word processor equivalent to Microsoft Word 4 for DOS (I used to use that on a 4MHz PC-AT). Rather frustratingly in once sense - but excitingly in another - the bar has just been raised quite considerably.

Edited January 25, 2010 by flashjazzcat