<zid>
new laptop = new benchmarks, only reason I get new hw
<zid>
it's been fast enough for forever
<gog>
i haven't done any benchmarks yet
<gog>
i'm still getting used to the iso keyboard too
<gog>
i've been having to use one at work for the last few weeks so i'm getting there
<zid>
iso keyboard <3
* vdamewood
stares at the fishy
<zid>
Welcome to the real world, goggo
* gog
chomps fishy
<zid>
enjoy being able to type BOTH kinds of slash
<vdamewood>
klange: I did import os and os.exit(5) and it crashed on me.
<klange>
in the web repl?
<klange>
you told emscripten to exit :D
<vdamewood>
klange: Seriously though, the response to the exit looks totally normal.
<vdamewood>
klange: Oh, the slides that tutorial() produces are neat. The Python REPL doesn't do anything that fancy.
<zid>
is it as good as vimtutor!1!wq!
<klange>
That's specific to the web repl and intended to to be a demonstration of using the wasm builds to use kuroko for frontend web scripting, but it's rather hacky since wasm doesn't have DOM access
diamondbond has quit [Quit: Leaving]
<vdamewood>
klange: Are integers machine int64s, (or 32s?) or are they bignums?
<klange>
48-bit due to NaN boxing constraints, with plans for bigints that have yet to come to fruition.
<vdamewood>
Got it, one amd64 pointer.
<vdamewood>
(not really. The pointers are still 64-bit, even if the high-order byte is redundant.)
<vdamewood>
"Objects are more complicated values like..." FWIW, I think the word 'complex' is more appropriate here.
<klange>
I've been really happy with how Kuroko has turned out. It's still got some quirks and the standard library is nearly non-existent, but it's served its original purpose quite well.
<vdamewood>
It looks neat.
<vdamewood>
It's certainly more of a programming language than my toy language, which only does expression evaluation.
<klange>
I've gotten Kuroko to a very high degree of compatibility with Python, have managed to squeeze in some things I personally consider improvements on the syntax, and am doing well in benchmarks.
<klange>
It's been much more rewarding than OSdev :)
<klange>
Also, since it's embedded in my editor, I use it every day - including at work :)
<vdamewood>
Are you shooting for a superset relationship?
<klange>
More of a venn diagram with a tight overlap. I haven't gone for too much new syntax, and I'm racing to catch up with new functionality in Python - the new(ish, I'm like a year late to this) pattern matching stuff is neat but they made some decisions with it that are giving me headaches.
<vdamewood>
I've been thinking of switching my build system to CMake... I think I'll give it a shot now.
<klys>
devs who switch to cmake should partially document cmake in their repos
<vdamewood>
klange: Given how customizable build system generators like CMake are, the build system should certainly be documented.
gog has quit [Read error: Connection reset by peer]
<vdamewood>
err klys ^
<vdamewood>
Damn... I have to type 3 letters to tab between you two.
<Mutabah>
klange klys kollision
<klys>
:)
<klys>
what's new mutabah
gog has joined #osdev
<Mutabah>
cold
<Mutabah>
... and background working on USB support
<Mutabah>
Doing EHCI because I'm a sucker for punishment
<klys>
oh yeah you were doing usb eh
<klys>
breaking out usb into serial for use on a breadboard seems imaginable yet perhaps a bit heavy on the difficult side
<klys>
actually parsing usb with circuity would be a job for some programmable logic I figure
<klys>
most usb-serial relies on the in-circuit uart, like ftdi, though if you're going to put it back into usb then you can't really rely on those.
<klys>
back into usb being, otg via a hub of sorts
<klys>
which reminds me I busted a port on my older usb 3.0 hub by plugging the input into the output
<klys>
meanwhile on the software side, attempting ehci must seem quite a bit different to someone who actually has the acpi stuff running
<klys>
the usb stack is fairly intricate itself, from views of wireshark, etc.
<Mutabah>
There's a recentish forum thread about EHCI. It's a mess
<Mutabah>
Mostly with how it handles USB1 devices, but the controller layout is also a little odd
<klys>
the ehci controller is probably the most standardized
<klys>
I can see something here about interrupts not working
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<klys>
said "the mouse shuts off" because it isn't "truly a high speed device."
nil is now known as eck
<klys>
so he switched to writing an xhci driver and "found the...ehci controller" on a higher interrupt
Likorn has quit [Quit: WeeChat 3.4.1]
<klys>
I guess if you were making circuits the trick would be having multiple serial ports available to assign enumerated devices to
<klys>
I'm also fairly interested in usb-otg, though still don't know much there yet.
<bslsk05>
en.wikipedia.org: USB On-The-Go - Wikipedia
<klys>
> "The new OTG protocols cannot pass through a standard USB hub since they are based on electrical signaling via a dedicated wire."
<zid>
over the gounter
sonny has joined #osdev
X-Scale has joined #osdev
gog has quit [Quit: byee]
<kingoffrance>
"which reminds me I busted a port on my older usb 3.0 hub by plugging the input into the output" klys is on my ignore, thats him in a nutshell lol
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<sonny>
Isn't the `hlt` code redundant in this UEFI 'hello world'? <https://bpa.st/LJ6Q>
<bslsk05>
bpa.st: View paste LJ6Q
<moon-child>
sonny: it lets you do nothing faster
<moon-child>
(or, rather, slower)
<moon-child>
(depending on how you look at it)
<moon-child>
it saves power
<sonny>
ok
<kingoffrance>
looks like it doesnt want it to return/exit
<sonny>
for(;;) won't exit
<sonny>
reading about hlt, seems like that by itself is sufficient
<moon-child>
hlt will spuriously wake
<moon-child>
in particular, when an interrupt is received
<sonny>
oh ok
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
gog has joined #osdev
gog has quit [Read error: Connection reset by peer]
srjek has quit [Ping timeout: 255 seconds]
the_lanetly_052 has quit [Ping timeout: 240 seconds]
Burgundy has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
srjek has joined #osdev
Oshawott has joined #osdev
sonny has quit [Quit: Client closed]
miezekatze has joined #osdev
archenoth has quit [Ping timeout: 260 seconds]
miezekatze has quit [Quit: WeeChat 3.5]
sheb has quit [Quit: Leaving]
wereii has quit [Ping timeout: 272 seconds]
jafarlihi has joined #osdev
<jafarlihi>
Is there any resource out there for creating lexer generators?
<klange>
You may want to ask in #proglangdesign
jafarlihi has quit [Ping timeout: 258 seconds]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
GeDaMo has joined #osdev
marshmallow has joined #osdev
bauen1 has joined #osdev
nyah has joined #osdev
pounce has quit [Ping timeout: 244 seconds]
wereii has joined #osdev
pretty_dumm_guy has joined #osdev
bauen1 has quit [Ping timeout: 244 seconds]
blockhead has quit []
jafarlihi has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
jafarlihi has quit [Ping timeout: 255 seconds]
foudfou has quit [Remote host closed the connection]
bauen1 has joined #osdev
foudfou has joined #osdev
bauen1 has quit [Ping timeout: 258 seconds]
bauen1 has joined #osdev
jafarlihi has joined #osdev
Oshawott has quit [Ping timeout: 260 seconds]
bauen1 has quit [Ping timeout: 246 seconds]
jafarlihi has quit [Ping timeout: 276 seconds]
bauen1 has joined #osdev
rpnx-phone has quit [Read error: Connection reset by peer]
heat has joined #osdev
<heat>
re: for(;;) <-- this can be completely eliminated (and is if you're using clang) by the compiler
<heat>
as it's UB
<zid>
how is it UB exactly?
<mrvn>
heat: for(;;);?
<heat>
infinite loop
<zid>
how is that UB?
<heat>
it is
<mrvn>
c++ foprbids infinite loops
<zid>
That's a great answer heat and you know it
<zid>
if you don't know just say so and I can try google it
<heat>
mrvn, is it just C++?
<mrvn>
ask google, no idea.
<zid>
C11+ apparently says something about it
<zid>
I don't use C11 so I'd have to go read it
<mrvn>
Is clang actually optimizing that UB? gcc sure doesn't.
<heat>
yes, clang does
<heat>
It has gotten me a few times
<mrvn>
DOes it insert UB2 opcode?
<zid>
Okay, "An iteration statement ... does not access volatile blah blah ... may be assumed by the implementation to terminate."
<mrvn>
I guess it unrolls it infinite number of times and then it's just ";" :)
<zid>
I'd honestly say clang is just fucking *wrong* here
<mrvn>
totally.
<zid>
In a very torvaldsian way, what the fuck is the point of that behavior
<zid>
it just exists to make programmers look stupid and break things
<mrvn>
But il-formed code may be translated how ever it wants
<mrvn>
zid: The optiomizer will see "for (something; something; something) { statement with no affect; }" and eliminate the loop. That "something" is "" doesn't matter.
<zid>
basically this but replace what he's talking about with "clang eliding loops"
<zid>
err wrong link whoops
<heat>
pre-therapy linus had some bad vibes :|
<zid>
I never had an issue with linus
<zid>
There's a rant I am thinking of but I can't find it, oh well
<j`ey>
cos he never had an issue with you :p
<zid>
Mainly because I also think the only recourse to people making the same mistakes over and over if I can't fire them is to send them angry emails :P
<zid>
including the C standar's comittee
Likorn has joined #osdev
<heat>
btw I believe that clang's behavior is OK since your .text is padded with int3's
<heat>
scary, but it should work I think
<mrvn>
I think it's stupid but it's correct.
<heat>
oh it's correct for sure since "hurr durr undefined behavior"
<mrvn>
I like my binaries to fail/hang when I write bad code. Not have the compoiler magically fix it.
<heat>
it doesn't seem to do this in C
<heat>
:)
<zid>
(it's not actual UB in C?)
<zid>
er sorry badly worded
<mrvn>
for(;;); is a simple way to quickly add a "breakpoint" in some code.
<zid>
it's not actual UB in C, is it in C++?
<kingoffrance>
confusion of tongues :)
<zid>
It's just pointed out explicitly that it's elidable
<heat>
yes it is
<heat>
in C++ that is
<zid>
C++ is weird
<mrvn>
zid: you are not allowed to loop forever. Doing so is UB.
<kingoffrance>
hmm, on the macro scale that would imply binaries must be restarted every so often
<mrvn>
I have no idea how they square that with signals and interrupts.
<kingoffrance>
:)
<mrvn>
alarm(1); for(;;); is perfectly fine code I feel.
<mrvn>
kingoffrance: binaries tend to have observable side effects
<Andrew>
An observable side effect is that your computer has became a spaceheater
<heat>
mrvn, clang disagrees :)
<mrvn>
for(;;); doesn't heat that much.
<heat>
i agree
<heat>
it doesn't me that much
<heat>
however
<heat>
damn inefficient
<mrvn>
How do you actually write the above c++ conform?
<heat>
__asm__(""); :)
<Andrew>
... Is anyone trying to do OS development in C++? Sorry I cleared my backlog
<\Test_User>
__asm__("jmp $"); ought to do it quite well
<heat>
now it's implementation defined!
<mrvn>
that's not c++
<zid>
A few people do microkernels and shit in it
<zid>
where they don't have to deal with the C++ nonsense so much
<heat>
\Test_User, jmp $ is bound to screw something up
<\Test_User>
heat: for(;;); is the same infinite loop
<heat>
I have a whole kernel in C++
<heat>
\Test_User, assembly jumps in inline assembly is bound to fuck something up
<\Test_User>
hmm fair enough
<heat>
especially when __asm__(""); is enough
<Andrew>
heat: Any reasons to use C++ over C (or is it you choosijg it because personal preference) for kernels?
<heat>
RAII
<\Test_User>
you mean for(;;) __asm__(""); ?
<heat>
also helps out with OO programming
<zid>
C++'s actually a huge pain in the butt in kernel code unless it's doing something *for* you that offsets it
<heat>
\Test_User, yup
<\Test_User>
k
<zid>
like "I really really want to have no compile time encapsulation, I'm willing to implement the C++ runtime to aquire it"
<heat>
Andrew, RAII is super useful, classes and structs and virtual methods are fantastic, templates are useful (in moderation)
<Andrew>
zid: I agree
<heat>
erm. it's not
<heat>
it's exactly like C
<Andrew>
heat: C has structs though, I generally find classes messey
<heat>
you need like 7 simple functions for the whole ffreestanding C++ runtime
<sbalmos>
global naming convention discipline gets to be a real PITA
<sbalmos>
err s/convention/uniqueness/
<Andrew>
Oh, that absolutely
<heat>
Andrew, structs are OK but then you end up 1) passing the equivalent of a this pointer everywhere, manually; 2) reinvent the function pointer vtable wheel
<Andrew>
I'm looking into Zig language for kernel development, it has namespaces and stuff but its standard library is disgustingly big
<heat>
well, you're not supposed to use the standard library
<Andrew>
Well
<Andrew>
There are things that I might lke
<Andrew>
for example sqrt()
<Andrew>
But the stdlib contains stuff like JSON parsers, meh
<heat>
you don't need sqrt in a kernel :)
<kingoffrance>
IIRC the zig author used to hang in here, but i played ddr "drop the bomb" for great justice, and i think i scared him off :/
<Andrew>
?
<Andrew>
heat: Fine lol
<heat>
Andrew, right. anyway, C++ is fine for kernel development. Some aspects of the language are bad, yes (exceptions, some good portions of the standard library, the expectation of Boost everywhere) but you can mostly manage to escape all that for a kernel
<heat>
does it compile as fast as C? no. but that's almost impossible to beat anyway
<heat>
my C++ compiles relatively fast as it's lightweight
<Andrew>
assembly "compiles" faster, but yeah that's not really compiling
<zid>
C++ is as good as the amount of it you ignore
<mrvn>
Andrew: just namespaces alone make C++ worth it
<heat>
AND it's more maintainable and safe
<Andrew>
Though compiling time isn't really important to me
* Andrew
looks at Zig and feels a bit better
<heat>
like RAII was almost the whole reason I switched, and is almost the whole reason why I use it
<heat>
i'm not smart enough to manually manage resources correctly
<mrvn>
templates add type safety to void* constructs in C
<heat>
templates are good but they're very overused I feel like
<mrvn>
In the STL? totally. concepts lessen that somewhat but it's ongoing.
<heat>
also SFINAE, etc make me barf
<heat>
and fucking recursive templates
<mrvn>
that's much less needed in c++20 too
<heat>
if you want something like std::tuple you do need recursive templates
<heat>
IMO a big problem with C++ is that people prefer to build stuff on top of existing stuff instead of adding more features directly
<heat>
leading to stupid shit like SFINAE
<heat>
a lot of it really kills compile time
<heat>
you end up with stupid late stage C++ stuff like LLVM
<mrvn>
heat: why? parameter packs work great
<zid>
late stage capitalism C++ is amazing
<zid>
"I've provided printing for my object via a virtually inherited polymorphic left shift operator friend class! Look how clean my code is!"
<mrvn>
only bad thing in std:tuple is std::tuple::get<int>()
<heat>
zid, it's not a virtual method I'm sure
<zid>
That's why I describe C++ as a meta-language for writing domain languages is, you write 40k lines of templates and operator overloads so that your main.cpp is 4 lines of BASIC
<heat>
just a simple shift operator overload with two operators
<mrvn>
zid: I tend to have a public: ostream & print(ostream &out) const;
<zid>
way to miss the forest for the trees there heat :P
<heat>
well. it's simpler than other languages
<heat>
in C you need GNU extensions to do that
<mrvn>
auto [a, b, c] = foo(); is greate too.
<zid>
Ever implemented iostream in an hour?
<zid>
ever implemented printf in an hour? :p
<mrvn>
Too bad that still calls std::tuple<A, B, C>::~tuple()
<heat>
i'm not defending iostream
<heat>
it's bad
<mrvn>
zid: rm -rf iostream, implement format in a week.
<heat>
std::format and std::print are good though
<mrvn>
I don't know how many c++ programs I have that still use printf().
<heat>
most of mine do
<heat>
<format> is not yet portable
<heat>
and iostream is crap
<j`ey>
how so?
<heat>
which part
<mrvn>
heat: you mean not all compilers have formatg yet?
<heat>
mrvn, yes
<mrvn>
saddly true. give it time.
<j`ey>
heat: portable bit
<j`ey>
oh ok
<heat>
well, ^^
<j`ey>
I was thinking architecure wise
<heat>
one of {gcc, clang} doesn't have it yet
<heat>
(the stupidest bit is that they only added std::string std::format(...); to C++20; if you want to print something, std::cout << std::format(...);)
<heat>
std::print is afaik C++23
<heat>
also my pet peeve for C++ is the networking proposal(s)
<heat>
holy fucking shit the overengineering they're doing is astonishing
<heat>
async everything because why not, everything is abstracted in little classes because why not
<zid>
50p says whatever it is they've proposed clashes wildly with every other C++ feature
<zid>
and has to be used exclusively in a safe-subset manner
<heat>
C++ (a language standardized since 1998) does not have networking in 2022
<heat>
that's how overengineered it is
<heat>
it's almost like BSD sockets aren't a portable thing
<mrvn>
heat: other languages, including C, just spawn threads like there is no tomorrow for asyncIO. It's horrible.
<heat>
io_uring?
<mrvn>
heat: new and linux specific.
<heat>
you can also *just do things yourself*
<heat>
async networking will fallback on top of threads without io_uring or similar
<mrvn>
heat: it should use select/poll/epoll and coroutines
<bslsk05>
en.wikipedia.org: Thundering herd problem - Wikipedia
<_73>
Ok the thundering herd problem makes sense.
<_73>
I am wondering though if Linux by default schedules threads executing syscalls with a higher priority then a thread executing in user space.
<zid>
why would it do that
<zid>
surely that's the opposite of what you want
<zid>
the 'user' thread has stuff to do, the blocked thread is obviously stuck with nothing to do
HD36079 has left #osdev [Leaving]
<zid>
wait for whatever IRQ to happen that unblocks the blocking thread (data arrives from the network or hard drive to resolve the read() or such), and either wake that thread up, or just mark the data as 'arrived' and the next time you look at the threads, the user thread will have ran 'too much' and the blocked one will wake up because it is now able to
<_73>
So when the syscall thread goes to do something that takes a while like a read/write it will be blocked, I see.
<zid>
ever written.. user applications?
<zid>
getchar(), read(), etc?
<_73>
Yes
<zid>
they don't just do while(1); if there's no data and your program fails
<mrvn>
zid: the question is if, when an IRQ wakes up a process stuck in a syscall, the kernel switches to that process.
<mrvn>
I do that depending on the remaining time slice of the process
<zid>
Like, 90% of the programs running on my desktop are using 0 cpu, they're stuck blocking on some resource like a message or mouse click or whatever
<zid>
no point running them if running them means they'd be broken cus the data they asked for isn't there
<_73>
Why would a blocked thread scheduled with a high priority negativly effect system performance?
<mrvn>
_73: while(true) getchar(); would DoS your system
<zid>
'poor system performance' in this case meaning, more cpu power was required than you had in order to keep things running in 'realtime'? They're not running, how are they using cpu time?
<zid>
They're specifcally *not* doing a while(1)
<zid>
They're just not running
<_73>
mrvn: Ok this example will be useful for me to spend time considering
<\Test_User>
"higher priority, not ignoring the blocking state and running them anyways"
<mrvn>
_73: giving a process stuck in a syscall higher priority makes sense, until they keep running syscalls all thetime. Hence why I only prioritize them when they haven't exceeded their time slice.
<mrvn>
_73: In luinux the behavior probably depends on whether you compiler your kernel as preemtive or not.
<Andrew>
\Test_User: Speaking of that, are you going to have processes in your OS? And if so, preemptive or coorporative?
<_73>
Ah I see, so surely the timeslice must be less time then say a disk read, right?
<mrvn>
And the recommended setting is totaly contrary to what you might thing. Desktops, where you want faster reaction time, should not preempt, which should improve reaction time. It's totaly backwards in linux.
<\Test_User>
Andrew: processes yes definitely, I like multithreading/etc too much to leave it out of mine :P
<\Test_User>
preemptive vs cooperative I haven't looked at yet though so idk
<mrvn>
_73: a disk read takes no time, that's just waiting for the disk.
<Andrew>
If I have processes in my system it's definitely going to be coorperative
<_73>
well I should say the time for a disk read to return
<mrvn>
Andrew: Nobody has cooperative processes. Everybody has some measure of preemptive.
<j`ey>
Andrew: if you dont have processes, how else is stuff run?
<zid>
who needs processes when you can just launch your OS via one command line option per core
<zid>
that tells it which code to run
<Andrew>
j`ey: * processes in the traditional sense; "How else" is basically like how emacs works
<Andrew>
zid: You launch OSes with command line options ... what
<j`ey>
thta doesnt really explain anything
<zid>
Andrew: That's how linux and windows both work
<zid>
??
<j`ey>
Andrew: yes? like linux etc has command line options
<j`ey>
root=/ etc
<Andrew>
Multiboot stuff, ah
<zid>
nothing to do with multiboot
<zid>
both linux and windows take options, that's all there is to it
<Andrew>
Alright - who passes the options?
<heat>
the bootloader
<heat>
even UEFI can pass you options
<zid>
how do you think safe mode happens in windows
<zid>
or debug mode
<heat>
how you get them depends on the boot protocol of course
<zid>
it's literally just /debug
<Andrew>
I was thinking in very siple (MBR) works
<heat>
the MBR code is part of the bootloader
<heat>
not the kernel
<_73>
With grub you can pass options by setting GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub
<Andrew>
zid: I don't use Windows, sorry I'm not familiar with what safe mode is, is it some kernel mode for reduced functionality and better dtability?
<zid>
my kernel options are root=/dev/sda1 fastboot net.ifnames=0
<zid>
yep
<heat>
Andrew, yes plus the whole system
<Andrew>
Ah
<heat>
lots of services won't start
<heat>
debug mode is debug mode :)
<zid>
and fwiw linux isn't even bootable with multiboot, it has its own custom 'linux boot protocol'
<heat>
it's not even the linux boot protocol
<heat>
it's the linux x86 boot protocol
<heat>
every arch has its own
<zid>
right, there are many like it, but this one is mine
<heat>
it's ridiculously stupid but that's the way it is
<Andrew>
Is there something that makes it that I can't directly jump form the MBR to the kernel but I have to use a bootloader? I don't really see the point here - or it could just be that I have a wider definition of the kernel
<heat>
Andrew, you need to load the kernel
<zid>
a master boot record is just a concept
<zid>
what it does or doesn't do is up to what you put *in* it for it to do
<heat>
loading a whole kernel in less than 512 bytes is a challenge and a half
<Andrew>
Yes, I know that
<Andrew>
Uh
<zid>
The MBR is just a PC concept that the first sector on the 'boot device' loads to 7C000 and runs
<Andrew>
I mean
<\Test_User>
s/000/00/
<zid>
nod
<Andrew>
For modenr systems, the MBR loads the rest of the bootloader which loads ther kernel
<heat>
yes
<Andrew>
Yes, I know what the MBR is lol
<heat>
(modern x86 systems)
<zid>
Well you don't seem to
<Andrew>
But, not sure why the rest of the bootloader is really necessary
<\Test_User>
you'll typically need more than 512 bytes to do everything you want before leaving 16-bit mode and entering the kernel
<heat>
embedded stuff may very well have a lot more functionality
<zid>
because 510 bytes
<Andrew>
As it's basically jump jumping to the kernel
<zid>
is absolutely fuck all
<zid>
My OS lives on an ext4 partition
<heat>
Andrew, that's not it
<Andrew>
\Test_User: Oh, yes
<\Test_User>
Andrew: if you write a 16-bit kernel that still collects stuff from bios sure
<zid>
good luck parsing and loading my kernel from ext4 in 510 bytes
<zid>
it *has* to chainload more code
<Andrew>
That makes the point
<_73>
You need a bootloader for a splash screen :)
<Andrew>
zid: *your* kernel :P
<zid>
The code that it chainloads is *called* the bootloader
<zid>
It's irrelevent for anything but loading and booting, and isn't part of the kernel
<zid>
so it's called the bootloader, and is seperate to the kernel
<Andrew>
Ah, got it
<heat>
things you need to do in an x86 PC bootloader: get the memory map, get acpi data, get efi tables (if EFI), read disk, interpret the partition, read the kernel and any possible ramdisks and any possible config file, load the kernel into memory, maybe relocate it, set up boot protocol arguments, jump to it
<mrvn>
Andrew: the MBR isn't used to start your kernel on UEFI
<Andrew>
... yes
<Andrew>
Though, I don't use UEFI
<zid>
In 510 bytes. Also those 510 bytes might also need to be a valid partition header
<heat>
and then in ARM (sometimes/usually) the bootloader kinda fuses together with the firmware
<zid>
which cuts you down to like 40 bytes or whatever
<mrvn>
Andrew: The reason why you should use a bootloader is that you should not waste your time messing around in 16bit code or caring about bios vs. uefi.
<Andrew>
mrvn: Yeah, get that point
<heat>
in fact u-boot has its own UEFI implementation these days for Reasons(tm)
<Andrew>
"valid partition header", what
<zid>
We're loading code of a 'boot drive'
<zid>
not a raw hard drive
<zid>
it has partitions, filesystems
<zid>
If the filesystem or partitioning scheme we're using says offset 7 on sector 0 has to be 'B'
<Andrew>
Oh, I'm using raw hard drives, so yeah that doesn't really apply
<zid>
then you have to code around that.
<heat>
oh right! I forgot you need drivers for a bunch of stuff
<heat>
GRUB doesn't use the BIOS for example
<j`ey>
heat: instead of chainloading edk2 i guess
<Andrew>
Ah, hard drive drivers, eww
<Andrew>
and other drivers too, yup
<heat>
j`ey, yup. although chainloading edk2 is the least trivial thing ever
<heat>
UefiPayloadPkg has two separate chainloading solutions (coreboot and slim bootloader)
<heat>
totally incompatible
<j`ey>
I mean from uboot -> edk2, not edk2 -> something
<heat>
there's no "generic" solution besides maybe ripping off slim bootloader's interface
<heat>
yes.
<heat>
UefiPayloadPkg = UEFI/edk2 as a payload
<j`ey>
ohh
<heat>
there's no generic payloading interface unfortunately
<zid>
Andrew: understand why 'why a bootloader exists?' is a silly question now I hope? :p
<heat>
I don't know how generic slim's interface is, but it's pretty Intel/UEFI-ish, based on HOBs and whatnot
<Andrew>
zid: Yup, I forgot that normal kernels reside on filesystems
<zid>
well at least you took something away, sigh
<heat>
Andrew, also, networking!
<heat>
GRUB is a small modular OS on its own
<\Test_User>
Andrew: even without parsing that, just collecting everything you want for your kernel will take quite a bit of code
<Andrew>
zid: Yeah and more of because not messing with 16-bit stuff in the kernel and atuff
<Andrew>
\Test_User: "parsing that", ?
<\Test_User>
filesystems/partitions
<\Test_User>
well, everything you *probably want
<Andrew>
\Test_User: I'm worried about hdd drivers, not partition/filesystems because no filesystems (no explicit distinction between primary and secondary memory)
<\Test_User>
...no files is just insane
<Andrew>
I never said that I'm sane
<\Test_User>
fair enough
<heat>
that is very clear :D
<Andrew>
lol
<heat>
anyway booting is hard and in no way minimal
<heat>
don't forget that the *processor that boots your processor* also has its own OS
<Andrew>
Hmm, yes
<Andrew>
At least for the computers with ME and similar things
<heat>
like everything built in the last 10-15 years
<heat>
relevant stuff
<Andrew>
Probably a similar but still not-exactly-that way of doing things for my pre-ME intel x86s and the arms
<\Test_User>
amd was later to adding their version
<Andrew>
\Test_User: Yes, I know
<\Test_User>
I was talking to heat with that one Andrew
<Andrew>
ok
<heat>
ARMs also have coprocessors
<_73>
The "processor that boots your processor" is the BIOS correct?
<Andrew>
heat: I'm mainly working with older hardware, i.e. ThinkPad x60s
<\Test_User>
amd, not arm
<\Test_User>
not to say they don't have it now
<mrvn>
heat: anything but RPi doing that?
<heat>
clever can stockholm-syndrome-tell-you all about the vc4 and how it boots the rpi
<\Test_User>
but I'm saying they were later to doing it
<\Test_User>
_73: no, the BIOS is running directly on your processor
<Andrew>
yup
<mrvn>
RPi doesn't have a coprocessor for the ARM, the ARM is the coprocessor for the rest of the system
<heat>
mrvn, dunno, I don't have much ARM hardware
<j`ey>
heat: :'(
<j`ey>
heat: can i buy you an m1
<heat>
send me sum j`ey
* Andrew
looks into RISC-V and MMIX
<_73>
\Test_User: Oh ok
<Andrew>
MMIX code is the sanest code I've seen so far
<\Test_User>
"code"
<Andrew>
?
<\Test_User>
mmix is the hardware
<Andrew>
Code for MMIX
<\Test_User>
code for mmix can be written in multiple languages
<Andrew>
.... code that natively runs on mmix = the freaking binaries = basically we write assembly for those
<\Test_User>
I don't see how that's any more sane than the same for anything else; calling the arcitecture itself sane though fair enough
<heat>
j`ey, the macbook pro i'm getting for work is still an i7 :|
<j`ey>
heat: laaaame
<Andrew>
MacBooks, meh
<heat>
j`ey: send me the M1 together with the job offer
<heat>
kthx
<j`ey>
heat: heh
<clever>
heat: *waves*
<heat>
j`ey: I have a feeling they don't give out ARM macbooks for work because the software isn't built for ARM lol
<heat>
which, fair enough, makes sense
<j`ey>
change that!
<heat>
give me an SBSA + SBBR compliant board and I will
blockhead has joined #osdev
<j`ey>
i think ampere altra is
<Andrew>
\Test_User: Where's your repo?
<\Test_User>
for which
<Andrew>
Architecture
<\Test_User>
still just a few files of basic ideas on my local filesystem
<Andrew>
When you extend them please share it in #os
<Andrew>
Preferrably in a version-controlled repository
<\Test_User>
ye
_73 has quit [Remote host closed the connection]
dh` has quit [Quit: brb]
_73 has joined #osdev
archenoth has joined #osdev
gog has quit [Ping timeout: 246 seconds]
jeaye is now known as notjeaye
notjeaye is now known as jeaye
terminalpusher has joined #osdev
jafarlihi has joined #osdev
rpnx-phone has joined #osdev
<heat>
clever, what does the vc4 use as memory?
<mrvn>
the first 1GB of ram
<heat>
you need to configure that though
<heat>
does it cache-as-ram before that?
<heat>
and then can't the arm processor access it? isn't the vc4 supposed to be kinda a security boundary?
terminalpusher has quit [Remote host closed the connection]
jafarlihi has quit [Quit: WeeChat 3.5]
gamozo has joined #osdev
<geist>
i dont think so, i think it's simply the graphics thing
<gamozo>
I've never done NVMe dev before. How hard is it? Just a ring of DMA buffers and some basic commands?
<geist>
oh hey heat is ready to go!
<heat>
sup les noobs
<geist>
answer is yeah basically. it's fairly sophisticated, but looks also like it's fairly straightforward
<heat>
gamozo, sooooooooooooooooooo
<geist>
and you can get the specs for free
<gamozo>
Lets assume I want to only support 1 drive, not trying to be general purpose
<heat>
lets establish a "queue" as a tx queue and rx queue
<gamozo>
I recently got a fancy storage server and I am _not_ impressed with the performance I'm getting. I kinda wanna see what it can do if I control the whole stack
<heat>
(the tx and rx queues are mostly ring buffers of commands)
<gamozo>
I see
* geist
senses heat cracking their fingers
<geist>
(heat was just working on a driver)
<heat>
an nvme controller has an admin queue, where you send it admin commands like identify, identify namespaces, create_sq, create_cq, blah blah
<heat>
you get it. admin commands, no IO here
<heat>
then you have IO queues that do all sorts of IO commands
<heat>
READ and WRITE are the basic ones of course but there's a lot more fancyness in there if you so desire
<heat>
your NVMe drive needs to support the admin queue (always there, no need to create it) and a single IO SQ/CQ pair (as far as I know)
<gamozo>
Okay, doesn't sound too bad. Hmm
<heat>
it tells you how many queues it supports and then you create them
<geist>
yah the basic queue mechanism is pretty straightforward. and it can complete them out of order of course
<gamozo>
There's no middle-man between the drive and the processor right? You are directly talking to the drive over PCI?
<heat>
it also tells you the max queue size
<geist>
i forget how you cause them to be in order aside from draining the queues or sticking some sort of barrier in it
<heat>
gamozo, sí
<heat>
also, no
<heat>
it's complicated(tm)
<heat>
NVMe itself has no transport, you can do it over fabrics, over PCIe, over something else they make up 5 years from now
<geist>
basic nvme/pci is just that. theres some way to sream it over other things
<gamozo>
Why does it always have to be complicated? :( I just want to say "giff bytes real fast" or "set bytes real fast"
<gamozo>
Ahh, so NVMe is detached from the transport
<heat>
then you have the transport specs that tell you how NVMe behaves over fabrics, pcie, blah blah
<heat>
yes
<geist>
well, i poersonally think nvme is much more straightforward than most, however it's also modern and sophisticated
<heat>
yes, it's both
<geist>
so it's not trying to be simple per se, but it's conceptually simple because it doesn't have any backwards compatibility
<gamozo>
Yeah, that makes sense. I'm guessing it's all based on LBAs and queues, which to me is away easier than CHS and I/O ports :D
<geist>
absolutely
<geist>
and there's no link state or any of that nonsense
<heat>
also, if you go through the spec, some parts have slightly different behavior depending on the transport, some things are only supported in a single transport, etc
<gamozo>
Hmm... I really need to play around with this. I ordered some new 100gbe nics that I'm gonna be writing drivers for, and I really really wanna switch my storage server off of Linux
<heat>
oh yeah, nvme-over-fabrics time
<gamozo>
But maybe I need to just look at more complex solutions than NFSoRDMA + Linux
<geist>
ooooooh 100gbe nics
<geist>
do you have any docs for those? which ones are they?
<gamozo>
Yes!
<gamozo>
So I bought $3k worth of mellanox NICs, and now I'm dumping them for Intel NICs because they're open docs
<geist>
i'm curious how a good 100gbe nic does its own stuff
<geist>
wow is this for some work thing?
<gamozo>
and they're identical to the same model of Intel drivers you've written for all other Intel NICs (in fact, my 1g/10g Intel NIC driver should "work nearly out of the box")
<gamozo>
obviously, using the fancy features will require some work
<heat>
obviously gamozo is just flexing
<gamozo>
Nah, just a personal project :D
<geist>
that's a little surprising. i would assume that >=10gbe would probably switch to something a bit more efficient
<gamozo>
I like perf okay, and this is where I've gotten to now :D
<geist>
though intel nics are pretty darn efficient
<heat>
im mean tbf regular NICs are already pretty efficient
<geist>
heh well, i just bought a new mobo for my ryzen server
<heat>
ring buffer of stuff, lots of offloading, etc
<geist>
heat: yeah i just was thinking that even more high end ones would need to offload even more stuff
<gamozo>
it is nearly identical to the x540/earlier Intel datasheets. It's actually really cool
<geist>
heat: basically
<gamozo>
I'm pretty sure an e1000 driver would work as long as you maybe tweak some of the BAR offsets. But I think the same registers still exist
<geist>
anyway if you're familiar with those sort of work queues nvme isn't that different
<zid>
On a weird fpga network accelerator? that's confidence
<geist>
though a bit more aggressive about scatter gather,etc
<gamozo>
I have no idea what kind of PPS/throughtput you'd get without leveraging offloads. But honestly, if you have a super close-to-metal driver without much abstraction, you might be able to hit 100gbe? I don't think sequential is too hard
<geist>
since the intel nic buffer management is actually *less* sophisticated than most nics i've seen in the past
<geist>
gamozo: i think the design of your net stack almost instantly becomes the bottleneck
<heat>
yeah
<heat>
you're better off using dpdk
<gamozo>
I now have all the hardware, NICs, switching, and drives to make my dream of "100gbe saturated with 4 KiB random reads". But now I'm really being held back by software (NFS, Linux kernel, filesystem design). I really wanna see what I can do!
<heat>
although for instance cloudflare uses the linux kernel's stack so, who knows
<gamozo>
I got an AMD box where all the NVMe drives are direct to the processor, no PCIe bridge or anything fancy. So in theory, I should be able to linearly scale with drives (but I am not getting that with Linux)
<heat>
maybe the kernel's stack really is that optimized
<gamozo>
Yeah, I haven't tried any crazy tuning
<heat>
the big advantage of dpdk might just be that you can avoid user <-> kernel transitions
<gamozo>
Out-of-the-box NFSoRDMA has been very very slow for random access. Totally fine for large file transfers, but I want to do things like "grep a AOSP source tree", and have it saturate hardware. It's the random/many small files that really seem to struggle
<geist>
well, i mean i'm not going to try to talk you out of it, because at the end of the day this is a darn good learning experience
<heat>
yeah
<gamozo>
My dream goal is to not have any drives in my workstations, instead have them network mounted. But get great performance (read: native NVMe performance) for things like source tree greps (this is my common personal workflow)
<gamozo>
For sure
<heat>
realistically you'll fail, but you'll learn a lot
<geist>
i dont quite have that level of disposible income and/or i'm a bit more realistic in my endeavors
<gamozo>
That's what all this is about at the end of the day :)
<gamozo>
I'm really just here to get every ounce of juice out of my hardware. Largely to know what is possible
sonny has joined #osdev
<gamozo>
Less so than to make a viable product
<geist>
sure. and that's *totally* fun
<geist>
as i was telling people, *real* driver and hardware people this is what gets them up in the morning
<geist>
you write a driver because you want to make it work and work efficiently, and that's what gets you the dopamine hit
<geist>
everyone has a different thing that really makes them happy
<gamozo>
If it all works out maybe I'll try to convince a company to adopt it and maybe make a product :D I've already been really happy with my specialized hypervisor performance
<gamozo>
Exactly!
<heat>
hmm
<heat>
geist, what's yours?
<heat>
board bringup? cpu stuff?
<gamozo>
geist gets the dopamine hit every time he sees a new bootloader using LK
<gamozo>
:D
<heat>
:D
<geist>
gamozo: surprisingly no, honestly, or i'd have figured out a way to make moneies off it
<geist>
i'm much more into doing things than getting it done
<geist>
seeing Lk used in stuff is nice, but not a huge source of excitement
<gamozo>
Awhh, that's fair though
<geist>
i love doing deep cpu stuff. i really get a kic out of learning all the nitty gritty supervisor mode bits
<geist>
eventually you learn most of an arch which is why i switch to other arches
<gamozo>
What's your current arch of study?
vdamewood has quit [Read error: Connection reset by peer]
<geist>
i mostly spend my days thinking about arm and riscv
<geist>
though i had recently done some bringup on 68k
<heat>
i bet you get sad when thinking about x86
<geist>
hmm? why so?
<gamozo>
Good choices. I love RISC-V with a passion. I haven't touched the system side though, only user-land design
<heat>
descriptor tables
<heat>
weird compat stuff
<mrvn>
I'm trying to convert between std::array and std::bitset: https://godbolt.org/z/MdeTr6xfs How does the compiler not see that this is just copying 16bit from A to B?
<bslsk05>
godbolt.org: Compiler Explorer
<geist>
heat: oh no. that's fun. almost the more gnarly the arch the more interesting it is
<sbalmos>
SPARC? Alpha?
<geist>
i just have been working with x86 for 30 years so there's not much interesting for me to personally learn about it anymore
<gamozo>
mrvn: Oh yikes ahaha
<geist>
i have owned a few of those, one day i'll go back to fiddling with
<mrvn>
to_array2 is verry interesting
<heat>
geist, ever done firmware?
<geist>
sure
<mrvn>
Why is the compiler doing a sign extend there by hand?
<heat>
that's probably a fresh take on the CPU
<geist>
but i also love writing kernels, or little blobs of free rnning code that have to deal with data over a long period of time
<heat>
(well, to an extent maybe)
<geist>
ie, kernels, filesystems, game engines, etc
vdamewood has joined #osdev
<geist>
that seems like intrinsically more interesting to me than run-once-and-stop sort of things: user space apps, even compilers/etc
<gamozo>
I think my favorite (albeit 15 minute project) was flashing "my own BIOS" on an Intel system. All it did was `out` to the PIT to play a sound on the PC speaker. But it was surreal to press a power button on a fully featured Intel workstation and _instantly_ it beeped. I've never had my code execute so fast on a big computer like that
<geist>
for no particular reason, just my preference
<geist>
gamozo: yep! thats a hard thing to describe, but i still, 30 years later, get a kick out of seeing exactly that sort of thing
<geist>
ie, building something out of nothing. being the first thing running on a thing, etc
<heat>
gamozo, that's totally fun but how do you recove your system after that? if you don't have a backup BIOS
<heat>
that's the thing that scares me
<heat>
unless you have an SPI programmer (?)
<sbalmos>
I got a kick out of firmware just because it was right at the hardware boundary to converting to electrons.
<zid>
ME fixes all sins
<gamozo>
heat: I actually uhh... desoldered my flash chip (8-pin flash), then crudly hot glued and soldered a DIP socket onto the motherboard, and then converted the surface mount bios flash to a DIP
<gamozo>
and I could just pluck it in and out, would re-program it physically. So I could recover/restore any bit on it
<sbalmos>
it's like when you /really/ understand that enabling an address line just energizes a wire to a set of transistors, and due to electron migration that's how a transistor lets through a signal, etc... build all that a billion+ times, and you somehow magically have logic
<gamozo>
I think I still have that computer
<zid>
a lot of my bios chips on mobos have been factory socketed
<heat>
sbalmos, that's still pretty far from the firmware though
<geist>
sbalmos: exactly
<heat>
at least x86 fw
<zid>
Lots of the little square holders where you pop the chip out from grabbing it
<geist>
there's a hard to describe enjoyment out of working at that level
<zid>
idk what they're called
<sbalmos>
heat: ture
<geist>
and i refuse to let people like heat and zid tell me it doesn't count :)
<geist>
there's always a 'well ackchyually' person
<sbalmos>
geist: it's why my degree is CSE. All the fun of hardware design and electrical eng without dual-majoring and having to deal with all that power electronics crap knowledge
<geist>
CSE is computer engineeering?
<heat>
geist, it's whats best described as "galaxy brain" time
<sbalmos>
Comp Sci Eng, ya
<sbalmos>
err rather more like Comp Sci & Eng
<heat>
true nirvana of understanding
<zid>
Fuck power electronics
sonny has quit [Ping timeout: 252 seconds]
<geist>
ah. mine is a differnt name but basically the same thing: computer engineering, but as taught by the CS department
<sbalmos>
huh interesting
<sbalmos>
yeah I'd always been told CS is the software side, CE is the hardware side
<geist>
they had a CS and EE track at the time. probably because the two departments hadn't yet decided who gets the degree
<sbalmos>
zid: What's a few blown caps and resistors among friends? :D
<zid>
power electronics are why HW dies
<zid>
true fact
<sbalmos>
heheheh
<geist>
funny i was just looking up what to replace REFA caps with
<bslsk05>
imgur.com: Imgur: The magic of the Internet
<zid>
does it need to be a gallery link
<zid>
I'd have to find chrome
<geist>
i see all thee videos of people doing it, but they never say what they replaed it with. i guess there's a modern equivalent of the same caps that just dont blow up
<mrvn>
Anyone an idea how to make the array <> bitset conversion more compiler friendly?
<sbalmos>
zid: yeah, don't ask how many 68HC12s and resistors I've /literally/ blown because I turned the knob on the bench PS one too many notches, and ended up putting 20V through it instead of 2V
<zid>
sbalmos: come fix my monitor, it needs new power electronics
<sbalmos>
gahd that was fun
<heat>
mrvn, memcpy and pray? :P
<mrvn>
heat: just acsting array and bitset to void*? urgs
<gamozo>
heat: Yeah! I have a TL866 which can program pretty much anything. It's like $80 on ebay + like 30-40 adapters for various chips. It has increased my confidence a lot
<heat>
i've slightly thought about getting open firmware on an old laptop but i'm just not qualified for it
<mrvn>
clang -O3 actually manages to optimize to_array2 perfectly. Just from_array2 is crap.
<gamozo>
I've lifted chips and firmware now off of pretty much all random things in my house. Printers, routers, my oscilloscope (eww runs Blackfin, hard to compile against)
<mrvn>
movzx eax, word ptr [rdi] which I find quite impressive
<heat>
1) can't desolder; 2) can't solder; 3) can't debug stuff; 4) No idea what's different from the reference platforms
<mrvn>
gamozo: have you found a use for any of those chips?
<heat>
i also have a big fear of fucking things up and ending with a bricked machine
<gamozo>
Uhh, so I had this dream plan to write an OS for my oscilloscope (common Rigol oscilloscope) and massively improve the UX/performance/remote data streaming. But when I found it ran blackfin I gave up
<heat>
> write an OS for my oscilloscope
<gamozo>
Mainly I just like to dump firmware and try to look for exploits and stuff :D
<heat>
cursed
<mrvn>
gamozo: play doom on your oscilloscope
<heat>
gamozo, you should look at edk2
<gamozo>
I drilled a hole in one of my printers and actually relocated the flash chip to an external socket. So you can hot swap the flash chip while the printer is fully assembled! :D
<heat>
it is neither fuzzed nor sanitized
<heat>
it's so :/
<gamozo>
mrvn: Ahaha, I really wanted to do something like that. But Rust can't target Blackfin (well, LLVm can't). Didn't want to write C. Although, I think rust's GCC backend might be stable enough at this point to use
sonny has joined #osdev
<mrvn>
gamozo: no need to compile anything. There is a doom version that outputs sound and your oscilloscope then draws the screen.
<gamozo>
heat: I've never audited edk2, that'd be fun :D
<bslsk05>
'Doom on an Oscilloscope (Tektronix 2220)' by MrSlehofer (00:05:10)
<sbalmos>
gamozo: Did my college cooping with Keithley Instruments, doing firmware for some of their bench scopes and high-end stuff. Working in Wind River for the high end stuff, but the bench scopes we ended up embedding a Lua runtime to execute sampler scripts
<sbalmos>
that was... interesting.
<sbalmos>
can't remember what processor it ran though
<mrvn>
Looks much better than quake on an oscilloscope too. Not sure if it's the game or the oscilloscope used.
<gamozo>
Hngggg that's awesome! I just got a Keithley DMM and it's honsetly the nicest piece of instrument I've ever used
<gamozo>
It's just so beautiful, great user interface, fantastic docs and programming interface
<sbalmos>
ya
<sbalmos>
which model?
<gamozo>
DMM7510
<gamozo>
I might get 1 or 2 more to add to my stack, right now I can only probe one thing. Would love to be able to do power analysis
<sbalmos>
geez that rings a bell. I think... was it a DMM750 series? Have to go look it up
<gamozo>
It's their main 7.5 digit multimeter model I think
<sbalmos>
yeah
<gamozo>
I bought it for doing hardware side-channel stuff where I care about super tiny changes in current, and needed good network data logging for long tests
<gamozo>
I love it. My nerdy friends and I love standing across the room and rubbing our feet no the carpet and seeing the instrument visibly pick up the data in the graph
<heat>
gamozo, last time someone enabled ASAN in edk2 it discovered a ridiculous amount of bugs
<gamozo>
ahaha
<heat>
it's... concerning
<gamozo>
heat: ugh, kinda not surprised. Lots of firmware/embedded stuff is really new
<sbalmos>
yup. my head hurt when I was first intro'd to the idea of a secondary signal ground probe when reading down in the pico/femtovolt range
<heat>
i want to see if I can get proper fuzzing going this summer as a side-project
<gamozo>
Sooooo I actually have a company that really wants me to start up their fuzzing team and really focus on being able to fuzz in weird places and embedded stuff. It sounds really fun
<geist>
FUZZ TILL YOU DROP
<gamozo>
Let me know if you have fuzzing questions. I normally do more one-off stuff, but I can always lend an ear
dude12312414 has joined #osdev
<heat>
gamozo, edk2 is like 22 years old. not new.
<heat>
it failed to adapt basically
<gamozo>
Really!? I always thought it was newish. Huh
<heat>
no lol
<heat>
it's the first (and the main) UEFI implementation ever
<sbalmos>
gamozo: gah! oh man, memory lane. TSB, the Test Script Builder. Yeah, my name's in a few of the contributor header comment blocks in there somewhere. LOL
<heat>
vendors just branch out from edk2
<gamozo>
sbalmos: That's awesome!
<gamozo>
I've only recently gotten into UEFI. I've written one UEFI OS. I like it, largely as it just normalizes a lot of annoying parts of boot. But I bet it's an absolute hack under the hood ahaha
<heat>
I had thought about using syzkaller to fuzz the APIs
<heat>
well, it's not a hack
ripmalware_ has joined #osdev
<gamozo>
I did (read: followed someones instructions) an EDK2 mod for one of my ARM64 dev boards to get Windows booting on it
<heat>
sometimes totally overengineered even
<heat>
it just has poor testing
<sonny>
gamozo: tldr boot process pls
<gamozo>
Someone had a patch that injected QEMU into EDK2, such that you could run an x86 video BIOS on an arm64 board
<bslsk05>
github.com: edk2-non-osi/Emulator/X86EmulatorDxe at master · tianocore/edk2-non-osi · GitHub
<sbalmos>
whoa
<gamozo>
that's the one!
ripmalware has quit [Read error: Connection reset by peer]
<j`ey>
bit crazy aint it
<gamozo>
yeah it was a patch set back then!
<sbalmos>
that's nuts
<mrvn>
I've booted Win95 on my Amiga.
<heat>
you know how we could've avoided this?
<heat>
efi bytecode
<heat>
just sayin
<gamozo>
I'm all for bytecode
<zid>
you mean EfiByteCode
<j`ey>
EFI_BYTE_CODE
<heat>
gamozo, you don't understand. this is a real thing
<mrvn>
and that was before emulators had good JIT.
<gamozo>
Can someone give me the EFI GUID for the EfiByteCode?
<gamozo>
;)
<heat>
gEfiByteCodeProtocolGuid
<gamozo>
Honestly I'm a huge fan of ILs and bytecodes. I wish software shipped in a super-close-to-native format such that it could be converted when you install it. I know, I know, Android kinda does this (but very poorly)
<sbalmos>
I just laugh/love how the FreeBSD bootloader is just Forth
<zid>
I love bytecodes
<geist>
yah re: running emulators to initialize video bios. i've seen various forms of that for various non x86 machines over the years
<gamozo>
I like to believe that in the future you can just run software on any arch and it's just fine
<zid>
As long as they're basically an arbitrary machine code, and not like "do complicated java thing"
<heat>
ask intel for the EBC compiler
<geist>
i used to have a PPC machine (Pegasos I think) that had a openfirmware based bios, but also did the emulator-to-initialize-vesa thing
<heat>
OVMF has the EBC interpreter built in :)
<\Test_User>
gamozo: sounds more like you want there to only be one arch in the future
<geist>
of course. as does ACPI, etc etc
<\Test_User>
the whole point of a different arch isn't to do... the exact same thing
<gamozo>
geist: Hmm. I think my G4 also uses openfirmware? Whatever has the white background-black text EFI shell. That was wild
<geist>
but my point is emulating a different arch because the rom is for it is an old silly tricky
<geist>
yep. that's openfirmware
<heat>
well an efi shell won't be openfirmware i think
<geist>
that's correct
<gamozo>
\Test_User: Not really. More just architecture-agnostic code. I don't care how many different ILs there are
<geist>
also iirc one of the X servers does it even on x86. i think it emulates a 8086 to re-run the video bios or something on some state transition
<heat>
yes they do that
<gamozo>
My security dream is shipping users IL, and users will randomize structure layouts and code layouts, and then turn on execute-no-read
<gamozo>
Would make exploitation really really hard
<\Test_User>
different architectures have different formatting and features, if it's the same code for the same results is it really a different arcitecture
<gamozo>
users meaning, the installer when you install the application
<geist>
yah we have an RFC and design in place to enable --X for arm64 in some cases
<geist>
it's a hairy mess though
<heat>
theoretically you can also have it in x86 server CPUs
<heat>
pkeys
<geist>
ah yeah, and that's intel specific right?
<j`ey>
--X?
<j`ey>
ohh RWX, --X
<heat>
geist, I believe so, at least for now
<geist>
j`ey: execute only
<gamozo>
\Test_User: It's mainly just getting people in the mindset that the same code they compiled will run in different environments, which would encourage future-portable code designs. It's less about the standardization, and more about getting developers to adopt coding styles that allow for their code to be easily shipped on many targets
<j`ey>
(thought it was a compile flag lol)
<geist>
ah haha. X-only
<gamozo>
Eg. a new arch comes out and you just re-compile with clang and it just works (barring some low level details). Arguably, this is the point of libc or an OS, but I don't think they do these things very well anymore
<geist>
you can do it on arm64 and i think riscv has the capability maybe? i should check, now that i am thinking about it
<geist>
but alas, arm64 has a bug in it that makes it not useful until later cores
<heat>
gamozo, EFI is done around those principles
<gamozo>
The fact that porting applications from gcc to clang was a big deal (because of GNU extensions) is insanely tilting
<geist>
one of the few straight up ARM spec bugs where someone forgot a detail
<heat>
geist, yes it does, iirc there's a read bit separate from the valid bit
<gamozo>
and to me, is a failure of our developer cycle :(
<geist>
heat: yah i think you're right. and IIRC the riscv version of SMAP/SMEP/PAN is pretty heavy hammered but works
<\Test_User>
gamozo: then that's simply a matter of the compiler's job, and fair enough
<geist>
ie, with the bit set supervisor mode simply cant access anything marked user, period.
<heat>
i thought it was fine
<geist>
right. that's sort of the most straightforward and hard to screw up version you can think of
<gamozo>
\Test_User: Honsetly, I think things like the ARM64 macbook have really helped this. I've been seeing a lot of applications (that ship binaries) now shipping with ARM64 on both Windows and OSX because of it. Which is nifty
<heat>
apparently I do indeed do execute only on riscv
<heat>
nice
<geist>
yep, just saw the same thing, i was trying to remember what the combination was for 'next table pointer' but it's ---
<geist>
so that makes sense
* kingoffrance
"the fact that porting applications from gcc to clang was a big deal (because of GNU extensions)" looks at big ball of c89 code. looks at gamazo. are you SURE you want to go there? <no> <no> "places where men fear to tread" -- frogurt guy
<geist>
they burned a bit for the valid bit but that's nice for other reasons
<heat>
what if --- was invalid and they had a separate huge page bit?
<heat>
I guess you'd still lose a bit but that sounds a bit saner
<heat>
at least more... normal?
<geist>
well one way they could have done it is used 3 bits, 000 is not valid and all the other combinations are RWX and one other invalid/not useful version of that is a next table pointer
<mrvn>
kingoffrance: what GNU extension doesn't clang have?
<geist>
but, having a separate bit 0 being V is useful for OSes that want to put stuff in an invalid entry, since they then have 31 or 63 bits to stuff what they want
<kingoffrance>
mrvn: ask crazy person gamazo :)
<heat>
mrvn, a bunch tbh
<heat>
also it ignores a lot of gcc options
<heat>
like straight up ignores
<heat>
-fcheck-new for instance
<geist>
iirc arm64 has i think 2 bits at the bottom, which is kinda a waste: something like valid + this is a terminal or non terminal entry
<bslsk05>
reviews.llvm.org: ⚙ D125272 [clang] Add -fcheck-new support
<geist>
so in that regard the riscv format is a bit more compact since you only need 4 bits to describe all of valid + permissions + pointer to next page table
<heat>
upstream is being very slow... yay open source
<geist>
but of course what it *doesnt* le tyou do is have heirarchial permissions, like arm and x86 have
<geist>
ie, having permissions on an inner page table node that take precendence on anything downstream of it
<j`ey>
heat: is that for work?
<heat>
i think hierarchical perms is a bit stupid
<heat>
j`ey, no. just something i really want
<geist>
they're great for safety purposes
<mrvn>
heat: sounds like a bogus option
<heat>
my kernel has been accidentally compiling without nullptr checks in clang builds *silently*
<heat>
you know, clang used to warn you about this
<heat>
but *they explicitly ignored it*
<heat>
this is a literal security risk
<mrvn>
heat: The check seems to be only for operator new that claims to throw but then returns nullptr instead
<heat>
geist, why? don't you just fail early on bad perms?
<heat>
mrvn, yes
<mrvn>
heat: so fix your damn new
<clever>
heat: the VPU can access the lower 1gig of memory, and the firmware places itself at the top $gpu_mem mb of that memory
<heat>
how about
<heat>
no
<clever>
heat: the hw is capable of blocking access from the arm, but that is not enabled on the rpi firmware
* geist
waits for the c++ discussion to die down
<heat>
new (std::noexcept) blah looks horrible
<mrvn>
heat: give me a compiler flag that gives a warning/error when new claims to throw but returns nullptr. That would be usefull.
<heat>
...
<j`ey>
heat: reply 'patches welcome'
<geist>
thats actually not always true
<geist>
patches welcome that line up with the pre-decided notions of how things should work are welcome
<mrvn>
heat: sure does look horrible but it's the right thing.
<j`ey>
geist: hehe
<geist>
heh i only say that because as a trite answer it's frequently not really true
<sbalmos>
void* bwahahaha = new (0x800000)EvilPointerClass();
<geist>
it's based on the idea that if you put forth energy any project will take what you give them
<heat>
mrvn, so. there's this option, it's useful, people find it useful, i want it, its a security risk if you don't have it
<j`ey>
geist: patches are welcome... to be rejected maybe :P
<mrvn>
heat: you should call it -fnew-nothrow
<heat>
.....
<mrvn>
heat: and then all the std::bad_alloc throws should return nullptr
mykernel has joined #osdev
<heat>
j`ey, i'm ok with a rejection, but a silent upstream is just frustrating as hell
<mrvn>
heat: I would love to have new/constructor behavior like you have with exceptions (stack unwinding etc) but return nullptr instead.
<j`ey>
yeah
<j`ey>
hopefully a few more pings will be enough...
<sbalmos>
Captain Ramius asked for one ping only though
<heat>
anyway geist how are hierarchical perms good for security?
<mrvn>
while(sleep(1m)) { if fixed then break else ping }
<mrvn>
sbalmos: newest gcc will warn about potential nullptr + offset access for that
<mrvn>
(annoying bug)
<sonny>
heat seems like the straigtfoward way to get RBAC
<heat>
hm?
<heat>
we're talking about page tables
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
jafarlihi has joined #osdev
<mykernel>
extern void f(uint8_t a[12]); // how do i write to this array in assembly
<mrvn>
mykernel: you write to it in C, compile and look at the objdump -d output
<mrvn>
and then you just keep the C version because doing it in asm is stupid.
<heat>
mykernel, it's passed as a pointer
<heat>
so you write to it normally, like a pointer
<mrvn>
mov.b #42, (a0)
<heat>
like mov $0xdead, (%rdi)
<jafarlihi>
How do browsers do rendering? Can something like GTK be used to create a respectable browser?
sonny has quit [Quit: Ping timeout (120 seconds)]
<heat>
they use tons of opengl, vulkan, d3d
<heat>
not gtk
<mykernel>
ty
<sbalmos>
don't forget the JS+DOM engine
sonny has joined #osdev
<heat>
gtk draws the normal UI widgets, window decorations, but not the HTML
<heat>
mykernel, np
eroux has quit [Ping timeout: 258 seconds]
<jafarlihi>
heat: Will I be able to figure out how if I read a book or two on OpenGL and Vulkan?
<sonny>
page tables have permission bits (on intel64), but it seems like there's other stuff on other arches
<bslsk05>
en.wikipedia.org: Skeuomorph - Wikipedia
<geist>
does that let you pilot your mecha with more efficiency?
<sonny>
"Less than a week after the initial version of the code was written, the project's website was attracting tens of thousands of visitors per day." -- That's a lot, especially since this paper looks old
<geist>
you can frag the Zentraedi invaders with more effectiveness
<heat>
"Competitive video games and operating system development as an interface for eternal anger issues"
<sonny>
apple bring Forstall back pls
<heat>
intel bring itanium back pls
<sonny>
heat: are you prepared to write the compiler?
<heat>
it's not the arch we deserve but it's the arch we need
<kingoffrance>
re: doom it makes sense, would you trust a sysadmin who is not a bofh :)
<sonny>
oh I learned some risc architectures have micro-ops
<heat>
sonny, backport gcc 10's itanium support
<sonny>
what a surprise
<sonny>
gcc 10 had itanium support!?
<heat>
yes
<sonny>
so I guess itanium is the arch we need if it doesn't have micro-ops
<sonny>
heat: to think there's still servers running that stuff
<bslsk05>
github.com: am01-assembler/lex.c at master · jafarlihi/am01-assembler · GitHub
<zid>
He just likes to hear himself talk
<sonny>
lol
<sonny>
a memory allocator is a good exercise
<heat>
i tell you to focus on something and you go off and look at something else
<heat>
focus on something
<heat>
you're not galaxy braining here, there's no way to get a good idea of how a whole operating system works if you haven't written any of it yet
<heat>
theory is useless
<geist>
heat: yeah there's a whole architype for this one
<geist>
have seen this sort of person come and go on the channel
<sonny>
heat: worked for me :P
<gamozo>
I mean, if a lot of os developers are stubborn, does that not mean stubbornness is the key to os dev?
<geist>
knowing some theory is useful, but it is some tiny slice of the pie. it doesn't *do* anything on its own
<geist>
you have to do
<heat>
gamozo, yes
<geist>
because it's a unrewarding hard slog at first, so you have to be stubborn and stick with it
<geist>
at least thats one aspect of it
<heat>
i got into it clueless and I stubborned my way through it
<geist>
if you keep flipping around tyring to find a simple thing to do you wont get started
<geist>
or if you constantly prepare to do the thing but dont just sit down and plow through it you also wont get anywhere
<geist>
however a stubborn osdev failure mode i've also seen folks here do over the years is essentially refuse to acknoledge that there is anything to help them, or rely on anything preexisting
<geist>
specifically "i'll start from writing a bootloader and fill in everything from there"
<geist>
or even worse "i'll start by writing my own programming language" or building own hardware, etc
<sonny>
xD
<sonny>
I making my own programming language
<geist>
or falls into "i'll make the best bootloader ever and *finish* it before going to the next step"
<zid>
Yea bootloader pergatory is pretty common
<geist>
that one i've seen many times. 10 years later they're still trying to build the best bootloader ever
<zid>
It's not even a single factor that causes it either
<zid>
Usually it's that they just have no idea what a kernel is or does, but a bootloader was the first 'step'
<geist>
right, yeah i'm not saying it's a failure mode to be stubborn, but it's a warning sign
<zid>
so they just make bootloaders all day instead, thinking they're progressing
<geist>
right the stubbornness is not listening to advice that it's not worth your time, etc. they usually retort with "yeah but i want to understand *everything*"
<heat>
well, it's a valid point
<heat>
*if* you're competent enough to write a bootloader
<kingoffrance>
there used to be a dolphin logo with an anchor. it meant you discuss/debate ...and then execute :)
<zid>
I remember when I couldn't have written a bootloader, because I didn't understand mmio or anything so once interrupts were gone I was lost
<zid>
err a kernel
<zid>
I could imagine sitting there writing bootloaders all day
<geist>
and it's not that there's something to be learned there, but it's a purgatory that is easy to fall into, because you end up immediately lost in the trees instead of seeing the forest
<zid>
Thankfully instead I just put 'osdev' as a concept away in my mind for when I was more experienced
<zid>
did some gameboy and stuff
<geist>
yah i remember when you were gameboying here
<zid>
Yea I came back to gaemboy, was really fun
<jafarlihi>
That's what I wanna do too but I haven't found my gameboy
<zid>
I ended up being the reference implementation for a few things on the gbdev discord
<geist>
woot
<zid>
because they were doing a project to convert the die shots at the time
<zid>
so a bunch of new bugs and behaviors were being found
<geist>
i remember being fairly excited about it because it was someone here actally doing something with ARM
<geist>
back before it became kinda defacto the thing other than x86
<sbalmos>
go emulate one of the old TI calculators with the amber digits that you had to hold the calculator at an angle to read
<jafarlihi>
We don't use TI calcs in third world
<geist>
yahs omeone here was doing a bunch of z80 work for their calc
<geist>
had some sort of DOS like thing on it
<geist>
(also a fun way to anger a gameboy original person: call it z80)
<zid>
It's A SHARP SOMETHING SOMETHING
<mrvn>
zBoy?
<sbalmos>
heh
<zid>
I don't even remember what it is
<geist>
zid: wait you were doing z80 gameboy or arm gameboy? i was thinking it was arm GBA stuff
<mrvn>
geist: avr gameboy
<zid>
gameboy advance
<zid>
is the arm7tdmi one
<zid>
NDS is arm7tdmi + ARM9
<zid>
I was doing gameboy
<zid>
I've fiddled with gba though
<geist>
yah, okay it was you then. there was someone here that was doing a z80 gameboy stuff and would get upset if you called it z80
<zid>
I have a linker script and stuff
<zid>
I don't get upset
<zid>
I don't even remember what the damn thing is
<geist>
anyway, fun times. i kinda wanted to hack on GBA, but too many other things to hack on
<bslsk05>
izik1.github.io: gbops - The Game Boy opcode table
<zid>
It's one of those, whatever one of those is
<geist>
yah it's some modified thing. not quite a z80 but it some superset of 8080 but etc etc
<zid>
yea it's sort of inbetween
<geist>
kinda a venn diagram where it overlaps with z80 somewhat which itself is an 8080 extension
<zid>
it's the z80 encoding, but with 8080's actual features
<zid>
no shadow regs etc
<zid>
It's either a stripped z80, or a built up 8080 in the style of z80
<geist>
yah honestly i'm not a huge fan of z80 or 8080. it feels a lot like all the bad parts about x86 except older and less functional
<geist>
but that's cause i didn't grow up with one and thus learn to love it, etc
<zid>
It's super clean for a little handheld though
<geist>
always been a pit partial to motorola style stuff, including 6502
<zid>
It's packed with nice bit operations via CB, and has auto-incrementing loads and stores etc
<geist>
yah
<jafarlihi>
NASM is 85 kLOC
<zid>
and given that 99% of what you do is twiddle bits and memcpy tiles around
<zid>
It's super tight and nice
<geist>
z80 is definitely much nicer to deal with than 8080 at least
<zid>
6502 is a fucking nightmare though, so crippled you have to software implement really basic things
<zid>
which was the alternative at the time
<geist>
yah that's why i say i thik it's just whatever you grew up with
<geist>
but in that whole line 6809 is super nice and pretty
<zid>
what's the weird 16bit extension one the snes used
<zid>
where they use the 6502 mode like thumb
<geist>
65c816
<zid>
650812823C16
<zid>
that's the one
<geist>
it's a mode switch basically, extnds the addressing out to 24 bits by adding some 8 bit extension reigsters and a few addressing modes that let you do long branches and whatnot
<geist>
and then extending the registers out to 16 bits
<zid>
yea I know about it
<zid>
That's how I brought it up
<zid>
I just couldn't remember the name of the cpu
<geist>
yah apple IIgs also had one too
<zid>
It's sorta what turned me off REing any SNES stuff
<geist>
not sure there was any other desktop computer like things with it, since even the IIgs was wayy too late
<zid>
because you can't diassemble it properly (it's not like you can do advanced static analysis with IDA)
<zid>
and I hate 6502
<geist>
I do like that it has a proper address extension, though you end up with some bank switching nonsense as part of your runtime to deal with it
<zid>
gameboy uses bank switching but people just treat it like x86 segmentation
<zid>
05:FFFF is just bank 5
<geist>
ah some hardware regs to set it?
<geist>
some latch to extend, etc
<zid>
not even that, the gameboy itself is unaware, but the cartridges respond to writes to the ROM by bank switching to that value's bank
<geist>
so question then is how does the bank switching logic deal with interrupts?
<geist>
or does it not bank the rom, and the first level vector is there, etc?
<zid>
Easy, not all of ROM gets remapped
<zid>
8k is fixed, 8k swaps
<geist>
ah and the fixed part is probably where the interrupt handlers and/or stack is located
<zid>
so you put all your 'game' in the 8k and swap the data and level bytecode around
<zid>
yup, z80's the same I think, there's a vector at 0, C, 14, etc or something
<geist>
right yeah okay. makes sense. was pondering another spin on my 6809 board and adding some sort of banking logic for that
<zid>
enough space for a cli jmp or whatever
<geist>
yah
<clever>
ive heard that some games used the rom mapper for animations
<zid>
RST 0, RST 8 etc opcodes exist to use them for SWIs if you want but nobody really bothers
<clever>
by swapping the rom banks, you can change the graphics for every sprite at once
<zid>
You can on NES but it's trickier on gameboy
<geist>
yep, CP/M had this whole complex scheme for that
<zid>
NES has bankable video memory
<zid>
gameboy just has bankable 'rom window'
<geist>
re: rom mapper animations, there are some great vids on the topic. if you ever saw a nes game with some sort of parallax scrolling in the background (and not just at the top or bottom) it was almost certainly doing some rom mapper swizzling of background tiles
<zid>
NES is super weird you do like, a serial link to the 'ppu' via an address register and a data register. That probably has a name.
jafarlihi has quit [Quit: WeeChat 3.5]
<zid>
gameboy just has the video memory in the address space instead. For NES you have to byte-stuff it into a single mmio reg.
<geist>
there's a great youtube line of vids ive been casually watching lately that go into all the details of this for all sorts of consoles, literally just watched one the other day on precisely that topic
<clever>
zid: nes also has a dedicated address space for the video rom on the cart, in its own rom chip
<zid>
yes, hence being able to bank switch the video memory
<zid>
because the PPU reads it over the same bus, so the cart can interpose
<zid>
and do whatever response it wants
<geist>
RetroGameMechanicsExplained is the channel. good stuff
<clever>
very
<clever>
was about to link one of his things
<zid>
yea I've seen a couple of those vids I think, windwaker's water may have been him
<bslsk05>
'TASBot plays Super Mario Bros. 3 by Lord Tom - Awesome Games Done Quick 2016 - Part 155' by Games Done Quick (00:19:06)
<zid>
the smw injections are the 'fun' ones
<clever>
this tas is just insane
<clever>
zid: and i can see the rightmost column being corrupted in this capture
<zid>
yup :D
<moon-child>
ahaha cute
<clever>
but coming up, its going to get insane
<mjg_>
is that the credit warp/
<clever>
mjg_: more like rewriting the entire game
<zid>
ACE got popular a while back
<zid>
You can do it in zelda.nes which is super surprising, by carefully organizing a bunch of ghosts' x and y positions then executing the OAM as machine code
<mjg_>
the crazy thing is that there are people who can pull it off
<mjg_>
pixel and frame perfect inputs for minutes
<clever>
mjg_: 9:53 is where it starts to go off the rails
<zid>
the smb3 ACE stuff is trivial
<mjg_>
ye, that's the wrong warp
<mjg_>
i mean end credits warp
<clever>
mjg_: no, look at 10:26
<clever>
he is using sudo in mario....
<mjg_>
lul it did not see that bit coming
<mjg_>
nice
<clever>
he didnt just wrong-warp, he injected custom code, and executed a custom app
<mjg_>
normally people "just" finish the game with this
<zid>
It basically memcpys from the multitap to memory for a bit
<clever>
zid: yep
<zid>
that's the 'payload' you build by manipulating OAM
<mjg_>
ye, i give it B- for effort
<clever>
11:30 now watch this....
<zid>
In OoT it's way easier because you can just execute your name
<zid>
which gives you a free ROP style gadget
<zid>
I know how the ACE actually works in OoT if anyone cares :P
<clever>
13:25, and now, the fixed auto-scroller
xenos1984 has quit [Read error: Connection reset by peer]
<bslsk05>
'Fallout Anthology by tomatoangus in 2:16:21 - AGDQ2020' by Games Done Quick (02:33:37)
<clever>
geist: and at ~16mins, they pass the controller to a human, with all of the hax still enabled, lol
<geist>
so the TL;DR gist of theses runs is using only controller input and bugs in the code it ends up keying in machine code and/or modifying existing stuff and hacking the game?
<zid>
yup
<zid>
The OoT one I know how to explain *please let me*
<geist>
sweet
<clever>
geist: the credits warp stuff, is basically an exploit that causes it to treat sprite xy coords as opcodes
<geist>
yah i saw some technical teardown of one of these, though i think in another game, but it was interesting
<bslsk05>
'Controversial New Glitch Destroys Ocarina of Time World Record!' by Karl Jobst (00:16:58)
<zid>
karl jobst is a nazi btw
<clever>
and if you position sprites at the right locations, you can key in a jump to the credits routine
<geist>
ah and hence why it's tossing a bunch of shells around to make sure the sprites are in the right spot at the time it enters it
<clever>
yep
<geist>
i think the glitch speed run of zelda BoTW is pretty great too, or at least one i watched
<geist>
lots of slingshotting yourself across the map into the lap of something
<zid>
are they still shield flying everywhere
<zid>
sounds like it
<geist>
oh i dunno, that was just the one i watched. probably be more elegant ones now
<zid>
If they were flinging themselves across the map the answer is just yes
Ram-Z has quit [Ping timeout: 255 seconds]
<clever>
there was another one for super mario, let me find it
<zid>
They used to use the timestop power and hit random logs a bunch of times and go like.. 100 meters at a time. Then they found out the equip system is mental and it slows down time when you hold the item menu up etc
<zid>
and found a way to get really dumb acceleration by falling and shielding
<bslsk05>
'Jailbreaking Super Mario World to Install a Hex Editor & Mod Loader' by SethBling (00:10:25)
<clever>
the 2nd one, is about corrupting your save-game in such a way, that it adds a hex editor to the game
<geist>
ah yeah that's the one i thik i had seen
<clever>
which then lets you key in a 512 byte "mod", that gets executed on every frame
<zid>
pokemon's ACE is like 20 y ears old now and basically uses a hex editor
<clever>
zid: skip to 1:39 in the 2nd vid, and youll see the hex editor
<zid>
the missingno glitch gives you 255 of like every item
<zid>
so you can just swap items in your inventory and toss certain amounts of them
<zid>
and now you have a huge block of perfectly controlled RAM
<zid>
because it's just item_id,count tuples
<clever>
i also remember generating custom cheat codes in emulators
<clever>
basically, you just input something like your current HP, and it runs a search for every memory location the number appears in
<clever>
then you change your HP, and repeat that search, to see what locations still match up
<clever>
and repeat until it only finds 1 location, that is the global var for HP, hard-code it to whatever you want
<zid>
yea that's really bog standard
<zid>
there were physical devices for it before emulators came about
<zid>
gamegenie, gameshark, etc
<zid>
gamegenie was interposed between the cart and cart slot
<clever>
those cant run the search, only force a certain ROM addr to return a certain value
<zid>
They absolutely can
<clever>
while i think the emulator stuff, is instead forcing the RAM to return a fixed value
<zid>
The cart is what the cpu is running, and the game genie interposes
<zid>
it can just suddenly start returning the machine code for a ram scna
<clever>
i think the gamegenie/gameshark can only use pre-designed codes, and you would need an emulator or disassembly to know what to even put into that code
<zid>
nope
<clever>
ive never seen such a gui in mine
<clever>
but maybe it was just an undocumented key combo
<zid>
exploder had loads of rad stuff
<zid>
it even had a TIM viewer to view all the texture files on the disk and stuff