Does this short square root program help at all?

https://github.com/revaldinho/opc/blob/610e6269d2c82d72dba3ba038ac6041bed11a2d8/opc5ls/sqrt.s#L73

these types of projects can be very challenging, not just on the technical aspects, but also in carrying them out to their logical conclusion. once you've met all your core goals, it's pretty hard to stretch it out further. i've had my own issues with my current cpu design as well ( https://hackaday.io/project/158510-ddl4-cpu/log/155698-where-to-go-from-here ). there is a pretty decent article on hackaday about deciding when to call a project done ( https://hackaday.com/2018/09/25/productivity-unfinished-projects-and-letting-go/ ). as a side note, i've been working a 5-bit tape reader design for another project....

Thank you for the article.

>Kid In A Candy Store Syndrome
>Doing Only The Interesting Parts
Exactly me. Definitely should try to fight it with the said methods.
>as a side note, i've been working a 5-bit tape reader design for another project....
Could you elaborate on the principle? Is there description online?

the tape reader project is for my WITCH replica design - https://hackaday.io/project/19955-witch-e-decimal-based-computer , i haven't posted a lot of info on it as of yet. the base is laser cut acrylic with the frame from a small Point-of-Sale printer. The "tape" is printed from another POS printer, and the "dots" are read with IR sensor. here are some photos of the prototypes - https://photos.app.goo.gl/9ZPoz1QFMBz23pDa7

Another way to match the rule "no silicon" could be to add a punched tape reader for bigger programs, with a mechanism that enables to "step" this punched tape in both directions. The real ROM should only contain low level functions, like "microcode". And the punched tape should contain "macro instructions" (as opposed to "micro instructions").

The "goto/jump" in your paper-tape-code should be "relative" : "step punched tape 24 steps forward" or "step punched tape 11 steps backward", etc...

This way, you could write quite big programs, with hundreds of "macro instructions".

I like the idea of using a punched tape, but the prospect of building the reader itself with only diodes, relays and motors seems terrifying. If only there was some kind of reversible clock-like-mechanism, that would move the tape one step at a time in the desired direction.

2 answers for that issue:

* yes, you should find a mechanism which moves the tape just 1 step, with 1 single electric impulse. Instead of "motor", you could use "electro magnet", one for each direction.

* the remaining of the logic could be directly integrated in the "microcode" with for example of macro instruction "step forwart xx steps". 

If you drop your "no silicon" requirement a bit, you can connect a flash ROM that gives almost infinite program space. Just add a few bits to your program counter.

You might get inspired from https://hackaday.io/project/11012-risc-relay-cpu, where I do that. The flash is programmed by a Raspberry Pi in my case. You could also use arduino.

And yes, it is not easy to find a nice demonstration program for a small or slow system. I have plans for a mechanical computer, that might also have 64 program steps, but can do no more than perhaps 3 instructions per second. The lack of a nice demonstration program keeps me from building it.

I still intend to keep "no silicon" requirement because it's one of the main things that drives me in this project, but thank you for the suggestion.

>I have plans for a mechanical computer ... but can do no more than perhaps 3 instructions per second

Why 'but'? My machine is also 2-3 IPS. Please let me know if you'll come up with something for your mechanical computer!

I have an idea for a small demo program... how about the mouse-in-a-maze like Shannon did build ? That also worked with relays.