Hatari 2.1.0 has been released

A forum about the Hatari ST/STE/Falcon emulator - the current version is v2.1.0

Moderators: simonsunnyboy, thothy, Moderator Team

MrPixel
Captain Atari
Captain Atari
Posts: 191
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Postby MrPixel » Wed Mar 14, 2018 6:39 pm

Eero Tamminen wrote:
MrPixel wrote:can't get GFA basic to run. i have it in the same directory as the emulator but the program won't read it. all options to run files are greyed out, leaving just screen and file directory options for a and b.


MrPixel, please be more explicit in describing what you're trying to do. What is the "program" you refer above? Hatari or GFA interpreter program?

What is grayed out and in where? On what OS you're running Hatari? Which version of Hatari? Which version of GFA?

Are you trying to run GFA from (floppy or hard disk) image, or from GEMDOS HD emulation?

(I think the issue is that you're trying to do something wrong, Hatari should have no problem running GFA.)


64 bit windows 10
tried hatari but stitched to steem, text is in red and in german
GFA basic
hard disk
not sure which version, probably version 1 or 2
2.1.0
the options to choose a file, run a program and do anthing else with the emulator are greyed out (file selection etc)
i would attach a file but i don;t know how to screen capture hatari

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12412
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: Hatari 2.1.0 has been released

Postby wongck » Thu Mar 15, 2018 12:31 pm

MrPixel wrote:i would attach a file but i don;t know how to screen capture hatari


On windows 10, click the start button and type "snipping".
The Snipping tool should be select, so press <RETURN> and it will run the snipping tool.
From the Snipping Tool window select NEW and the whole screen goes transparent grey. Select the area you want to snip.
The snipped area will appear in the window of the Snipping Tool.
Save the screen grab into a JPG file.
Attach the JPG on to the forum.
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1726
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Thu Mar 15, 2018 3:57 pm

MrPixel wrote:64 bit windows 10
tried hatari but stitched to steem, text is in red and in german


If you're referring to text in the TOS file selector, its language comes from the TOS version you're using, and if text there is red, GFA basic has changed palette before opening the file selector.

MrPixel wrote:hard disk


Does the hard disk work fine outside of GFA basic? There can be all kind of non-Hatari issues with hard disks...

Which hard disk driver you're using? Some programs have problems with specific HD drivers.

MrPixel wrote:GFA basic
not sure which version, probably version 1 or 2


I remember there being versions of GFA basic which don't work well with hard disks.

Could you provide your GFA basic version so that I could try it?

MrPixel wrote:2.1.0
the options to choose a file, run a program and do anthing else with the emulator are greyed out (file selection etc)
i would attach a file but i don;t know how to screen capture hatari


Hatari includes screenshot functionality for the emulated content. Just click to "Hatari screen" -> "Screenshot", or use the AltGr+G keyboard shortcut.

(You can change keyboard shortcuts through "Keyboard setup" dialog.)

MrPixel
Captain Atari
Captain Atari
Posts: 191
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Postby MrPixel » Thu Mar 15, 2018 11:28 pm

will do

MrPixel
Captain Atari
Captain Atari
Posts: 191
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Postby MrPixel » Fri Mar 16, 2018 11:39 pm

similar options are greyed out in the file selection menu

all i can use is format disk and execute emucon
You do not have the required permissions to view the files attached to this post.

darwinmac
Captain Atari
Captain Atari
Posts: 180
Joined: Sat Aug 06, 2011 2:49 pm
Location: Chicago, USA

Re: Hatari 2.1.0 has been released

Postby darwinmac » Sat Mar 17, 2018 1:19 am

Have you inserted GFA Basic into Drive A? I do not see where you have opened the drive to see GFA. If you have GFA Basic on a GEMDOS drive, you could use the Install Devices command to see those drives. However, it would be easiest to start with if GFA Basic was on an ST image that you inserted into Drive A.

From your screenshot, I do not see where you have opened up any desk to start running GFA Basic.

Bob C

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12412
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: Hatari 2.1.0 has been released

Postby wongck » Sat Mar 17, 2018 4:31 am

Your screenshot shows just the desktop, no program running.
Options are grey out because there is nothing for that option to work on.
For example,
- you select FILE>INFO without highlighting anything ==> nothing happens.
- click on DISK A to highlight it, select FILE>INFO ==> gives you information on the DISK in a dialog box.

So the 2nd case, DISK A was the thing for FILE>INFO to work on. Likewise you can highlight folders and files, for it to work on.

Also notice that FILE>OPEN is no longer grey out. Open it, it will look into DISK A to give you a listing of what's inside disk A.

This is similar to Windows XP, no?
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1726
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Sat Mar 17, 2018 8:37 am

darwinmac wrote:If you have GFA Basic on a GEMDOS drive, you could use the Install Devices command to see those drives.


He's running EmuTOS and that automatically installs icons for every drive, so it's not needed.

PS. Could somebody move these GFA posts to some other thread (e.g. "Using GFA with Hatari")?

MrPixel
Captain Atari
Captain Atari
Posts: 191
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Postby MrPixel » Sun Mar 18, 2018 12:02 am

fixed it, needed tos 2.06

MrPixel
Captain Atari
Captain Atari
Posts: 191
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Postby MrPixel » Sun Mar 18, 2018 12:48 am

so i decided to try out some example code with Devpac 3.10 and got a whole bunch of errors when assembling.

this is the code:


intin equ 8 ; setup some constants
ptsin equ 12
colbit0 equ 24
colbit1 equ 26
colbit2 equ 28
colbit3 equ 30
lstlin equ 32
lnmask equ 34
wmode equ 36
x1 equ 38
y1 equ 40
x2 equ 42
y2 equ 44
init equ $a000
setpix equ $a001
getpix equ $a002
drwlin equ $a003

start:
jsr initialize

dc.w init ; call line a init

move.w #1,colbit0(a0) ; setup arguments to draw line
move.w #1,colbit1(a0)
move.w #1,colbit2(a0)
move.w #1,colbit3(a0)
move.w #0,lstlin(a0)
move.w #$ffff,lnmask(a0)
move.w #0,wmode(a0)
move.w #0,x1(a0)
move.w #0,y1(a0)
move.w #100,x2(a0)
move.w #100,y2(a0)
dc.w drwlin ;call line a draw line

move.w #7,-(a7)
trap #1 ;wait keypress
addq.l #2,a7
jsr restore
clr.l -(a7) ;call gemdos
trap #1

initialize: ; go into super user mode
clr.l -(a7)
move.w #32,-(a7)
trap #1
addq.l #6,a7
move.l d0,oldstack
rts

restore: ; go back into user mode
move.l oldstack,-(a7)
move.w #32,-(a7)
trap #1
addq.l #6,a7
rts

oldstack dc.l 0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
intin equ 8 ; setup some constants
ptsin equ 12
colbit0 equ 24
colbit1 equ 26
colbit2 equ 28
colbit3 equ 30
lstlin equ 32
lnmask equ 34
wmode equ 36
x1 equ 38
y1 equ 40
x2 equ 42
y2 equ 44
init equ $a000
setpix equ $a001
getpix equ $a002
drwlin equ $a003

start:
jsr initialize

dc.w init ; call line a init

move.w #1,colbit0(a0) ; setup arguments to draw line
move.w #1,colbit1(a0)
move.w #1,colbit2(a0)
move.w #1,colbit3(a0)
move.w #0,lstlin(a0)
move.w #$ffff,lnmask(a0)
move.w #0,wmode(a0)
move.w #0,x1(a0)
move.w #0,y1(a0)
move.w #100,x2(a0)
move.w #100,y2(a0)
dc.w drwlin ;call line a draw line

move.w #7,-(a7)
trap #1 ;wait keypress
addq.l #2,a7
jsr restore
clr.l -(a7) ;call gemdos
trap #1

initialize: ; go into super user mode
clr.l -(a7)
move.w #32,-(a7)
trap #1
addq.l #6,a7
move.l d0,oldstack
rts

restore: ; go back into user mode
move.l oldstack,-(a7)
move.w #32,-(a7)
trap #1
addq.l #6,a7
rts

oldstack dc.l 0

User avatar
troed
Atari God
Atari God
Posts: 1418
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Hatari 2.1.0 has been released

Postby troed » Sun Mar 18, 2018 9:12 am

Feel free to make a post about assembler coding with Devpac in the 68000 development forum. It hardly has any relevance to Hatari.

michel30
Atarian
Atarian
Posts: 1
Joined: Sat Mar 17, 2018 6:03 pm

Re: Hatari 2.1.0 has been released

Postby michel30 » Mon Mar 19, 2018 9:59 pm

Hello,

Does somebody running this version on retropie ( Raspberry pi3 )?
The only version that I found is 1.8.0 and the B.I.G demo is not running on it :-( .

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1726
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Sun Mar 25, 2018 9:04 pm

What distribution retropie is based on?

If it's Debian based, Debian stable has Hatari v2.0 and testing/unstable have Hatari 2.1:
https://packages.debian.org/stable/hatari

And following will tell which of the Hatari architecture packages need on your HW:

Code: Select all

dpkg -s hatari | grep ^Architecture


Most likely issue you would have when installing Hatari from newer Debian (-based) distribution is the SDL dependency. Hatari v1.8 is normally built against SDL v1.2, and Hatari v2.x are built against SDL v2.x. I.e. you may need to install also extra deps. If that gets too hard, easiest will be building the newer Hatari from sources.

Here's how you would do it with Debian package sources:
https://wiki.debian.org/BuildingTutorial

User avatar
Bikerbob
Captain Atari
Captain Atari
Posts: 174
Joined: Wed Mar 23, 2016 2:46 am
Location: Oakville, ON, Canada
Contact:

Re: Hatari 2.1.0 has been released

Postby Bikerbob » Mon Apr 02, 2018 2:51 pm

So with 2.1 can we get on the net through the emulator yet? - what about something on the PC side that will re-direct the serial output to ethernet?

I have no issues using STing or STick -- I know we can go from the virtural ST com to the PC com.. then what about directing the PC com to the ethernet and there for bang we have internet?

There is software that will create virtural modems on your PC.. that accept AT commands. how do I trick the modem to think its dialed an ISP?? just direct it to the portal address?? 192.168.1.0 type thing? and the STing or STick stack will take over?

James

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: Hatari 2.1.0 has been released

Postby Foxie » Mon Apr 02, 2018 5:23 pm

Since upgrading to v2.1.0, I have a performance problem. Previously, I always had prefetch mode and cycle exact mode enabled. This was OK when emulating a TT or Falcon. As of v2.1.0, enabling either (or both) of these options slows my i7 to a crawl - I only get a few frames per second.

I have a couple of questions. Do "cycle exact" and "prefetch mode" have any effect on 68000 emulation? Or is it 68030+ only?

Also, is there any way to enable/disable these options on the command line? I use a launcher script for Hatari which allows me to select a pre-defined machine configuration. I'd want to enable cycle exact and prefetch on an ST, but disable it on a Falcon/TT.

I have also noticed that with cycle exact and prefetch disabled, NVDI won't run on the Falcon. The system locks up at boot.

Also, another unrelated problem: the mouse speed appears to be slower in this release (on OS X). I can no longer move the mouse from one side of the screen to the other without moving outside the emulator window. I seem to recall there is some way of adjusting this?

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1726
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Mon Apr 02, 2018 6:29 pm

Bikerbob wrote:So with 2.1 can we get on the net through the emulator yet? - what about something on the PC side that will re-direct the serial output to ethernet?

I have no issues using STing or STick -- I know we can go from the virtural ST com to the PC com.. then what about directing the PC com to the ethernet and there for bang we have internet?

There is software that will create virtural modems on your PC.. that accept AT commands. how do I trick the modem to think its dialed an ISP?? just direct it to the portal address?? 192.168.1.0 type thing? and the STing or STick stack will take over?


No idea how one would do something like that on Windows, but on Linux one can just give the Linux serial device as serial device to Hatari.

One can forward any file over network with "socat" command. I.e. one can connect two Hatari instances on opposite sides of earth through Internet with it.

"MIDI and networking" section here tells how to do it with MIDI, but it should work same way also for Hatari serial:
https://hg.tuxfamily.org/mercurialroot/ ... -linux.txt

If your question wasn't about how connecting different (H)atari instances, but how to do www-browsing with emulated machine... Modern www-pages are so bloated & slow, that either they don't work properly, or using them with emulated original Atari machines is closer to torture. For emulated Atari www-browsing I would recommend using Aranym + NatFeats MiNT setup instead, that's much faster than Hatari and supports more reasonable resolutions for modern www-pages.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1726
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Mon Apr 02, 2018 6:52 pm

Foxie wrote:Since upgrading to v2.1.0, I have a performance problem. Previously, I always had prefetch mode and cycle exact mode enabled. This was OK when emulating a TT or Falcon. As of v2.1.0, enabling either (or both) of these options slows my i7 to a crawl - I only get a few frames per second.

I have a couple of questions. Do "cycle exact" and "prefetch mode" have any effect on 68000 emulation? Or is it 68030+ only?

Also, is there any way to enable/disable these options on the command line? I use a launcher script for Hatari which allows me to select a pre-defined machine configuration. I'd want to enable cycle exact and prefetch on an ST, but disable it on a Falcon/TT.

I have also noticed that with cycle exact and prefetch disabled, NVDI won't run on the Falcon. The system locks up at boot.


Cache emulation got more accurate in Hatari v2.1, and it's enabled by default, that slowed down "cycle accurate" emulation a lot. There were similar improvements also with MMU emulation, but that doesn't have much perf impact. Both caches and MMU are 030+ specific features, so they don't affect 68000 emulation.

On Falcon, cycle-exact is mainly needed by some of the demos, for better CPU<->DSP sync. Unless you run timing sensitive demos, just disable cycle-exact, maybe also prefetch mode for 030+ emulation. On command line you can do that with: "--cpu-exact off" and "--compatible off".

For more information where cycle-exact is needed, see the Hatari compatibility list:
https://hg.tuxfamily.org/mercurialroot/ ... ility_list

(If you notice something in the list not to be up to date, please comment on Atari-forum or hatari-devel mailing list.)

Note: there have been similar complaints also from other Mac users, but Hatari 030+ cycle-exact emulation works fine for me on Linux with my old i3 CPU. v2.1 takes more CPU, but it's a problem only when something is taxing also DSP emulation.


Foxie wrote:Also, another unrelated problem: the mouse speed appears to be slower in this release (on OS X). I can no longer move the mouse from one side of the screen to the other without moving outside the emulator window. I seem to recall there is some way of adjusting this?


On Hatari side there have been no changes that should affect that. Hatari v2.0 was probably built with SDL v1, and Hatari v2.1 *is* built with SDL v2. All the OS specific backends in SDL were AFAIK re-written for v2 (which uses now GL for scaling application output) -> I think any mouse change would be due to libSDL version change.

You'll probably know this, but you can use mouse grab keyboard shortcut or fullscreen to make sure mouse keeps within Hatari window.

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: Hatari 2.1.0 has been released

Postby Foxie » Mon Apr 02, 2018 7:48 pm

Eero Tamminen wrote:On Falcon, cycle-exact is mainly needed by some of the demos, for better CPU<->DSP sync. Unless you run timing sensitive demos, just disable cycle-exact, maybe also prefetch mode for 030+ emulation. On command line you can do that with: "--cpu-exact off" and "--compatible off".


Thanks, this solves the problem.

The NVDI issue remains, it will work if I enable either prefetch or cycle exact (don't need both to be enabled). But unfortunately enabling either drops the performance to about 1/10th realtime. At the moment my workaround is just to disable HDD boot when in Falcon mode.


Eero Tamminen wrote:Note: there have been similar complaints also from other Mac users, but Hatari 030+ cycle-exact emulation works fine for me on Linux with my old i3 CPU. v2.1 takes more CPU, but it's a problem only when something is taxing also DSP emulation.


Is this related to LLVM? I'm not sure why else it would be so slow on the Mac. I don't think it has anything to do with SDL, because Hatari takes less than 60% CPU when I disable cycle accurate and prefetch.


Eero Tamminen wrote:On Hatari side there have been no changes that should affect that. Hatari v2.0 was probably built with SDL v1, and Hatari v2.1 *is* built with SDL v2. All the OS specific backends in SDL were AFAIK re-written for v2 (which uses now GL for scaling application output) -> I think any mouse change would be due to libSDL version change.


I vaguely recall having to change this on Linux years ago. I think there was an environment variable which SDL reads. I'll have to do some digging.

Has anyone considered mapping the middle mouse button to grab/release the mouse? UAE does this, and it's more convenient than using a keyboard shortcut. Another interesting possibility is an Atari driver to read absolute mouse coordinates, but I don't know where to pass such information into GEM.

User avatar
Bikerbob
Captain Atari
Captain Atari
Posts: 174
Joined: Wed Mar 23, 2016 2:46 am
Location: Oakville, ON, Canada
Contact:

Re: Hatari 2.1.0 has been released

Postby Bikerbob » Mon Apr 02, 2018 8:29 pm

Not about modern webbrowsing.. its about TELNET, IRC, EMAIL. Calling TELNET BBSs, IRC on #atariscne or ##atari.. or just sending and receiving emails. All of that is no problem on a real atari.. but on a Emulated Atari .. does not seem possible. Which seems crazy to me.

There is software on the PC Windows that is called Virtural Modem.. with that I can dial an address IP4 --- IF I can get to an ip adress is there any way to make the modem beleive its dialed into a dialup ISP? So that I could use all my protocals, without having to "call" again. Like all the eithernet adapters we have for the real ST hardware. Why would it be so hard to emulate an ethernet adapter?

James

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1726
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Mon Apr 02, 2018 10:13 pm

Here's old NE2000 / NE1000 network adapter emulation for Hatari:
https://github.com/mist-devel/mist-boar ... i/memory.c

(See the code inside "NE_EMU" ifdefs.)

Code comment in the beginning of the file mentions few (fairly severe) impacts of this code.

Feel free to port it to latest Hatari version sources, fix the issues and test that it works, then post the code to hatari-devel or here for review.

User avatar
Bikerbob
Captain Atari
Captain Atari
Posts: 174
Joined: Wed Mar 23, 2016 2:46 am
Location: Oakville, ON, Canada
Contact:

Re: Hatari 2.1.0 has been released

Postby Bikerbob » Tue Apr 03, 2018 6:24 pm

Thanks Eero, now all I have to do is learn to code ;)

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: Hatari 2.1.0 has been released

Postby Foxie » Wed Apr 04, 2018 1:11 am

I think I might have run into a VDI-related issue in Hatari.

Configuration:
Mega STE (2.06 UK).
With or without NVDI.
Extended VDI screen, 1024 x 768 monochrome or colour.

I run Devpac 3.1 and hover the mouse nearly off the bottom right of the screen. The Atari system locks up after a few seconds. A single line of graphics corruption is sometimes seen near the bottom when this happens.

I haven't been able to reproduce the problem in TT high mode.

It could be a bug with Devpac itself, but I can't remember this happening on the older version of Hatari.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1726
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Thu Apr 05, 2018 11:20 pm

I'm able to reproduce the crash/freeze issue, also with ST / TOS v1.04, and it happens even without any program running.

Here's the first error for TOS 2.06uk:

Code: Select all

Bus Error at address $400000, PC=$e0c9f6 addr_e3=e0c9f8 op_e3=3431


It happens only in about 16x16 sized area at the bottom right corner of the screen.

It does NOT happen:
* with Hatari v2.0
* with EmuTOS (only with real TOS)
* if I reduce VDI screen height by 16 pixels, to 1024x752

You could try whether reverting changeset 6445:dca750f303bb ("Choose the default font depending on the choosen VDI height") would change anything. It's the only one between 2.0 and 2.1 that seemed like it could affect this.

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: Hatari 2.1.0 has been released

Postby Foxie » Sat Apr 07, 2018 12:36 am

I think I've found another problem.

I don't know if this is unique to Hatari 2.1.0 yet. It might be a long-standing issue. It might be an SDL issue.

On OS X the YM sound is broken up in monochrome mode when vsync is turned on. This is for square wave playback, not samples.

Resolutions affected:
ST high.
TT high.
VDI extended with 2 colours selected.

Resolutions NOT affected:
ST low/medium.
VDI extended with 16 colours selected.
Falcon 640x480 16 colours.
Falcon ST high compatibility mode (Hatari reports 50Hz).

TOS versions affected:
TOS 1.62.
TOS 2.06.
TOS 3.
TOS 4.
Probably all others?

Software affected:
FOXIE_YM Cubase driver: viewtopic.php?f=111&t=33485&p=342956#p342956
Games which run in high resolution mode.
Probably all YM software?
Happens regardless of NVDI being loaded.

Hatari sound settings affected:
44.1kHz.
50kHz.
Synchronise on or off.

Hatari video settings:
Vsync enabled (disabling solves the problem).
Window mode (not full screen).
Mac monitor refresh rate: 60Hz.
High Sierra.

This is not related to the VBL interrupt driving the music playback routine too fast. The FOXIE_YM driver doesn't use the VBL at all.

User avatar
npomarede
Atari God
Atari God
Posts: 1241
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 2.1.0 has been released

Postby npomarede » Sat Apr 07, 2018 9:39 am

Hi
but if you set ST to Mono, it will refresh frames (including sound) at 70 Hz, but as vsync is ON, the main vsync loop in Hatari will pause until the next 1/60 of sec.

At 70 Hz a frame lasts approx 0.014 sec, so Hatari will generate sound for 0.014 sec every frame (based on the emulated video freq). But if your PC/Mac is set to vsync ON at 60 Hz, it means a host frame will last à.016 sec.
So, the OS gets new video/sound data every 0.016 sec, but Hatari generated only 0.014 sec of sound. You will miss 0.002 sec of sound for every frame, which might be enough to alter YM square sound (YM samples are altered too, but it's harder to hear).
Unfortunately, Linux version don't have VSYNC option, so I can't reproduce this at the moment. It should be fixable by detecting VSYNC is on and generating more YM data.

But on a general side, I don't think it's a good idea to use vsync=on when your host display freq is not able to match the emulated video freq. This might limit some "tearing" video effect because you're in sync with the host display, but it will completely ruin the accuracy of the emulated timings.

Nicolas


Social Media

     

Return to “Hatari”

Who is online

Users browsing this forum: No registered users and 4 guests