Atari800 2.2.0 released

[Kr0tki]

I do feel like taking a summary look at what would be involved, however I'd highly recommend using Altirra.

Anyone who publicly considers working on the WinPLus will be severely pestered to do something useful instead.

 

 

All of my tests below are done with a clean start (no .cfg file) and with -windowed, so the settings are like this: (...)

Thanks for the reports. Still I'm not able to reproduce the tiny-window bug and the fullscreen decenter bug on either of my WinXP, Win98, Win2000 and Win2003 machines (the Ctrl+C bug has been fixed). I suppose it's a Win7-specific issue, a 64-bit-specific issue, or both - which I am not able to test. Would you have the time to post the bug reports on the SourceForge bug tracker?

 

EDIT: The latest test version.

Edited April 10, 2011 by Kr0tki

[phaeron]

I do feel like taking a summary look at what would be involved, however I'd highly recommend using Altirra.

Anyone who publicly considers working on the WinPLus will be severely pestered to do something useful instead.

 

Err... can I ask why? As a Windows user, I prefer the WinPLus interface a lot more than the Atari800 interface, and judging from the other posts in this thread, I'm not the only one. I can understand why people working on the core wouldn't want to deal with Windows-specific platform code, but what would be wrong with someone bringing the GUI up to date?

 

All of my tests below are done with a clean start (no .cfg file) and with -windowed, so the settings are like this: (...)

Thanks for the reports. Still I'm not able to reproduce the tiny-window bug and the fullscreen decenter bug on either of my WinXP, Win98, Win2000 and Win2003 machines (the Ctrl+C bug has been fixed). I suppose it's a Win7-specific issue, a 64-bit-specific issue, or both - which I am not able to test. Would you have the time to post the bug reports on the SourceForge bug tracker?

 

EDIT: The latest test version.

 

Alright, I'll throw them up on the bug tracker... even though you guys still haven't fixed 5200 Pengo.

 

I did some more testing, and so far, I've only been able to reproduce the tiny window issue on Windows 7 x64 and Vista x86, not XP.

 

However, there's a serious regression in this build: resizing in OpenGL mode is now almost a 100% crash on Vista x86 and Win7 x64. This was not happening with the previous test build. Info in the debugger suggests that the problem is caused by Atari800 trying to call through old OpenGL entry points after opengl32.dll has been unloaded and reloaded, causing a crash if the DLL relocates. I'm guessing that Address Space Layout Randomization (ASLR) is what's making this bug manifest so frequently on Vista and Windows 7.

[Kr0tki]

Err... can I ask why?

For two reasons:

1. Altirra, I believe, seems to cover the Widows GUI front quite adequately,

2. The Atari800 project suffers from lack of developers. So if anyone wanted to sacrifice their time for the WinPLus, It would be more beneficial to the project if that person considered starting work on a cross-platform GUI instead.

 

Alright, I'll throw them up on the bug tracker... even though you guys still haven't fixed 5200 Pengo.

We are thankful, nevertheless

 

