Cypress EZ-Host Firmware Development Under Linux.

Progress has been slow, because I have been otherwise occupied for quite some time.  Slow, but not entirely still.

Since turning Loper OS into an ab initio CPU architecture project, I have been using Xilinx development boards for prototyping.  For the past year —  an ML-501.  The FPGA toolchain itself is (grudgingly) Linux-friendly, but those for many of the I/O chips included with the board are anything but.

For instance, on the ML-501 (and a few other Xilinx boards) there is a Cypress Semiconductor CY7C67300 “EZ-Host Programmable Embedded USB Host and Peripheral Controller.”  Sounds useful, no?  The free SDK includes a few code examples.  Cypress also distributes an assembler, “QTASM.EXE” (included with the EZ-Host BIOS source code.)  The assembler is Windows-only but will run happily under Wine.  And it would not be too difficult to write your own assembler for this very simple and decently-documented chip.

The Cypress EZ-Host (also called EZ-OTG) should not be confused with the commonplace Cypress EZ-USB chip!  This is a rather different architecture.  None of the EZ-USB tools will work.

Know that the EZ-Host SDK is a cruel kick in the face to a Linux user, because Cypress’s firmware-uploader and memory-dumper tool (”QTUI2C.EXE”) will not run under Wine.  Nor is any source for the tool available.

Imagine there were a construction company which expected carpenters to cut wood only with pocket knives!  Vendors who expect embedded firmware developers to use MS-Windows are just the same.  But odder still are vendors whose SDK is a mix of the reasonably Linux-friendly and the purely MS-bound.  That is quite like mandating pocket knife-only sawing on even-numbered days of the calendar.  (One less-than-shocking example of this: Intel.  And, well, Cypress.)

But, my fellow Xilinx and Cypress sufferers!  The hour of liberation has come! I have written EZOTGDBG, a quick, rough replacement for QTUI2C.EXE. The sole dependency is libusb-1.0. The license is GPL-3.  Friends, please test EZOTGDBG on your boards!   But all normal caveats apply!  In particular, your system will release magic blue smoke under the right circumstances if you don’t know what you are doing (or are merely unlucky.)  But if you own one of these toys you ought to have known that already.

All bug reports / hate mail / etc. for EZOTGDBG should only be submitted as comments to this post.

So what does any of this have to do with Loper?

The USB controller in question will eventually be used for the obvious purpose: as a USB host on which to hang traditional peripherals (keyboards, mice, disks, etc.)  But at that point, there will be no need to flash its firmware from the “mother ship.”

But right now the 67300 sits on “ShortBus”, the Loper prototype machine’s rough analogue to the original Lisp Machine’s “Spy Bus.” The basic idea here is to inspect/manipulate state under remote control.

And so, something like EZOTGDBG is needed, to initialize the controller when Loper cannot yet be relied upon to do so.

Writing programs like this is a misery, but it cannot be entirely avoided if the kind of thing I have in mind is to go forward.

Posted in: Hardware, LoperOS, Progress, Useful by Stanislav 3 Comments

How to Run HyperCard Under Emulation

If you want to try HyperCard yourself, you can download an archive containing a hard disk image with Mac OS 8 and HyperCard installed, plus the ROM image file needed for most emulators, here.

The only Classic Mac emulator I know to work is Basilisk II.  If you run MS Windows, you can get that version here.

All comments regarding this being some morally depraved thing to do will be deleted.

Posted in: NonLoper, ShouldersGiants, small by Stanislav No Comments

Why Hypercard Had to Die

Update: Click here if you would like to try HyperCard yourself.

Hypercard (version 2.4.1.) Home card.

Hypercard (version 2.4.1.) "Home" card.

I was a Hypercard child – though our friendship was brief.

Our seventh-grade class was led into a room full of brand-new Macintosh Performas.  The day’s lesson was a crash course in the use of an uncomplicated yet marvelous program. With it, one might persuade a computer to do anything and everything – or so it seemed to a child with the attention span to appreciate the wonder.  Half a dozen of us were invited back a week later; and then again, and again, for several delicious months.

