On 9/14/26 13:00, B9 wrote:
That NODE datapac thingy is a fascinating bit of kit, and yeah, it
would definitely make the phone number to text program simpler.
I think I saw that a while ago and I had dismissed it because it looked
like it didn't have BASIC drivers to show up as a disk drive (or some
new device type.)
No drive hook like that.
The 2 ways to use it from BASIC would be to install RAMDSK (or the NODE
Rom) and call the main routines, or just access the sectors & bytes
directly by reading/writing the control & data ports (no RAMDSK or node
rom needed for that.)
I see your site mentions modifying it for coin cell operation. What
happens when the battery dies?
The data goes poof. But that happens in only a few weeks with the
original nicd battery anyway, while the coin cell lasts years, and you
can change the coin cell without losing anything if you do it while the
card is plugged into the computer. The computer can be turned on or off
while doing that, the computer just needs to have any 1 of it's own 3
sources of power working at the time. (or in the case of MiniNDP, there
is extra cap capacity on VMEM so you get grace period even without any
power.)
What really happens is the coin cell does not get used very much as long
as the computer gets used once in a while and the card is plugged in.
Any time the computer is plugged into the wall, on or off, the computer
is powering the ram and not the coin cell.
When not plugged into the wall, then power comes from the AA's until
they die.
When they die then power comes from the motherboard nicd until it dies.
And only after all that then the coin cell start being used.
Or of course the coin cell is used starting immediately any time the
card is unplugged.
A CR2032 should last 5-7 years by the numbers, and like I said even when
it's time to change it you can do that without losing data.
The Olivetti card only has a CR2016 so that will have less shelf time.
Actually you can probably build the Olivetti card with a CR2032. It's
the same footprint of the pcb, and it's a trivial single number to edit
in the openscad file to generate a taller cover to fit it. What I don't
know is if that taller card & cover will still fit in the space under
the M-10. By eye it looks close, like it might touch the table but still
be ok, or maybe it only fits without a cover? In that case I could
probably modify the cover to be flush with the top of the battery
holder, maybe cover it with kapton or packing tape or a paper or vynil
sticker or something. But the Olivetti version can also safely just stay
installed all the time so it will just naturally be supported by the
computer most of the time as long as the computer gets used once in a
while, so the CR2016 doesn't hurt as much.
The 100/k85 board only has a CR1025, so that will be much less. But that
also just stays installed all the time, so you lose the card data some
unknown number of months or maybe a couple years (but not 5-7) after the
computer's batteries all die.
I could probably make a MRAM version which needs no battery and
supposedly last 100 years. It would need level shifters but I can
probably get them on there, especially with the room freed up by not
needing the battery, even on the tiny 100/k85 board. For that one some
or all of the level shifters would have to go on top, but the chips are
very thin so it's possible. It would also be pretty expensive like
$75-$100 probably, and it would only be 128k or 512k, no 1M. The mram
WP-2 card comes out almost $100, but that includes a commercially 3d
printed part and an expensive connector. The 100/k85 board at least does
not need any cover nor special connector.
By the way, there was a typo in your link. It should be: https://
github.com/bkw777/NODE_DATAPAC <https://github.com/bkw777/NODE_DATAPAC>
I haven't tried Sardine yet and didn't know it had a dictionary.
That's interesting! I bet the "galaxy brain indexing" is based on
Lempel-Ziv (ala .zip), which we've seen the Model T use for compression.
The fragments would be the most common ngrams in English, which means it
might even be directly useful for the phone number-to-word program.
If I recall correctly, the UNIX dictzip program uses LZ repeatedly on
blocks of any given dictionary file to give a compressed file that can
be accessed semi-randomly.
could be!
--b9
On September 11, 2026 8:57:26 AM PDT, Brian White <[email protected]>
wrote:
Correction one bank is 256k.
The device is really like 4 256k disks.
bkw
On Fri, Sep 11, 2026, 11:44 AM Brian White <[email protected]
<mailto:[email protected]>> wrote:
The dictionary in sardine requires a 100k disk used in raw
sector / database mode (not a file in a filesystem) or 128k of
eproms (in a SAFE or booster pack etc), and it's not a list of
words, it's a database of word fragments and some kind of galaxy
brain indexing scheme. Words are built out of re-used fragments,
so the dictionary is larger than however many words would
normally fit in 100k.
It's probably a perfect application for 2 different things I've
worked on but not worth actually doing because the hardware
requirement means there would be almost no users.
One is, dl2 emulates raw sector acces for both tpdd1 and tpdd2,
so you could use dl2 as an outboard database for a dictionary
the same way sardine does. That requires a real tpdd drive, or
dl2 and a whole pc and serial cable. pdduino does not support
it, nor backpack as far as I know. Anyone can use this but it
requires a whole pc so there is no point.
You could just use regular files on a backpack but that's slower
and requires more code. This would be what you'd have to do to
be useful for at least a few users, and not totally pointless by
needing a laptop.
The other is I have made 1 megabyte versions of Node Rampac for
all but NEC machines. These are very simple little devices with
a couple basic chips, and the board sticks right on the machine
and doesn't stick out, and gives you 1M of virtual disk. There
are versions for 102/200, 100 & K85, and M10. It's "disk" but
not tpdd. It's a simpler (from a software pov) direct bus
interface. If you use the device as raw database space instead
of a RAMDSK filesystem, then the software interface is very
simple. You can even do both, use some 128k banks for raw data,
and others can still have ramdsk filesystem.
https://github.com/NODE_DATAPAC <https://github.com/NODE_DATAPAC>
But most people don't have this hardware and I don't even
suggest they all go get it. It's neat and works well, but for a
user a backpack will be more useful all in all. I'm just working
on those because I like it.
I only bring it up because a dictionary would be one of the few
theoretical database type uses that were always mentioned as a
potential use-case but never actually done. Phil Wheeler wrote
some example code in a magazine article and that's all I ever found.
bkw
On Fri, Sep 11, 2026, 1:18 AM B9 <[email protected]
<mailto:[email protected]>> wrote:
Peter: What you are asking for is not easy. The storage
space alone for the dictionary is prohibitive.
Of course, where there is a will, there is a way. For
example, when Brad Grier released Wordle for the M100
(M100LE), I helped him by figuring out a way to compress the
official Wordle word list in a form that allowed direct
lookup from the date so it always had the correct "word of
the day" instantly.
Uncompressed, the wordle word list — which contains every
common five-letter word in a specific order — takes 17K. The
BASIC source code for M100LE is 9K, tokenized. (17K, ASCII).
That would seemingly rule out playing the game on anything
less than a 32K machine. Fortunately, there were two ways to
tackle that:
1. The data was split by year. It was left up to the user to
download whatever years they were interested in. By relying
on the user's intelligence, only 365 words were required to
be in RAM instead of all 2000.
2. Every word was compressed into exactly three bytes.
Reading the file sequentially would have been too slow, so
we indexed the RAM filesystem directly. (A sly trick, yes,
but surprisingly it works portably on all Model T's).
Putting both together, the required word list was reduced to
1K for a single year or 7K for all the years.
I think you will need solutions like that to improve your
phone number-to-word generator. Specifically, I suggest
focusing on the first method: relying on the user's human
intelligence to fill in the gaps the computer has trouble
with. That is the way Model T's have worked historically and
designing for that is part of the challenge of programming them.
The second method, coming up with a fast and small word
checking algorithm is going to be harder and provide less
benefit than leveraging the user's brain. Which is not to
say it shouldn't be done. You may want to try something that
recognizes common English patterns (character ngrams)
instead of using a fixed list. For finding misspellings that
sound right, consider Knuth's soundex algorithm.
John: AI has uses, but I doubt it would make this particular
puzzle any easier. There are plenty of phone number-to-words
example programs it could give you, but the standard
algorithm requires CPU and storage the Model T simply does
not have. What is needed is not regurgitation but novel
insight into how the problem can be redefined to be soluble
on such a small machine.
For me at least, the effort to get something working within
tight limits is a major part of what makes hacking on a
Model T so fun.
--b9
On September 10, 2026 10:41:40 AM PDT, "John R. Hogerhuis"
<[email protected] <mailto:[email protected]>> wrote:
On Tue, Sep 8, 2026, 12:24 PM Peter Vollan
<[email protected] <mailto:[email protected]>> wrote:
There is a program called NUMWRD which finds words
in phone numbers, but it just generates every
possible letter combination. Is there any way to run
it against a dictionary?
Long answer...
That seems relatively hard because of the size of the
English language and the small size of the model t's memory.
There is at least one spell check for the model t's but
I think it stores its dictionary on disk. So I think you
would need probably a combination of compression and
storage beyond the main ram.
You could I guess include words that are exactly 7
letters only. But most letter phone number patterns
rely on dropping vowels or relaxed spelling rules. So
that seems harder too. You need to determine patterns
that look pronouncible even if not spelled correctly.
Plus some readable phone numbers leave some digits as
digits. Like 555-HELP. so even more complicated.
Maybe decide on a set of rules, write a English language
specification of those rules, and ask an AI to generate
C or something and convert it to microsoft basic.
Might have the AI do research even on the rules since I
think such things already exist for other platforms.
Short answer is I don't think anything like what you
want exists for the model t.
-- John.
--
bkw
