Discoveries made while pursuing what has turned into a [constructive] obsession.
Initially, it was purely replacing my old 3D raytraced masthead on my Tech CV, with a logicsim demonstrating my expertise in both coding and hardware design. While that seemed complex at the time with merely a fixed fairly simple circuit, it now looks a lot simpler, in comparison to a whole FPGA. Saying I do logic design using paper and pencil, is sometimes more impressive than Verilog, and somehow less impressive... Is my Linux box good enough to run Lattice's freeware? Nope! Then I remembered Restart (DWP) had offered to buy me a laptop, but in the meanwhile, can I work out how to make an FPGA, and run than as a logicsim in SVG & javascript? Yes, so it seems, and employers might like it too: So that comes full circle. No Verilog compiler there though: Instead, you configure the FPGA schematic directly.
"Mental Health" is sometimes misrepresented by being used to refer solely to when there's a problem, but there are good MH issues, as well. It's just like physical health, and the two are linked.
Just before I started this, which was originally part of some routine CV revision, I was suffering badly from the effects of recent traumatic experiences, which had produced a partially Depressive state among other stuff. This project has given me a new lease of life. It's possible it worked the other way around instead, ie that the natural "bouncing back" enabled getting back to starting projects like this.
Although I started this using paper and pen, and typing things into my mobile [phone], at some point I had to start using desktop machines, and I moved one previously set up as an mobile experiment, back onto a desk as a fast machine, while I started spending a lot more time using my (rather more primitive) Linux desktop, which I originally only got to talk to printers. I was forced to switch to Linux as an online system, when my (also rather primitive) Windows 7 machine reached its end of service life. I will, when finances permit, upgrade to something decent. For the time being however, I have to use something.
The original design started in bursts, sometime in July 2022, but as I wasn't fully back to health at the time, it was a burst of a few days, then a two-week lapse; and repeat. It wasn't until late August, that things kicked up a notch.
This turned into intensive creating and the compromise/definition process, followed by intensive tests and debugging: This is common to all design cycles.
The intensity of it changed me, and also reminded me that I hadn't sat at a desk for long periods of time, for quite some while: I experienced temporary backache when I got up (which I straightened out with a recliner, resolved in just four hours), as well as increased stamina. I hadn't been getting as much physical exercise as I thought ideal, but at least this alternate mixed exercise was making up for it. It didn't help that my desk chair is a bit wobbly (I used to have a much better one, but it was too bulky to transfer it from my last office). When I stood up after up to 17 hours of straight desk work, I found I was hobbling about; very strange.
Optimisation notes, still is draft (sorry). It's a placeholder, innit?
Realised why commercial FPGAs don't use flash plugboard memory: Flash memory has a limited number of write cycles, and while a memory management unit can swap things around in a flash drive, things can't be swapped in a plugboard.
This leads to the possibility of having two versions of FPGAs: A normal version for development and slower-speed use, and a fast version for final/fixed use. For that matter, the final version could use old-style PROM memory, plus a master link that, when blown, means the device can no longer be programmed/altered.
These approaches could be united when a more durable form of memory comes along, ie faster and more repeatable than flash. Currently, memory usage splits into two types: The working store, and the backing store, or filing system. One volatile & fast; the other non-volatile & slower. Universal memory could mean simpler design in eg mobile phones.
WAI stands for Web Accessibility Initiative, a standard usually thought of as providing for access for people with disabilities, but it's wider than just that: It seeks to provide an equivalent experience for mobile, XR, and future platforms, as well as printed/broadcast media, and any other data access experience.
I noticed that some HTML BUTTON elements were not responding at all on mobile, even though they passed validation/lint tests. So I wrote some more-specific test pages.
Desktop browsers respond to a wide variety of events, including onmousedown and onmouseup, which I use on desktop to highlight elements while buttons are held down: It's quicker that way. But on mobile, only one event (for buttons anyway) is observed: onclick. I wasn't listening for that, consequently the buttons indicated they were operating fine visually, yet nothing was triggered.
To test things on desktop with only onclick, it has to trigger a toggling mechanism. -I actually already use that with SVG buttons, as they're very much a "bake your own button" phenomena.
And so, I'll have to add toggling buttons, to all the places where press-and-hold buttons currently are.
Why did I prefer hold-able buttons on desktop: It's easy to do that with a mouse (not so much, on a touchscreen!), and it's faster to test & move on, than to stop & toggle. That kind of rapid testing speed, isn't needed with a demo, so no worries about losing functionality there; and I can still use speed desktop-only speed, in later tests, if necessary.
It's just as well I cracked the non-operational BUTTONs on the mobile issue:
From a job advert I scrolled through recently:
Why yes: Here, look at these pages... which don't work very well [yet].
Look, the tests are under test, alright?!
All the cool stuff which worked perfectly on desktop, used those non-mobile-compliant BUTTONs! #Arrgh
This is a graphical, and practical one: I design visual elements using a grid-lock system, so lines and terminals need to centre on them. While this doesn't force everything into a rigid square appearance, it does impose some helpful easy-alignment constraints.
But my initial designs often didn't turn out to be compact enough, which led to redesigns, which flowed both backwards and forwards through other subprojects: So this is another design loop.
While I'm vaguely aware of the new-ish term of "refactoring", for rewriting code to a completely different standard (hard to describe really), and dubious claims of automating the process, I didn't expect to encounter it in SVG.
I design my circuits with paper and pen, then drawing using !Draw on RISC OS, which is a really fast way of generating professional original work, particularly as I now have a library of (self-made) components to use.
... Which is all very well, except the vector design application produces a file primarily intended for display, so its internal structure doesn't necessarily reflect how I drew it. And even if it did to begin with, it certainly doesn't after I've run it through various converters: First I print the design to a PDF file, transfer it across to Linux, load it into Inkscape using Poppler, which mangles the text but produces more-direct other code, and then collapse the document boundaries to the area of the document: This automates the dark art of fiddling around with the SVG viewbox attribute, so the display area matches the drawing. Then it's a journey through vecta.io's nano SVG compressor, to take out all the junk attributes Inkscape adds into the file, when it saves. Then I have to add linebreaks back in, in a text editor, so it's easier to work with manually.
Although it's a good start, and the resultant SVG will display very well inside a web page, the file structure is not good enough to manipulate live elements from javascript. It turns out to be in a random order, with parts which are completely unnecessary. Cleaning it up, often leads to a drastic reduction in filesize!
Even when cleaned, with all the major parts identified, it's often not precise enough, which requires further refactoring, in the guise of manually shifting component parts across the canvas, partially using Chrome's object inspector. I tried using Inkscape, but it just messes up the file again. This (eventually) results in an SVG where all the elements are identified, with ones that will need to be highlighted as a group, grouped together: This simplifies coding.