How about a thread about TempleOS?

How about a thread about TempleOS?
(But about its workings and internals, not about Terry for once)

Other urls found in this thread:

youtube.com/watch?v=Zr_3cdWKzys
youtube.com/channel/UC2JvKvUmoWdtE55ta15a3tg/videos
templeos.sheikhs.space/Wb/Home/Sup1/Sup1Bin/
github.com/tramplersheikhs/hgbd
github.com/minexew/Shrine/tree/master/HwSupp
github.com/minexew/Shrine/tree/master/SnailNet
templeos.sheikhs.space/Wb/Doc/HolyC.html
codersnotes.com/notes/a-constructive-look-at-templeos/)
youtube.com/watch?v=zfEAgtYDyJA
wikileaks.org/ciav7p1/cms/page_36896783.html
files.osdev.org/mirrors/geezer/osd/graphics/modes.c
twitter.com/AnonBabble

Posting rare Terrys to get the thread going

update: terry clicks on fake download ads with a stock firefox and almost installs an add-on that would've set his home page and search engine to something he didn't want in order to convert a image from jpg to bmp

youtube.com/watch?v=Zr_3cdWKzys

Discussing Terry is a lot more fun.

>This is Terry the black
Fucking every time

>Fucking magic spell based on Murphy's law, fucking free white man fucking nigger slave fucking piece of shit stop fucking with Terry Fucking Davis nigger monkey

lol

Sad that he doesn't do programming streams/videos anymore.

Terry spending 11 minutes trying to convert an image to bmp is not a programming video, you fucking ignoramus.

does terry count as a yourtuber?

youtuber*

no, since he's not on youtube anymore. it's more than one person archiving his vids at this point

youtube.com/channel/UC2JvKvUmoWdtE55ta15a3tg/videos

I just found out about Terry and TempleOS from Sup Forums and just started watching his vids. He is a likeable and intelligent guy. I can respect what he has accomplished, but he clearly has unhealthy an mental map and confused circular thought patterns. It's sad, but he still lives a higher quality life than most of humanity.
Who is the "Dianna" that he keeps talking about?

Kek at first I thought he was the fat guy in the middle

There are 3 archive channels

>Who is the "Dianna" that he keeps talking about?
"physics girl" on YouTube

but she's a niggabitch

oh thanks. does she even know who Terry is, or is she just his waifu?

His ex-wife. She fucks niggers so Terry broke up with her.

>ex-wife
Meant to say ex-waifu

TempleOS is the concrete manifestation of Terry's insanity. You can't separate both.

Do you guys want to know the difference between a white free man and a nigger slave? Just watch the video!

youtube.com/watch?v=Zr_3cdWKzys

Guatemalan chap returns home from a hard day dealing with Canadians only to be accosted by a drunk schizophrenic with divine intellect.

was she really his wife?

Yes, she was.
How new are you?

The call that saved TempleOS

I love comfy Sundays w/ TempleOS

TRANS NIGGERS B T F O

Why is Terry no longer streaming?

He's busy drinking his 12 pack.

>tfw you know that Sup Forums will eventually make a murderer out of this guy

that grrl wants him

cia niggers

wait that's not him?

That's his brother Sean

Hey nnnnnnnigger bitch

That video could have been 30s if that loser knew how to use Linux

>if that loser knew how to use Linux

Everyone knows that the purpose of Internet Explorer is to download Firefox.

CIA niggers watch out

>That video could have been 30s
...are you in a hurry or something?

I'm using this guy's videos for quick transcription practice. Someone please link his best video/moment so I can do that one.

Okay so today we're gonna learn the difference between a white free man and a nigger slave? Okay, so you wanna know the difference between a white free man and a nigger slave? Okay here's the difference. The slave... comes in here, he says, okay. So- I have a uh- a fabulous- so like Dan has got a nigger right? We're gonna lynch him perhaps. Right? So like, we wanna make a picture- Terry the Black. Like- but- we gotta lynch him or some shit. Right? So l- where are we?

