New GUI for the Atari 8-bit

[+MrFish]

Very interesting! I wonder how this is working. How do you handle upper/lower/middle overhangs on the left and right side of a char? Does it have multiple parameters for that?

 

The overhangs are defined with each individual character -- initially using some font editor. It's up to the font designer to define how each character should be spaced with the previous and next character. It doesn't take too many parameters though -- in fact just two (for horizontal).

[Prodatron]

Just an example:

- an F can be placed closer to a J

- an L can be placed closer to a T

- but an F can't be placed closer to a T

- and an L can't be placed closer to a J

That's why I wonder how many different parameters do you need?

[+MrFish]

It's different when you're talking about italics/script/cursive, because everything has a forward slant. Those examples would not be true for italics/script/cursive. What you're talking about though, is "kerning pairs", which is a whole other ball-game. Kerning pairs can be used for any type of font, and amount to fine-tuning for special cases. We've not attempted that yet, although it's been talked about quite a bit in the past. Kerning pairs require a separate table, and of course would incur a penalty hit on rendering speed as a result. We're happy to have proper italics/script/cursive and mono-spaced font support at the moment.

[+MrFish]

Or I should say, the last two ("can't") examples you gave would not be true for italics/script/cursive fonts. The first two would still hold of course.

Edited January 11, 2016 by MrFish

[Prodatron]

Thanks for the explanation, MrFish, that makes a lot of sense! TBH I never had a deeper look in this before, so sorry for mixing these two ball-games! Now I learned something more!

Edited January 12, 2016 by Prodatron

[+MrFish]

No problem, it's a related issue, because you need the ability to negative offset into the previous character's space for Italics/script/cursive to look right. Mono-space is a different issue, but becomes possible with the same x-offset parameter, just used with positive values. And then of course mono-spacing needs a way of defining the character space (to be equal to all others) regardless of the width of the actual character itself. Both types were taken care of by implementing use of these two parameters.

[+mytek]

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

[bbking67]

I just bought a JerryUSB adapter from ebay and it supports Atari ST and Amiga, so theoretically should work with Atari 8-bit. I'll have to dig out the DiamondGOS cartridge and try it out.

 

The advantage of this unit is that it works with modern USB optical mice. The compatibility with mice is not 100% though... I have some that work and some that don't.

 

http://www.ebay.com/itm/Amiga-and-Atari-ST-USB-mouse-adapter-JERRY-Smooth-working-Easy-to-use-/172050498922?hash=item280f02456a:g:YvIAAOSw34FVDHNo

[flashjazzcat]

Nice. I especially like the look of the JerryUSB adapter.

[+mytek]

I just bought a JerryUSB adapter from ebay and it supports Atari ST and Amiga, so theoretically should work with Atari 8-bit. I'll have to dig out the DiamondGOS cartridge and try it out.

 

The advantage of this unit is that it works with modern USB optical mice. The compatibility with mice is not 100% though... I have some that work and some that don't.

 

http://www.ebay.com/itm/Amiga-and-Atari-ST-USB-mouse-adapter-JERRY-Smooth-working-Easy-to-use-/172050498922?hash=item280f02456a:g:YvIAAOSw34FVDHNo

It does look nice, but with those mounting ears sticking out, I kinda doubt that it would work on a 1200XL or XEGS. You mentioned compatibility problems with some mice, is there a list of ones that are known to work? USB does allow for easy access to wireless mice, so that would be a big plus.

 

You also mentioned using the DiamondGOS to test this out with. Any reason not to test with Jon's GUI?

 

- Michael

Edited January 21, 2016 by mytekcontrols

[Joey Z]

It does look nice, but with those mounting ears sticking out, I kinda doubt that it would work on a 1200XL or XEGS. You mentioned compatibility problems with some mice, is there a list of ones that are known to work? USB does allow for easy access to wireless mice, so that would be a big plus.

 

You also mentioned using the DiamondGOS to test this out with. Any reason not to test with Jon's GUI?

 

- Michael

read the ebay page. It's not a *true* USB adapter. It uses the USB connector, but it uses the PS/2 protocol. It's the same as taking a USB mouse and sticking one of those passive USB to PS/2 adapters on it. It only works with mice made to work with that. Wireless won't work.

 

EDIT: well, you'd have to get a PS/2 compatible wireless mouse I mean. I think most USB wireless mice are not dual PS/2, but there are wireless PS/2 mice, that could be passively adapted to the USB connector, and made to plug into that.

Edited January 21, 2016 by Joey Z

[+mytek]

