Friday, May 1, 2020

New display server on Raspberry Pi

My fellow HelenOS developer Maurizio Lobardi tested my new display server on a real Raspberry Pi and shared a video of his test. Thanks Maurizio!

Still work to do, btw! Rest assured I am working on it. I've just been quite busy + I stumbled upon a mystEEErious heisenbug. In the end it turns out it's all a case of misunderstanding and misusing async_hangup(). Back to work!

Thursday, March 5, 2020

GZX 2020.1 is finally here!

I finally released GZX 2020.1. Most of the work on the new functionality was done between May - September last year.

This release has many exciting new features, including completely rewritten tape emulation, ULAplus emulation, usable Spec256 emulation and more.

Monday, January 20, 2020

The window system saga continues

It takes many small steps to reach the goal. Some of the stages are shown here. We already display via KFB and at the end we can move windows and fill the display with a background color. Window overlap is not handled correctly yet.

Thursday, November 21, 2019

Working on the new HelenOS display server

GFXdemo, Display Server, Terminal, GZX. Bloopers! Drama! Special effects! Featuring 100 elephants!

Friday, August 9, 2019

CF2 Unpacking

Opening up a mysterious package.

Wednesday, April 17, 2019

State of GZX nextgen tape support

You may already know GZX, my humble venerable ZX Spectrum emulator. It runs on Linux/SDL, Windows, HelenOS and has a collection of interesting features (Spec256, MIDI, HiRes, AY file, I/O recording, child lock, ...) It is free software, under the terms of a BSD-style license.

I am trying to gradually modernize and improve the software. Currently I am in progress of revamping the tape support. Currently GZX tape is mostly read only. There is an abstraction layer that unifies TZX, TAP and WAV fiels (not all TZX block types are supported), above that we have a layer that either quick-loads data blocks into the Spectrum memory or synthesizes the tape audio to the virtual Spectrum's EAR. Separate from that, you can quick save blocks to a TAP file and that's it. This is very simple with very low use of memory (one version of GZX worked in 16-bit DOS, after all), but very limited. No way to browse the tape, modify it or convert files between different formats.

Now the goal is to move to a different model of in-core tape representation, where we load the file to memory, keep it in an editable format and then write it back to a file. The memory representation must represent all TZX features to allow for a perfect round trip. With this we can browse the tape, edit it and perform format conversions. After all RAM is somewhat cheaper today ^_^ and it is still possible to optimize the code to load stuff lazily from the file.

I have the basic scaffolding for the in-memory tape in place and now starting on TZX file loading. Once I can load and save a simple file, I can theoretically add a backend for the current tape support to read from this in-memory tape as a starting point for a switch over to the new system.

I will need to add complete support for loading/saving of all TZX blocks. This will be a challenge to test, so I guess I will probably need to fabricate some test files.

Progress on this has been painfully slow simply because I am working on other things most of the time (such as having Sycek compile C for ZX Spectrum, let's leave that for another day). With the basic tape and TZX work added in one commit in August last year and finally some progress on TZX loading yesterday. Hope I will be able to push this forward as tape support is one of the crucial big pieces.

Thursday, December 13, 2018

My 2018 in HelenOS and future plans

Here are my notable contributions to HelenOS in 2018:
  • Deceloped Ccheck, a C-style checker, and integrated it into HelenOS developer workflow
  • Volume mounting automation and fdisk improvements
  • Initial support for persistent system volume (/w)
  • Unification of character device interfaces
  • DDF-ization of legacy device drivers
  • Huge amount of work on bringing the C library into alignment with C standard
  • Replaced kernel AVL trees and B+trees with ordered dictionary in the kernel
  • Fixed ISA-only PC support (finally!)
  • Made XCW work with Coastline and added harbours for Sycek/Ccheck and GZX
  • Added perf command to collect benchmarks, new memory allocator benchmark
  • Very basic printing with standard PC parallel port driver and lprint command that can send files or messages to the parallel port
Some areas where I would like to (continue) working on in the next year(s):
  • File system management / Installation / Distribution / Packaging
    • VSN/UUID support
    • Need persistent system volume on wider range of platforms / configurations
    • Attack problems around persistence and different location of packages / relocatability of packages
    • Initrd minimization and support for booting natively from CD-ROM, HDD
  • Network configuration
    • We need a new model for network configuration that is more dynamic (think WiFi)
    • We need a model that will support persistent network configuration
  • PC platform support (old and new)
    • Look at issues when running on modern PC HW (interrupts, etc.)
    • WiFi, Ethernet drivers
    • Old PC support (CPU, devices...)
  • Look at user-space memory allocator performance
  • User interface (GUI / Console / Shell / Serial / Remote)
    • A large rework is needed in this are - big plans
    • This is a long-term project
  • End user usability
    • General focus on usability of the stock system without modifying sources or re-compiling
    • Practical use cases (e.g. web server)