
TempleOS V4.02 Released - TerryADavis
http://www.templeos.org/TempleOS402.html
======
PeCaN
Say what you will about TempleOS, but HolyC is actually brilliant. The same
language is used for the OS, programs, and shell, the entire OS is JIT-
compiled (modify the source and reboot to make changes), and it's just
generally a really different way of doing things. You can also put vector
graphics in source code.

~~~
fit2rule
I agree with you completely. The idea of a single language to rule the entire
system is brilliant, and is something I wish others would consider putting
their attention on - i.e. distro builders who compose a "Lua-only" stack, or a
"Python-only" stack, and so on.. well, such things exist in Dockerland easily
enough these days, but one wonder what it would be like if the 'modern desktop
OSes' had this hit-one-key-and-access-code-anywhere mentality .. it has so
much appeal over the current worm bucket o' mystery that is the modern OS
'distribution'/'package'/'bundle'/'module collection' ..

~~~
emailgregn
wasn't that the idea with OLPC Sugar
[[http://wiki.laptop.org/go/Sugar](http://wiki.laptop.org/go/Sugar)]?

The whole desktop and apps in python and hackable.

~~~
masklinn
It was definitely the idea with lisp machines (taken even further as they had
hardware support for Lisp primitives and GC)

------
vinceguidry
Things like this and Dwarf Fortress are just so amazing to me. What you can
accomplish if you can devote an entire decade to doing just one thing...

It's something I want to try, say, in my sixties or so.

~~~
voaie
Then it will be very amazing if Dwarf Fortress runs in TempleOS. ;-)

------
sdk77
Nice, I will give it a try. I've installed templeOS in a VM before and played
around with it. I really like the concept of a graphical console, being able
to literally put images right into source code and the C++ like shell that
uses some kind of JIT compiler, it's different, and interesting.

------
desireco42
I think he actually got to something really important here: "The vision for
TempleOS, however, is a modern, 64-bit Commodore 64"

------
emcrazyone
As someone who grew up with a C64 and programmed them, I can totally
appreciate this. The C64 had ROM basic at the same address as part of the
physical RAM.

I developed software called CNet BBS back in the day, and the software,
written in assembly, would constantly switch the basic ROM interpreter in and
out to simulate a multi-tasking environment allowing basic programs to run
along side a mini OS.

I absolutely love the sound of his keyboard!

I wonder if TempleOS could find practical applications in the embedded world
as an RTOS.

I currently am working with Jacinto J6 processors which are multi-processor
devices. They have two ARM A15 cores and 4 ARM M4 cores (called IPUs). My work
involves running Linux & Android on the A15 cores while bringing up a hardware
monitor on the M4 cores. I looked at several possibilities such as uCLinux,
FreeRTOS, and a commercial product called uVelOCity by Green Hills.

Something like TempleOS might feed this need for what appears to be a market
of CPUs needing a small RTOS running along side another OS.

For the interested, there is also this project:
[https://gdmissionsystems.com/7-31-2014-sel4-microkernal-
open...](https://gdmissionsystems.com/7-31-2014-sel4-microkernal-open-source-
software/)

------
bliti
Mr. Davis,

The link posted mentions the OS being developed to provide a similar
programming experience as the c64. Are there any learning resources available
like there are for the c64? Thank you!

------
rwl4
I feel like TempleOS has a lot of parallels to Dr Bronner's Soap. That's the
only soap I use as bodywash in the shower. ;-)

------
breakingcups
Are these two statements not contradictory?

"I capped the line-of-code count at 100,000 and God said it must be perfect,
so it will never be an ugly monstrocity. It is currently 80,590 lines of
unblemished code. Backward compatibility is not promised."

"I wrote all 119,580 lines of TempleOS over the last 12.5 years, full-time,
including the 64-bit compiler."

Or is the compiler excluded from that line count?

------
madprops
Cool, what's new in this release?

