2102 replies to this topic

[flashjazzcat]

31336haxx0r, on Fri Apr 20, 2012 3:57 AM, said:

flashjazzcat, on Fri Apr 20, 2012 3:42 AM, said:

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...

flashjazzcat, on Thu Apr 12, 2012 2:56 PM, said:

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...

andym00, on Fri Apr 20, 2012 3:57 AM, said:

flashjazzcat, on Fri Apr 20, 2012 3:42 AM, said:

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.

[mangamuscle]

flashjazzcat, on Fri Apr 20, 2012 3:42 AM, said:

mangamuscle, on Thu Apr 19, 2012 3:26 PM, said:

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 ^^;

[Fox-1 / mnx]

flashjazzcat, on Fri Apr 20, 2012 3:42 AM, said:

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?

Edited by Fox-1 / mnx, Fri Apr 20, 2012 11:39 AM.

[flashjazzcat]

mangamuscle, on Fri Apr 20, 2012 10:26 AM, said:

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.

Fox-1 / mnx, on Fri Apr 20, 2012 11:34 AM, said:

flashjazzcat, on Fri Apr 20, 2012 3:42 AM, said:

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?

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

Edited by flashjazzcat, Fri Apr 20, 2012 12:08 PM.

[hitchcock4]

1500 posts on this topic!!

Wow - you must have hit on something big, as we all know.

-Hitchcock

[bf2k+]

Should be named "Thread of the decade!"

[dr. kwack]

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...

[Gunstar]

Apparently your 130XE will be the required minimum (128K).

Edited by Gunstar, Sun Apr 22, 2012 5:29 PM.

[dr. kwack]

Excellent. Can't wait and thanks for doing such a great project.

[fibrewire]

flashjazzcat, on Fri Apr 20, 2012 6:28 AM, said:

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....88156/pixelfari

[flashjazzcat]

fibrewire, on Sat Apr 28, 2012 3:59 PM, said:

We can only imagine...
http://mrgan.tumblr....88156/pixelfari

Nice! Shame the A8 can't manage the colour... VBXE would work, though.

[130XE]

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.

[flashjazzcat]

130XE, on Wed May 2, 2012 6:44 AM, said:

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.

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.

[130XE]

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!   ) 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.

[130XE]

A little quote.
- I am not his third wife. I'm his LAST one!

[flashjazzcat]

130XE, on Thu May 3, 2012 4:58 AM, said:

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...

Quote

Then (Don't kill the pianist!   ) 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, Mon May 7, 2012 11:11 AM.

[130XE]

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.
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.

[flashjazzcat]

130XE, on Tue May 8, 2012 9:42 PM, said:

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.

[LoTonah]

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?  

[flashjazzcat]

LoTonah, on Wed May 9, 2012 5:29 AM, said:

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?  

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, Wed May 9, 2012 5:55 AM.

[130XE]

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.

[RodCastler]

LoTonah, on Wed May 9, 2012 5:29 AM, said:

Seriously, you are becoming a coding legend to me.  

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

[Stephen]

As a new ST user, I think this GUI looks better than GEM (no proportional fonts - seriously?!?) and it seems almost as fast.

[atarixle]

When they saw my (that time brand new) BOSS-X, people asked me for the required specs of the ST/TT/Falcon-System to run that GUI ...

[LoTonah]

RodCastler, on Wed May 9, 2012 11:06 AM, said:

LoTonah, on Wed May 9, 2012 5:29 AM, said:

Seriously, you are becoming a coding legend to me.  

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.