<![CDATA[My journey to using and programming computers started around 1983 with a Sinclair ZX Spectrum 48K, the very first I owned. At the time I was clueless. For example, I wondered whether, once I loaded a program from tape, I needed to write it back at the end of the session so that it didn't vanish when turning off the machine. The Sinclair ZX Spectrum Introduction and the Sinclair ZX Spectrum BASIC programming guides that came with the device were my first learning resources, complemented by the great Italian computer magazine MC-microcomputer. Aside from some books, in that pre-online era technical documentation wasn't easy to come by in Italy, especially foreign works in English. I pored over the Spectrum manuals, reread them many times, and experimented with the sample code. I've never been into gaming but did run many games to see what the machine could do. I've come a long way since then, hopefully. #retrocomputing #personal a href="https://remark.as/p/journal.paoloamoroso.com/the-origins-of-my-computing-journey"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>

<![CDATA[GravityLoops, my gravity simulator in Interlisp and LOOPS, can finally show something on the screen. The program now animates a body of mass like the Moon interacting under gravity with a body of mass like the Earth. The dots in the simulation window here are the bodies after 180 days of simulated time, with the Earth at left. Watch the full run. Screenshot of a still frame of a simulation of a body like the Earth and one like the Moon interacting under the muatal gravity. Well, that's not much. But the code confirms the simulation loop with an offscreen buffer works well. After putting in place some infrastructure, to get there I wrote the simulation loop, tweaked a few methods, wrote a demo function that sets up the simulation, and fixed a few bugs. There's a lot more to do. I need to make the graphics of the body markers more complete and explanatory, control the speed of the animation, fix more bugs, and refactor to decouple some interclass dependencies. And, of course, GravityLoops will also have a user interface to control the simulation and enter the parameters. #GravityLoops #Interlisp #Lisp a href="https://remark.as/p/journal.paoloamoroso.com/early-simulations-with-gravityloops"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>

<![CDATA[I started working on the class Universe of GravityLoops, my gravity simulator in Interlisp and LOOPS. I defined the class itself and the main methods, Universe.Register and Universe.Simulate. The class represents a collection of bodies and manages the parameters and state of the simulation. Universe.Register adds a body to a universe, Universe.Simulate runs the simulation. In the C++ code of the article my design draws inspiration from, an instance variable of the class UNIVERSE holds a pool of bodies in an array, with the most recently added body indexed by another instance variable. In GravityLoops the corresponding instance variable bodyPool is a list which, as the article notes, is more versatile and doesn't need the index. Universe.Simulate, just a stub for now, is the core method. It will update the state of the simulation, display the bodies in a graphical window along with status information, and check whether the user interrupts the simulation. The C++ program runs the simulation until the user presses a specific key and GravityLoops will have a similar feature. I'll also have the program accept a number of time ticks to step the simulation through. For Universe.Simulate I'll mostly follow the C++ code. But I plan to revisit the decision after I have something running to experiment with. I may want to split the simulation functionality into more than one method to separate the simulation itself from output, or redesign control around LOOPS' active values. #GravityLoops #Interlisp #Lisp a href="https://remark.as/p/journal.paoloamoroso.com/representing-the-universe-of-gravityloops"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>

<![CDATA[Insphex adds the Hexdump item to the File Browser menu to view the hex dump of the selected files. The initial implementation called the public API for adding commands at the top level of the menu. To later move the item to the See sumbenu that groups various file viewing commands I resorted to list surgery, as the API doesn't support submenus. The problem is internal system details can and do change, which happened to the File Browser menu and led to an Insphex load error. I fixed the issue by reverting the public API call and now the item is back at the top level of the menu. Insphex is a hex dump tool similar to the Linux command hexdump. I wrote it in Common Lisp on Medley Interlisp. #insphex #CommonLisp #Interlisp #Lisp a href="https://remark.as/p/journal.paoloamoroso.com/rearranging-the-file-browser-menu-for-insphex"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>