siriushardware wrote:Forgive my ignorance, but is there a quick way to get a .zip or tarball of all the files and folders of the current dev version? Following your link a few posts ago I can see lots of files and folders which would need to be downloaded individually - I am happy to do that if there is no easier way, but maybe there is an easier way?

I downloaded and compiled the devel version as of lunchtime on 13th November (2015, for anyone reading this in a year or two) - there was one little bit of screen strangeness, the sense of some of the flags / switches in the F12 'Atari screen' / 'Hatari screen' menus seemed to be a little bit mixed up.

For example, when first run, Hatari came up in fullscreen mode with ST/STe resolution locked on so I could not get the emulated screen to fill the physical screen, but the box to lock the ST/STe resolution was not actually checked. When I unchecked it, it was ignored (the resolution in ST/STe mode remained locked). Only when I unchecked 'TT/Falcon resolution locked' would the ST/STe mode screen expand to fully fill the sceen, even though Hatari is running in ST/STe mode and not TT/Falcon mode, unless of course that flag is also mixed up as well.

By randomly checking various boxes to the opposite of what I would expect, I have managed to get the screen working the way I want it. I'm not too worried about this: It is after all a dev version. In the stable V1.9.0 release, the behaviour of all of these settings is as expected.

This is strange, config file should be the same between 1.9 and current devel version.Did you run ./configure then make to compile your version ? Maybe the config file hatari.cfg is not located in the same place between your previous version and the version you built ?

(I understand that specifying winuae-cpu may no longer be necessary as it looks as though it is now the default setting as of the last or second last dev update).

I have previous downloaded versions of Hatari in folders, eg, 'hatari-1.8.0' and 'hatari-1.9.0' and now the devel version in folder 'hatari-dev', When I compiled V1.9.0 it obviously overwrote the installed executable of V1.8.0 with V1.9.0, but continued to use my original saved .cfg file, wherever that is normally kept. When I compiled 1.9.x dev, it again overwrote the previous executable, but on first running the screen settings did not appear to match the way they were set in the F12 / Atari screen / Hatari screen menus, and it seemed that I had to deliberately set some of them in reverse to force the screen behaviour I wanted.

Don't worry about this too much at the moment: Over the weekend I will try to play with it more and see if I can pin down some specific, consistent misbehaviour that I can tell you about. I know there is nothing worse than a vague bug report.

Edit: OK, here's something you can investigate and maybe reproduce.

Using only the F12 menus (not command line switches) and with Hatari running as an emulated 2MB ST (confirmed by the info bar at the bottom of the screen, in mono fullscreen mode...)

... I find that if I set 'TT/Falcon resolution locked', the ST/STE resolution is locked (but the checkbox for 'ST/STe resolution locked' remains clear).

If I uncheck 'TT/Falcon resolution locked', then ST/STe resolution is unlocked and the emulated screen expands to fill the whole physical screen. Does this happen for you?

siriushardware wrote:Using only the F12 menus (not command line switches) and with Hatari running as an emulated 2MB ST (confirmed by the info bar at the bottom of the screen, in mono fullscreen mode...)

... I find that if I set 'TT/Falcon resolution locked', the ST/STE resolution is locked (but the checkbox for 'ST/STe resolution locked' remains clear).

If I uncheck 'TT/Falcon resolution locked', then ST/STe resolution is unlocked and the emulated screen expands to fill the whole physical screen. Does this happen for you?

Are you using SDL1 or SDL2 build of Hatari, and how you're changing the ST/STe resolution locking?

However, in the SDL GUI, there's only one option with SDL2, and command line gives you a warning about this (which had a bug I just fixed), so I'm assuming you used some other (not updated) interface for that... Which one?

Eero Tamminen wrote:Are you using SDL1 or SDL2 build of Hatari, and how you're changing the ST/STe resolution locking?

SDL1, and using the built in GUI found under the 'F12' menu in Hatari.

I run a relatively old Linux distro (Derived from Ubuntu 12.04) and I'm not even sure if SDL2 can work in such an old distro - it certainly doesn't seem to be offered in the repos.

I posted my small report about this quite some time ago now (November 2015) and I am sure you will have made a lot of changes and tweaks since the version I was referring to then.

Let me try it again with the most recent dev version, and I'll see if I still have the same problems there. In the meantime, thanks again for the specific fix you included to get Cubase 2 working without crashing on entry to the edit screens - that has been working very well for me, hopefully for others too.

Using Mono mode, I was able to launch Master Tracks Pro, but I'm still having difficultly getting any Midi to work - I keep selecting "Enable MIDI" then it's asks to reset, where I get the message "Midi will Not be enabled - OK?" So, I am struck there (Why Hatari? b/c STeem's Midi while it reads input and delivers outputs to instruments, it all just half-there and half-jumbled)

Last I looked at the MIDI support for Hatari under Linux it wasn't really usable. a) /dev/sequencer isn't really the way MIDI is done under Linux these days and b) if I recall it was write-only, couldn't do read. I doubt it would actually work for running anything with timing, etc. Aranym has similar issues.

I actually had done some significant work under OSX to get either Aranym or Hatari (can't remember which) to drive MIDI on OS X. But I never finished. I might have to return to this some day. In theory what's done there could probably be ported to run on iOS too...

Hi siriushardware - Hatari 1.9.0 on a Dell Inspiron 530 Desktop PC with Windows 7 64 bit using a Neewer Midi in/out to USB Cable (Cable works on other DAW's) - I think I read that as well (at tuxfamily.org) that Midi was Not possible, too - I'm in mid-stream trying to get STeem's Midi problem fixed (Rapid-fire phantom notes play along side my sequenced chords) - I do Not have Linux - Thanks

ryan wrote:Last I looked at the MIDI support for Hatari under Linux it wasn't really usable. a) /dev/sequencer isn't really the way MIDI is done under Linux these days and b) if I recall it was write-only, couldn't do read. I doubt it would actually work for running anything with timing, etc. Aranym has similar issues.

All testing I've done is with virtual midi devices and they work fine. I don't see why there would be problems with reads with real MIDI devices. MIDI is an established standard, that's why Atari MIDI programs from 90's work still fine, Hatari itself doesn't need to do any translation.

ryan wrote:It might be Aranym that I'm thinking of with /dev/sequencer. But I do recall attempting to use Hatari with my (hardware) MIDI setup and finding it not workable. But this was also about 4 years ago.

Your MIDI device may show up as any number of things depending on the type of hardware you have, but typically on my Linux PCs the device name of my USB cable midi interfaces is MIDI1 (both input and output). Until V1.9.0, MIDI implementation in Hatari even under Linux had some problems but the necessary fixes to address those were incorporated into V1.9.0.

There was a further problem which prevented certain features in the most popular available version of Cubase 2.0 from working - not really a MIDI problem but a slight difference between Hatari and a real ST - but this was also fixed by Eero during development which has taken place since the release of V1.9.0.

So in general terms, for a working implementation of MIDI under Linux you need to be running V1.9.0, no earlier, and to run Cubase 2.0 you need the fixes which have been implemented in the dev version after the release of V1.9.0.

I use Hatari (compiled from recent dev version), Cubase 2 and a USB-MIDI interface on a 1.6Ghz netbook and I have to say it works really smoothly nowadays.