New GUI for the Atari 8-bit

[popmilo]

..If you're a Classic Mac coder, I hope to give you an API you can be creative with. I'm holding you to developing some apps, though!

...

Just provide the api docs and sign me up for first version of Sokoban

[simonl]

I'm planning on doing CC65 support for the API.

 

Excellent, if I can help out with something like a resource editor/compiler let me know. I miss ResEdit/rc in these days of integrated development environments . Separate resource forks like on the original Mac file system or even separate resource bundle files might pay dividends in allowing flexible memory management at runtime.

 

Cheers,

 

Simon

[danwinslow]

Sure, help will be welcome. So far I foresee a very specialized linker config and some surgery to the crt0.s file. The main() will probably wind up doing some setup and then immediately going off ( via RTS ) into the API and never really running on its own. Any execution of code will be as a result of a callback from the API, to a callback routine that main() will register. The API is in charge, not C. Usage of any memory or file related stdlib functions is pretty unlikely too, although we may lay a new malloc down as a wrapper to Jon's mem routines.

Edited September 8, 2011 by danwinslow

[UNIXcoffee928]

Well, I haven't been paying much attention to the 8-bit scene for a couple of years now, so I'm getting in on this conversation probably way to late to contribute with ideas, but here it goes anyway.

 

The things I want out of a GUI are the ability to be resolution-independant (able to run in ANY 8-bit resolution). Ability for desktop wallpaper, the ability to load and display any graphic resolution pictures, Atari mode or jpeg and gif stuff to(even the newer software graphic modes with 64/128/256/4096 color interlaced and non-interlaced like APAC for one example) regardless of the desktop resolution (obviously desktop pics would have to be in the desktop res). Of course all the usual stuff like being able to boot up any program, or disk image and then recover to the desktop afterwards. Can work on 64k or 128k machines, but takes full advantage of more memory. Multitasking with programs developed for the GUI.

 

Why stop there? What about a harem of female laboratory assistants, (blond, brunette, AND redhead) wearing labcoats, bikinis, and silver combat boots, with makeup like the Scorpion's "Rock You Like a Hurricane" video, a large, tropical private island, in the middle of nowhere, WITH a racetrack going around it, a candy-apple red squadron of SR-71 Blackbirds, a German automobile mechanic, on staff 24/7, a full size remote-control helicopter (one of those big dual prop Soviet ones, thanks), a huge stone castle, with a razor-wire perimeter, a pack of laughing hyenas for pets to keep in the front yard (please dye the fur pink, with a black Mohegan stripe, thanks), an unlimited ebay budget, a 100 foot schooner from the 1890s, a pet dolphin, and a fishbowl like the Brooklyn Aquarium, 600 Menacing-Looking Evil Robots, 20 gynoid fembots programmed like LEXX, 40 fembots programmed to do laundry with the same type of determination, a CDC 6600 and a SAGE workstation (be sure to include the built-in ashtray, thanks), Energy, food, tobacco, coffee, & support systems to make the whole island self-sustainable, a Saturn 5 launchpad, the contents of the NY Public Library, and the Museum of Natural History, some other trifles, and a really wiz-bang Internet connection? Thanks, Jon!

 

It could actually be done, that's why stop there. If you want to be sarcastic, you should at least keep it computer oriented, going off in an "anything in the world" tangent is too lame to be sarcastic.

 

... and how is Infrastructure not computer-related? ha. I was under the impression that he was entertaining Wishes, and I just wanted to make the third one count, before he got back in his Lamp. If you're gonna do Mad Science, you have to do it right, dude.

 

 

 

[flashjazzcat]

With regards to resolution independence, I agree that the lower resolutions are..harder to display and control a desktop with, but screen scrolling and scalable fonts could take care of it. My main reason for wanting all resolutions support is I'm a graphic artist and want more than monochrome or 4-color desktops and GUI oriented art programs. I want to be able to use APAC and GR. 9, etc. modes to have cool wallpaper.

Your saying that gr. 8 mode is faster for graphic routines than say Antic E or Gr. 9 would be?!? Isn't it generally the lower the res, the faster it can display?

