Maury Markowitz

They will do fine, I'll definitely use the second one. I really like the lighting, it's "flat" with no bright spots so it will be much easier to do touchups. Can you upload them to the commons? Click here: https://commons.wikimedia.org/wiki/Special:UploadWizard Let me know the resulting URLs and I'll put them in the right categories and everything.

Is there any indication of why? From an overview, it seems there are few differences between 2.x and 7.x in overall design. It would appear at first glance they still both use the same chunker/tokenizer, and I can't imagine they removed the basic speedups, so I can't think why this might be. The problems in Atari BASIC are well documented, but I can't seem to find anything similar concerning the CBM versions.

I'm wondering if anyone out there has a working setup using MADS or xasm on a Mac and has advice on how to push the resulting binaries into Atari800 (or similar)? I have some hacks I'd like to try in the original Atari BASIC code, but it is a daunting process of bootstrapping the system.

BTW, I'm 90% certain my friend Alex's Bigston 410 lacked the tape counter. Did anyone else ever see such a thing or am I going nuts?

Yes, THAT one! Can you do me an enourmous favour? Can you take an "angled" photo of that and upload it to the Wiki Commons? An angled photo is like this one: https://en.wikipedia.org/wiki/List_of_cassette_tape_data_storage_formats#/media/File:Atari_410.jpg Maybe do the reverse angle so we have some visual difference? The door open is a nice change too. Don't worry about the background and such, the peeps on the Commons are wizards and fixing that up.

I've written a wiki article on the Program Recorder series: https://en.wikipedia.org/wiki/Atari_410 I'd like to add an image of the earlier 410 with the Bigston mechanism. Does anyone out there have one in reasonably good condition and would be willing to upload a "glamour shot" of it to the wiki commons?

I recall seeing details on the Atari drives, perhaps specifically the 410, that listed the company that produced underlying tape mechanism. Does anyone have a list of these?

I'm always surprised about all the hate for the 400's keyboard. I had this exact setup and I could type up a storm on it. I only saw a 800 some time later, and found the keyboard entirely "meh", I found the short throw of the keys weird after getting used to things like the VT100. Given that I'm typing this on a butterfly I think I would have quickly got used to it, but that doesn't detract from the fact that you could do the same on the 400. I had a problem on my 400 I have not seen elsewhere. The glue under the control key died and the key bubbled up instead of being concave. Over time the plastic started to crack around the white line so I was very careful using it. Never caused any problems in the end, but certainly worried me.

I'm not sure one can call it optimized, per se. The use of 16-bit line numbers in branches, for instance, was a side-effect of them not tokenizing numbers at edit time. So they had to read it from ASCII every time, and as such it was easier to make an ASCII->16 bit parser than use the 40-bit version and then convert. In contrast, AB was converting these to FP at edit time, so in their case it was easier to just call the FP->int. In neither case do I think anyone asked "how do I make this fast?" That said, MS's "search from here forward" clearly is a deliberate optimization. I suspect that came later. One sees the same pattern in the loops. I suspect in both cases it was simply a case of using whatever pointer they had in-hand to push on the stack.

Except the 1200XL, which may have indeed done that but then had a higher MSRP. What did Atari think they were selling users for all that extra money? 16k you could only use in certain cases? I am absolutely convinced that if the 1200 had an 80-column mode, even monitor port only, it would have been the most popular machine in the lineup. Even failing that, one could immediately understand what you were getting for you money, even if it was even more money. I still consider the 1200 to be the straw that broke the camel's back.

I think you both missed it. I am fully aware "yolk" is part of an egg. I did not type "yolk", I typed "yoke", and grammarly changed it. This is the problem with auto-correct, but the fact that it is correct 98% of the time makes it worth the occasional confusion like this one.

Not according to Grammarly, which changes it without telling me.

And the prize goes to Scorpio! It's surprising how little-known this game is.

Ok, that trench is very similar to what I recall. But the action is very different than what I recall. Weird... normally I have pretty good memory for these things.

I cannot find any references to this game so maybe someone here will recall it: It was a full-sized arcade cabinet with an aircraft-yolk type controller with fire buttons on the tip of the yolk. I seem to recall rubbery handles on the yolk that looked like they came from a kid's bike handlbars. This controlled the player vehicle, which I seem to recall looking like a TIE fighter (or perhaps the enemies were?), turning it moved left and right and pushing into the cabinet moved upwards. There was a deliberate slowness in the motions to make it more difficult. The action took place in a moving graphic that looked like you were flying up the Death Star trench. But you weren't - the game was actually 2D although the perspective use was very clever such that it looked like you were above the surface of a rapidly rotating DS. Enemies would approach from the sides near the top of the display, at the "horizon" of the trench, where they could not be shot. They would then enter and begin approaching you. You shot upward at them. I seem to recall they sometimes laid a barrier of some sort a-la Pleiades? No, this is not any variation of Star Wars. This was a 3rd party product using a B&W television as the monitor. Unfortunately SW related games so polute Google I can't find any trace of it. This would have likely been in the 80/81 time frame. And no, not Juno First, far less advanced.

