Jump to content

BASIC 2? Why not get BASIC 7?


Recommended Posts

4 hours ago, Scott Robison said:

I may be in the minority, but Commodore BASIC v2 is responsible for getting me started!

PET BASIC 4.0 was responsible for getting me started, which is more or less BASIC 2 (we didn't use the disk commands so much).

 

Link to comment
Share on other sites

9 hours ago, Scott Robison said:

I may be in the minority, but Commodore BASIC v2 is responsible for getting me started! Sure, there are a lot of things missing WRT modern languages, but I firmly believe that learning any language is a useful exercise to get one to begin thinking in a programmer mindset. And the more languages you learn, the better off you are because you being to contemplate programming in the abstract (input, output, variables, conditionals, control structures) instead of the concrete (INPUT, PRINT, A$, IF X=Y THEN ...).

I know there are plenty of people who believe "avoid these toy languages because you'll learn bad habits" or other similar arguments. For learning the basics (pun not intended but apropos) of how to write a program to tell a computer what to do, BASIC is great.

Not every language must lead directly to a six figure income.

Then of course there is assembly / machine language. Talk about a language without modern first class features like functions! 🙂

Indeed, one advantage of Basic is that is it NOT a "watered down version of a popular modern language", so people who start learning to program on Basic know that they don't know how to program in Java or Python or R or C++ or uhhhh ... Clojure. If the language WAS an aggressively watered down version of a more popular modern language, there would indeed be some people who would be, "yeah, I know how this works" when they set down in front of a real version of those languages, and would set about using all of the bad habits for those languages that they learned because it was how you had to do it in a version of the language stripped down to be able to run on an 8bit processor with, for a base set-up, 558K of RAM.

If the CX16 picks up a niche in education in addition to its core niches, it will be because of the "an entire system you can understand completely" nature of it, not because it's a great sandbox for learning to program Python or R or C++ or Clojure. For that kind of sandbox, a Raspberry Pi will always beat it, hands down.

And of course the biggest language by job listings citations is SQL, so before worrying about a Small-Python, the first target on that track would be a CX16-SQL database manager. 😉

  • Like 1
Link to comment
Share on other sites

The problem with BASIC is that it is an evolutionary dead end as programming languages go. And BASIC v2 is not even very far down that dead end, it's extremely limited and forces the use of very poor programming habits.

Now, in the interest of shipping the product as well as having some compatibility with the most popular computer ever, it's not a bad idea to go for a slightly extended BASIC v2 now.

But if the Commander X16 is going to be an educational tool in addition to something those of us of a certain age can use to relive our youth, then something better than BASIC (v2) is warranted.

I've seen Forth being suggested. I liked it back in the day, but the RPN is weird and it's also extremely far from the programming main stream.

I barely know Python myself, but when I started looking at it I was struck at how friendly it comes across doing away with the annoying syntax of C-based languages. And except for any time a GOTO appears, it's actually pretty straightforward to convert BASIC to Python. The main issues are that function definitions must come at the beginning of the program and you must explicitly declare global variables. But these are not issues when writing something from scratch.

Even many statements and functions are the same between Python and BASIC, and the missing ones can be added in Python with just a few lines of code.

So the main issue with Python on an 8-bit system is that the language is just too big and too complex. But by simply omitting any features that go beyond what BASIC can do, it should be shoehornable into a system like the X16.

This means that you will be unlikely to run existing Python code on the X16, but the other way around (X16 program on a real Python system) should work as long as you don't use any of the X16's hardware features.

And although I'd say if you want to learn Python, just learn the real thing, it's definitely helpful for people who learn to program on the X16 to be able to take those skills to more modern systems rather than have to start from scratch.

Link to comment
Share on other sites

27 minutes ago, iljitsch said:

The problem with BASIC is that it is an evolutionary dead end as programming languages go. And BASIC v2 is not even very far down that dead end, it's extremely limited and forces the use of very poor programming habits.

The single best (as in most valuable to me) programming class in college (the first time I tried in the 1980s) was a FORTRAN 77 class. I did not have many of the modern niceties. Sure, it had subroutines and functions, but it didn't have many typical control structures. But the reason it was a great class was not because FORTRAN 77 was a great language (though there are things written 50 or more years ago still being maintained because Fortran is great at what it does). It was a great class because the instructor taught it not as a FORTRAN 77 class, he taught it as a learning to program class. So he actually took the time to show "you should use a WHILE loop in this case; FORTRAN 77 doesn't have a while loop, so you would write it as an IF condition with a GOTO to exit the loop, and a GOTO at the bottom to return to the top.

In my experience of managing and interviewing engineers over the years, there are far too many who are completely lost when they don't have their tool box. They don't know how to adapt. They don't know how to craft a tool that isn't already in their toolbox when needed.

One common question we would ask engineers, just to weed out ones that couldn't cut it, was to write in pseudocode a routine to reverse the characters in a string. We were in a C# shop at this point, and I was shocked at how many BSCS grads could not do it without resorting to a standard library function. The point wasn't that we expected them to write a bunch of string reverse code from scratch. Clearly the standard library would be the best way to accomplish this in production code in most cases. But there are many algorithms / decisions for business logic that will not be in the standard library, and if they can't reverse the characters in a string without a "strrev" function or similar, we knew they were't going to be a good fit for our organization. Note: Just because they *could* write up a strrev didn't mean they *would* be a good fit, but it was a good first step.

So I disagree fundamentally that BASIC is a dead-end language if what you are trying to do is learn logic and program structure. There are ways to write BASIC in a "pretty" way to ensure that it is "structured" even if it must use GOTO. The problem with GOTO isn't that it exists, the problem is that it isn't used well.

Now, I'm not advocating that everyone should be forced to write in BASIC v2 before moving on to other languages, but it could be taught in a way that allows BASIC programmers to adapt to other languages, once they understand that the BASIC incantation for "PRINT" is knowns as "PRINTLN" in Java or "printf" in C "std::cout" in C++. Yes, the syntax is different, but they ultimately do the same things. That's what I think a good programmer / engineer does. They know there are a bunch of types of screwdrivers and wrenches and pliers and other tools. Some are better suited for certain tasks, but in a pinch, you can adapt and use a less capable tool when you must. BASIC is that limited toolbox that can help you learn about the "basics" of tools that you will encounter as an engineer.

In like fashion, 6502 ML isn't a dead end either any more than x86-16 is a dead end in a world of x86-32 or x86-64. They all allow one to learn how CPUs work at a low level and that knowledge can be translated to other platforms.

Circling back to the interview of programmers who are lost when their library doesn't provide the exact tool they need: That doesn't make them bad. There are jobs for people who know how to do particular tasks, and they are good and necessary jobs. I would not be a good fit for a webdev position given my specialty which made me stand out to my employer and which results in regular contacts from recruiters trying to hire me away. A webdev would not be a good match for what I do. Specialization can be a good thing, but so can generalization. It's allowed me to work a number of different industries and with multiple programming languages. Could I do webdev? Probably. I just am not interested in it, so I'm glad there are others who are, and I'm glad my skills are not shared by as many which increases my value in projects that require high performance on custom platforms.

  • Like 2
Link to comment
Share on other sites

Dead end as in: it has no living descendants. (At least not as far as I know / recognize.) Obviously you can learn programming in BASIC, as I did myself many moons ago. But structure in BASIC is write-only: perhaps you used GOTOs the most structured way possible. But someone reading the code won't be able to tell. (This is actually also true for imperative constructs like FOR loops, where declarative would be better, but let's not get carried away.)

