MikeFulton

A question. The STEEM emulator has the option to use extended screen modes like 1280x960x4 (not sure if that's supposed to be 4 planes or 4 colors). However, if you have GDOS installed it boots up into the regular ST low-rez mode up in the top left corner of the window, with the rest of the window blank. My guess would be that however STEEM is hooking into the display driver, it's not doing it quite right. Before I jumped into trying to figure out how to fix this, I thought I'd ask around here to see if anybody else already knows about this and has a fix. (I tried using this "VGAWIN.PRG" program by Derek Mihocka but it just crashes.)

I'm not claiming they couldn't have done better, just that it wasn't a "rush job"

The project deadline specified in the contract was mid April '79 but it was turned in to Atari in Dec '78, just after they finalized the contract.

No, it really wasn't. It was a job done quickly, which isn't at all the same thing. The developer turned in the finished product almost 4 months before the deadline. There was plenty of time to do more, if more had been required. You have to keep in mind that all of these flaws and shortcomings that are mentioned in this thread are coming 35 years later with enormous amounts of actual operation in the field. If you think all these things were so well known and obvious at the end of 1978, you're kidding yourself.

If it was Atari's official dev kit, it wouldn't have Megaroids source code. Megamax C was a third party product.

He had a "completed Jaguar 2" ? Why was he flying commercial when his flying unicorn could have gotten him there twice as fast?

I think perhaps you mean "free TV"

Reasonably, if you're doing a game where screen refresh rate is an issue, you probably don't wanna be doing it with GFA Basic. But even in C, you're probably not going to use VDI for drawing anything. You're going to want to manipulate the screen buffer directly, using the 68000 and blitter.

Looking at pixels isn't really the best way to do it. Gnn's method works ok in many cases, but it's really sort of a brute force approach that might not scale well to larger sizes. If you don't mind a more sophisticated method, my suggestion would be to create a list of rectangles that describe the things you can collide with. Also create one for the character. Then what you do is check the character's bounding box against the rectangles in the list. You can arrange the list so that you can find out quickly if a collision isn't possible. For example, if you have your list divided into screen quadrants, you can skip the rectangles that are in completely different ones from the character. You can also use several overlapping rectangles to fine-tune the accuracy. For example, you could have one overall bounding box for the entire character, and smaller ones for individual sections. Then if you find that you're intersecting the overall rectangle, you check the smaller ones. But if you're not intersecting the overall, you don't have to worry about the smaller ones.

Sorry for the "gotcha" !

Is there an FTP route to this, or just HTTP?

As someone who started saving their pennies the day the Atari 800 first hit the shelves at my local electronics store, I'll chime in here. First, ATARI BASIC wasn't an interim solution. An "alternative solution" might be more accurate. Microsoft simply licensed MS BASIC to Atari and was never involved in the programming for the Atari version. In late '78, after the in-house programmers at Atari realized that MS BASIC was *never* going to fit into an 8k cartridge, Atari went to a subcontractor (SHEPARDSON MICROSSYSTEMS), who proposed doing ATARI BASIC instead of simply taking over the existing project. Atari ended up contracting them for the development of ATARI BASIC as well as ATARI DOS. It's not really fair to say it was all that rushed or last-minute, either, because you have to keep in mind that back in those days, development cycles were typically measured in weeks. A project that took more than about 4 months was virtually unheard of. In fact, the developer earned a bonus for delivering ATARI BASIC ahead of schedule. The MS BASIC project got put on the backburner for awhile, but Atari knew that MS BASIC was popular with the education market, and also that there were business programs that could theoretically be useable on the Atari if it was available. So the project eventually came out, first as a floppy-disk loaded version, and then later as came out as a cartridge/disk combo.

When Megamax released their MEGAMAX C compiler, they also released a game written with it, along with source code. It was an Asteroids clone named MEGAROIDS. I have been looking all over for the source code disk, but cannot find it. So I started looking online and haven't had any success there either. Does anybody have the Atari version source code?

I guess I imagined the earlier post where I saw this: That was you, wasn't it? To be clear, I only mentioned 1988 in response to what you'd written. However, the bigger question than "1988wtf?" is why you're making such an emotional argument to something I never said. At no time did I claim there was never any shortage of ST inventory in the USA. Never said it. Dunno why you're arguing like I did. At most, I suggested it was a likelihood that unpaid bills could be involved. A statement directly supported by first hand experience, but still not at all the same thing as saying that every failure ever, by every US dealer, to get inventory was caused by unpaid bills. Which is what you seem to be arguing against. Perhaps you should retake that course in logic? While you're there, ask the instructor about the concept of the "straw man" because you seem to be pretty good at it.

You are correct. I worked in the showroom or in the back doing repairs and upgrades. I was referring to what I was told by the owner of the dealership. And maybe it didn't apply universally, or maybe it simply hadn't gotten that bad yet during the time I worked there.

I didn't accuse anybody of lying. Saying something is not true is not at all the same thing. I have no doubt that the OP believed what they said. That doesn't make it the absolute truth. At the very least, the original statement doesn't accurately apply across the ST's retail lifetime. If someone wants to narrow things down to 1988, then they need to make that distinction in the first place, not after the fact. My own anecdote was based on working at a local dealer from 1986 to 1987 and I stand by it.

SCART was all but nonexistent in North America. Unless you went looking specifically for a multi-format capable device you'd never run across it. I worked at Atari for two years before I saw a TV with a SCART connection.

I dunno why you think Epyx releases would be different one way or the other, but as a general rule, games ran at the default refresh rate the system booted on, whatever that was. A game programmed around 50hz and using the vertical blank for timing would run about 15% faster on 60hz but that's about it. A few games, very few, wouldn't run at 60hz. Probably too much code and too little time between vertical blanks. But there was a little program called "50hz.tos" which switched the system into 50hz mode. Once this was run, many of these games would work. As long as you were using the Atari SC1224 monitor, anyway.

It's simply not true that Atari would only ship to large dealers and distributors. I worked at a small dealer for a couple of years and we never had any particular problem getting stock as long as we did one thing. Paid our bills. The few times we had any issues with getting product from Atari, it was when we were a little late paying on some invoice. When that happened, we would be at the bottom of the queue for getting anything. But as long as we were paid up and current, we never had to wait more than a week or so for most products. If your local dealer had problems getting stock, it was very likely because they had an outstanding unpaid balance with Atari.

The biggest reasons were: 1) The price gap between the PC and ST was larger in Europe than in the USA, making the ST a more attractive choice price-wise. 2) Game consoles where less common in Europe than in the USA. To a large degree computer gaming filled the gap.

Dunno where these ideas came from but this is the first time I've ever heard of them. Except that there was no real defined standard for filenames or extensions. There were, however, common practices. The ".OBJ" extension was used to refer to any loadable binary file. There was never any distinction made between multi-segment or single-segment, or having a RUN address specified or not. Maybe there were some individuals who made such distinctions but it was never a widespread thing as far as I've ever heard. At some point, people started using ".EXE" in the same way as ".OBJ". I recall this was mainly an attempt to be more like how they did it on other computer systems. There was no distinction here other than personal preference, and in fact I remember one guy at my user group being proud of this program he'd written that did nothing more than rename all the ".OBJ" files on your disks to use ".EXE" instead. The use of the ".COM" extension on the Atari 8-bit computers was something you started seeing with command-line shells like OSS DOS-XL or SPARTADOS. For extrinsic shell commands (i.e. requiring a program loaded from disk, rather than being built into the shell) they used the ".COM" extension. This made it easy to distinguish which files on your disk were used by DOS.