Jump to content
IGNORED

New GUI for the Atari 8-bit


flashjazzcat

Recommended Posts

Well - maybe it will be possible. I hope so. However, one practical point: if the ethernet cart is plugged in, where does the GUI cart go? :)

 

Well...

 

However, I want to make a commercial version with custom cart case, printed manual, etc. The custom cartridge will at the very least have a pass-thru on the back.

 

You just gave the answer to yourself. :)

 

Heh, I suppose I did. I just envisaged widespread use of the GUI on standard flash carts, supposing that not everyone will want to buy a custom cart. But, I guess if they want Internet functionality...

 

Well - maybe it will be possible. I hope so. However, one practical point: if the ethernet cart is plugged in, where does the GUI cart go? :)

Contiki is a bit more than 'just' a TCP/IP stack, hence it's full name Contiki-OS..

Projects like uIP(micro IP) work in 4-5K of code space with RAM use measured in the hundreds of bytes.. And is also part of Contiki.. By the same guy, but whether or not it was the starting point of Contiki I don't know.. It used to be a seperate project, but now seems to link directly to Contiki, hence why I've linked to the old uIP ;)

Also projects like ip65 etc.. There's stacks of them out there, and there's no reason for them to be show-stopping in size, unless you want to write the worlds first 6502 Torrent client supporting 1000's of simultaneous connections ;)

 

I certainly wasn't implying that Contiki was no more than a TCP/IP stack. :) I've read about the OS (even looked at the A8 sources), but my mind's just not in the right place right now. ;) I'll surely look into supporting the Ethernet cart at some stage, though: it's a no brainer having a browser and chat client in an attractive GUI environment.

Link to comment
Share on other sites

I am no expert, but Contiki "advertises" itselft as requiring only 40k ROM + 2k RAM. That is the reason the IP stack could be used in other low RAM configurations.

 

Well - maybe it will be possible. I hope so. However, one practical point: if the ethernet cart is plugged in, where does the GUI cart go? :)

 

This is more like wishful thinking than anything else, but since the Atari ethernet cartridge is still an unfinished project, they might add to the final version the option to boot from a built-in eeprom, I figure that said eeprom should be at least 256k in size to be useful since I am supposing the GUI will be commonly used alongside spartados (which requires 128k ROM) and the GUI+IP stack will most likely exceed 64kb of ROM (specialy if including VBXE extensions). Yeah, I know I am dreamer ^^;

Link to comment
Share on other sites

This is more like wishful thinking than anything else, but since the Atari ethernet cartridge is still an unfinished project, they might add to the final version the option to boot from a built-in eeprom, I figure that said eeprom should be at least 256k in size to be useful since I am supposing the GUI will be commonly used alongside spartados (which requires 128k ROM) and the GUI+IP stack will most likely exceed 64kb of ROM (specialy if including VBXE extensions). Yeah, I know I am dreamer ^^;

 

That sounds an ideal solution. The GUI code footprint (in 8KB banks) will be at least 32KB, but I'd like to map the rest of the free cartridge space out as a ROM drive (a la SpartaDOS X).

 

Regarding VBXE extensions - careful not to give Candle palpitations. :) VBXE version will require completely new graphics module (basically we just replace the whole graphics layer of the GUI, since - shock horror - we're not using hardware abstraction here as far as pixel operations are concerned). This will happen one fine day, but not before version for stock hardware is complete and released.

 

Well - maybe it will be possible. I hope so. However, one practical point: if the ethernet cart is plugged in, where does the GUI cart go? :)

 

In here?

 

med_gallery_3660_639_40067.jpg

 

Yikes. :) So GUI set-up kit should include cartridge, dremel and soldering iron. :D

Edited by flashjazzcat
Link to comment
Share on other sites

Wow! This is very cool. I've been following off and on for awhile and am really surprised at the progress made. This is turning out to be a real must have!!

 

So- will I be able to use this on my 130XE as is? I keep getting kinda lost in the technical stuff on the posts...