Among these pupils, I was the only one who had already dabbled in programming.  Compared to the familiar ROM BASIC of my family’s second-hand Commodore 64, the HyperTalk language seemed clunky and comically verbose.  And yet there was something magical, something oddly enthralling about Hypercard as a whole.  The ease with which a mostly-blank screen could be turned into an interactive, living, breathing graphical toy of my own creation was astounding, exhilarating, and addictive.

After the final week, I and one other schoolboy were driven to a distant office building, where we were asked to present our unremarkable creations in front of a darkened lecture hall. The latter was full of somber-faced, suit-wearing adults idly tapping away on costly Apple portables.  With their lukewarm applause, the adventure came to its rather boring end.  Lacking true English fluency at the time, I never learned exactly who was behind this brief departure from the braindead routine of my early schooling.  And without regular access to a Mac (given its expense, it may as well have been a Cray as far as my family was concerned) I could not return to this fascinating plaything.  My development as a programmer continued as it had begun, almost entirely Mac-less and Hypercard-less.

Though almost unknown to the sniveling digital trendoids of today, HyperCard was and is one of the most loved software products ever created. It was quite possibly an inspiration for the World Wide Web.  Among its satisfied users one could even find the rich and famous.

When Steve Jobs returned from exile to rule Apple again, he let HyperCard wither away and die. Why?

In order to answer this question, it is necessary to actually power up an old Mac (or an emulator) and try HyperCard on your own skin.

Even today, there is still a wealth of HyperCard-related material on the Net, but I was unable to find a compact “Hello World”-style walkthrough example.  So I created one: a very basic “four function” calculator.  The materials needed for this recipe were:

  1. Basilisk
  2. A copy of HyperCard
  3. (Optional) A HyperTalk manual. I fished mine out of a dumpster when I was an undergraduate student.
  4. Around half an hour of time.  Most of it was spent arranging the screenshots and writing their captions.

Without further delay:


Create a new HyperCard stack:

(more…)

Laboratory Robotics with Common Lisp

To stave off the never-ending questions — variations on the theme of “Where is Loper? Why the wait?” I would like to confess the following: I live a double life!

I spend my days… working! For money!  So that I can eat.

Here is my current commercial project.

It is a laboratory robotics controller, based on the Programming by Demonstration paradigm.  The beast is made of ~10,000 lines of Common Lisp, sitting on SBCL/Linux.  Much of the code relates to semi-automated protocol reverse-engineering (for adding support for new lab instruments.)

Posted in: Lisp, LoperOS, NonLoper by Stanislav 6 Comments

Roman Lisp

You’ve met the Steam Lisp.  Now meet vitrium flexile, the Roman Lisp:

“… there was an artificer once who made a glass goblet that would not break. So he was admitted to Caesar’s presence to offer him his invention; then, on receiving the cup back from Caesar’s hands, he dashed it down on the floor. Who so startled as Caesar?  but the man quietly picked up the goblet again, which was dinted as a vessel of bronze might be. Then taking a little hammer from his pocket, he easily and neatly knocked the goblet into shape again. This done, the fellow thought he was as good as in heaven already, especially when Caesar said to him, ‘Does anybody else besides yourself understand the manufacture of this glass?’ But lo! on his replying in the negative, Caesar ordered him to be beheaded, because if once the secret became known, we should think no more of gold than of so much dirt.”

The question of whether or not vitrium flexile might have actually existed is beside the point.  The real question ought to be: what keeps a legend like this alive for thousands of years?  What makes the reaction of Tiberius Caesar so believable? Could it be the fact that, then as now, a great many people are unable to distinguish work from production?

Most people might laugh at the idea of rewarding a house painter for using a toothbrush in place of a paint brush.  And yet there are many who eagerly take on the role of this painter when they call for “job creation” and praise “job creating technologies.”

A “job creating” technology is a loss, not a win.

It is a field of wheat burning, a book burning, a glass breaking, again and again and again.  Forever.  Or until the madness stops.

It is a faucet out of which drips death, in little man-hour-sized drops.

Every minute which you spend babysitting a process which could have been automated, you could have been reading a book, writing a symphony, proving a theorem, playing with your children, listening to birdsong.  Being alive.

And if this isn’t true under the economic system you believe in, throw it in the trash where it belongs and forget it like a bad dream. Go find another which isn’t toxic to human life.

RIP jmc.

A giant fell.

