mangamuscle

<wishful thinking>So then there will be a different windows manager for VBXE but compatible with the process and file manager? or the windows manager be split into two, one with the logic and another one with the screen output routines?</wishful thinking> are there any considerations for sound writing routines in the windows manager (booting with the classical mac ping would be funny, even Wall-e does that) further down the line?

Out of curiosity, what kind of limiations does a quad-pokey implementation entails?

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

I was led to believe the stack was RAM-hungry 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. Thanks for replying

I would like to ask, in the (near?) future, if the atari ethernet cartdrige is ever completed is there a chance that this GUI gets/imports/recompiles Contiki's IP stack and utilities?

IMO this might the "killer-app" for VBXE

Thank you very much ^_^/ It compiled under Ubuntu 10.04 flawlessly.

I was wondering what are the chances that we will ever see 28 (or even 22) bit LBA ^^;

New source code works like a charm in my puppy linux install TV effects are greyed out (as it should be) since it reports openGL version 1.5 (my card is a 16 mb vanta). Just as a comment, I enabled and disabled openGL mode with no problesms, even played a bit of phoenix in fullscreen opengl (with gl vsync on) to be certain

Seems I am a bit late on my reply, did the two changes suggested but still got segmentation fault error. I a bit late because I could not find how to do a debug build (which I suppose automatically crates a core dump when crashing), there is info about how to enable the debugger (on by default) and the profiler (which for some reason would not compile on my box) but I suppose they have nothing to do with a debug compile of Stella.

I would like to happily reporta that it works, but the truth is that after recompiling 2.8.2 now when I enable opengl and restart I get a segmentation fault error >_< please let me know if there is anything I can do to squish this bug.

But that would require reading and reading is so 20th century. I vote for removing the * and the explanatory text and replace it with a dialog box that states "Enabling this option requires restarting Stella. Do you want to restart it now? (Yes) (No)"

Thank you very much

I'll look into it. I really don't see why it should be happening. Are you sure you were getting OpenGL mode in 2.7.7? I recompiled 2.7.7 and the config file says video=gl so I suppose it is using the opengl render. Maybe newer versions of Stella are using a 1024x1024 texture to map the screen while older versions used several 512x512 (or 256x256) textures that older videocards like mine support. This is simply a guess as I cannot say I am a programmer ^^;

I just compiled 2.8.1 and I tried to enable the opengl renderer but I see a "OpenGl mode Failed. Fallback to software" when I restart Stella. Sigh, I suppose it is back to 2.7.7 for me until this bug is fixed.