So, I've got my Upduino boards the other day and found out that the available docs are spread throughout the internet, the code examples don't work or are missing build instructions, and the official manufacturer-supplied tools require multiple hard to remember and follow steps. I figured there's got to be a better way, so I'm describing it here.

So you've got your Upduino. What now?

Upduino is a dream come true for my 8-years-ago self - a cheap FPGA capable of holding nontrivial CPU designs that you can program in an easy way. Like an Arduino. Get it? Upduino. Arduino. Almost as if it were on purpose.

Here's a quick post showing how I solved an issue with an unreliable LTE backup connection. Depending on your hardware, firmware & UI version YMMV.

The problem

It appears that Huawei E3372 frequently disconnects from the LTE network for no apparent reason. It wouldn't be much of a problem if it managed to quickly and reliably reconnect, but that isn't the case it would seem. Whenever that happens packets get lost and websites don't load properly, and overall internet experience is well below acceptable. After some googling it turned out that it might be caused by E3372 automatically disconnecting from the network, but fortunately enough, automatic disconnects when idling seem to be a configurable feature [sic] in the HiLink version of the modem. Less fortunately though, the default interval is set to 5 minutes, and obviously needs to be changed, potentially even disabled altogether. Let's see what the WebUI has to offer in this regard:

Oh...

Recently, I had a craving for some PowerPC action, so I dug up an old PPC970-based machine and had some considerable fun playing with it. The machine in question is an early model of double-processor PowerMac G5, version 7.2 to be exact:

I've decided to write this post because these machines are getting old and any sort of info on how to boot GNU/Linux on them is getting sparser by the year. Especially the correct sort.

Just the other day, while programming in Scala, I was thinking how nice it is that Haskell hides non-strictness (a.k.a. laziness) underneath, so no obnoxious lazy stream creation/forcing needs to be done. And then it struck me: how cool would it be to treat Promises in a language the same way that Haskell treats lazy values? Would such a language even make sense? How would you program in such a language?

Let's explore! You can find all the code included in this post in a more useful form here.

Promise

(define *promises* '())

(define (make-promise value state then handle thunk)
  (list '&promise value state then handle thunk))

;; Field accessors omitted.

(define (promise fun)
  (let* ((val '())
         (state 'pending)
         (on-resolve id)
         (on-reject id)
         (resolve (lambda (v)
                    (set! val v)
                    (set! state 'resolved)
                    (on-resolve val)))
         (reject (lambda (e)
                   (set! val e)
                   (set! state 'rejected)
                   (on-reject val)))
         (then (lambda (t)
                 (if (equal? state 'resolved)
                     (t val)
                     (set! on-resolve t))))
         (handle (lambda (h)
                   (if (equal? state 'rejected)
                       (h val)
                       (set! on-reject h))))
         (p (make-promise (lambda () val)
                          (lambda () state)
                          then
                          handle
                          (lambda () (fun resolve reject)))))
    (set! *promises* (cons p *promises*))
    p))

After a lengthy break I'm back to the UPNOD series. This time we'll take a closer look at the dynamic random-access memory (DRAM) circuitry present on the PCB:

As usual, all of my findings can be found here.

Recently, I came across this post about implementing custom type systems using Prolog and it inspired me to revisit an old logic-programming-related project of mine.

About a year and a half ago I took a shot at using Prolog for type reconstruction (a.k.a. type inference), but that resulted in a load of not much for one reason or another. I did write this Rule-based system shortly thereafter, however I did not give much thought to using it for type reconstruction. Let's change it...

(assert! (: map (-> ((-> (?a) ?b) (list ?a)) (list ?b))))

A second installment in the UPNOD series, this time we'll take a look into the reset circuitry of the telco card.

As the title implies, this circuit is responsible for generating a proper Z80' reset sequence. Z80, being a rather dumb piece of clever electronics, may boot up in an undesirable undefined state and requires a few cycles of special treatment to properly initialize internal register values. This circuit does just that - it generates the initial reset pulse and handles reset signals coming from other parts of the board, all while maintaining proper synchronization.

Cranking out another post took me way longer than I had anticipated when I rebooted this blog, but I got sidetracked by another quick hardware project that turned out to be way more involved and equally more fun than I originally thought...

I've designed an Atari 400/800/XL/XE standard cartridge compatible board that can hold up to 127 different standard 8KB and 16KB game ROMs at the same time. It's memory chip agnostic and features software game selection & a few neat hacks.

Since my last actual post on this blog I have acquired a new class of hobbies - electronics. Most recently, reverse engineering of really old computers. This series of posts will be about a vintage eighties TelCo computer-card-thing marked UPNOD CARD0117 TN64 I bought on a local auction:

All my findings will be posted on this blog and the accompanying data will be gathered in this GitHub repository.

In case you are wondering, here are some questions & answers regarding λ-blog: