New GUI for the Atari 8-bit

[w1k]

any new version?

[flashjazzcat]

Unfortunately not, since for the past sixteen months my A8 time has been almost completely consumed by developing the new U1MB/Incognito firmware, ironically undertaken solely as a means of making the GOS bootable on both devices to begin with. Not to mention testing Rapidus/U1MB, which was a lengthy diversion which eventually outstayed its welcome.

 

In any case: those projects approach completion and I will not require much persuasion to release when a GOS update is ready.

[suspicious_milk]

This is a long thread, sorry if the following questions are obvious and/or have been addressed.

If I wanted to test; I just DL the zip and use uFlash to flash my SIDE2 with the .ROM file? This would replace SDX? Then I could flash the latest SDX back to the SIDE2 whenever done playing/testing?

 

Looks amazing BTW!

[flashjazzcat]

This is a long thread, sorry if the following questions are obvious and/or have been addressed.

If I wanted to test; I just DL the zip and use uFlash to flash my SIDE2 with the .ROM file? This would replace SDX? Then I could flash the latest SDX back to the SIDE2 whenever done playing/testing?

Good question. It's so long since I made the SIDE build that I had to check the sources to answer your question, and indeed it's not obvious where the SIDE ROM should be placed. Turns out it goes in the upper half of the ROM, replacing the SIDE Loader. You need to have the SIDE switch in the SDX position, though, and boot from SDX on the SIDE cart, then flash to the External Cart slot using UFLASH. Then reboot with the SIDE switch flipped up to the loader position.

 

The SDX slot could be used if the ROM was set up that way, but for the moment it's as well it is not, since it would currently be impossible to revert back to SDX (there is no bypass for the GOS boot). Easy to go back to the loader, though: just boot with the switch in the SDX position and flash the XEX loader back to the upper slot.

[suspicious_milk]

Awesome, and thanks for the reply. Can't find my ST mouse ... so I'll have to grab a "new" one or pickup a trackball first.

[Stormbringer]

Any new news?

[flashjazzcat]

When there is, you'll see it here.

[Guest]

Jon

 

is the eventual plan to run xex/exe/com files directly from desktop? or is this unlikely?

ideally, i'd setup a 256mb CF card with my IDE 2.0 if this were the case

[flashjazzcat]

Evicting the kernel and GUI to run legacy stuff isn't high on the priority list, but we'll have to see how things turn out. The trouble with running DOS stuff is that you a) need some kind of compatibility layer for CIO calls, and b) you need to vacate RAM above $2000, turn the cartridge off, and run the stock OS. Since we're not running on top of an existing DOS, this means creating something like SDX's CIO layer. But the key issue is that the file system manager itself is a multi-tasking process, so in order to run the FMS with the multi-tasking disabled (which it would absolutely have to be once you fire up a non-GUI application), an FMS which doesn't rely on multiprocessing would have to be swapped in, or large parts of the FMS called by the multitasking parts would have to be non-multitasking.

 

It's ironic that the first thing people want to do with a multi-tasking graphical OS is use it to launch non-GUI, single-tasking applications, but I guess it's understandable.

[holgibo]

The main question will be: What kind of software will be available for the GUI. To fill the new GUI with life, other programmers will have to write compatible software for it. Just a graphical OS is nice, but without software running in it, it"s not very usefull.

The one-way-ticket with old software is the problem for every GUI on the Atari.

 

I hope, some programmers will create software for your new GUI, flashjazzcat. It"s a very impressive software.

[flashjazzcat]

Many thanks. The point you make is absolutely correct. We will have to see if a richer interface, usable performance and multi-tasking makes any difference. It certainly motivates me, although I've had little time to work on it recently.

[+mytek]

The main question will be: What kind of software will be available for the GUI. To fill the new GUI with life, other programmers will have to write compatible software for it. Just a graphical OS is nice, but without software running in it, it"s not very usefull.

The one-way-ticket with old software is the problem for every GUI on the Atari.

 

I hope, some programmers will create software for your new GUI, flashjazzcat. It"s a very impressive software.

 

I would think that high on the list would be a very versatile text editor that is syntax smart, recognizing ASM, ect. with configurable tab stops and such for each situation that are saved as preferences. And of course it should multi-task, allowing many instances to be open at once and have cut 'n' paste between them. Then a graphics bitmap and character set editor with a magnified and non magnified view would be very useful. So basically a bunch of productivity tools.

 

- Michael

[popmilo]

It's ironic that the first thing people want to do with a multi-tasking graphical OS is use it to launch non-GUI, single-tasking applications, but I guess it's understandable.

Imho forget those Just give as simplest tools or specs so we can write new tools from scratch...

[ebiguy]

A resource editor in WUSDN would be cool to be able to write graphical applications but that's not an easy job !!!

[Bikerbob]

Does this not bring us back to if your using a MOD machine etc.. if I have a U1mb machine.. would not loading the GUI.. being able to access my APT harddrive on my CF card... LOAD a game (space invaders.. whatever) have the GUI moved to upper memory in a saved state.. run the game.. RESET and the GUI returns not be a fantastic use of the interface??

 