Also thanks for the new report. It might be caused by ASLR, if your OpenGL DLL supports it (the emulator itself doesn't). I'll look into it.

[Heaven/TQA]

what about latest Mac OS X port?

[flashjazzcat]

I would love to see the H: device implemented at the SIO level. I believe the implementation would be something similar to what's used by APE when mirroring PC folders. I know I've harped on about this before, but SDX will never be able to access H: from the command prompt, since H: is universally implemented at the CIO level and the SDX CP doesn't use the CIO. I'm about this far from writing a couple of SDX apps: one to copy files to and from H: at the CP, and another to binary load a file from H: (both resorting to CIO calls and SDX kernel device name translation). I know Drac030 had plans to make SIO2BSD interface with emulators to allow access to virtual folders via a separate SDX device handler, but surely this is a rather distant prospect at best.

[phaeron]

I would love to see the H: device implemented at the SIO level. I believe the implementation would be something similar to what's used by APE when mirroring PC folders. I know I've harped on about this before, but SDX will never be able to access H: from the command prompt, since H: is universally implemented at the CIO level and the SDX CP doesn't use the CIO. I'm about this far from writing a couple of SDX apps: one to copy files to and from H: at the CP, and another to binary load a file from H: (both resorting to CIO calls and SDX kernel device name translation). I know Drac030 had plans to make SIO2BSD interface with emulators to allow access to virtual folders via a separate SDX device handler, but surely this is a rather distant prospect at best.

 

I took a look at this, and it turns out that PCLINK.SYS is already shipping on the toolkit disk, and I can see it translating filesystem calls into SIO requests. With the /S flag it even invokes SIOV and thus emulator SIO hooks. I don't know what the Atari800 H: handler code looks like, but it may be easier to implement an SIO side to H: than implement an incrementally updating SDX filesystem. The protocol doesn't seem to be documented, though.

 

This does make me wonder if it isn't possible just to write an SDX driver that talks to CIO devices. That would work on all emulators that support H:.

[Kr0tki]

Hey phaeron, I've recently tested Atari800 on a Win7/64 machine, and guess what, I couldn't reproduce neither the "tiny window" bug, nor the "maximise decenter" bug, not even the "resize crash". Nevertheless I think I've found the reason for the crash, so here goes another test build.

 

In this version I switched from using the DirectX SDL backend to Windib. the DX backend was responsible for some of the previously-mentioned glitches (capturing the mouse etc.) and I suspect that it could also be the cause of the "tiny window" and "maximise decenter" bugs. Phaeron, could you check it out?

Edited April 13, 2011 by Kr0tki

[phaeron]

Hey phaeron, I've recently tested Atari800 on a Win7/64 machine, and guess what, I couldn't reproduce neither the "tiny window" bug, nor the "maximise decenter" bug, not even the "resize crash". Nevertheless I think I've found the reason for the crash, so here goes another test build.

 

In this version I switched from using the DirectX SDL backend to Windib. the DX backend was responsible for some of the previously-mentioned glitches (capturing the mouse etc.) and I suspect that it could also be the cause of the "tiny window" and "maximise decenter" bugs. Phaeron, could you check it out?

 

Fixed for capturing the mouse. Fix failed for tiny window and maximize decenter bugs. Looks like fixed for the GL resize crash so far, although repro rate varies.

 

I hacked the build scripts enough to get a debug build of Atari800 2.2.0 under VS2005. (Makefiles... bleah!) From what I can tell, the tiny window problem is coming from the Win32 window procedure in SDL, which has this bizarro section for the WM_GETMINMAXINFO handler:

 

		/* Calculate current width and height of our window */
		size.top = 0;
		size.left = 0;
		if ( SDL_PublicSurface != NULL ) {
			size.bottom = SDL_PublicSurface->h;
			size.right = SDL_PublicSurface->w;
		} else {
			size.bottom = 0;
			size.right = 0;
		}

 

What seems to be happening is that this is getting called in the middle of a video mode change:

 

	SDL.dll!WinMessage(HWND__ * hwnd=0x00030894, unsigned int msg=36, unsigned int wParam=0, long lParam=1634960)  Line 558	C
	user32.dll!_InternalCallWinProc@20()  + 0x23 bytes	
	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes	
	user32.dll!_DispatchClientMessage@24()  + 0x51 bytes	
	user32.dll!___fnINOUTLPPOINT5@4()  + 0x2e bytes	
	ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e bytes	
	user32.dll!_NtUserMessageCall@28()  + 0x15 bytes	
	user32.dll!_RealDefWindowProcWorker@24()  + 0xace bytes	
	user32.dll!_RealDefWindowProcA@16()  + 0x2a bytes	
	user32.dll!_DefWindowProcA@16()  + 0x50 bytes	
	SDL.dll!DX5_HandleMessage(SDL_VideoDevice * this=0x02210a40, HWND__ * hwnd=0x00030894, unsigned int msg=274, unsigned int wParam=61448, long lParam=19071594)  Line 640	C
	SDL.dll!WinMessage(HWND__ * hwnd=0x00030894, unsigned int msg=274, unsigned int wParam=61448, long lParam=19071594)  Line 699 + 0x1d bytes	C
	user32.dll!_InternalCallWinProc@20()  + 0x23 bytes	
	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes	
	user32.dll!_DispatchClientMessage@24()  + 0x51 bytes	
	user32.dll!___fnDWORD@4()  + 0x2b bytes	
	ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e bytes	
	user32.dll!_NtUserMessageCall@28()  + 0x15 bytes	
	user32.dll!_RealDefWindowProcWorker@24()  + 0xace bytes	
	user32.dll!_RealDefWindowProcA@16()  + 0x2a bytes	
	user32.dll!_DefWindowProcA@16()  + 0x50 bytes	
	SDL.dll!DX5_HandleMessage(SDL_VideoDevice * this=0x02210a40, HWND__ * hwnd=0x00030894, unsigned int msg=161, unsigned int wParam=17, long lParam=19071594)  Line 640	C
	SDL.dll!WinMessage(HWND__ * hwnd=0x00030894, unsigned int msg=161, unsigned int wParam=17, long lParam=19071594)  Line 699 + 0x1d bytes	C
	user32.dll!_InternalCallWinProc@20()  + 0x23 bytes	
	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes	
	user32.dll!_DispatchMessageWorker@8()  + 0xed bytes	
	user32.dll!_DispatchMessageA@4()  + 0xf bytes	
	SDL.dll!WIN_FlushMessageQueue()  Line 148	C
>	SDL.dll!DX5_SetVideoMode(SDL_VideoDevice * this=0x02210a40, SDL_Surface * current=0x022136c0, int width=328, int height=136, int bpp=32, unsigned int flags=16)  Line 1654	C
	SDL.dll!SDL_SetVideoMode(int width=320, int height=109, int bpp=32, unsigned int flags=16)  Line 675 + 0x20 bytes	C
	atari800.exe!SetVideoMode(int w=320, int h=109, int bpp=32)  Line 129 + 0x15 bytes	C
	atari800.exe!SDL_VIDEO_SW_SetVideoMode(const VIDEOMODE_resolution_t * res=0x0018fe64, int windowed=1, VIDEOMODE_MODE_t mode=VIDEOMODE_MODE_NORMAL, int rotate90=0)  Line 179 + 0x18 bytes	C
	atari800.exe!PLATFORM_SetVideoMode(const VIDEOMODE_resolution_t * res=0x0018fe64, int windowed=1, VIDEOMODE_MODE_t mode=VIDEOMODE_MODE_NORMAL, int rotate90=0, int window_resized=1)  Line 83 + 0x15 bytes	C
	atari800.exe!SetVideoMode(VIDEOMODE_resolution_t * res=0x0018fe64, VIDEOMODE_MODE_t display_mode=VIDEOMODE_MODE_NORMAL, unsigned int out_w=320, unsigned int out_h=109, int windowed=1, int rotate=0, int window_resized=1)  Line 502 + 0x19 bytes	C
	atari800.exe!UpdateVideoWindowed(int window_resized=1)  Line 567 + 0x1f bytes	C
	atari800.exe!VIDEOMODE_SetWindowSize(unsigned int width=320, unsigned int height=109)  Line 584 + 0x7 bytes	C
	atari800.exe!PLATFORM_Keyboard()  Line 266 + 0x13 bytes	C
	atari800.exe!SDL_main(int argc=1, char * * argv=0x003a1b50)  Line 158 + 0x5 bytes	C
	atari800.exe!main(int argc=2, char * * argv=0x003a1b50)  Line 315 + 0xd bytes	C
	atari800.exe!__tmainCRTStartup()  Line 327 + 0x19 bytes	C
	atari800.exe!mainCRTStartup()  Line 196	C
	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

 

Because the SDL public surface hasn't been recreated yet, the code above tells Windows that the window has a maximum size of 0x0, which is pretty bogus. This is happening off of an internal SDL operation, though, so I'm not sure you can work around it.

[Wrathchild]

Err... can I ask why?

For two reasons:

1. Altirra, I believe, seems to cover the Widows GUI front quite adequately,

2. The Atari800 project suffers from lack of developers. So if anyone wanted to sacrifice their time for the WinPLus, It would be more beneficial to the project if that person considered starting work on a cross-platform GUI instead.

Haven't had much opportunity this week, but at the end of last week I did try re-compiling my 4.0 sources under VS2010 and despite a few simple warnings the only main issue seems to be with some DirectX supported libraries not being available anymore, so some reworking needed there or it might make sense to stick with having it use SDL?

 

The cross-platform bit is definitely a minefield considering the ports Atari800 has, i.e. Android etc, touch screen support on multiple platforms. I guess on mobile devices a more native implementation is still required for performance and so going down a Silverlight re-write path would no longer make it Atari800?

[flashjazzcat]

I would love to see the H: device implemented at the SIO level. I believe the implementation would be something similar to what's used by APE when mirroring PC folders. I know I've harped on about this before, but SDX will never be able to access H: from the command prompt, since H: is universally implemented at the CIO level and the SDX CP doesn't use the CIO. I'm about this far from writing a couple of SDX apps: one to copy files to and from H: at the CP, and another to binary load a file from H: (both resorting to CIO calls and SDX kernel device name translation). I know Drac030 had plans to make SIO2BSD interface with emulators to allow access to virtual folders via a separate SDX device handler, but surely this is a rather distant prospect at best.

 

I took a look at this, and it turns out that PCLINK.SYS is already shipping on the toolkit disk, and I can see it translating filesystem calls into SIO requests. With the /S flag it even invokes SIOV and thus emulator SIO hooks. I don't know what the Atari800 H: handler code looks like, but it may be easier to implement an SIO side to H: than implement an incrementally updating SDX filesystem. The protocol doesn't seem to be documented, though.

 

This does make me wonder if it isn't possible just to write an SDX driver that talks to CIO devices. That would work on all emulators that support H:.

Well, that distant prospect could be closer than I thought. Writing an SDX driver which could talk to H: was the first thing I considered, but I'm not sure what the kernel's internal handler function table looks like. I assume kernel devices have OPEN, PUT, etc, and one might hope they could be patched into H:'s handler table, but then again the returning mechanisms, etc, might be different. I'll quiz Draco about that.

 

The advantage to the kernel driver approach is that it would require no mods to existing emulators.

[+therealbountybob]

Took a quick look at this emulator on a friends' PC yesterday

 

Does it support the ppjoy driver for the parallel port joystick if not can it be added to the todo list

 

On my laptop (WXP) I cannot get the keyboard keys to work as the joystick, they map ok in the setup

[Kylev]

therealbountybob,

 

I am running windows 7 with this version of the emulator and once I used the controller configuration menu to tell the emulator what keys were which directions, I was able to successfully play Spy Hunter. So I guess you might have a configuration issue.

 

I set mine up to use the numeric keypad. Numbers 4,5,6, and 8 with each key being the logical direction. Right cntrl key is used for the trigger on joystick #1. Each of these settings can be made using the controller configuration menu, then choosing the "define configuration of keyboard joystick #1" option. Simply highlight the option and then press enter. Another screen will open asking for the keys to use to set the various directions and the trigger.

 

I did not test the diagonal responsiveness of this configuration. Hope this helps.

 

Russ

[+therealbountybob]

Thanks Russ, the keys did map ok (and saved) but no responses in any game. I'm running on Windows XP.

[Kylev]

therealbountybob,

 

Sorry I wasn't able to help. Hopefully someone else who is running with your OS can be of further assistance.

 

Russ

[Kr0tki]

I hacked the build scripts enough to get a debug build of Atari800 2.2.0 under VS2005. (Makefiles... bleah!) From what I can tell, the tiny window problem is coming from the Win32 window procedure in SDL, which has this bizarro section for the WM_GETMINMAXINFO handler: (...)

Thanks phaeron. Now I think I know what's the possible cause for the problem appearing only on Win7 (although I still can't reproduce it). In Win7 there's this new feature that when you double-click a window's bottom border, the window's height gets maximised. I'm suspecting that it sometimes causes to send two "resize" events to SDL so fast that the second one comes at a moment the public surface is not yet recreated.

 

