Jump to content
IGNORED

New GUI for the Atari 8-bit


flashjazzcat

Recommended Posts

Can we call it ACHROMATIC OS? New GUI OS sounds strange.

Achromatic = https://en.wikipedia.org/wiki/Achromatic

 

Achromatic means literally “without color”. It can also refer to:

 

So meaning is perfect.

 

Also A can be for Atari. So can be Atari Chromatic shortage.

 

Also any plans for VBXE version??? As I will have VBXE.

And I want see color icons! Blitter support!

 

When will be cartridge available?

Link to comment
Share on other sites

Not to get too far ahead here.... but this GOS is moving at fast enough speeds that some color imho might eventually be possible... I prefer performance over aesthetics but I am sure it could be demand driven. color might naturally drop out under demand, display list cut down when speed is needed etc... we have sort of seen that done for bbs output speeds and for compression decompressing programs and the like.... it may be possible in the future or not at all but there could be a way in which things get done in due time. As I looked at what has been accomplished so far.... the OS already sort of does handle things or appears to prioritize things to give it the nice feel it's already got going on.

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

FJCs GUI based multitasking operating system really should have a real brand name soon.

Though A8GUI and A8GOS already created a brand here :) (and at youtube etc...)

But I know, it's really hard to find the perfect name, logo etc. for such a project, especially when it's already existing for so many years.

  • Like 1
Link to comment
Share on other sites

All it needs to work in colour is a VBXE driver and colour resources. So it might be unwise to give it a name referencing a lack of colour. ;) A VBXE driver would be faster than the ANTIC driver, since the hardware blitter could be used for most rendering operations (and would replace the software blitter). There are many unaddressed unknowns regarding mouse pointer rendering in an interrupt and font bitmap upscaling, but the possibility is there.

  • Like 1
Link to comment
Share on other sites

I vote for Flash Jazz GOS, or name it after the CAT!

I am not buying a VBXE, and during our discussion I thought it was primarily going to be standard Antic machines and that a VBXE driver would be provided for extra goodies overlaying the base displays but if that has changed can we at least fork it or make it part of an auto-config where the software blitter ANTIC driver stays unless the VBXE is detected and then the software blitter gets yanked and the vbxe hardware drivers load?

Edited by _The Doctor__
Link to comment
Share on other sites

What have I written which suggests the GOS is no longer primarily aimed at stock video hardware? :) The whole idea of having display drivers is that the GUI itself is completely hardware abstracted. If in the future we can be bothered to write a VBXE driver and craft 16 or 256 colour icons and handle resampling them down to various bit depths on the fly, then the facility exists to do so. The coordinate system is signed 16-bit and the GUI control records allow for 8-bits of colour. No forks are required: just a driver. Seriously, I have enough to worry about writing filesystem drivers and all the unwritten GUI components without reaching for a colour display at the moment. ;)

Edited by flashjazzcat
  • Like 4
Link to comment
Share on other sites

What have I written which suggests the GOS is no longer primarily aimed at stock video hardware? :) The whole idea of having display drivers is that the GUI itself is completely hardware abstracted. If in the future we can be bothered to write a VBXE driver and craft 16 or 256 colour icons and handle resampling them down to various bit depths on the fly, then the facility exists to do so. The coordinate system is signed 16-bit and the GUI control records allow for 8-bits of colour. No forks are required: just a driver. Seriously, I have enough to worry about writing filesystem drivers and all the unwritten GUI components without reaching for a colour display at the moment. ;)

 

I love the monochrome look :) I remember way back when I had an ST, the color desktop always looked so cheesy, whereas the hi-rez mono one looked very pro. IMHO color GUIs only look good if you've got the resolution to back it up. Not sure how much the VBXE is reasonably able to pull off when it comes to this, but for me mono just has that serious Desktop Publishing/CAD feel to it that I love.

 

- Michael

Link to comment
Share on other sites

  • 2 months later...

That would be a great use of the vbxe. Maybe just plugging in a driver for it depending on how the driver subsystem is built.

 

That's exactly how it will work. The entire display subsystem is being painstakingly redesigned so that all the hardware-specific parts are part of a module which can be swapped out.

  • Like 3
