Jump to content

Maury Markowitz

  • Content Count

  • Joined

  • Last visited

Community Reputation

30 Excellent

About Maury Markowitz

  • Rank
    Chopper Commander

Recent Profile Visitors

4,635 profile views
  1. Neither of which has a ROM file that can be used with the Atari800 emulator.
  2. 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.
  3. 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.
  4. 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".
  5. 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.
  6. 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.
  7. 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.
  8. In the early 1980s I visited a neighbour’s house here in Canada. His father was an engineer (SPAR Aerospace IIRC) and the house was filled with every gadget of the era. Among these was a computer trainer I had seen in catalogs and I’m trying to identify it. The key feature of the system was a display consisting of a 4x4 (or 5x5?) grid of red LEDs lamps in a panel that was raised above the main desk-top console on two cylindrical supports. This placed the display at eye level. I recall the panel itself was oval shaped. This is the key feature, if you’re going to suggest a potential system and it does not include this display, it is not the system in question. I recall 8-segment LEDs being for score keeping but I am no longer sure if they were on the display panel or on the base unit. The rest of the unit was a simple desktop box with a hex pad in the lower right. Poking about in Google Images, it is overall similar in layout as the ELF II and I would not be surprised if it was based on this system. All I recall running on it was a Pong clone where the ball moved back and forth on the LED lamps. As I had seen it in a catalog, that almost certainly suggests it was Tandy/Radio Shack, but looking through historical catalogs from 1978 to 1982 I cannot find anything similar - just those 150-in-1 kits where you wire together using springs. That might suggest Heathkit, but they were not terribly popular in Canada and I can’t find anything like that in their catalogs either. I have a dim memory of the system being offered by two companies, that it was actually produced by one and was being white labeled by another… again, that strongly suggests the second company was Tandy. Anyone have any ideas?
  9. Does anyone have a pointer to an 800XL-compatible Atari ROM that has Fastchip ROMs in place of the original Atari FP? I thought this would be easy to find but my google-fu is failing me.
  10. Sure, but then it's no longer the same benchmark. The conditions of the test are just as important as the code. Can you run the first set in ANTIC 0?
  11. ... thereby eliminating the CPU waiting on memory. Perhaps there is some other term than "wait state" I should use? In any event, these numbers are not the same conditions, which explains the different numbers.
  12. "Original XB 24k of GROM"... "Original XB 16K of ROM"... so did XB have both ROM and GROM for a total of 32 k?
  13. These numbers are significantly higher than what I got under Atari800Mac for Turbo 1.5. I got an overall Index of 164. Does running under the XEP get rid of wait states perhaps?
  14. I'm adding these to the results table, is this with Atari's original math package, or a different one?
  • Create New...