And circus pyramids of idiot midgets make cargo-cult noises.

Sniveling trendoids, have you run out of crocodile tears yet?

And his “Maxwell’s Equations of Software”?  How many have even heard of, much less understood them?

They will be remembered long after the last idiot shiny toy maker has closed up shop.

They will be remembered long after all traces of the Great Chiefs of the Iron Age are dust.

They are destined to be forgotten and re-discovered, perhaps many times.  Because mathematics is eternal.

Did you know that there once lived a Soviet John McCarthy? Who remembers?  No one but me? No matter.

But yes, there did indeed.  Because mathematics is “one for all of us, like victory.”  It never goes away.

Generations of time-servers will live and die, but the forgotten jewels will wait patiently for the next explorer, the next brave soul who is not afraid of Upsight.

The universe keeps its most beautiful jewels in a safe that most of us cannot crack or even see.  But JMC could.  And did.

He was worth a billion smarmy hucksters.  Ten trillion superstitious do-gooders.  A googol of Googles.

But now he is gone, and you and I are here.

Posted in: Lisp, Mathematics, NonLoper, ShouldersGiants by Stanislav 13 Comments

The comment box has been fixed.

Posted in: NonLoper, small by Stanislav 4 Comments

Why Skin-Deep Correctness — Isn’t, and Foundations Matter.

Among the advertised features of Apple’s latest OS update, three in particular caught my attention: “auto-save”, which claims to wipe out the abomination of volatile-by-default documents; “versioning”, which claims to introduce document version-control into the Mac’s normal operations; and “resume”, which promises to re-load a user’s work-state whenever an application is re-started.

On the surface, these new features appear to bring in two of what I believe to be the defining attributes of a non-user-hostile computer system:

the Second Law of Sane Personal Computing:

Information which entered the machine through deliberate operator action shall never be destroyed or otherwise rendered inaccessible except as a result of deliberate operator action to that end.  No operator action shall lead to the destruction of information unless said destruction is the explicit and sole purpose of the action.  If all non-volatile storage space that could hold full undo-information for operator-initiated actions is exhausted, the operator shall be informed immediately and given the opportunity to explicitly erase unwanted data or connect additional storage devices, thus preventing unintentional information loss.

and the Third:

Volatile storage devices (i.e. RAM) shall serve exclusively as read/write cache for non-volatile storage devices.  From the perspective of all software except for the operating system, the machine must present a single address space which can be considered non-volatile.  No computer system obeys this law which takes longer to fully recover its state from a disruption of its power source than an electric lamp would.

But… not so fast.  By all means, open your checkbooks, buy the updates.  But before you also buy an icon of Mr. Jobs to kiss, take a moment to think.

As expected, Apple’s promotional material breathes not one word about how these features are implemented.  But the fact that they are advertised as separate features is just about a dead giveaway of how they aren’t implemented.  That is to say: correctly, as a unified whole; in some way which is not, at its heart, a sham, a cheap trick, a fuffle.  But how can we be so certain that we are being fooled?

It is because a system architecture having orthogonal persistence [1] would give you “auto-save” and “resume” for free.  Auto-versioning would follow just as readily from a relatively-uncomplicated mechanism laid on top of an orthogonally-persistent address space. [2]  Apple’s OS update clearly has not removed and replaced the system’s UNIX foundation with something sane, and therefore orthogonal persistence is not to be found in Mac OS 10.7.  It follows trivially that Apple’s auto-save and all related features are implemented by means of demanding ever more pervasive use of proprietary document-specific API calls from programmers.  There is ample precedent: consider Apple’s much-hyped “reinvention” of parallel programming. It might seem like manna from heaven to a thread-addled C/C++/Java programmer, but compared to even the lamest proposals for dataflow-based architectures it is the innermost circle of hell.