Link to comment
Share on other sites

 

That's exactly how it will work. The entire display subsystem is being painstakingly redesigned so that all the hardware-specific parts are part of a module which can be swapped out.

 

Sounds like a pretty big nut to crack, but if anyone can do it it is yourself. Thanks for the update!

  • Like 1
Link to comment
Share on other sites

To the detriment of other overdue projects, I'm experimenting with the basics of a new GUI system for the 8-bit. The mouse handler is just about finished (the reason this is taking so long is because the mouse is drawn in bitmapped graphics rather than using a PMG, and this necessitates extra work to ensure it always remains visible even when the underlying app is drawing to the screen), and everything else should keep me busy for the next six months or so.

 

There are two reasons this project interests me:

 

1) I find GUIs intrinsically fascinating, and I always wanted to write one.

2) At the risk of courting huge criticism from those who've already written good GUIs for the 8-bit, I think the world could stand another crack at it, since mostly they've either ended up as unsupported novelties, or elaborate ways of launching text-mode applications.

 

Diamond still seems the most ambitious attempt, and I'm inclined to make the new system partly or wholly compatible with the API described in the Diamond Developers' Kit. This doesn't mean, however, that the new system will look or work the same as Diamond. I think it's a mistake to try an implement a full-blown Windows type environment that the 8-bit can't really handle. GEOS on the Commodore 64, for example, didn't have moveable or sizeable windows, and if it had been running on a 1.7MHz 6502, it would have been quite useable. So we won't necessarily see overlapping windows, scroll bars, and the like with my system. It will be a framework for writing consistent applications which utilize a uniform mouse/menu/dialogue interface.

 

The system will also use proportional fonts, which is a good compromise between readability and maximising screen real-estate. Whether it will end up on a cartridge or not, I don't know. There's a huge amount of work to do and when I get a blank desktop with a working menu bar across the top of it, I'll know I'm getting somewhere.

 

The intention is to release it with a GUI version of The Last Word, plus a simple notepad type program, a handful of accessories, and a decent file manager. Being realistic at this stage in the game, life's too short to write a bunch of big applications on my own, so one of my most difficult tasks is going to be making this system attractive and accessible to the handful of programmers who might be inclined to write their own apps.

 

We can look at what happened to Diamond, which to my knowledge never had a single third-party application written for it. Perhaps my own effort will go the same way. I'd like from the offset, though, to get opinions from interested parties. What kind of GUI would you have liked to have seen twenty years ago on the Atari? What would you like such a system to do now? Do you think it's a waste of time?

 

I'd love to hear your views. icon_smile.gif

 

Thanks for the kind words about Diamond GOS... my view on it is...

 

a) I sure didn't have the money to support the project to the point that would have gotten 3rd party apps developed for it. I kept having whispers in my ear about Atari being interested, but they clearly weren't (as they were focused on the Atari ST). I never had any direct contact with Atari and don't know how much of what I heard was actually true vs hearsay, but in thinking about it now it seems a bit ridiculous to think Atari would have packaged an 8-bit computer with a GOS which would have somewhat competed with its Atari ST line of computers.

 

b) The install base wasn't there and when ICD pulled the plug on it (e.g. I got a phone call telling me I could order one last batch of cartridges and that was it and certainly didn't have the resources to make a huge order... a great lesson in binding your product to one supplier) I don't recall exactly how many had been sold, but I'd guess around 4 to 5 hundred at most... ultimately this is what killed it.

 

c) I didn't have the Comp Sci knowledge to do some of the stuff I would have done with it had I known what I know now. Better memory management is what comes to mind first.

 

- Alan

  • Like 12
Link to comment
Share on other sites

@Alan-

Don't be hard on yourself... we had a lot of that back in the day. You were and still are an inspiration.

Friends and common interests persist through years.

I.C.D. became a mixed bag for a multitude of reasons, delivery of product became a problem as someone wanted a lifestyle and made a mess of a number of things..

Supra and Electrosmith, and a couple others produced most of their stuff anyway.... and there was really no way for you to know it....

Edited by _The Doctor__
Link to comment
Share on other sites

