Commander X16

Note: In reading more about the +4, my cycle counts are way off. Yes, the CPU can run at 1.76 MHz. But any time TED is accessing the chip, it is running at half that speed, or about 0.88 MHz. The Wikipedia article claims that the actual speed increase for the +4 is only about 15% when the screen is being displayed. Taking that into account, my +4 cycle count in the earlier post is probably wildly off.

All numbers are estimates but especially cycle counts and the effective speed of a +4 under varying circumstances.

x128 GO64 SLOW: 521 jiffies (8,883,050 cycles [1.02 MHz])

x128 GO64 FAST: 252 jiffies (51.6% faster, 8,593,200 cycles [2.04 MHz])

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

x128 VDC FAST: 334 jiffies (35.9% faster, 11,389,400 cycles [2.04 MHz])

xplus4 SLOW: 659 jiffies (26.5% slower, 12,883,450 cycles [effective speed of 1.173 MHz])

xplus4 NO BANK: 550 jiffies (5.5% slower, 10,752,500 cycles  [effective speed of 1.173 MHz])

xplus4 NO TED: 396 jiffies (24% faster, 11,616,000 cycles [1.76 MHz])

xplus4 FAST: 331 jiffies (36.5% faster, 9,709,333 cycles [1.76 MHz])

Quote

I think the two systems are really very comparable in how they deal with bank switching. +4 write to one address switches ROM out (FF3E) , another address to switch ROM in (FF3F). 128 is more complicated, but they simplify it by having four configurable memory configurations

 

Yep.   I think the 128 does whatever to keep at least its interrupt routine (and the things it calls) in the right place so that it doesn't have to mess with disabling interrupts during every single BASIC character fetch.   The MMU on the 128 lets it deal with ROM/RAM ranges in a more granular way; whereas the Plus/4 banking is always a swap of all the entire ROM/RAM in the range from $8000 to $FFFF, period full stop  (well, perhaps excluding special cases with carts, though I didn't look at that).      

All that said,  both Plus4 and 128  take a speed hit compared with the C64 (and X16!) version of 'CHRGET' which not only has no need for the SEI/CLI instructions of the Plus 4, but is also able to omit an additional 6 bytes (and 12 CPU cycles) of register writes for bank switching compared to both the Plus4 and C128.  Moreover the C64 implements its actual fetch of the next program byte into the accumulator as something akin to an  "indirect" e.g., equivalent to something like a fictional 'LDA (txtptr)' instruction, all as a result of the self-modification of the TXTPTR and TXTPTR+1 values inline in the C664 CHRGET routine:

C64 'chrget'

chrget = $73
chrgot = $79
txtptr = $7a
	 
:chrget
	0073     inc txtptr
	0075     bne chrgot
	0077     inc txtptr+1
:chrgot
	0079     lda [word: txtptr txtptr+1] 
:txtptr
	007a     [ ]  ; low byte of address of next BASIC prog char (or input buffer location in direct mode)
:txtptr+1
	007b     [ ]  ; high byte of address of next BASIC prog char (or input buffer location in direct mode )         
	007c     cmp #$3a      
	007e     bcs exit_routine
	0080     cmp #$20
	0082     beq chrget
	0084     sec
	0085     sbc #$30
	0087     sec
	0088     sbc #$d0
:exit_routine
	008a     rts
	

By my rough tally, the C64 version takes 38 to 41 cycles depending on how the branches go and assuming it doesn't go back to the start upon encountering and discarding a space character, whereas the Plus/4 version takes 53 to 57 cycles to complete and the C128 takes 49 to 53 cycles.   

And getting back to to the topic of this thread and coming around full circle, I think our little examination of the more 'advanced' BASICs from the other machines leads me to this conclusion:   

Not only is C64 derived BASIC 2.0 probably sufficient for the X16, its actually probably the BEST choice for the startup environment/ entry level console, interpreter, 'novice/beginner's' programming language on the machine.      Partially due to the space savings from new 65C02 instructions like STZ and the like, the team already greatly enhanced BASIC and KERNAL in the same amount of rom space.   But its going to (and should) basically be an extended C64 BASIC, and nothing more.   There's not a realistic path for a volunteer team to rewrite Commodore BASIC into something with a highlighted, tab indented syntax IDE with with private subroutine variables, or branches to labels, or long variable names, etc.   

After all... 

1) its STILL an 8 bit chip.   Each memory space can only have 256 values; of which most are already spoken for for letters, numbers, symbols, PETSCII graphics, and the existing pantheon of BASIC tokens.   So adding a bunch of new functionality will require using escape characters  and double byte tokens (one set for tokens; another set for structure if line numbers were gotten rid of; another set for branch or subroutine labels; another set to define context for private variables; another set for variable name-table hashes, and so on.    But from the last few posts, we see all too clearly the performance impact of things that make parsing take even a little bit more work.   This is especially the case if all the extra features require banking operations and access to additional RAM. 

2) A program that would take more than 40K of code and variables would be unusual to the point of "extremely rare" for just about every 'retro' flavor/context of interpreted program language anyway, particularly on an 8 bit platform.   I don't think anything written in BASIC in the downloads for the X16 so far comes even close.   The '8bit show and tell' guy recently did a segment on Sid Meier's Pirates and the BASIC  listing for that sucker was really REALLY long and still managed to fit in the space available on a stock C64 (and thus would fit on the X16).   Doing that long or longer of a program today, someone would probably be better suited using a compiled language, whether 'C' using one of the projects that have support for the X16, or something new and cool like 'PROG8' which is I am following with interest.   