What- so- Dan's got a nigger- this is Terry the Black. Fuckin' badass fuckin' photo, huh? Fuckin' Terry the Black. Right? So like, I come up here, I say like okay I'm gonna resize my image. I go to my website right? I put it on my website. It's like, a huge picture right? Put it on my website.

Piece of shit website, like, crashes. 's like- 's like 18 meg or some shit. Right? So like, now what? Now what? So like I come in here I say, okay, mister Photoshop, fuckin' resize me an image eh?

...

whats wrong with him?

whats wrong with you?

...

I kind of want to dick around with this. Two questions.
1) Can I easily set up a VM and access its filesystem from the host? I want to be able to save a file in my normal text editor and have tOS see it straight away. Anything less sounds like hassle.
2) How compatible is HolyC with regular C? If I were to take a portable C codebase such as Lua or SQLite, how long would it take to get it building as HolyC? Hours, days, months?

>Can I easily set up a VM and access its filesystem from the host?
You've got a couple of options:

You could keep the TempleOS install as FAT32, and use Terry's scripts to mount/unmount the virtual disk depending on your hypervisor:
templeos.sheikhs.space/Wb/Home/Sup1/Sup1Bin/

or, you could use HGBD, and transfer files between host and guest:
github.com/tramplersheikhs/hgbd

or, you could use the PCNet PCI II driver and TCP/IP stack from Shrine, set up a local webserver on your host machine and get the files via HTTP:
github.com/minexew/Shrine/tree/master/HwSupp
github.com/minexew/Shrine/tree/master/SnailNet
>How compatible is HolyC with regular C?
a general overview is here, most code in TempleOS is pretty much self-documenting so it's easy to pick up:
templeos.sheikhs.space/Wb/Doc/HolyC.html

Let me know if you have any other questions and I'll try my best to help you out

i don't think you can do either of those easily.

1. TempleOS supports FAT32 iirc, but i never tried actual file transfers myself. If you use something like a raw image for the VM, and if TempleOS decides to format it as FAT32, then using a loopback device to mount the image wouldn't be hard.

2. HolyC, according to Terry, is a non-standard C/C++ dialect, hence not compatible, so good luck porting the codebase.

...

>Firefox
Funny way to spell Chrome actually

>not 640x480

Spotted the MIT nigger.

Hi Terry

bump

You will never date female Terry. Why even live?

baby FaceApp Terry kinda looks like a younger Annie Lennox

I have an idea. Why don't we manipulate Terry into becoming a tranny?

>googleshit

lol

CIA nigger detected

>How about a thread about TempleOS?
>(But about its workings and internals, not about Terry for once)

>almost every post is about terry and not the workings and internals

besides the codersnotes article (codersnotes.com/notes/a-constructive-look-at-templeos/) i havent seen templeos explored in depth

can some smart programmer from here make a video or videos showing the internals of templeos?
or even an infographic showing how the it's different compared to linux and windows?

lots of people would be interested in seeing it properly explored and explained

terry is a nigger faggot

>Can I easily set up a VM and access its filesystem from the host?
Possible yes, easily no.

Will Terry ever put up the old website. It contained so much valuable information. Also can I install this on my 2017 PC without gimping all my drives into IDE compatibility mode? I just really love the idea of a modern C64. Does anyone even run this shit naively?

The old website and terrys youtube had plenty of info if you had any clue about operating systems or compilers, but the took those down because he is a dumb schizoid. But then again if you have to ask how it is different from Windows you're not the target audience in the first place.

>Will Terry ever put up the old website. It contained so much valuable information.
It's on archive.org. Also, a lot of the info is in the OS itself now if you use help.
>Does anyone even run this shit naively?
I think that Alec dude does.

>Does anyone even run this shit naively?
I do, here's a video of me playing a Game Boy emulator w/ SFC controller via parallel port, running TempleOS bare metal:

youtube.com/watch?v=zfEAgtYDyJA

