Hatari 2.1.0 has been released

[MrPixel]

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

[wongck]

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.

[Eero Tamminen]

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.

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.

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?

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]

will do

[MrPixel]

similar options are greyed out in the file selection menu

all i can use is format disk and execute emucon

[darwinmac]

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

[wongck]

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?

[Eero Tamminen]

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]

fixed it, needed tos 2.06

[MrPixel]

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

[troed]

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

[michel30]

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 .

[Eero Tamminen]

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

[Bikerbob]

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

[Foxie]

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?

[Eero Tamminen]

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.

[Eero Tamminen]

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.

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.

[Foxie]

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.

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.

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.

[Bikerbob]

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

[Eero Tamminen]

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.

[Bikerbob]

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

[Foxie]

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.

[Eero Tamminen]

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.

[Foxie]

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: http://atari-forum.com/viewtopic.php?f= ... 56#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.

[npomarede]

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