TUNIX

[pixel]

Still no cigar time .Yes, some big-ass bugs gone. Most notably an issue with READ on ends of files which put back a 0 into the buffer.
Also CBM DOS status codes are fetched after OPEN. Heap size is reducing again.

Also: images. Not for multiple heaps yet (like the VIC uses). Maybe later today. If you saved an image called 'image', it'll load automatically. Bugs are inevitable. Good luck!

Code: Select all

; On the C64 and Plus/4 you can load all that's there to load:
(load "all.lisp")
; When finished (and your computer turned retro), do a:
(isave "image")

D64 images have gone as they're becoming too small. It was nice to play around with them any way. Modern drives are better suited for this.

With VICE you can jump into one of your target's directories and launch TUNIX Lisp conveniently:

Code: Select all

cd tunix/vic20
xvic -attach8rw -autostartprgmode 0 -moncommands lisp.lbl lisp

The moncommands will give you nice disassemblies in the VICE monitor.

Overlays will be required soon for 6502 targets.

Have fun!

[pixel]

Stabilizing bug fixes. No image support with the Unix version and with the Plus/4 the ROM suddenly gets banked in.

The z88dk compiler seems to be one of a kind, so no CP/M version. Am hoping that some expert can fix that build. Same with the PET.

Oh, yes, added additional error info like lists of missing arguments.

Have fun!

[pixel]

Only few bekloppies later, the function that handles BUTLAST, COPY-LIST and REMOVE (copy_list() with different modes) has been re-implemented.

A bit more fun ensured.

[pixel]

Can't quit messing around with this.

Cons compression is disabled. It will have more value with full heap compression and copying garbage collection. It shouldn't be done during GC as it can be quite time-consuming. Awesome for creating environment images and app releases. For the latter there's, by the way, compile-time option "NAIVE" which disables all kinds of error checks (~3K code). There are quite a lot of options, so it should work on any micro-controller worth 5 cents.

There's more heap any way. Overlays and banking come to mind but the evaluator alone is 5.5K and the heap cannot be banked. I'm sure. Bytecode procedures could be.

Included .lbl, .map, and .dbg files if you like to peek and poke around in the binaries.

Have fun!

[pixel]

Release v0.0.1 is out! https://github.com/SvenMichaelKlose/tunix/releases

It has CHAR-AT, returning the value of a symbol name character at some position, and SYMBOL-NAME, giving you a symbol's name as a list of character values.

And it's a bit faster.

Have fun!

Oh! And it's MIT licensed.

[pixel]

It's release v0.0.6. (EDIT: v0.0.7 - a regular v0.0.x emergency release)

Download: https://github.com/SvenMichaelKlose/tun ... tag/v0.0.7
Changelog: https://github.com/SvenMichaelKlose/tun ... angelog.md

Am hacking towards a very simple text editor to integrate. Doodled this so far: https://github.com/SvenMichaelKlose/tun ... /edit.lisp. Want to find out how usable it'll be performance-wise.

Found some cc65 optimization bug, but it'll rarely hit. Such things are always mean but it should be going away within the next couple of days.

Some averages:

Code: Select all

2655    lisp            lisp=1430,ansic=1097,asm=127,sh=1
299     simpleio        ansic=299
178     simpleio-cbm    ansic=178
151     simpleio-stdlib ansic=151

Total Physical Source Lines of Code (SLOC)                = 3,283
Development Effort Estimate, Person-Years (Person-Months) = 0.70 (8.36)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.47 (5.60)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 1.49
Total Estimated Cost to Develop                           = $ 94,130

The manual is another 1.8k of Markdown with lots of things missing and there are also Makefiles and scripts and what not.

Setting things up for the Raspberry Pi Pico is a pain at the moment. However:

Have fun playing around!

[pixel]

I'm pretty sure it was one of my bugs, not cc65. That's quite a relief.

[pixel]

v0.0.10 it is: https://github.com/SvenMichaelKlose/tun ... ag/v0.0.10

It's really getting tight for the VIC now, but still good to experiment with a couple of expressions.

[pixel]

Trying to escape into the weekend will probably be interesting with that new set of laptop batteries. Would love to finish the editor and not stop until it's done, but wetware has its limits. (One more minute and I'll qualify for an official care level and free drool bib.)

The Lisp code to play around with amounts to >1,800 locs now. Only the C128 and Plus/4 are booting properly. (It's still too early to start optimizing stuff.)

https://github.com/SvenMichaelKlose/tunix

Have fun!

[pixel]

The Word for Sunday

[pixel]

There's a v0.0.17 already but not much reason to go waste a night on it: https://github.com/SvenMichaelKlose/tun ... ag/v0.0.17

An auto-loader is making life easier and the editor is as responsive as a typewriter. That breaks the roadmap, so it's writing the compiler with host software instead – a much simpler version to at least kill the overhead of flow control in a handful of passes.

Have fun!

[pixel]

Oh dude. Several v0.0.x releases happened since the last post, each one fixing something utterly idiotic. Not so idiotic was the call to stay straight and not mess around with memory expansions.
"test-all.lsp" is now dragging along on the C128 too. Thanks to AUTOLOAD the trick is to throw everything out and have stuff re-loaded on demand if the heap is getting too tight.

Just so you know it's continuing... with the regular, frustrating set of bugs. More writing tests ahead...

BTW: Compiled for the Z80-CPU the code doesn't look much better nor is it any smaller than the 6502-CPU versions. Wrote a bit of a 6502 assembler in TUNIX Lisp.

[pixel]

We'll have to skip a couple of releases here until it's working on the VIC again (no memory). There's been quite a performance boost of 10%-40% thanks to a couple of pointer handling tricks around the NIL object and a redo of parts of the evaluator. But there's more to get out of it. A damn break for example. As for that huge, pink elephant in the nerd cave: the latest bytecode interpreter design promises 15k calls per second of overhead. Being so super-fast it should be blowing everyone's hair back in intervals, collecting garbage every other second.

Add native types (and overloaded code generation macros) and the thing could become self-hosting and even faster. Good to know that a long-term hobby with passion is also key to a long life...