Ninjaed

...and then seconds later found it, John Jainschigg

I'm trying to correct the "inaudible" sections in the David and Betsy Ahl interview. One I can't quite make out: Betsy: But then John [inaudible 01:11:05] kept doing it a little bit. It sounds something like "Genji" or "Chenchi" or something to that effect. I assume this was someone at Atari as the context is Atari Explorer, but I suppose it could be the games magazine they mention. Anyone have any ideas?

Love too, but no Mac version as of yet.

Neither of which has a ROM file that can be used with the Atari800 emulator.

It was because of the DEF FNs. He had no interest in trying to code around versions that lacked it. I don't think it's because he wanted to test DEFs that badly, but didn't have any interest in learning new dialects. I don't think the short deadline or size constraints fully explains it. One of the biggest problems in AB is the FOR/NEXT loops, which write down a 16-bit line number instead of a 16-bit address, and then calls the (slow) line-lookup macro every time through the loop. It is exactly the same code in the end, you simply have to move one macro call from A to B in the code. According to his later articles, this was done deliberately so you could CONT after breaking in a loop, but honestly, that always sounded like a post-facto explanation. What's amazing about that particular issue is that when I was in university my computer languages book had a list of 10 commandments on the inside cover. Among them was "distributed costs", which was essentially don't make a statement do something general if the 99% use is very specific. This is precisely what AB did - by adding a feature that might be used 1 in 1000 times, they slowed down every program every time it ran. One can give them a bye on the GOTO issue, as that would require more code, but the FOR/NEXT is simply a wrong decision that was never fixed.

Mine failed, although it was still usable. The glue holding the layers together on the left side of the keyboard started to come off. Eventually one of the keys, I can't recall exactly but I think control, "bubbled up" so that the top plastic layer was convex rather than concave. It still worked, but every press caused the plastic to move further than its design, and eventually it began to break off along the bottom white ridge. It was only a matter of time before it broke off completely, although it lasted me 3 years so likely at least that again. I may be the only person to actually prefer the 400 keyboard to the 800. Once I got used to it I could type just as fast as any other keyboard. When, several years later, I got the chance to use an 800, I found the keys to be very short throw and not comfortable for someone coming from the VT-102 world. I understand the 1200 was the best-in-class, but I have never seen one in the flesh.

It is not clear what "dog" refers to in this case. Normally that would refer to performance, as in "dog slow", but your following list is mostly feature related. If we are talking about performance, there's really nothing dog-like about it. As it runs basically the same underlying code as practically every other platform of the era (Atari and TI-99 being the obvious exceptions), I would not say "dog" but instead "baseline". One could also say that applies to the features. To be dog slow, one would have to run much slower than MS. I recall when I first started reading the original 6502 MS code. I understood how BASICs worked from descriptions of Atari found in magazines, so I simply assumed all BASICs worked that way. When I read the MS code I was gobsmacked - it doesn't tokenize anything other than keywords? It re-parses constants every time through the code? It leaves things in a weird mash of pre-interpreted and original source code? What madness is this?! The fact that MS has to, for instance, re-parse the "100" in "GOTO 100" every time through a loop and that it still runs 2 to 3x faster than Atari BASIC is downright breathtaking. Now AB... that is the definition of "dog slow".

I'm keeping a running list here: https://github.com/maurymarkowitz/Atari-BASIC-benchmarks/blob/main/RESULTS.md Just got off the phone with Jim Galbreath, author of the original 1981 Byte Sieve. I was trying to track down the version of BASIC used in the original listing, as it doesn't match anything I've seen (and its missing some line numbers). Its at the bottom the page here. He said his son wrote that version, but he's in the car driving to California so I don't expect an answer until at least Sunday. Some interesting points: 1) can anyone explain the strange result for MS BASIC running broucke? It's significantly slower than any other variety, even Atari, but nothing in the source seems to suggest a reason, it's just loops and simple math, which MS is generally better at across the board 2) All of the math-pack versions put paid to the argument that binary math is faster than BCD. As you can see, XE and Turbo both run at least on the same performance level, somewhat faster on the rugg8 tests and somewhat slower (although only slightly) in the maths test in scruss 3) another curiosity is Turbo's performance of the for loop relative to XE in fast mode. This would seem to suggest that XE's math is slower? But the relative difference in the math test suggests this is not the source of the difference.

I'm sure this exists but by google-fu is failing. Does anyone have a version of a ROM file that can be used in the Atari800 emulator (which I assume works on other emus as well?) that has had the original Atari FP libraries replaced with the ones from Newell? Yes, previous thread same topic, but no direct results there.