Jump to content

Maury Markowitz

Members
  • Posts

    222
  • Joined

  • Last visited

Posts posted by Maury Markowitz

  1. I'd like to write a wikipedia article on Word Writer ST, which was probably the most popular non-freeware word processor on the platform. I have all the details I need for the description of the program itself, and found a number of good reviews (including the NYT no less). However, I'm utterly lacking anything on the company, Timeworks, or anything about who might have programmed it.

     

    Does anyone know anything of the history of this product or the company?

  2. I'm writing an article on WordUP.

     

    I'm wondering if anyone knows whether Mike Fulton or Shelby Moore are still out there on the interwebs?

     

    I found Mike Fulton Consulting, but it bounces. His last post is from 6 years ago, so I'm concerned... Shelby's most recent post speaks of health problems due to undiagnosed TB (!!!) but I do see posts around the 'net from 2021.

     

    If anyone has any working contact info, please feel free to pass along my contact info. It's my first and last name with a dot between them on gmail.

     

    Thanks!

  3. I'm playing about with AtariWriter Plus. One of its key features is horizontal scrolling, which is invoked using option-C. I assume they mean the same option key I'm thinking of. Yet every attempt I've made to invoke this command has failed.

     

    On Atari800(Mac) the Option key is in a separate window, or using F2. However, neither of these options seems to work. I strongly suspect that when you hold down the "key" in the window it no longer receives other keystrokes (but how to tell?) and the fn-F2-c seems to trigger the new control panel gizmo.

     

    Anyone know the trick here?

  4. ... has anyone come across it being reviewed for the 8-bit in a contemporary source? There's a number of modern reviews and playthroughs, but I can't seem to find anything from the 1980s except a mention of one in a compendium book and a short capsule review in Antic.

     

    It was released during "the troubles" but I suspect someone else must have talked about it, even if it was a user group newsletter. Anyone recall any?

  5. Does anyone have an 815 and might upload some images to the Wiki Commons?

     

    I mention the 815 in the wiki articles on the 810 and 551, but don't have an image, and the 810 article in particular can really use it.

     

    No, don't bother googling up images, they have to be ones you took due to copyright issues.

  6. 4 hours ago, thorfdbg said:

    Yup, reading the 6502 specifications for one thing. (-; The decimal flag is only honored by ADC and SBC, and thus not by INC and DEC. If you want to increment a BCD number, the only option is ADC. Or performing a half-carry check manually.

    Instead I first check if the number is less than 99, at which point a carry is impossible and INC works fine.

  7. Just started playing with MAC/65, OMG I wish I had this as a kid! DDT is amazeballs! Anyway, check this out:

    10 .ORG $4000
    20 .FLOAT 123456789
    30 SED
    40 INC $4005

    When you ASM this and look at $4000, you have:

    44 01 23 45 67 89

    Now G 4006. This will SED into BCD mode and then increment the last number. The result is:

     

    44 01 23 45 67 8A

    THAT'S interesting! Did I miss a step here? Or does the 6502 simply not consider BCD in INC?

     

     

  8. I'm curious about the passage on page 8-45 of De Re where it's talking about the memory representation of FP. The last two examples are:

     

    Number: 37.0 = 37 * 100**0

     

    Format: 40 37 00 00 00 00  (exponent= 40+0)

     

    Number: -460312 = -46.0312 * 100**2

     

    Format: C2 46 03 12 00 00  (exponent= 80+40+2)

     

    So I'm wondering what the rule is here... is it simply that the exponent is changed until the leftmost digit of the mantissa is non-zero?

     

    Does this imply that anything with exponent 100**0 ... 100**4  (40 ... 44) is directly readable? IE:

     

    Number: 123456.0 = 12.3456 * 100**4

    Format: 44 12 34 56 00 00  (exponent= 40+4)

  9. On 1/2/2022 at 4:32 PM, Alfred said:

    All FAST does is replace all references to a line number with the address of that line number.

    But it can't just be that, can it? It must store the original line number somewhere.

     

    If it doesn't, there would be no way to look up the new address when the BASIC code changes and causes the stored address to change. If the user inserts line 4955, and as a result line GOTO 5000 moves from $7564 to $7578, it has to know the original line number so it can look it up the new address. Failing to store the original number would also mean LIST would have to look up every address to get the line number.

     

    I assume it folds the original number and address together? Or has a separate store? Or maybe I completely misunderstand how it works?

  10. I don't know how I did not come across this earlier; in the September 1982 Insight Atari, Bill posted a short benchmark to compare variations of BASIC on the Atari - along with Applesoft as a comparison. Here are the results (at the bottom of the page).

     

    The bench is fascinating - it's clearly written specifically to make AB look good. Ultimately all it does is loop 10,000 times doing a simple addition in the middle of the loop. Typically one would use a FOR/NEXT for this sort of task, but in this case it uses a branch. This plays to AB in two ways, one is that FOR performance in AB is (comparatively) very poor, and the other is that backward branches do not take advantage of that little tweak in MS BASIC's so both are searching from the top in both cases.

    The modified versions are designed to illustrate some edge cases, but again, they are carefully selected to play into AB's strengths. Note for instance that version B uses ONE more decimal place. This triggers MS's double-precision mode and slows it down, but is still within AB's single-precision format limit. If you add one more decimal MS continues to work (albeit slowly) while AB now fails to give the proper result.

     

    The next two variations in the original article add long variable names that differ only in the last letter, which forces MS to do string searches across the entire variable name. This is not quite so much a cheat, but one might consider that most MS's don't support these at all, so this is really testing "Atari MS BASIC" vs AB, not AB vs the MS hoi polloi.

     

    In spite of any of that, there's still some really interesting bits one can find in these tests. For instance, note the difference in time between the a and c variations using ABrevC. The c version simply replaces a single numeric constant with a variable containing the same value. So the slight difference in time, .5 seconds, appears to be the 10,000 executions of the quarter page of assembler needed to look up the value from the variable table. This is a very useful bit of data!

     

    What's even more interesting is the comparisons with other BASICs on the platform. One would not expect, for instance, BASIC XL to be much faster than AB without using FAST, but as you can see, it runs these tests roughly twice as fast across the board! And that's *without* a new math library or FAST. Note that this test has only a single branch and it's in a tiny program, but in spite of that, FAST mode still shaves a whopping 5.5 seconds off the times. The same is true in the XE versions, where adding FAST also results in just over 5 seconds improvement.  But in that case, we gain even more insight from the fact that replacing the math library speeds things by almost 11 seconds.

     

    Note that in this bench, XL and XE manage to outperform Turbo by some reasonable amount. I attribute this to the fact that the entire program fits within the first "group" of line numbers and thus gains nothing from their caching concept. It is surprising that XE's math lib outperforms it in this case, as I've yet to see an example of that in the past - but of course there's no multiplication in this example so Turbo's real improvements aren't being kicked in.

    • Like 2
  11. 10 minutes ago, _The Doctor__ said:

    I think you are being rhetorical. I didn't like the change they made, I somehow missed "the word exactly in the topic' Moving on... I vaguely remember this same conversation either here on AA or in the WIKI at some point. It's a good bet the answers were given either in those or some conversation about the two different cart images when used in an emulator/multi cart. Ultimately I think the consensus was there was little to no reason to have changed it and some other discussion about the extensions disk came into play and took the conversation over. Is there a purpose in mind, perhaps to make a unified version?

    I think my OP explains my question quite well. I have no other "purpose in mind" except to understand what is going on.

     

    The original claim you made about this happening because it does nothing in immediate mode appears to be incorrect. You then modified your answer to state it was due to differences between XL and XE, but I examined that possibility and see no differences that would explain it.

     

    If you don't know, fine, but don't pretend this is me being argumentative. Your answers appear to be wrong, and pointing that out is hardly being "rhetorical".

     

    If you have a pointer to the thread you mention, I will be happy to read it, but the only thing search turns up is one I posted some time ago on FAST that is unrelated.

  12. I was running Bill Wilkinson's looping tests from the September 1982 Insight Atari and noticed something odd.

     

    Previously I though that after typing in a program if you did FAST in immediate mode it was the same as doing it in the program. However, when I added a "1 FAST" to the programs, they sped up.

     

    So I don't think I completely understand FAST, can someone explain this?

×
×
  • Create New...