Planned Tachyon V6 ZOOM - requesting input (and output)



  • P1 is here to stay, or so I'm told, and unless sales figures drop dramatically thus forcing Parallax to cease production, I think it will continue to be used in many projects. I don't do fancy stuff like others here (games, video, sound) and for my current needs what P1 offers is fine.
    I see a SD card addition useful mainly for the development purposes and for the actual device not so much, if at all. It'll be ages before my forth programs need more than 15 kilobytes of space. The P2, while highly desirable, would be an overkill in most cases, feature wise, not to mention the cost.
    That said, I agree with you when you say "Given Peter's commitments with P2D2, we shouldn't expect him to do much on tachyon for some time, either." but I also think, when the time is right, some overhaul of Tachyon is needed and will happen.
    And I am waiting for that P2D2 impatiently and then, even more impatiently, for the alike P1 module Peter mentioned some time ago.
  • When you consider that the P1 has 32k of memory total, and that while each cog has 2k which sounds like something extra, it has to use and be loaded from that 32k etc, then it is even more amazing that we can get so much in there as we do. From the early days we just wanted a P1 with more memory, a P1B, perhaps with few basic enhancements. Now we have the P2 but it's not a small chip, nor is it a single-chip, hence the reason for other small chips that do have the memory. But Tachyon P1 does have a future if the P1V implementation of it into a small and low-cost FPGA is successful. Then again I'd like to experiment and have a minicog in each pin or group of pins etc.

    If all goes well my P2D2 boards and sundries will be here in a few days and I will be busy building up a tester. If I'm happy with the design and how the boards go together I will make up all I can with the stock I have but rather than ordering more parts at the moment I will get quotes on A&T from JLCPCB as they can also supply most of the parts from their LCSC division.

    As you have seen, my designs are based on practical and commercial use, not educational nor hobbyist. Neither are they necessarily plug-in breadboard friendly although one can created a special breadboard JM style. My software is not purely for software purposes, but to run the hardware. My hardware is not ignorant of the software that runs on it either and even the layout reflects how I envisage the software will use it. P2D2 is a holistic design and while it may also look "pretty", it is entirely practical and versatile. At 2.4sq" including connectors it is a very compact design especially considering it is not a "bare-bones" design, but is fully fleshed out, and even more so with the P2PAL "layer" added. But this thread is about Tachyon :)

    (I might repost some of the P2D2 info in its own thread)

  • bob_g4bbybob_g4bby Posts: 109
    edited 2020-10-05 - 07:37:54
    More thinking aloud on the memory constraint thing - the 32k of ram in the case of P1. Tachyon development has always been about squeezing more into that space. An astonishing amount of complex functionality has been made to fit.

    A product designed using tachyon consists of the application code and the 'runtime' code. Ideally, all of the runtime code is called by the application, and no code is left uncalled. This is efficient, in the sense that the most memory is made available for application data. In nearly all forth systems, it's also unachievable.

    I notice that Charles Moore was very keen on the principles of 'less is more' and 'write it yourself'. This was reflected in the small size of the dictionaries in his forths. He minimised the size of the 'runtime' - with good reason - he often had much less than 32k of memory to work with. He also had a drive to reduce problems to the simplest level, which never left him.

    If 'runtime' minimisation is a useful goal - and some might not agree - it begs the question: Just what tachyon words are essential to be able to write and deploy a product? If we look top-down, there would seem to be a small number of essential features necessary: Backup sticks out as an example. Without the word Backup or it's equivalent, you don't save the final application to EEPROM. So, given those essential words, what if we determined what words are essential versus what are not? We might use the machine to help, maybe with a 'dictionary crawler' that drilled down the words to determine all the dependencies.

    Thus the tachyon dictionary might shrink to that which just produces a product and no more. On the other hand, the library folder would expand with various files of words that were taken out. Here, the designer could choose whether some of those words were needed for the product and put them in. At the moment, the system isn't so easy to prune back without inadvertently breaking stuff, as I've commented on in a previous post.

    Disadvantages? Tachyon consists of 3 main files, the kernel, extend.fth and easyfile.fth. They would shrink + you'd have all the new files of 'extras'. Not quite so easy to find that 'must have' word.

    Extending dictionary word search to an sd card, with auto-dependency is one way of fixing the issue. You can have as large lexicon as you like given the space there. It isn't as fast to compile as the all ram resident system that exists now, it just has to be fast enough?
  • I think that's the bucket we need to fill first before we need to find a bigger bucket. I did a lot of squeezing in various forms in V3 and it became counter-productive. I've always had the ability to have the SD card searched for a file that matched any words not found anyway, although I should probably check again how I did that. Once we have an SD card in the system it requires EASYFILE and that uses up more memory but at the same time we can leverage the huge storage capabilities of the card itself. Certainly the help files would be useful but the dictionary even completely reside in SD if need be. This makes more of the 32k available as code space which is obviously much more important. However tools and other debug functions could be loaded in as necessary.

    As for Chuck I think he spends too much time polishing the Forth brass trying to making it as beautiful as possible but that doesn't always make it more usable or practical. The latest forays into Forth chips especially GA144, although much dated now, are so impractical. Sounds good, looks good, but I haven't seen one useful thing that can be done with it.

    Tachyon is about being practical and useful. We can always do a small Tachyon with the same brevity as TAQOZ ROM if there is some advantage in that.
  • bob_g4bbybob_g4bby Posts: 109
    edited 2020-10-05 - 10:44:33
    Enough about space saving, then
  • bob_g4bby wrote: »
    Enough about space saving, then

    Please don't let me stop you though Bob, really. Discussion and arguments for and against stimulate lateral thinking. We are thereby forced to look at things through someone else's eyes and that adds a new angle. I'm not always convinced by my own arguments and I use them like questions too. So don't stop.
  • bob_g4bbybob_g4bby Posts: 109
    edited 2020-10-05 - 14:27:24
    May be useful for SD card interface ideas - this file, line 198 onwards. It's FAT32 too
Sign In or Register to comment.