The structure thing is actually not the worst problem. That can be fixed by extending IF / THEN to IF / THEN / ELSE / ENDIF.

A much more nefarious issue is that you can't use functions like you can in other languages. In BASIC you can define a function, but  but that's in the mathematical sense of the word: you can only use it to calculate something.

With proper functions, people could for instance write their own graphics routines and others could improve those, with no need to lobby the X16 development team for specific additions to BASIC. Having the community extend the language in an organic fashion would be pretty cool.

Actually in my opinion, for someone who knows they want to learn how to program and will commit to the time required up front, I'd recommend C. Although not easy, it's small enough that you can learn the whole thing reasonably quickly and because it's low level in many ways, you learn a whole bunch of computer architecture in the process. But it's still high level enough to get reasonable things done in a reasonable amount of time. And even if you then never program in C again, you're in a good position to learn a good number of other languages.

If you want quick and cool results on something modern, I'd say Javascript along with HTML and CSS. And just like back in the day on an 8-bit home computer, you're not going to understand much of what you're doing for some time, let alone what a lot of other people's code does, but you can do a lot by copying other people's code and tinkering with it.

It's surprising how tinkering with web stuff is the closest thing I've experienced the past decades to experimenting with programming on my C128 back in the day. For instance, I wrote some Javascript to make my Hue lights do things that the apps that are available won't do, which was extremely satisfying.

