What is the premiere emulator for the 520/1040 ST series

[Keatah]

Just as the title says. What is the best emulator for running 520/1040 software on the PC via windows?

I've played around with Gemulator, Pacifist, Saint, and Steem.

 

All of these have user interfaces that seem rooted back in the windows 98 days. None are polished like Stella or Altirra or Atari 800 Emulator 2.2.1.

 

All these emus seem to have excessive busy-ness and generally clunky operation. Though perhaps Steem is the best of a bad lot.

[+CyranoJ]

Write a better one then...

[Charlie_]

I don't think STeem is bad at all.....

In fact I thought it was really good and got me interested enough in the ST to start getting real hardware.

[Keatah]

Write a better one then...

 

Why would I do that?

[Christos]

Steem and Saint clunky? That's a new one! I am really interested, what did you find clunky!?

[svenski]

I think Steem is pretty cool, very high compatibility and straightforward to use.

[+Guitarman]

I have always favored STeem. It seems to work and react like a real ST.

 

Also, let's not forget Aranym (Site here)

[+remowilliams]

STeem is an excellent emulator and SainT is as well (albeit with a slightly different focus). Pacifist is ancient but was a great first step.

 

Gemulator much like its author is a giant pile of ass.

[+wood_jl]

I must admit that STeem is the only one I've ever tried. It works so well, I saw no reason to try any other. It's so good it could be an "official licensed product."

 

What kinds of problems do you have with it?

[+rdemming]

Though perhaps Steem is the best of a bad lot.

 

STeem is probably the most user friendly and has the best debugger. But SainT & Hatari have better compatibility with overscan and hardware scroll tricks. E.g. No Buddies Land and the Lemmings screen from the nostalgia demo do not work on STeem but do work on SainT & Hatari.

The advantage of Hatari is that it is cross platform but the GUI is a pain. Hopefully they make a Qt GUI sometime. It's a pity that STeem is no longer updated.

 

Robert

[Keatah]

I just don't like a lot of mouse clicks and moving around. I didn't like the screen resizing controls, or the way it grabs the mouse and you know, task switching, things like that. It just feels tedious. I suppose Steem is the better choice. And Gemulator is god-awful. Seriously smelly ass.

[Christos]

You know, you really only need to set it up once. Have you ever used an ST?

[Cyprian]

I preffer Hatari, due to is the most advanced and still developed and emulator.

 

STeem has really nice GUI, unfortunately is really outdated.

[AstFan]

Just as the title says. What is the best emulator for running 520/1040 software on the PC via windows?

I've played around with Gemulator, Pacifist, Saint, and Steem.

All of these have user interfaces that seem rooted back in the windows 98 days. None are polished like Stella or Altirra or Atari 800 Emulator 2.2.1.

All these emus seem to have excessive busy-ness and generally clunky operation. Though perhaps Steem is the best of a bad lot.

 

If you want 'premiere' emulator, best ask some big SW firm to make it and pay for :-)

Still, it will be 'clunky' and 'excessive busy'

[oky2000]

STeem works all the time and has drag and drop, how it looks is unimportant. There are many machines that aren't emulated properly.

 

Super Stardust STE is the only game I couldn't run on it (not really an issue for me as I have WinUAE)

[Keatah]

STeem works all the time and has drag and drop, how it looks is unimportant. There are many machines that aren't emulated properly.

 

Super Stardust STE is the only game I couldn't run on it (not really an issue for me as I have WinUAE)

 

I've never seriously played with the ST series, except for a little bit in the stores. I was big into the Apple II scene and other systems. About the time the ST came out I had already spent too much money on the other 8-bitters. Not that it mattered. I tried breaking into the world of 16 bits, but all the 16 bit machines made the user feel too far removed from the heart of the system - the crystal-like snappy interaction between cpu and ram. All these custom chips and the bloating os'es got in the way.

 

I didn't like the ports of arcade games to 16 bitters, they seemed like the PC remakes of just a few years ago. All the artwork was redone (un necessarily I think). In spite of the greater capabilities of the amiga and st I would still prefer 8-bit games by far. 16 bit games felt sluggish.

 

IMHO, the acceptable choice of all the 16 bit machines was the mac classic. Despite it having a tiny b/w screen, it worked almost like one would expect. But that's just my opinion.

[wongck]

STEEM... but it's an STE series emulator, a bit more than the 520/1040 ST series.

[wongck]

I have always favored STeem. It seems to work and react like a real ST.

Also, let's not forget Aranym (Site here)

 

Yes, I use Aranym alot probably because of Mint rather than games.

But Aranym is a Falcon class emulator.

[+wood_jl]

I didn't like ... the way it grabs the mouse and ...

 

You toggle the "mouse grab" with the key on your PC keyboard that says "Pause Break." It's the easiest and handiest thing in the world.

[Keatah]

I didn't like ... the way it grabs the mouse and ...

 

You toggle the "mouse grab" with the key on your PC keyboard that says "Pause Break." It's the easiest and handiest thing in the world.

 

The position of the pause-break button is too far to the right and at the top of the keyboard..

[+rdemming]

but all the 16 bit machines made the user feel too far removed from the heart of the system - the crystal-like snappy interaction between cpu and ram. All these custom chips and the bloating os'es got in the way.

 

Then you would hate modern PC or even worse smart phones (iPhone, Android, WinPhone) because they have a thick layer of OS & drivers

 

B.T.W. the customs chips in a basic ST are in a sense less capable than the ones in an Atari 8-bit. The video chip does little more than displaying pixels. Unlike the 8-bit it had no hardware scroll, no sprites, no split screen, no display list, no character mode. All effects had to be done in software. Nearly all games and demos used the OS only the get started (and load data from disk although most demos used there own code for it). All other things were done by directly accessing the hardware.

 