From the hardware point of view (i.e. having the most free machine cycles left to play with), I guess Graphics 7 (160 x 96 x 4) would be a good bet (I believe it has its fans for game authoring ), but it's only when you get into diagonal lines, arcs, circles, etc, that bigger pixels start to save time. The horizontal and vertical lines and black and white rectangles which make up the GUI's basic visual components are all "blitted", for want of a better word, however, so the resolution is pretty immaterial at the moment. For example, when drawing a horizontal line, I divide it into three sections: left, middle, and right. The left section comprises 1-8 bits in the leftmost byte of screen RAM where the line begins, and the right section comprises 1-8 bits in the rightmost byte. The number of bits set in these sections naturally depends on X and the length of the line in pixels MOD 8. To draw the centre section (all the other pixels in the line divided by 8 ), I load the accumulator with $FF and STA in a loop.

 

Now, if I factor colour into the equation, these nice little optimisations aren't so easy to do and I need a lot more bit tables and shift tables (at the moment, my left / right line section LUTs are a mere seven bytes long). So I see it as a tradeoff: lower resolution in some cases (though not GR.9, which uses the same mode lines as GR.8 ) may offer speed benefits, but they're probably lost by the overhead of handling bit combinations for colour selection.

 

That said, of course you'll get a "QuickDraw" style library for doing all your graphics primitives, and to a very great extent the event handler / window manager side of things couldn't care less how things are drawn, so I guess with very great expansion of the graphics library, multi-resolution support would be possible. I just struggle to see how usable the GUI would be in 80 x 200. The components look pretty large at 320 x 200.

 

Go on then, you talked me into it. I feel a version of Minesweeper or something coming on for a kick off. Have you decided how you're handling bitmap resources for apps, or will they get a canvas and wrangle that directly themselves? If you have resource formats and APIs for bitmaps and bitmap drawing, best to make them capable of holding or referencing device parameters such as bit depths, aspect ratios and palettes for future proofing (otherwise you'll end up in the same mess as Apple when Macs went colour ) Bayer and Floyd Steinberg dither are pretty easy to implement for crunching colour/greyscale ones down to monochrome.

The above notwithstanding, you make an excellent point about not limiting the resource formats to 1BPP (at least to leave the door open for VBXE). I already spoke to Candle about ensuring the memory pointers for resources are capable of addressing the full range of the VBXE's VRAM. All the resource formats were supposed to be designed months ago, but that schedule went awry (damned real-life and other projects). I just sent MrFish an email regarding bitmap resource format and compression, funnily enough. We have icons and fonts just about down pat, but the way this thing is developing here on my hard disk... it's kind of like building a ladder up into space, with staging posts every step of the way. At each new level, the view of the whole below becomes clearer, and then I pick up my hammer and nails again and start on the next section. Sometimes I have to climb back down a few levels and make structural changes...

 

How about this: MrFish put me onto some excellent documents describing the Classic Mac's "Regions" (part of QuickDraw). It's a famously patented invention, and makes just fascinating reading.

Edited September 8, 2011 by flashjazzcat

[flashjazzcat]

Double post.

Edited September 8, 2011 by flashjazzcat

[+David_P]

I, for one, would love to see a Graphics 3 version of the GUI

 

 

Anyone out there have a Tardis? I'd like to send FlashJazzCat back to 1984 with a 256K 800xl, two US Doubler 1050s and some diskettes full of source code, so he can complete this and permanently alter the histoy of computing.

Edited September 9, 2011 by David_P

[Gunstar]

"I just struggle to see how usable the GUI would be in 80 x 200. The components look pretty large at 320 x 200"-Flashjazzcat

 

The idea would be that the whole desktop would not be visible at once, but require scrolling and/or zooming in and out or something like that. Maybe the whole desktop on screen, but then have a special large-windowed cursor, with a magnifying effect to show the desktop in more detail in the magnified window area.

Edited September 9, 2011 by Gunstar

[+DarkLord]

We've had a couple of those virtual res type apps for the ST over the years.

Let you run a desktop larger than your actual physical monitor/res could do.

 

I have to say, while not knocking anyone's idea's, that I never did care for

them at all...

[flashjazzcat]

Anyone out there have a Tardis? I'd like to send FlashJazzCat back to 1984 with a 256K 800xl, two US Doubler 1050s and some diskettes full of source code, so he can complete this and permanently alter the histoy of computing.

The neat thing about that is that if I'd started it in 1984, I'd probably be finished by now.

 

The idea would be that the whole desktop would not be visible at once, but require scrolling and/or zooming in and out or something like that. Maybe the whole desktop on screen, but then have a special large-windowed cursor, with a magnifying effect to show the desktop in more detail in the magnified window area.

Yeah - I noticed your reference to scrolling before. The only thing which puts me off is the necessity to horizontally scroll over a WYSIWYG 72DPI text document even at 320x200. Imagine scrolling a low-res screen to get access to the horizontal scroll bar, then dragging the handle to bring-off-off-screen text into view... not my idea of fun, but I'm not knocking the idea. I guess you wouldn't be doing much word processing in these modes.

 

Overlapping window drawing methods are being totally reimplemented now, using masks and no off-screen buffering. I'm keen to get a demo of this coded up, because I think it will look exceptionally cool, especially compared to the bottom-up full-desktop redraw of the previous demos.

[Stormbringer]

I was mulling over a couple of screen-buffering ideas last night, and I can see a lot of mileage in keeping separate cached bitmap copies of all "layers" of the desktop, i.e. the desktop itself and each window image. This would make redraws extremely fast but would be rather costly in terms of memory, and as I've said before, I'm against throwing lots of resources at making stacked windows look slick when they'll only show up in the desktop manager. The special "RAM cart" Steve Tucker designed for me would have been ideal for this, since we have plenty of 8KB RAM banks to waste. Unfortunately, I don't think folks want to be tied to using one particular flash cart for this thing. That's a shame, since if I could overcome the headache of where to put things when $4000-$7FFF is the RAMdisk banking window and $8000-$BFFF is taken up by 8KB of banked cart RAM and 8KB of banked cart ROM, then we could have gone really wild and designed something which ran out of the box on a stock 800XL.

 

These RAM carts, would they operate like "main" memory that other applications outside of your GUI would be able to utilize like a standard memory upgrade? Say you use your GUI to launch a demo or game that requires more than 64/128k?? The reason I'm asking is because I envision this mated with a recent IDE cart and your GUI environment.

[Vaughan]

We've had a couple of those virtual res type apps for the ST over the years.

Let you run a desktop larger than your actual physical monitor/res could do.

 

I have to say, while not knocking anyone's idea's, that I never did care for

them at all...

 

I certainly won't knock anyones ideas - but I too remember this type of idea back-in-the-day. There were similar ones for PC's. There's good reason they never took off, usability being the primary one.

[flashjazzcat]

These RAM carts, would they operate like "main" memory that other applications outside of your GUI would be able to utilize like a standard memory upgrade? Say you use your GUI to launch a demo or game that requires more than 64/128k?? The reason I'm asking is because I envision this mated with a recent IDE cart and your GUI environment.

The intention is just the opposite, really: to allow the cart (i.e. the GUI) on-board memory that nothing else will touch. Sure, an application could access the cart's RAM by manipulating the hardware registers, but 99.9 per cent of DOSes and applications will be using PORTB to seek out extra RAM for RAMdisks, etc. Keeping the GUI's extended RAM away from PORTB is a perfect way to ensure that legacy apps or DOS itself don't "interfere". The GUI could ignore PORTB RAM and DOS would be blissfully unaware of the GUI cart's RAM, and never the twain shall meet.

 

Using PORTB RAM for one's application is a real headache, since it's necessary to attempt to establish firstly which DOS we are running, and then attempt to intuit how said DOS is using or might potentially use extended RAM. I discovered all this when writing The Last Word, which - regardless of the DOS in use - first detects the amount of extended RAM present, then - according to the DOS "signature" - attempts to figure out which banks are used by RAMdisks. This is EASY when SpartaDOS X is detected, but "competing" DOSes (and their attendant RAMdisk drivcers) rarely saw fit to leave any kind of easily accessible information about extended memory and how it's being used. And it follows that since there was never any agreed standard on extended memory usage and RAM disk protocol, there's similarly no standard for applications themselves, which may or may not used fixed extended banks, wiping out RAMdisks and such like.

 

The challenge is to keep our GUI away from all this mess, and having on-board "secret" RAM that nothing else can see or access is really the ultimate solution.

Edited September 13, 2011 by flashjazzcat

[Stormbringer]