Oh, by the way:

A$="ABCDE":B$="":FORI=LEN(A$)TO1STEP-1:B$=B$+MID$(A$,I,1):NEXT:PRINTB$

Life was so much simpler before Unicode. 😃

Link to comment
Share on other sites

The thing about the friendliness of Python is it HAS that friendliness because of burning cycles to create it. Assuming that a computer has the cycles to burn on resolving ambiguities based on what is being operated on is a lot more tenuous in an 8bit system. C was originally created in the days of teletypes to access mini computers, so has a syntax that is less tolerant of ambiguity. 

  • Like 2
Link to comment
Share on other sites

What kind of ambiguity do you have in mind?

Again: I'm not advocating for anything resembling the full Python that exists today. That is possibly even too much for an Amiga, and famously a non-goal of Python is to be fast. They handsomely non-reach that goal.

After programming in C, PHP and Javascript for a long time the lack of { } and ; in Python was a revelation. Creating structure through indentation is a bit weird, but probably the best/easiest way to do it.

Obviously "real" functions would be quite different from BASIC, and replacing GOSUB subroutines with functions is a bit annoying as the latter usually go at the end but Python functions need to go at the beginning. Other than that, the differences between BASIC and Python are actually relatively small. I could easily see Python be tokenized like Commodore BASIC, although of course there would have to be a system to create new tokens for new functions.

Link to comment
Share on other sites

1 hour ago, iljitsch said:

A much more nefarious issue is that you can't use functions like you can in other languages.

This has been false since the 80s for Microsoft Basic, and earlier than the 80s for some minicomputer Basics. Similar to that fact that Microsoft Basic has had DO UNTIL expr ... LOOP, DO WHILE expr ... LOOP, DO ... LOOP UNTIL expr, and DO ... LOOP WHILE expr since the 80s.

Simply stop saying "Basic can't ..." when you mean "CBM Basic can't" for the functions with local variables, or "CBM V2 Basic can't" for the DO LOOP and IF expr THEN ...:ELSE ... that the CBM V7 had. It often converts true claims into falsehoods.

 

Link to comment
Share on other sites

1 hour ago, BruceMcF said:

Simply stop saying "Basic can't ..." when you mean "CBM Basic can't"

Well, how many things do you need to add to BASIC (and take away) before it's not really BASIC anymore?

We're talking about different flavors of Commodore BASIC here...

Link to comment
Share on other sites

Posted (edited)
1 hour ago, iljitsch said:

Well, how many things do you need to add to BASIC (and take away) before it's not really BASIC anymore?

We're talking about different flavors of Commodore BASIC here...

On your first question, anything in QBasic is obviously "still Basic", and QBasic has full fledged functions and procedures with local variables. It ran on the original IBM PC, so it COULD well be implemented for the more powerful CX16. So I don't worry about the general philosophical question of how many things you need to add to Basic before it's not really Basic anymore.

