New GUI for the Atari 8-bit

[Shawn Jefferson]

I would like a GUI desktop where I can launch a binary (like Atari Tennis or BobTerm for example) via icon double-click. I would like then to be able to terminate it, perhaps by escape key or key-combination, and end up back on the desktop without reboot.

 

That would be a neat trick, on an Atari. Most games assume they own all the RAM in the machine, especially ones that were converted from cartridge like Tennis. There's a good chance that any random game will overwrite your GUI system (either the GUI code itself, or the memory it's using for whatever data structures it needs while running). Without hardware support for protected memory pages, there's not much the GUI code could do about it...

 

Maybe using something like the Atarimax flashcart or the Corina cart would work. You could hook DOSVEC to call a small routine in the bottom of the stack (page 1) to reenable the cartridge and boot your GUI code again. With these carts you could "save" your desktop state as well, so that when it boots back up, everything looks like it did when the user ran their application... doesn't matter if the application returns via DOSVEC, or ends up cold booting the machine. The user is fooled into thinking it returned to the GUI properly.

 

Of course, making it cartridge based will probably preclude it being used with SpartaDOS X, which would be too bad. A nice app would be a moveable terminal window for SDX, and the ability to have several open at once.

[Thorsten Günther]

I would like a GUI desktop where I can launch a binary (like Atari Tennis or BobTerm for example) via icon double-click. I would like then to be able to terminate it, perhaps by escape key or key-combination, and end up back on the desktop without reboot.

 

As others have already pointed out: most games suppose they own the computer alone and they don't even have a "quit" function - but that was similar on the Atari ST, where the vast majority of games had to be ended by resetting the computer. It would of course help if the program was on ROM (e.g. on an extended SpartaDOS cartridge), in extended RAM or even in the 16 KB of RAM "under" the ROM in the 64K machines (many games do not use that area as they would not run on a 400/800 then, but several other programs - e.g. Turbo-BASIC XL - do).

 

Thorsten

[Thorsten Günther]

I don't see Translator as any sort of issue - any game or application worth having should have been XL fixed by now.

 