Link to comment
Share on other sites

I certainly wasn't implying that Contiki was no more than a TCP/IP stack. :) I've read about the OS (even looked at the A8 sources), but my mind's just not in the right place right now. ;) I'll surely look into supporting the Ethernet cart at some stage, though: it's a no brainer having a browser and chat client in an attractive GUI environment.

 

We can only imagine...

http://mrgan.tumblr.com/post/3330188156/pixelfari

Link to comment
Share on other sites

As far as it's concearned the name of New GUI

I think it must be smth. like Last Word (Do your remember it FJC?).

Surely - Last Desk.

 

Or - considering state of bank balance - perhaps Last Penny or Last Breath. :D

 

Anyway - thanks for the suggestion! Word processor is a alive and well, BTW... I need to formally release VBXE version which has been in beta for months and which has barely attracted any comments at all. I assume that means it works. :)

Link to comment
Share on other sites

I'm asking myself every time...

Is it possible to place all the code of GUI to some banks of VBXE memory. (I think it has them.)

 

Then (Don't kill the pianist! :skull: ) rewrite code for running on VBXE processor itself, staying 6502 and it's memory almost intouch.

I think this structure gives Atari all compartibility and new usability.

 

New Last Breath I mean. :D

Link to comment
Share on other sites

I'm asking myself every time...

Is it possible to place all the code of GUI to some banks of VBXE memory. (I think it has them.)

 

At this point I assumed you were Candle in disguise...

 

Then (Don't kill the pianist! :skull: ) rewrite code for running on VBXE processor itself, staying 6502 and it's memory almost intouch.

I think this structure gives Atari all compartibility and new usability.

 

...and then I realized you're not. :)

 

In all seriousness, a VBXE version is appealing but not before the stock version is done. Those who think a VBXE GUI should be the first or only version are approaching the project, the A8... indeed the whole hobby... from a different perspective to myself and MrFish. With a 640x400 interlaced display, 256 colours, hardware blitter and 512KB of graphics RAM, it's a given that a good-looking GUI can be created. Add into the mix a 6809 or 7MHz 65816 with access to bags of linear RAM and... wait - I have an Atari ST and Amiga right here which I might as well use, and the GUIs have already been written... You get the idea. :)

 

If this were just a mechanical coding effort to reach a specific goal, I would have probably tired of it by now. But by restricting ourselves to a base configuration of 6502, 64KB base RAM, 64KB of banked memory and a 320x200 1bpp display, new challenges present themselves at every turn. All such challenges have - I think - so far been met, and there are many more to come. The pleasure is in making the hardware do things it was never intended to do, and which have not been done before.

 

On the other hand, if you want a fast, multi-colour, hi-res GUI which perhaps bests those of its 16-bit brethren... then a pimped-up machine is the way to go. But that's something for later... much later.

Edited by flashjazzcat
  • Like 7
Link to comment
Share on other sites

FJC

Do you remember that all the power of all computers which send man to the moon was only two 486?

 

I think I understand your thoughts about Atari evolution.

 

Thus I beleive in your TUI - text interface. I know that God made us to be like him.

You are almost there, but ...

 

I think that atari8 absolutely ready for being menu/mouse driving system!

I don't want beautiful win7 or Enlightenment on Atari. I hate desktop icons.

 

I speak about smth like SMIT on AIX.

It is an mouse driven breadcrumbs-like system written in Java.

(It works in console of cource but in different manner).

 

You need not even pixel control with Atari GTIA possibilities.

 

Another choice is LCARS if we needs sounds and colors.

 

Mouse pixel control is absolutely needed only in graphics programms.

The emulation of Atari touch tablet is perfectly enough for menues.

 

I even don't know Is it possible to understand me. :grin:

No mean.

 

I only wanted to say that you are much more closer to TUI/tablet driven decision than all of us with your TUI library.

 

GUI is another demo of possibilities of our beloved Atari. Nothing more.

Link to comment
Share on other sites

GUI is another demo of possibilities of our beloved Atari. Nothing more.

 

I tend to think this has been true of many GUIs written so far for the A8. The reason is less to do with graphical performance, and more to do with a total lack of quality GUI applications. The GUIs - as we've discussed elsewhere in this thread - have often been front-ends presenting a desktop metaphor, for the purpose of launching legacy applications. The technicalities of fitting large applications and memory pools into bankswitched memory have hitherto been confounding. The result is that unless the system loads quickly, gets the job done as fast as using the DOS prompt, and is something you want to see every time you boot the machine, it has only novelty value.

 

Personally I yearn for a Mac-like interface on the A8 and I intend to perform my file management tasks with the new GUI's file manager when it's done. I love desktop icons, and I can't wait to start developing applications within a GUI framework. It's a case of personal preference. I think the many people following this thread do not have unreasonable expectations, and however fast the finished system turns out to be, one will always be aware that it's running on a 1.79Mhz 8-bit machine.

 

A GUI is a visual experience as much as anything else, hence the great importance we're placing on meticulous design and presentation. Proportional fonts are NICE. The desktop in the demos is something I can live with every time I switch on the machine. But I can only repeat myself about application support: in the first instance, a quality file manager and text editor will be vital to the success of the system. We've seen file managers of varying degress of quality in other GUIs, but no "killer app" springs to mind.

 

The text-based interface is something I want to develop further, but the graphical version is ten times more exciting for me. The freedom of working outside of text cells cannot be overstated.

 

At the end of the day, people will use the system or they won't. People will develop for it, or they won't. If they don't, I'll be using it and developing for it for my own amusement, and the finished project will stand for what it is. But rest assured there will be a finished product. A demo is something which looks nice but can't be used for a practical purpose. This will be usable for pratical purposes. Make no mistake about it. I'm not in the business of writing demos for the sake of demos, and I wouldn't spend 16 months working on a project I'm not going to finish.

 

No offense taken, of course: you're entitled to your opinion just like anyone else. I know there's at least one other big player around here who shares your views. :D

  • Like 2
Link to comment
Share on other sites

I personally think what you are doing is amazing. Don't let anyone bring you down, there are plenty of backseat drivers around that will drive you crazy if you let them.

 

Seriously, you are becoming a coding legend to me. Also remember it took a small team of people a few years to develop the Mac software, and that was on more capable hardware.

 

So, what kinds of goodies are you going to show us on your next update? :D

Link to comment
Share on other sites

I personally think what you are doing is amazing. Don't let anyone bring you down, there are plenty of backseat drivers around that will drive you crazy if you let them.

 

Seriously, you are becoming a coding legend to me. Also remember it took a small team of people a few years to develop the Mac software, and that was on more capable hardware.

 

So, what kinds of goodies are you going to show us on your next update? :D

 

Thanks man! You're right about the crazy part. This project will drive me crazy on its own without extra assistance. :)

 

As for the next update: I'll make a few tweaks to what was seen in the most recent videos (mainly to do with identifying drags and double-clicks properly), and let people have a play. Reason being that - as MrFish correctly observed the other day - all roads lead to the cartridge version and I'm pretty much stuck for adding more code until that's done. And it'll take a while. ;)

 

At least the latest demo runs under DOS now and exits cleanly (it uses the RAM under the OS, as a temporary measure until we break out into extended memory).

Edited by flashjazzcat
Link to comment
Share on other sites

FJC

I'm the first who is on your side.

I said nothing to make you to stop great project .

And I beleive that you can bring it to world.

 

Above mentioned TUI is only some kind of options.

Anyway, I'm glad that you understand it's necessity.

 

This world changing every day...

May be I'm not. :D

Link to comment
Share on other sites

Seriously, you are becoming a coding legend to me.

:D

 

He is becoming a coding legend to many other people as well and eventually, will be for everybody.

 

Even before he took on this project, I watched the progress videos for The Last Word and I was dumbstruck. He has some serious programming prowress.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...