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.
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
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
|
V
TileIndexPIO
|
V
TileDataDMA
|
V
UnpackPixelIndex_PIO
|
V
PaletteReadDMA
|
V
TransparencyPIO <-- ScanlineBufferReadDMA
|
V
ScanlineBufferWriteDMA (Yes this was as hard to debug as it looks)
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.
For some the "point" is just solving a problem, however that happens.
For others it's an art form that gives them a sense of worth, using their knowledge and experience to do something special that not just anyone can do.
Neither is right or wrong; people just have different goals.
I am not a great programmer, and I certainly do not have the attention span to complete a big personal project. But I can describe well to Claude the architecture I want, the look and feel of the UI and how it all should work.
I have things running in my homelab which are awesome and amazing and useful and one of a kind. It is a great feeling.
it's just insane what you can get done these days.
i just think with this thing in particular, it being in x86 assembly means you're not really "porting" but rewriting. and then why that and not something else? :)
but imagine using AI to port it quickly, and then using AI to expand the feature set, refine elements, etc. That would be very satisfying to me, for example.
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.
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
>I went to the University of Washington and [then] I got hired by this company called Geoworks, doing assembly-language programming, and I did it for five years. To us, the Geoworkers, we wrote a whole operating system, the libraries, drivers, apps, you know: a desktop operating system in assembly. 8086 assembly! It wasn't even good assembly! We had four registers! [Plus the] si [register] if you counted, you know, if you counted 386, right? It was horrible.
>I mean, actually we kind of liked it. It was Object-Oriented Assembly. It's amazing what you can talk yourself into liking, which is the real irony of all this. And to us, C++ was the ultimate in Roman decadence. I mean, it was equivalent to going and vomiting so you could eat more. They had IF! We had jump CX zero! Right? They had "Objects". Well we did too, but I mean they had syntax for it, right? I mean it was all just such weeniness. And we knew that we could outperform any compiler out there because at the time, we could!
>So what happened? Well, they went bankrupt. Why? Now I'm probably disagreeing – I know for a fact that I'm disagreeing with every Geoworker out there. I'm the only one that holds this belief. But it's because we wrote fifteen million lines of 8086 assembly language. We had really good tools, world class tools: trust me, you need 'em. But at some point, man...
>The problem is, picture an ant walking across your garage floor, trying to make a straight line of it. It ain't gonna make a straight line. And you know this because you have perspective. You can see the ant walking around, going hee hee hee, look at him locally optimize for that rock, and now he's going off this way, right?
>This is what we were, when we were writing this giant assembly-language system. Because what happened was, Microsoft eventually released a platform for mobile devices that was much faster than ours. OK? And I started going in with my debugger, going, what? What is up with this? This rendering is just really slow, it's like sluggish, you know. And I went in and found out that some title bar was getting rendered 140 times every time you refreshed the screen. It wasn't just the title bar. Everything was getting called multiple times.
>Because we couldn't see how the system worked anymore!
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.
Classic response to that:
https://www.folklore.org/Negative_2000_Lines_Of_Code.html
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.
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
Folks who are curious about the underlying technology can see:
https://github.com/bluewaysw/pcgeos
(which I'd love to see get ported to the Raspberry Pi EDIT: or updated to make it easy to run on contemporary hardware)
I have looked at what it would take to port it to a PI Pico.
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.
Hi! I'm doing something similar: vic-2350. But I'm not porting any existing system, I'm doing it to match the constraints of the hardware we have now.
I've been meaning to show you some of the stuff I have been working on.
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.
That's quite cool. I haven't dug deep into using the PIO but it clearly has potential, as shown by Linus Åkesson's demo work.
It's all in x86 assembly though. "Porting" it would be a complete rewrite to ARM64.
aka just one AI prompt away
Eh. Neither Claude nor Codex are that great with 16-bit real mode 8086 assembly.
yes maybe, but also will feel completely pointless after. like a soulless one-night stand :-)
could as easily run it in an emulator
Different people code for different reasons.
For some the "point" is just solving a problem, however that happens.
For others it's an art form that gives them a sense of worth, using their knowledge and experience to do something special that not just anyone can do.
Neither is right or wrong; people just have different goals.
I am not a great programmer, and I certainly do not have the attention span to complete a big personal project. But I can describe well to Claude the architecture I want, the look and feel of the UI and how it all should work.
I have things running in my homelab which are awesome and amazing and useful and one of a kind. It is a great feeling.
don't get me wrong. i've always just built for the sake of it and nerd out. and now I just... do more of it, with AI. i'm not opposed.
e.g. https://github.com/rdaum/rekursiv/ done on a whim based on a book i've had on the shelf for 25 years
it's just insane what you can get done these days.
i just think with this thing in particular, it being in x86 assembly means you're not really "porting" but rewriting. and then why that and not something else? :)
but imagine using AI to port it quickly, and then using AI to expand the feature set, refine elements, etc. That would be very satisfying to me, for example.
Wow! I remember using GEOS as a kid and not getting it. Lol
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).
(2016)
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
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.
Do be careful. The link to nokiamuseum dot info tries to download some crap
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
The GEOS Software Library: https://web.archive.org/web/20021203000244/http://www.tvakat... ("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"
Steve briefly mentioning that he worked for GeoWorks, and why he thinks/thought it ultimately couldn't keep up with changes. https://steve-yegge.blogspot.com/2008/05/dynamic-languages-s...
>I went to the University of Washington and [then] I got hired by this company called Geoworks, doing assembly-language programming, and I did it for five years. To us, the Geoworkers, we wrote a whole operating system, the libraries, drivers, apps, you know: a desktop operating system in assembly. 8086 assembly! It wasn't even good assembly! We had four registers! [Plus the] si [register] if you counted, you know, if you counted 386, right? It was horrible.
>I mean, actually we kind of liked it. It was Object-Oriented Assembly. It's amazing what you can talk yourself into liking, which is the real irony of all this. And to us, C++ was the ultimate in Roman decadence. I mean, it was equivalent to going and vomiting so you could eat more. They had IF! We had jump CX zero! Right? They had "Objects". Well we did too, but I mean they had syntax for it, right? I mean it was all just such weeniness. And we knew that we could outperform any compiler out there because at the time, we could!
>So what happened? Well, they went bankrupt. Why? Now I'm probably disagreeing – I know for a fact that I'm disagreeing with every Geoworker out there. I'm the only one that holds this belief. But it's because we wrote fifteen million lines of 8086 assembly language. We had really good tools, world class tools: trust me, you need 'em. But at some point, man...
>The problem is, picture an ant walking across your garage floor, trying to make a straight line of it. It ain't gonna make a straight line. And you know this because you have perspective. You can see the ant walking around, going hee hee hee, look at him locally optimize for that rock, and now he's going off this way, right?
>This is what we were, when we were writing this giant assembly-language system. Because what happened was, Microsoft eventually released a platform for mobile devices that was much faster than ours. OK? And I started going in with my debugger, going, what? What is up with this? This rendering is just really slow, it's like sluggish, you know. And I went in and found out that some title bar was getting rendered 140 times every time you refreshed the screen. It wasn't just the title bar. Everything was getting called multiple times.
>Because we couldn't see how the system worked anymore!
[flagged]