New GUI for the Atari 8-bit

[+MrFish]

7 hours ago, atarixle said:

FJCs GUI is indeed impressive, but I highly guess that it wont come any further just because of the limitations the Atari has. The goal of having Multi-Tasking on the 6502 is set too high.

Development progress of the GUI is in no way impeded by the inclusion of multitasking -- the functionality/viability of which has already been quite thoroughly demonstrated.

 

7 hours ago, atarixle said:

It is indeed impressive to see, that coders can do it, but without the help of some hardware, like the 68000 and the x86 has, it is doomed to stuck in demo mode.

SymbOS has already proven a full system like this can be created without the help of a 68000 or x86. The fact the author @Prodatron urged @flashjazzcat, and in fact helped him, to add multitasking, is a testament to his confidence that it can be brought to full fruition with our 6502 @ 1.79Mhz/1.77Mhz.

 

It's been stated time and time again that progress is hindered by lack of available time. I'm not sure why people feel the need to bring up unfounded ideas like this. Do you have some specific evidence of why it couldn't work, or have you seen something that hasn't worked as it should so far?

 

[+David_P]

The main technological limitation is the lack of a flux capacitor and a DeLorean.

 

[Atari8man2004]

Lets not focus on what the 8bit Atari can't do but what it can do.  The Atari computer was developed in the late 70's for gaming education and telecomunications.  Look at what the FujiNet group was able to do inteface that with a Gui and you have online gaming, chat rooms New feeds Weather and much more maybe even an internet radio plug ..   The Home entertaing computer.  

[flashjazzcat]

7 hours ago, atarixle said:

FJCs GUI is indeed impressive, but I highly guess that it wont come any further just because of the limitations the Atari has. The goal of having Multi-Tasking on the 6502 is set too high. It is indeed impressive to see, that coders can do it, but without the help of some hardware, like the 68000 and the x86 has, it is doomed to stuck in demo mode.

We already had this discussion - laboriously and over several years - with the likes of Atari8Warez, whose assertion that the hardware wasn't up to the talk was already comprehensively debunked several times over by the time he got himself banned for harassing me off-site.

 

