DA2023 : Charles Childers' ===================================== _ _ __| | ___ ___ ___ _ __ ___ | |__ ___ _ __ / _` |/ _ \/ __/ _ \ '_ ` _ \| '_ \ / _ \ '__| | (_| | __/ (_| __/ | | | | | |_) | __/ | \__,_|\___|\___\___|_| |_| |_|_.__/ \___|_| _ _ __ _ __| |_ _____ _ __ | |_ _ _ _ __ ___ / _` |/ _` \ \ / / _ \ '_ \| __| | | | '__/ _ \ | (_| | (_| |\ V / __/ | | | |_| |_| | | | __/ \__,_|\__,_| \_/ \___|_| |_|\__|\__,_|_| \___| The December Adventure is low key. The goal is to write a little bit of code every day in December. DA2023 Day 1 =================================================== I decided to start my December Adventure by working on the x86 native ilo system. For the first day I added port i/o and physical memory access to the ilo vm, and then wrote words in Konilo to interact with them Using these, I then wrote simple drivers to access the CMOS RTC and serial ports. I've done some test words to access the BPB, these worked as expected. Tomorrow I'll start adding the mult/ilo functionality so I can use F1-F5 to switch between several Konilo sessions. (While I've only had this for a short time under Unix, I've found it to be very useful). Summary: 9 lines of C 4 blocks in Konilo (29 words) DA2023 Day 2 =================================================== I recently wrote "mult/ilo", a modified ilo computer that can be switched between several open sessions of Konilo. This has been very useful, so I wanted to do the same on the native ilo system. For the second day of December Adventure, I decided to work on this. Last night I spent some time considering whether this should be the only native ilo kernel, or if it should be a sep- arate one. I ended up deciding to keep them separate. The base ilo is a very simple thing and it didn't make sense to make it any more complex than necessary. (It's not drastically longer; the C ends up being 507 lines contrasting with the 469 of the original ilo/native). I've decided to limit the number of concurrent sessions to 5. For me, this seems sufficient. If more are needed, the source can be edited to add additional ones. For the interface to switch between these: F1 - F5 jumps to a specific session. F11 switches to the previous one, F12 to the next. (F11/F12 are circular). F9 restarts the current one. Switching can only be done while the system is waiting for input at the keyboard. Summary: 39 lines of C (-109/+144) At this point I have a functional (though still very minimal) standalone system that I can actually use. I think my next step will be to write a few more drivers, and work on recognizing partitions. I also think I should setup a bootable ISO and USB image since floppies are not common anymore. DA2023 Day 3 =================================================== In the native ilo system, I use the entire hard disk for my block storage. This works, but in the future I may decide to try to coexist with other operating systems. For this, I need to be able to find each systems partition(s) and limit ilo's use to a dedicated one. In today's December Adventure, I'll work on the first part of this. On x86 there are two partition schemes I'm aware of: MBR and GPT I'm going to focus on MBR. It's simpler, and , though limited to 2TB disks, this seems more than adaquate to me. In looking at the MBR, the biggest annoyance I have is that it is not aligned on 32-bit boundaries. ilo is a word-addressed system, but thankfully the Konilo Forth does provide byte level addressing words. I read the MBR into a dedicated buffer and then have written words to access various fields in it. A secondary annoyance is that the CHS fields are spread across three bytes, but aren't just words, so a bunch of bit manip. would need to be done to access these. I decided instead to just rely on the LBA and sector count fields. I've written the necessary words to get at these fields, but haven't written anything that actually uses them yet. I will be doing so later in December, after I can construct a few test disk images. (The words seem to work as expected on the one image with an MBR partition table that I currently have, but I'd like to test on a wider range of data). Overall I'd say it was a productive learning experience. I've not worked with actually readingt the MBR since 2005 or so, and I had forgotten many of the details. There's enough little issues with getting blocks constrained to a partition that I probably won't do so unless I actually find an actual need for it. DA2023 Day 4 =================================================== Today I am focusing on small improvements to konilo. In tuhi, I added a key binding for `sys:status` so I can more easily check the current block number and memory usage. In mult/ilo, on Unix, I added CTRL+a for shutting down, whch is more comfortable for me to hit than CTRL+\. Revisiting an old idea, I brushed off the code I had previously played with for extending functionality via an external process. The daemon now uses kevent() to monitor the blocks for changes. I can pass the block to use for communications on the command line. I then added code to write the current time & date to the block. I also added in a random number reader, from /dev/urandom, which can be used for programs that need a greater amount of random than the standard words provide. It should be possible to use this as a means of accessing files on the host. I might explore doing this later this month. Stats: waea.c 143 lines of C waea 7 forth words tuhi 1 forth word milo.c 1 line of C Other things today: I moved a couple of words out of the (nonix) blocks and into (opt:nonix) since I don't use them often enough to keep in the main set. I fixed an incorrect entry in the Konilo glossary and rebuilt the dictionary files. I'll have to update the PDF for the print copy later, perhaps tonight. DA2023 Day 5 =================================================== Back to work on mult/ilo today. ilo (and mult/ilo) are intended to be used on a terminal in a mode where keys are returned immediately after input. Up to this point, I've manually set this using `stty`, but this is not ideal. I checked the man pages for termios, then wrote a few lines of C to switch modes on startup and restore on exit. There is still a little weirdness with backspace handling. I will look into this further. I added more #define statements to make the source a little closer to the standard ilo.c source. Stats for the above: vm/milo.c +15 lines native/milo.c +11 lines I began work on adding support for graphics to the x86 native ilo. It will likely be a while before this is actually working. (my efforts have been delayed a bit due to GRUB legacy not impl- ementing the graphics part of multiboot1; I'll setup a GRUB 2 boot system soon). In an attempt to work around the above, I spent a little time trying to get it operational by manually adjusting the VGA regi- sters. This has not yet been successful. I will work more on the graphics support in native x86 ilo. It would be nice to have it operational soon. Tomorrow will probably be a continutation of research and exper- iments into getting graphics working. I'll probably also start setting up scripts to mount/update an ISO or IMG with GRUB2 in hopes that it'll work a little better with this than the legacy GRUB1 that I've been using. (I think that stuff like Ventoy can work with these, so it might also become possible to boot a little more easily on recent systems.) DA2023 Day 6 =================================================== After several hours of reading, I finally found the register information I needed, so I now have some graphics capability. I've been able to initialize 320x200x256 and (partially) a 640x400x16 mode. For now I'll use the lower resolution mode. Since this is quite low res, I need to use a very small font if I want to be able to display a full block or any of the terminal programs. I'm going to use miniwi (an 8x4 font) for this. After a bit more testing, I was able to tie in Arland's terminal (DEC subset) code, giving a fully functional text mode over the graphical display. The next step will be to get pixel drawing (and reading) words in place. At that point it should work with the drawing words from ilo/x11. I'm happy this is working. It's better than needing to rely on a black box (BIOS or GRUB) to do things. A future project: merge the graphics functionality into mult/ilo system. This would have a separate display for each session. Some notes on the 640x400x256 mode attempt: the display does switch to the new mode, but it appears to still be using planes. I'd like to use this mode as it'd allow a much larger font but still keep to 256k of video memory. Hopefully it'll just be a matter of determining the correct register values. Afternoon update: I added the pixel functions, so I can now draw using the (ilo/x) words. With this functioning, I've updated https://konilo.org/x86/ to include the latest copy. (It's better to emulate locally, with qemu or bochs, but this can serve as an easy demo copy). I think I'm going to stop for today. I might do formatting fixes tonight, but my wrists & hands are getting a touch painful, so it's probably best to take a break from typing for now. DA2023 Day 7 =================================================== I took a small diversion from working on the native x86 ilo to fix a little issue with the REM block editor. A while ago I had renamed some words in the terminal code, but neglected to update REM. This has been corrected. Next was a return to the ilo/native code with graphics. When I stopped yesterday, it was working, but the code was very messy. I removed unused pieces that were left over from previous tests, grouped related functions, and fixed formatting issues. It's much nicer now. I did a similar update to ilo.c & milo.c. On to the next thing. Interrupts. This is a long overdue addition. Adding interrupts gives me a chance to deal with errors in a better manner, and to start on more advanced drivers. I've successfully set up an IDT and enabled interrupts on the base ilo/native kernel. I think that I'll get it cleaned up & added to the others tomorrow. I might also write a vocabulary to allow running words on interrupts. (That might not work well on mult/ilo though). DA2023 Day 8 =================================================== I started with a continuation of yesterday: cleaning up and mer- ging in the interrupt support for mult/ilo and ilo+graphics. As expected, this went smoothly. Next I prepared a mult/ilo kernel with the graphics support. It encountered no issues other than needing a .bochsrc with more RAM. And I'm stopping with this for today. Not as much typing as the last few, but my hands are hurting, so I need to slow down for a few days. DA2023 Day 9 =================================================== With the major pieces of the native x86 ilo now in place, I am switching my focus to work on RetroForth for a while. The Retro code is older, and it has a number of issues I'd like to fix. Since I'm still experiencing pain in my hands, I'll be moving slowly for now. Today I added constants for the i/o device identifiers, updated the C to use them, and started updating the Forth parts that use them. I did not finish the Forth part yet. Tomorrow I'll finish the Forth part of this update, then begin a little update to how i/o devices are detected. (Right now all of them have slightly different, very repetative methods.) DA2023 Day 10 ================================================= Taking a small diversion from programming on my projects, I built porporo. A little adjustment was needed on the Makefile. http://forth.works/share/porporo-20231209-openbsd.diff I'm not really sure how to use it. I'll probably play with it more over the next week, but I feel I'll have better luck with a mouse rather than only using a keyboard. ---- Back to RetroForth: I finished updating the Forth side of the device code to use the named constants. I also updated some of the C part of the i/o code, doing more refactoring, and generally trying to clean things up further. ---- Some time was invested on reading about PS/2 mice. While I do not like mice, they are useful for some things, and Arland will need this for his arks project. It looks pretty straightforward but I will need to figure out how to convert the relative motion values returned to screen positioning. ---- Stopping again. My hands are hurting less, so I'm hopeful this bout will pass soon. DA2023 Day 11 ================================================== For RetroForth, I'd like to have a way to load extensions more easily. It's time to add support for a user controlled library of extensions. Writing this was straightforward. The code generates filenames, verifies that they exist, and loads them. Or displays an error if the file is not found. I have this searching two paths: ~/.config/retroforth/library ./library A case can be made for adding a system-wide library path, but I am not going to do so at this point. In the library directories, a filename.retro file should be added. Then it can be loaded with: 'filename library:load With this done, I added the x11 words as a library, along with the basic block editor from Konilo and then ported the (termina) words so I can start bringing other programs over. I also added a new example, displaying a word listing, using color to indicate the word classes. I think this will be all for today. It's still early, but I want to stop before my hands get too painful. DA2023 Day 12 ================================================== In RetroForth, I made a small change to the handling of invalid instruction bundles. Then I worked on a few ilo things: For the assembly version, I added a .openbsd.syscalls section. This will be needed for the next release of OpenBSD. I wrote mult/ilo/x, which brings the x11 support to mult/ilo. That concludes today's projects. DA2023 Day 13 ================================================== Some days it's harder to get motivated. For me, today is one of those. But I need to do a little programming for the DecAdv, so choosing a task... I decided to continue the long, slow cleanup of the unix nga vm. This entailed moving the signal handling setup to a separate function, shifting some of the initialization code to an exist- ing function, and cleaning up part of the argument handling. Other than this, I've done a little work on documenting Konilo. DA2023 Day 14 ================================================== In Konilo I began writing a little thing to create and track an index of the title lines for the blocks. I already have several words to search for blocks, but they are all slow due to the overhead imposed by ilo. Blocks are stored in a single large file. For each block, ilo will open this file, seek to the correct location, read in the block, then close the file. An upside to this is that there is only a small window for data corruption to occur if ilo crashes. A downside is that it requires a lot of disk i/o to scan the entire block set. The idea in this tool is to maintain the relevant information in a smaller set of data that can be quickly read & scanned. Each block is 1,024 values (mainly text), and is generally presented as 16 lines, with 64 characters per line. I use the first line as a title. For this tool, I'm storing the hash of the title lines. (This will mean that I can only look for exact matches, but I can fall back to the slower methods if I need finer control). The data is stored in lines 2-16 of each index block, allowing for 960 hashes per block. Doing this requires 69 blocks for indexes. Each index block gets a title of "LocateDB (Data)". The work done this morning was to write the words to allocate all the index blocks. I also started on words to scan the blocks and begin filling in the index blocks. While working on this, I discovered a bug in `s:trim-right`. It was leaving a single space at the end of a string. I have fixed this in the repository & nightly builds of ilo.rom DA2023 Day 15 ================================================== The next several days will be quite busy for me, so I'll be writing less for a bit. I started today by reviewing RetroForth's code changes and then began preparations for building a new release. (Unless I find a major bug, it's probable that the next version will be ready in early January). For programming, I rewrote a few words in assembly and then made a couple of small changes to allow the full listener to be moved into the main image source. These reduce the image size by 258 cells. DA2023 Day 16 ================================================== With a planned Christmas gathering tomorrow, this is my only free day this week. But I'll still do a little programming. I dipped back into Konilo and added `code:` to allow slightly easier entry of words in assembly. I also fixed a small issue with the * loader code that was causing an incorrect block to load if the specified set was not found. I made small improvements to the definitions of `describe`, and a few internal words in the manual viewer and tuhi editor. A bug in `indexed-times` was also found & fixed. DA2023 Day 17 ===+============================================== v | >X< | Today is the day my family is celebrating A | Christmas, so I'm doing very little with d$b | programming today. .d\$$b. | .d$i$$\$$b. | I recently noticed that the export code for d\$$$ib | my wiki wasn't completing. This morning I .d$$$\$$$b | a closer look, found a memory leak, and .d$$@$$$$\$$ib. | fixed it. d$$i$$b | d\$$$$@$b | And that's it for today. .d$@$$\$$$$$@b. | ### | ### | ### mh | DA2023 Day 18 ===+============================================== I began today by doing more cleanup work in Konilo. The standard set of extra words and tools is great, but there are a variety of places where the definitions could be tightened a little. I made improvements to the stack display and stack reordering code before turning my attention to the catalogue. The catalogue code is now a bit smaller, using direct pointers where possible (instead of wrapping things in quotes). I took a few minutes to clean up the key binding code, so keys are listed in order now. The nonix blocks were reorganized, dropping from three blocks to just two. Introducing _ _ __ __ _ _ _| |__ ___ __ _ | '_ \ / _` | | | | '_ \ / _ \/ _` | | | | | (_| | |_| | | | | __/ (_| | |_| |_|\__,_|\__,_|_| |_|\___|\__,_| Moving on from the cleanup work, I began writing nauhea. This will be a set of tools & a vocabulary for writing small games. (These will be small, text-based things, perhaps something in the rougue-like family). The first part of this is an editor for the game maps. I've setup some data structures & begun the display code. The map editor is going to be a (termina) program. (For those curious on the naming, nauhea is from the Maori word for rogue or scoundrel). One more thing for today: I have been playing around with C# and now believe I know enough to write an ilo + graphics for Windows. DA2023 Day 19 ================================================== I continued to work on nauhea today. I have rewritten the code for the display, making it easier to colorize different items being displayed. I have the initial (termina) interface for it working, though it will need further refinement as it gets used. The next step for this is moving the cursor around. I've written part of this, but won't finish today. Hopefully tomorrow. Separate from this, on paper, I've started sketching off some initial notes for a small game to be written using this. DA2023 Day 20 ================================================== Continuing working on nauhea, I have tied in the cursor movement and added character selection, entry, load, and save. So this part is finished. With that done, I moved on to writing the data structure and a few words to detect solid objects. This is also working, so my next step will be to move a character around the map. I will try to have this complete tomorrow. The map editor code is pretty straightforward. I'll probably do a variation on it for an ASCII art editor in the near future. I've also begun writing some documentation on the completed bits though this will be an ongoing process as things evolve. DA2023 Day 21 ================================================== This morning I was able to finish the character movement and collision handling, so I can now move around my game map. I've started on some variables and words for dealing with varied player attributes. Either tonight or tomorrow morning I'll try to complete this, then I'll spend a little time organizing the code blocks and getting the documentation more complete. Nauhea currently uses 1,008 cells of memory and is seread across 16 blocks of source. DA2023 Day 22 ================================================== I spent my morning organizing & cleaning up the code for nauhea. It's dropped from 16 to 12 blocks, and the compiled size is now 977 cells (down from 1,008). Tomorrow I'll start on the next set of updates. These will cover some battle aspects, player & enemy attributes, and inventory tracking. After work I'll continue with writing documentation. DA2023 Day 23 ================================================== I worked on the entity management in nauhea. This is not yet complete. I've written words to create entities, allocate space, and access various attributes. I'm unsure of some of the word naming, and want to create nicer initialization process. Tonight I'll spend some time considering these. Inventory management is another aspect I began working on today. It's *very* incomplete at this point, and might take a couple of days to finish & refine. Tomorrow I will continue with these, and then start on the battle related code. DA2023 Day 24 ================================================== Arland suggested adding . accessors for the entity fields, so I added them this morning. I have also imported his (dice) words (extended to include defaults for common configurations) as the first part of the battle system. The first words in the overall battle system are completed. Not documented yet (I'm lagging behind on this), and definitely in need of some refinement, but it's good enough to let me do some testing. I'll try to have this improved to an actually usable state tomorrow. DA2023 Day 25 ================================================== Arland and I are working on the battle code. We are currently working out various parts of the underlying formulas for decid- ing the outcome of each turn in a battle. I'm hoping we can make enough headway on this to let me finish implementing it tomorrow or Wednesday. I did some more block cleanups & consolidations in the standard extensions for the basic Konilo system. The manual browser has been reduced in size (now two blocks instead of three), and some reorganization was done in the catalogue. One block was removed from the tuhi editor. There was one more change. Up to this point, Konilo has had a dictionary structure with a pointer to the previous entry, a pointer to the start of the word, a hash of the word name, and a flags field. The only flag used was to indicate immediate words. I've removed this and now just use a negative starting address to indicate that a word is immediate. This is a breaking change, but not drastically so. Konilo only has three immediate words ( [ ] and ; ), and only one block that needed updating due to using pointers to them directly. I think this was a worthwhile change as it reduces the overall memory usage of my basic system by over 600 cells. DA2023 Day 26 ================================================= Under Konilo, I optimized the code in another block. For RetroForth, I resumed work on the new listener. I'll not have this done for the 2024.1 release, but hope to have it ready for the mid-year release. Other than this, I am doing a little work on the iOS stuff. I hate this, as I really dislike Xcode. I spent several hours downloading the latest iOS SDK updates only to run out of disk space to install it. So I'll be delayed until tomorrow to get anything done with this. Ugh. DA2023 Day 27 ================================================== While I wait for some feedback from Arland regarding nauhea, I am continuing to work on the new Retro listener. Today I was able to fix several bugs and started on much needed cleanups to the source. I'm expecting it'll be ready to share as an early preview to my patrons later this week, and will be in the repository next week. In non-Forth programming, I picked up a bunch of pieces of a project a friend and I started about a year ago and have (with much time sunk in Xcode & Swift Playgrounds) assembled them into a functional proof-of-concept application. Not sure if this actually evolve into something actually useful, but time will tell. DA2023 Day 28 ================================================== I finished the initial cleanups to the new listener and spent some time noting down things I need to work on before this can be completed. Other than this, I did some server maintenance (closing down two more old VPS instances), updated some shell scripts for creating backups, and then took a break from the computer for a bit. DA2023 Day 29 ================================================== I worked on the terminal emulator for RetroForth's new listener. The core functionality is working, though I have reason to susp- ect a bug in the scrolling code. I'll look at this more closely tomorrow, then start on the escape sequence handling. And that's it for today. DA2023 Day 30 ================================================== I began work on handling the escape sequences, but did not get far. Instead I took time to rest and be offline and away from the computer. DA2023 Day 31 : The End ======================================== It's a bit sad to reach the end of something, but December, and therefore the December Adventure is at an end. I quite enjoyed this, much more so than prior years where I dabbled at Advent of Code and similar challenges. Keeping it low key was very good. And for a low key adventure, I accomplished more than expected. The native Konilo system grew into something I can actually use. A previous experiment in extending Konilo via an external proce- ss was revived and expanded. Some website work was finished. For RetroForth, many source cleanups were done, support for loading extensions from a library was added, and bugs were found and fi- xed. Several things were started but not completed: a block ind- exer, game scaffold (nauhea), and a new listener (+ terminal em- ulator) for RetroForth. I offer my thanks to Eli for prompting this, and his tracking of the various logs participants kept. I've enjoyed both writing code & following along with everyone's adventures. While this adventure may be ending, I'm looking forward to many new ones during the coming year, and hope to partake in a new December Adventure next year. ---- For the final day of December Adventure, 2023, I chose to write a program to convert my Konilo blocks into HTML, with syntax highlighting. This has been written in RetroForth. A demonstration of the output can be viewed at: http://forth.works/temp/x.html This contains the first 128 blocks. I'll continue on this in January, with plans to make the full set of default blocks online and browsable sometime before the end of the month. ---- And that's it for my December Adventure in 2023. Thanks for following along.