I know this guy lurks Sup Forums. I would love to know his opinion which hardware to use for maximum compatibility. Sadly, Terry is stuck in the year 2005 and everything he supports is old legacy shit. Does anyone want to help me to port this shit to UEFI with proper SATA support? We could literally use TempleOS as our preboot environment. That would be pretty cool. Also we would get networking support for free. Since the UEFI preboot environment is also identity mapped, this shouldn't be too hard. All we need to do is to write a VGA emulator for UEFI GOP or UGA.

his brain is completely fried at this point

Here's a screenshot of my PCIRep, I run TempleOS native on a Core i5-2400, 14GB RAM. I keep the RedSea partition to a few GB, otherwise on first write the file allocation bitmap takes forever. I use a IBM 11H8130 (PCNet PCI II) network card, it works great with minexew's PCNet driver and network stack.

I haven't done much with UEFI (back when I was messing with applications it was just EFI) but I'm curious about what your thoughts are. I know Terry has mentioned in the past he would like UEFI support.

no

>firefox is not responding because you made your website one single huge ass page like a retard

How difficult would it be to add a network stack and drivers to TempleOS?

>but I'm curious about what your thoughts are.
UEFI has huge potential to be the ultimate Sup Forums autism box. The boot time services allow you to load and unload kernel images as if they we're applications. It's a literal meta os. The only issue is that the OS bootloader is supposed to call ExitBootServices, which frees all the memory of those neat firmware functions. If we could trick the firmware into preserving the boot-time services as if they were run-time services, we could unload the linux kernel, go back to the EFI shell and then load a completely different kernel like Windows, all without ever rebooting. UEFI is basically a modern high level version of DOS, but designed by committee to debug shitty preboot drivers. But we can make it our own. It even supports TCP out of the box. Without a fucking kernel, a full TCP stack. How cool is that? The big hurdle when it comes to porting TempleOS is that it relies on VGA graphics based on int10h. Setting the video mode this way only works in 16 bit real mode. However, a UEFI system starts in 64 long protected mode with identity mapping and you can't interact with the hardware with interrupts anymore and instead everything relies on UEFI firmware function calls. In order to get TOS running we need to emulate the VGA videomode in UEFI. UEFI provides a simple 2D accelerated graphics api called GOP (Graphics Output Protocol) that supports stuff like blitting. Sadly, there is very little documentation outside of the specification PDF. I don't know if GOP could give us framebuffer access for instance. I also don't know if it is even possible to talk to the PC speaker in UEFI mode. I should also add that I don't know shit about OS development and that I'm just a third year CS student who spend way too much time on the OSDev wiki and reading UEFI specs over the last 6 months or so. All my knowledge is purely theoretical.

I would rather keep a BIOS setup than have a UEFI system potentially compromised with TCP access.

>resize a simple picture
>it crashes
>save a picture in a different, common format
>it crashes

The year of desktop Linux

But I don't want to enable fucking CSM. I want to be able to boot into TempleOS from my main computer without changing any firmware settings and without using antiquated BIOS emulation. Also I'm pretty sure that TCP isn't enabled by default. Every UEFI protocol needs to be manually probed and activated by a EFI application. Imagine how cool it would be if you turned on your PC and it would boot straight into Temple OS, from where you could just type Arch; or Windows; and it would boot into the OS you want. Now also imagine returning to Temple OS from Linux or Windows with a single function call. This is possible if we port Temple OS to UEFI and manage to hack our firmware to preserve the boot services even after ExitBootServices has been called. Hooking these UEFI calls is pretty easy, too. You just assign a function pointer. Thank god for the CIA and wikileaks:
wikileaks.org/ciav7p1/cms/page_36896783.html

>Making it easier for the CIA niggers to take over your computer
You're a nigger

Are you here because you want a C64 with x86, or do you just want to post dank memes? Also we're literally using information the CIA doesn't want us to know to make this work.

>Does anyone want to help me to port this shit to UEFI
No, you can fuck right off.

BIOS is dead. In 10 years there will be no BIOS compatible firmware left. Why do you hate UEFI? All the NSA shit is happening way before UEFI takes over in the boot phase. Coreboot and UEFI are not mutually exclusive.

...

