Expansive expansions

[SpacedCowboy]

Those times for the TT are significantly better than before ...

I fixed the issues you found and re-checked everything in.

• TA_* are now the definitions used for Text Align. I downloaded Otto's cross-compiler so I can look at header files
• I now include <sys/types.h>. I assume that's one of those cross-platform things because it's not necessary on the Mac.
• Thanks for the pointer to v_clrwk() - I think that's one of the very first functions I wrote, and I'm kind of surprised it lasted this long as incorrect...
• vq_exit_cur() should of course be v_exit_cur(). Now fixed.

[SpacedCowboy]

So, to follow up on the above post regarding the HD LED on my TT -Digikey delivered the components, and soldering up a little lead to plug the LED into the drive seems to have worked. The LED I have isn't quite as bright as the other two, but it'll do - I can see when the disk is accessed now.

This is all temporary anyway - assuming Matthias gets back to me with the Thunder/Storm/Lightning quote, because the HD is soon to be history in that case. It's a fine, if old, hard drive, but the noise - clearly I've been spoilt by newer machines, but the spin-up for the HD, and the grating whine are ... irritating

Thunder and Storm ought to fix that, and in preparation for a quieter TT, while the box was open I also took the opportunity to replace the PSU fan with a Noctua NF-A6x25 - exactly the same size (fans haven't changed much in dimension over the last 30 years or so) but so much quieter

As far as the coding goes, I'm most of the way through the shel_xxx library, just shel_read and shel_write to go, and at that point I'll get the startup code to execute a 'Desktop' application, which means parsing configuration from newdesk.inf so the launched file can be configured. Once that is in place (even if only a very minimal desktop app) I can start getting either the objc_ library or the wind_ library up and running. Probably the wind_ library...

I've been thinking about how to package apps up, and I was never very happy with just PRG files randomly scattered around. I'm planning on stealing an idea from the Mac (which stole it from the Archimedes, IIRC) of making a folder into an application, and having the actual binary inside the folder, but double-clicking the folder will launch the app. That means I can put config files into the folder, set the current-working-dir to the folder etc. etc. Makes things a lot neater.

So, folders with a .app extension will be considered applications, if they also contain a file with the same name but having the extension .prg. Or maybe I'll actually go with an Info.plist approach and make it *really* configurable. I think that might be slightly overkill though.

[SpacedCowboy]

Incremental progress

I got the shel_read() and shel_write() code working (shel_write is just doing application-launching, not any of the added-later stuff yet). The "AES" (such as it is) now looks for a desktop application to launch (via shel_write) which itself connects to the display server and is annotated as being the desktop. The actual program that runs here is configurable but the codebase has a (very!) basic stand-in for the time being. Since I'm missing event processing, it currently launches, does its stuff, and disconnects, but that will eventually change...

The model will be a bit different for this desktop, because there aren't really "drives" per se - instead I plan to make each directory under {sys root}/Disk into a "disk". The user can have as many as (s)he likes, but we install an "Applications" folder there (in which goes the 'desktop.app' folder-cum-application <- see above) but others can be installed there also just by coping the files over. Another thing might be a symlink to the user's home directory as 'Home' for example.

Given that we know which application has been chosen by the user as the "desktop", when that application asks to create its first window, we can create a full-screen sized window with no borders. It's still a window in the window-list, but (uniquely) the work-area is the entire display. Subsequent windows will get suitable chrome.

Here's where things start to get a bit fun I intend to make the screen manager code be theme-able for the various widget types (including window decorations), and since I have this handy-dandy per-application folder, the preference can go inside that application's folder. So when you launch Nethack, the theme might be based on something like this and when you run the scientific calculator app (at the same time) it might display something like this.

So, before the fun bit starts, I do need to parse/write the newdesk.inf file (which I can get/save via shel_get/shel_put) - although I suspect I'll be extending that quite a bit with the various options I intend to support. So that's next on the list.

I also have to figure out how I'm going to to redraws - given the memory size of the target hardware (a Pi 5) is at least 4GB, and a 1920x1080x32-bit screen is 8MB, I do have a lot of latitude for using memory-backing to optimise the screen redraw (and minimise the number of times I have to send a large data-dump over the socket). It comes with extra complexity though, and some apps might want to re-render rather than just re-draw if you pull the window wider (do a zoom-up, or re-layout text in a wider column, or...). I think it was Knuth who came up with the rules for optimisation...

1. Don't.
2. (for experts only) Don't, yet

So, I'm probably going to go with the "app has to redraw" and maybe tackle the optimisation later if it ends up being needed.

Anyway, progress is happening, if slowly. The newdesk.inf parser/writer is up next, then themes, then I can start actually creating windows...

[Steve]

@SpacedCowboy have you considered putting in a BlueSCSI (Pico) V2 in your TT? Even if to supplement your Thunder/Storm combo. I recently put one in my TT because they added Daynaport scsi emulation over Pico WiFi, which is fully hardware compliant. Ie; Daynaport was an old scsi to ethernet adaptor. The BlueSCSI pretends to be one on the scsi bus, thus allowing WiFi transmission through the Pi Pico to the Atari. On top of that it obviously also allows you to add multiple SCSI hard disks simply by putting an empty image file on the SD card and naming it 'HD5 mydrive.hdf' which puts it on scsi ID 5 etc etc.

[SpacedCowboy]

@SpacedCowboy have you considered putting in a BlueSCSI (Pico) V2 in your TT? Even if to supplement your Thunder/Storm combo. I recently put one in my TT because they added Daynaport scsi emulation over Pico WiFi, which is fully hardware compliant. Ie; Daynaport was an old scsi to ethernet adaptor. The BlueSCSI pretends to be one on the scsi bus, thus allowing WiFi transmission through the Pi Pico to the Atari. On top of that it obviously also allows you to add multiple SCSI hard disks simply by putting an empty image file on the SD card and naming it 'HD5 mydrive.hdf' which puts it on scsi ID 5 etc etc.

I think the BlueSCSI is kind of neat (and about a decade ago, I was considering something similar myself, though with an FPGA not an MCU) but I don't think I actually need it. Matthias got back to me re: the Thunder/Storm/Lightning boards, and hopefully we can make some progress this weekend Once the Thunder is in there, the IDE<->CF card interface is going to be really fast, especially into the TT RAM. Using the SCSI interface for networking is interesting, but I'm planning to go with the USB<->network route, so again, I don't think I actually need it.

On a slight tangent, I had considered using the ACSI port as the gateway for the GPU idea - with the goal being to allow any ST to have a high-res screen. The problem is that it seems to be orientated around sector i/o (quite reasonably, given its design target) rather than small quantities of bytes. For graphics, I want low-latency and small-packets (typically), and although ACSI gives me a nice DMA interface, I don't really want to be sending 256/512 bytes for each transfer when they're typically only 16-20 bytes (apart from when downloading images). I was disappointed in the parallel port as well - yes you can technically make it bidirectional, but it's going to be pretty slow, with TOS screwing around with the MFP chip every VBLANK it gets...

So the (nominally read-only) cartridge port is where I ended up

[Steve]

@SpacedCowboy well coming from someone who has a thunder/storm/lighting in their TT, and has played with USB solutions, I find the Daynaport WiFi solution to be a very good use of the (otherwise unused) SCSI bus. In fact, it requires less drivers and is simpler to set up. I think USB polling uses some CPU cycles, where as the DMA ability of SCSI is more efficient. I'm just saying you can have the very best of both worlds if you want, especially since BlueSCSI is very cheap

[SpacedCowboy]

@Steve Maybe my mind will change once I've got it all installed

As you say, BlueSCSI is pretty inexpensive, and I'm generally in favour of less drivers - always less to go wrong

[SpacedCowboy]

So, more of a progress update than anything else, but in recent days the framework has come on a bit, which means that the code now:

• Searches for (with shel_find), and spawns off a 'desktop.app' program to bootstrap the whole thing up
• Parses 'newdesk.inf' into an easily-accessible binary form (and allowing for saving of said binary form back to ascii format). The ascii form is available via shel_get/shel_put
• Runs the very bare basics of a window library, no decorations yet, just enough to show the root window (which doesn't need them). No menu-bar support as yet.
• Parses the rectangle list from overlapping windows so that overlapped-window redraws can be functional at some point
• Implements the very basic beginnings of the asynchronous event loop (in this case, just WM_REDRAW in response to a wind_create/wind_open of the root window but it ought to work for any window).
• Masks off icons so they can be displayed nicely.

That means that desktop.app can provide the most boring screenshot of a desktop in the world, and I couldn't be happier The icons are in a standard RSC file, and are located with shel_find(), newdesk.inf specifies which icon to use for which entity. I guess one thing it has going for it is 32-bit colour at 1080p

Desktop.png (51.79 KiB) Viewed 194 times

The nice thing is that there's absolutely nothing special (other than being the first app to launch, so it gets to control the root window) about desktop.app, any application can launch via shel_write() and have its own VDI workstation to draw on

Next up is probably a lot of debugging of the split-the-window-into-non-overlapping-rectangles code...

[Badwolf]

That means that desktop.app can provide the most boring screenshot of a desktop in the world, and I couldn't be happier

Looking good!

BW