As stephanie said, the C256 should be like a successor of the C128. So in my opinion it should boot into 2 possible states.
The first one (I call it TUI Text user interface) should go directly into Basic 10 (the basic like the one of the never released C65) with some 'additional' commands for disk management in so called 'direct mode'. Catalog/Directory already exists for listing contents of diskettes. I'd like to see additional seqfile reader (similar more on DOS/unix), a simple copy command (copy 8:file to 9:file) and of course a simple delete command (del 8:file).
The second state would be GUI (Graphical User Interface). This one should (in my opinion) look like a modernised GEOS.
This PhoenixGEOS should only use 16 colors and a max. resolution of 800x600. I opt for 16 colors once for speed and second because it should be (modern) retro ;) In both modes I see no real need for multitasking. Only in GEOS-Mode I can see use for Task-Switching. Also it would be nice if PhoenixGEOS could import datafiles from C64/128 GEOS (geoWrite, geoPaint, geoCalc etc.)
But that is realy music for much much later.
Why GEOS and not Workbench or GS-OS? Well it is successor of C64/128-line, and not successor of Amiga/AppleIIGS. Simple, eh?
A few years ago I read a good book called 'Sketching user experiences' by Bill Buxton. The two big impressions it left me with are to not first delve into the mechanics of how a user interface works, first worry about actually interfacing with the user. How the interface is implemented comes later.The second impression was to not be married to one (firm) idea, come up with a lot of semi-vague ideas to give yourself and others a chance to expand upon them. Years before reading this I had designed an semi-automated test fixture for a alarm system keypad. I used the PSOC-1 as I had recently got a dev kit for it (yes, 20 or so years ago when they first came out). Anyhow I had a mechanical mock up done and enough code written for a proof of concept. My boss decided to let the head of test/repair do the code (which irked me) and he came up with the idea to ditch the PSOC and use a new PCB we were getting ready to release, which was really an Ethernet interface for an alarm panel, but it had a lot of I/O, was easier to develop for as we already had the tools. I was against this at first as it was not my idea, but it turned out to be a very good idea in the end. I had just been too married to my initial idea to see it at first.
Any how, back on point, perhaps the first thing to do is think about how the user would interact with a GUI, what sorts of tasks would they carry out, any sort of dragging and dropping, etc. Don't worry about how to make it work at first. Look at other GUIs form back at that period, like GEOS and 'Arthur' (I'll have to do dome research on that one as I have not seen it before), etc. Do some sketches with paper and pencil to get a feel for what it would look like and how a user would interact with it, etc.
Maybe you will think that I am stubborn ( the french side of the pond, 😆) but I keep thinking that a Graphical User Interface has not to deal with any kind of process (programs) management. For example, X11/Motif does not manage the processes; Unix does. So does Mach/Darwin in MacOS, etc... Ok I admit that I am influenced by Unix/X11, lol.
Anyway, obviously there are two subjects emerging here: GUI and Kernel/OS.
But I agree that C256 could benefit from a kernel, or a (light) OS able to do that, and on which programs using a GUI could run.
I have an simple idea of an Application Framework, providing basic features to switch between applications by loading them on-demand: for example there could be a «main » app A(let's say it's the Desktop) used to launched an other app B, and when user has done with B the application framework used to write A and B allows to reload A. With config files and backup files it could look like a mechanism to save/load the application's context. And to stay more in the late 80's 8 bits computer, it keeps the one-app-in-memory-at-one-moment paradigm of the C256 while giving impression to have a "multitask" os (I guess it’s what Geos did).
Just sort of saying hello and putting some random thoughts out there...
On my side of the pond (the UK) one GUI in the mid/late 80's was "Arthur" which ran on the ARM - This was the fore-runner to RISCOS. The early versions were written in BBC Basic. (And was developed on a BBC Micro with ARM 2nd processor). It was a single-user co-operative multi-tasking OS. One program could stall the lot, but if it co-operated by calling back into the OS at regular intervals then everything all ran smoothly. I wrote a few programs under that early OS and it wasn't too bad.
RISCOS lives on today with a dedicated band of enthusiasts although if you've never seen it, it may well look quite alien when you compare to Unix/X-Windows, MS Win, etc.
What would I suggest here? Well, the '816 had a GUI back then too - in the form of the Apple //gs and GS/OS, however I've no real experience of that. It's graphics were either 640x200 (4 colours) or 320x200 (16 colours).
The 65c816 has a built-in block-move instruction although it takes 7 cycles per byte - I'd like to think the DMA engine can save a cycle or 2 there, but to block-clear a 640x480 display needs to move 307200 bytes which will take 153mS using the block-move instruction. Phew! (That's also important for scrolling too unless the video generator does screen-start offsets)
Anyway, who knows for now - what I'd like is a nice fast software development platform - I'd want to develop directly on the system and not resort to cross compiling if possible, but that means a lot of tools to develop or port, so in that respect, do I need a GUI? Probably not - at least not in the early days.
And am I the only one thinking SNES/Famicom (simlar CPU) rather than C64?
I think it would be nice to see if Gregory (@c64os.com) would be interested to join is effort on this project. I have been following is work and I think he could be helpful on building a new GUI. I'll send him an invite.
I was never really impressed with GEOS . If this is implemented , I think it should be one of the last things. A disk operating system and some basic Kernel should be first.
Apologies for my part in hijacking the case design thread. Threadjacking is a serious problem that afflicts countless forums every year. We should all do our part in stamping it out.
Meh, who am I fooling? Threadjacking ain't ever gonna go away. lol
A lot of early "GUIs" in MS-DOS programs were actually text mode simulations of a GUI. Tandy's DeskMate immediately comes to mind. I suspect such a system would be more easily achievable than a graphic mode GUI on a 1987-style computer.
Phil is correct in saying "window" doesn't necessarily imply the overlapping, decorated windows that are common in GUIs today. Perhaps a better word for a rectangular output area would be "viewport," as it avoids the connotation of WIMP-style windows.
I find the idea of using ANSI graphics vs. 2D drawing kits particularly appropriate for a computer of that era. Games and other programs that require graphics mode could run full screen, which is how people still play games nowadays anyhow.
After 30 years of using WIMP GUIs, frankly I have to say the thrill is gone. If you're hung up on them, use a Mac, Windows, or Linux system. We have a unique opportunity to start fresh with a completely new paradigm here. I never associated GUIs with 80s home computers anyway. The only DOS GUI I ever used (other than Windows 3.1) was GEM. I thought GEM Paint's ability to fill an area with a user-created bitmap was pretty cool, but GEM was just another GUI shell other than that. I haven't installed a GUI on my Raspberry Pi at all. I find I can get more done with bash.
What I advocate is a simple context switcher that will allow the user to switch between several full-screen programs. The interface could be simply a screen containing square tiles or icons that represent loaded files and programs. Maybe have a few global menus for file system and clipboard operations and system settings. Even a text mode menu would suffice for the whole interface, really.
I would take opportunity of this forum thread to share some ideas about a GUI.
First, I am not an expert, just a software engineer, but in the past I have made several attempts to write GUI toolkits for fun (in GFA Basic on AtariST, in Turbo Pascl for DOS) and for more serious work (a X11-based toolkit for project at university, and a Windows MFC-based toolkit for a company during internship)
As GUI I mean... GUI... Graphic User Interface. A graphic environment, IMHO, has nothing to do with multitasking, as mentioned in an other post. Managing the memory, loading the programs, dispatching the CPU time among them or just switching from one app to an other is the job of an OS, or maybe of the Kernel, not GUI's job.
Maybe the Kernel could be enhanced, or someone could write an app, to be able to load several programs in memory and give possibility to switch, but in the C256 with its processor it won't be multitasking. At best maybe one could see that as in-memory resident programs (I think there was something like that on MS/DOS). Well I'm not a kernel expert, I let that to the professionals :-))
So, let's assume that C256 is mono-tasking : one app at one moment.
A first question is: does it make sens to have multi overlapping windows (I mean decorated, movable windows)? I do not know, there are pros and cons. A good stacking window management could be enough. An application dealing with multi document could benefit from a kind of tabpane instead of cluttering the screen (800x600) with lots of windows. After all, on tablet (I know only iOS), even if the OS is true multitasking we only deal with one app on the screen, or with splitted screen.
But, who can do more can do less (sorry for the translation from french); let's assume it's about to manage several overlapping windows.
Then what does it need to have a GUI ? I do not invent anything here, just mentioning what already exists (and existed in 1987) and coming from my past experience, I would say :
- A 2D graphic library, dealing with low level graphic features: init graphic mode, dealing with palette, providing 2D graphic primitives (lines, rect, circle, fonts, text), clipping (if possible), screen buffering features if available, etc... No doubt that all that will be more that feasible on the C256.
- A windowing system. By "window" I mean rectangular areas displayed on the screen, not (only) decorated windows (even if they are windows... lol). Managing a window hierarchy and window refresh mechanism.
- A mouse and keyboard event management.
- A GUI toolkit providing elements like buttons, radio buttons, checkboxes, scrollbar, etc, etc... All those widgets are windows able to receive mouse and/or keyboard events. And of course those widgets are decorated to provide a look-and-feel. There's several option to decorate them: all vector based drawings, bitmap decoration, mixing both...
- A window manager to... manage windows at high level and to decorate them. Maybe this one is optional.
About the look and feel, well... I know one could mimic GUI existing in 1987: GEM, MacOS, AppleIIgs OS, Amiga (sorry but... eew!!), Geos... But when writing software, even in 1987, we are not limited (well, not too much)... Imagine a 1987 machine running a scifi UI for its time. What!? It already almost existed??... have I heard NeXTStep? LOL
Seriously, I think all that would need structured programming.
A 2D graphic library could use lot of assembly to implement fast drawing algorithms and to access the graphic processor features, but an interface for a higher level language should be provided.
That's why I think C is the best candidate (not mentioning that it was already here in 1987, lol).
I have started to redo such programming, after years of Java, javascript (eew!!! beurrk!!) and devops... I'm trying to write a POC (proof of concept) in C for C128, with cc65 cross compiler and Vice.
CC65 provides a tiny graphic library, and is quite ANSI compatible. Then I guess it should not be too difficult to port that for C256 ( I even think that the code could be ok for its processor because it's a compiler for 6502. (?) ) with dedicated compiler for its processor.
If I have enough time, and can achieve something interesting I will let you know here.
In terms of hardware, my intentions are to provide a specific Graphic Mode for a potential GUI mode. Considering that the CPU is fairly slow, having a large resolution bitmap is quite difficult to manage unless there are 2D hardware features that allows to move the bitmap around without too much overhead. So, I believe that with a good DMA engine and the help of the 32 available sprites and probably with the double buffering technique, I think it could be achieved with a CPU @ 14Mhz.Since every pixels in the system is 1 Byte only then, the management becomes a lot easier and bandwidth can can be contained somehow.
Anyway, a lot of possibilities will be available to a mavericky, valiant programmer with a lot of time on his hand and a desire to be the first to bring his own vision of that could have been a great GUI in the late 80s time period! Any takers?
As stephanie said, the C256 should be like a successor of the C128. So in my opinion it should boot into 2 possible states.
The first one (I call it TUI Text user interface) should go directly into Basic 10 (the basic like the one of the never released C65) with some 'additional' commands for disk management in so called 'direct mode'. Catalog/Directory already exists for listing contents of diskettes. I'd like to see additional seqfile reader (similar more on DOS/unix), a simple copy command (copy 8:file to 9:file) and of course a simple delete command (del 8:file).
The second state would be GUI (Graphical User Interface). This one should (in my opinion) look like a modernised GEOS.
This PhoenixGEOS should only use 16 colors and a max. resolution of 800x600. I opt for 16 colors once for speed and second because it should be (modern) retro ;) In both modes I see no real need for multitasking. Only in GEOS-Mode I can see use for Task-Switching. Also it would be nice if PhoenixGEOS could import datafiles from C64/128 GEOS (geoWrite, geoPaint, geoCalc etc.)
But that is realy music for much much later.
Why GEOS and not Workbench or GS-OS? Well it is successor of C64/128-line, and not successor of Amiga/AppleIIGS. Simple, eh?
Anyway: Good work Stephanie
Best regards.
Joseph
A few years ago I read a good book called 'Sketching user experiences' by Bill Buxton. The two big impressions it left me with are to not first delve into the mechanics of how a user interface works, first worry about actually interfacing with the user. How the interface is implemented comes later. The second impression was to not be married to one (firm) idea, come up with a lot of semi-vague ideas to give yourself and others a chance to expand upon them. Years before reading this I had designed an semi-automated test fixture for a alarm system keypad. I used the PSOC-1 as I had recently got a dev kit for it (yes, 20 or so years ago when they first came out). Anyhow I had a mechanical mock up done and enough code written for a proof of concept. My boss decided to let the head of test/repair do the code (which irked me) and he came up with the idea to ditch the PSOC and use a new PCB we were getting ready to release, which was really an Ethernet interface for an alarm panel, but it had a lot of I/O, was easier to develop for as we already had the tools. I was against this at first as it was not my idea, but it turned out to be a very good idea in the end. I had just been too married to my initial idea to see it at first.
Any how, back on point, perhaps the first thing to do is think about how the user would interact with a GUI, what sorts of tasks would they carry out, any sort of dragging and dropping, etc. Don't worry about how to make it work at first. Look at other GUIs form back at that period, like GEOS and 'Arthur' (I'll have to do dome research on that one as I have not seen it before), etc. Do some sketches with paper and pencil to get a feel for what it would look like and how a user would interact with it, etc.
Hi all,
Maybe you will think that I am stubborn ( the french side of the pond, 😆) but I keep thinking that a Graphical User Interface has not to deal with any kind of process (programs) management. For example, X11/Motif does not manage the processes; Unix does. So does Mach/Darwin in MacOS, etc... Ok I admit that I am influenced by Unix/X11, lol.
Anyway, obviously there are two subjects emerging here: GUI and Kernel/OS.
But I agree that C256 could benefit from a kernel, or a (light) OS able to do that, and on which programs using a GUI could run.
I have an simple idea of an Application Framework, providing basic features to switch between applications by loading them on-demand: for example there could be a «main » app A(let's say it's the Desktop) used to launched an other app B, and when user has done with B the application framework used to write A and B allows to reload A. With config files and backup files it could look like a mechanism to save/load the application's context. And to stay more in the late 80's 8 bits computer, it keeps the one-app-in-memory-at-one-moment paradigm of the C256 while giving impression to have a "multitask" os (I guess it’s what Geos did).
Well maybe it worth an other forum topic.
Just sort of saying hello and putting some random thoughts out there...
On my side of the pond (the UK) one GUI in the mid/late 80's was "Arthur" which ran on the ARM - This was the fore-runner to RISCOS. The early versions were written in BBC Basic. (And was developed on a BBC Micro with ARM 2nd processor). It was a single-user co-operative multi-tasking OS. One program could stall the lot, but if it co-operated by calling back into the OS at regular intervals then everything all ran smoothly. I wrote a few programs under that early OS and it wasn't too bad.
RISCOS lives on today with a dedicated band of enthusiasts although if you've never seen it, it may well look quite alien when you compare to Unix/X-Windows, MS Win, etc.
What would I suggest here? Well, the '816 had a GUI back then too - in the form of the Apple //gs and GS/OS, however I've no real experience of that. It's graphics were either 640x200 (4 colours) or 320x200 (16 colours).
The 65c816 has a built-in block-move instruction although it takes 7 cycles per byte - I'd like to think the DMA engine can save a cycle or 2 there, but to block-clear a 640x480 display needs to move 307200 bytes which will take 153mS using the block-move instruction. Phew! (That's also important for scrolling too unless the video generator does screen-start offsets)
Anyway, who knows for now - what I'd like is a nice fast software development platform - I'd want to develop directly on the system and not resort to cross compiling if possible, but that means a lot of tools to develop or port, so in that respect, do I need a GUI? Probably not - at least not in the early days.
And am I the only one thinking SNES/Famicom (simlar CPU) rather than C64?
Cheers,
-Gordon
I think it would be nice to see if Gregory (@c64os.com) would be interested to join is effort on this project. I have been following is work and I think he could be helpful on building a new GUI. I'll send him an invite.
Martin
I was never really impressed with GEOS . If this is implemented , I think it should be one of the last things. A disk operating system and some basic Kernel should be first.
Apologies for my part in hijacking the case design thread. Threadjacking is a serious problem that afflicts countless forums every year. We should all do our part in stamping it out.
Meh, who am I fooling? Threadjacking ain't ever gonna go away. lol
A lot of early "GUIs" in MS-DOS programs were actually text mode simulations of a GUI. Tandy's DeskMate immediately comes to mind. I suspect such a system would be more easily achievable than a graphic mode GUI on a 1987-style computer.
Phil is correct in saying "window" doesn't necessarily imply the overlapping, decorated windows that are common in GUIs today. Perhaps a better word for a rectangular output area would be "viewport," as it avoids the connotation of WIMP-style windows.
I find the idea of using ANSI graphics vs. 2D drawing kits particularly appropriate for a computer of that era. Games and other programs that require graphics mode could run full screen, which is how people still play games nowadays anyhow.
After 30 years of using WIMP GUIs, frankly I have to say the thrill is gone. If you're hung up on them, use a Mac, Windows, or Linux system. We have a unique opportunity to start fresh with a completely new paradigm here. I never associated GUIs with 80s home computers anyway. The only DOS GUI I ever used (other than Windows 3.1) was GEM. I thought GEM Paint's ability to fill an area with a user-created bitmap was pretty cool, but GEM was just another GUI shell other than that. I haven't installed a GUI on my Raspberry Pi at all. I find I can get more done with bash.
What I advocate is a simple context switcher that will allow the user to switch between several full-screen programs. The interface could be simply a screen containing square tiles or icons that represent loaded files and programs. Maybe have a few global menus for file system and clipboard operations and system settings. Even a text mode menu would suffice for the whole interface, really.
Hi Stefany and all,
I would take opportunity of this forum thread to share some ideas about a GUI.
First, I am not an expert, just a software engineer, but in the past I have made several attempts to write GUI toolkits for fun (in GFA Basic on AtariST, in Turbo Pascl for DOS) and for more serious work (a X11-based toolkit for project at university, and a Windows MFC-based toolkit for a company during internship)
As GUI I mean... GUI... Graphic User Interface. A graphic environment, IMHO, has nothing to do with multitasking, as mentioned in an other post. Managing the memory, loading the programs, dispatching the CPU time among them or just switching from one app to an other is the job of an OS, or maybe of the Kernel, not GUI's job.
Maybe the Kernel could be enhanced, or someone could write an app, to be able to load several programs in memory and give possibility to switch, but in the C256 with its processor it won't be multitasking. At best maybe one could see that as in-memory resident programs (I think there was something like that on MS/DOS). Well I'm not a kernel expert, I let that to the professionals :-))
So, let's assume that C256 is mono-tasking : one app at one moment.
A first question is: does it make sens to have multi overlapping windows (I mean decorated, movable windows)? I do not know, there are pros and cons. A good stacking window management could be enough. An application dealing with multi document could benefit from a kind of tabpane instead of cluttering the screen (800x600) with lots of windows. After all, on tablet (I know only iOS), even if the OS is true multitasking we only deal with one app on the screen, or with splitted screen.
But, who can do more can do less (sorry for the translation from french); let's assume it's about to manage several overlapping windows.
Then what does it need to have a GUI ? I do not invent anything here, just mentioning what already exists (and existed in 1987) and coming from my past experience, I would say :
- A 2D graphic library, dealing with low level graphic features: init graphic mode, dealing with palette, providing 2D graphic primitives (lines, rect, circle, fonts, text), clipping (if possible), screen buffering features if available, etc... No doubt that all that will be more that feasible on the C256.
- A windowing system. By "window" I mean rectangular areas displayed on the screen, not (only) decorated windows (even if they are windows... lol). Managing a window hierarchy and window refresh mechanism.
- A mouse and keyboard event management.
- A GUI toolkit providing elements like buttons, radio buttons, checkboxes, scrollbar, etc, etc... All those widgets are windows able to receive mouse and/or keyboard events. And of course those widgets are decorated to provide a look-and-feel. There's several option to decorate them: all vector based drawings, bitmap decoration, mixing both...
- A window manager to... manage windows at high level and to decorate them. Maybe this one is optional.
About the look and feel, well... I know one could mimic GUI existing in 1987: GEM, MacOS, AppleIIgs OS, Amiga (sorry but... eew!!), Geos... But when writing software, even in 1987, we are not limited (well, not too much)... Imagine a 1987 machine running a scifi UI for its time. What!? It already almost existed??... have I heard NeXTStep? LOL
Seriously, I think all that would need structured programming.
A 2D graphic library could use lot of assembly to implement fast drawing algorithms and to access the graphic processor features, but an interface for a higher level language should be provided.
That's why I think C is the best candidate (not mentioning that it was already here in 1987, lol).
I have started to redo such programming, after years of Java, javascript (eew!!! beurrk!!) and devops... I'm trying to write a POC (proof of concept) in C for C128, with cc65 cross compiler and Vice.
CC65 provides a tiny graphic library, and is quite ANSI compatible. Then I guess it should not be too difficult to port that for C256 ( I even think that the code could be ok for its processor because it's a compiler for 6502. (?) ) with dedicated compiler for its processor.
If I have enough time, and can achieve something interesting I will let you know here.
In terms of hardware, my intentions are to provide a specific Graphic Mode for a potential GUI mode. Considering that the CPU is fairly slow, having a large resolution bitmap is quite difficult to manage unless there are 2D hardware features that allows to move the bitmap around without too much overhead. So, I believe that with a good DMA engine and the help of the 32 available sprites and probably with the double buffering technique, I think it could be achieved with a CPU @ 14Mhz. Since every pixels in the system is 1 Byte only then, the management becomes a lot easier and bandwidth can can be contained somehow.
Anyway, a lot of possibilities will be available to a mavericky, valiant programmer with a lot of time on his hand and a desire to be the first to bring his own vision of that could have been a great GUI in the late 80s time period! Any takers?
Stefany