Jump to content
IGNORED

ECS BASIC Color Coding Patent


intvnut

Recommended Posts

When was the next time you saw something like that. I wonder if the patent was enforceable.

 

When I first saw this in an Intellivision catalog in 1983, I didn't know what to make of the colours, but the 20x12 display made it look like a joke. They had plans for an expanded full basic and ram expansion.

 

Had the Intellivision ecs had a full basic with peeks and pokes, a decent keyboard, do you think you could have worked with that 20x12 display?

Edited by mr_me
Link to comment
Share on other sites

A few systems to compare with:

 

The VideoBrain (1977) has a graphics resolution of 128x56 semipixels (supposedy 384x366 hires pixels?!) which in text mode generates 16 characters x 7 lines. Perhaps it was bearable by 1978?

 

The Interact Home Computer (June 1978) supposedly has a text mode with 17x12 characters in 8 colours, or in graphics mode 112x78 pixels in 4 colours. It lived on in France as Victor Lambda (1980-81), shortly after bought by Micronique which continued with the Hector series.

 

Perhaps the one most people know best though is the VIC-20 which has a default resolution of 22x23 characters. I think it is fairly OK, though many people consider it a joke even at that screen resolution.

 

So yes, if the ECS had been released right away in 1981 instead of the delayed work with the KCS, it might have been considered an adequate resolution, though as home computers became both cheaper and more advanced for each day, it would have been rather low priced or intended only for existing Intellivision owners wanting to upgrade.

Link to comment
Share on other sites

Originally, the Intellivision computer was to be used primarily for home productivity and as a terminal for videotex data and online services. It didn't even come with a programming language. The default 20x12 text display wouldn't have worked.

 

I remember the vic20, the text was ugly but it's still double the ECS.

Link to comment
Share on other sites

I personally thought, back in the day, that the 20x12 resolution was extremely limiting. I can see why, even in the late 70s, Mattel realized they needed a higher-res character generator for their computer. The ECS, being a low-cost quick hit to get out from under the FTC fines, jettisoned it. I suppose it also dovetailed with the decision to rework the video-mixing circuitry to enable the System Changer, although theoretically they could have tried to make both high-res text overlay work as well as System Changer video cut-through.

 

If ECS BASIC had performed at all well, it would have been more interesting. It was extremely slow and clunky, though. I spent some time reverse engineering parts of it, and it's pretty awful code. It looks like it was thrown together very quickly, perhaps glancing at some of the 6502 MS BASIC code for parts of it. There's one loop that shifts a floating point accumulator that's amazingly bad, for example.

 

As for seeing anything else like this... I remember when syntax-highlighting editors started becoming all the rage in the mid 1990s. IIRC, both Turbo Pascal and Turbo C++ had this functionality. I'm not sure that it would run afoul of this patent. I haven't studied the claims super closely to see if they're drawn too narrowly. My initial impression is that they might be. Let's look at independent claim 1:

 

 

. For use in a digital computer in which a series of programming statements are processed, and in which the structure of programming statements must conform to a predetermined set of syntax criteria to permit processing, a method of syntax examination and correction comprising the steps of:

compiling a programming statement in response to user input;
displaying said programming statement;
examining the structure of said statement in accordance with a predetermined set of syntax rules;
displaying selected color indicia of each character within said statement which is in accordance with said predetermined set of syntax rules;
determining whether any characters remain to which color indicia have not been assigned;
examining the color indicia bearing characters alone in accordance with said set of syntax rules and designating said statement as acceptable or unacceptable, and, if designated acceptable, entering an altered programming statement thereof into the program formed solely of color indicia bearing characters.

 

I suppose it depends on what you consider "compiling." A syntax-highlighting editor does some parsing, but it may be a stretch to call that "compiling." Also, the claim specifically includes ruling a statement as "syntactically correct" vs. "incorrect," while syntax-highlighting editors tend to be a bit fuzzier on what they highlight as correct/incorrect. (For example, mismatched parentheses get highlighted, but the rest of the statement may still be correctly colored rather than greyed out.)

  • Like 1
