The text mode is generated per Scanline using an ARM core, Tile, image, and sprite layers are all DMA+PIO generated.
So a Tile Layer is
TileMapDMA->TileIndexPIO->TileDataDMA->UnpackPixelIndex_PIO->PaletteReadDMA-> [ Transparency ]
ScanlineBufferReadDMA -> [ PIO ] ->ScanlineBufferWriteDMA
To do the entire tile map with paletted tileset happens in a single chained DMA operation, the other layers are a little simpler. It could generate the entire display without using the CPU, but the memory for the display Descriptors would take up too much memory, so there is a simple interrupt at the start of each scanline that updates the pointers in the DMA descriptors for the source and destination addresses that change per scanline.
I did have a text mode running without CPU as well but it was cumbersome due to the attribute color lookup adding another map lookup. Now it is spending just a little CPU time per scanline to do the ReadChar, Read Attribute, read Font to convert it into a 1 bit-per-pixel image with a color per byte.
Performance is better that way, even if it does make a little more work for the CPU, the scanline renders quicker. Since they all render into the single scanline buffer, you can do as many layers as you have time for, so using no CPU is no good if it still takes too long.
People often talk about how fast old software is, but one of the things that stands out about GeoWorks for me is how small it was while doing a lot.
Of course, lots of things that make modern software bigger are things we very much don't want to do without--full Unicode support, accessibility, clever rendering, improvements to quality of life. But our 'foundations' are also built higher; the Web platform and a bunch of native toolkits provide a lot out of the box. (The platform doesn't include all the widgets that are now quasi-standard, of course, so we build a lot on top anyway.)
There are also a ton of useful third-party libraries you can call on without getting too bloated, and there's a lot that would have been bloated then but not now: in the 90s you probably wouldn't embed an SQL DB you didn't really need, but SQLite is a pretty safe dependency now.
Nothing in particular I'm really driving towards here but I think "how do I keep the code to functionality ratio good" can still be an interesting angle from which to look at high-level design decisions even as a lot of the circumstances and numbers have changed over decades.
These days it's have LLMs rewrite it in rust. </s>
Software these days compared to back then is bloated. There were memory constraints and processor constraints. If RamAltman had his way, we would likely return to needing to do that.
GEOS and the like was a bit before my time, I mostly know about geoworks because back in the 2003 while in high school, I played a lot of "Wyvern" (https://web.archive.org/web/20030212212420/http://www.caboch...), an online 2d rpg game primarily made by Steve Yegge. There seemed to be significant contributions from other GeoWorks related people early on and I had noticed the name come up from time to time.
Here's some GEOS/GeoWorks related internet archaeology you may find interesting
Tried a version in the 1990s on a lark. I recall it had theming similar to Windows 3. Yet it lacked the programs I was used to for making stuff, so I went back to Windows.
If memory serves it did perform quite well for an OS shell.
I tried to read this with genuine interest but was stopped by ads that reloaded the page 4 times and gave up. I don’t like hijacking comment threads with whining about ads, but holy shit guys, get it together
16 comments
[ 2.3 ms ] story [ 13.1 ms ] threadhttps://github.com/bluewaysw/pcgeos
(which I'd love to see get ported to the Raspberry Pi)
I think it would be remarkably feasible. The size and memory model is almost ideally suited.
A rp2350 with PSRAM and a SD card as a harddrive could do a quite capabLe implementation.
It's more of an architecture port than a code port because it is almost all ASM.
This is my scanline at a time renderer.
https://fingswotidun.com/cruft/2350LCD_5.mp4
The text mode is generated per Scanline using an ARM core, Tile, image, and sprite layers are all DMA+PIO generated.
So a Tile Layer is
To do the entire tile map with paletted tileset happens in a single chained DMA operation, the other layers are a little simpler. It could generate the entire display without using the CPU, but the memory for the display Descriptors would take up too much memory, so there is a simple interrupt at the start of each scanline that updates the pointers in the DMA descriptors for the source and destination addresses that change per scanline.I did have a text mode running without CPU as well but it was cumbersome due to the attribute color lookup adding another map lookup. Now it is spending just a little CPU time per scanline to do the ReadChar, Read Attribute, read Font to convert it into a 1 bit-per-pixel image with a color per byte.
Performance is better that way, even if it does make a little more work for the CPU, the scanline renders quicker. Since they all render into the single scanline buffer, you can do as many layers as you have time for, so using no CPU is no good if it still takes too long.
Some previous and related discussion:
2017 https://news.ycombinator.com/item?id=14748209
GeoWorks: The Other Windows (2019)
2024 https://news.ycombinator.com/item?id=41373650
2021 https://news.ycombinator.com/item?id=29402609
Of course, lots of things that make modern software bigger are things we very much don't want to do without--full Unicode support, accessibility, clever rendering, improvements to quality of life. But our 'foundations' are also built higher; the Web platform and a bunch of native toolkits provide a lot out of the box. (The platform doesn't include all the widgets that are now quasi-standard, of course, so we build a lot on top anyway.)
There are also a ton of useful third-party libraries you can call on without getting too bloated, and there's a lot that would have been bloated then but not now: in the 90s you probably wouldn't embed an SQL DB you didn't really need, but SQLite is a pretty safe dependency now.
Nothing in particular I'm really driving towards here but I think "how do I keep the code to functionality ratio good" can still be an interesting angle from which to look at high-level design decisions even as a lot of the circumstances and numbers have changed over decades.
https://www.folklore.org/Negative_2000_Lines_Of_Code.html
Software these days compared to back then is bloated. There were memory constraints and processor constraints. If RamAltman had his way, we would likely return to needing to do that.
Here's some GEOS/GeoWorks related internet archaeology you may find interesting
Steve briefly mentioning that he worked for GeoWorks, and why it ultimately couldn't keep up with changes. https://steve-yegge.blogspot.com/2008/05/dynamic-languages-s...
The GEOS Software Library: https://web.archive.org/web/20030210052015/http://tvakatter.... ("Två Katter" = swedish for two cats, a play on tucows.com)
Video of the launch party for GeoWorks Ensemble 2.0 with CEO Brian Dougherty: https://www.youtube.com/watch?v=wOImkzTyJ7s "Geoworks - Brian's Got A Brand New Bag"
Until that point I had only run software via command line. Our first Windows machine was a few years away (386 with win 3.11).
If memory serves it did perform quite well for an OS shell.