As far as "we are talking about different flavors of Commodore Basic here", ... setting aside that when you go into "evolutionary dead ends" you are clearly NOT talking about ONLY different flavors of Commodore Basic, here, but talking about the Basic programming language more generally ...

... sometimes TTSIA ... it doesn't ask "Basic? Why not get Basic?", it asks "Basic 2? Why not get Basic 7?" Just talking about DIFFERENT flavors of Commodore Basic requires being more specific than "Basic".

And yet again, if something is a part of an argument about "why Basic should be abandoned", it bears making a distinction between "Basic 2 can't" and "Basic 2 doesn't". After all, a number of things that "Basic 2 doesn't" on the C64 are things that Basic 2 does on the CX16.

Edited by BruceMcF
  • Like 2
Link to comment
Share on other sites

2 hours ago, iljitsch said:

What kind of ambiguity do you have in mind?

Again: I'm not advocating for anything resembling the full Python that exists today. That is possibly even too much for an Amiga, and famously a non-goal of Python is to be fast. They handsomely non-reach that goal.

After programming in C, PHP and Javascript for a long time the lack of { } and ; in Python was a revelation. Creating structure through indentation is a bit weird, but probably the best/easiest way to do it.

Obviously "real" functions would be quite different from BASIC, and replacing GOSUB subroutines with functions is a bit annoying as the latter usually go at the end but Python functions need to go at the beginning. Other than that, the differences between BASIC and Python are actually relatively small. I could easily see Python be tokenized like Commodore BASIC, although of course there would have to be a system to create new tokens for new functions.

As an example of something that burns cycles in the lexer, and indeed strongly favors having a lexer pass first and then a parser second ... rather than a one pass line by line parser like Basic 2/7 or Forth ... we can go with creating structure through indentation.

White space where indentation level is significant is a PITA to parse, which is why it makes sense to clean up white space and convert whatever way the indentation is expressed into a common consistent parse-able format with the lexer. Then after its parsed, it must be executed ... with CPython that is by converting the parsed tree into bytecode and then executing the bytecode. That's why the library calls to functions in libraries that have a reputation for efficient data analysis in Python are often C-code or, indeed, sometimes Fortran code running with a little bit of Python function call glue on top.

IIRC, the "over three decades old" Basic alternative to those { } program blocks are simply keywords that end the blocks. In QBasic, that is "END ...", where "END" without anything following it ends the program.

FUNCTION odd%(N%)
   odd=((N AND 1)=1)
END FUNCTION

 

 

 

Link to comment
Share on other sites

14 hours ago, BruceMcF said:

And of course the biggest language by job listings citations is SQL, so before worrying about a Small-Python, the first target on that track would be a CX16-SQL database manager. 😉

Oh the horror.

	SELECT * FROM ACCOUNT WHERE RAM_BANK = 4 AND ID = 15
	

  • Like 1
Link to comment
Share on other sites

35 minutes ago, BruceMcF said:

IIRC, the "over three decades old" Basic alternative to those { } program blocks are simply keywords that end the blocks. In QBasic, that is "END ...", where "END" without anything following it ends the program.

FUNCTION odd%(N%)
   odd=((N AND 1)=1)
END FUNCTION

ALGOL shows us the way.  Or Oberon, if you're not allergic to Pascal.

Golang learned positive lessons from both C and Oberon.

But I'm fading fast on the idea of anything other than a Structured BASIC added to the X16.

Of course, S-BASIC looks rather ALGOL-like.

Link to comment
Share on other sites

44 minutes ago, rje said:

Oh the horror.


	SELECT * FROM ACCOUNT WHERE RAM_BANK = 4 AND ID = 15
	

 

To be fair, if people get a job on the basis of, "Yeah, I can do that", but then when hired they set about working out how to get promoted to a job where they DON'T have to "do that", then there will be a steady stream of "help wanted" ads that specify such a language.

Link to comment
Share on other sites

  • 2 weeks later...
On 6/3/2021 at 6:06 PM, iljitsch said:

Well, how many things do you need to add to BASIC (and take away) before it's not really BASIC anymore?

We're talking about different flavors of Commodore BASIC here...

Despite topic title is obviously about Commodore BASIC, we're not talking about Commodore only BASIC here. The main reason is despite X16 is using Commodore BASIC V2 as starting point, the team is evolving it beyond CBM contraints. And I think it will evolve to something close to QBasic.

I'll remind you that David was impressed by full screen editor of MMBasic, which lets you ommit line numbers and write a structured program very much like QBasic. And he said he wants X16 to have something similar.

And it's still BASIC. )

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

I've read through this topic, and I've come to the same conclusions as I do with many 'programming language' discussions. The people saying the most and shouting the loudest aren't really the target audience. They aren't thinking about others, but about themselves and how they progressed as programmers. They think about what they know and use now, and they want to shape everything to fit in with that. They forget that some people have absolutely no idea of what programming is and need to learn everything from scratch. The absolute basics of programming... learning some simple commands, breaking a problem down in to steps, linking them and getting results. Understanding concepts such as variables, loops, counters and simple logic. 

 

Most people don't want to be professional programmers, they may not even want to be "good" programmers. They just want to dabble their toes in the water, experiment, have a bit of fun and see where it takes them. Or maybe just get a pleasant dose of nostalgia.

Would you teach somebody to read by starting them off with the works of Prof. Stephen Hawking and perhaps some Tolkien? Do you teach people to count by dropping them straight in to calculus, trigonometry and statistics? Probably not much fun for intermediates, never mind absolute beginners.

When you start thinking about being productive and suggesting modern languages, you are clearly missing the point... this is a retro 8 bit platform. Most people already have a PC/Mac for serious stuff. If they wanted to learn 'serious' programming and be 'productive', they are hardly likely to choose this platform are they?

Dartmouth BASIC was originally a simple language for students who wanted, or needed, to solve problems, automate calculations or some other process, without having to spend years learning computer science and complicated programming languages. It was ideal for that, and it still is. Nearly all the '80s micros had extended and improved versions of Basic available. Atari, Sinclair, Amstrad and CBM 8 bits had loads. COMAL was essentially an extended, structured version of Basic. They were all easy to learn.

Had someone showed me C, Java, Fortran, Javascript or even Pascal as my first experience of programming, I would never even have bothered trying.  The Sinclair ZX81 had a wonderful manual to introduce simple programming concepts to 14 year old me, as did my old Atari 400. That led me on to more complicated things, and now I actually like Pascal, and think Psion's OPL was a great little language to mess with. To me, the rest are overcomplicated, hard work and not much fun.

There's that word again "FUN". Funny eh? 😁

  • Like 1
Link to comment
Share on other sites

In the spirit of the discussion getting bumped up for a rehash, here is a...   Trivia Question! 

Did you know:  The "more advanced" BASIC versions Commodore released for the Plus/4 and C128 were considerably slower than BASIC on the Commodore 64.       I'm talking comparable tasks where all three versions of BASIC are compatible with the program listing.   Think of a Prime numbers finder using trial division or the sieve approach.   Lots of maths; big arrays; lots of jumps and loops; logic and memory operations.    

And I mean considerably slower!     Like 20% or so depending on the mix of operations!   

Can anyone guess the reasons why?   

 

Link to comment
Share on other sites

38 minutes ago, Snickers11001001 said:

In the spirit of the discussion getting bumped up for a rehash, here is a...   Trivia Question! 

Did you know:  The "more advanced" BASIC versions Commodore released for the Plus/4 and C128 were considerably slower than BASIC on the Commodore 64.       I'm talking comparable tasks where all three versions of BASIC are compatible with the program listing.   Think of a Prime numbers finder using trial division or the sieve approach.   Lots of maths; big arrays; lots of jumps and loops; logic and memory operations.    

And I mean considerably slower!     Like 20% or so depending on the mix of operations!   

Can anyone guess the reasons why?   