Link to comment
Share on other sites

Maybe it's been discussed before, but is this ecs basic interpreter slow because it's written poorly or because the intellivision is too slow?

 

I'd say the word compile is used similarly to parse in this case. I was thinking how some patents are given and then found to be "unpantentable" in court, because they are found by the judge, for example, to be not novel or inventive enough. It's probably a good patent, long expired.

Link to comment
Share on other sites

Maybe it's been discussed before, but is this ecs basic interpreter slow because it's written poorly or because the intellivision is too slow?

 

A little of both.

 

A 895kHz CP-1610 pulls about 100,000 - 110,000 instructions per second in the context of an Intellivision with a typical instruction mix. (This includes cycle stealing during active display.) A 1MHz 6502 pulls closer to 250,000 - 300,000 instructions per second. So, on raw instruction rates you're behind the curve. The CP-1610 does have 16-bit arithmetic, but it only helps in places where you need it. Most of the BASIC interpreter doesn't benefit from it. So, you start out with a factor of 2 or more slowdown going from 6502 to CP-1610.

 

The ECS BASIC implementation itself is designed to be extensible, and so it it has a number of hooks in highly trafficked code paths. While that's nice and flexible, it also slows it down. The hooks could have been implemented much more efficiently than they were. You have code that periodically checks for the existence of a ROM (possibly page-flipping), directly in high-traffic code paths, when really it could have checked once and then configured a handful of lower-overhead vector addresses in RAM.

 

It also has some straight-up WTFs, such as zeroing out a 42-byte "instruction buffer" and then copying each statement into that buffer, for each statement it executes. There's no good reason for this--it should just execute the instruction directly from the tokenized program store.

 

Or, this massively crappy shift loop. If they'd put any thought into their number representation--e.g. used little endian because it matches the machine better--they could implement this floating-point accumulator shift far, far, faster. This loop looks like someone glanced at the 6502 version of the code and wrote a slavish reproduction of it.

L_E1FD:
        PSHR    R5                              ; E1FD   Save return address
        MVII    #L_47D5, R1                     ; E1FF   Point to FACC
        CLRR    R5                              ; E202   
L_E203:
        MVI@    R1,     R2                      ; E203   Read a byte
        SLR     R2,     1                       ; E204   Right shift it 1
        XORR    R5,     R2                      ; E205   XOR in bit from prev
        MOVR    R2,     R5                      ; E206   Copy to R5
        MVI@    R1,     R2                      ; E207   Reload original byte
        MVO@    R5,     R1                      ; E208   Store out updated byte
        ANDI    #$0001, R2                      ; E209   See if LSB was 1
        BEQ     L_E211                          ; E20B   No: Clear R5

        MVII    #$0080, R5                      ; E20D   Yes: Set bit 7 of R5
        B       L_E212                          ; E20F   Iterate

L_E211:
        CLRR    R5                              ; E211   
L_E212:
        INCR    R1                              ; E212   Move to next byte
        CMPI    #L_47DB, R1                     ; E214   At end of FACC?
        BNEQ    L_E203                          ; E217   Keep going...

        PULR    R7                              ; E219   Return

I went through ECS BASIC and cut out the hooks and replaced that craptastic loop above with something slightly more sane. I also replaced that repeated-zeroing loop with something lighter weight. I got maybe a 10% - 15% speedup. Nothing earth shattering, but not bad for just some quick minor tweaks.

  • Like 2
Link to comment
Share on other sites

