Jump to content

Maury Markowitz

Members
  • Content Count

    161
  • Joined

  • Last visited

Community Reputation

31 Excellent

About Maury Markowitz

  • Rank
    Chopper Commander

Recent Profile Visitors

4,691 profile views
  1. Not according to Grammarly, which changes it without telling me.
  2. And the prize goes to Scorpio! It's surprising how little-known this game is.
  3. 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.
  4. 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.
  5. ...and then seconds later found it, John Jainschigg
  6. 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?
  7. Neither of which has a ROM file that can be used with the Atari800 emulator.
  8. 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.
  9. 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.
  10. 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".
  11. 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.
  12. 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.
  13. A seven page thread over whether or not turning off DMA is valid, complete with name-calling etc. Unexpected! So let me simplify matters as the author of the repo in question: The benchmarks should be run in Antic Mode 0 with the screen turned on. Any other display is considered an invalid test. Changes to the math pack - not the rest of the ROM - are allowed, but have to be clearly identified.
×
×
  • Create New...