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

[sack-c0s]

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

 

 

Although if you feel like a challenge you could always try and blag a job writing the drivers. The pay is fair enough and it does have an oldschool 'using a bit of cunning to try to coax every cycle out of the thing' kind of feel to it

 

On the subject of game music - on the C64 it was normally triggered by the raster interrupt every frame, which is pretty much how the atari 8-bit folks do it, isn't it?

Edited July 6, 2011 by sack-c0s

[+wood_jl]

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.

 

If it were a single-sided disk (on the ST) I seem to remember using disks that would step the head one track with each rotation of the disk (bump-bump-bump) as fast as possible, reading the data as fast as was physically possible. I don't ever remember an Atari 8-bit doing this. However, on either system, I remember head positioning and grinding (and delays) as the software forced the drive check for copy protection.

[+rdemming]

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) .

 

Thanks for the explanation. So, in short usually only the non time critical things in games are done using OS calls.

 

I remember that Kick Off 2 (at least the first buggy version) used many calls to the malloc() and mfree() for many small memory blocks. And that while the documentation (Atari Profibuch) warns that malloc() can only handle a limited amount of blocks and that it is better to allocate only one big block and manage it your self. No wonder the game crashed after a while.

 

Robert

[+rdemming]

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!

 

Hmmmm, I suppose this is usually due to "sloppy" programming. When programmed right, sound-effects should kick-in within 1/50 of a second. Or in case of samples, there might have been a short piece of silence in the start of the sample.

At least, I never experienced the "problems" you describe or didn't notice it as problem.

 

 

On the subject of game music - on the C64 it was normally triggered by the raster interrupt every frame, which is pretty much how the atari 8-bit folks do it, isn't it?

 

Yes, the Atari 8-bit and Atari ST usually had their sound-routines run in a VBL thus 50 or 60 times per second. In that sense C64, A8, ST are not that different. If you say the timing on a ST or C64 is different that on A8 then it has in my opinion more to do with how you experience the sound or the style of the sound/music than that the timing (things delayed) is really different.

 

Robert

[sack-c0s]

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) .

 

Thanks for the explanation. So, in short usually only the non time critical things in games are done using OS calls.

 

I remember that Kick Off 2 (at least the first buggy version) used many calls to the malloc() and mfree() for many small memory blocks. And that while the documentation (Atari Profibuch) warns that malloc() can only handle a limited amount of blocks and that it is better to allocate only one big block and manage it your self. No wonder the game crashed after a while.

 

Robert

 

This is my most shameful example of code abuse, and I would really like to say I've learned a lot in the 15-ish years since I did it so don't judge me by these standards now

 

I did a game once for the Archimedes where it was decided to use a relocatable module (sort of like a .DLL, but it responds to ARM SWI calls) for sprite and background tile drawing. so you'd stuff the registers with the appropriate data and call 'SWI Sprite_Draw', or whatever we decided to call it.

 

fair enough - until you figure out what is happening behind it. the CPU hits the SWI, branches to the SWI vector at 0x08, the OS then has to interpret the data field of the instruction,because this is all the chip actually does with a SWI, then having extracted the call number has to walk the chain of modules loaded to find out who is dealing with it. One ice-age in CPU clock cycles later our module gets control and starts drawing.

 

This was being done for a 16x16 pixel tilemapped 320x256 screen and again for the sprites on an 8MHz ARM 2. If anyone knows what the bloody hell we were thinking when we decided this piece of shameful coding was a good idea I'd like to know about it. Maybe we were bitten by the 'do things properly to futureproof things' bug but even then we should've thought further and passed a pointer to a batch structure in so we only hit this epic processing drag once a frame.

 

I suppose on the plus side if I want to resurrect the game through emulation it should run nicely because I can just emulate the game logic and trap the drawing operations, but that's just making excuses in hindsight.

[AstFan]

For sure, OS functions are not speed champions. In case of TOS there is a lot of for game unnecessary things done by usual Trap calls. Like saving all registers (this is not too slow), then saving almost complete stack (little slower), then comes more-less efficient branching by function # , etc ...

But if function is called only by initialisation it is not problem if is slow(er). I currently do game adaptations updates for TT, and almost every second game has problems because writing directly into Video HW registers. If they used TOS calls there would be no so much non-working on TT. But TOS call usage is possible only if low RAM is not destroyed by game self. Still, all necessary settings can be done before game low RAM part load - with TOS calls. But that practice is not common.

 

Sloppy programming : it is possible in many ways. I see mostly problems with IKBD chip programming in games - maybe there was no good documentation available in 80-es ? Can not blame programmers not doing Falcon and TT compatible code before those machines arrived. Although, there are cases of some weird code, which does nothing useful, contrary... Case of EPIC and some traps when 68030 is detected - total crap.

 

Considering : "If it were a single-sided disk (on the ST) I seem to remember using disks that would step the head one track with each rotation of the disk (bump-bump-bump) as fast as possible, reading the data as fast as was physically possible. I don't ever remember an Atari 8-bit doing this. However, on either system, I remember head positioning and grinding (and delays) as the software forced the drive check for copy protection."

 

If there is only 9 sectors/track it is possible easy. But with by Atari ST usual 10 s/tr no way, even with fastest code. Because we need some time after step for head settle (that oscillations stop). So, only way to avoid 2 rotations average for 1 track read is skew. It means that second track starts not with sector 1, but with 10 or 9 . Then during stepping and settle down time sectors 9 and 10 will be under head, and sector #1 od track 2 just right in proper moment. It is of course little slower than skewless 1 track/rotation read, but not much more, just 10-20% . And it explains why popular Fast Copy Pro is so fast. But there is many other programm which does same skewed formatting of floppies. And even TOS self, at v. 2.06 .

Edited July 8, 2011 by AstFan