New GUI for the Atari 8-bit

[UNIXcoffee928]

I've never seen a titlebar do this before, so I figured that you might like to see it. This is a demo, but the scrolling text might be useful for presenting information, so it's worth checking out:

https://www.youtube.com/watch?v=eU0vflFqEso&feature=youtu.be&t=51s

[Bikerbob]

Something that would likely make a good companion to this GUI...

 

 

I came across these selling for approximately $15 (+$5 shipping) on Ebay (LINK). And here's a LINK to their website products page.

 

This will probably work better then an old ST Mouse.

 

- Michael

 

Did anyone try one of these or the other one on an A8 to see if we can get this to work???

 

Also is there a usable version of the GUI? or a demo that can be tried? Anyway to help?

 

James

[+mytek]

 

Did anyone try one of these or the other one on an A8 to see if we can get this to work???

 

Also is there a usable version of the GUI? or a demo that can be tried? Anyway to help?

 

James

 

Thanks for the reminder , I need to place an order for one of these and give it a test.

 

The thing I noticed when trying to test a PeST mouse adapter I recently purchased with this GUI, is that I only see the application (or demo) available as a ROM image. Is there an earlier version that can boot from an ATR for testing with an ST mouse?

 

- Michael

Edited April 14, 2016 by mytekcontrols

[flashjazzcat]

Thread search for "XEX" revealed this to be (apparently) the last XEX demo posted:

 

http://atariage.com/forums/topic/154520-new-gui-for-the-atari-8-bit/?view=findpost&p=2799246

 

Numerous bugs and lacking rather important stuff like multi-tasking. My signature has a link to the project page.

 

Working on the driver structure at the moment and have managed to further crank up text rendering speed. Also extended the relocating loader, which can now dynamically allocate page zero memory from a pool. If I stick with this scheme, it would banish fixed page zero references from application binaries, meaning the allocation and caching/swapping mechanism could be changed without the application having to be rewritten. Downside is the fixup tables are bigger and loading is a bit slower, but it's nice to have a few different solutions to throw at things.

 

Also changed the list control so the application gets notification when the user clicked in heading to resort on columns. This allows the profiler to restart its sleep timer on the last user action instead of sometimes automatically redrawing the list immediately after the user had already triggered a redraw, Hard to see much here but every time I click in the list column header the profiler redraws the list then puts itself to sleep again for another three seconds or so or until it receives another message from the UI.

 

 

List heading no longer redraws all the time either, so it looks a little smoother. At least the core UI stuff is nearing the stage where it needs no further rewrites or improvements. There's a threshold text rendering speed which I felt needed to be attained here and I think we're finally there. The list redraw you see in the video isn't just rendering: background is erased, numbers are ascii converted on the fly and proportionally column aligned, then everything is clipped and sent to the screen.

[Prodatron]

Great to see and good news, that you are back on the A8GOS after this long time!!

[Stormbringer]

Great to see and good news, that you are back on the A8GOS after this long time!!

 

 

Yeah... what he said!

[flashjazzcat]

Great to see and good news, that you are back on the A8GOS after this long time!!

 

Nice to be back on it. Sometimes a long break (a year in this case, aside from a week or so dabbling with optimisation last August) owing to diversions and other projects can be a good thing, since one comes back to the thing with fresh eyes. Having heavily optimised the rendering code (to the point at which we have probably hit the wall: late hours spent weeding out superfluous "CLC" and "SEC" instructions just to shave a couple of extra cycles off the bottlenecks), I'm now happy we've reached the magic speed threshold which will allow text editors and the like to work smoothly. Some simple changes broke things completely at first but were worth doing, such as changing right/bottom edge rectangle coordinates from X+WIDTH-1 and Y+HEIGHT-1 to simply X+WIDTH and Y+HEIGHT. This places the coordinate on the outside of the rectangle, but required only a small change to the masking lookups and yet enabled the removal of awkward "add, less 1" calculations all over the place. Rectangle merging instantly becomes easier, too, since we need just check for - say - the right edge of rectangle A being the same as the X coordinate of rectangle B instead of first nudging one or the other along by one.

 

So, with all that done, I'm now ripping all the device-dependent code out of the ROM banks and into relocatable driver modules, enabling the core library to be completely device independent. This includes mouse, keyboard, and - most significantly - the display driver, much of which had to run in RAM anyway owing to self-modifying sections. But formally moving everything into a driver module means that you could, for instance, write a VBXE driver and have the GUI run in 256 colour mode or interlaced 640/400. Not something I intend to worry about any time soon, but it's perfectly doable. The display driver also handles mouse pointer rendering, dynamic display list, etc.

 

Of course I'm paying a dear price for doing (IIRC) three complete design iterations on this thing: I spent a couple of hours just weeding out disused equates dating back to the old single-tasking GUI with the RLE mask based window manager. The amount of code is enormous already, but splitting things up into modules is making things more manageable. The display driver work will segue into work on other drivers and it'll be a big milestone to get some simple interaction with a block storage device. I'm also tackling - now rather than later - blitter based control scrolling through rectangle lists (as we discussed some time ago), which will allow console windows and the like to scroll away when partly obscured by other windows.

 