~~~
Aloha
See -
[http://www.templeos.org/Wb/Doc/ChangeLog.html](http://www.templeos.org/Wb/Doc/ChangeLog.html)

------
sitkack
This is excellent! Thanks Terry.

------
bobsgame
thank you Terry!!

TempleOS is TRUE ART. Terry is like BACH.

if you haven't tried it in a VM you REALLY SHOULD, it boots up in two seconds
and is REALLY INTERESTING!

~~~
GFK_of_xmaspast
> Terry is like BACH.

I would have said more like Henry Darger.

~~~
smt88
I don't know if Bach was a paranoid racist. Was Henry Darger?

" _Fucken china-niggers, LOL.[https://www.brainpickings.org/2012/01/04/isaac-
newton-list-o...](https://www.brainpickings.org/2012/01/04/isaac-newton-list-
of-sins/*"\[1\])

1\.
[https://twitter.com/TempleOS/status/682387889104273408](https://twitter.com/TempleOS/status/682387889104273408)
(other examples on his Twitter feed)

~~~
GFK_of_xmaspast
I was thinking more along the lines of 'maybe you'd better be careful when
they're around children'
[https://twitter.com/templeos/status/666064493881896960](https://twitter.com/templeos/status/666064493881896960)

------
TerryADavis
Myth Busters CPU vs GPU. Go to 2:40 and 8:00 in the video.

[https://www.youtube.com/watch?v=XcolCeWIcss](https://www.youtube.com/watch?v=XcolCeWIcss)

~~~
ma2rten
Is this in any way, shape or form related to TempleOS?

~~~
TerryADavis
You might wonder why TempleOS is barely doing 640x480 at 30fps. The GPU is
2000 times faster than the CPU.

~~~
i336_
Do you have any current or distant ideas on implementing basic GPU support in
TempleOS? Virtualization has gotten to the point where GPU passthrough is
beginning to be feasible/viable.

PS. I think this is an amazing project. I'm grateful you accepted the
challenge in writing it. :D

~~~
garrettgrimsley
"GPU is banned."
[http://www.templeos.org/Wb/Home/Web/TAD/GraphicsPerformance....](http://www.templeos.org/Wb/Home/Web/TAD/GraphicsPerformance.html#l1)

~~~
i336_
Ah, right.

I wonder what the rationale behind this point is, then - especially
considering the GPU _is_ quite a bit more parallel than the CPU.

~~~
garrettgrimsley
Because God said so. That and the aim of the system is to create something
akin to the Commodore 64 in which the entire system is open to the user.
[http://www.templeos.org/Wb/Doc/Charter.html#l1](http://www.templeos.org/Wb/Doc/Charter.html#l1)

~~~
chippy
"Graphics operations should be transparent, not hidden in a GPU."

Is GPU programming opaque, I've not done any low level stuff? I imagine it's a
whole bunch of different API calls, but based on triangles, rather than points
and lines?

Could one write a simple GPU in code, for example, I wonder?

~~~
dogma1138
Well with how modern GPU's, their driver and API's work you write code to do
something then the driver "decides" on the "best" way of doing it.

Display drivers can replace entire shaders and modify pretty much any
instruction and they often do so if nothing than for the code to actually work
because game developer not only have shifted allot of the "performance"
optimization burden to the GPU vendors but also quite often ship completely
non complaint (and nonfunctional) graphics code, there have been plenty of gem
posts on gamedev.net including multiple AAA studio's that botched their code
so poorly on multiple titles that if it there wasn't a generic fix in the
driver already it would not display anything at by not calling D3D::Create,
D3D::EndFrame/Begin frame properly or at all in many cases.

Overall the majority of the driver codebase today is abstraction and fixes,
only about a 3rd of it is actual API implementation.

~~~
choosername
How much performance would a pure and thus leaner driver gain, I wonder. Also
a fair bit of backwards compatibility will be involved, like with x86 cpus.
And even then, the same fixup is required to run opengl on directX cards, I
believe.

~~~
dogma1138
Considering that even with API's that have some what good internal compliance
testing like DirectX developers still ship utterly broken and un-optimized
code - none.

This is also why Vulcan will probably not succeed (at least now how people
think it will).

The last thing that say Nvidia wants is to maintain a code base of 3-4M LOC's
which 50-60% of it is intended to allow for games to run anywhere from running
at all to running well.

With how the current market works the driver is the "secret" sauce that GPU
makers use to compete in the market and is just as important (or even more in
some cases) as the hardware it self.

------
johnhattan
This rather reminds me of the "Coral Castle" in Florida. Basically one guy
went nuts after getting dumped by his girlfriend, so he built a fortress-sized
structure out of blocks of limestone (not actually coral). It's quite a goofy
little tourist attraction now.

If only all people who lost their minds could devote all their time to a
harmless quest that doesn't hurt anybody.

~~~
choosername
Well an artist might argue that the art is, vice versa, driving the craze,
too.

