[HN Gopher] The Forth Deck mini: a portable Forth computer with ...
___________________________________________________________________
The Forth Deck mini: a portable Forth computer with a discrete CPU
Author : hggh
Score : 272 points
Date : 2024-06-26 20:12 UTC (1 days ago)
(HTM) web link (mynor.org)
(TXT) w3m dump (mynor.org)
| artemonster wrote:
| I have used to have an obsession with Forth and discrete CPUs
| when I was a teenager (if you google hard enough you will find an
| ancient webring of homebuilt CPUs out of discrete components),
| this obsession led me to my profession now - Digital Hardware
| Designer. My heart fills with joy when I see such posts at top of
| HN :) Great work!
| pushfoo wrote:
| TL;DR: Looks like a step toward the AlphaSmart of programming
|
| If you don't remember the AlphaSmart[1], it was a line of
| typewriter-like devices with small LCD displays. They ran on
| batteries for hours and had limited save space. You could hook
| them up to a larger computer to save your drafts.
|
| Where's the programming version of that? The recent HN post[2]
| about running a Mac 128k on a RPI2040[3] got me thinking about
| that. In theory, you could get real work done on a system like
| that, although it wouldn't be very good for entertainment.
|
| So, where's the AlphaSmart of low-power computing?
|
| 1. "Real" keyboard
|
| 2. Low-power display, ideally a larger e-ink one
|
| 3. Not connected to the internet
|
| To be clear, I don't mean a TI-83-like[4], TI-92[5], or even the
| recent NumWorks[6]. Those are meant to be calculators and have
| inconvenient calculator-like form-factors.
|
| [1]: https://en.wikipedia.org/wiki/AlphaSmart
|
| [2]: https://news.ycombinator.com/item?id=40699684
|
| [3]: https://axio.ms/projects/2024/06/16/MicroMac.html
|
| [4]: https://en.wikipedia.org/wiki/TI-83_series
|
| [5]: https://en.wikipedia.org/wiki/TI-92_series
|
| [6]: https://www.numworks.com/
| voltaireodactyl wrote:
| Even just an e ink alphasmart would be killer -- the key
| feature for me was the Mac keyboard + shortcuts so I never had
| to think while using it.
| pushfoo wrote:
| TL;DR: Freewrite[1] tries but it isn't the same
|
| They are selling a line of professionally oriented devices.
| I'm not sure they're worth it.
|
| * The "Alpha" model[2] nods to the AlphaSmart form factor,
| but it isn't e-ink
|
| * Weird-looking keyboard layouts with no Apple-style key in
| sight
|
| * These devices are expensive for what they seem to offer
|
| I've never used one so I can't really speak about more than
| what I've seen on the site. There were some negative reviews
| of earlier models. I'm not sure how current ones rate, nor
| what their keyboard feels like.
|
| [1]: https://getfreewrite.com/
|
| [2]: https://getfreewrite.com/products/alpha
| kragen wrote:
| i've been wanting that for years myself, and with the advent of
| sharp's memory-in-pixel lcd displays and ambiq's subthreshold-
| logic arm microcontrollers, it's become possible to make it
| work under a milliwatt, which means it can run purely on solar
| power without batteries, using parallel nand flash for mass
| storage at a low duty cycle. i haven't progressed beyond the
| earliest prototyping stage myself; my design notes on the so-
| called zorzpad (mostly in spanish) are in
| http://canonical.org/~kragen/sw/zorzpad.git/ and za3k vance has
| been working on a project inspired by it called the zorchpad
| https://blog.za3k.com/tag/zorchpad/
|
| the primary objective of the zorzpad is longevity, with a
| design lifetime of 53 years. to reach that objective i think i
| can't use batteries, charging ports, or off-the-shelf
| keyswitches. this forces a lot of compromises on the system
| design; i haven't found a processor with an mmu that can run at
| under a milliwatt
|
| ("zorzpad" is a pun on "thinkpad"; it's pronounced "thorthpad"
| in some spanish dialects, so it's the opposite of a thinkpad)
|
| i think e-ink displays probably use way too much power. for
| years i've been looking for solid power consumption numbers,
| but in their absence, dividing an amazon swindle's battery life
| by its battery capacity suggests that they use about 100
| milliwatts. the zorzpad's e-ink displays are about a tenth as
| big, use about a thousandth as much power (100 microwatts), and
| can be updated at 60 hertz (though the datasheet only
| guarantees 20)
|
| if you aren't worried about going batteryless, or about mass
| production, you could literally buy an alphasmart neo and wire
| its keyboard and display up to an esp32 or something
| e63f67dd-065b wrote:
| My understanding is that eink only uses power on refresh; if
| you don't change the image, the pigments remain where they
| are and draw no power.
| kragen wrote:
| yes, that's right. so there's a refresh rate crossover
| point at which e-ink actually uses less power. my
| calculations from the very uncertain information i have is
| that it's around 20 minutes. that is, if you update the
| display once every five minutes, the e-ink display will use
| significantly more power than the memory-in-lcd display
| updating 60 times a second. there are real limits to the
| utility of a computer that needs several minutes to redraw
| its display; though i wouldn't venture to say that it's
| useless, you can't do anything similar to a conventional
| gui on it
| kristopolous wrote:
| The hisense e-ink phones are known to have week long
| battery lives (A5 and A9) so I'm thinking not all e-ink
| is the same. I know there's e-ink nerds out there and
| forums dedicated to it but I don't actually know the
| different types (here's an overview I think:
| https://en.wikipedia.org/wiki/Electronic_paper). Maybe
| the good stuff is harder to find
| kragen wrote:
| the amazon swindle is known for a month-long battery
| life, so a week is easily believable. but you're talking
| about how to solve a different problem
|
| if batteries are an option, e-ink is a super-low-power
| option because it uses 100 milliwatts or maybe 10
| milliwatts at a cellphone size, while a conventional
| backlit color lcd uses 1000. but to run off solar panels,
| indoors, my power budget for the whole zorzpad is 1
| milliwatt, and the screen can only have a fraction of
| that
| pushfoo wrote:
| TL;DR: I love this idea and have two questions:
|
| 1. For early iterations / similar projects, could all-metal
| screw terminals[1] accept power internally?
|
| 2. Would supporting UXN/Varvara[2] be an option?
|
| More on these questions below after initial comments.
|
| ## Initial Comments
|
| > if you aren't worried about going batteryless, or about
| mass production, you could literally buy an alphasmart neo
| and wire its keyboard and display up to an esp32 or something
|
| I could, but it's a limited in availability. The keyboard is
| pretty important in my opinion.
|
| > memory-in-pixel lcd displays
|
| I vaguely remember hearing about this, but don't have the EE
| knowledge to judge the benefits of these. Data sheet for
| anyone interested: https://www.sharpsde.com/fileadmin/product
| s/Displays/Specs/L...
|
| ## 1. The screw terminal:
|
| Disclaimer: I'm not an EE specialist.
|
| My understanding is that if the power loss isn't too great,
| an all-metal internal screw terminal[1] might improve device
| durability:
|
| * The power source could be replaceable. AA, AAA, LiPo,
| solar, etc
|
| * If you don't solder to the metal part, even sandpaper or a
| conveniently shaped rock could remove oxidation
|
| * For a case, internal screw terminals could turn a charging
| port into an easily replaceable component
|
| ## 2. UXN/Varvara:
|
| From your blog, I see an "artemis apollo 3 board"[3] is being
| used. From a Sparkfun page[4], it seems to have enough ram to
| host graphical Varvara.
|
| I was initially doubtful of UXN despite loving the idea, but:
|
| 1. The UXN community seems to have built a self-hosting
| ecosystem[5] of: * development and GUI ROM
| launching tools * text, font, and graphics
| editors * music sequencing tools
|
| 2. The UXN VM is light: 64k system ram, 4-bit 2-plane color,
| and misc state and debug
|
| 3. The core UXN VM is simple: a minimal implementation fits
| in under 150 lines[6] of C89
|
| [1]: https://en.wikipedia.org/wiki/Screw_terminal
|
| [2]: https://wiki.xxiivv.com/site/varvara.html
|
| [3]: https://blog.za3k.com/zorchpad-update-cardboard-mockup-
| mk1/
|
| [4]: https://www.sparkfun.com/artemis
|
| [5]: https://github.com/hundredrabbits/awesome-uxn
|
| [6]: https://wiki.xxiivv.com/etc/uxnmin.c.txt
| kragen wrote:
| i'm glad to hear you find it appealing! i'll explain some
| of my thinking on these issues, some of which is specific
| to my own eccentric objectives ( _nobody_ designs computers
| to last decades) and some of which is more generally
| applicable
|
| screw terminals or post terminals are a good idea if you're
| going to have charging and want longevity. but charging
| implies batteries. and batteries themselves induce lots of
| failures; they typically have a design lifetime of two
| years, more than an order of magnitude too low for the
| zorzpad. by itself that's not a fatal flaw, because you
| could replace them, but it becomes fatal in combination
| with either of the two supplementary flaws:
|
| 1. battery shelf life is limited to about 10 years, except
| for lithium thionyl chloride and so-called 'thermal
| batteries' that use a molten-salt electrolyte (kept frozen
| during storage). consequently, if your computer needs
| batteries, after 10 years you're dependent on access to not
| just a market but a full-fledged industrial economy to keep
| your computer running. a friend of mine in rural romania
| has been trying to build a usable lead-acid battery from
| scratch to provide energy storage for his solar panels, and
| it's motherfucking _difficult_ without that supply chain
|
| 2. batteries have a lot of failure modes that destroy the
| devices they power. overheating, swelling, leaking
| corrosive electrolytes, and too much voltage are four of
| them. if these failure modes were very rare (like once in
| 100 battery-years) that might be okay, but they aren't
|
| for me these are fatal flaws, but for others they may not
| be. if you can afford batteries, you can run for one hell
| of a long time on a single 18650 lipo on a milliwatt. a
| coin cell can deliver a milliwatt for a month
|
| as for uxn, uxn is the first attempt at frugal "write once,
| run anywhere" that's good enough to criticize. everyone
| should read devine's talk about its aspirations
| (https://100r.co/site/weathering_software_winter.html)
|
| however, uxn is not frugal with cpu, or fast, nor is it
| good for programmer productivity, and it's not all that
| simple. It's designed for interpretation, which inherently
| means you're throwing away 90% or 95% of even a single-
| threaded cpu, and it's not designed as a compilation
| target, which means that you're stuck programming at the
| assembly-language level. This is pretty fucking fun, but
| that's because it makes easy things hard, not hard things
| easy; the offgrid notes lionize oulipo
| (https://100r.co/site/working_offgrid_efficiently.html)
|
| as a result of the efficiency problems, the platforms with
| complete uxn implementations (see
| https://github.com/hundredrabbits/awesome-uxn#emulators)
| are the luxurious ones: microsoft windows, linux, amigaos,
| the essence operating system, anything that can run sdl or
| lua and love2d, gameboy advance, nintendo 64, nintendo ds,
| playdate, and the nook ereader: all 32-bit or 64-bit
| platforms with ram of 4 mebibytes or more, except that the
| gba only has 384 kibibytes, and there were amigas with as
| little as 512k (though i don't know if they can run uxn).
| more limited machines like the gameboy, ms-dos, and the zx
| spectrum do not have complete uxn implementations
|
| (384k is the same amount of ram as the apollo3, so it's
| probably feasible, as you say)
|
| the uxn machine code is basically forth. forth is pretty
| aesthetically appealing to me, and i've gotten to the point
| where forth code is almost as easy for me to write as c
| code (though i have to look things up in the manual more
| often and have more bugs). however, it's much, much harder
| for me to _read_ forth than it is to read c. it 's harder
| for me to read forth code than to read _assembly_ for any
| of 8086, arm, risc-v, i386, or amd64. possibly i just haven
| 't written enough forth to have the enlightenment
| experience yet, but currently my hypothesis is that forth
| is just hard to read and that's it, and that the really
| great thing about forth is not actually the language but
| the interactive development experience
|
| the varvara display model is not a good fit for the memory-
| in-pixel displays, which only have one bit per pixel, while
| varvara requires two. also, evaluating things 60 times a
| second is not a good fit for low-power systems of any kind.
| and i'm not sure how well the existing varvara applications
| will work at 400x240 or tolerate a requirement to use fonts
| many pixels tall in order to be readable
|
| (a lot of the above notes are from xpasm.md in
| http://canonical.org/~kragen/sw/pavnotes2.git/ if you're
| interested in the context)
|
| as for tools for software development, program launching,
| editing text, editing fonts, editing other graphics, and
| sequencing music, i'm confident i can write those myself if
| i have to. i've written a compiler in a subset of scheme
| that compiles itself, a compiler in a forth-like language
| that compiles itself, various toy text editors, various
| virtual machines in under 150 lines of code, and various
| pieces of music synthesis software, and i've designed a few
| fonts of my own (though not using software i wrote)
|
| maybe i should set up a patreon for this or something,
| maybe people would be interested in supporting the project
| pushfoo wrote:
| TL;DR: Thank you for confirming some mismatch in display
| hardware and project goals
|
| > also, evaluating things 60 times a second is not a good
| fit for low-power systems of any kind.
|
| Agreed. As to a terminal-mode UXN, you pointed out:
|
| > as for uxn, uxn is the first attempt at frugal "write
| once, run anywhere" that's good enough to criticize.
| everyone should read devine's talk about its aspirations
|
| I think it's the primary use case like Java Applets and
| Flash preceded JS as iterations of sorta-portable and low
| efficiency tools which make up for it with sheer volume
| of high-familiarity material.
|
| > nor is it good for programmer productivity
|
| I'm curious about this. Could you please elaborate?
|
| When trying earlier uxntal versions, the worst part
| seemed to be the string syntax. If it wasn't because it
| seemed easier at the time, my guess is the pain point
| might be intentional nudges away from making things the
| designer doesn't like.
|
| > and it's not all that simple.
|
| This is where I get confused:
|
| * Can you explain more about your views on this?
|
| * Do you favor a specific structure of hardware, OS code,
| and user scripts, or whatever ends up offering the best
| use of power and long-term device durability?
|
| > i'm not sure how well the existing varvara applications
| will work at 400x240 or tolerate a requirement to use
| fonts many pixels tall in order to be readable
|
| Counting mW and decades implies text > GUI. Despite 100r
| & fans favoring GUI, there's an UXN terminal mode and a
| few math and terminal libraries written for it.
|
| As to GUI, many of the ecosystem's GUI programs are FOSS
| with room to shrink the graphics. There's a decent 4x6 px
| ASCII font which is CC0 and could help, but as fair
| warning, it's awful at accents and umlauts.
|
| > possibly i just haven't written enough forth to have
| the enlightenment experience yet, but currently my
| hypothesis is that forth is just hard to read and that's
| it, and that the really great thing about forth is not
| actually the language but the interactive development
| experience
|
| This seems to be a universal opinion since REPL isn't
| rare anymore. Being portable and easy to bootstrap are
| probably the main draw now. In addition to 100r's work, I
| think remember hearing ${NAME}boot or another project
| used it to simplify porting.
|
| > the varvara display model is not a good fit for the
| memory-in-pixel displays, which only have one bit per
| pixel, while varvara requires two.
|
| Ah, this is what I suspected. I wasn't sure I understood
| the display you mentioned, so thank you for confirming
| the hardware mismatch.
|
| Although your blog showed you'd considered two identical
| side-by-side displays[1], I have a radical idea which
| might not be a good one:
|
| 1. A "Full" display of W x H characters (the Sharp
| display or whatever you replace it with)
|
| 2. A "Fallback" 1 or 2 line display (2nd line reserved
| for editor info / UI?)
|
| A single 1-bit editable line is so hard to work with that
| ed[2] isn't even installed by default on many Linux
| distros. However, people _did_ once got real work done
| with it and similar tools.
|
| As a funny sidenote, this is where non-colorForth[3]
| forths may align with UXN's dev. He's a Plan9 fan and
| uses its Acme editor[4]. So Varvara is theoretically
| capable of syntax highlighting, but he refuses to
| implement it as far as I know.
|
| > as for tools for software development, program
| launching, editing text, editing fonts, editing other
| graphics, and sequencing music, i'm confident i can write
| those myself if i have to. i've written a compiler in a
| subset of scheme that compiles itself, a compiler in a
| forth-like language that compiles itself, various toy
| text editors, various virtual machines in under 150 lines
| of code, and various pieces of music synthesis software
|
| You may be pleasantly surprised by how many people will
| show up if you start building and releasing tools which:
|
| * let them solve problems or have fun
|
| * allow extending the tool
|
| * can be used to build their own tools
|
| Many will will even contribute back. To paraphrase the
| Gren[5] maintainer's recent livestream:
|
| > we've had more engagement in our time on Discord than
| all our years on Zulip.[6]
|
| > maybe i should set up a patreon for this or something,
| maybe people would be interested in supporting the
| project
|
| Based on your blog, I think you can safely skip to the
| footnotes:
|
| * GitHub sponsors might be worthwhile if you're willing
| to use non-fully FOSS platforms
|
| * Don't make people feel like they're paying for their
| own work
|
| * Do let the system do real-ish creative work and self-
| host, even if only as emulators
|
| If you'd like, I can provide more specific suggestions.
|
| [1]: https://blog.za3k.com/zorchpad-update-cardboard-
| mockup-mk1/
|
| [2]: https://en.wikipedia.org/wiki/Ed_(software)
|
| [3]: https://concatenative.org/wiki/view/colorForth
|
| [4]: https://wiki.xxiivv.com/site/acme.html
|
| [5]: https://gren-lang.org/ (Disclaimer: I sorta
| contribute to this now)
|
| [6]: https://www.youtube.com/watch?v=PO8_pV7r168 (Sorry,
| I don't have an exact timestamp, but I'm pretty sure it
| was in here)
| kragen wrote:
| i'll reply in more detail later but for the moment i just
| want to clarify that i'm not za3k, although i've been
| collaborating with him; his priorities for the zorchpad
| are a bit different from my priorities for the zorzpad
|
| you said:
|
| > _I think it 's the primary use case like Java Applets
| and Flash preceded JS as iterations of sorta-portable and
| low efficiency tools which make up for it with sheer
| volume of high-familiarity material._
|
| i wasn't able to parse this sentence. could you unpack it
| a bit?
|
| you said:
|
| > _If you 'd like, I can provide more specific
| suggestions._
|
| yes, please! even if our priorities aren't exactly
| aligned i can surely learn a lot from you
| pushfoo wrote:
| > 'll reply in more detail later
|
| np! I'll comment now in case it gets weird about a
| double-comment on the same parent by the same user.
|
| > > I think it's the primary use case like Java Applets
| and Flash preceded JS as iterations of sorta-portable and
| low efficiency tools which make up for it with sheer
| volume of high-familiarity material.
|
| > i wasn't able to parse this sentence. could you unpack
| it a bit?
|
| Software that doesn't care about being well-made or
| efficient. It doesn't matter because it's either fun or
| useful.
|
| > > If you'd like, I can provide more specific
| suggestions.
|
| > yes, please! even if our priorities aren't exactly
| aligned i can surely learn a lot from you
|
| This is a long topic, but some of it comes down to
| Decker[1] vs Octo[2]'s differences:
|
| * Decker can be used to make and share things that
| process data
|
| * The data itself can be exported and shared, including
| as gifs
|
| * Octo can't really, but it does predate the AI
| commnity's "character cards" by shoving game data into a
| "cartridge" gif
|
| * Octo has LISP Curse[3] issues
|
| I'm serious about the LISP curse thing. In addition to
| awful function pointers due to ISA limitations, everyone
| who likes Octo tends to implement their own emulator,
| tooling, etc and then eventually start down the path of
| compilers.
|
| I haven't gone that far _yet_ , but I did implement a
| prototyping-oriented terminal library[4] for it. Since
| Gulrak's chiplet preprocessor[5] is so good, I didn't
| bother with writing my own.
|
| > i just want to clarify that i'm not za3k
|
| Ty for the reminder. On that note, the larger font sizes
| you brought up are seeming more important in this moment.
| I don't think I can deal with 4 x 6 fonts on tiny screens
| like I once could. HN's defaults are already small
| enough.
|
| [1]: https://github.com/JohnEarnest/Decker
|
| [2]: https://github.com/JohnEarnest/Octo
|
| [3]:
| https://winestockwebdesign.com/Essays/Lisp_Curse.html
|
| [4]: https://github.com/pushfoo/octo-termlib
|
| [5]: https://github.com/gulrak/chiplet
| contingencies wrote:
| Awesome art project. Where did you get 53 years from? I
| think, for longevity as a design criteria, including the
| documentation including design files is the best and most
| significant strategy.
|
| Mechanical: machine everything out of solid metal, over-spec
| the springs, seals and potential ingress point precision.
|
| Electronics: fat traces, replacement-optimized through hole
| components, socket-mounted chips, over-rated everything,
| passive cooling, conformal coating, arrays of smaller
| components in preference to single large components.
|
| Fasteners: easy grip broad head twistable screws only,
| potentially to double as stands, this ensures accessibility
| until fingers become obsolete.
|
| Software: ROM base system with physical restore function,
| dual ROM with mutual checksum if required, RAM for everything
| else.
|
| Digital storage/retrieval: Solid state only.
|
| Physical output: Optional low-longevity RS232 receipt printer
| for retro effect.
|
| Power: Solar + supercaps and/or a corded pull-out analog
| watch-style shake-to-charge assembly and/or a thermal charger
| utilizing thermals from combustion and/or a pneumatic charger
| utilizing common compressed air interfaces as a power source.
| kragen wrote:
| thanks! your ideas are mostly pretty good
|
| i agree that the machine should be fully self-describing,
| like darius bacon's 'book in itself'. of course, that won't
| help you if it won't turn on...
|
| rather than just conformal coating and seals, i'm thinking
| i'll not just conformally coat the boards, but also pot the
| whole assembly in something like silicone or toilet-ring
| wax, so that the potting material can be removed, but
| otherwise it's trivially ip68. except for the keyswitches,
| but the keyswitches can be a magnetic type that doesn't
| have any exposed electrical contacts or any springs
|
| solar-powered devices generally don't have to worry too
| much about cooling, though. or if they do it's from the
| heat they passively absorb from the sun, not from anything
| they dissipate internally. if your solar panels are 10%
| efficient (the best you can get out of amorphous silicon,
| which is the only kind that works under indoor lighting)
| and cover 30% of your device, they only harness 3% of the
| illuminance, which is later converted to heat in the
| circuitry. the other 97% is either reflected or converted
| into heat immediately. so the heat produced internally is
| only about 5% of the heat it has to deal with. now think
| about how much heat you feel on your skin from indoor
| illumination; we're talking about 5% of _that_
|
| socket-mounted chips tend to induce a lot of unreliability,
| so i don't favor them. desoldering surface-mount chips is a
| bit of a pain but still done routinely in cellphone repair
| shops around the world. but i want it to make it to its
| design lifetime without replacing components, and one
| reason for that is that i don't want to depend on the
| economy. (consider what components were commonplace in
| 01971 and how many of them are hard to obtain nowadays --
| and that was 53 years of relative peacetime. imagine trying
| to get parts today in moscow.)
|
| unlike batteries, chips _do_ have a long shelf life, so you
| could conceivably stockpile chips today for future repairs.
| but if you 're going to do that, probably the best place to
| stockpile them is on circuit boards inside the device, so
| you don't have to solder anything to fail over to them.
| that's not applicable for every device, but fortunately
| things like voltage regulators have very low failure rates,
| and you can still probably build in redundancy at a higher
| level. that's what we did when i worked on satellite
| systems: of _n_ identical systems onboard, we only needed
| one to survive to run the satellite. there were even
| multiple power buses, so that even a failure that shorted a
| voltage rail to ground would only disable part of the
| satellite
|
| as i understand it (not having taken the measurements yet
| myself) over-rating is especially important for bypass
| capacitors in this context -- not because they're prone to
| failure (unless you're using tantalums) but because
| capacitors have enormously higher leakage near their rated
| voltage
|
| if you want to build such a thing and have a mechanical
| charging option, i think a pullstring like 20th-century
| children's windup toys is the best option. it's compact,
| the spring constrains how much force you can apply to the
| generator and runs it at a predictable speed, and the
| pullstring grommet constrains the direction of force
| applied to the mechanism so that kofi annan can't break it
| by applying side-loading to your crank handle like he did
| with olpc. but i don't think electromechanical generators
| are likely to fit into the reliability budget
|
| for screws, i think protruding screws would catch on my
| pockets. but there are lots of ways to fasten things
| together in reopenable ways, especially if you don't need
| seals. if you did want to use conventional milled-head
| screws, well, i filed a flathead screwdriver out of a bolt
| a few months ago. i used a file, a vise, and a steel bolt.
| but exposed screws would tend to rust unless you made them
| out of titanium or something, which isn't an option for me
|
| a metal case has advantages and disadvantages. being able
| to take input power inductively (qi style) or communicate
| over rf could be useful, which you can't do with an all-
| metal case. metals are not very chemically stable, except
| for gold, silver, platinum, iridium, palladium, lead,
| nickel, aluminum, titanium, tin, and chromium. most of
| these have major disadvantages of their own, though
| titanium would be a pretty good option. many plastics are
| very chemically stable, including polypropylene, polyester
| terephthalate, silicones, and epoxy resins, and the epoxies
| in particular can be glass-fiber reinforced up to steel-
| like strengths and stiffnesses. so that was my plan
|
| why 53? i just like 53
| contingencies wrote:
| Pocketable wasn't in my mental spec, agree this is a good
| idea. You can also inset them.
|
| Marketing a portable as Kofi-proof is a neat marketing
| angle ;)
|
| Depending on your radio frequency perhaps you could put
| your RF behind your screen to get signal out, or use a
| slot as the antenna, or have a fold-out or telescopic
| antenna, or have a screw-on antenna port exposed when you
| open the thing, or some combination thereof.
|
| Aluminium's fine for cases, cheap, light, castable,
| extrudable, cheaply machined, and readily anodized.
|
| Steel won't rust for ages if it's of a decent chemistry
| and either treated and/or oil is used when the thread is
| mated. Even steel that appears heavily rusted after many
| decades of total abuse can be restored quite easily to a
| good state in many cases. I mean people had multi hundred
| year old wooden structures ... I don't think an embedded
| steel thread with an oil surface coating is going to
| disappear overnight. As a learning project I recently
| restored a 1980s drill press, that's basically 40 years
| old which is ~most of your target length, it had
| apparently been left with exposure to moisture for 20+
| years, and was mostly intact. The net result of the
| learning was it's not worth restoring old drill presses,
| but I sure learned a lot!
|
| For maximum chip shelf life, you want to store them in
| nitrogen or some similar inert gas.
|
| With Wikipedia and survivalist content modules you could
| market this to the prepper crowd. Of course long distance
| radio would be an add-on. As would the radio direction
| finding hardware, encryption, etc.
|
| I still like the pneumatic idea. 100% of existing bicycle
| pump hardware becomes your viable charging interface.
| Speaking of which, a low profile wheel based generator
| would be a good add-on module.
| kragen wrote:
| those are good ideas about antennas
|
| i hadn't actually considered machining it out of an
| aluminum billet. you might be right that it would be
| adequately stiff, even if it's much less stiff than
| glass-fiber-reinforced epoxy. it's much heavier than
| epoxy, but only slightly heavier than glass, and of
| course most of its grades are enormously less brittle
| kragen wrote:
| oh, i don't know why i didn't answer the stuff about
| steel and preppers and pumps; maybe it was a brain fart
| or maybe you edited it in later. i'll try to answer later
| contingencies wrote:
| Yeah it was a few edits. I often stay on a theme awhile
| once consciously captured, resulting in a re-read and new
| ideas/tweaks. Ninja skill: trainable psycho-inertia, AKA
| "focus", now perhaps ostracized as a 'spectrum member'
| activity, I believe it was merely associated with clarity
| of thinking and general education in the 19th and early
| 20th centuries.
| kragen wrote:
| so, with respect to steel, i think a steel case in a
| sweaty pocket will rust rather quickly and
| comprehensively, even if it's a good steel. often
| alloying elements that improve steel's mechanical
| properties make it _more_ prone to rust rather than less
| so
|
| i'm guessing the drill press was not in working condition
| after the 20 years of moisture, and i'm assuming you mean
| something like 'in a basement with relative humidity that
| reached 100%' or 'with the bottom resting on moist soil'
| and not 'under dripping water for 20 years' or
| 'underwater for 20 years'
|
| i don't really have a good way to machine steel anyway,
| and it's inconveniently heavy. aluminum is amenable to
| wood rasps and drills
|
| i think probably embedded in silicone or paraffin wax or
| something would be better than just stored in nitrogen.
| gottta be careful of static buildup tho
|
| while i sympathize with preppers in some ways (i, too,
| value autonomy) i think they might be a hard group to
| market to. a friend of mine occasionally reads
| survivalist board forum and there's a lot of toxic ultra-
| right-wing stuff there; i don't want to be lynched for
| not supporting trump
|
| you can of course do secure encryption on any general-
| purpose computer unless you're trying to defend against
| side-channel attacks. i ran pgp on a 286, and we have
| more efficient algorithms now
|
| long-distance radio is potentially interesting but i
| agree that it's probably a different piece of hardware;
| short wavelengths can only go short distances unless
| they're bouncing off the moon or something, and you need
| a long antenna to transmit long wavelengths efficiently,
| although efficiency isn't a significant concern for
| reception (at transcontinental-capable wavelengths radio
| noise is a bigger concern than noise generated inside
| your amplifier). so for long-distance radio you probably
| need a large, fixed antenna installation rather than a
| pocket computer
|
| my concern with pneumatic-to-electric power is that it's
| probably hard to make reliable. but i don't really know
| nine_k wrote:
| I wonder what's the point to run.batteryless? With such a
| small power budget, the device should accumulate energy when
| it can harvest more than it needs to consume, and use it when
| the lighting conditions deteriorate. It would only take a
| really small battery, but would seriously increase
| usefulness.
| kragen wrote:
| i've discussed the reliability problems of batteries
| further in https://news.ycombinator.com/item?id=40805573,
| but, as an intuition pump, consider that when cellphone
| repair shops advertise particular repairs, the particular
| repairs they advertise most are battery replacement,
| charging port replacement, and broken screen replacement
| nine_k wrote:
| So use a battery of a standard form factor and make it
| easy to replace. E.g. one AAA battery per device is
| easiest. Most coin-sized lithium batteries are also
| rechargeable, explicitly or implicitly.
| kragen wrote:
| you don't seem to have really understood my points,
| because you aren't engaging with them; as it happens,
| you're also mistaken about coin-sized lithium batteries
| (though any battery can be _slightly_ recharged)
| thetoon wrote:
| What do you mean by implicitly? Last time I checked, most
| of button/coin-like batteries (CR2032 and the such)
| aren't know to be rechargeable, unless you specifically
| get rechargeable ones.
| nullc wrote:
| Have you given much though to the idea that parts which are
| inexpensive and shelf stable could just be bulked up? Long
| lifetime won't save you from parts that just get damages from
| wear and tear.
|
| For something like a keyboard, it might be better to have a
| box of spares, rather than trying to build for 53 years of
| use and abuse... just as an example.
| kragen wrote:
| yeah, it might be a reasonable choice for mechanical parts
| like keyswitches and hinges. i think keyswitches with a
| wearout life of a billion cycles keyswitches isn't
| infeasible either, but testing them to verify the cycle
| life could be challenging
| bloopernova wrote:
| An e-ink with an HDMI input would be fantastic.
| rom16384 wrote:
| Dasung makes e-ink monitors, with an HDMI input, such as the
| Dasung Paperlike.
| cancerhacker wrote:
| TRS-80 Model 100 seriously fits the bill. Basic, word processor
| and spreadsheet in ROM, pixel addressable display, fabulous
| keyboard for its size. RS-232 and 300bps modem. The recent
| Clockwork-PI evokes it - but the keyboard is a toy and then
| it's just a Linux laptop with all the distractions therein. The
| Model 100 was carried by journalists well into the 90s, to
| compose and upload stories to service bureaus.
| Jun8 wrote:
| I had one and in a moment of greed sold it :-( What I loved
| about it was:
|
| * Used regular batteries, no charging, easily obtainable,
| lasts _quite_ a bit
|
| * Keyboard was awesome
|
| * Retro look & feel
|
| * Size
|
| What I didn't like:
|
| * 8 line display is tiny!
|
| * Would prefer a bit smaller
|
| * Getting data off is a pain (ether are many workarounds but
| you have to fiddle with it)
|
| So, assuming a $200 price point and using the 5x rule of
| thumb for HW products, BOM should be $40. Problem is eInk
| displays are kind of expensive. Putting $15-ish for a 7-inch+
| display, rest seems bearable doable. (I've never developed a
| consumer HW product, so these are wild guesses.)
| nine_k wrote:
| What's the point of e-ink? I's good when the picture
| changes once in a few hours, sucks for word processing.
|
| A monochrome transreflective LCD (without a backlight)
| would consume fractions of a milliwatt, can be a high
| resolution graphical display or character-based display,
| and would look plenty sharp under direct sunlight. Also
| widely available and inexpensive.
|
| It can't have such a high contrast as e-ink though.
| kragen wrote:
| typically monochrome transflective lcds consume quite a
| bit more than fractions of a milliwatt, though it does
| depend on how big they are. the two-line reflective lcds
| commonly found on pocket calculators do indeed consume a
| fraction of a milliwatt, but power consumption scales
| mostly with display size
|
| e-ink is fast enough to be usable for word processing
| because the updates are small and incremental and, most
| importantly, can tolerate some ghosting
| JKCalhoun wrote:
| Yeah, best compromise is a single row LCD display for the
| "live", "editing" line of text and then eInk for the rows
| of text above. Of course scrolling the eInk is still
| slow.
| pushfoo wrote:
| TL;DR: The TRS-80 Model 100[1] indeed looks closer than the
| AlphaSmart!
|
| If something like that TRS had e-ink, it might be what I'd
| had in mind. If you're familiar with the idea of the OLPC
| hardware[2], like that except:
|
| * More durable
|
| * Lower power
|
| * E-ink
|
| * Not effectively vaporware
|
| On a related note, I heard Pixel Qi[3] displays were
| interesting. However, the company folded. Some panels seem to
| pop up for sale now and then, but my understanding is they're
| effectively obsolete.
|
| > The recent Clockwork-PI evokes it - but the keyboard is a
| toy
|
| That's a shame.
|
| > it's just a Linux laptop with all the distractions therein
|
| After taking a look at the device, this seems like an
| understatement. The Clockwork-PI[4] looks like it's mostly an
| emulation machine. For anyone who doesn't want to click
| through, it's a Game Boy form factor with a few extra buttons
| and a keyboard below the D-pad.
|
| To be fair to the device, I think it's different class of
| device. It also fills some very specific niches:
|
| 1. Prototyping for GB/GBC games on higher-power hardware and
| higher-level languages
|
| 2. A decent front-end attached sensors if you can use USB
|
| As example of #2: Mapping WiFi signal strength. Walking
| around a building holding a clunky laptop while someone else
| held the antenna wasn't fun. It was what we had to work with
| given the deadline, but if I had to do it often, I might want
| something like the Clockwork PI if someone could source
| better keyboards.
|
| [1]: https://en.wikipedia.org/wiki/TRS-80_Model_100
|
| [2]: https://en.wikipedia.org/wiki/OLPC_XO
|
| [3]: https://en.wikipedia.org/wiki/Pixel_Qi
|
| [4]: https://www.clockworkpi.com/
| cancerhacker wrote:
| Just to be clear - I was referring to what they call the
| "Devterm"[1] with the wide screen and toy keyboard. They
| even sell it in a color scheme that matches the Model 100 -
| and it has a built in printer like the Epson (?
| Something-20) if that era.
|
| [1] https://www.clockworkpi.com/devterm
| eschneider wrote:
| I always loved the simplicity and form-factor of the Model
| 100. For a "practical" modern version, the tricky bit is
| getting data on and off. Wifi/ethernet would definitely
| replace the modem, but for comms ssh/scp isn't that
| convenient for folks looking for something "simple".
| Personally, some combination of Dropbox-esque file sharing
| and SMB disk mounting strike me as practical.
|
| I doubt that there's anything like a commercial product here,
| but I find it a really fascinating design space.
| Jun8 wrote:
| I would plunk down $199 _right now_ for a basic version of this
| (more with extra features, e.g. WiFi, expansion lot, etc). My
| key use case would be using in on planes, esp. when the jerk in
| the from title their seat all the way back.
| kstrauser wrote:
| Take my money. I want a little thing like that to carry in my
| bag for writing when the inspiration strikes. I'd be
| perfectly ok with it being append-only as long as it could
| easily dump data back to my laptop for real editing later on.
| kragen wrote:
| this is one of my key use cases for the zorzpad, but i want
| to be able to program it, because often what i'm writing
| are algorithms
| kstrauser wrote:
| I'm torn. One hand: Yeah! Other: I don't need more
| convenient distractions at hand. Programmability is an
| attractive nuisance _for me_.
| kragen wrote:
| yeah, i have that problem too :(
| NovemberWhiskey wrote:
| WiFi? What? How would you even use that?
| fragmede wrote:
| I'd say the Cardputuer is closest to what you're asking for.
|
| https://docs.m5stack.com/en/core/Cardputer
| dsalzman wrote:
| I use an Alphasmart Neo for journaling. Recently modded it with
| an ESP32 for wireless file transfer. I love it!
|
| https://www.dannysalzman.com/2024/06/20/modding-alphasmart-n...
| simlevesque wrote:
| woah, four lines display ? that's luxury. I remember coding on a
| single line display, kids these days...
| rbanffy wrote:
| My Epson HX-20 has 4 lines but only 20 characters each.
| ForHackernews wrote:
| Hmmm... http://collapseos.org/forth.html
| xlii wrote:
| There's implementation of Forth for Cardputter[0] if anyone is
| interested. I tried to boot it and it worked.
|
| I'm not a Forth enthusiast myself but was thinking about doing
| something with Uiua, as I think it's really fun toy language for
| such application.
|
| [0]: https://github.com/ryu10/M5CardForth
| andypiper wrote:
| Oh, interesting. Would that be installable OTA using
| M5Launcher?
| mongol wrote:
| Reminds me about Oric-1
|
| https://en.m.wikipedia.org/w/index.php?title=Oric_(computer)...
| mjg59 wrote:
| Some prior art in terms of computers with built-in Forth
| interpreters: https://en.wikipedia.org/wiki/Jupiter_Ace
|
| And, of course, the Open Firmware used on Suns, PowerPC Macs, the
| One Laptop per Child, and others made use of Forth (including for
| the ROMs in expansion cards, allowing them to be CPU-agnostic):
| https://en.wikipedia.org/wiki/Open_Firmware
| phire wrote:
| I love reading about optimised Discrete CPUs like this.
|
| Only 16 logic ICs. Doesn't even have an adder, the only ALU
| function is a 1 bit Nor gate.
|
| Details on this page: http://mynor.org/my4th.htm
| bananaboy wrote:
| This is fantastic!
| fallat wrote:
| I've built 5 of the author's My4th Light boards. Contact me (bio)
| if you're interested in one. I wouldn't mind building a batch of
| Forth Deck minis if people are interested too.
|
| I plan to do a small demo video on Forth but haven't gotten
| around to it yet.
| spiritplumber wrote:
| The Parallax Propeller 2 comes with this by default, check it
| out.
| anigbrowl wrote:
| If you are into tiny computers but not especially moved by Forth
| or the prospect of soldering, you can get a rather capable ESP32
| box for $30: https://shop.m5stack.com/products/m5stack-cardputer-
| kit-w-m5...
| bottom999mottob wrote:
| Wow... everything from M5Stack looks capable for the price. $30
| for the capabilities of the Flipper Zero is nice.
| anigbrowl wrote:
| Yes, though note you'd need to add a few modules to get the
| full capabilities of the FZ (eg the RFID reading and 432Hz
| antennas iirc). Be warned that the documentation is kinda
| minimal, so if you're new to IOT stuff there's quite a
| learning curve. There are fairly decent core libraries in C
| and also a fairly capable micropython stock, but you have to
| be willing to figure out a lot of stuff on your own or with
| the help of their user forums.
| notatoad wrote:
| every time somebody posts the M5stack site, i just want to
| order everything.
|
| but on some level, i know it'll all end up on the pile of
| projects that i've started and not yet finished.
| xattt wrote:
| "Backorder"
| anigbrowl wrote:
| It appears as available for me. As a fairly regular buyer
| from them (but not in commercial quantities or anything
| close) my experience is that their restocking turnarounds are
| usually only a few weeks. They're very responsive via email
| if you want to inquire ahead.
| kstrauser wrote:
| What's the OS like there? I'm guessing you're not booting into
| a Wayland desktop. However, that's way more powerful than the
| Amiga I emulated over the weekend and it had a full GUI
| desktop, compilers, and all sort of other stuff.
|
| Basically, what can you do with it out of the box?
|
| Edit: Dont' care; ordered anyway. I'll find out when it gets
| here. I still wonder what I can get excited about in the mean
| time.
| anigbrowl wrote:
| It comes with a demo, which does not do much (edit text, run
| a python REPL, record and play back audio). Since you've
| ordered one, you have a few options; use the pretty solid
| ESP/IDF IDE to program it in C and start familiarizing
| yourself with the M5unified stack*, or if you are more of a
| Python person check out M5stack's UIflow tool.
|
| This implements a Scratch-like component-plugging interface,
| but also gives you access to a Python editor that works in
| parallel with it. This makes prototyping very easy and is a
| handy way to get familiar with the CPU modules and built-in
| peripherals because most (though not all) of the
| functionality is implemented there.
|
| * https://github.com/m5stack/M5Unified
| kstrauser wrote:
| That's right up my alley. I can't wait!
|
| (But I'll have to.)
| t-3 wrote:
| There does exist a Forth for it though:
| https://github.com/ryu10/M5CardForth
| nullc wrote:
| you can also get ESP32S3 boards with a gps, lora radio, lipo
| charger, and oled screen for ~$28... common device for
| meshtastic.
| electrodank wrote:
| What is this exactly? What do you do with it?
| fallat wrote:
| You program anything your heart desires :)
|
| * it can be a calculator * it can be a text editor * it can be
| a side scrolling shooter * it can be a text adventure * it can
| be a life simulator * it can be an algorithm playground * it
| can be a way to work on larger programs in smaller pieces in
| quiter places!
|
| etc.
| whartung wrote:
| What's the modern day barrier to creating a "hobby" TRS-80 Model
| 100?
|
| 40x8 LCD display, one of the best keyboards ever made.
|
| I see the custom keyboard community seem to be able to make any
| keyboard they like.
|
| The keyboard on the Model 100 consumed the majority of its space,
| but at the same time, it was usable. I don't know what a
| reasonable display would be. The notable thing about the 40x8 is
| that it was big enough to be usable, and it was readable. I've
| seen some decks with tiny 640x480 displays, and they're not
| readable, particularly to my aging eyes.
|
| The Psion 5 had a very usable keyboard, and better display than
| the M100. I don't know if that kind of keyboard can be made by a
| hobbyist like the other ones can. I don't know enough about
| keyboards. I don't know if one of those could be gutted and
| repurposed. (No doubt considered sacrilege to some.)
|
| We see these "decks" with these matrices of buttons, but I'd dare
| say they're not really keyboards. The PET 2001 kind of proved
| that (and I did a lot of coding on a PET back in the day).
|
| So, just curious what's stopping "real" ones, "nice" ones from
| showing up. I'd dare say money, but I see what folks spend money
| on for their hobbies, so it can't be that alone. Doesn't have to
| be a viable product for market.
| Gracana wrote:
| Finding big low resolution displays is a pain. Pixel density
| has increased a lot, so larger displays are high resolution,
| which means you need a much faster device to drive them, and at
| that point it starts to feel a little silly because your
| display controller is way more powerful than the actual
| computer.
|
| That's the stumbling block I've run into, anyway. It's plenty
| doable, it just feels sillier than I intend.
| bongodongobob wrote:
| Why would you? Back then, keyboards weren't peripherals. Now
| they are. Restricting peoples choice doesn't make sense. Get
| whatever keyboard you want. What's stopping _you_ from using
| whatever keyboard you want? Nothing, at that 's what progress
| looks like. Buy whatever keyboard you want.
| robxorb wrote:
| Substitute "keyboard" for "computer" for most of your comment
| to see how it misses the point.
| bongodongobob wrote:
| Right it's a computer. Where parent misses the point is he
| can buy an old TRS if that's what he wants or he can try to
| build one himself. Wondering why people aren't building
| custom keyboards and 4x8 displays or whatever is pretty
| obvious, it's not 1972.
| trueismywork wrote:
| If you're using it to develop bare metal os then writing
| keyboard driver is the issue
| boffinAudio wrote:
| >What's the modern day barrier to creating a "hobby" TRS-80
| Model 100?
|
| Nothing:
|
| https://www.clockworkpi.com/home-devterm
| fouc wrote:
| I'm imagining software developers using this as their primary
| work device. Like authors that use typewriters. Distraction
| free.
|
| If they need to develop for the web, they can just prop their
| phone above the display, and develop in mobile-first style.
| tailrecursion wrote:
| The CPU for this computer is microcoded and is made out of a
| small number of discrete logic chips, plus an EEPROM. The data
| and address bus are 8 bits wide but the NOR unit operates on one
| bit only. The microcode has to loop in order to perform an 8 bit
| add.
|
| I was looking for a hardware shifter in the diagram, because I
| figured it'd be necessary to access bits D1-D7. But there is
| none. He uses a lookup table in EEPROM to do the shift.
|
| If you're interested in nice CPU designs, here's another one: the
| Novix NC4000 (also RTX2000), in which the bits in the
| instructions lead directly to control various muxes and units
| inside the chip. There's almost no decoding.
| abdellah123 wrote:
| how much does this cost?
| Pet_Ant wrote:
| What I'd love is a dialect of Factor written in Forth so that it
| could be run on these machines. Factor is a much higher-level
| Forth that is usable for scripting. Would make it more fun to
| use.
| eschneider wrote:
| Oh, this is _nice_! It's not quite what I'd want, but all the
| schematics and software is there, so it wouldn't be too hard to
| change things to taste. :)
___________________________________________________________________
(page generated 2024-06-27 23:02 UTC)