Multitasking has worked smoothly since 2013 or so, with performance better than anyone expected. The impediments - if I have to list then again for the umpteenth time - are basically lack of time, lack of motivation, and fatigue over the need to constantly defend and justify the system's viability and functionality to people with no real grasp of how it works or why it's perfectly reasonable to run such an OS on an 8-bit machine (if you're happy to code everything in raw assembler, at least).

[danwinslow]

[flashjazzcat]

19 hours ago, woj said:

Sorry for being a killjoy, but why? I mean, if we are talking about the GUI from this topic (or was it the GEOS that we switched to on the way?) it would have to be Jon doing this work, or at least coordinating it, from the looks of it and his comments here he might find time to do it in few years from now, and besides, the actual point I am getting to - I can name at least two other projects I'd love to see him working on, write support for the FATFS SDX driver, or FAT32 driver for SDX to begin with.

 

(Also, don't get me wrong, I think the GUI is great, I am very impressed with it, it would be really nice to see it finished, I am all for that, I am just being less of a dreamer here 😉.)

That doesn't come across as a killjoy comment at all. I already remarked on the open-source multitasking kernels that had been ported to the A8 long before I started the UI, let alone the multitasking kernel, and I've yet to see anyone drape a GUI on top of them, and probably for good reason (it may ultimately be a solution looking for a problem). When it comes to priorities, back in 2014, the clear need for better U1MB/SIDE/Incognito firmware far outweighed the GOS in terms of importance (and remember the primary motivation for rewriting the U1MB firmware was initially to provide the GOS with a means of booting from ROM), and as it happens, doing that eventually contributed to my turning my hobby into my self-employed occupation (I wasn't working at all for much of the time when I was working intensely on the GOS, and when I did get a full-time job in IT support - itself partily because of some firmware I had produced - I recall being too tired after work to do any large-scale coding). And - as mentioned previously - work on the SIDE2 and later the SIDE3 loaders took care of FAT drivers on the A8 (R/W in the case of SIDE3, as recently as two years ago, with long filename support, etc), filesystem drivers being one of the more intimidating obstacles to turning the GOS 'demo' into a full operating system.

 

Shortly after I finished the R/W FAT drivers, we sold my parents' house (both of them having died in 2021/22), bought this place, and I expect to have the place fully fixed up by the end of 2024. Coding priorities include the SIDE3 Loader, Ext U1MB/Incognito Lite/Incognito 3 firmware, etc, etc. Will I start dabbling with the GOS project again? More than likely, since I have ready-written filesystem driver code now which didn't exist ten years ago.

 

Regarding the SDX FAT drivers: I completely appreciate and support developers who wish to 'do it themselves', and I heard some gossip that the R/W version of the SDX FATFS.SYS 'exists somewhere', but who knows. I reached out to Trub about a year ago, nevertheless, offering to help add write support if it wasn't already done, but I received no response whatsoever to that offer. I would write a R/W driver myself, but unfortunately - while the SDX developer documentation is absolutely excellent - the chapter on writing filesystem drivers is still missing, so we're at a bit of an impasse there at the moment.

18 hours ago, Atari8man2004 said:

Not everybody likes the CLI of Sparta dos my wife, kids and grand kids would not use the Atari they have no patience and not every Atari user uses the CLI.  I on the other hand Love Sparta and ran a mutiline BBS for 11 years.    I'm not going to hold my breath for them to fix the issues with GEOS it's all up to FJC and the Users that would like to see the GUI and want to fund him.  I'm retried and can spend money now   Like I said I'm all in with a funding payment system for FJC Gui.       

Someone from the Americas offered me some kind of financial support scheme back in 2013 or so, but I didn't pursue it since it seemed to me at the time like making a pact with the Devil.  Once you accept money (regardless of all the failed Kickstarter projects which exist), you've committed yourself to providing a product of some kind, and that's a considered responsibility, IMO. The amount of time required to complete the GOS - unless invested piecemeal over a couple of years - would be significant enough to affect my day-to-day occupation (whose backlog of work I am still struggling to manage), and if that's neglected for a year while I work full-time on the GOS, I'd risk having no job at all at the end of it.

 

I haven't forgotten the donations I received a decade or more ago in terms of support for the GUI/GOS project, but sending tips to egg someone on to push the project further and formalising a funding scheme in order to ensure a completed project are two entirely different propositions.

17 hours ago, Beeblebrox said:

It would be amazing, but the main consideration here is it would all come down to Jon's day to day commitments, time available and motivation/willingness to put himself through it all.

 

It's a major undertaking, even if the colossal work he spent in the last couple of years on the fat file system/dos and related coding which can be used in the GUI has already been done. Even if a generous amount of money was to come his way via the forum and wider donations, it's unlikely to be enough to allow him to focus on the GUI above his day to day hardware work/income and other coding commitments, videos, etc. 

 

Also, being beholden to the community who has funded him is a real pressure and at times a demotivate I'd imagine. 

 

I think at some stage I am sure he'll find time to do bits on it, but I think it's a case of just seeing what happens over the next couple of years. Maybe we'll see something develop further, maybe not. 

 

If course this is my own opinion and I am sure Jon will chime in at some stage.

Couldn't really have put it better myself.

17 hours ago, mytek said:

I'm just being realistic on whether my wife and kids would ever want to do something productive on an Atari 8-bit computer, irrelevant if it had a GUI or not

 

But that doesn't mean I wouldn't want to see Jon's GUI finished.

It's a valid concern, and definitely something that's in the back of my mind when I wonder whether - for instance - to improve a game loader for which I get paid and which is used by hundreds of SIDE3 owners, or a graphical OS which people would probably tinker with for five minutes (imagine any recent GEOS demo on YouTube, for example), adjusting the font size in the word processor and dragging windows around the screen. And if - as it appears to some - the whole project is just about 'can it be done?', then we already know it can be done, since the GOS 'demo' works, has a ROM file system, and runs multiple processes at the same time on a 128K system, and uses a graphical front-end with proportional fonts.

17 hours ago, danwinslow said:

This horse is thoroughly dead and beaten into the ground so far you'd need a ladder to get back up.

LOL. Reverse psychology sometimes works, I suppose, to inspire people to finish something out of spite or a sense of indignation, but this thread (which I actually have hidden because it's become such a time-drain in its own right; I'm only here because I was quoted) has been such a source of motivation and demotivation in almost equal measure, they pretty much cancel one another out now, and thus become irrelevant.

 

Part of me wishes I had written nothing at all on the forum until the system was complete, but on the other hand, without public discussion, we wouldn't have the cool mouse pointer, nice visuals, efficient window manager, or the multitasking kernel (all of which are - directly or indirectly - a result of community discussion and participation).

Edited April 12 by flashjazzcat

[+mytek]

4 hours ago, flashjazzcat said:

Part of me wishes I had written nothing at all on the forum until the system was complete, but on the other hand, without public discussion, we wouldn't have the cool mouse pointer, nice visuals, efficient window manager, or the multitasking kernel (all of which are - directly or indirectly - a result of community discussion and participation).

I sometimes feel that way if I post something about one of my projects before its conclusion, because it adds sometimes unwanted pressure to get it done. But on the other hand it does feel good to share, and as you pointed out, get inspiration that drives the project forward in an even better way.

[flashjazzcat]

Apologies to @danwinslow (who kindly reached out to me privately). I (grumpily) completely misconstrued his remarks in my prior post (as he pointed out, he was really referring to the thread rather than the project itself or its objectives).

 

[atarixle]

Never ment to be harassing. I love to see the GUI having progress.

 

What I mainly ment was that the limitations in hardware have to be implemented in software (use relocatable code only, instead of an MMU in hardware; ...). Those occupy memory, and main memory is limited. Multitasking might run well but how much memory is left for applications?

You could put it into The Cart or comparable memory-monstrouse products, or reload as much as possible from RAM-Disk or storage on the parallel-port. But still all the active code has to fit into less than 64k main memory.

 

The framework for the Window-Management and GUI widgets is eating up memory too 

... ok this is what you save when the app itself does not need to have this implemented separately.

 

And the last thing is time. You are one of the most genious programmer who writes the official firmware for other products. You said that time is missing. Contrary I also said that once the GUI framework is ready, writing apps itself should be doable relatively quickly.

[Heaven/TQA]

Flash... You don't need to defend yourself in detail why or why not you are doing the Multitasking OS thingy... 

 

At revision 2024 I had a longer chat with Jac! And the CPC multitasking OS closer and played around little bit on the CPC standing on the desk. Nice one like it. But it's always kind of chicken egg issue with those OS?

[flashjazzcat]

12 hours ago, atarixle said:

What I mainly ment was that the limitations in hardware have to be implemented in software (use relocatable code only, instead of an MMU in hardware; ...). Those occupy memory, and main memory is limited. Multitasking might run well but how much memory is left for applications?

Relocatable code occupies no more memory than non-relocatable code once loaded from storage and fixed up in RAM, so the only real issue presented by the lack of an MMU seems to me to be the lack of memory protection (so random writes outside of the application's allocated RAM can be somewhat disruptive).

 

The minimum RAM requirement is 128K, with (on that base configuration) 80KB available for resources and applications (four extended banks plus the main bank). That's ample for a handful of applications, resident resources, etc. In point of fact the system could probably run in 64K, although the limitations (16K for applications and resources) would severely impede usability. Although, since we now have a proliferation of mass storage devices which are as fast as RAM to RAM CPU block moves, it would be fairly trivial to cache an inactive process to disk if RAM was in contention.

12 hours ago, atarixle said:

The framework for the Window-Management and GUI widgets is eating up memory too

That's why the UI is one of the processes which runs entirely in banked ROM, consuming no RAM whatsoever. Applications, meanwhile, can implement a complex UI using minimal code (since they're just calling the OS instead of drawing everything themselves).

12 hours ago, atarixle said:

Contrary I also said that once the GUI framework is ready, writing apps itself should be doable relatively quickly.

Probably so, although all but a few of the most ardent coders will probably balk at the complexity of the window and dialogue descriptions and hope that someone also writes a resource editor to make application development less intimidating.

2 hours ago, Heaven/TQA said:

Flash... You don't need to defend yourself in detail why or why not you are doing the Multitasking OS thingy... 

Appreciated - thanks!

2 hours ago, Heaven/TQA said:

At revision 2024 I had a longer chat with Jac! And the CPC multitasking OS closer and played around little bit on the CPC standing on the desk. Nice one like it. But it's always kind of chicken egg issue with those OS?

You mean SymbOS? I had a cheeky idea the other week while making a video demoing 'Let's Emu' (Spectrum emulator for the 65C816). If we can emulate the Z80 at reasonable speed with Rapidus, would it not be feasible to emulate the CPC (with VBXE taking care of the emulated display)?

Edited April 18 by flashjazzcat

[Heaven/TQA]

7 minutes ago, flashjazzcat said:

Relocatable code occupies no more memory than non-relocatable code once loaded from storage and fixed up in RAM, so the only real issue presented by the lack of an MMU seems to me to be the lack of memory protection (so random writes outside of the application's allocated RAM can be somewhat disruptive).

 

The minimum RAM requirement is 128K, with (on that base configuration) 80KB available for resources and applications (four extended banks plus the main bank). That's ample for a handful of applications, resident resources, etc. In point of fact the system could probably run in 64K, although the limitations (16K for applications and resources) would severely impede usability. Although, since we now have a proliferation of mass storage devices which are as fast as RAM to RAM CPU block moves, it would be fairly trivial to cache an inactive process to disk if RAM was in contention.

That's why the UI is one of the processes which runs entirely in banked ROM, consuming no RAM whatsoever. Applications, meanwhile, can implement a complex UI using minimal code (since they're just calling the OS instead of drawing everything themselves).

Probably so, although all but a few of the most ardent coders will probably balk at the complexity of the window and dialogue descriptions and hope that someone also writes a resource editor to make application development less intimidating.

Appreciated - thanks!

You mean SymbOS? I had a cheeky idea the other week while making a video demoing 'Let's Emu' (Spectrum emulator for the 65C816). If we can emulate the Z80 at reasonable speed with Rapidus, would it not be feasible to emulate the CPC (with VBXE taking care of the emulated display)?

I guess it was SymbOS and the coder explained me the concept of those core routines and the layers on top. jac had some ideas on Atari ports. We talked about that gui window rewriting on layered windows while pac man clone was running in one of those.

 

I also liked the abstract window gui layer as we had 4 Color display and monochrome display of the same app.

Edited April 18 by Heaven/TQA

[flashjazzcat]

1 minute ago, Heaven/TQA said:

I guess it was SymbOS and the coder explained me the concept of those core routines and the layers on top.

Prodatron (the SymbOS author) has been a regular participant in this thread and it was he who convinced me to abandon my mask-based window manager and replace it with a rectangle-based one similar to what he implemented in SymbOS. Indeed, it was he who convinced me to make the thing multi-tasking.

 

[+MrFish]

17 hours ago, atarixle said:

What I mainly ment was that the limitations in hardware have to be implemented in software (use relocatable code only, instead of an MMU in hardware; ...). Those occupy memory, and main memory is limited. Multitasking might run well but how much memory is left for applications?

17 hours ago, atarixle said:

The framework for the Window-Management and GUI widgets is eating up memory too 

Apparently you haven't paid very close attention to what's going on in this ancient video that @flashjazzcat posted on Youtube (and links to on his website's section about the GUI), from back when the last demo was released.

 

If you watch the "RAM (KB) - Used" (down in the lower-right of any "Profiler" he's opened), you'll see that number go far beyond 64KB: he reaches 118KB, and then 121KB after opening the "Jotter" (text) window towards the end. If you look at the number of "Total - Apps" currently open (on the lower-left of any Profiler window), you'll see it reach 9, and then 10 when he opens the Jotter; 7 of those 10 apps are Profilers, totalling about 42KB (~6KB each), all running simultaneous, and having their window contents updated in real time.

 

In fact, he could have as many as 12 apps total open (I think it's the current hard limit for the demo; 2 apps of which are always the Keeper -- desktop/file manager -- and clock); with 10 of those apps being Profilers, it would be 126KB total RAM used, of which active, multitasking Profiler apps would occupy 60KB.

 

 

 

[flashjazzcat]

34 minutes ago, MrFish said:

In fact, he could have as many as 12 apps total open (I think it's the current hard limit for the demo).

MaxTasks = 16 (an arbitrary value, chosen to keep the process table at a reasonable size). The following processes are run at start-up:

 

Clock

Desktop

Idle

File manager

Kernel

System

 

Two of these (clock and file manager) are classed as applications, and the rest system tasks. So it would be possible to run ten profilers.

 

Memory usage is indeed quite high right off the bat, but the kernel immediately counts 48K ($0000-$3FFF and $8000-$FFFF) as used (by ROM, the 8K display buffer, and internal tables), and the system allocates RAM (by 256-byte page) for quite a few large resources before the desktop comes up. Note also that one page (256 bytes) of each 16K extended memory bank is reserved for memory housekeeping.

 

Edited April 18 by flashjazzcat

[+MrFish]

29 minutes ago, flashjazzcat said:

MaxTasks = 16 (an arbitrary value, chosen to keep the process table at a reasonable size). The following processes are run at start-up:

 

Clock

Desktop

Idle

File manager

Kernel

System

 

Two of these (clock and file manager) are classed as applications, and the rest system tasks. So it would be possible to run ten profilers.

Ah, ok, it's tasks that are the limiting factor not apps. I probably knew that 10 years ago. I did remember the limit you set was arbitrary, though, and not because it wasn't possible to go higher.

 

Well, I'm still amazed when I start examining what's going on again. It's quite a feat for the humble 6502.

 

[almightytodd]

Any way this could run on the 400 mini? Even just as a demo?

 

[+MrFish]

1 hour ago, almightytodd said:

Any way this could run on the 400 mini? Even just as a demo?

It could run on a 400 Mini; but I'm not sure if ST Mouse emulation is supported yet or not. If it is (via a DE-9 to USB adapter or something similar) then all should be fine. Just select 130XE as your system for full functionality (800XL/64KB will work, but functionality is limited -- basically, only one Profiler can be opened, but six simultaneous Jotters are possible).

 

[pcrow]

2 hours ago, MrFish said:

It could run on a 400 Mini; but I'm not sure if ST Mouse emulation is supported yet or not. If it is (via a DE-9 to USB adapter or something similar) then all should be fine. Just select 130XE as your system for full functionality (800XL/64KB will work, but functionality is limited -- basically, only one Profiler can be opened, but six simultaneous Jotters are possible).

The 2600+ with "real" joystick ports doesn't handle things that change the inputs to outputs, which is how the keypad controllers work.  But the 400 Mini is USB, so I don't know how you would get the ST Mouse connected and what signals are required.  I know there are several different adapters to plug real Atari controllers into a USB port for use with emulators, and some of them can work with weird modes but require some host support to enable that.

As a side topic, I'm curious as to how a ST mouse is seen on an Atari 8-bit.

[+MrFish]

32 minutes ago, pcrow said:

As a side topic, I'm curious as to how a ST mouse is seen on an Atari 8-bit.

It's just seen through the normal joystick registers as gray code. Any drivers written for it need to therefore be written in machine language in order to keep up with movement, to any practical usage. You can write a routine in BASIC (or even TBXL, etc.) to see how it works, and then move the mouse faster to see how it doesn't work.

 

Edited April 23 by MrFish
Edited to mock Atari BASIC.

[+MrFish]

56 minutes ago, pcrow said:

But the 400 Mini is USB...

Right, so it wouldn't even require a real ST Mouse for emulation; it could just emulate it by plugging in a modern USB PC mouse, as all (or certainly most) emulators can.

 

[+MrFish]

2 hours ago, pcrow said:

As a side topic, I'm curious as to how a ST mouse is seen on an Atari 8-bit.

I just had a quick look at what's happening again...

 

It uses the first two nibbles of the register, giving one nibble to each axis.

 

The x-axis uses the first nibble, the y-axis uses the second nibble.

 

As the mouse is moved on a given axis, the nibble will rotate through the 4 values; not in numerical order, but as follows.

 

00 -> 01 -> 11 -> 10... and then in the opposite order when it's moving in the opposite direction on the same axis.

 

[+MrFish]

Worth mentioning here too, is that a stock ST Mouse can only have it's left button read on the Atari 8-bit computers. There is a fairly simple mod for the ST Mouse that will allow the second button to be read, though.

 

[+Stephen]

2 minutes ago, MrFish said:

Worth mentioning here too, is that a stock ST Mouse can only have it's left button read on the Atari 8-bit computers. There is a fairly simple mod for the ST Mouse that will allow the second button to be read, though.

 

Details on that mod please?  I'd love to have a 2-button mouse solution for some stuff I am working on.  I assume it use a resistor and gets read as a paddle input?

[+CharlieChaplin]

3 minutes ago, Stephen said:

Details on that mod please?  I'd love to have a 2-button mouse solution for some stuff I am working on.  I assume it use a resistor and gets read as a paddle input?

See Mathy's page:

https://www.mathyvannisselroy.nl/stm18bit.txt