The greatest use for a GUI as Linux has demonstrated is the ability to co-ordinate everything that you want to do in one place. Linux is very usable from a CLI.. many hardcores still just use a CLI.. but GUIs in linux have allowed a far greater range of users.

 

In this case.. I am not talking about multi tasking older single operation programs.. but with memory.. could they not be saved into ramdisks etc.. and then back to the GUI to do what you need with file transfers et al and then reload the machine? If you had a 1mb 2mb 4mb machine .. would it not be possible to save 48k windows or 64k windows in a non active save state and then move between them?

 

For example I am in a WP - I want to find the file I need to work on.. its not loaded in a drive at the moment. I can reset - return to the GUI with the WP in a saved state. Do the file transfers, swap disks etc, I need to do, return to the WP and there is the files I can now load and work on.

 

I understand this ignores your Multitasking aspect FLASH, but maybe this is a feature/function that one of these people can develop for your GUI.

 

This is my pie in the sky - as I am a user, not a developer.

 

James

Edited November 2, 2016 by Bikerbob

[Guest]

Imho forget those Just give as simplest tools or specs so we can write new tools from scratch...

why???

 

1] it'd be nice if some old (serious) software - as well as games, worked within a GUI

2] creating new apps/tools to run within the GUI would (surely) by default mean that older stuff would work too? why shouldn't it? same processor, same same, same architecture

 

also, ATOS - as old and tired as it is - does run old software from within its GUI.

Edited November 2, 2016 by Guest

[Prodatron]

why???

 

Because the A8GOS is probably not intended as a starter tool for old programs. And it's more or less impossible to run old programs directly in the GUI.

[Guest]

 

Because the A8GOS is probably not intended as a starter tool for old programs. And it's more or less impossible to run old programs directly in the GUI.

you'll need to explain to stupid me, why new progs would be able to run and old ones won't.

surely they use the same coding, sound, graphics and ram limitations and environment as any new programs designed for the A8 platform?

 

the architecture is the same, after all.

and as Bikerbob said (as a user) it'd be nice to be able to run old/new s'ware thru desktop.

[flashjazzcat]

Allow me to elucidate. ATOS is frequently cited as an example of a GUI capable of running legacy applications, but there are some important differences to consider:

• ATOS is basically a graphical shell which runs on top of SpartaDOS, and SpartaDOS is designed to run conventional A8 software. All ATOS has to do is expunge itself from memory, call DOS's binary load function via the CIO and - hey presto - the legacy application is running. When the application is finished (providing ATOS hooked itself into DOSVEC somehow), the shell runs again and you're back in the desktop.
• At the heart of the new GOS is a multitasking micro-kernel which replaces the Atari OS ROM during normal operation. The file system manager is one of several running processes, dependent like all the others on the scheduler, without which nothing runs. The scheduler runs in the A8's vertical blank interrupt, completely replacing - for the sake of fast interrupt dispatch - the OS VBI handler. For this reason it is imperative that a GOS application makes no direct writes to any hardware registers, and especially the machine NMI vector. Applications should not even execute the SEI opcode, and definitely not LDA #0 / STA NMIEN, since this would bring down the whole system. Of course legacy applications perform direct hardware writes all the time, so we can immediately see one basic reason why multi-tasking and legacy applications cannot co-exist.
• I am not sure if ATOS has an exposed API which GUI applications may access in order to generate graphical UIs consistent with the shell (I suspect not), but the new system does. Every system tool, therefore, unless it is a console application (which themselves must be written subject to constraints similar to those applied to GUI apps), generates its UI solely via messages sent to the UI manager. No jumping into full-screen graphics 0 here when running the file manager!

While no software on an unmodified Atari 8-bit can satisfy the full requirement of preemptive multitasking in the strictest sense (since there is no memory protection, so one rogue application can bring down the whole OS, and errant programs may suspend task-switching), the WIP system gets as close as possible. Native applications are relocatable, preemptively multitasked, and rich GUI controls mean applications are light and their interface consistent. Diamond GOS - without multi-tasking or task-switching of any kind - is the only other A8 GUI I have seen which attempted to completely abstract the UI and the hardware from applications. Unfortunately, performance left something to be desired, and since the GUI ran on top of DOS, it was really a graphical shell.

 

Now, this is not to say that it is technically impossible to launch legacy applications from the GUI, but the kernel/GUI environment is so completely polarised from the DOS/legacy environment that legacy applications require, that the entire GOS would essentially be purged from memory in order to launch the app. And that's OK, but it's not one of the project's primary goals.

 

Prodatron's phrase "a starter tool for old programs" is something I could not have worded better as a means of describing many existing A8 GUIs and shells. And I suppose those which can launch legacy software can do so very well. My own preferred method of launching old programs (whether XEXs or disk images) is via the SIDE XEX Loader I'm working on right now. It has an appealing UI and its entire raison d'etre is launching legacy software. It strives to be as compatible as possible with every game, application and demo ever written.