Persistence implemented correctly is an architectural simplification, rather than yet another proprietary knob dumped on top of a tall, stinking heap of the same.  With true persistence, user and programmer alike are completely relieved of the burden of thinking about RAM volatility. It simply vanishes as a concern.  Why, then, won’t Mr. Jobs sell you a computer which has this marvelous property?  Is it out of malice, out of a desire to watch you squirm?  No: it is because he simply cannot. While Apple remains the undisputed champion of seamless architecture-hopping, moving between competing instruction sets is nothing compared to even the smallest movement between paradigms.  And that is precisely what a move to orthogonal persistence would be.  The UNIX loader and just about everything connected with the act of manually shuttling data between different forms of storage would have to vanish. The difference between asking developers to port code (what happened after each of Apple’s three CPU swap-outs) and asking developers to junk all code ever written by anyone is, well, a serious one.  Don’t expect this kind of suicidal courage from Apple or from any other commercial entity.  Or from any mainstream organization led by respectable people, for that matter.

All you will ever get from Apple is a “Worse Is Better“, taxidermic imitation of orthogonal persistence.  The same goes for the First Law.  As for the others, just forget it.  Apple’s products shit [4] on the Fourth, Fifth, Sixth, and Seventh Laws [3] enthusiastically and malignantly. [5]  And if you think that this is merely a story about the antisocial behavior of a large American company, you are not seeing the big picture.  Apple’s notions of how to build a personal computing environment are already finding their way into university classrooms.  Not only Tetris-playing accountants, but now so-called academics are eagerly sucking them up.  In the classrooms they will be taught as the best, perhaps the only reasonable notions.  This is when the sun will truly set on the personal computer’s potential as a civilization-level game changer.

Foundations matter.  Always and forever.  Regardless of domain.  Even if you meticulously plug all abstraction leaks, the lowest-level concepts on which a system is built will mercilessly limit the heights to which its high-level “payload” can rise.  For it is the bedrock abstractions of a system which create its overall flavor.  They are the ultimate constraints on the range of thinkable thoughts for designer and user alike.  Ideas which flow naturally out of the bedrock abstractions will be thought of as trivial, and will be deemed useful and necessary.  Those which do not will be dismissed as impractical frills — or will vanish from the intellectual landscape entirely.  Line by line, the electronic shanty town grows.  Mere difficulties harden into hard limits. The merely arduous turns into the impossible, and then finally into the unthinkable.

The typical MS Windows user may never read or write a single line of C++, C#, or any other programming language.  Nevertheless, Windows is ultimately a product of the way C++ built environments; Unix, of the way C does; the Lisp Machines, of Lisp’s way. This holds true not because of some yet-undiscovered law of mathematics, but rather due to the limitations of the human mind.  No matter who you are, regardless of your intelligence, endurance, motivation, or other qualities, your capabilities are still finite. Thus, a “mental CPU cycle” which you spent on manual memory management (or decisions regarding static types, and other drudge work) is one which can no longer be spent on something more interesting.  Any given conceptual foundation sets up a kind of current, against which those who build on that foundation swim at their peril.  To continue with this analogy in reference to modern computing, what has once been a fast-moving stream has now become a high-pressure steel pipe beneath city streets.  A sewer main, to be exact.

Bedrock abstraction is destiny.  This cruel law of nature applies to all aspects of computing, both above and below the level of the programming language.  The Von Neumann Bottleneck is known to many, and is sure to become a dinner-talk phrase among ever less intellectually-inclined programmers as Moore’s Law breathes its last.  But it is not the only conceptual flaw in the foundations of the modern computer.  The pervasive use of synchronous logic circuits is another, far more serious one.  The basic principles of asynchronous digital logic design have been known for more than half a century.  Yet engineers continue to be taught only synchronous design, popular CAD tools remain incapable of asynchronous synthesis, and through the familiar vicious chicken-and-egg circle the tradition persists.  On the rare occasion when someone bothers to design an asynchronous CPU, it invariably turns out to be a mindless adaptation of the tired old crippled Von Neumann paradigm, sans clock.  We can do better than that.  But that is a story for another time.

There are those who tell us that any choice from among theoretically-equivalent alternatives is merely a question of taste.  These are the people who bring up the Strong Church-Turing Thesis in discussions of programming languages meant for use by humans.  They are malicious idiots.  The only punishment which could stand a chance at reforming these miscreants into decent people would be a year or two at hard labor.  And not just any kind of hard labor: specifically, carrying out long division using Roman numerals.  A merciful tyrant would give these wretches the option of a firing squad.  Those among these criminals against mathematics who prove unrepentant in their final hours would be asked to prove the Turing-equivalence of a spoon to a shovel as they dig their graves.