Ahh... You haven an excellent ability to explain things in an easy to understand way for the laymen like myself.

One thing I still don't get is why you are trying so hard to maintain compatibility. Isn't this being able to run on a standard 800xl more important than launching the OS from DOS 3.0? Heck, I don't even want a dos involved after someone makes a file manager, but personal preferences aside I'd hate to see old DOS's limit progression and access from standard machines. Either way, the project is awesome and hope some day to buy this when its 'done'.

 

BTW: I appreciate this and all the hard work you've done, adding tremendous value to our old lil machines. You truly are an Atari hero

[Mr.Amiga500]

The intention is just the opposite, really: to allow the cart (i.e. the GUI) on-board memory that nothing else will touch. Sure, an application could access the cart's RAM by manipulating the hardware registers, but 99.9 per cent of DOSes and applications will be using PORTB to seek out extra RAM for RAMdisks, etc. Keeping the GUI's extended RAM away from PORTB is a perfect way to ensure that legacy apps or DOS itself don't "interfere". The GUI could ignore PORTB RAM and DOS would be blissfully unaware of the GUI cart's RAM, and never the twain shall meet.

 

Using PORTB RAM for one's application is a real headache, since it's necessary to attempt to establish firstly which DOS we are running, and then attempt to intuit how said DOS is using or might potentially use extended RAM. I discovered all this when writing The Last Word, which - regardless of the DOS in use - first detects the amount of extended RAM present, then - according to the DOS "signature" - attempts to figure out which banks are used by RAMdisks. This is EASY when SpartaDOS X is detected, but "competing" DOSes (and their attendant RAMdisk drivcers) rarely saw fit to leave any kind of easily accessible information about extended memory and how it's being used. And it follows that since there was never any agreed standard on extended memory usage and RAM disk protocol, there's similarly no standard for applications themselves, which may or may not used fixed extended banks, wiping out RAMdisks and such like.

 

The challenge is to keep our GUI away from all this mess, and having on-board "secret" RAM that nothing else can see or access is really the ultimate solution.

 

That's an awesome idea. I'd definitely buy a GUI cart that uses its own onboard RAM.

 

But... now I'm starting to get crazy ideas of combining it with the Ethernet cart into a monster cart with a built in GUI browser and email and removable SD card and megabytes of RAM and... [help! somebody stop me!]

Edited September 13, 2011 by Mr.Amiga500

[flashjazzcat]

Ahh... You haven an excellent ability to explain things in an easy to understand way for the laymen like myself.

Heh... thank you. I suppose this facility aided in my success when teaching ICT to senior citizens. I wish I was still doing that job, given the alternatives...

 

One thing I still don't get is why you are trying so hard to maintain compatibility. Isn't this being able to run on a standard 800xl more important than launching the OS from DOS 3.0? Heck, I don't even want a dos involved after someone makes a file manager, but personal preferences aside I'd hate to see old DOS's limit progression and access from standard machines. Either way, the project is awesome and hope some day to buy this when its 'done'.

I think the desire for compatibility arises because of two factors. Firstly, the GUI must be able to run legacy applications written for DOS, and must therefore have a compatible binary loader and be able to "recover" fairly efficiently when the legacy application terminates and drops us back to the desktop. If the legacy app has trashed all the extended RAM, clearly the GUI will have to rebuild the entire object tree and reinstall all resources, etc, used by the desktop manager. Secondly, the GUI is currently reliant on DOS for the file management system, and since I've been strongly discouraged from tying the GUI to - say - SpartaDOS X - we have to work with what we've got. There are a lot of MyDOS and DOS 2.5 users out there who don't think it's reasonable that they have to adopt a more advanced DOS just in order to use the GUI.

 

Of course, we could solve many problems by building the FMS into the GUI itself, in the same way which GEOS did it on the C64. Unfortunately, creating an FMS more or less from scratch which gave us half the functionality and solidity of SpartaDOS X would be a rather intimidating prospect. I have the interest of one DOS author who would be happy for the FMS to be built into the GUI, but imagine the job of writing GUI undelete apps, disk partition editors, etc, etc. It would be rather like dropping the DOS "layer" in Windows 95 and writing Windows NT.

 