I've found one that - sadly - was not: Slime by Synapse. Or perhaps anyone else here knows a fixed version (I tried Fandal's site, Homesoft, atariarchives.org, atarimania.com and even igorlabs.com (Steve Hales' page) directly).

 

Most other games - also the other Synapse titles - have been fixed though.

 

Thorsten

[Wrathchild]

Check on this thread.

[walter_J64bit]

I don't see Translator as any sort of issue - any game or application worth having should have been XL fixed by now.

I've still have old software, that hasn't been fixed.

[MEtalGuy66]

Maybe you could implement some sort of feature like "snapshot" uses in extended ram.. Make it set up another complete memory map in extended ram, and "swap" it when it executes programs, then install some "hook" to trigger a small routine that "swaps it back" to get back to the GUI..

 

Also, How feasible would it be to use the "interlaced" modes that Rybags developed, in order to gainmore vertical resoultion? One of my biggest problems with GUIs on the 8-bit is limited screen real-estate..

[twh/f2]

A terminal to the underlying SpartaDos X+ command line would be nice!! The killer app would be to me if you could run The Last Word and the terminal in parallel. Just like DOS and windows 3.1 or something

 

grtx,

\twh

[flashjazzcat]

Maybe you could implement some sort of feature like "snapshot" uses in extended ram.. Make it set up another complete memory map in extended ram, and "swap" it when it executes programs, then install some "hook" to trigger a small routine that "swaps it back" to get back to the GUI..

 

Also, How feasible would it be to use the "interlaced" modes that Rybags developed, in order to gainmore vertical resoultion? One of my biggest problems with GUIs on the 8-bit is limited screen real-estate..

That sounds an attractive option, actually. Although I'd prefer to focus on custom-written apps for this system, it's obvious it's going to have to be able to launch the text mode apps and games which will make up 99.9% of the software which is run on it. I think the best idea is if a launched applicaion isn't a GUI app, the resident GUI library hides itself completely until the application hands control back to DOS. This could be accomplished via a small TSR in low RAM or some such. The opportunities presented by cartridge bank switching are immense, but compatibility with MaxFlash versions of SDX is a must, and given that the GUI would have to reside on a MaxFlash cart, the cart option's not looking good.

 

I guess the interlace idea is perfectly realistic, subject to a packed interrupt schedule which already handles the mouse, rendering the pointer and will also have a keyboard buffer tacked onto it. I also think interlaced 640x400 would be great using VBXE: this would yield the same hi-res as the ST desktop.

 

A terminal to the underlying SpartaDos X+ command line would be nice!! The killer app would be to me if you could run The Last Word and the terminal in parallel. Just like DOS and windows 3.1 or something

I agree! If I get my head around the SDX console driver (as I've promised Draco for ages), it should be possible to pipe SDX output to a terminal window with proportionally spaced text. I think what would work nicely with this is a "freezer" kind of facility, where two apps can be swapped in and out with a hotkey. Advanced and ambitious stuff, but all possible.

 

I've been thinking today about data structures and the general architecture of the window manager. It's very hard to find good texts on the theory of this stuff so I would appreciate any pointers (no pun intended). I assume I'm leaning in the right direction by implementing a stack of clickable regions: basically, these regions will be scanned, from foreground window to back (thus dealing with overlapping windows) on a mouse click, yielding an ID of the region clicked. The event handler will then match the ID against any controls it needs to deal with itself (scroll bar dragging, window swaps, focusing on dialogue controls, etc), and if not, it will finally return the X,Y and region ID (along with click type) to the application if it's within the workspace area.

 

It seems a good idea to keep the click regions and controls/window data structures separate (relating them together with ID numbers), but complications arise with the stacks when it comes to windows changing their stacking order, etc.

 

As I say, I could do with some good reading on the basic data structure theory of a window/GUI manager.

Edited December 9, 2009 by flashjazzcat

[atarixle]

well ... GUIs all failed on the 8 Bit ...

 

some were available just on cartridge (Diamond GOS)

some need too many hardware-extensions (TRS-Desktop)

some weren't very flexible (SAM - runs only on DOS2)

and some were written in BASIC (BOSS-X)

 

we're looking forward to your project

[+CharlieChaplin]

Well,

 

most GUI`s that were and still are available (with a few exceptions) can only load a few applications and/or tools that were written especially for it. Most of the time these GUI`s run only under one certain DOS version. Nowadays more and more users want a GUI on the A8 that can load simply everything, e.g. games, demos, applications, tools, utilities, whatever and run fine under almost every DOS - but this scenario seems a bit unrealistic to me...

 

Why not extend the features of the old GUI`s in the application/tool/utility area ?!? I am thinking of a GUI that would become the ultimate application/tool/utility/viewer/player (loader-) package:

 

- loads/runs applications like a Word Processor (e.g. the last word), a Spread sheet (e.g. something like Visicalc, Syncalc or the PD programs Speedcalc, B[bK]-Calc), a Painting/Drawing program (e.g. something like XL-Art) and other applications that should be the most important factor besides the GUI itself...

 

- load/run tools like e.g. file copier, sector copier, disk/sector-editor, gamedos, bootloader, packer/depacker, etc.

 

- load/run utilities like e.g. a calendar, a diary, a calculator, a hex/dec/bin converter, etc.

 

- load/run a gfx viewer (and/or converter) program for various A8, PC, ST, Amiga, Mac picture formats to display these pics on the A8; this should be an expandable, where the GUI provides free room to load in other/external viewer programs than the few that come with it. Maybe it could be done in a such a way, that the GUI uses some file and function similar to WIN.INI, which means a file that keeps track of the extensions and which programs must be loaded to show such files - e.g. whenever one clicks on a file named *.G15 the GUI will look into this INI file (or file extention table) and then load a viewer which can finally display Gr. 15 Micropainter or Koala files (the same for other A8 gfx formats or PC formats like GIF, TIF, JPG,etc.; ST formats like PI1/PC1, PI2/PC2, PI3/PC3, etc.; Amiga formats like IFF, etc. )

 

- load/run a text viewer/reader program to display not only ASCII and ATASCII texts on the A8 but also other text formats (HTML, RTF, etc.), in 40-column or 80-column mode with a) scroll option (scroll displayed text up or down) or b) page-option (left-right to display one page of text, where left=previous page and right=next page of text)...

 

- load/run a player (and/or converter) program for various A8, PC, ST, Amiga, Mac sound formats, to playback these sounds in 2Bit, 4Bit, 6Bit or 8Bit resolution (mono/stereo/quad) with the A8. The same functions as in the viewer area should apply here, the GUI looks for the extender of the file (in the INI table) and then starts a certain player program to playback that sound (of course there is no need for the GUI to check for mono/stereo/quad or the BIT resolution or the availability of certain upgrades, its the job of the player program to check for all that or at least provide a menu where one can choose from different options...)

 

The GUI could then provide a fixed number of applications (four or five maybe; this could also be PD programs that run fine with that GUI), whereas in the area of tools, utilities, viewers and players it will provide only a few programs (two or three maybe) but therefore it will be expandable there. Regarding the DOS, its not nescessary to support all available DOS versions (the A8 simply has too many!) but at least two very common ones - for me a GUI that would only run under SpartaDOS or SpartaDOS X would not be enough, there should be also support for one DOS 2.x type (might it be MyDOS, TopDOS or another DOS 2.x type), so that the GUI runs in both SpartaDOS and DOS 2.x worlds. Not everyone owns SpartaDOS X yet and if one has to buy (or burn) SpartaDOS X first to use the GUI, it will surely keep some Atarians away from using this GUI.

 

Last not least the GUI should use or better require as basic A8 hardware as possible, e.g. 64k or 128k (not a minimum of 320k or 1024k), Antic/GTIA (not nescessarily VBXE or other GFX upgrades), mono/4Bit (not nescessarily stereo or quad Pokey or 8Bit-Covox or other sound upgrades), minimum a disk drive with 130k or 180k (not nescessarily a SIO2xxx device with a 16MB image or a harddisk with a 16MB partition) or some other non-standard upgrades and extentions. These upgrades and extentions could be supported, but the GUI has to run fine without them in the first place...

 

...just some thoughts...

(Besides, I have already uploaded various GUI`s from my collection several times here at atari-age, maybe some of them can be used for collecting ideas or -the opposite- to remind you how it should not be done...)

 

-Andreas Koch.

Edited December 9, 2009 by CharlieChaplin

[flashjazzcat]

Been reading through the Diamond Manual and all of the supplied MAC/65 macros and source code. The API is actually very well thought out, although certain things - such as dialogue controls not automatically setting up their own "touch areas" (this has to be done explicitly for each control), and it being impossible to "click" out of a text box without pressing return - are slightly unusual. I'm inclined to follow the same programming model: this will mean that reverse-engineering the programming concepts will be much easier. The more I study Diamond, the more impressive it is. I think what actually held it back was over-ambitiousness. The word processor, for example, doesn't need to have a 64K text buffer in extended memory. It's also beset by "quirks" which I find frustrating, like keys which annoyingly won't register in the file selector, and the aforementioned not being able to click on anything while typing into a text box. These small details, coupled with sluggishness in critical areas, are what spoil Diamond for me. Other than that, I'm more amazed by the day by just what a huge achievement it is. It's by far the most complete WIMP environment I've ever seen on the A8. Forget that it doesn't allow wallpaper, of doesn't run in 80 columns, or was only available on a cartridge. It's a very, very clever piece of software. Personally, I'd be satisfied with a makeover of the Diamond UI, plus an overhaul of its underpinnings, but until Alan digs out the source code, that's not going to happen. A shame, because it would have saved a whole lot of time.

 

So, I think I'll write a compatable system, but written totally from scratch. Quite how the proportional fonts will fit in with the original Diamond API, I'm unsure, but on the whole I think it's doable. Why re-invent the wheel, as they say. Sure the entry points will be different on my system (especially while the code decides where it's going to live), but we could even add additional "functuion" numbers to Diamond's list in order to introduce new controls such as icon bars, list boxes, and the like.

 