Fortunately all this under-the-hood stuff is pretty absorbing in itself, which is as well since it's time-consuming. I had to implement a memory allocator for main memory (the existing one being focused on banked RAM) so that RAM can be dynamically allocated for those drivers and interrupt handlers which need to load and relocate below $4000. Since the assembler won't allow multiple segments in its proprietary relocation format, drivers in banked RAM which need direct access to the underlying application or process (for example, a block IO driver) will need to allocate a few bytes of low RAM and stash some code in there which banks out the driver, transfers a raw sector to the calling process's buffer, then banks in the driver again. Lots of fun.

Edited April 24, 2016 by flashjazzcat

[+mytek]

Mini Review: KMTech Design MKIII PS/2 to Amiga/Atari Mouse Adapter

By: Michael St. Pierre

 

I ordered mine from Ebay and it took 8 days to arrive in the USA from the UK.

 

What you get for $20 is a kit which consists of a...

1. PCB
2. PS/2 connector
3. D-Sub 9 connector
4. 18 pin IC socket
5. 0.1uf capacitor
6. Jumper header with two jumper blocks
7. Programmed PIC chip (microcontroller)

It took maybe 5 minutes to assemble and solder everything. Then just set the jumper blocks for Atari ST mode and plug it into your A8 joystick port (use port #2 for use with the GUI).

 

How well does it work?

 

I loaded up that last FJC GUI demo that can be run strictly from a disk (LINK), and it worked fantastic right from the get go! It exhibited fine granularity, and smooth acceleration. Tried it with two different optical mice (HP & Logitech), and it worked great with both of them. On the plus side it has no problems with hot swapping mice when powered up, and instantly reinitializes each and every time I did so. I would highly recommend the KMtech MKIII for use with FJC's GUI. And although it surprised me, this worked even better than the PeST PS/2 to ST Mouse Adapter for this application.

 

- Michael

 

Order details below

Something that would likely make a good companion to this GUI...

 

 

I came across these selling for approximately $15 (+$5 shipping) on Ebay (LINK). And here's a LINK to their website products page.

 

This will probably work better then an old ST Mouse.

 

- Michael

Edited April 25, 2016 by mytekcontrols

[Bikerbob]

Thankyou mytech.. I think things like this are important for the GUI.. if we can get people to contribute modules to the gui once flash gets the under the hood stuff finalized then we could have various developers do their own drivers etc. and maybe others can help with the atari hardware etc.. so that we can take some of the load off flashjazzcat.

 

I assume this will not work with a wireless mouse? BT drivers are needed?

 

But I can use my Trackman wheel

 

James

Edited April 25, 2016 by Bikerbob

[+mytek]

Thankyou mytech.. I think things like this are important for the GUI.. if we can get people to contribute modules to the gui once flash gets the under the hood stuff finalized then we could have various developers do their own drivers etc. and maybe others can help with the atari hardware etc.. so that we can take some of the load off flashjazzcat.

 

I assume this will not work with a wireless mouse? BT drivers are needed?

 

But I can use my Trackman wheel

 

James

 

No wireless, because even if a USB mouse works (PS/2 compatible type), it'll not be a BT dongle version. Not sure about a PS/2 wireless mouse, may or may not work as I've experienced in my TK-II mouse trials. But it definitely works well for a couple of optical mice I have (just tested with a 3rd one I found and it works as good as the others). So when the GUI hits prime time, at least we'll have something better to drive it with instead of the clunky old ST mouse (sorry if this offends any of the purists out there, but it truly is clunky in my humble opinion).

 

- Michael

[flashjazzcat]

There are a few aftermarket ST/Amiga replacement mice which are vastly superior to the Atari devices and require no interface at all. I developed the driver using these mice and they're quite usable, although it's pot luck getting hold of them (I hunted most of mine down on ebay, although the one I'm using now I bought at an electronics shop in 1991!). I'd like to try one of these PS/2 adapters eventually, though: maybe I'll find them superior. Certainly broadens the range of suitable mice. I have an ST trackball here which also works with the existing mouse driver. I definitely wasn't impressed by the responsiveness of Atari's ST mouse, and they don't age so well.

[flashjazzcat]

Random question: is there much advantage either way as far as set pixels being black or white in hi-res mode? Currently, the playfield is white and set bits are black, but I vaguely recall some talk of using the playfield as a the foreground colour (i.e. using reverse video spaces as the background and printing everything in reverse video with the colour registers swapped) making the uprights of characters "fatter" on stock hardware. Now that the video driver is isolated, it'll be somewhat easier to change this.

[danwinslow]

I am not aware of any. I would think that going along with the video hardware's idea of what 'set' means would be best/simplest.

[Joey Z]

Random question: is there much advantage either way as far as set pixels being black or white in hi-res mode? Currently, the playfield is white and set bits are black, but I vaguely recall some talk of using the playfield as a the foreground colour (i.e. using reverse video spaces as the background and printing everything in reverse video with the colour registers swapped) making the uprights of characters "fatter" on stock hardware. Now that the video driver is isolated, it'll be somewhat easier to change this.

Doesn't matter to me, I'll be using VBXE Even if I have to write the driver. Just please, if you haven't already, separate the blitter into a module too

[flashjazzcat]

Doesn't matter to me, I'll be using VBXE Even if I have to write the driver. Just please, if you haven't already, separate the blitter into a module too

I'll have to do some experiments sometime. Console will be white on black, GUI windows black on white, so which is playfield? It feels odd filling an area with 1s to turn it black.

 

Anyway: blitter is part of the video driver module, so no worries there.

 

Just puzzled over some screen corruption in a list box while dragging the scroll bar handle. List was being blitted up and down and after a couple of seconds would become corrupted at either end. Turns out the application was updating the list so the blitted bitmap became invalid. Joys of multitasking. I'll put a lock on listboxes so the application can't change them during an interactive scrolling session. At least during 'interactive mode' the desktop manager now gives up the CPU so other things get processor time while stuff's being dragged (this didn't happen before, hence the application couldn't change list data at inopportune moments).

Edited April 28, 2016 by flashjazzcat

[Joey Z]

I'll have to do some experiments sometime. Console will be white on black, GUI windows black on white, so which is playfield? It feels odd filling an area with 1s to turn it black.

nah, perfectly normal....

... if it were a printer

just picture it as putting down black ink instead

[Bikerbob]

Ahhh I need my U1mb so I can run the gemo of the gui I want!!! I cannot get the xex to run on a 64mb 800xl.. bummer.

 

I have my KTM mouse adapter, interesting thing I found out.. it will work on the 8-bit.. with the gui.. as was discussed above.. but I cannot get it to work with a TOS 1.0 STFM.. It will work with TOS 1.04.. I was not aware that the mouse driver was affected by TOS.

 

Flashjazzcat, can you verify that the driver used in the gui comes from a later TOS code?

 

James

[flashjazzcat]

The mouse driver in the GUI has nothing to do with TOS or any ST drivers. No idea why TOS 1.0 has issues with the KTM adapter.

[Bikerbob]

OK, so to firm this up.. what is the minimum memory version of the current progress of the GOS?

I did get the KTM adaptor to work,, a little cleaning changing of connectors etc.. all of this stuff I am putting back to use after being in someone elses storage for a long time

 

James

[flashjazzcat]

Apps, data and some drivers all load into the banking window, so while you might just about get a desktop running in 64KB (and even that's uncertain), to do anything useful you'll need at least 128KB.

[Bikerbob]

Thats fine Jazz.. sounds awesome.. keep it up.. I just wanted to check if I could play before my U1mb upgrade.. or I have to wait..

 

James

Edited May 29, 2016 by Bikerbob

[+mytek]

Is it possible to get a step-by-step description of how to install the GUI with the SIDE2/U1MB setup. And what specifically is the difference between the two different sizes of SDX, besides the smaller one being required for the GUI. So in other words what is sacrificed when using the smaller version?

 

Thanks a bunch

 

- Michael

[flashjazzcat]

Is it possible to get a step-by-step description of how to install the GUI with the SIDE2/U1MB setup. And what specifically is the difference between the two different sizes of SDX, besides the smaller one being required for the GUI. So in other words what is sacrificed when using the smaller version?

I'll try to cook something up. I seem to be fiddling with a dozen different little side projects at the moment. As far as shrinking SDX is concerned: I just strip out the MAN files (online help). These are just as easily stored on a fast HDD if you need them, but using the SDX Imager you could delete 64KB of whatever you don't need.

[+mytek]

I'll try to cook something up. I seem to be fiddling with a dozen different little side projects at the moment. As far as shrinking SDX is concerned: I just strip out the MAN files (online help). These are just as easily stored on a fast HDD if you need them, but using the SDX Imager you could delete 64KB of whatever you don't need.

 

No rush. But when I get more into the TK-III project I'll want to use this as the Gold Standard to test my mouse code against However that is still a ways down the road.

 

- Michael

[flashjazzcat]

Still need to write that guide...

 

Anyway, just took this shaky video of the GOS running under Rapidus at 20MHz since I realized it's one thing I haven't even done since I got Rapidus installed:

 

 

Just moving the graphics driver into RAM has made all the difference to performance under acceleration, since all the code on the cart ROM is throttled. Aside from the snappier redraws and some kernel operations (such as memory allocation) taking less time, there's no real "look and feel" difference between this and the same version running at 1.7MHz. Apart from a glitch in the profiler (keen eyes will notice crap in the App list) which also affects 6502C mode (I guess I introduced the bug when testing MADS' "empty block" segment generation), everything works perfectly.

Edited June 24, 2016 by flashjazzcat