Page 1 of 1

BASIC 3.5 on a VIC?

Posted: Thu Sep 28, 2017 12:30 pm
by napabar
Has anyone heard of an effort to port Commodore BASIC 3.5 to a cartridge for the VIC-20?

CBM 3.5 is found on the Commodore 16 and Plus/4. Even thought it's numbered lower than CBM 4.0, it's more advanced.

It has the graphics and sound commands of the SuperExpander, disk commands of CBM 4.0, and the structured looping (DO,LOOP,WHILE,UNTIL,EXIT) logic of Waterloo Structured BASIC.

I can only imagine how much better the VIC-20 would be this version. Obviously, CBM 7.0 is even better, but since 3.5 ran on the VIC's only slightly more powerful cousin (Commodore 16), it would seem the most logical choice to port.

Re: BASIC 3.5 on a VIC?

Posted: Thu Sep 28, 2017 12:43 pm
by srowe
How big is the BASIC ROM on the C16? According to Wikipedia the total ROM size is 32K. Assuming 24K of that is needed for BASIC 3.5 that's going to take out BLK5 plus 16K of memory space that could be used for RAM.

Re: BASIC 3.5 on a VIC?

Posted: Thu Sep 28, 2017 1:04 pm
by Mike
I know of a port for the C64. Obviously, the prospects over there were much better, given the necessary (and available!) memory and also the graphics capabilities.
napabar wrote:[V]3.5 is found on the Commodore 16 and Plus/4. Even thought it's numbered lower than [V]4.0, it's more advanced.
Yep. They really should have called it V4.5, but probably didn't do so because it would have openly outclassed the BASICs in their CBM 6xx/7xx series.
I can only imagine how much better the VIC-20 would be this version.
If anything, a BASIC extension is only going to make some (hardware) capabilities easier accessible for the BASIC programmer.

With quite a lot BASIC extensions, IMO, the programmer went over the top with creeping featurism. At least many of them are unused or unusable because of lack of documentation and/or example programs. Just a list of the available commands and functions is not going to help with their exact intended use and syntax.

Now my view on this topic might be biased, because I actually like to use BASIC extensions, also in conjunction with added ML libraries, and with success. :mrgreen:

Oh, and welcome to Denial!

Re: BASIC 3.5 on a VIC?

Posted: Sat Sep 30, 2017 8:33 pm
by eslapion
A BASIC with more instructions is also slower. The difference is most obvious with BASIC 7.0 of the C128 but this is also true of BASIC 3.5.

The BASIC 2.0 equipping the VIC-20 is the fastest and this is most obvious on European VIC-20 which run their 6502 a bit faster than US/Canada ones.

Re: BASIC 3.5 on a VIC?

Posted: Sun Oct 01, 2017 8:03 am
by wimoos
A BASIC with more instructions is also slower.
Not necessarily so, it entirely depends what you want from it. WimBasic http://wimbasic.webs.com has some features that really can improve speed of your Basic programs: SuperNumbers, DIVMOD, Mike's SQR implementation, DEEK/DOKE, FRAC, WHiLE/WEND/QUIT, to name but a few.

Regards,

Wim,

Re: BASIC 3.5 on a VIC?

Posted: Sun Oct 01, 2017 10:33 am
by groepaz
since token lookup basically translates to a table lookup, more instructions only mean using a bigger table - the speed difference is negligible. what makes it slow on C128 is the bank switching being done all the time.

Re: BASIC 3.5 on a VIC?

Posted: Wed Nov 22, 2017 3:05 pm
by J.E.E.K.
groepaz wrote:since token lookup basically translates to a table lookup, more instructions only mean using a bigger table - the speed difference is negligible. what makes it slow on C128 is the bank switching being done all the time.
Also to mention is the more elaborate interrupt processing. Commands with background functionality like PLAY or MOVSPR are based on raster interrupt processing handling duration counters, sprite coordinate manipulations, split screen handling ... all of these - even if nothing is currently active - take off noticeable time every 1/60 (NTSC) or 1/50 (PAL) second.
As already mentioned before, just the count of commands is not the problem, at least for CBM BASIC variants (apart from a possibly slightly longer processing routine handling 2-byte tokens, which I think is negligible).