...as to Andreas' post which co-incided with my own: I agree with many points there, especially with regard to hardware and DOS requirements. In reality, I DON'T want this thing to become a glorified file launcher. What really bugs the s**t out of me, if I'm honest, about some modern A8 GUIs, is that they come with a bunch of software which, when launched, does away with the GUI altogether. There will have to be a set of key applications specially written for the interface. This is where I'd hope to incite the interest of application programmers out there, although there don't appear to be more than a handful. GEOS - though dog-slow - succeeded because the bundled GUI apps were not only good, there were some of the best of their typed, GUI or not. Of course, they had the weight of umpteen programmers at Berkley Softworks. There's no way I'll be able to code up a word processor, spreadsheet, paint package, desktop publisher, database, media player, etc, etc, all on my own.

 

So - application programmers - cast your eyes across the Diamond Developers manual: your services may be required soon!

Edited December 9, 2009 by flashjazzcat

[walter_J64bit]

o - application programmers - cast your eyes across the Diamond Developers manual: your services may be required soon!

 

Does anyone have the Diamond Developers manual on a PDF?

[flashjazzcat]

Here you go. Both manuals on PDF:

 

Diamond - GOS.pdf

 

Diamond - Developement.pdf

 

And the Examples (un-mac/65'd):

 

Diamond Examples.zip

Edited December 10, 2009 by flashjazzcat

[pseudografx]

I've been playing in my graphics editor just for fun and this is what I came up with :-)

Edited December 10, 2009 by pseudografx

[MEtalGuy66]

What about the ability to use a huge 4-way scrolling "superbitmap" desktop ?

[flashjazzcat]

I've been playing in my graphics editor just for fun and this is what I came up with :-)

Nice! Not sure I'll manage co-operative multi-tasking, though!

 

What about the ability to use a huge 4-way scrolling "superbitmap" desktop ?

Possible: or we could go for multiple desktops...

 

Anyway, back to basics. I had a look at Diamond with the Atari800Win monitor and it does indeed "steal" $0A in order to circumvent the DOS menu, so that's that sorted.

 

I've been designing the dialogue API today, and I think we could go a stage further than Diamond (assuming I understand Diamond's methodology correctly), and provide a dialogue with a list of controls with their "hot spots" built in, along with the text prompts, etc. The event handler will only return a plain, unactioned X,Y and click type once it's exhausted all the visible controls. I've devised a common data block for all controls, and Radio Buttons, for example, will be described as a group and all you'll have to worry about is extracting a single byte (i.e. the ID of the selected radio button) when the user clicks "OK". Roughly, the data structure is:

 

