hatari-users — Hatari mailing list for normal users

[hatari-users] Is this still alive

[Jesus C. <jc...@jc...>]

Ping ping

-- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jc...@jc... - https://www.jcea.es/    _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jc...@ja...  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

Re: [hatari-users] Known issues with Mac OS X 10.6.2?

[Anders E. <ae...@dh...>]

On Wed, 13 Jan 2010, Götz Hoffart wrote:

> Are you using a GEMDOS drive? Or a drive container/image?
>
> My other settings:
> - 640x400 (non-extended VDI)
> - slower but more compatible CPU
> - ST
> - TOS 2.06de
> - 4 MB RAM
> - 68000, "32 MHz"


Here is my configuration file:

http://ae.dhs.nu/tmp/hatari.cfg.txt

--
Anders Eriksson
ae...@dh...     http://www.dhs.nu/
ae...@at...  http://www.atari.org/

Re: [hatari-users] Known issues with Mac OS X 10.6.2?

[Götz H. <go...@ho...>]

Am 13.01.2010 um 10:44 schrieb Anders Eriksson:

>> I'm using Hatari on a Core Duo MacBook, therefore 32 Bit kernel.
> 
> Macbook Pro (old case), C2D 2.2 GHz 4GB ram, GF8600
> Macbook Pro (uni case), C2D 2.4 GHz 4GB ram, GF9600
> 
> Both run OS X 10.6.2 with 32-bit kernel.

Are you using a GEMDOS drive? Or a drive container/image?

My other settings:
- 640x400 (non-extended VDI)
- slower but more compatible CPU
- ST
- TOS 2.06de
- 4 MB RAM
- 68000, "32 MHz"

Regards
Götz

Re: [hatari-users] Known issues with Mac OS X 10.6.2?

[Anders E. <ae...@dh...>]

On Wed, 13 Jan 2010, Götz Hoffart wrote:

>> I run Hatari on 10.6.x and have not had any issues like this.
> Which CPU? Which kernel mode?
> I'm using Hatari on a Core Duo MacBook, therefore 32 Bit kernel.

Macbook Pro (old case), C2D 2.2 GHz 4GB ram, GF8600
Macbook Pro (uni case), C2D 2.4 GHz 4GB ram, GF9600

Both run OS X 10.6.2 with 32-bit kernel.

--
Anders Eriksson
ae...@dh...     http://www.dhs.nu/
ae...@at...  http://www.atari.org/

Re: [hatari-users] Known issues with Mac OS X 10.6.2?

[Götz H. <go...@ho...>]

Am 13.01.2010 um 07:31 schrieb Anders Eriksson:

> I run Hatari on 10.6.x and have not had any issues like this.

Which CPU? Which kernel mode?

I'm using Hatari on a Core Duo MacBook, therefore 32 Bit kernel.

Regards
Götz

Re: [hatari-users] Known issues with Mac OS X 10.6.2?

[Anders E. <ae...@dh...>]

On Wed, 13 Jan 2010, Thomas Huth wrote:

> All I can say is that Hatari does not seem to work very well with OS X
> 10.6, see also this thread here:
> Seems like Apple changed some stuff in their operating system that
> causes Hatari to behave strange.
> Unfortunately there also seems to be no OS X Hatari developer around
> who has 10.6 and is able to fix these issues, so OS 10.6 is currently
> unsupported.

Hi,

I run Hatari on 10.6.x and have not had any issues like this. I'm using it 
daily for coding ST/STe/Falcon programs and it works just as well as it 
did with 10.5. 2.06 in ST/e-mode is no problem either, both with the HG 
and release version (1.3.1).

--
Anders Eriksson
ae...@dh...     http://www.dhs.nu/
ae...@at...  http://www.atari.org/

Re: [hatari-users] Known issues with Mac OS X 10.6.2?

[Thomas H. <th...@gm...>]