However, the prospect of running the GUI on a stock 800XL is an enticing one, and the RAM cart would allow us to do precisely that. But there are always those who think it's unreasonable to be asked to shell out dollars or Queen's sheets on "specialized" cartridges however far the software designed to run on it pushes the envelope, so to speak. Putting the GUI on a cheap flash cart is probably an unpopular move to begin with (despite the overwhelming and excellent reasons for doing so), so it looks like I'll have to make at least two builds of the GUI to keep everyone happy: one which runs on a generic flash cartridge, and one which runs on Steve Tucker's RAM cart or Hais' new Turbo Freezer.

 

BTW: I appreciate this and all the hard work you've done, adding tremendous value to our old lil machines. You truly are an Atari hero

Thanks. I just hope I don't go to zero any time soon.

 

That's an awesome idea. I'd definitely buy a GUI cart that uses its own onboard RAM.

Great!

 

But... now I'm starting to get crazy ideas of combining it with the Ethernet cart into a monster cart with a built in GUI browser and email and removable SD card and megabytes of RAM and... [help! somebody stop me!]

It's hard not to go down that thought-path! Imagine SIDE with on-board RAM... it has to be said, though, that Steve's RAM cart (assuming I overcome the logistical obstacles to using it for this project) has a pass-thru, so you could plug your SIDE cart into the back of it: you'd then have plug-in ROM and RAM, GUI, SDX, RTC, and IDE HDD.

Edited September 13, 2011 by flashjazzcat

[Stormbringer]

A cart that does all this and has your GUI on it is hard NOT to buy. If its accessible enough then throw them on ebay and get the average joe up and running easily. I'm a cheap ass and would throw money to this gladly.

 

candle and steve, get together have a love child and glue that ram on there please - I'd like a kitchen sink in there too if you can fit it.

 

One cart to run them all, One card to find them,

One cart to bring them all and in the Atari bind them.

 

Hummm.... ethernet? how bout bluetooth instead? doesn't that have a networking layer? then we can join mice, keyboards webcam's.... flashjazzcat will write drives for them all (you know im kidding about this, right?)

[flashjazzcat]

...flashjazzcat will write drivers for them all...

Heh... these preductions have a habit of coming true.

 

Anyway - perhaps my entire life has been leading up to seeing this in front of my eyes:

 

http://www.youtube.com/watch?v=-GTbVjdeurk

 

How nice is that!

[+DarkLord]

...flashjazzcat will write drivers for them all...

Heh... these preductions have a habit of coming true.

 

Anyway - perhaps my entire life has been leading up to seeing this in front of my eyes:

 

How nice is that!

 

That is awesome...!

 

PS BTW, were you eating chips?

[flashjazzcat]

PS BTW, were you eating chips?

Certainly not - no food comes near this machine!

[+DarkLord]

Certainly not - no food comes near this machine!

 

lol - Okay...just near the end of the video, with the sound turned up,

there is a suspicious shadow and sound...

[flashjazzcat]

...there is a suspicious shadow and sound...

LOL - it's the camera (silhouetted), and the sound of the shutter closing (or something - I must admit it does sound like a packet of Tudors).

Edited September 14, 2011 by flashjazzcat

[popmilo]

I've been following your Gui development for some time now, but I just realized I have no idea what sort of hardware would I need to run it ?

 

Will it work on 64k 800xl, and I guess sio2sd will be ok as a drive ?

 

ps. mouse of course

[w1k]

I've been following your Gui development for some time now, but I just realized I have no idea what sort of hardware would I need to run it ?

 

Will it work on 64k 800xl, and I guess sio2sd will be ok as a drive ?

 

ps. mouse of course

 

yes, try it only

[flashjazzcat]

I've been following your Gui development for some time now, but I just realized I have no idea what sort of hardware would I need to run it ?

 

Will it work on 64k 800xl, and I guess sio2sd will be ok as a drive ?

 

ps. mouse of course

If the RAM cart version is possible (no guarantees there) it'll work on a 64K 800XL. Otherwise, minimum hardware will be a 130XE (or equivalent), and without the RAM cart it'll be a case of the more on-board RAM you have, the better.

 

I'm not tying it to any DOS or using lots of overlays, so any SIO storage medium should do (although an HDD is obviously gonna give the most responsive experience).

 

ST or Amiga mouse - either's fine. We'll have drivers for other input devices eventually.