.byte control_type

.byte ID

.byte num_elements

 

...and for each control in the list (although anything but a radio button group will only have a single element):

 

.byte touch_ID (corresponds to "hot spot" in global list of touch areas)

.word value (#of selected item in group control / control value / or address of string for text box)

.byte x,y (co-ord of control)

.byte width, height (size of control)

.byte x,y (co-ord of label)

.byte [label]

.byte 0

 

"control_type" will be something like:

 

1 - Command Button

2 - Check Box

3 - Radio Button

4 - Text Box

 

Doubtless there will be others added eventually. The event handler will check the list of hotspots when the mouse is clicked, and when it finds a match, it will scan the dialogue's controls until it finds the hotspot ID among the controls. It will then action the control, update the variable in the data block, and return an event to the user. Nine times out of ten, the code will just need to loop until the OK or cancel buttons are clicked. Text boxes are a tad more complex, in as much as a click outside the text box will need to be registered as an event and fed back to the event handler.

 

There will also be "non-click" touch areas, so that - for example - a drawing program could get an event saying "mouse is now over toolbar area". The main program could then change the pointer from a crosshair back to an arrow while the mouse is hovering over the icons.

 

The implementation of the text cursor will be trickier, since I've used up most of the resources on the mouse pointer. If the text cursor doesn't need to flash, things will be greatly simplified. Formatted text output will be handled by a proper "printf" routine.

 

Now that Mr Fish has been kind enough to design a proportional system font, I aim to get a plain desktop with a mouse pointer and working pull-down menus this weekend.

Edited December 10, 2009 by flashjazzcat

[tebe]

some ideas from my old unfinished project, graphics primitives, line (dot line), box, fillbox (fill with shape 8x8 pixels), pmgbox (underlay pmg), circle etc.

windows6502.zip

[+Guitarman]

flashjazzcat,

 

Allan Reeves was on Atariage a year or 2 ago. He gave me some cool insight into what happened with Diamond and Atari. Anyway, you may want to get a hold of him and see if he has any helpful info to use in the project.

[flashjazzcat]

flashjazzcat,

 

Allan Reeves was on Atariage a year or 2 ago. He gave me some cool insight into what happened with Diamond and Atari. Anyway, you may want to get a hold of him and see if he has any helpful info to use in the project.

I corresponded at some length with Mr Reeves some months ago about Diamond. We were discussing bringing the project back to life (subject to his digging out a lot of old stuff), but I haven't heard anything from him since then.

[walter_J64bit]

flashjazzcat,

 

Allan Reeves was on Atariage a year or 2 ago. He gave me some cool insight into what happened with Diamond and Atari. Anyway, you may want to get a hold of him and see if he has any helpful info to use in the project.

I corresponded at some length with Mr Reeves some months ago about Diamond. We were discussing bringing the project back to life (subject to his digging out a lot of old stuff), but I haven't heard anything from him since then.

Cool, maybe he has some un-Release apps like a screen saver or something I hope he'll reply back.

[analmux]

I've been playing in my graphics editor just for fun and this is what I came up with :-)

Nice work. I really like these.

 

Any more?

[falcon_]

flashjazzcat,

 

Allan Reeves was on Atariage a year or 2 ago. He gave me some cool insight into what happened with Diamond and Atari. Anyway, you may want to get a hold of him and see if he has any helpful info to use in the project.

I corresponded at some length with Mr Reeves some months ago about Diamond. We were discussing bringing the project back to life (subject to his digging out a lot of old stuff), but I haven't heard anything from him since then.

 

 

I don't want to be negative to your efforts flashjazz, you've already put in a good amount of time on your plans.

I'm getting to this thread a bit late. I do like your plans and would love to see it happen, however I feel concern

that the Wheels you're using (checkboxes, window-movement, clicky-area-filtering, etcs) are more appropriate for bigger

machines, and maybe it needs to be honed down to fit 8bit scale? Already you mentioned you were concerned with size.

 

Might I suggest another idea? Instead of redoing all the regular windows elements and its similar functionality,

why not make the system simpler but with clever interoperating principles? What I mean by that is if I were

to think on designing this, I would probably start from the PSP UI as inspiration. It's functionally fairly

simple, but it's able to do everything one needs. Other inspiration is the Palm pda's. The Atari pretty much

has to be single-tasking IMHO, so why not build the UI for that? The UI can appear on its own separate screen,

not interfering with the App/Game screen. How many UI controls/things does any possible Atari8 App need?

 

I would drop the Checkboxes and Bullitbuttons, and go with either ValueTag (32bit/4byte) or TextTag (2byte pointer

to buffer, and 2byte length.) There could also be a powerful Plugin type system, for things just like file-viewers,

etc. Perhaps a very (very) minimal script language internal to it, and it is able to call-back into the GUI functions

for greater functionality? The PSP style UI could even be done in Gr.0, saving more memory from being eaten.

PMG's could be used for color icons (3 PM's with overlap-colors), which also might be stacked virtically meaning