Some special tricks like overscan and sync-scrolling required you to count clock cycles of the used instructions to achieve the proper synchronization with the video beam. Can you get much closer to the hearth of a system than that?

 

Robert

[AstFan]

 

... Nearly all games and demos used the OS only the get started (and load data from disk although most demos used there own code for it). All other things were done by directly accessing the hardware.

 

Some special tricks like overscan and sync-scrolling required you to count clock cycles of the used instructions to achieve the proper synchronization with the video beam. Can you get much closer to the hearth of a system than that?

 

 

My statistic says different, and I went through nearly 500 games. Actually, about 50-60% of Atari ST games uses TOS more than just for starting. XBIOS, BIOS functions called, and mostly filesystem functions (loading files via regular GEMDOS) . For instance all Silmarils games are very TOS dependant, and they made quality games, isn't ?

 

Yes, clock cycle depending code is used for some great effects, enhancements. Unfortunately it ended with era of pipelined CPUs, where it works not. Maybe not so unfortunately, because parallel with new CPUs better video modes and more res. came too

[+rdemming]

about 50-60% of Atari ST games uses TOS more than just for starting. XBIOS, BIOS functions called, and mostly filesystem functions (loading files via regular GEMDOS) . For instance all Silmarils games are very TOS dependant, and they made quality games, isn't ?

 

Yes, I said that besides for starting, many games use the OS for loading data. But what other OS functionality do you mean that is used by the mentioned 50-60% of games? I don't think there are many games (besides those few games that use GEM) that use the OS to play sound or draw graphics.

 

Robert

[AstFan]

Yes, I said that besides for starting, many games use the OS for loading data. But what other OS functionality do you mean that is used by the mentioned 50-60% of games? I don't think there are many games (besides those few games that use GEM) that use the OS to play sound or draw graphics.

Robert

 

Filesys functions are needed if game must load some further data after start - and it is case when not all data fits in RAM at once. Filesys provides some functions which require extra code with direct floppy access - as easy accessing any part of file.

Considering graphic and sound: yes, sound and graphic is programmed usually with direct HW access. But for instance setting screen base, res goes via XBIOS calls. And it is recommended (by Atari) and most compatible way. If you write directly into Video sync. reg. it will fail on TT for instance.

From experience, what is most called: video settings, IKBD chip settings, RAM allocation, BIOS calls for keyboard reading, mouse reading. Mouse handling is btw. not as expected in GEM (AES), but in GEMDOS. Only that is not initialised before AES start. Same stays for Line-A. All Line-A functions together with via blitter executed ones are in GEMDOS, not GEM . So, games with AUTO or boot start can use TOS mouse functions - examples: Dungeon Master, Millennium 2.2 (later use Line-A too) .

[Keatah]

but all the 16 bit machines made the user feel too far removed from the heart of the system - the crystal-like snappy interaction between cpu and ram. All these custom chips and the bloating os'es got in the way.

 

Then you would hate modern PC or even worse smart phones (iPhone, Android, WinPhone) because they have a thick layer of OS & drivers

 

B.T.W. the customs chips in a basic ST are in a sense less capable than the ones in an Atari 8-bit. The video chip does little more than displaying pixels. Unlike the 8-bit it had no hardware scroll, no sprites, no split screen, no display list, no character mode. All effects had to be done in software. Nearly all games and demos used the OS only the get started (and load data from disk although most demos used there own code for it). All other things were done by directly accessing the hardware.

 

Some special tricks like overscan and sync-scrolling required you to count clock cycles of the used instructions to achieve the proper synchronization with the video beam. Can you get much closer to the hearth of a system than that?

 

Robert

 

Maybe I should give up trying to find the precise reason why I dislike a lot of 16-bit gaming.

I understand what you said about the 800 having a more functional graphics chip than the ST.

I just seem to feel that when I would do something on the Apple II or Atari 800, and it involved a disk access, it would go faster. Irregardless of the the actual transfer rate.

 

With the Apple II, it seemed the drive would snap on, and the head would nag right into place, immediately. And after what would seem like one or two rotations on a 300 RPM drive, data transfer would begin. And transfer the entire track in one revolution. Similar thing seemed to happen with the Atari drives.

 

Now, on the Amiga 500/1000's (and what little I remember of the 520ST). I'd issue a save command of a sort, or some small quick disk access task. It seemed the disk would spin a few times, then click loudly while the magnetic clutch engaged, then spin a few more times. You'd get this buzzing as a the screw-drive head positioner moved into place. Then more spinning. Then a few more positionings (via that slow screw), then you'd get your data. And the computer would still hold the data someplace before releasing it to you (or your program) then the drive would shut down a moment later.

 

While I'm sure the actual xfer rate was faster on the 16 bitters, there seemed to be a lot of set-up time involved and head positioning. And a lot of tiny delays in the system from the time you started your request for data to the time you actually got it - ready for use.

 

Similar situation with the sound, much of the sound *seemed* delayed or the samples not started at 100% the correct time. Or felt just slightly out of sync. And background music would seem to be a totally separate entity away from the main game loop. And there was/is startup delays or stopping delays. Kinda like a kid pressing play to get the main game theme song going. Not quite exactly when the game action started. Usually it starts way before gameplay.

 

To some extent I noted it happening in the C-64 and Colecovision and Intellivision, Amiga, and 520ST. But rarely on the Apple II or Atari 400/800/2600, or Astrocade or Vectrex. The music on the earlier machines was integrated into the main game loop!

 

Nice and tight!