The ancient Romans could not know that their number system got in the way of developing reasonably efficient methods of arithmetic calculation, and they knew nothing of the kind of technological paths (i.e. deep-water navigation) which were thus closed to them.  Who knows what marvels we are denied, lacking the true computer, the true intelligence amplifier, the true labor-saver?  But unlike the Romans, we have some clues regarding the ways in which our foundational concepts are lacking.  Let’s consider alternatives.  Just… consider them.  I ask here for neither respect nor money, but merely that people think.  Pretend that you are doing it only for sport, if you must do so to save face.  But do think.


[1] If you try to research the meaning of the phrase “orthogonal persistence”, you will drown in an ocean of pseudo-intellectual babble.  The original, true idea behind it was that of creating the equivalent of non-volatile RAM, and restricting all of the machine’s user-accessible storage to said RAM.  This is something that once stretched the bounds of the technologically-plausible, but is trivially accomplished today — if you enthusiastically piss on backwards-compatibility.

[2] “…that this margin is too narrow to contain.”

[3] Comments re: the Seven Laws which sum up to “who do you think you are, what, a Euclid, you wanker” will be silently deleted unless they contain an honest attempt at deriving a different, more perfect set of such Laws.

[4] For the idiots who would like to paint me as a paranoid lunatic, a reminder: Apple shits on the principles of sane personal computer design not out of a sadistic desire to torment users, or from a lack of awareness of said principles, but simply because doing so is immensely, irresistibly lucrative.

[5] This is not the place to summarize exactly why, but it suffices to say that Apple is

  1. In bed with copyright racketeers
  2. About as interested in building — or even permitting to exist — the cheap, legal, easily-user-programmable personal computer as Boeing or Airbus are in the cheap, legal, and easy-to-fly private airplane.  The destruction of HyperCard alone is proof of this.

The Ultimate Cross-Platform Malware

The Mac Defender trojan scare confirmed what everyone has suspected all along: that Apple’s products are vulnerable to malware after all!

But we can do better than that!

My new Computer Defender trojan, working on the same proven principles as Mac Defender, will eagerly attack a Mac, a PC, Commodore, Lisp Machine, UNIVAC, arithmometer, and just about any other computing device.  The latter does not even need to be switched on or fully assembled!  Behold:

So, computer insecurity charlatans, how will you defend the public against this grave, unprecedented threat?

Posted in: ModestProposal, NonLoper by Stanislav 6 Comments

The Simplest Lisp Machine

Looking for an inexpensive, robust Lisp system?  Consider this one:

Tried it?  Not satisfied?

Well, don’t blame me: it meets all of the basic qualifications for “Lispiness”:

  1. Does not hide the abstract syntax tree from programmers.
  2. Does not force a non-modifiable syntax on programmers.
  3. Does not impose an arbitrary order of sub-expression evaluation on programmers.
  4. Does not force a bondage-and-discipline type system on programmers.
  5. Does not create an arbitrary distinction between “run-time” and “compile-time.”

There are a great many other things this amazing silicon device refrains from doing!

Such as, for instance… computing.  And yet, it is still a Lisp system!  Lispiness is best understood as a collection of certain unfeatures (that is to say, anti-antifeatures.)  Usually, unfeatures are easy to implement.  In most (though not all) cases, all a designer must do in order to implement an unfeature is to refrain from tying the user’s hands in a particular way.

If you believe that the take-home message of this site boils down to “let’s use Lisp!”, this story is for you — and the above computer should take the place of your PC, until you understand its moral.  Note that the word “Lisp” never once comes up in the Seven Laws page.

Lispiness is merely a starting point, a basic requirement for any halfway-decent mind-amplifier — in much the same way that reasonable non-toxicity is a basic requirement for a tasty meal.


[1] Many more-or-less respectable Lisps are somewhat weak in unfeature #5.  Some so-called Lisps have quietly abandoned unfeature #4. And there are a few programming systems which lack unfeatures #2 and/or #3 — and still manage to be called “Lisps” by some people!  There are even those who refer to systems lacking unfeature #1 as Lisps! What can we say to them?  Words have meanings!  To these lost souls, “lisp” is probably just a speech impediment…

Posted in: Hot Air, Lisp by Stanislav 2 Comments