different colors for each icon and maybe use one PM for a pointer in some cases. Shouldn't need it full-time tho.

 

How much memory can this GUI afford to use?? Is 16K alright in all situations? Can it be done smaller?

KISS Principle, Optimized, and Small.

 

Just my .02, maybe food for thought for anyone... :-)

 

*peace*

falcon_

[flashjazzcat]

I don't want to be negative to your efforts flashjazz, you've already put in a good amount of time on your plans.

I'm getting to this thread a bit late. I do like your plans and would love to see it happen, however I feel concern

that the Wheels you're using (checkboxes, window-movement, clicky-area-filtering, etcs) are more appropriate for bigger

machines, and maybe it needs to be honed down to fit 8bit scale? Already you mentioned you were concerned with size.

 

Might I suggest another idea? Instead of redoing all the regular windows elements and its similar functionality,

why not make the system simpler but with clever interoperating principles? What I mean by that is if I were

to think on designing this, I would probably start from the PSP UI as inspiration. It's functionally fairly

simple, but it's able to do everything one needs. Other inspiration is the Palm pda's. The Atari pretty much

has to be single-tasking IMHO, so why not build the UI for that? The UI can appear on its own separate screen,

not interfering with the App/Game screen. How many UI controls/things does any possible Atari8 App need?

 

I would drop the Checkboxes and Bullitbuttons, and go with either ValueTag (32bit/4byte) or TextTag (2byte pointer

to buffer, and 2byte length.) There could also be a powerful Plugin type system, for things just like file-viewers,

etc. Perhaps a very (very) minimal script language internal to it, and it is able to call-back into the GUI functions

for greater functionality? The PSP style UI could even be done in Gr.0, saving more memory from being eaten.

PMG's could be used for color icons (3 PM's with overlap-colors), which also might be stacked virtically meaning

different colors for each icon and maybe use one PM for a pointer in some cases. Shouldn't need it full-time tho.

 

How much memory can this GUI afford to use?? Is 16K alright in all situations? Can it be done smaller?

KISS Principle, Optimized, and Small.

 

Just my .02, maybe food for thought for anyone... :-)