Even so, the X16 architecture will permit alternatives.   If someone is able to fit a version of QuickBasic or an 8-bit pseudo Python or whatever (including dev environment, runtime interpreter, AND a system kernel) into 16K of ROM bank (or two) , they should write it and see how it goes!   But I'm now firmly in the camp that thinks its not reasonable to insist or expect the dev team to go there.   The 8BITGUY wanted that 'power on to BASIC' experience and we've more than got that covered. 

 

1 hour ago, Snickers11001001 said:

Even so, the X16 architecture will permit alternatives.   If someone is able to fit a version of QuickBasic or an 8-bit pseudo Python or whatever (including dev environment, runtime interpreter, AND a system kernel) into 16K of ROM bank (or two) , they should write it and see how it goes!   But I'm now firmly in the camp that thinks its not reasonable to insist or expect the dev team to go there.   The 8BITGUY wanted that 'power on to BASIC' experience and we've more than got that covered. 

That's exactly what I want to do with xenon. Alas, my employer(s) don't care about my interesting hobbies. ? But I agree, there is nothing wrong with an enhanced BASIC v2. Do I want to write everything in it? No. But it's fun!

As others have said, some people work on retro cars. Some people practice retro writing (calligraphy). Some people work on finding and restoring antique (retro) furniture. There is nothing wrong with embracing a retro experience in whatever interests you, and I like the X16. I like the MEGA 65. I'd love to find a C64 or C128 or C128D or Apple II or Sinclair or or or or at the local thrift stores.

I was thinking yesterday that as much fun as it is to have my Pi 3B+ setup now as a bare metal CBM machine, the PI really needs a bare metal BASIC-like experience. Something that is just "instant" on and you don't have to think about linux or whatever. Maybe someone has already done it and I just haven't found it because I haven't been looking. Still, I think it would be great to have a native BASIC for PI that allows you to peek and poke and sys and etc. Not as bare as BASIC v2 of course, but ... anyway, yet another project idea to work on and no where near enough hours in the day to accomplish even a fraction of them.

8 hours ago, Scott Robison said:

I was thinking yesterday that as much fun as it is to have my Pi 3B+ setup now as a bare metal CBM machine, the PI really needs a bare metal BASIC-like experience. Something that is just "instant" on and you don't have to think about linux or whatever. Maybe someone has already done it and I just haven't found it because I haven't been looking.

There's rpi-basic:

Quote

RaspberryPi BASIC is an homage to the Commodore 64; a bare-metal operating system that boots directly to a BASIC prompt, similar to early computers. Right now it's incredibly barebones, so expect bugs! The interpreter is based on Adam Dunkels' uBASIC, and the kernel is written in C++.



It builds upon awesome work by Josh Cole, Alex Chadwick, John Cronin and others.

 

Convenient timing with respect to recent discussions in this thread, Bill Herd's new book about his era at Commodore (Plus/4 and 128 dev cycles in particular)  is out on AMAZON.   

https://www.amazon.com/gp/product/B09BDF92F4

Shocking to read in the blurb that the C128 took only 5 months from 'paper design' to working proto at the CES.   Looks like it will be a good read, but Herd has given so many long talks about this stuff I suspect it will be in some part a rehash of a lot of things he's already presented.   Still, I'll probably pick up a copy. 

9 hours ago, BruceMcF said:

There's rpi-basic:

See? I'm old enough to know at this point that any idea I come up with is not a unique thought. ?

Edit: Having looked at the repo, I'm sure that 8 years since last update is just a ruse and it'll be finished Any Day Now(TM). ?

53 minutes ago, Scott Robison said:

See? I'm old enough to know at this point that any idea I come up with is not a unique thought. ?



Edit: Having looked at the repo, I'm sure that 8 years since last update is just a ruse and it'll be finished Any Day Now(TM). ?

Picking it up and fixing the promised bugs is a golden opportunity to get in on the ground floor.

5 minutes ago, BruceMcF said:

Picking it up and fixing the promised bugs is a golden opportunity to get in on the ground floor.

Why work on 8 year old stale code when I can create my own masterpiece from scratch? Rhetorical question... ?

15 minutes ago, Scott Robison said:

Why work on 8 year old stale code when I can create my own masterpiece from scratch? Rhetorical question... ?

I don't even know whether his own code is worth using, but if any of the projects he built it on are ongoing, that's an excellent starting point. Hiowever, according to its developer, uBasic is a bit of a hack:

Quote

My intention with this program is to be able to use it for adding a simple scripting language to severely memory-constrained applications or systems (e.g. a scripting language to the web server applications in uIP or Contiki). While I secretly hope that the uBASIC code may be useful to someone, it currently is a really quick hack made primarily for personal enjoyment. However, if you are interested in looking at how a really small BASIC interpreter can be written, go ahead and take a look at the code!

... so it might be better to work with a more stable Basic model. Basicpp seems like a more alive project, and it's implemented in the same C++ toolchain that are required for the other parts of that project.

Myself, of course, I'd just pick up one of the bare metal Forth's available and find some 28 year old Forth code to implement a Basic to build upon ... once it's a turnkey, it's the next best thing, and AFAIU the ARM processor allows a pretty efficient Forth implementation. I figure if a codebase is old enough to drink, then working with it qualifies as a little bit retro anyway.