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.

May I suggest, whichever the hidden location is, to add to the windows exe installer a shortcut to said location so even a newbie can open that folder and drag and drop any files? I think most users will not notice/mind the change then.

Have you tried 1024x768 or 720x480? Most HDTV accept that resolutions (mine does).

I seem to have made a tiny mistake, it is not: %USER%\AppData\Local\Stella instead it would be: %USERPROFILE%\Local Settings\Application Data\Stella or %APPDATA%\Stella

I'm glad to hear that gl.txt I attached my videocard info just in case it is required. if you need any more info to squish the bug please let me know

My nvidia card (with nvidia drivers) has OpenGL < 2.0 but that was not a problem with Stella 2.7.7, I could enable the OpenGL renderer in the UI no problem. Now with version 2.8 every time I enable "opengl" instead of "software" I get an error when I reopen stella, even tough I have not enabled the new TV filters (to be honest, I am not interested, the sharper the picture the better IMO) and gl_texrect = false was set from the start when the config file is created. I think it is unfair to require all users to have OpenGL 2.0 or higher, why not simply disable in the UI those features that require it? I get the following error when opening stella with video = gl: ERROR: Couldn't initialize video subsystem ERROR: Couldn't create launcher I downloaded the tar file and compiled (gcc 4.2.2) both 2.7.7 and 2.8. As a side comment, would't it be more appropriate instead of saving the config files in "MyDocuments" to save them in %USER%\AppData\Local\Stella ? Just a thought.