>and you can't interact with the hardware with interrupts anymore and instead everything relies on UEFI firmware function calls
Holy shit, what a pile of fucking trash UEFI is.
I'm never fucking supporting this utter trash in my OS.

Well you could probably still talk to the device directly over PCI, but every device needs to be handled differently, you can't force graphics cards to pretend that they are DOS compatible VGA cards forever. That's where the UEFI driver comes in. UEFI is basically a micro kernel that allows for OS independent drivers. The implementation is crap, but the idea is nice.

minexew did that awhile ago, it works great:
github.com/minexew/Shrine/tree/master/HwSupp
github.com/minexew/Shrine/tree/master/SnailNet

Here's a screenshot of a simple web server I wrote for TempleOS, running native w/ PCNet card, serving a live screenshot from TempleOS as a PNG.

What's wrong with this? Do you think interrupts are some sort of low level magic? All you are doing is using a primitive API to change the state of the GPU to support some primitive 2D graphics protocol. Why is using function calls instead of interrupts such a big deal?

>UEFI is basically a micro kernel that allows for OS independent drivers.
And it's completely useless because you'd usually call ExitBootServices before handing control over to the kernel, which makes it inaccessible.
And what's even worse, is that because it's UEFI, and not BIOS, then when I do hand control over to the kernel, I won't have any graphics AT ALL, because there's no VBE or anything to interact with from vm86 mode.

Graphics for hobby OS developers are just completely hopeless.
If you're writing a 64bit OS, you can just say goodbye to graphics whether you're BIOS or UEFI, because there's no fucking vm86 mode.
Shit fucking sucks, the big corporations really need to give us hobbyists some love by providing a simple and standard (that vendors actually implement. Looking at you, VBE3) interface accessible from protected/long mode.

The only thing we can do is set the video mode in the bootloader, which is way too restrictive in my opinion.

Dare I run TempleOS as my main?

>And it's completely useless because you'd usually call ExitBootServices before handing control over to the kernel, which makes it inaccessible.
Which is why I want to hook it and trick the OS intro preserving the boot services along side the runtime ones.

>And what's even worse, is that because it's UEFI, and not BIOS, then when I do hand control over to the kernel, I won't have any graphics AT ALL, because there's no VBE or anything to interact with from vm86 mode.
If I understood a microsoft powerpoint about the windows UEFI boot process correctly, it should be possible to write to the framebuffer after ExitBootServices without having an actual GPU driver.

>The only thing we can do is set the video mode in the bootloader, which is way too restrictive in my opinion.
If we hack the firmware and manage to castrate ExitBootServices there is no fucking difference between the OS and its boot-loader anymore. UEFI is less restrictive then the fucking BIOS, because it gives you an identity mapped 64 bit environment for free without you having to set up paging and shit.

>Shit fucking sucks, the big corporations really need to give us hobbyists some love by providing a simple and standard
Could easily be solved by the vendors supplying a Vulkan driver for UEFI for their graphics cards. Are there any open source Linux drivers for contemporary Nvidia or AMD cards? We could just port those over to the UEFI driver model and then we could have 3d accelerated graphics in bare metal.

>then when I do hand control over to the kernel, I won't have any graphics AT ALL, because there's no VBE or anything to interact with from vm86 mode.
Just don't call ExitBootServices.

>Which is why I want to hook it and trick the OS intro preserving the boot services along side the runtime ones.
And I don't want to do hacky fucking bullshit like that which sounds like it could easily break.
The rest if your post is pretty much invalidated now.

>Could easily be solved by the vendors supplying a Vulkan driver for UEFI
Haha, you really fucking think any vendor would actually do that?
They can't even provide VBE3 support, which is way simpler than Vulkan.
There is no way in fucking hell that will ever happen.

>If I understood a microsoft powerpoint about the windows UEFI boot process correctly, it should be possible to write to the framebuffer
Even so, you still can't change the graphics mode.

Aren't there any consequences to that? Would a full blown kernel be able to work without calling ExitBootServices?

happened already

VGA might not be a problem with something like this:

files.osdev.org/mirrors/geezer/osd/graphics/modes.c