Not all 6502 based BASICs were that fast as well. Take for instance the VTech Creativision, which has a 2 MHz CPU but runs its cartridge based BASIC in VDP RAM just like the TI-99/4A does (and yes, that ain't a speed monster as well). I find it remarkably slow even for its conditions. A few years later VTech built a proper computer, the Laser 2001 which is based on the Creativision. The 2001 has a different BASIC, possibly partly lifted from the Apple II, and of course proper CPU RAM which makes it rather fast on the other hand, despite the chipset is very much alike.

  • Like 1
Link to comment
Share on other sites

Not all 6502 based BASICs were that fast as well. Take for instance the VTech Creativision, which has a 2 MHz CPU but runs its cartridge based BASIC in VDP RAM just like the TI-99/4A does (and yes, that ain't a speed monster as well). I find it remarkably slow even for its conditions. A few years later VTech built a proper computer, the Laser 2001 which is based on the Creativision. The 2001 has a different BASIC, possibly partly lifted from the Apple II, and of course proper CPU RAM which makes it rather fast on the other hand, despite the chipset is very much alike.

 

Yes, there are other slow BASIC implementations out there. The TI-99/4A implementation in particular was bad performance-wise. I mainly look to something like traditional Microsoft BASIC on the 6502 as the baseline benchmark. Some may be faster (Apple Integer BASIC), while many will be slower due to implementation bottlenecks. Storing programs in VDP RAM and double-interpreting are examples of such bottlenecks.

Link to comment
Share on other sites

OK, so I ran a very simple benchmark:

.

10 FOR I = 1 TO 1000
20 A = A + I
30 A = A * I
40 NEXT I
50 PRIN A

.

This took 203 seconds (approx) when I ran it in jzIntv. I've attached the profile info from jzIntv (dump.hst.txt), and it shows rather pervasive malaise: There's no real one "hot spot." Rather, there's lots of "general warmth."

 

In my lightly optimized version of ECS BASIC, it took around 162 seconds (also approx). I've attached its profile also (dump2.hst.txt). That's nearly a 20% speedup.

 

I used an in-browser emulated Apple ][ to run substantially the same benchmark in Applesoft BASIC. (Replacing PRIN A with PRINT A, naturally.) It exited with an overflow error in line 30 in 2 seconds. So, I added a line 35 that did "A = A / I". The program ran in 11 seconds.

 

I re-ran the "optimized" ECS BASIC with that additional line, and it took 253 seconds. The unmodified ECS BASIC took 322 seconds.

 

ECS BASIC is about 30 times slower than Applesoft BASIC. Yikes!

 

I ran the same test in a TI-99/4A in-browser emulator here, in TI BASIC. That test included "line 35" (the divide). It took 22 seconds. Still about half the speed of the Apple ][, but also still over an order of magnitude faster than stock ECS BASIC, and just slightly faster than 10x my optimized version. FWIW, TI Extended BASIC was slower: 28 seconds. How disappointing.

 

I think it's fair to say that ECS BASIC's implementation pretty much stinks on ice.

dump.hst.txt

dump2.hst.txt

Edited by intvnut
  • Like 3
Link to comment
Share on other sites

For fun I tried your extended benchmark on an emulated Creativision, running a modern and accurate emulator.

Original 1982 version of BASIC: 70 seconds
Improved 1983 version: 75-80 seconds
Speed hacked 1983 version: 20 seconds

In this case, the BASIC is polling the keyboard on every interrupt which slows it down a lot. The hacked version bypasses most of this polling, which means calculations run faster but possibly that keyboard input is not as agile. Unfortunately the speed hack also breaks the RND function quite badly.

 

No benchmark is complete without mentioning the Comx 35, also infamous for its slow BASIC:

 

COMX BASIC V1.01: 72 seconds

 

Not too bad, but not particularly good anyway.

 

It concludes that ECS BASIC at least:

 

* Offers one of the lowest possible text resolutions on the market at the time, possibly adequate 2-3 years earlier but not when it was released

* Runs 5 times slower than the slowest competitor on the market, and we shouldn't even bother comparing it to a proper home/business computer

  • Like 1
Link to comment
Share on other sites

Personally, I think that it's not only the clunkiness and slow performance of the BASIC interpreter in the ECS that kills it, it's also the reliance on the EXEC 20 Hz engine cycle. Both of these together make the running program virtually unresponsive and any sprite manipulation useless.

 

About a year ago I tried writing some very simple AI routines to control a sprite: just a simple state machine that causes it to change direction chasing a character on the screen. I couldn't get it to work at any reasonable speed. The interpreter takes so long that by the time it completes executing the few statements, it missed its ISR window to update the sprite's position, so it must wait yet another frame, which delays the rest of the loop. If there are multiple sprite manipulation statements together, each one may end up in different EXEC cycles, making the thing pretty much useless.

 

By the time I got to add a simple hand-controller decoding (i.e., just a simple "IF <controller-was-pressed> THEN") it virtually stopped moving altogether. It was all very painful for anything more than just toy programs. It reminded me of playing one of the old Mattel games in the "Slow" setting, where the EXEC slowed the entire thing down to a crawl.

 

I've read through Microsoft's BASIC source code recently and it occurred to me that something like it but optimized for the Intellivision architecture could work, in theory at least. I mean not just optimizing the interpreter code for the CP-1610, but something designed specifically for Intellivision games with optimized sprite handling routines and such. This is similar to what the ECS BASIC did with the EXEC, but in a primitive way at 20 Hz.

 

It also occurred to me that the interpreter itself could be optimized by more aggressive tokenization. The MS BASIC interpreter only tokenizes the commands, leaving all variable names and expressions intact (in order to be able to read them back as is on a LISTing view), and interprets them "on the fly" during execution -- Every. Single. Time. This could be avoided by essentially "compiling" the program into a tighter byte-code. You would need to store the original text somewhere (perhaps in Flash RAM on a specialized cartridge) in order to not lose the ability to LIST the program and edit it in place.

 

I have some ideas on all this, and it is something that I have played around in my head for a while. I have plenty of other things I want to do first, including some more games, but it sounds like a very cool project. :)

 

-dZ.

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

The EXEC 20Hz cycle certainly doesn't help. In fact, I suspect (but haven't actually validated) that the ECS BASIC interpreter loop is synchronized to interrupts on some boundary, which would help explain why it's so cosmically slow and so difficult to speed up. A FOR loop that iterates 1000 times and executes 3 statements plus the FOR and NEXT would execute ~5000 statements total.

 