read the ebay page. It's not a *true* USB adapter. It uses the USB connector, but it uses the PS/2 protocol. It's the same as taking a USB mouse and sticking one of those passive USB to PS/2 adapters on it. It only works with mice made to work with that. Wireless won't work.

 

EDIT: well, you'd have to get a PS/2 compatible wireless mouse I mean. I think most USB wireless mice are not dual PS/2, but there are wireless PS/2 mice, that could be passively adapted to the USB connector, and made to plug into that.

 

Hi Joey glad you spotted that! Although I do see why that was done, since a PS/2 connector would not fit into that housing. Of course the bad part about doing it this way is that you would need to use a 'passive' PS/2 to USB adapter on a 'true' PS/2 mouse, which I seriously doubt even exists. Most adapters going in that direction would be to convert PS/2 signals to 'true' USB signals, which would not work.

 

- Michael

Edited January 21, 2016 by mytekcontrols

[Joey Z]

 

Hi Joey glad you spotted that! Although I do see why that was done, since a PS/2 connector would not fit into that housing. Of course the bad part about doing it this way is that you would need to use a 'passive' PS/2 to USB adapter on a 'true' PS/2 mouse, which I seriously doubt even exists. Most adapters going in that direction would be to convert PS/2 signals to 'true' USB signals, which would not work.

 

- Michael

the adapter to do so, does exist. I have seen them. They're often fairly cheap, and they can be told apart from active protocol converters usually by their size.

[+mytek]

Just to be sure I understand, this GUI does work with an ST mouse? Reason I ask is that I sadly have not had the time to play around with it yet, and I also don't have an ST mouse either. And last but not least, I can't think of any other mouse besides possibly the Amiga's that would work on an Atari 8. So that is why I posted the PS/2 to ST/Amiga mouse board info. Please someone enlighten me if I am incorrect.

 

Thanks,

 

- Michael

[flashjazzcat]

Yes, the GUI works with an ST mouse in port 2. There's also a build for Amiga mice. In addition, there any number of aftermarket mice for both machines which are rather more pleasant in use.

[ballyalley]

I decided to give this GUI a try on my NTSC 130XE. I'm hoping to get a little help, as once the GUI started, I could not click any items on the desktop except the top menu. Here's what I did to get the GUI running:

1. Downloaded the latest version of the GUI from http://atari8.co.uk/gui/
2. Used the file called "GOSMF8MB.rom" that was in the "Amiga Mouse" directory.
3. Used the Maxflash Cartridge Studio to program an Atarimax 8Mb flash cartridge.

When I plugged the 8Mb flashcart into the 130XE the system comes up fine. Using a known-good Amiga mouse in port 2, I can move the cursor around the screen. I can left-click and highlight items from the top menu, but I can't choose anything. Double-clicking (with the left mouse button) any items on the desktop doesn't do anything (it doesn't even highlight them). The right mouse button doesn't seem to have any function at all. What should I be able to accomplish using the GUI and the Amiga mouse?

 

If it makes any difference, I do have other hardware that might be able to run the GUI. For instance, if these two items are compatible, I also have the AtariMax MyIDE II and the sio2sd 1.3 (from Lotharek).

 

Is there any guide on how to use this in-progress GUI?

 

Adam

[flashjazzcat]

I can left-click and highlight items from the top menu, but I can't choose anything.

Only the "Profiler" and "Notepad" items in the system (Atari logo) menu do anything at the moment I'm afraid. However, once you launch the profiler, you can select any of the three tabs, click on the column headings to re-sort the lists, use the scroll-bars, etc. Getting performance to an acceptable level was such a gargantuan task that I didn't want to get bogged down in details (well... basic functionality) until it was apparent that the thing could actually work at a reasonable speed. You can launch multiple instances of the two demo apps (although describing the Notepad as an app at this stage is a little extreme), and watch the CPU graphs and per-process CPU usage in the Profiler. These are actual relocatable GUI binaries which exist as files in the ROM-based file system, but unfortunately I haven't hooked up their desktop icons yet.

 

I've spent much of the last twelve months writing new firmware for the Ultimate 1MB and Incognito, but I was dabbling with the GOS again the other night and will be getting back into it soon.

 

[danwinslow]

It is time, Jon. Put down the drivers and step away. Your real task awaits. And then when you're finished doing what your wife wants, then get to work on the GUI!

[_The Doctor__]

It is time, Jon. Put down the drivers and step away. Your real task awaits. And then when you're finished doing what your wife wants, then get to work on the GUI!

@danwinslow, after all these years you still have a wonderful way of putting things.... why hasn't it rubbed off on me yet?

[ballyalley]

Only the "Profiler" and "Notepad" items in the system (Atari logo) menu do anything at the moment I'm afraid.

Ah-ha! I tried out what you suggested. The "jotter" (notepad) program starts up and displays Bill Gate's letter. Or the beginning of it, at least (there's no way to scroll through the letter, right?). The "Profiler" is also pretty cool! It's really neat to see both windows open at once displaying information in real-time. The fact that the windows can overlap is something I don't recall GEOS on the C64 being able to do. Then again, I haven't used GEOS since the mid-to-late 80s. I'm also really impressed that I can just plug in my Amiga mouse and it just, you know, works.

 

