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. >> >> >>
