BASIC ideas:
- BASIC written in Arduino assembly again
- BASIC written in Common Lisp
- yet another 6502 BASIC
Common Lisp (SBCL) ideas:
- a line editor in Common Lisp
- a static site generator the way i actually like to do it... in Common Lisp
special mention:
- try and remove the C primitives from emacs again
- look into guilemacs again
#ideas #showerthoughts #daydreaming #commonlisp #basic #6502 #arduino #emacs #lisp #elisp #commonlisp #projects #passionprojects #hobbies #guile
Poking thru Compute!, March 1983, there's a mini-language designed by Bill Wilkinson! (BASIC XL, Action!, C/65)
https://archive.org/details/1983-03-compute-magazine/page/192/mode/2up
Bill shares my loathing of algebraic math in mini-languages: "No precedence of operators."
Poking thru Compute!, March 1983, there's a mini-language designed by Bill Wilkinson! (BASIC XL, Action!, C/65)
https://archive.org/details/1983-03-compute-magazine/page/192/mode/2up
Bill shares my loathing of algebraic math in mini-languages: "No precedence of operators."
While I was working on this, the article Python Numbers Every Programmer Should Know appeared on the orange website. In #LuaLang, and on a 16-bit target, these overheads are less -- for example, a number weighs 10 bytes instead of 24 bytes -- but overheads don't have much place to hide on a small, slow machine.
(Btw numbers cost 7 bytes each in 8-bit Microsoft BASIC so Lua isn't gratuitously inefficient here, even by the standards of 50 years ago.)
One place that makes overhead really obvious: a 64K segment holds a table of length, at most, 4,096 entries. That's 40,960 bytes, and Lua's strategy is to double allocation size every time it wants to grow the table. 2 x 40,960 exceeds a 64K segment, so 4,096 entries is the growth limit.
On a 640K machine, after deducting the ~250K (!) size of the interpreter (which is also fully loaded into RAM), you'll get maybe five full segments free if you're lucky. So that's like maybe 20,000 datums total, split across five tables.
Meanwhile a tiny-model #Forth / assembly / C program could handle 20,000 datums in a single segment without breaking too much of a sweat!
The efficiency has costs to programmer time, of course. Worrying about data types, limits, overflows, etc. The kinds of things I was hoping to avoid by using Lua on this hardware -- and to its credit, it does a good job insulating me from them. Its cost is that programs must be rewritten for speed in some other language once out of the rapid prototyping phase and having reasonable speed / data capacity becomes important.
I'd estimate the threshold where traditional interpreters like Lua become okay for finished/polished software of any significant scope, is somewhere around 2MB RAM / 16MHz. So think, like, a base model 386. Maybe this is why the bulk of interpreters available in DOS are via DJGPP which requires a 386 or better anyway.
#BASIC was of course used on much smaller hardware, but was famously unsuited to speed or to large programs / data.
I know success stories for #Lisp in kilobytes of memory, but I'm not quite sure how they do it / to what extent the size of the interpreter, and overhead of data representation (tags + cons representation), eats into available memory and limits the scope of the program, as seen with other traditional interpreters.
This is beginning to explain why #Forth has such a niche on small systems. It has damn near zero size overhead on data structures. (The only overhead is for the interpreter core (a few K) and storing string names in the dictionary (which can be eliminated via various tricks)). ~1x size and ~10x speed overhead is the bargain of the century to unlock #repl based development. However, you're still stuck with the agonizing pain of manual memory management and numeric range problems / overflows. Which is probably why the world didn't stop with Forth, but continued on to bigger interpreters.
Esta es otra forma de programar en Basic ZX Spectrum.
Redacto el programa en Basic en un editor de texto como nano y lo convierto en cassette de formato .tap con bas2tap, un programita genial hecho por Martijn van der Heide, el creador de la web World of Spectrum.
Es mucho más cómodo programar con el portátil desde GNU/Linux que con el The Spectrum.
i think the little game i have been coding in BASIC has been coming together quite well
Arrays and string arrays in BASIC are simple and powerful.
I like the syntax-- A(B,C) or S$(B).
Makes me wonder. Writing a BASIC interpreter with a strong focus on the power of DIM and array operations would be interesting.
currently live coding in BASIC
https://spectra.video/w/jvves1Y5zC7f7uZpqETm4x
#livecoding #live #basic #retrocomputing #retro #retrogames #retrogaming
currently live coding in BASIC
https://spectra.video/w/jvves1Y5zC7f7uZpqETm4x
#livecoding #live #basic #retrocomputing #retro #retrogames #retrogaming
Esta es otra forma de programar en Basic ZX Spectrum.
Redacto el programa en Basic en un editor de texto como nano y lo convierto en cassette de formato .tap con bas2tap, un programita genial hecho por Martijn van der Heide, el creador de la web World of Spectrum.
Es mucho más cómodo programar con el portátil desde GNU/Linux que con el The Spectrum.
A Basic Just-in-Time Compiler
https://nullprogram.com/blog/2015/03/19/
#HackerNews #A #Basic #Just-in-Time #Compiler #programming #compiler #technology #just-in-time #learning
By 100x speed difference, I mean the uu encoding/decoding rate is about 30 bytes per second. I'm not accustomed to a correct program being this catastrophically slow ;)
Not throwing shade at #LuaLang for the 100x speed difference: it's astonishing that a modern interpreter can be built for a 4.77 MHz 8088 and run at usable, if lukewarm, speeds. The 100x size difference comes down to the interpreter including Lua's full library, most of which isn't needed for all programs.
If I had to guess, I'd expect most of the time to be spent in string operations and syscalls. Lua translates file contents to (immutable) string when reading, so more conversions are necessary to perform transformations and output results. Moreover, when writing output the program does f:write() 3-4 bytes at a time: if this were unbuffered and translating directly to hundreds of write syscalls, that would also be very slow.
While I was working on this, the article Python Numbers Every Programmer Should Know appeared on the orange website. In #LuaLang, and on a 16-bit target, these overheads are less -- for example, a number weighs 10 bytes instead of 24 bytes -- but overheads don't have much place to hide on a small, slow machine.
(Btw numbers cost 7 bytes each in 8-bit Microsoft BASIC so Lua isn't gratuitously inefficient here, even by the standards of 50 years ago.)
One place that makes overhead really obvious: a 64K segment holds a table of length, at most, 4,096 entries. That's 40,960 bytes, and Lua's strategy is to double allocation size every time it wants to grow the table. 2 x 40,960 exceeds a 64K segment, so 4,096 entries is the growth limit.
On a 640K machine, after deducting the ~250K (!) size of the interpreter (which is also fully loaded into RAM), you'll get maybe five full segments free if you're lucky. So that's like maybe 20,000 datums total, split across five tables.
Meanwhile a tiny-model #Forth / assembly / C program could handle 20,000 datums in a single segment without breaking too much of a sweat!
The efficiency has costs to programmer time, of course. Worrying about data types, limits, overflows, etc. The kinds of things I was hoping to avoid by using Lua on this hardware -- and to its credit, it does a good job insulating me from them. Its cost is that programs must be rewritten for speed in some other language once out of the rapid prototyping phase and having reasonable speed / data capacity becomes important.
I'd estimate the threshold where traditional interpreters like Lua become okay for finished/polished software of any significant scope, is somewhere around 2MB RAM / 16MHz. So think, like, a base model 386. Maybe this is why the bulk of interpreters available in DOS are via DJGPP which requires a 386 or better anyway.
#BASIC was of course used on much smaller hardware, but was famously unsuited to speed or to large programs / data.
I know success stories for #Lisp in kilobytes of memory, but I'm not quite sure how they do it / to what extent the size of the interpreter, and overhead of data representation (tags + cons representation), eats into available memory and limits the scope of the program, as seen with other traditional interpreters.
This is beginning to explain why #Forth has such a niche on small systems. It has damn near zero size overhead on data structures. (The only overhead is for the interpreter core (a few K) and storing string names in the dictionary (which can be eliminated via various tricks)). ~1x size and ~10x speed overhead is the bargain of the century to unlock #repl based development. However, you're still stuck with the agonizing pain of manual memory management and numeric range problems / overflows. Which is probably why the world didn't stop with Forth, but continued on to bigger interpreters.
O único jogo de macaco (ou gorila?) que consigo lembrar agora vinha de exemplo com MS QBASIC e/ou com MS-DOS 6, salvo engano. Embora também não me lembre do nome disso, mas achava divertido. Tinha que dizer a força e o ângulo da banana a ser arremessada pra ver se atingia o gorila do outro lado. 
Algo assim.
#old #dev #basic
tc-ematch(8) extended matches for use with "basic", "cgroup" or "flow" filters
https://man7.org/linux/man-pages/man8/tc-ematch.8.html
#HackerNews #tc-ematch #extended #matches #basic #cgroup #flow #filters #Linux
Unfolding "Die große #BASIC Referenztabelle der 51 Dialekte" - a chart that compares 51 different BASIC dialects, published in 1984:
(Get your own copy: https://www.ebay.com/itm/276431614056)
The latest prototype of my tiny BASIC interpreter can save programs in CCITT-2 encoding, so it can in theory write programs to 5-channel paper tape. I have a paper tape punch, but it has an RS530 interface, so I need a converter to RS232, which seems to be hard to come by these days. I bought a used one that is supposed to be in "good working condition", but comes without any documentation. Why am I even doing this? :)
#retrocomputing #papertape #baudot #BASIC
I finally received my PicoCalc yesterday. I’ve installed the included pico and tried out a simple basic program.
Now it’s time to start modifying it. I’m going to upgrade to a Pico 2W, and try out the python firmware.
After that I’m going to try compiling a Rust program for it.