To test the hypothesis, I've prepared a new test executable which causes each window resize request to be delayed a bit. By default the delay is 50 frames, but it can be adjusted by the "-resizedelay <number>" parameter (0 disables resizing completely). Hopefully it'll be a good workaround.

 

Haven't had much opportunity this week, but at the end of last week I did try re-compiling my 4.0 sources under VS2010 and despite a few simple warnings the only main issue seems to be with some DirectX supported libraries not being available anymore, so some reworking needed there or it might make sense to stick with having it use SDL?

I'd say get an older version of the DirectX SDK - the August 2007 one is the last one that includes DirectInput.

 

The cross-platform bit is definitely a minefield considering the ports Atari800 has, i.e. Android etc, touch screen support on multiple platforms. I guess on mobile devices a more native implementation is still required for performance and so going down a Silverlight re-write path would no longer make it Atari800?

No, not a problem with accepting such solution, as long as the number of features implemented as native-platform-exclusives is kept at a minimum.

 

The issues with WinPLus are that it was developed in a really messy way (because it was a completely external project) - the Atari800 kernel is now littered with "#ifdef __PLUS" conditionally-compiled code, which makes it difficult to maintain. In recent years, during the development of Atari800 2.0.0, some of this conditional code was wiped out.

 

Also, a lot of the WinPLus code is various enhancements which are made Windows-specific for absolutely no reason. These features include: turbo mode, adjusting the size of the audio buffer and audio quality settings, support for digitised POKEY sounds, scanlines, keyboard mapping, and various other little things. Only recently some of these features were added back to the main kernel, and actually had to be rewritten in order to support multiple platforms.

 

