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.) I see your site mentions modifying it for coin cell operation. What happens when the battery dies? By the way, there was a typo in your link. It should be: 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. --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]> 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 >> >> 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]> 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]> wrote: >>> >>>> >>>> >>>> On Tue, Sep 8, 2026, 12:24 PM Peter Vollan <[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. >>>> >>>> >>>>