I'm displaying the GUI's desktop screen on a 13" Toshiba monitor using composite from my 130XE. There is articulating (which give red and blue hues). I suppose this is to be expected from an application like this. I may try separate luma/chroma signals to see if the artifacting colors go away. I'm primarily an Atari gameplayer, so I actually prefer using a composite signal over the higher-quality separate signals because I don't lose color in games that use artifacting to get the extra colors.

 

I was dabbling with the GOS again the other night and will be getting back into it soon.

 

This project has been going on a long time. This thread is intimidating. Where does one start reading through it all? Are there are particular posts in this thread that I should read to give me some additional background on the GUI? I did hear the interview on the Antic podcast some months back, and that was really interesting to me. What are your immediate plans for the GUI once you start coding for it again?

[flashjazzcat]

Or the beginning of it, at least (there's no way to scroll through the letter, right?).

Correct. The text control in the "Jotter" window (sorry for calling it "Notepad"... shows how long it is since I looked at it) is extremely bare-bones at the moment.

 

The fact that the windows can overlap is something I don't recall GEOS on the C64 being able to do.

Correct, although I believe later GEOS versions implemented a slightly more sophisticated window manager than that in the original release. However, I think SymbOS is the only other system which implements a rectangle based window manager on an 8-bit micro (basically the same mechanism used by GEM), instead of rebuilding the entire desktop from the bottom up (the way Diamond GOS does it) every time something moves. The A8 GOS window manager was latterly modelled directly on the one in SymbOS.

 

There is articulating (which give red and blue hues).

Yes - the artifcating is not intentional, but is unavoidable using composite.

 

This project has been going on a long time. This thread is intimidating. Where does one start reading through it all? Are there are particular posts in this thread that I should read to give me some additional background on the GUI? I did hear the interview on the Antic podcast some months back, and that was really interesting to me. What are your immediate plans for the GUI once you start coding for it again?

Scan for "SymbOS": that's when things started to really progress (when SymbOS' author took an interest in the project, prompting a complete re-write). The initial concept was a stand-alone graphical front end for applications, then it was envisaged as a single-tasking shell for DOS. A couple of years on, it became a pre-emptively multi-tasking OS. If you want to get a general flavour of how the thing works, I can do no better than recommend digesting the SymbOS documentation.

 

Immediate plans are to further abstract device-dependent display code into a display driver module (making it easier to write a VBXE driver if desired in the future), formalise the device driver model (so we can talk to disk drives), write the (FAT) FMS, and get the terminal going so we can dig into processes and see the file system before all the nice graphical stuff is written.

Edited March 24, 2016 by flashjazzcat

[Faicuai]

Same old, same old visuals here but it definitely feels snappier:

 

 

Bodged the blitter last night to use the new shift tables but a complete rewrite will make that faster too and won't take long. Idle CPU usage when showing one CPU graph dropped from 10 per cent to 9 per cent so I guess that means it got better somehow. Now I can see the wood from the trees, more sophisticated clipping when bringing windows to the front (only drawing what's revealed, etc) will be fairly easy, and I'll add clickable icons and possibly a skeletal console app for the next download. Am mentally focused on file systems at the moment, and if I can abstract the file system on the ROM (which is kind of a modified version of FAT) so that it's accessed using a proper driver API, we'll be getting somewhere (you'll be able to list the ROM disk directory in the console, for example).

 

Low-level GFX routines shouldn't have taken this long to get right, but you live and learn I suppose.

 

Note: button bug (white text) now noticed and fixed.

 

F-Monumental (!)

 

Can't hardly think of any other (better) words to fully describe it.

 

And I am typing / expressing all this from a 12/24T Cores, 48 GB ECC Ram, Quadro-Kepler, 54,000 MIPS workstation (Z-series, HP).

 

KudoSsSsS (!)

Edited March 29, 2016 by Faicuai

[tschak909]

Holy shit!

[Bikerbob]

This is amazing.. when will you need testers? I am up for helping with that!!!

 

James

[flashjazzcat]

Hopefully later this year, once I've cleared the decks of other projects.