Foebane

I am trying to extract the intros from these disk-based magazine issues: ftp://fujiology.untergrund.net/users/ltk_tscc/fujiology/MAGS/STAMPEDE/ but while some are .PRG files which are easy enough to extract and run, some are this obscure file format called .STU that I cannot figure out how to use or convert easily. Anyone know of what these are and how they can be converted?

My guess is the Windows Registry. Although, I would think you would lose all those settings if you had to reinstall Windows. I'm assuming the Registry simply because no additional files are added in the Altirra folder.

That'll do absolutely fine, thanks.

Something I forgot to ask: is there at least a keyboard shortcut for toggling between mono and stereo? I just find it fiddly navigating to the menus each time.

Thanks for your replies, I appreciate them. So I guess I'll stick with my original plan of indicating which ATRs and XEXs and so forth require (M) or (S).

I'm not asking for autodetection of mono/stereo, just that if it's mono, then the mono left channel is also put on the right. It could even be optional. I know that the Atari 8-bit cassette system was famous for using one side for data and the other for audio, but does that have to extend to POKEY itself?

I am currently using the latest version of Altirra (2.60), but there is a problem with games and demos that use stereo on it: 1. If I select Mono for stereo programs, some will adapt to mono but others will attempt to play it and sound bad. 2. If I select Stereo for mono programs, the sound only comes out of the left speaker, silence on the right. Is there going to be a fix to this problem in an upcoming version? Who should I contact to make sure this happens? It's more of an inconvenience than anything, but I've had to indicate in my Atari files which sound mode to use so as to get the best out of them.

They ARE in my memory, now very vaguely, but not my "phantasy". In any case, I was not impugning your work, sir, if in relation to the "tune" I mentioned.

My game program "Worms" (NOT anything linked to above) used 8-colour graphics, mainly Graphics 1 rendered as Graphics 10, and it looked bloody great if very blocky. Same for my title screen which was a straight echo of the Boulder Dash front screen with that tune I mentioned... ...but since I had it stored on tape only it was easily lost, and it was, along with my other games Blockman and Special Agent Fartski. How I miss them.

Worms is long-gone, but I still remember it. It's basically a Snake clone but with Boulder Dash style, I was so inspired by that game. I'm 42, born in September 1972.

Some sound more off than others, even though I know that POKEY is forced to represent 3-4 octaves in just 0..255. The problem stems from when "fellow" C64 users told us how awful they find POKEY music because of that lack of accuracy, I've not been able to ignore it since.

Me, too!

Why do the notes sound so... off? It's almost as if the tracker needs tuning!

D12 Basses are used because if I recall, the standard 0-255 Distortion 10 pure tone sound is inadequate in the number of octaves needed, so D12 makes up the difference. There were quite a few modes of audio selectable on a single memory register for POKEY, if I remember: I do know that for one game I produced back in the 1980s (Worms) I went ahead and made a simple tune that simply cycled from 0-255 on that register - it was actually quite catchy.

But I LOVE those! In fact, when I was playing around with Atari XL sound in BASIC I always figured that that distortion was useless, but it wasn't until I heard it used in some tunes that it fits perfectly well to a musical scale!

I think DVDs look best on a CRT, as that is what they were designed for (especially in SCART RGB mode, I was blown away when I first saw that!) For some reason, DVDs just NEVER look good on an LCD - must be the dodgy upscaling that is constantly used.

Phaeron, how do I get the minidump file to show you? EDIT: I only had a quick go with one game (Defender) but it seems to work fine. I'll try several more games on it today and let you know.

I don't agree with PMGs in Boulder Dash AT ALL. To me, part of the appeal of BD is that everything is locked into a cellular grid, and part of the appeal of Rockford's movement is the jerky cell-to-cell movement he has, not to mention everything else like the boulders and other entities, especially when the scrolling occurs. With PMGs, Rockford would be free to move smoothly from cell to cell and I would frankly find that very jarring. In fact, later BD clones have done just that, and I do NOT like these as much as the original jerky cell-to-cell movements.

Just had a look at Altirra 2.60, and I love the homage to the Amiga Workbench 3.0 boot screen. BUT, the 64-bit version crashes immediately when I try to run it, unlike 2.50 where it ran fine.

I think the Amoeba used the 5th colour, but I could be wrong.

Why use sprites at all? It would've looked wrong if Rockford was a sprite and obviously not part of the environment. And the basic five colours could be seen as the "lighting" in the game world. What is PF3? Speaking of PMGs in Atari games - some games are JUST NOT SUITED for them. Take Mercenary, for example: a totally 3D graphic rendering game with just plain Atari graphics, and no PMGs in use at all - except for a simple aiming sight that is picked up as an inventory item. Must've been the easiest coding Paul Woakes ever did!

The "fizzle" in the blank areas that announces an extra life, to my mind, is of a random number simply being POKED into the relevant character's display memory just twice, every four bytes. It looks cool as heck and is really simple to do. As for the rest, you're right. It would be wasteful of memory otherwise. EDIT: As far as I can see, only the following is animated: Rockford Amoeba Fireflies Butterflies Magic Walls That's five animated items x 4 characters for each one = 20 characters x 8 bytes = 160 bytes altogether. Absolutely small overhead, yes.

I never thought of it that way, but what I meant was that all eight character sets are in memory at once, and the single POKE into the memory register simply tells the custom chip what area of memory to refer to when rendering the graphics on screen. My own game did it this way, so that must be how BD does it. What's more, I've seen games where this memory register was given a value which didn't refer to any character sets in memory but other data, to give a type of fizzling blocky effect. I'm certain of that.

I remember being fascinated by how smooth and versatile the animation was in this game, even when things were busy and frenetic, and I found out later on that by POKE-ing a single value into a memory register, the character set graphics could be changed just like that, and that somehow the programmers of Boulder Dash had EIGHT such sets of character set graphics. I've seen other games where the graphics in character sets have been poked directly to produce random fizzle effects and whatnot, and I really like this aspect of Atari 8-bit graphics. I also noticed that the Commodore 64 seems to have the same ability. I was even more surprised when I made my own game that utilised this multiple character set switching, where a Player sprite is guided around animated traps in multiple caves - even the collision detection worked this way perfectly! What does everyone else think of this simple method of animation?

Ah, right, AtariONLINE.pl! I was looking at the wrong website! Thanks.