Without question, the KISS principle is always a good one to follow. Originally I had intended to follow the GEOS design, with fixed windows, no overlapping, no scroll bars, etc. It's only after researching Diamond that I realized these features are fairly simple "extras" as far as implementation goes. The bulk of the code is concerned with presentation, and doing things in a very specific way. I've taken pains to avoid PMG use and base the system around proportional fonts because presentation is all with this project. Moreover, the UI is intended less as a launch pad for existing software, than as a platform for specially written applications. Certainly the 8-bit can be easily overloaded with functionality, but the drive behind this project is to see something as polished as GEOS gracing our Atari screens.

 

Given that the first application for this system will be a word processor, I see the UI requiring check boxes, radio buttons, text boxes, spinners, list boxes and sliders. I like the plug-in idea: it would be terrific if the system could be designed with a minimal set of controls built-in, and additional ones loaded from a resource file.

 

Something like this project is going to mean different things to different people. It's already generated a great deal interest (even though there are plenty of other Atari GUIs out there), and this - along with all the suggestions and points of view - are extremely welcome. When using my touch-screen mobile phone (which has a very simple interface), I often wonder what I can take away from that and apply to the GUI. So the ideas are far from cast in stone as yet: I hear what you're saying and these and all other comments will be in my thoughts as I progress with the design over the coming weeks.

 

As for memory requirements: I've set myself the challenge of keeping the base code down to 16K (or 14 if it were to live under the OS ROM). This doesn't include buffers or anything; it's just solid library code. The desktop, apps, etc, will all be loaded from disk. Applications should remain small, since things like file selectors, menus, dialogue handlers, etc, will all be in the library code. To get a file selector, you should just have to push three or four pointers onto a stack and do a JSR. In a program like "The Last Word", the file selector accounted for about 4K of the application's code (although it is a very full-featured file manager).

 

We'll need another extended bank for heap space, stacks, etc. The screen (sadly) has to reside in main memory (in order to be compatible with DOS and RAMdisks), although a future VBXE version will be freed up in that respect.

 

Who knows: there may prove to be no need for overlapping windows and the like once I think out how the desktop's going to work. It's often easier to take cues from something we know (i.e. GEM or the early Mac OS) than to come up with new ways of doing things. Floating windows are probably the least essential element of the GUI. The important elements are:

 

• An easy way for an app to put a menu system on the screen
• An easy way for an app to gather complex input from the user (dialogues)
• An easy way for an app to get a filename and path from the user
• An easy way for an app to draw nice-looking proportional fonts on the screen in a number of sizes
• An easy way for an app to draw lines, circles, filled areas, etc.

We really are going back to UI fundamentals here, which is quite fun in itself. What worries me is how much an application like The Last Word will shrink/expand when the GUI is applied to it. Most of the "presentational" code will be jettisonned, and if the file selector is cleverly written, the file management module can be completely jettisonned. Will the editor itself be WYSIWYG? If it is, the print formatter will delegate much of its functionality to the screen refresh. If it isn't, the print formatter will get even more complex.

 

Who knows? It'll probably take me till February to get a system which will print "Hello World!" in a message box.

Edited December 13, 2009 by flashjazzcat

[Velcro_SP]

 

Maybe using something like the Atarimax flashcart or the Corina cart would work. You could hook DOSVEC to call a small routine in the bottom of the stack (page 1) to reenable the cartridge and boot your GUI code again. With these carts you could "save" your desktop state as well, so that when it boots back up, everything looks like it did when the user ran their application... doesn't matter if the application returns via DOSVEC, or ends up cold booting the machine. The user is fooled into thinking it returned to the GUI properly.

 

Of course, making it cartridge based will probably preclude it being used with SpartaDOS X, which would be too bad. A nice app would be a moveable terminal window for SDX, and the ability to have several open at once.

 

Good idea. Yeah, it should be possible to launch a binary like Tennis (or Star Raiders, etc.) from the desktop, but is it really feasible to find a way to terminate it (other than flicking the power switch)? It would be okay if that were even possible to just quick-reboot the desktop (warm-start) but to get that speed it'd have to be cart-based.

[flashjazzcat]

Sorry about the lack of progress with this, but I've used all my spare time over the weekend finishing my SIO2SD case. Once that's done (which should be tonight), that's it for the hardware mods for the time being.

 

I found out today that my full-time job is not being extended beyond Christmas, so I'll have some time on my hands in a couple of weeks to get stuck into the GUI (and other stuff I've promised people I'd get around to).