unsigned char g_640x480x16[] =
{
/* MISC */
0xE3,
/* SEQ */
0x03, 0x01, 0x08, 0x00, 0x06,
/* CRTC */
0x5F, 0x4F, 0x50, 0x82, 0x54, 0x80, 0x0B, 0x3E,
0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xEA, 0x0C, 0xDF, 0x28, 0x00, 0xE7, 0x04, 0xE3,
0xFF,
/* GC */
0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x05, 0x0F,
0xFF,
/* AC */
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x14, 0x07,
0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F,
0x01, 0x00, 0x0F, 0x00, 0x00
};

write_regs(g_640x480x16);

assuming I/O port writes should work fine...? screen refresh in TempleOS is simply:

U0 GrUpdateVGAGraphics()
{//Update Graphic Card
I64 row,plane,d=gr.zoomed_dc->width_internal;
U32 *src,*vga,*dst;
if (gr.scrn_zoom==1)
src=gr.dc1->body;
else {
GrZoomInScrn;
src=gr.zoomed_dc->body;
}
dst=gr.scrn_image->body;
if (LBtr(&sys_semas[SEMA_FLUSH_VGA_IMAGE],0)) {
for (plane=1;plane

As far as I understand ExitBootServices does literally nothing except killing the boot-time services and signaling all connected device drivers to stop listening to UEFI calls. I think the point is to isolate the operating system from the firmware so it can't just go around loading other kernels and shit, because that would be a straight rootkit pass-through. So basically: Everything prior to ExitBootServices is the new real mode and everything after is the new protected mode. Except that "real mode" can do anything" protected mode can do too.

What even are I/O ports? The pins on the CPU? Is there some sort of memory mapping involved, giving us a direct pointer into the GPU? The problem here is that if we boot in UEFI mode, then firmware of the GPU will set up compatibility with UEFI GOP instead of the old BIOS VGA. The VGA registers you write to don't exist on modern hardware anymore. The GPU firmware is just pretending and it doesn't pretend if the firmware of the PC isn't also pretending to be a BIOS. At least that's what I think. I'm not a firmware developer.

>Even so, you still can't change the graphics mode.
You can. Just don't call ExitBootServices.

>Haha, you really fucking think any vendor would actually do that?
No. But there are FOSS drivers for Linux. We could just port those over.

Won't there be a security risk by not doing that?

Yeah, that's the entire point. If you want your OS to have full control of your hardware and firmware you need to say goodbye to security. No fucking shit Sherlock. You can't have it both ways.

>If you want your OS to have full control of your hardware and firmware you need to say goodbye to security
That makes no fucking sense, nigger.

Ok question time...temple os actually does seem interesting and seems to have some unique features...and his programming language holy c also seems very unique.

So the question is why is nobody else touching this stuff? Is it actually terrible software or is it being avoided only for its creators personality?

Is that software worth 2 shits?

It does. You need to firmware to get access to certain low level functions. If you kick out the firmware from the system with ExitBootServices you can make sure that no one can abuse the firmware as a backdoor, but you also lock yourself out of the firmware. If you want to access firmware functions from the OS you just need to deal with the fact that the firmware is still there in the background. Also you can't even get rid of the firmware, because the runtime services are in the background anyways. Doesn't matter if you call ExitBootServices or not. The security risk is inherent to UEFI, which is why secure boot was a thing, but all you people did in response was autistic screeching.

it might be amusing and interesting to the likes of Sup Forums but it doesn't offer anything of commercial or end user value.

Could the inner working of temple os be used as the basis for a better system?

Why has nobody made a fork yet?

>So the question is why is nobody else touching this stuff? Is it actually terrible software or is it being avoided only for its creators personality?
Because it requires you to gimp your PC into emulating outdated protocols for your fucking hard drives in order to function. Also there is not a big target audience for something like a x86 C64 in the first place.

>Is that software worth 2 shits?
The idea is absolutely next level genius. The implementation is a bit questionable. It would have been great in the 90s or 2000s or so, but the world of hardware has moved on, making the entire thing a bit backwards. Terry can't even boot this thing natively on his machine.