Commander X16

I renamed the Joplin notebook I have for X16 stuff to "The feature creep was too strong to resist".

10 minutes ago, paulscottrobson said:

Depends. You could probably chuck all the floating point stuff in its entirety ; it's only there really because MS Basic comes from Dartmouth Basic. No-one's going to do their accounts on an X16. Whether 16 or 32 bit integers, it's questionable.

Heresy!

 

Ok, my initial knee-jerk reaction is over, so I can think about that.  Integer BASIC, eh?  Hmmmmm.

And "yes" to structured BASIC, of course.  I was aiming for the lowerbound, but yes, removing line numbers already means "different animal entirely", so...

I'd love to geek out over a structured syntax.  This is probably not the thread for it.  On the other hand, it's probably ok.

Quote

The nice thing about STOS is the bank/task switching design, so you can have multiple programs running at once ; a sprite editor in one block, tile editor in another, music editor in a third, and so on.

Wow.  I barely have a concept for that on an 8-bit system.  Doesn't Acheron do that?  

Quote

Might as well add in REPEAT/WHILE/Block IF/ELSE/ENDIF and named Procedures ; doesn't take up much space, nor do locals.

I was thinking about the "C-Lox" implementation I'd been beating my head against on the X16, and thinking that instead of parentheses in its if statement, I'd rather use a colon (as a shorthand for "then" I guess).  Even though it resembles Python in a superficial way...

if foo < bar:
   do things, please
endif  # or whatever serves to end a block politely
while foo < bar:
  do other things, please
end # endwhile is awfully bulky

 

 

1 hour ago, TomXP411 said:

While I mostly think we've moved on from the need for line numbered BASIC in Computer Science, I don't see a lot of replacements that can fill the shoes of Advanced BASIC as a first language



 

Two things - the immediacy - if you type CIRCLE 100,100,80 you get a Circle. The other thing is the abandonment of the state machine that you get in most of these systems. FSMs are very flexible but complicated to grasp. In a language like BASIC you can have directly acting code rather than a layer.

Most of the downsides of BASIC are down to specific BASICs - GOSUB, line numbers, two character identifiers and so on.

There's no reason why you can't have all of them ; an emulator on a modern PC, one on a Raspi, one in Javascript and a physical machine. The thing I don't like about Maximite is it's not a real computer - it's a BASIC interpreter running on a MCU. So you can't really program it in Assembler.

There is one issue, which is some things are difficult to emulate at speed, the most obvious in X16 is pixel level collisions. Sometimes you have to make some compromises in the design.

2 minutes ago, rje said:

Heresy!



 



Ok, my initial knee-jerk reaction is over, so I can think about that.  Integer BASIC, eh?  Hmmmmm.



And "yes" to structured BASIC, of course.  I was aiming for the lowerbound, but yes, removing line numbers already means "different animal entirely", so...



 

If you're doing multiple platform designs you can keep but not use the line numbers. If you have a proper editor, just hide them, if you are running in a TTY situation they can be quite handy. The thing is you want a language where their sole function is ordering the code. Also makes it much easier to compile it.

2 hours ago, TomXP411 said:

While I mostly think we've moved on from the need for line numbered BASIC in Computer Science, I don't see a lot of replacements that can fill the shoes of Advanced BASIC as a first language...

Add to that the likelihood that a programming language on the X16 "should" fit in 16K.  In other words, a subset of Algol 68 that (strongly) resembles a structured BASIC.

Paul's suggestion, that line numbers are hidden entities which only maintain program order and aid in debugging, is a good idea.

I've already figured, in a very loosey goosey fashion, that any imperative language stripped down to fit into 16K is going to essentially resemble a BASIC subset of Algol 68.  What I mean is that one could call it "Retro Python" for marketing hype and maybe a tiny bit of syntactic sugar, but it will be just as far away from Python as it will be from C, Perl, Pascal, Swift, Dart, Go...   ah maybe farther, but the error measurements here are large.

* * *

I've been coding shell-like scripts for decades now, and I still appreciate sigils.  Although in the Unix world, the sigils are at the front of the variable, not the back.  I suspect that was done to make parsing easier: a dollar sign plus an alpha equals the start of a variable.

 

3 hours ago, paulscottrobson said:

Two things - the immediacy - if you type CIRCLE 100,100,80 you get a Circle. The other thing is the abandonment of the state machine that you get in most of these systems. FSMs are very flexible but complicated to grasp. In a language like BASIC you can have directly acting code rather than a layer.



Most of the downsides of BASIC are down to specific BASICs - GOSUB, line numbers, two character identifiers and so on.



There's no reason why you can't have all of them ; an emulator on a modern PC, one on a Raspi, one in Javascript and a physical machine. The thing I don't like about Maximite is it's not a real computer - it's a BASIC interpreter running on a MCU. So you can't really program it in Assembler.



There is one issue, which is some things are difficult to emulate at speed, the most obvious in X16 is pixel level collisions. Sometimes you have to make some compromises in the design.

There's no reason you can't add the ability to load and run machine code binaries on the Maximite, although loading it down with assembly and C++ toolchains kind of ruins its simplicity.

 

As a novice the X16 appeals to me because it is kept simple so that I feel I can still learn to understand the inner workings. It’s close to a c64 which I had as a child so it checks that nostalgia box, and it pushes the envelope a bit by having a higher clock speed and some other features that make it superior in specs to a c64 which makes it a new thing. Also keeping it at a lower price point makes it accessible.


Sent from my iPhone using Tapatalk

7 hours ago, paulscottrobson said:

The thing I don't like about Maximite is it's not a real computer - it's a BASIC interpreter running on a MCU. So you can't really program it in Assembler.

Not entirely it's not a real computer. While its BASIC interpreter is written in 32-bit C, you can't call it an emulation, because the real hardware is actually used. So BASIC here is more like a firmware ROM, and while running it uses real CPU and real memory inside MCU.

And while you don't have Assembler, you have PEEK and POKE to interact with memory directly. Pretty good for exploration and education.

8 hours ago, TomXP411 said:

There's no reason you can't add the ability to load and run machine code binaries on the Maximite, although loading it down with assembly and C++ toolchains kind of ruins its simplicity.



 

I was always a big fan of the BBC Basic Assembler. Allowed you to tinker without being a full bore system. I wrote a lot of ARM code that way ? I'm a big fan of the idea - I've actually got one though I haven't done much with it yet. It fulfils the #1 criteria I think a system designed for learning should have, which is that the built in programming system, whatever it is, should be fast enough to produce 1980s type games without struggling.  Someone wrote a very nice Boulderdash type game in BASIC, but you can see the limitations in the code to make it quick enough.

4 hours ago, Cyber said:

Not entirely it's not a real computer. While its BASIC interpreter is written in 32-bit C, you can't call it an emulation, because the real hardware is actually used. So BASIC here is more like a firmware ROM, and while running it uses real CPU and real memory inside MCU.

And while you don't have Assembler, you have PEEK and POKE to interact with memory directly. Pretty good for exploration and education.

Well, in that sense, yes it is, but it doesn't have the accessible layer below. And ARM RISC is way too complex for a beginner.