I would think the first / main reason is the amount of bank switching required. C64 BASIC programs stood alone in their address space. The increased size and complexity of the 128 & +4 ROMs no doubt necessitated fetching bytes through a routine that would bank out the ROMs, fetch the bytes from RAM, bank in the ROMs, then continue with BASIC interpretation of the data.

I've not looked at the ROMs for +4 ever. I had a 128 and I know there were routines to fetch bytes from a specific bank (variables from bank 1, BASIC text from bank 0). But even if you had a program with zero variables, so you never have to switch to bank 1, you would still have to do a lot of bank switching from ROM to bank 0 RAM to access the linked list of lines of code.

  • Like 1
Link to comment
Share on other sites

On 6/2/2021 at 3:50 PM, rje said:

PET BASIC 4.0 was responsible for getting me started, which is more or less BASIC 2 (we didn't use the disk commands so much).

I don't know how I missed this for this long. I guess BASIC 4.0 was my start, as we had PETs at school. They were purchased for a computer class that wound up not happening for four years! They just sat gathering dust in the back of the math classroom and I was interested so I was allowed to use / play with them after getting my work done. I did use the disk commands because we had a dual disk drive (and printer) to go with the three systems. I wish I knew whatever happened to them!

  • Like 1
Link to comment
Share on other sites

Quote

I would think the first / main reason is the amount of bank switching required.

 

Bingo! 

'CHRGET' (which I think I mentioned earlier)  is the machine code that fetches a byte of the BASIC listing from program memory for the interpreter.   There are equiv. routines for BASIC to go get variable values etc., from var. space or the string heap.   But the 'CHRGET' routine gets called a LOT by the BASIC stuff. 

In the C64 (and our X16) the actual routine is copied to zeropage at startup and runs from there.  Its 24 bytes long with the main pointer actually included in the routine as a self-modified pointer.   The pointer contains the address of the next byte to be fetched.   On the C64 the two byte pointer is actually the object of an LDA right in the routine.

On the Plus/4 (which is where my experience was) that routine is 33 bytes and doesn't even live in zero page, although the two byte pointer takes two more bytes and IS in ZP.   Now part of the reason its not in ZP can be chalked up to questionable decisions on the Plus4 side from Commodore's team.   They used space in zero page to hold variables for the RENUMBER and AUTO line number stuff -- things that are not performance critical and on the Plussy and did not need to use ZP space.   They also reserved 20 bytes or so in ZP for a speech chip enhancement for a top end Plus4 model that was never released.    But mostly, the Plus4 and 128 CHRGET functions don't live in zero page because they wouldn't get much benefit all things considered from doing so.   All those extra bytes on the PLUS4 are disabling interrupts, banking out the ROMs with a write to a register on the TED chip (up in the FFxx area), then they load the text pointer (using a more cycle costly instruction ) and finally they have to make another write to the TED registers to bank the ROMS back in and, finally, reenable the interrupts.   AND the Plus4 does that for EVERY single BASIC character fetch.   (A similar routine with the added interrupts/banking cost is used when it grabs a variable or a string).   It does the banking even where the pointer contains an address in an area of the memory that would never be under a ROM.   Simply put, the logic to 'look and decide' if the pointer was to an address under ROM or not would itself be more costly than just doing the bank operations every time. 

If memory serves, the 128 banked ram/rom for the first 64K for BASIC program stuff; and ROM/RAM at the second 64K for variables and string stuff.    Same sort of problem/cost.      The 128 also introduced so many new tokens that they had to use a token as an escape character so that some keywords now had two tokens, but I don't think that would have much of a performance hit except  maybe in scanning the dispatch table when those tokens were used  -- and that would not be the case in an apples to apples comparison of a Prime Numbers test or something like that. 

I suppose we have to also acknowledge Commodore was doing all these changes 'in house' instead of having Microsoft (who we might expect to have been better at updating their own BASIC) do so.    But Jack Tramiel had gotten away with murder on his BASIC license deal with Microsoft back with the PET machine.  Commodore's license was a flat one-time payment, and NOT tied to units sold and was perpetual for Commodore to use and extend for ANY Commodore computer model based on a 6502!.   You can bet Tramiel was NOT going to got back to MS asking for them to work on any update as that would have opened the door to amending that license!      

But yeah, mostly it was the banking.   Someone made a utility for the Plus4 last year and all it does is copy the entire ROM set (BASIC and KERNAL) down into RAM; rewrite all the routines that used bank switching to skip doing that; adjust the top of memory to account for the permanent residency of the rom code there, and just leave the ROMS banked out.    Effectively it puts it in the same mode as C64 but still with a little more costly CHRGET routine since its still not in ZP and not self modifying.    And because the Plus4 ROMs are so much larger, it leaves the user with only 28K of memory for BASIC but its often a double digit improvement in performance.   

Edited by Snickers11001001
Link to comment
Share on other sites

The +4 was a faster clocked CPU, which means the fact that it is slower than a C= 64 is even more "impressive". Lots of code must run to get each byte. I have to believe there would be a way to write that routine to not take the speed hit of bank switching when accessing always RAM / never ROM space while not significantly slowing down RAM under ROM, but that's just intuition. Even tripling the amount of ram for those routines (which I don't think would be necessary) would be well worth the double digit speed improvement, but that ship sailed long ago.