To sum it up, developing WinPLus further would need some significant rewriting (moving the Windows-specific features back to kernel, using the new kernel-built features instead of Windows-specific code) - I believe a few parts would have to be written from scratch. If that's the case, why don't really start from scratch and make the GUI cross-platform?

 

Does it support the ppjoy driver for the parallel port joystick if not can it be added to the todo list

Does PPJoy support DirectInput? (well it should ) From what I understand, it can be configured to map joystick events to keyboard presses, so it could work that way. Since it's Windows-specific I won't support adding it to the TODO.

 

On my laptop (WXP) I cannot get the keyboard keys to work as the joystick, they map ok in the setup

We're talking about the SDL version, right? Kinda strange. Does the emulator properly emulate keyboard and console keys? Would you save the configuration after mapping the joysticks, and send the .atari800.cfg file?

Edited April 21, 2011 by Kr0tki

[+therealbountybob]

Unfortunately ppjoy is no longer supported, but it's nice to use a regular atari josytick on the PC... the console keys work fine, here's the .cfg file (renamed .txt), SDL version

Copy of .atari800.cfg.txt

[Kr0tki]

Ah, now I get it.

 

When you have a real DirectInput joystick connected to the PC, Atari800 uses that joystick instead of the keyboard mapping. The only way to use the keyboard mapping in such situation is to run the emulator with the "-nojoystick" parameter.

 