5000 statements at 20 statements per second gives 250 seconds. If you allow for some overlapped execution between unnecessary sync points w/ the 20Hz EXEC cycle, then my 253 second benchmark seems... very interesting. It's perhaps a red herring though.

 

The optimized sprite handling, etc. sounds like it's in the direction of what IntyBASIC already provides, and perhaps goes a little further to the automatic sprite motion and collision primitives that something like TI Extended BASIC provided. More aggressive tokenization would tend to increase program size (particularly for manifest constants) but would potentially speed things up. It'd be a non-starter for the puny 2K RAM in the ECS, but would be workable with a larger program store. If you wanted to preserve the original representation of manifest constants, you'd need to stash them somewhere. For everything else, I don't think you'd need to keep the original program text anywhere as long as you kept a symbol table to look up the names of variables.

 

That is, unless you went to a full BASIC compiler, in which case... IntyBASIC? Maybe with float support added? :-)

Link to comment
Share on other sites

 

That is, unless you went to a full BASIC compiler, in which case... IntyBASIC? Maybe with float support added? :-)

 

Because I was thinking of on-boarding it on a cartridge and although I think myself capable of implementing an MS BASIC style interpreter with some minimal Z-Machine style VM sprinkled in it (especially with a P-Machiner core), I do not feel like porting the entire IntyBASIC source code into CP-1610. It doesn't have to be constrained to the ECS, but it could come on a cartridge with considerably more RAM and be simple enough for non-programmers to dabble with (like they did back in the day) without having to learn command line incantations or deal with the assembler. Think Rev or C-mart playing on ECS BASIC.

 

