unbibium

So, I have a long-term goal of writing my own smart speaker program using publicly-available software. And I've met the intermediate goal of making essentially a version of the old Eliza chatbot that you can converse with aloud. I downloaded an Eliza implementation in Python from Github, and used one of those cloud speech recognition engines, and combined them in a way where I can swap the speech engine for a text engine -- meaning I can switch to a different speech engine, too. And I can swap out Eliza for a chatbot of my own design, once I get all the glue in place...

one of these glue elements is, I want this chatbot to have a wake word. like it shouldn't start listening for actual sentences until it hears its name. There's an engine called Snowboy that everyone seems to use... except that it's impossible to install on my Mac or my Raspberry Pi. The python bindings all fail and crash and burn. ...there's another one called Porcupine which seems to work better, but it's complicated to start using... and also seems to have some limitations. like, I'm stuck with the default wake words until I can get a commercial license to use it. so I guess I'll rename it to "bumblebee" or something instead of "Annette" which isn't a good wake word anyway; it's only four phonemes long.

a problem I'm running into with speech/AI/cloud stuff is that I keep finding things that look like they're going to work great, but they're at end-of-life. Snowboy is one of them, that's probably why I can't get it to compile on anything. Six months ago it was Kalliope, which you were supposed to run locally but program through the cloud, somehow. Now there's wit.ai, an intent detection engine, which isn't shutting down... but as I asid before, it's been bought by Facebook, which means I can't get my API token with my Github account anymore, I have to use my Facebook account. Gah.

this is going pretty slowly, I hope I can get past these dumb obstacles and get to writing the conversations soon... even then i'll probably get bogged down in data structures...

I feel the need to put a finer point on this SpeedScript thing.

SpeedScript had no idea where the cursor was on the screen, only in memory. So in order to blink the cursor, it had to blink the actual letter in the document, and then redraw the screen.

This was already a problem on the c64; where I can now type faster than the screen redraws. The Vic-20 probably didn't have this problem because it had fewer letters to draw. The Commander X-16 prototype runs at 8 MHz so it's lightning fast in 40-column mode, but 80-column mode also has 60 rows. So it has to redraw 4120 characters every time anything on the screen changes.

It'd probably be worth my while to optimize it, like maybe store a line length table or something. But every optimization means I'll have to track something that SpeedScript for the C64 never had to track. It never scrolled the screen, for example; it just moved the top-of-screen pointer before redrawing.

I already tried to track the cursor position on the screen, but that's easier said than done. I can catch the cursor position when the screen is redrawn, but that means if they move the cursor, SpeedScript will have no idea where the cursor is until it redraws again. so I need to find some cheaper way of locating the cursor.

I'll probably need a lookup table or something.

the only thing from that list I did was do some Angular.JS lessons.

haven't worked on BASIC for a week

because the filesystem is next

Star Trek kinda works. remember to press CTRL to unlock the keyboard first. you can type LOAD with or without a filename.

There are three demos: Eliza, Star Trek, and 10 PRINT.

so I fixed the INT() problem but now the bit in Star Trek that should say "30 YEARS" now says "29.99999991 YEARS". not sure what happened there.

No, wait... the fast inverse square root does 1 / SQR(X), while what I need is SQR(2) / X.

there's probably some algebraic principle I can exploit to turn one problem into the other, but i've already sprained my brain on it..

Apparently some calculations are resulting in strange results, and it's messing up the galactic map.

i'll deal tomorrow i guess.

Star Trek kinda-sorta works, but there's this overflow error I keep getting.

It uses DEF FN to compute distances with the Pythagorean formula, which uses exponents, which in turn uses division. So there's a chance that the 16-bit division shortcut is to blame. Still, it should be resulting in inaccurate answers, not aborting the program.

I'll have to dive into the floating point routines once again to fix this, and I'll have to do that before releasing this.

It's so obvious now.

Star Trek. That's a BASIC game from the 1970s, and thematically appropriate.

I tried it, and it works with a little modification. It's slow too, probably too slow to play, but you can at least see it working. So it's more like playing Star Trek on a 300 baud modem than anything else.