On Tue, 12 Jan 2010 22:54:02 +0100
Götz Hoffart <go...@ho...> wrote:

> Hi,
> 
> are there any known issues running Hatari* on Mac OS X 10.6.2?
> 
> I have problems getting it running stable. TOS 2.06 (ST) doesn't run
> at all ("Fensterspeicher konnte nicht angelegt werden" kurz vor dem
> Desktop), TOS 1.04 (ST) and 1.06 (STE) unstable: crashes in normally
> reliable programmes (two, three, four bombs), then an automated reset
> -- then the Desktop reappears but with a different position of my
> icons and hard disk 'C' (a GEMDOS drive) is empty.
> 
> Any hints?

 Hi!

All I can say is that Hatari does not seem to work very well with OS X
10.6, see also this thread here:

 http://forum.atari-home.de/index.php?topic=6484.0

Seems like Apple changed some stuff in their operating system that
causes Hatari to behave strange.
Unfortunately there also seems to be no OS X Hatari developer around
who has 10.6 and is able to fix these issues, so OS 10.6 is currently
unsupported.

 Thomas

[hatari-users] Known issues with Mac OS X 10.6.2?

[Götz H. <go...@ho...>]

Hi,

are there any known issues running Hatari* on Mac OS X 10.6.2?

I have problems getting it running stable. TOS 2.06 (ST) doesn't run at all ("Fensterspeicher konnte nicht angelegt werden" kurz vor dem Desktop), TOS 1.04 (ST) and 1.06 (STE) unstable: crashes in normally reliable programmes (two, three, four bombs), then an automated reset -- then the Desktop reappears but with a different position of my icons and hard disk 'C' (a GEMDOS drive) is empty.

Any hints?

[*] I tried 1.3.1 and 1.2.0

Regards
Götz

Re: [hatari-users] Project moved to hatari.berlios.de

[Thomas H. <th...@gm...>]

On Sat, 20 Dec 2008 11:38:50 +0100 (CET)
npo...@co... wrote:

> do you know if there could be a possibility to import the archived
> mails from sourceforge to the new berlios lists ? There were some
> interesting infos and it could be useful to have them in a central
> place (even if I think they won't be removed by SF)

As far as I can see, there is no possibility to migrate the mail
archives.

 Thomas

Re: [hatari-users] [hatari-devel] Project moved to hatari.berlios.de

[<npo...@co...>]

On Sat, 20 Dec 2008, Thomas Huth wrote:

>
> Hello everybody!
>
> As some might already have noticed, I've moved the Hatari project from
> SourceForge.net to BerliOS.de, so that we can use a moderne distributed
> versioning control system like Mercurial instead of the old CVS.
>
> I've also created new mailing lists there, to keep everything at one
> place. That means that the mailing lists at Sourceforge here are now
> obsolete - I'll shut them down in a couple of weeks.
> So please visit the following page and register with the new mailing
> lists:
>
> http://developer.berlios.de/mail/?group_id=10436
>
> Thanks!
>
>  Thomas

Hello,

do you know if there could be a possibility to import the archived mails 
from sourceforge to the new berlios lists ? There were some interesting 
infos and it could be useful to have them in a central place (even if I 
think they won't be removed by SF)


Nicolas

[hatari-users] Project moved to hatari.berlios.de

[Thomas H. <th...@gm...>]

 Hello everybody!

As some might already have noticed, I've moved the Hatari project from
SourceForge.net to BerliOS.de, so that we can use a moderne distributed
versioning control system like Mercurial instead of the old CVS.

I've also created new mailing lists there, to keep everything at one
place. That means that the mailing lists at Sourceforge here are now
obsolete - I'll shut them down in a couple of weeks.
So please visit the following page and register with the new mailing
lists:

 http://developer.berlios.de/mail/?group_id=10436

Thanks!

  Thomas

Re: [hatari-users] [hatari-devel] Hatari version 1.1.0 released

[<npo...@co...>]

On Sat, 29 Nov 2008, Thomas H. wrote:

> Hatari version 1.1.0 has been released.
>
> Emulation changes:
> - Falcon DSP emulation good enough to improve some few games/demos, e.g.
>  Virtual City. (most still work better with emulation disabled, though)
> - New sound engine that fixes all problems with the old one
> - 16-bit stereo sound (instead of 8-bit mono)
> - Improved blitter emulation (blitter cycles emulation, blitter interrupt)
> - Improved STE support for some video registers (hscroll, linewidth, ...)
> - Improved printer emulation
> - Improved STE microwire emulation
> - Improved support for games & demos which are accessing IKBD directly
>  (including a fake 6301 emulation for the known IKBD programs)
> - ACSI emulation fix to get HDDriver working
> - Some other minor bugfixes to ST/STe emulation (FDC, MFP, PSG, RS-232)
> - Improved MFP emulation
> - Improved 68k emulation (move.b Ax,(Ay) and extb.l)
> - Fixed bugs in the GEMDOS HD emulation (Pexec() etc.)
>
> General emulator changes:
> - Statusbar and overlay led features
> - Screenshots work also in VDI/TT/Falcon mode and are saved as PNGs
> - Support for automatic frameskip and pausing emulation
> - Support for embedding Hatari window (on X11) and control socket
> - Improved memory snapshot function
> - Improved the "trace" debug function


Good news, great work !

I noticed on http://sourceforge.net/forum/forum.php?forum_id=892540 that 
the text doesn't have any line return (as in your above description). 
Perhaps this could be corrected ?

Do you want me to post a news on pouet.net (certainly a lot of people 
interested in emulation over there) ?

Well, I guess cvs is open for new commit now ? :)

Nicolas

[hatari-users] Hatari version 1.1.0 released

[Thomas H. <th...@gm...>]

Hatari version 1.1.0 has been released.

Emulation changes:
- Falcon DSP emulation good enough to improve some few games/demos, e.g.
  Virtual City. (most still work better with emulation disabled, though)
- New sound engine that fixes all problems with the old one
- 16-bit stereo sound (instead of 8-bit mono)
- Improved blitter emulation (blitter cycles emulation, blitter interrupt)
- Improved STE support for some video registers (hscroll, linewidth, ...)
- Improved printer emulation
- Improved STE microwire emulation
- Improved support for games & demos which are accessing IKBD directly
  (including a fake 6301 emulation for the known IKBD programs)
- ACSI emulation fix to get HDDriver working
- Some other minor bugfixes to ST/STe emulation (FDC, MFP, PSG, RS-232)
- Improved MFP emulation
- Improved 68k emulation (move.b Ax,(Ay) and extb.l)
- Fixed bugs in the GEMDOS HD emulation (Pexec() etc.)

General emulator changes:
- Statusbar and overlay led features
- Screenshots work also in VDI/TT/Falcon mode and are saved as PNGs
- Support for automatic frameskip and pausing emulation
- Support for embedding Hatari window (on X11) and control socket
- Improved memory snapshot function
- Improved the "trace" debug function

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

[hatari-users] Release critical bugs?

[Thomas H. <th...@gm...>]

 Hi everybody!

I am planing to do a new public release of Hatari soon. So if you use
the CVS version, please update to the current state and check whether
there are any release critical bugs left that should be fixed before
the release!

 Thanks,
  Thomas

Re: [hatari-users] OSX performance issue

[O. M. F. <den...@gm...>]

2008/10/27 Oisín Mac Fhearaí <den...@gm...>:
> So it seems the CVS service is down...?

Ooops, looks like Peerguardian (which I installed and forgot about
like a year ago) was blocking (some) access to sourceforge CVS, for no
obvious reason. Got the source now.

Oisín

Re: [hatari-users] OSX performance issue

[O. M. F. <den...@gm...>]

2008/10/26 Eero Tamminen <oa...@he...>:
>> Maybe I'll try QuickST or some other benchmark program in windowed and
>> fullscreen modes.
>
> It measures the emulated system speed (which doesn't change regardless
> of how fast Hatari can run it), not the speed of Hatari.

I figured that I could just set Hatari to have no speed throttle and
run the tests in QuickIndex (not QuickST...), then the scores would be
higher for the method with the least CPU/memory bandwidth/GPU
overhead.

>> Will try to pull from CVS and use auto-frameskip.
>
> When you build it, please make sure that optimizations are enabled (-O2).

Good point - I neglected to check last time. However, I can't pull
from CVS at the moment:

[cvs login]
Logging in to :pserver:ano...@ha...:2401/cvsroot/hatari
CVS password:
cvs [login aborted]: connect to
hatari.cvs.sourceforge.net(216.34.181.108):2401 failed: Connection
refused

[nmap]
Interesting ports on cvs1.sourceforge.net (216.34.181.108):
Not shown: 998 closed ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

So it seems the CVS service is down...?

thanks,
Oisín

Re: [hatari-users] OSX performance issue

[Eero T. <oa...@he...>]

Hi,

On Sunday 26 October 2008, Oisín Mac Fhearaí wrote:
> > Recent build means CVS HEAD?  In which version of Hatari this was
> > better?
>
> Yeah, I think I got it from CVS, unless there was a source tarball. It
> reports itself as v1.0.1. The previous version I'd been using was
> 0.9.5 from apparently May 2007.

Hatari emulation has been improved significantly between those versions.
This means that it uses more CPU for the emulation (difference is even
larger to something like v0.50).


[...]
> Maybe I'll try QuickST or some other benchmark program in windowed and
> fullscreen modes.

It measures the emulated system speed (which doesn't change regardless
of how fast Hatari can run it), not the speed of Hatari.


[...]
> Will try to pull from CVS and use auto-frameskip.

When you build it, please make sure that optimizations are enabled (-O2).

The OSX (SDL) clock may be less accurate than on Linux.  If this is
the case, auto-frameskip may be less useful, but let us know how it works!


	- Eero

Re: [hatari-users] OSX performance issue

[O. M. F. <den...@gm...>]

2008/10/21 Eero Tamminen <oa...@he...>:
> Recent build means CVS HEAD?  In which version of Hatari this was better?

Yeah, I think I got it from CVS, unless there was a source tarball. It
reports itself as v1.0.1. The previous version I'd been using was
0.9.5 from apparently May 2007.

> With Hatari in ST mode?  In fullscreen or non-fullscreen?
>
> Was Statusbar or Overlay disk access led enabled?

ST mode and STe mode, but perhaps I was running in windowed mode
which, now that I think of it, is probably much slower than
fullscreen!
I used to usually run 0.9.5 in fullscreen mode, so this may explain
the perceived differences. Not running with status bar / overlay LED
though.
Maybe I'll try QuickST or some other benchmark program in windowed and
fullscreen modes.

> What if you select "Auto" as the frameskip option in Hatari display options?

Hmm. There is no such option, so perhaps I've been using a slightly
outdated source tarball?

> Was Hatari using ~100% CPU when your MacBook was otherwise idle?

I didn't check when the problem occurred - currently it's using about
17.5% CPU idling on the GEM desktop, although Opera is swallowing
about 8% CPU on this machine so that may not be a great measurement.

Will try to pull from CVS and use auto-frameskip.

thanks!
Oisín

Re: [hatari-users] Performance on Mac OS X (was: Media change bug)

[Eero T. <oa...@he...>]

Hi,

On Sunday 26 October 2008, Thomas Huth wrote:
> I just checked the source code and as far as I can see, Hatari only uses
> SDL_UpdateRect() once per VBL (unless you enable the new Statusbar
> which might require some additional UpdateRects).

Statusbar does SDL_UpdateRect() only when a led, frameskip or rec state,
or message changes, and these should happen much more rarely than
VBL (and it happens at most once a VBL).

The overlay led which can be used only when the Statusbar is disabled, adds
a single additional SDL_UpdateRect() call per VBL (preceeded with two
minuscule blits and fills), but that happens only when the Led is shown.

This can be checked by enabling DEBUG in statusbar.c.

IMHO everybody should just use the new automatic frameskip and make sure
Hatari is compiled with proper optimizations.


	- Eero

Re: [hatari-users] Performance on Mac OS X (was: Media change bug)

[Thomas H. <th...@gm...>]

On Tue, 21 Oct 2008 15:13:55 +0200 (CEST)
Anders Eriksson <ae...@dh...> wrote:
 
> I quote:
> 
> "Ok, here's the deal: under macosx SDL_UpdateRect() automatically
> waits for vblank so calling it for each pixels drawn isn't a good
> idea at all. What i did is to remove all those updates calls for
> macosx and just use one in Get_Input()."
> 
> This is for a painting program so it doesn't directly apply to Hatari 
> functionality, but waiting for vblank for each SDL_UpdateRect() might
> be a hint? I belive this was also an issue with Aranym FVDI speed
> which was solved.

I just checked the source code and as far as I can see, Hatari only uses
SDL_UpdateRect() once per VBL (unless you enable the new Statusbar
which might require some additional UpdateRects).

I think the problem is buried somewhere else in the SDL library... 

 Thomas

Re: [hatari-users] Media change bug

[Eero T. <oa...@he...>]

Hi,

On Tuesday 21 October 2008, Anders Eriksson wrote:
> I reported the bug beacuse I thought it was the right thing to do. But
> sometimes my energy runs out to argue for everything. Especially this
> time when there was a workaround. When my program is finished (should be
> on sunday) I'll conduct more tests and you'll have the same binaries then
> as well.

This isn't about "arguing", just about having enough information to
understand what is the problem so that it can be fixed (if it's in Hatari).

If this happens again, could you mail here the information given by
"minfo"[1] for both of the disk images:
	minfo -i <diskimage> ::
?

This will list the disk size, serial number, name etc.

(In the command line "::" refers to disk given with "-i" instead
of "<letter>:" drives defined in the mtools configuration file.)


[1] "minfo" is part of Mtools.

Mtools is a collection of utilities for manipulating disks and disk images
using FAT file system.  The utilities are pretty handy, I often use "mcopy"
when I need to copy large directory hierarchies to disk images (I have
configured mtools so that by default "a:" points to my default Hatari floppy
image).  For more info, see e.g:
	http://packages.debian.org/lenny/mtools
	http://www.mtools.linux.lu/faq.html


	- Eero

Re: [hatari-users] OSX performance issue

[Eero T. <oa...@he...>]

Hi,

On Tuesday 21 October 2008, Oisín Mac Fhearaí wrote:
> 2008/10/21 Anders Eriksson <ae...@dh...>:
> > This is for a painting program so it doesn't directly apply to Hatari
> > functionality, but waiting for vblank for each SDL_UpdateRect() might
> > be a hint? I belive this was also an issue with Aranym FVDI speed which
> > was solved.
>
> Hmm, this sounds right. I only noticed a few days ago when I moved to
> a recent Hatari build that it wasn't able to run at 100% on my Macbook

Recent build means CVS HEAD?  In which version of Hatari this was better?


> (which is bad, since the machine is dual-core with 2.1ghz or so for
> each core and 2 gigs of RAM), at least when playing Super Sprint.

With Hatari in ST mode?  In fullscreen or non-fullscreen?

Was Statusbar or Overlay disk access led enabled?

(In ST/e mode (which may do partial screen updates), overlay led needs to do
two (very small) additional display updates per frame when the led is ON. 
Otherwise Hatari does just one display update per frame.)


> Even after turning down the sound quality to the worst option,

The things improving the Hatari performance, from most to least:
- Enabling frameskip
- Disabling low-rez zooming (if in low-rez with frameskip off)
- Disabling "more compatible CPU"
- Disabling sound


> the whole thing became jumpy and behaved weird when the system
> came under load (about 10-15% from my web browser).

What if you select "Auto" as the frameskip option in Hatari display options?

Was Hatari using ~100% CPU when your MacBook was otherwise idle?


> Not sure why it wasn't happening on the older build, but it's
> certainly noticeable now.


	- Eero

Re: [hatari-users] Media change bug

[O. M. F. <den...@gm...>]

2008/10/21 Anders Eriksson <ae...@dh...>:
> This is for a painting program so it doesn't directly apply to Hatari
> functionality, but waiting for vblank for each SDL_UpdateRect() might be
> a hint? I belive this was also an issue with Aranym FVDI speed which was
> solved.

Hmm, this sounds right. I only noticed a few days ago when I moved to
a recent Hatari build that it wasn't able to run at 100% on my Macbook
(which is bad, since the machine is dual-core with 2.1ghz or so for
each core and 2 gigs of RAM), at least when playing Super Sprint. Even
after turning down the sound quality to the worst option, the whole
thing became jumpy and behaved weird when the system came under load
(about 10-15% from my web browser).
Not sure why it wasn't happening on the older build, but it's
certainly noticeable now.

Oisín

Re: [hatari-users] Media change bug

[Anders E. <ae...@dh...>]

On Tue, 21 Oct 2008, Thomas H. wrote:

>> Datum: Tue, 21 Oct 2008 08:48:37 +0200 (CEST)
>> Von: Anders Eriksson <ae...@dh...>
>
>>> How do you test for the disk change in your program?
>>
>> as I've said two times. I don't test for disk change, I let TOS do that.
>
> Maybe I asked the wrong question. I wanted to know what exactly you were doing in your program.
>
>> Eg, I load file 1, ask the user to change disk, and load file 2. Both with
>> Pexec.
>
> Ok, that's what I wanted to know, thanks.
>
>> But forget it, I have my workaround, it's enough.
>
> As you like. If you're not interested in this topic anymore, I'll drop it.

Hello,

I reported the bug beacuse I thought it was the right thing to do. But 
sometimes my energy runs out to argue for everything. Especially this 
time when there was a workaround. When my program is finished (should be 
on sunday) I'll conduct more tests and you'll have the same binaries then 
as well.


Over to another matter, the slow Mac OS X screen updates. I read about 
Grafx2 OS X port (also SDL) and they had to patch the OS X redraw a bit as 
it was much too slow otherwise.

I quote:

"Ok, here's the deal: under macosx SDL_UpdateRect() automatically waits 
for vblank so calling it for each pixels drawn isn't a good idea at all. 
What i did is to remove all those updates calls for macosx and just use 
one in Get_Input()."

This is for a painting program so it doesn't directly apply to Hatari 
functionality, but waiting for vblank for each SDL_UpdateRect() might be 
a hint? I belive this was also an issue with Aranym FVDI speed which was 
solved.


--
Anders Eriksson
ae...@dh...     http://www.dhs.nu/
ae...@at...  http://www.atari.org/

Re: [hatari-users] Media change bug

[Thomas H. <th...@gm...>]

> Datum: Tue, 21 Oct 2008 08:48:37 +0200 (CEST)
> Von: Anders Eriksson <ae...@dh...>

> > How do you test for the disk change in your program?
> 
> as I've said two times. I don't test for disk change, I let TOS do that. 

Maybe I asked the wrong question. I wanted to know what exactly you were doing in your program.

> Eg, I load file 1, ask the user to change disk, and load file 2. Both with
> Pexec.

Ok, that's what I wanted to know, thanks.

> But forget it, I have my workaround, it's enough.

As you like. If you're not interested in this topic anymore, I'll drop it.

 Thomas

-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196