Jump to content

Maury Markowitz

Members
  • Content Count

    113
  • Joined

  • Last visited

Community Reputation

15 Good

About Maury Markowitz

  • Rank
    Chopper Commander

Recent Profile Visitors

4,213 profile views
  1. Uhhh, it is. This is a program that decodes Atari BASIC programs into text files.
  2. So the code in question is so old that it will not run on any modern Windows machine. I downloaded the source, did some touchups for modern VS c++, and built a new version called ChkBase64. The name is inaccurate, it's really 32-bit as well, but it works. Is there a place I should upload the binary for other to use?
  3. There is an older 2012 thread on converting Atari BASIC programs to text format. At the time, it required the programs to be loaded into an emulator and then LISTed out to H Has there been: 1) any improvement in this? I would like to convert every file in the Antic Software Collection and any others one might suggest so this would be sometime time consuming 2) has someone already done this? Is there an archive of text format Atari BASIC programs out there?
  4. 10 PRINT "Asteroids. You lose, insert another quarter." Describes my attempts to play it, anyway.
  5. Ok, so this is ultimately wrong. Yes, it DOES post the line number, but it does so only so it can report the line on which an error might have occured. The actual pointer to the code to run is in TXTPTR, which is the address of the code to run. eval.s uses that pointer to loop back to the top in the NEXT. Which brings us back to why Atari BASIC didn't do this? MS would simply refuse to continue if you changed practically anything, and while this is perhaps going too far, in this case the massive upside of loops would seem to argue that this is a reasonable tradeoff.
  6. I asked on SO, but it seems that's drawing a blank, so maybe someone here knows. I was always under the impression that MS BASIC implemented NEXT by pushing the address of the FOR on the stack. So convinced that when I read the source code I assumed CURLIN had to be referring to the address, not the line number. Quelle surprise! Now recall that MS BASIC does NOT allow you to add or remove lines during a STOP/CONT - anything that might change addresses will cause the CONT to fail. So they didn't use the line number in order to allow CONT after modifying the code. So why did they then? If you used the address the NEXT code gets a bunch of lines shorter and a whole lot faster.
  7. But that's not true, the original basic, Dartmouth, was a compiler. This became common later, indeed, but it is not clear to me that they ever considered stop-n-go to be important.
  8. I am looking at the code, it seems to push CURLIN and TXTPTR, isn't that the address into the line?
  9. Sure, but it seems like a HUGE cost to pay! That seems like a simple solution!
  10. I'm on page 19 of the Atari Source Book. It shows how the FOR statement pushes an entry containing the line number so the NEXT can find it again. But why a line number? Why didn't they push the address of the line and/or individual statement on the line? I'm reading the MS code on github and it appears that's what they do - well if I'm reading it correctly they pop off until they get to the address and then RTS. I'm not sure I totally understand the stack use though.
  11. Therein lies the rub, this question is ultimately about parsing, but because MS has its own math there's no trivial way to directly compare the two, the changes to the underlying math routines would make it difficult to figure out how much the parser is eating up. Well, I guess running it in cc65 might do it...
  12. There's been much discussion over the years about the floating point system in Atari BASIC, but one topic that doesn't get so much attention is strings. AB had pre-defined string lengths, like HP BASIC. These sat in the heap and were pointed to from the variable table. Upsides and downsides are well defined. MS used a linked list of strings (IIRC) and did GC when required. BBC used a similar system, but just coughed a out-of-memory instead of any sort of GC. Are these the only approaches that have been used in BASICs?
  13. Well that makes sense, because if you end up having to start a GOTO you have the number right there. But... a) just store both, it's two freaking bytes b) the line number is +2 bytes in from the line start, it can't be that expensive to deref it BTW I did see your original message, no blocking, I just didn't notice this very interesting bit of it.
  14. Wait, I totally missed this too... why the heck does it do this?!
×
×
  • Create New...