Memory management is challenging on the A8, not least because the RAM banking is a little inflexible. Since 2014 or so, the A8 GOS's general structure is broadly modelled after SymbOS (on the CPC, Amstrad and MSX) and if you look at the SymbOS documentation you'll see that the banking schemes on those Z80 machines lend themselves a little better to a multitasking OS. For example, one bank is the "transfer" area which is basically directly addressable by code in any other bank. Contrast this with the A8, where everything in an extended bank is forced to share the same address space. This presents some mighty challenges, especially when applications want to dynamically allocate memory or drivers need to transfer data to and from buffers belonging to a different process. Difficulties are compounded by the relocatable binary format I decided to adopt (that of the MADS assembler), which - unlike the SDX relocatable file format, which has its own limitations - only allows a single binary segment. The upshot of that is that you can't build a driver with a segment which installs in conventional memory, another which installs in extended memory, and code which gets fixed up in both regions and is able to directly call the other. In reality this may not be such a big deal since the kernel provides calls outside of the banked area whose job it is to copy data between banks, read n bytes from a hardware register into a specified address, etc. But it's still a tremendous PITA, and far more cumbersome than working around a fixed stack location, sharing ZP between processes, and other stuff which has already been solved.

 

For information, the memory manager in the GOS uses a bitmap as an index to 256-byte pages of extended RAM, and there's another version of it which handles conventional memory in small sixteen byte chunks. Both are closely modelled on the allocator in the LNG (Lunix) OS, whose author I emailed some time ago with this exciting news but I didn't hear anything back. It does rather nice best-fit allocation so things don't become too fragmented.

 

It's interesting to see how little of the original blurb quoted above (written a year before the project was undertaken in earnest) still applies now. The thing was originally going to be a graphical UI for DOS applications, then it was a single-tasking desktop metaphor, then it was a multi-tasking shell, and then it became a full multi-tasking graphical OS... with corresponding re-writes along the way. Having a clear plan from the get go would probably have helped, as would not being involved in other stuff (APT, UFLASH, U1MB Alt BIOS, The Last Word), but you live and learn. It's a gargantuan investment of time and effort and the most short-sighted thing I ever did was try to put dates on the road-map. :)

  • Like 14
Link to comment
Share on other sites

Perhaps you could optionally support the 128kB S/XEGS RAMCart . That way you can switch $4000-$7FFF and $8000-$BFFF, effectively bank switching 32kB.

 

Or maybe we need a new RAM upgrade that can switch a full 48kB, including stack and page zero through an Axlon style bank switching location :)

  • Like 1
Link to comment
Share on other sites

Well, the banking limitations are the prime reason the system must be ROM/cart based, since we need large amounts of code which can get direct access to all the banked RAM. The microkernel sits in the Shadow RAM and the GUI is in banked ROM. This gets around some of the problems and at least means the OS can work without hardware mods.

Link to comment
Share on other sites

  • 2 months later...

 

Thanks for the kind words about Diamond GOS... my view on it is...

 

a) I sure didn't have the money to support the project to the point that would have gotten 3rd party apps developed for it. I kept having whispers in my ear about Atari being interested, but they clearly weren't (as they were focused on the Atari ST). I never had any direct contact with Atari and don't know how much of what I heard was actually true vs hearsay, but in thinking about it now it seems a bit ridiculous to think Atari would have packaged an 8-bit computer with a GOS which would have somewhat competed with its Atari ST line of computers.

 

b) The install base wasn't there and when ICD pulled the plug on it (e.g. I got a phone call telling me I could order one last batch of cartridges and that was it and certainly didn't have the resources to make a huge order... a great lesson in binding your product to one supplier) I don't recall exactly how many had been sold, but I'd guess around 4 to 5 hundred at most... ultimately this is what killed it.

 

c) I didn't have the Comp Sci knowledge to do some of the stuff I would have done with it had I known what I know now. Better memory management is what comes to mind first.

 

- Alan

 

Wow Alan ... great to hear your experience with that GOS. Honestly as a kid, I was completely obsessed with Diamond GOS. But alas, with a 15 year old's budget, I never could do anything more than rent it from a local user's group.

 

 

i thought it was a work of art at the time

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

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