New PicoCalc firmware Version 2


#1

A new version of the PicoCalc firmware has been released. This second version updates it to uLisp 4.8f and incorporates the following improvements:

  • An improved extendable implementation of streams.
  • Better truncate, floor, and ceiling functions.
  • Improved Autocomplete (thank you @hasn0life!).

Get it from GitHub here: https://github.com/technoblogy/ulisp-picocalc

What is the PicoCalc uLisp Machine?


#2

I have updated uLisp to version 4.8f on my PicoCalc with Pico 2W using the file from Alternative UF2 images.
It seems that the r command of the edit function is broken. You have to add an extra closing bracket to make the replacement happen and you get the error message „read can only be used with one stream at a time“. Furthermore the replacement is not always what it should be and the with-gfx environment is in most cases not usable anymore.

Best regards
Friedrich


#3

Thanks for reporting that - I’ll have a look at it and see if I can work out what’s happening.

the with-gfx environment is in most cases not usable anymore

Can you give me an example that demonstrates that?

Thanks, David


#4

Take the trivial function
(defun tt (x) (fill-screen) (with-gfx (s) (print (* x x) s)))
Which works fine typed in right after power on. When I replace (* x x) with (* x x x) using edit commands everything looks fine at first but running (tt 7) e.g. causes a short flashing of the screen and below the line
38433> (tt 7) appears the correct result 343. Only the graphic extension or stream related function do not work as expected. Before the editing the screen was blanked and the result displayed in cursor position 0 0.


#5

Yes, I’ve confirmed that if you use the editor ‘r’ command with a form such as:

r(* t t t)

you have to type an extra closing bracket. That’s definitely a bug. I think it’s caused by a change to (read-byte) and (read-line) in 4.8f. Previously you couldn’t evaluate (read-line) at the keyboard and type in a line to be read.

I haven’t been able to get anything strange to happen with your with-gfx example. If I replace (fill-screen) with (cls) it does what you describe. What did it do before the upgrade to 4.8f, and what version were you using previously? I may have to install that and compare the behaviour.


#6

OK, try the following two changes:

In the function object *edit (object *fun) change:

else if (c == 'r') fun = read(gserial);

to:

else if (c == 'r') fun = readmain(gserial);

and:

else if (c == 'c') fun = cons(read(gserial), fun);

to:

else if (c == 'c') fun = cons(readmain(gserial), fun);

Let me know if that restores the correct behaviour.

Thanks, David


#7

The version I have used before was 4.7(d if I remember right), the uf2 file from the alternative images folder. Since the keyboard of the Picocalc is somewhat tricky you have to use the edit function rather often to insert missing characters. No problem with that version.
I will try to compile uLisp as you suggested. I am at the moment travelling and without a suitable computer to compile and flash the Pico 2. I will report on Sunday what I found out. Many thanks for your commitment and your friendly help.
Best regards
Friedrich


#8

I add another example to show the with-gfx problem:
(defun tt (x) (with-gfx (s) (set-text-size 2) (print x s)))
(tt 7) displays a large 7 in the upper left corner.
Editing tt and replacing the (2) by (3) should display an even larger 7, but no large 7 appears. (pprint tt) shows the correct function with (set-text-size 3).
Hope this helps.
Regards Friedrich


#9

I think that’s caused by the fact that if the screen scrolls after you’ve entered the command, the ‘7’ you’ve just displayed gets wiped out by the scrolling screen. To make the screen scrolling efficient it overwrites any graphics on the screen.

If you try:

> (cls) (tt 7)

and press Enter the screen doesn’t scroll and the ‘7’ appears as expected. I’m pretty sure the behaviour with uLisp 4.7d would have been the same.