Ah, that's great. I hadn't remembered that (nor had I recalled the direct string comparison, but I don't think I use the equivalent in mine).

One of the major speed issues is that LEFT$/MID$/RIGHT$ creates temporary string, which beyond just the work to do that, causes garbage collection pressure as well. It would be ideal if there were an ASC(string [,index]) to directly get a character from anywhere in the string without allocation, instead of having to create all these 1-char strings as other portions of the code need.


A big issue is getting the instruction encodings in such a way that both the assembler & disassembler can reuse the same reference information. In the style you had, an assembler (if you planned on adding one) would have to have its own solution.

If everything is held in arrays, that would make it a lot faster, but then the arrays need initializing, usually by a bunch of DATA statements. Re-reading from DATA means that I don't have an init speed hit, and probably save a kilobyte or more of just array infrastructure overhead, but it is still relatively slow on a per-instruction basis. (Of course, if you're using a compiler, then some of these issues may not be in play as it is with these ROM-based interpreter platforms.)

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

That is the main reason I never considered using BASIC for serious development, at least on 8-bit platforms.



It was never intended to be a real monitor; I needed some code to run through the compiler and almost everything I found needed either arrays or floating point support, both of which I lack.



There is no technical reason the language could not have been extended to allow read and write to individual characters in a string. That would eliminate the heap churning.

The memory dump code in the monitor I uploaded is very slow, even in the compiled form. I suspect it is because I am building up each line of output in a string instead of PRINTing it as I go.

DEC-style BASIC string handling is very powerful, but a bit resource-hungry. HP-style BASIC string handling (as seen in Woz Integer BASIC) can usually get you there more efficiently, but needs careful and sometimes clumsy translation effort if you're starting with a DEC-style source (or vice-versa). I used to translate some Integer BASIC programs to Applesoft before I got my disk drive and language card for my ][+, and that was a sticky point. Another was the way that Integer BASIC's IF/THEN would only skip one statement for a false condition, instead of the remainder of the multi-statement line.

Of course, translating HeyMon to Integer BASIC would require a complete re-design, because Woz inexplicably left CHR$(), READ, DATA and RESTORE out of the language! I have a back-burner project to add those and WozFloats (probably using the default FORTRAN naming convention), but I lack the time, talent and motivation to allow myself to provide an estimate on the time frame for that creation ... a 50th anniversary Enhanced WozBASIC with cross-platform capabilities isn't entirely out of the question, but I'm definitely not making any commitments.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I suspect a major reason for some (many?) of the infelicities of Woz's Integer BASIC was that (as I understand it) it never had source code: the initial versions were hand assembled and the machine code was modified from that point on. Obviously this makes extensive modifications a bit tricky, and that may be the reason that the Apple II's floating point library was incorporated into the ROM but Integer BASIC never used it.

So to be true to the spirit of Integer BASIC, I think you should make your modifications to the machine-language version, too, and not spoil the whole thing by introducing assembly language source code. The 50th anniversary is coming up: tick, tick! :-)

(Side note: A year or two ago I wrote a little monitor in C64 BASIC as well, though nothing so sophisticated as this one. It didn't go much further than the bare minimum I needed it the time because it painfully reminded me of what, among the many miseries of BASIC programming, is surely the greatest misery: every variable is global. It's worse than even assembler that way, where at least you have stacks easily available.)

_________________
Curt J. Sampson - github.com/0cjs

Also the original name, AIUI, was Game BASIC and Woz didn't think floats were needed in that scenario...

It's also possible that things were speeding up, the Apple II -> IIplus, the DISK II and other hardware, markets opening up, and just buying (and modifying) MS Basic into Applesoft may well have been an easier route (at least from a marketing point of view) so who knows.



It all depends on the BASIC (and assembler) - in 1981 I had a 6502 BASIC with named procedures and functions with local variables... And in all the early assemblers I used all variables, labels, etc. were global too - as there wasn't a linker - you simply included files in-line and hoped for the best..

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

My understanding is that that was the original name, yes, but it wasn't that he didn't think floats were needed; it was just that it was a lot faster to get the thing out with only integer support.


Yes, according to Wikipedia around the time the need for FP support was getting urgent Woz was deep into Disk II design and so wasn't available to hack on BASIC. And with no source code available, it's certainly reasonable that the fastest thing to do was just to license an already working BASIC from someone else.


Well, having a linker or not is orthogonal to this. I switched from linking to whole-program assembly pretty quickly when I restarted 6502 assembly a couple of years back, but that didn't at all affect my ability to have local symbols. (It improved it, in fact, but that's just because I switched to an assembler with better support for it.)