If that DirectInput joystick that Atari800 detects is your PPJoy device, it's probably gonna work with the emu.

 

It seems that PPJoy is still supported, but its (other) website is not updated anymore.

Edited April 21, 2011 by Kr0tki

[+therealbountybob]

Ah, now I get it.

 

When you have a real DirectInput joystick connected to the PC, Atari800 uses that joystick instead of the keyboard mapping. The only way to use the keyboard mapping in such situation is to run the emulator with the "-nojoystick" parameter.

 

If that DirectInput joystick that Atari800 detects is your PPJoy device, it's probably gonna work with the emu.

 

It seems that PPJoy is still supported, but its (other) website is not updated anymore.

Ahh, I didn't actually try it with the joystick connected ... will report back

[Kr0tki]

The joystick issue has been fixed. In the next release the user will not have to add "-nojoystick" to make things work.

[phaeron]

To test the hypothesis, I've prepared a new test executable which causes each window resize request to be delayed a bit. By default the delay is 50 frames, but it can be adjusted by the "-resizedelay <number>" parameter (0 disables resizing completely). Hopefully it'll be a good workaround.

 

Can't repro with this build, so I'm going to call the tiny window bug fixed.

 

Haven't had much opportunity this week, but at the end of last week I did try re-compiling my 4.0 sources under VS2010 and despite a few simple warnings the only main issue seems to be with some DirectX supported libraries not being available anymore, so some reworking needed there or it might make sense to stick with having it use SDL?