Edited November 2, 2016 by flashjazzcat

[Prodatron]

All old programs would require the GUI, multitasking kernel etc. to disappear during the time they are running but having the "original" A8 environment enabled.

As mentioned here before it's a complete different environment, and it's not compatible at all for old apps. Yes, the hardware is the same, but not the OS environment.

It shouldn't be a problem to write a launcher for the A8GOS, which can start old stuff. But it would be an one-way-ticket like Holgibo said. It could be something like my emulator snapshot starter for SymbOS (

; http://symbos.org/appinfo.htm?00012).

The way bikerbob described could be interesting as well. But it's probably still not the reason why FJC has started this project for the A8!

 

*EDIT*: FJC was even faster!

Edited November 2, 2016 by Prodatron

[Timothy Kline]

 

For this reason it is imperative that a GOS application makes no direct writes to any hardware registers, and especially the machine NMI vector. Applications should not even execute the SEI opcode, and definitely not LDA #0 / STA NMIEN, since this would bring down the whole system. Of course legacy applications perform direct hardware writes all the time, so we can immediately see one basic reason why multi-tasking and legacy applications cannot co-exist.

 

 

How feasible is it to use a method such as "vectoring" like Microsoft did in order to keep their Windows software compatible with older software? Basically, they incorporated code to "fake out" older software that went looking for folders/locations that no longer exist under the newer operating system.

 

Thus, in the case of a program that attempted the SEI opcode, or the LDA #0 / STA NMIEN instructions, your GUI would fake them out by redirecting them to where they would be prevented from bringing down the whole system.

 

It would be impractical to do this for every program out there that violated Atari's documented vectors and access points, but the GUI would, at a minimum, trap those programs, pop up a box alerting the end-user that the GUI has prevented a catastrophic failure, and let them know that the program is incompatible with the GUI.

 

Or, in some programs, the vectoring would be sufficient to allow an older program to work just fine if they aren't too dependent upon directly accessing addresses/instruction code outside of the documented fair-play vectors issued by Atari.

 

Just late afternoon musings,

Tim

[Bikerbob]

Thanks Flash.. was an excellent breakdown!!

 

I now get how different what you are doing is.. from what I would want.. I am asking for french fries when your trying to give me the whole meal

 

SO Flash, will this XEX SIDE loader work with my incognito? when you are done will I in effect have what I want anyway???

 

James

[flashjazzcat]

The SIDE loader I'm talking about is the one already on you Incognito (assuming you upgraded to the new firmware), but in a somewhat improved form. I've been adding recursive searching and other niceties... basically as much as will fit into 16KB.

[flashjazzcat]

How feasible is it to use a method such as "vectoring" like Microsoft did in order to keep their Windows software compatible with older software? Basically, they incorporated code to "fake out" older software that went looking for folders/locations that no longer exist under the newer operating system.

 

Thus, in the case of a program that attempted the SEI opcode, or the LDA #0 / STA NMIEN instructions, your GUI would fake them out by redirecting them to where they would be prevented from bringing down the whole system.

 

It would be impractical to do this for every program out there that violated Atari's documented vectors and access points, but the GUI would, at a minimum, trap those programs, pop up a box alerting the end-user that the GUI has prevented a catastrophic failure, and let them know that the program is incompatible with the GUI.

 

Or, in some programs, the vectoring would be sufficient to allow an older program to work just fine if they aren't too dependent upon directly accessing addresses/instruction code outside of the documented fair-play vectors issued by Atari.

Vectoring is a perfectly reasonable approach when it comes to faking out applications in the legacy environment. In a way, that's what SpartaDOS X's CIO layer does for legacy applications, allowing them to access the kernel FMS driver via the expected API, despite the fact SDX - internally - doesn't use IOCBs, etc. Faking out IRQ/NMI disabling wouldn't be sufficient to allow co-existence with the scheduler, however, since it would likely break the software (which probably has a perfectly good reason for turning off the interrupts), and in any case the same software will likely set up its own screen display and do other things which will wreck the GUI and scheduler. I get the point about merely filtering out incompatible software, though, although this would probably best be accomplished by simply checking the binary file header for the relocatable GOS application signature. If that's not found (i.e. it's a standard non-relocatable binary file), it's a legacy app and the kernel and GUI should be shut down before running.

 

Whatever kind of compatibility layer then gets switched in would have to create a reasonable facsimile of the DOS 2.5 API and memory map, though. Anything more than that (faking out programs to make them think they're running under SDX, for instance) would probably become a mind-boggling undertaking, and it would then be easier to simply boot SDX and run your programs from the command prompt.

[Timothy Kline]

Thank you for the follow-up, FJC, as well as your time in explaining the inner workings. Like I mentioned, those were just some late afternoon musings I had.

 

In any case, I'm still very much looking forward to seeing where you take this!!

 

--Tim