Edit: forgot to say, the fact that the C= 128 was slower in otherwise identical BASIC code isn't surprising, since it was clocked at the same speed as the 64 (and we can't switch to FAST without the program becoming different).

Edited by Scott Robison
Link to comment
Share on other sites

15 minutes ago, Scott Robison said:

The +4 was a faster clocked CPU, which means the fact that it is slower than a C= 64 is even more "impressive". Lots of code must run to get each byte. I have to believe there would be a way to write that routine to not take the speed hit of bank switching when accessing always RAM / never ROM space while not significantly slowing down RAM under ROM, but that's just intuition. Even tripling the amount of ram for those routines (which I don't think would be necessary) would be well worth the double digit speed improvement, but that ship sailed long ago.

Edit: forgot to say, the fact that the C= 128 was slower in otherwise identical BASIC code isn't surprising, since it was clocked at the same speed as the 64 (and we can't switch to FAST without the program becoming different).

The cost is mostly in cycles.    My idea back in the day was to put together a custom interrupt handler that added a peek at the high byte of the pointer and if it were less than $79 it would write a zero/nonzero flag somewhere that might let one branch between fast/slow versions of the fetch routines like CHRGET.   But...  by that point I was in college chasing women, had moved on to my first 386 DOS machine, and didn't have the interest (or skills if I'm honest) to chase the issue down and figure out if it would really be feasible or worthwhile.  

Link to comment
Share on other sites

I just wrote the following test code to see how much difference it makes. The program:

demo2_prg.png.7ab3489be10bf5d8890a2cde1a83b07a.png

As I don't have any actual hardware, I'm using WinVice 3.5, which should be adequate and illustrative if not 100% exact. It's close enough. All time reported in jiffies as it is a measure independent of the host environment. All machines are NTSC.

x128 GO64: 521 jiffies (8,883,050 cycles)

x128 SLOW VIC: 706 jiffies (35.5% slower, 12,037,300 cycles)

x128 FAST VDC: 334 jiffies (35.9% faster, 11,389,400 cycles [roughly the same plus benefit of VIC being inactive])

xplus4: 659 jiffies (26.5% slower, 19,330,666 cycles)

Just to be complete, a special version of the program that enables 2 MHz clock in 64 mode:

x128 GO64 POKE 53296: 252 jiffies (51.6% faster, 8,593,200 cycles [roughly the same as regular 64 mode plus benefit of VIC being inactive])

Edited by Scott Robison
Link to comment
Share on other sites

Without taking time to look, I wonder how much of the enhanced speed of the 128 relative to the +4 is due to better coding on the 128 and how much is due to the 128 MMU being more efficient at bank switching.

Edited by Scott Robison
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use