I'd say get an older version of the DirectX SDK - the August 2007 one is the last one that includes DirectInput.

 

I think the problem is with the version of the DirectInput API it's trying to use -- the code doesn't appear to have been ported to DirectInput 8, which <dinput.h> defaults to. I turned off DirectInput support to get it to build, but #define DIRECTINPUT_VERSION 0x0300 or 0x0500 might work. I'd recommend porting or removing that code as DirectInput 5 is pretty old....

[Kr0tki]

Can't repro with this build, so I'm going to call the tiny window bug fixed.

 

Great! Thanks! I'm assuming that the "maximise-decenter" bug is still there, is that right?

[Wrathchild]

I did try going to DirectInput8 but gave up in favour of reverting to the DirectX Summer 2004 Update SDK.

 

Have corrected pretty much all of the variable name re-mappings resulting from the Atari800 2.x update. Only a few more things to correct before I can try a 'link', mostly around the moving of 'rdevice' from PLUS's Core_c into the Atari800 sources. After that I imagine they'll be some fun and games with DirectDraw stuff.

 

Of course this will only produce the same WinPLus skin to Atari800 and there is a lot more under the hood now that should be exposed. As pointed out earlier, assistance with the UI approach in the Atari800 sources would be better but at least this lets me familarize myself with things.

 

Seeing as the current Atari800 has a menu already perhaps this should simply be expanded upon to provide the WinPLus style menus and dialogs? However would this involve switching on MFC and that in itself causes the pain?

 

Regards,

Mark

[+therealbountybob]

The joystick issue has been fixed. In the next release the user will not have to add "-nojoystick" to make things work.

Thats thanks, it worked ok with the joystick attached. Another thing I noticed is when saving a screenshot you have to add the .png to the filename or it "cant save". Also would prefer the console keys to be start F2, select F3 and option F4 the same as atari800win+4.0 & atlirra

[phaeron]

Can't repro with this build, so I'm going to call the tiny window bug fixed.

 

Great! Thanks! I'm assuming that the "maximise-decenter" bug is still there, is that right?

 

Yes, I can still repro that one.

[oesii]

Just updated Atari800, the best A8 emulator for Android phones/tablets, to version 1.2.

It is a port of Atari800 v. 2.2.0.

 

Thanks for this. Works great on my Nexus One. Also installed the Wiimote and classic controller support for this

 

Is anyone aware of any ports of Atari800 being developed for iOS devices like the iPad/iPhone? I have my iPad jailbroken and have been using Mame and NES emulators with the Wiimote for awhile now but I haven't seen any Atari 800 emulators out there. A few people have installed the dos versions of XFormer or A800 in DosBox but there got to be a better way.