Besides, why does anyone do any of these things? Tell me again what practical problems are the PlayCable or Keyboard Component reverse-engineering projects trying to solve? ;)

 

And finally, although it could be a "full BASIC" interpreter/compiler, it does not have to be something to make fancy games that competes at the caliber of IntyBASIC; it just needs to be better than ECS BASIC and fulfill its promise, and that's a pretty low barrier, I think.

 

-dZ.

Edited by DZ-Jay
Link to comment
Share on other sites

A proper performing basic interpreter for intellivision would be nice to have, even without graphics and sprite extensions. It would show how good something could have been and allows comparisons with other computers. It could be combined with the high resolution text overlay one of the guys is working on.

------------

 

Off topic but the exec speed limitation idea had me wondering about the chess cartridge. If uscf chess is an exec program then it might be slower than it needs to be. Something tells me they worked around the exec because the 1+9 pause feature doesn't work when the computer is thinking. That's just guessing.

Edited by mr_me
  • Like 1
Link to comment
Share on other sites

A proper performing basic interpreter for intellivision would be nice to have, even without graphics and sprite extensions. It would show how good something could have been and allows comparisons with other computers. It could be combined with the high resolution text overlay one of the guys is working on.

 

I've toyed with the idea of spending a weekend converting MS-BASIC to CP-1610 just to see where it lands. What ballpark are we even in in terms of relative speed. It's never bubbled far enough up my list though.

 

 

Off topic but the exec speed limitation idea had me wondering about the chess cartridge. If uscf chess is an exec program then it might be slower than it needs to be. Something tells me they worked around the exec because the 1+9 pause feature doesn't work when the computer is thinking. That's just guessing.

 

Chess does seem to intercept and modify the EXEC ISR. Looking at the code, it installs its own ISR to manage the chess clock, among other things. And, from the Chess manual, it seems it implemented its own rules for display blanking:

 

THE SCREEN GOES BLANK

The screen automatically goes blank after about 4 minutes if no keys

or buttons are pushed. To reactivate the screen, press the DISC for

one second. (If the screen goes blank on the computer's move, you

can wait until you hear a gong and the screen automatically returns

when the computer has a move.)

 

You can make the screen go blank by pressing BISHOP [1] and NEW

GAME [9] simultaneously on the left keypad. This is helpful when

you want to leave the game for a moment.

 

So there you go. AFAICT, Chess still chains back to the EXEC's ISR code. I haven't dug into how much EXEC ISR logic it might bypass. I think it just tweaks the behavior a bit by overwriting variables to control the behavior.

  • Like 1
Link to comment
Share on other sites

With chess they had no choice but change the exec screen blanking feature. When the computer takes hours to make a move you can't have it pausing every four minutes. The question is does the exec slow down that thinking and could they have done more to work around it and speed it up. As you know levels five and six are unplayable unless you're okay making one move a day. I know someone that actually did that back in 1983.

Link to comment
Share on other sites

With chess they had no choice but change the exec screen blanking feature. When the computer takes hours to make a move you can't have it pausing every four minutes. The question is does the exec slow down that thinking and could they have done more to work around it and speed it up. As you know levels five and six are unplayable unless you're okay making one move a day. I know someone that actually did that back in 1983.

 

For funsies, I set up a Computer vs. Computer match at level 8 in jzIntv, with rate control off, and profiling enabled. I'm going to bed. I'll see where it is in the morning. My laptop is definitely getting warm, though.

 

We can see where all the cycles get spent.

Link to comment
Share on other sites

 

For funsies, I set up a Computer vs. Computer match at level 8 in jzIntv, with rate control off, and profiling enabled. I'm going to bed. I'll see where it is in the morning. My laptop is definitely getting warm, though.

 

We can see where all the cycles get spent.

 

FWIW, in over an hour and a half of simulated game time, at level 8, neither side has made a move.

 

post-14113-0-14952900-1541063121.gif

  • Haha 1
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.
Note: Your post will require moderator approval before it will be visible.

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.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...