But I was actually thinking of the ability to, e.g., PSH and POP to save variables as providing run-time local storage. BASIC has nothing to let you do that, unless you write something that itself has to use global variables. That said, even labels in assemblers with only global labels never seemed as bad as BASIC, and I now recall the other part of the problem, which was having only two significant characters in variable names. That, combined with the lack of local variables, is what destroyed any possible enjoyment I could have gotten from programming in BASIC.

_________________
Curt J. Sampson - github.com/0cjs

BASIC, as in Structured BASIC/SBASIC (c1976) - as a spin-off from the original Dartmouth BASIC, has local variables (as far as I can tell). The issue is - from my point of view - it all went downhill from there when the populous jumped into the 8-bit micro era - it was relatively easy to get a BASIC going, but the limitations of the cheaper systems limited the BASICs at the time...

So I really think that differentiating between BASICs is essential here. The original Dartmouth BASIC didn't have locals, early 8-bit MS Basics don't have locals, but BBC Basic (c1981) does have locals (and recursion). My own BASIC (RTB) also has locals and recursion, but I wrote most of that (only) 10 years ago. There are many "modern" BASICs that do have these features.

A simple BBC Basic example:


Personally I think it's a shame that MS BASIC seems to be some sort of de-facto standard for BASICs, especially when we talk about the 8-bitter era microcomputers.

But if you do want to PUSH/POP variables - it's not hard in these old BASICs to do in a subroutine - just keep an array and a pointer, store at pointer, increment pointer on entry, and do the reverse on exit. Clumsy, but workable.




-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Not really, no. Through the mid 1980s, when ROM BASIC finally started going away, the vast majority of the installed base had a BASIC that did not have local variables or much else in the realm of structured programming features. You can point out the exceptions all you like, but they amount to almost nothing compared to the number of C64s, Spectrums, TRS-80s, Apple IIs, MSXs, PC-6/8/9001s, FM-7s, and on and on.


And here we see that "early" versus "late" seems to make no difference as far as ROM BASICs are concerned. The new MSX2 machines coming out in 1985 had no locals, still had 2-character variable names, and so on.


Sure. And do you see how it suffers from the exact same problem that made me want some sort of local storage in the first place? (Answer: it still uses global variables and still goes terribly wrong if you ever accidentally combine it in the same program with a different subroutine that uses `SP` or whatever you chose for a different purpose.)


Ok, this next bit, though factually correct, tends to be taken as a massive personal insult by some people, so if you're going to reply to it I suggest you start a new thread. This is not an issue with MS BASIC. It's an issue with BASIC itself: it started out as a stripped-down FORTRAN for interactive use and, while the Dartmouth folks did something very good when they took the ideas of interactive use and automatic memory managemet from the LISP folks¹ they did something very crippling to programmers when they didn't also take the ideas of functions and local parameters. (I think that these, along with not needing line numbers, were both ideas that were in FORTRAN by that point, too, or at least arriving soon.) You can complain all you want that BASIC should be structured, but that's not what the people who wrote BASIC wanted nor was it what the people who chose BASIC in the 60s and early 70s were looking for; they had other interactive options with these features and went for BASIC instead. BASIC for most of its actively used life was exactly what it was designed to be: an unstructured language.

___________________
¹ Yes, Kurtz and Kemeny visited MIT in 1961, saw LISP and even talked to McCarthy, who was the one who gave them the sugestion that they use timesharing for their efforts to bring computing to the masses.

_________________
Curt J. Sampson - github.com/0cjs

I don't at all dispute the great popularity or importance of MS Basic, but I can't consider other implementations to be out of scope.

Let's not butt heads over how much history we know, or how wide our experience is. Let's learn from each other, and enjoy it.

At age 13 I learned how to program on the TRS-80 Level 1 (a lightly-modified Tiny BASIC), so when my school upgraded to Level 2 (a "deluxe" at the time MS BASIC) I was suitably impressed. It was easy to put Level 1 behind me, but through my teenage years in my part of the world MS BASIC (not unlike Windoze later) had proliferated to the point that the only easy escape for me was assembly language. I still use MS BASIC for quick-and-dirty experiments, because the unstructured code just flows from my brain with minimal effort and allows me to concentrate on the experiment instead of the language. Its interactive nature also makes debugging less of a chore. Love him or hate him, it's difficult to deny that Mr. Gate$ knew what he was doing.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)