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