<bslsk05>
github.com: toaruos/pic.c at master · klange/toaruos · GitHub
sprock has quit [Ping timeout: 265 seconds]
<zid>
I actually think the defines make it less readable somehow
<j`ey>
klange: what does that "BAD;" thing do?
<klange>
In what? The bad math library? If $LIBM_DEBUG is set, it prints a message to stderr recording the name of the unimplemented math function that was called.
<j`ey>
ah ok
elastic_dog has quit [Ping timeout: 265 seconds]
elastic_dog has joined #osdev
sprock has joined #osdev
<junon>
microsoft terminal is the worst piece of software I've ever had the displeasure of using
<hbag>
been making a shitty little microcomputer in my computer architecture class
<kazinsal>
junon: how so? the only issue I've ever had with it is that it's not pixel perfect with bitmap fonts
<klange>
what is "microsoft terminal"?
<hbag>
like command prompt but less shit
<kazinsal>
klange: `wt` I'm thinking
<gog>
conhost.exe
<klange>
Windows Terminal is a pretty solid piece of software.
<klange>
conhost is utter garbage
<junon>
windows terminal, yes
<junon>
and it freezes up on me
<junon>
all the time
<junon>
Like not the whole program. Just panes.
<junon>
If I resize the terminal a certain way, all of my panes for the current tab just stop responding.
<junon>
I can close the tab and start a new one, no problem. The app is otherwise responsive.
<zid>
cmd is also shitty
<zid>
all their terms are bad
<zid>
There was a 'making a fast terminal' that went into some of why though
<zid>
the backend they use for fonts and terminals is just terrible to begin with
<gog>
yeah that's conhost
<junon>
But there's no way to configure pane layouts and stuff so I have to delicately build up all of my `entr` stuff to get qemu to auto reboot and stuff each time.
<junon>
Annoying.
<junon>
No I don't use conhost
<gog>
right, cmd.exe does
<klange>
Are you running WSL instances in this?
<junon>
klange: yes
<klange>
(If the answer had been 'no', sadly you would still have been using conhost's backend bits, as native Windows console stuff can't avoid it, but I believe they get around it for WSL and WSL2)
<junon>
Right yes, because e.g. coloring and cursor positioning and stuff is all done via API calls
<junon>
not via stdio streams
<klange>
It's really quite a mess. WT itself of course natively supports parsing those sequences.
GreaseMonkey has quit [Remote host closed the connection]
<junon>
hence why libuv for node.js wrote a layer over the top of the conhost api calls
<junon>
It's really extensive (I contributed to it way back when)
<klange>
But the Windows console layer has the API calls... but then there's conversions available there as well... and it seems there's back and forth conversions happening if you have the wrong config options set in your app and are running it in WT...
<bslsk05>
github.com: libuv/tty.c at v1.x · libuv/libuv · GitHub
<klange>
Like in Kuroko, I got the ANSI output working in the general case, but I'm pretty sure conhost is converting that, and then converting it right the hell back for WT...
<junon>
Yeah I stopped caring about how windows does TTY stuff. They've been absolutely terrible with it.
<junon>
The early version of WT didn't have `bold` (x1b[1m)
<junon>
The response was "oh we forgot that" basically
<junon>
I maintain chalk and had to service like 10 bug reports regarding it. They were nice on the issue tracker but... come on. It's literally rendering mode 1.
<junon>
Out of 109.
<moon-child>
junon: deep down, in my heart of hearts, I hope to someday forget all the SGR escape codes
<moon-child>
I know it'll never happen though
<junon>
Yes me too
<junon>
I maintain that TTYs and escapes and all that are the most archaic thing still in widespread use these days when it comes to general programming.
<junon>
That haven't been updated, I mean.
<moon-child>
psh!
<moon-child>
try programming languages
<junon>
It's really hard to pin down exactly where half of them even came from.
<klange>
But they have been updated. Several times. That's how we got 256 and later 24-bit color.
<moon-child>
no new real advancements, in like 30 years
<junon>
klange those are xterm extensions, technically
nvmd has joined #osdev
<junon>
only 256 is really specified in terminfo, truecolor is not
<klange>
Those are widespread standards supported by everything.
<moon-child>
junon: termcap got truecolor
<junon>
They're not standards.
<klange>
terminfo is dead, everything either speaks a sufficient xterm subset or is best ignored.
<junon>
wat since when
<junon>
klange: I agree, I'm merely stating that the whole "standards" thing is shaky at best.
<klange>
It's like HTML5.
<junon>
Yes.
<moon-child>
html5 is one of the most nonsensical things ever
<junon>
Similar in nature. Standardization through ubiquity.
<moon-child>
it’s useless as a standard, since you can't rely on any particular behaviour from it
<junon>
moon-child: sauce on termcap supporting truecolor now?
<moon-child>
trying to find it
<zid>
4.01 strict for life
<junon>
that's news to me
<junon>
XHTML and DHTML thanks
<klange>
My editor bangs out escapes. It works in xterm, it works in VTE, it works in a Linux console, it works on ToaruOS, on Sortix, on BSD framebuffers, it works in WT, in Terminal.app, in iTerm 2.
<klange>
No terminfo, only a couple of escapes behind option flags.
<klange>
It'll work on a VT220 with the right colorscheme.
<junon>
yeah, the terminfo stuff was more for the days where baud rates were still something you had to worry about.
<zid>
DHTML is amazing, every website can have falling snowflakes during christmas!
<junon>
klange: yes because xterm is based off the vt220 :D
<junon>
in large part, at least
<junon>
and the vt100
<klange>
Yes, I'm aware of the history.
* junon
bows
<klange>
Terminfo and termcap are from an era when there were competing glass TTYs that had entirely different command sets.
<junon>
yes
<zid>
I prefer mechanical ones
<junon>
also it's a full blown scripting language lol
<klange>
And then the world moved on and everything has been based on those DEC command sets, and the core actually did get properly standardized under ANSI.
<klange>
And that ANSI standard has an ISO equivalent.
<moon-child>
junon: https://gist.github.com/XVilka/8346728#checking-for-colorterm mentions it 'Terminfo has supported the 24-bit TrueColor capability since ncurses-6.0-20180121'. The linked mailing list post doesn't seem to list it as a change, though
<bslsk05>
gist.github.com: True Colour (16 million colours) support in various terminal applications and terminals · GitHub
<klange>
And the irony is... Microsoft managed that and it had SGR 1 in it, so lol at them messing that one up :D
<junon>
Ahh yes COLORTERM, I thought you meant the terminfo database file format was updated.
<moon-child>
that is what I meant
<junon>
Oh right
<junon>
Actually this probably explains why a python library of mine broke...
<junon>
thanks for the heads up
gog has quit [Ping timeout: 256 seconds]
srjek has joined #osdev
nvmd has quit [Ping timeout: 265 seconds]
nvmd has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
dutch has quit [Quit: WeeChat 3.3]
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
nvmd has quit [Ping timeout: 252 seconds]
dutch has joined #osdev
<Ameisen>
I had a horrible idea for making an OS that runs on AVR
<Ameisen>
I suspect that it wouldn't run very fast, though
<zid>
well it's an AVR, isn't it mandatory that it runs slowly
nvmd has joined #osdev
nvmd has quit [Quit: Later, nerds.]
<Ameisen>
slowerly
<zid>
:D
<geist>
finally sat down to really implement the m68k MMU (at least the one in a 040)
<klange>
Something classic Unix-y like?
<klange>
geist: neat
<geist>
kinda annoying i gotta say: 4K or 8K pages, but 3 levels
<Ameisen>
I want to do something with the 68k, but getting set up seems painful
<geist>
and each level is 512 bytes
<Ameisen>
zid - it involves... at least two layers of emulation
<Ameisen>
since you need both instruction-level protection (so you can simulate user/kernel level code) and memory protection
<Ameisen>
so... yeah
<zid>
Only two? Sounds like you should step your game up and make it more slowerly
<klange>
Ameisen: Oh that sounds like how someone ran Linux on one of those embedded controllers that barely qualifies as a CPU by emulating a full ARM system.
<Ameisen>
I mean, the second level might itself need sort of a half-level of emulation as well if you want to use something like an SD card as a paging file...
srjek has quit [Ping timeout: 252 seconds]
<Ameisen>
klange: not too dissimilar. But still an AVR system being emulated.
<klange>
I think they also included DRAM control logic so they could actually have a viable amount of memory to work in.
<Ameisen>
and not emulating Linux.
<Ameisen>
I was considering basically mimicking a (very, very small) cache in sram, with an sd card as the backing
<Ameisen>
I always thought that jamming an m68k onto a board and making something like an Arduino would be neat
<Ameisen>
Arduinorola
<junon>
night all
<geist>
Motorino
<heat>
geist: do you always start out archs like that? just make a very small kernel to test the waters?
<geist>
yep
<Ameisen>
heat - past that, having memory protection or not wouldn't make too much difference; if I want multitasking, I'll need to abstract the memory somehow
<heat>
I should do that for riscv
<Ameisen>
what's wrong with a multitasking system that runs at 50 KHz equivalent, anyways?
<heat>
i eventually get tired of porting stuff
<heat>
Ameisen: linux runs multitasking without an MMU
<kazinsal>
I should probably just init a new repo for working on an x86-64 kernel core
<Ameisen>
Yes, but the AVR doesn't have enough memory to multitask meaningfully without paging.
<geist>
how much memory does it have?
* geist
is ready to type 'OMG THATS A HUGE AMOUNT XYZ DID IT IN LESS'
<Ameisen>
depends on the chip. the mega2560 has 8 KiB of SRAM
<heat>
OMG THATS HUGE
<geist>
OMG
<heat>
TWO FULL PAGES? WOW
<zid>
0.640k should be enough for anyone
<Ameisen>
problem is multitasking, you know, X processes are gonna want Y memory.
<Ameisen>
that fills up 8 KiB pretty quick :)
<geist>
8K is a bit tough if you have a standard preemptive threading system. mostly in that you probably have to burn a stack per thread so you can only really meaninghfully run a few stacks
<geist>
i've run LK in 8 or 16K and you can build a reasonable system, but just dont expect much more than 3 or 4 threads
<geist>
but you can build a fairly nice little preemptive system with that. a few threads to run a network stack, some blinkin lights, a ui, etc
<Ameisen>
geist - well, the processes themselves have to be virtualized (so there is instruction-level user/kernel protection), so memory access would be virtualized as well, thus my thinking that I could basically have a really tiny, crappy cache on the chip that pages in/out from a sd card
<geist>
you're leaving out that the 8K is just the RW part of mem. you have alot more rom in the form of flash
<geist>
what you dont have is a meaningful way to protect processes from each other
<geist>
that's generally the life of an embedded OS. you have to live withj the fact that everything can trash everything else. but you can pretend that there are multiple apps
<geist>
just different modules with their own threads and where things intersect there's some locks
<zid>
Just emulate six gameboys
<heat>
linux has FDPIC ELF to help out with that
<heat>
it also has XIP
<zid>
My solution is always to emulate a gameboy though
<Ameisen>
well, no matter what I have to virtualize the processes
<heat>
why no gamegirl? :(
<Ameisen>
the AVR cannot execute instructions from SRAM
<Ameisen>
once their virtualized, it's basically a thin VM
<Ameisen>
they're*
<geist>
yah what you want you really cannot do
<geist>
or.. you're better off emulating something that does
<Ameisen>
well, I can. It's just be really, really, really slow
<geist>
or emulate something bytecode, like run some lua apps or whatnot
<Ameisen>
I cannot emphasize how 'really' in the worst case
<Ameisen>
every memory access requiring paging out and paging in from an SD card
<kazinsal>
if it's that slow, is it worth doing?
<Ameisen>
of course
<geist>
you lose performance, but you get fairly nice modularity and can even protect things from each other
<geist>
every access from SD card is not going to work real fast. you can realistically only do a few thousand ops per second to a card
<geist>
so you're pretty quickly going to arrive at a 1khz machine
<Ameisen>
well, since I have to emulate things _no matter what_, I get protection since they effectively have their own instruction space, meaning they get their own address space if I want that.
<Ameisen>
yeah, I know
<Ameisen>
IIRC, the fastest you can get is something like 15 MB/s
<geist>
in that case you're far better off actually writing an emulator to work around your lack of executable space
<Ameisen>
when the chip is entirely dedicated to that
<Ameisen>
sure, I just thought it would be fun to have
<geist>
yah but that's throughput. the overhead of SD commands is fairly large
<Ameisen>
right
<geist>
the number of ops/sec is far lower
<Ameisen>
and it'd have to be done any time the cache line (I cannot imagine I'd have more than one) would need to be invalidated
<Ameisen>
which... would be often.
<Ameisen>
I do think it would be fun to write, though
<Ameisen>
and funny to run
<Ameisen>
if the quantum for multitasking is large enough, it might actually finish something.
<Ameisen>
could use an SRAM chip instead of an sd card, but it still needs to be interacted with over something like SPI
<geist>
i got an apple 2 yesterday
<geist>
it's a beaut
<kazinsal>
nice
<Ameisen>
I'd think if I did it, it would make sense to make a version without paging first, just to have a functional thing
<Ameisen>
not hard since any AVR binary knows exactly how much SRAM it requires
<geist>
also got a Type 2 conner drive
<geist>
20MB
<Ameisen>
the kernel itself would mostly be in program memory
<Ameisen>
dinner time
isaacwoods has quit [Quit: WeeChat 3.3]
<geist>
looks like it's a 820-0001-04, so a late model rev 1
Oli has quit [Ping timeout: 265 seconds]
Oli has joined #osdev
[itchyjunk] has joined #osdev
kanton has quit [Ping timeout: 265 seconds]
<heat>
geist: not sure if you know the answer but do zircon VMOs have an (internal) async get_page()?
<heat>
where async = give me a struct page, and do any IO in the background if needed
<geist>
inside the kernel?
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<heat>
yeah
<geist>
yeah you can get a page out of the vmo
<geist>
i think it's pretty much literally vmo->GetPage()
<geist>
there are a ton of options to that, basically telling it whether or not it should fault in a new one for you, zero fill it, do a copy-on-write (if needed), etc
<geist>
but the effect is 'do what you need to do to try to get me a pointer to the page, including causing this page to come into existance'
<heat>
I see some batching stuff
<heat>
might be that?
<geist>
well, remember the kernel has no notion of io. it doesn't do io
<geist>
so it's only dealing with pages at that point
<geist>
but pages may be in various states of transition though
<heat>
do you not do any sort of expensive filling of pages?
<heat>
i.e user VMO pagers
<geist>
yep, hence why get page may actually involve queuing up a transaction to user space
<geist>
but strictly speaking that's not io, i guess
<heat>
right now my vmos are completely synchronous which means that any IO operation on a specific VMO (of an inode) holds the lock
<heat>
which sucks for threading
<heat>
I know linux does a sort of a half get_page() where you get a struct page and then you have to check if its up to date, if not you do a futexy like wait on page flags
<heat>
definitely way faster when you have lock contention
<geist>
yah so the canonical example of where the zircon vm does a get page is a page fault: you hit some fault, it looks as to why, checks to see if it's a valid region, then drills into the vmo asking for a page so it can map it, and asks for it given the access method (ie, read or write)
<geist>
normally that's a plain demand fault, but it if it happens to be a user pager backed vmo, or a COW clone of one then it may return 'nope i dont have it but i can block for you'
<geist>
there's a sort of complicated token you can pass in that it'll signal or block on
<geist>
tghat used so you can rewind out of the locks you have and then block
<heat>
i was thinking that maybe you could fit an async get_page() design with like C++ coroutines or a std::future-like thing where you just unwrap the return and be done with it
<heat>
at the very least until I may actually need to expose those tokens to user-space
<heat>
probably never since iirc linux's io_uring is just a separate thread
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<kazinsal>
turns out all I needed to convince myself to sit down and crank out some x86-64 code was these atrocious queue times for FFXIV
<klange>
I have no idea what you're talking about. [laughs from JP datacenter that has had no queuing problems]
Oli has quit [Quit: leaving]
Burgundy has joined #osdev
heat has quit [Ping timeout: 265 seconds]
smeso has quit [Quit: smeso]
[itchyjunk] has quit [Quit: Leaving]
smeso has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
ElectronApps has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
YuutaW has joined #osdev
YuutaW has quit [Quit: WeeChat 3.3]
YuutaW has joined #osdev
* CompanionCube
noticed GRUB+UEFI looked uglier on his new 1440p monitor. Then I got around twiddling with the CSM and stuff, the result is interesting
<CompanionCube>
You would think enabling the CSM would have gimped VBE and not GOP. You would also be wrong.
<CompanionCube>
Not to mention this behaviour is stupid when it iirc doesn't occur with a 1080p monitor. But checking with the old monitor would be Effort(tm)
<CompanionCube>
(also lol bios can't stretch to 1440p but could (i think) stretch to 1080p. 1024x768 is acceptable for that though, GRUB/boot efifb not so much)
<CompanionCube>
was somewhat perverse to see VBE GRUB having a better resolution than GOP+CSM GRUB, though.
<CompanionCube>
might also want to check if the connector matters...
sdfgsdfg has quit [Quit: ZzzZ]
<zid>
VESA > GOP sounds about right to me
<zid>
vesa's a thing the hardware's emulated fine for 25 years, GOP's some silly new thing bios writers have to do :P
<CompanionCube>
zid: it would make more sense if it was equally broken with/without CSM, but it's not
sdfgsdfg has joined #osdev
<CompanionCube>
it can clearly do 1440 both VESA and GOP, so it's not as if the higher res is verboten when needing legacy support, no idea how the CSM ends up botching it.
<CompanionCube>
(the monitor also provided me with my first actual need for xrandr lol)
GreaseMonkey has joined #osdev
<Ameisen>
geist - I'm guessing that even using external SRAM, I'll be limited by the interface (in this case, SPI most likely)?
<Ameisen>
annoyingly, atmega2560 and many of the boards actually DO have address pins (for memory banking) but they're usually not exposed on boards
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
CryptoDavid has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
<mxshift>
ATmega2560 has max Fosc of 16MHz. SPI max clock is Fosc/2 so your absolute best case is 8Mbit/s.
<Ameisen>
2560s generally run at 20MHz fine, they're clocked at 16MHz by default for backward compatibility
<Ameisen>
but yeah, 10 then
<mxshift>
I checked the datasheet which only guarantees up to 16MHz on 4.5-5.5Vcc
<Ameisen>
right, I've just never seen anyone have trouble running them at 20
<Ameisen>
higher than that it gets iffy
<mxshift>
I know they generally can go faster but I've never really tried running SPI at Fosc/2 in that mode
<mxshift>
paging at 1.2MB/s would be an experience
<Ameisen>
but, as was said earlier, it's not just the throughput but the latency of starting the operation
<mxshift>
hence why I said 1.2MB/s absolute max
<mxshift>
that's also not assuming addressing overhead
<Ameisen>
yeah, but it's also 12:40 AM
<Ameisen>
so my brain is tired
<Ameisen>
well, you're still working with programs that only use a few K of RAM _total_. 4 KiB @ 1.2 MiB/s is 3.26 milliseconds. Which is a long time.
<mxshift>
"paging" in this case is likely replacing all of RAM
<Ameisen>
given that a clock cycle is 62.5 ns
<Ameisen>
I was hoping to try to be a little bit more granular, but yes
<mxshift>
64B pages might not be so bad
<Ameisen>
the concept of talking about pages in regards to avr8 is weird
<Ameisen>
if the pages are too small, the scheduling for paging has to be smart if it needs to invalidate multiple pages, otherwise the overhead of starting an operation is going to become more significant.
<mxshift>
gets you ~6% addressing overhead assuming 4B SPI addresses. Transfer time would be 50us for a page.
<Ameisen>
that's reasonable. Most accesses are going to have high locality, as well
<Ameisen>
still slow, but not so slow that things would never finish
<mxshift>
may as well go fancy and have non-volatile RAM
<Ameisen>
I was looking at SRAM, but similar.
<Ameisen>
I was looking at a 1 MiB SRAM chip
<Ameisen>
SPI
<Ameisen>
err, 1 Mbit
<mxshift>
FRAM is non-volatile though
<mxshift>
with SRAM speeds
sdfgsdfg has quit [Quit: ZzzZ]
<Ameisen>
true, but does it being non-volatile help in this regard?
<Ameisen>
I suppose you could page out the OS's data to it and it would be retained upon reboot
<mxshift>
more novelty in that you can preserve running tasks
<Ameisen>
true
<kingoffrance>
ACTION reads scroll back terminfo termcap ansi escapes dont forget, ascii itself has DC1-4 "Probably the most influential single device on the interpretation of these characters was the Teletype Model 33 ASR, which was a printing terminal with an available paper tape reader/punch option" before glass ttys "These four control codes are reserved for device control, with the interpretation dependent upon the device to which th
<kingoffrance>
its like 4 pragmas!
<Ameisen>
hmm
<Ameisen>
8 Mb FRAM modules!
<Ameisen>
$40/ea though
<Ameisen>
'course, it only works if that particular page happens to be in the nvram at the time, not on the chip
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
<klange>
Hm, have there been any hardcopy ttys that supported DEC-style color escapes... or even any color hardcopy ttys at all... I know there have been typewriters with dual black/red tape...
<kingoffrance>
what are you saying, you would support hardcopy devices if color
<Ameisen>
mxshift - first step would be having a functional virtualizer and system overall. Paging can be implemented after that.
the_lanetly_052 has quit [Ping timeout: 240 seconds]
<klange>
kingoffrance: heh, I think most of my stuff needs better over-striking support than any hardcopy terminal could offer. Maybe `bim -C` could work :) but if I want to emulate that I can convert to HTML and print with a regular color printer.
<kingoffrance>
thats a good point; hardcopy inherently supports bold and underline at least
<kingoffrance>
just back up and repeat
<Ameisen>
the end question is: can DooM run on AVR
<kingoffrance>
there's just no "undo"
<kingoffrance>
write-only bold and underline
<klange>
There were typewriters that would strike with an erasing tape that _kinda_ worked.
<kingoffrance>
s/write-only/one-time.
<klange>
Maybe if you used a very solid ink, like a white-out paint...
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
xenos1984 has quit [Quit: Leaving.]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
the_lanetly_052 has joined #osdev
xenos1984 has joined #osdev
<kazinsal>
Ameisen: As far as I know there's no doom port for AVR, though someone did do a wolf3d-esque rendering engine for AVR that ran at about 8 FPS on an atmega328
<Ameisen>
that's surprisingly unbad
bradd has quit [Ping timeout: 256 seconds]
vladm has joined #osdev
<vladm>
Hello world! Hope everyone is doing well
<vladm>
How long does it take to develop a Unix-like kernel, no networking no multithreading, pretty bare bones?
vladm has quit [Quit: Konversation terminated!]
<kazinsal>
1d12+3 weeks
<zid>
I recon I could get it to take 800 weeks
<kazinsal>
minus your int modifier if you're skilled in Knowledge (Berkeley)
CryptoDavid has quit [Quit: Connection closed for inactivity]
xenos1984 has quit [Quit: Leaving.]
<Ameisen>
they waited a long time for a response.
<vdamewood>
What if you lack an int score?
<zid>
focus on breathing
<zid>
if you get distracted you might forget to
<kazinsal>
"Hi! I'm actor Troy McClure. You may remember me from such films as, You're Now Reading This In My Voice, and You Are Now Breathing Manually."
<bslsk05>
'Animaniacs - Useless Facts' by rainbowzzzzzzzz (00:01:22)
bradd has joined #osdev
someonejv[m] has quit [Quit: You have been kicked for being idle]
<geist>
well, if they can't wait around for 3 minutes to get a response.... probably not gonna have the patience for it
<Ameisen>
maybe they finished it in that time
vlad has joined #osdev
<vlad>
I'm still here guys, just turned off my IRC client for a bit.
<Ameisen>
impossible, that vlad had an m
<vlad>
Guess the only non-tongue-in-cheek answer is 2-3 months? fair enough
<vlad>
Argh the secret is out!
vlad is now known as vlad_
<geist>
it's all about how much you know already. someone that's done it before can probably make pretty good progress in a few weeks, if they're working full time on it
vlad_ is now known as vlad
vlad is now known as vladm
<vladm>
:)
vladm has quit [Client Quit]
sdfgsdfg has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
gog has joined #osdev
<kazinsal>
yeah it really does depend on what your prior knowledge is
<kazinsal>
if the lowest level thing you've touched is node.js you're gonna need more time than someone who's previously touched kernels
<klange>
You'll be happy to know that most kernels, even Linux, build faster than the typical `npm install`, though.
<immibis>
press [x] to doubt
<j`ey>
my typical npm install is ∞
<klange>
npm installs on some large projects have been known to reach into the hours
<klange>
A survey of Linux kernel build times averaged it at 2 minutes.
<kazinsal>
the proliferation of everything needing its own package manager is one of those awful things that makes me glad I touch kernels instead of any other kind of software
<j`ey>
2mins is pretty fast for Linux
<kazinsal>
I was looking at a friggin HTML5/CSS framework in the same vein as bootstrap and you needed to install it via npm
bauen1 has quit [Ping timeout: 256 seconds]
<klange>
That was back around 4.xx, but there's always tccboot to point to for crazy fast Linux kernel build times.
<klange>
I can do my whole OS in a minute. The long compiles are for the editor and interpreter.
<klange>
I regularly `make clean` and time fresh builds. Good to also make sure I haven't picked up any stray warnings.
<j`ey>
I build a most-modules-off-Linux in about a minute @ work, its good if youre switching branches and testing different patches
<klange>
I really should get my last few external build deps eliminated...
<j`ey>
what are they?
<j`ey>
gcc? :P
<klange>
Excluding gcc and binutils from my target scope at the moment.
<klange>
But one day ;)
<klange>
Binutils will go away first, I think, but I need to write an x86/64 assembler...
* kazinsal
meanwhile is contemplating reworking his network stack and userspace to run on top of misaka
<klange>
Actual targets are... xorriso (I have the starts of an ISO builder in Python/Kuroko), mkfs.fat (EFI payloads, don't have any FAT tools of my own yet), Python's tarfile module (or more specifically, its use of zlib for compression, the actual tar writing is boring)...
<klange>
oh and mtools
<klange>
Strictly speaking, I should be able to build an ISO without EFI, and with an uncompressed ramdisk...
<j`ey>
at least those tools are not very, cant think of the word. theyre "important" but not super "integrated" into the build
<bslsk05>
twitter: <astarasikov> Pixel 6 pro bootloader (LK) contains a debug table with function names. Not DWARF so Ghidra won't pick it up but not that hard to write a parser. Even more info than one can typically get from prints https://pbs.twimg.com/media/FF-dZqoXwAIZMVG.jpg
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
m3a has quit [Quit: leaving]
zaquest has quit [Remote host closed the connection]
<geist>
woot
<geist>
yah pixel 6 has LK all over it
bauen1 has joined #osdev
zaquest has joined #osdev
xenos1984 has joined #osdev
bauen1 has quit [Read error: Connection reset by peer]
dormito has quit [Quit: WeeChat 3.3]
bauen1 has joined #osdev
[itchyjunk] has joined #osdev
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #osdev
dormito has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
the_lanetly_052 has quit [Ping timeout: 265 seconds]
the_lanetly_052 has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
the_lanetly_052 has quit [Max SendQ exceeded]
the_lanetly_052 has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
CryptoDavid has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
pretty_dumm_guy has joined #osdev
xenos1984 has quit [Quit: Leaving.]
dennis95 has joined #osdev
dennis95 has quit [Remote host closed the connection]
ahalaney has joined #osdev
xenos1984 has joined #osdev
ZipCPU has quit [Remote host closed the connection]
ZipCPU has joined #osdev
bauen1 has quit [Ping timeout: 265 seconds]
bauen1 has joined #osdev
gog` has joined #osdev
lleo has joined #osdev
CryptoDavid has quit [Quit: Connection closed for inactivity]
heat has joined #osdev
dude12312414 has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
isaacwoods has joined #osdev
srjek has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
dude12312414 has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
YuutaW has quit [Ping timeout: 265 seconds]
YuutaW has joined #osdev
ElectronApps has quit [Remote host closed the connection]
heat_ has joined #osdev
heat has quit [Ping timeout: 268 seconds]
heat_ is now known as heat
srjek has quit [Ping timeout: 265 seconds]
gog` has quit [Read error: Connection reset by peer]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<zid>
okay advent 7 pretty easy, just bruteforced it naively in a few ms so presumably intended
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
[itchyjunk] has quit [Read error: Connection reset by peer]
lleo has quit [Ping timeout: 265 seconds]
heat_ is now known as heat
heat has quit [Ping timeout: 265 seconds]
<junon>
okay so I am setting up my x86-32 ISRs right now. After everything is loaded in my kernel init procedure I do a divide by zero just to test isr0. It correctly jumps to it, and then to my generic ISR thunk which I've more or less borrowed from here: http://www.osdever.net/bkerndev/Docs/isrs.htm
<bslsk05>
www.osdever.net: Bran's Kernel Development Tutorial: Interrupt Service Routines
* zid
waits for 'but then everything goes wrong'
<junon>
However upon executing the common stub for isr0 I get a GP on the line `mov %ax, %ds` (GAS syntax)
<zid>
:D
<j`ey>
there it is!
<junon>
which jumps to isr 13
<junon>
which jumps to the stub again
<junon>
which of course triple faults
<zid>
what cpl is your idt entry for that one?
<zid>
I think there's some bits for that there
<zid>
cus that looks like 'you tried to run an elevated priv instruction in ring3'
<zid>
I'll read the manual
<junon>
for isr0?
<zid>
yea, DPL
<zid>
of the IRQ1 interrupt, int 13?
<zid>
33?
<zid>
IRQ0*
<zid>
32 in a normal pic setup
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<junon>
I'm still a bit confused with all of the numbering stuff, I have 32 (0-31 inc) ISR entries in my idt
<junon>
those are the exception ISR handlers
<zid>
oh right I'm dumb
<zid>
it's not an irq at all is ti
<junon>
null division is isr0
<zid>
INT 0 is div by 0 always
<junon>
no, exception routine
<junon>
yes
<junon>
flags are 0x8E
<zid>
but yea, what's in that IDT entry
<zid>
specifically, the selector bits and dpl bits
<zid>
and the qemu info for the fault would be useful
<zid>
-d int
<junon>
selector is 0x08, flags are 0x8E.
<zid>
old_checkexception: 0xffffffff new 0xd <regdump>
<junon>
I'm not sure what you're asking me :D
<zid>
are you using qemu
<junon>
I'm stepping through via qemu's gdbserver
<junon>
yes
<zid>
run qemu with -d int
<zid>
it will print the interrupt to the monitor
<zid>
along with a register dump
<zid>
you will get some spam from SMM, so the part you want starts with old 0xfffffff new 0xd
<zid>
I don't understand 0x8E as flags btw, that byte is present, dpl, 0D110000xxxx
<zid>
where x is reserved
<zid>
for an interrupt gate
<junon>
qemu is just sending me matrix-like spammy output to my terminal in an endless loop when I do that
<junon>
-d int
<junon>
do you just want a reg dump? I can have gdb do that
<zid>
No
<zid>
it prints the fault info too
<zid>
If you're getting interrupt spam, then something is still serving interrupts after the triplefault, is it boot looping?
<zid>
-no-shutdown -no-reboot
<junon>
I'm using -display curses which I think is part of the annoyance
<junon>
but yeah it's boot looping even with those two flags
<zid>
-monitor stdio
<zid>
is what I use
<junon>
qemu-system-i386 -display curses -no-shutdown -no-reboot ./oro.iso -d int
<j`ey>
why 32-bit anyway?
<zid>
I skipped 32bit, kinda glad
<zid>
pmode is more messy with the idts and gdts and stuff
<zid>
but it's mostly the same
<junon>
there we go, -display none -monitor stdio
<zid>
-monitor stdio <3
<junon>
now it's just dumping a TON of spam, I wonder if it'll stop.
<junon>
still going.
<zid>
it should print like.. 10 SMM interrupts during boot, then anything after that is on you
<zid>
what's it printing, faults?
isaacwoods has quit [Quit: WeeChat 3.3]
<junon>
no idea sec
<junon>
just the same thing over and over again with some counter increasing
<zid>
why is it that sometimes your first exception is a gpf and sometimes a divide by zero?
<eryjus>
zid, different cores?
<eryjus>
0: vs 3: ?
<zid>
oh wow
<junon>
the first check_exception is 0x0, the past above I sent was further down in the log and I didn't realize I hadn't copied from the beginning of the check_exception
<zid>
you set up smp already!?
<junon>
No
mahmutov has joined #osdev
<zid>
why 3: then *very confuse*
<zid>
let's just go with the core 0 taking a divide by zero first then..
<zid>
Oh that's really really short compared to the amd64 version of these dumps, hah
<junon>
the 3: 4: 5: etc. just incremental infinitely
<junon>
is there a way to ask qemu to dump that in the tcp shell?
<zid>
your ax value is wrong
<junon>
0x10 is the kernel data selector from the GDT
<zid>
f the fault condition was detected while
<zid>
descriptor; otherwise, the error code is 0.
<zid>
loading a segment descriptor, the error code contains a segment selector to or IDT vector number for the
<zid>
this says ax=ff50
<junon>
Oh wait :C
<zid>
lemme check that reg dump
<junon>
gas syntax
<zid>
..eax = ff53
<junon>
mov 0x10, %ax // kernel data segment selector
<junon>
can you spot the error
<junon>
:D
<zid>
no cus I don't trust myself to read gas
<zid>
I always use intel because I make massive and constant mistakes in GAS
<junon>
missing a $ before the 0x10
<zid>
set disassembly-flavour intel
<zid>
is that a load from [0x10] or something
<junon>
probably
<zid>
set disassembly-flavour intel
<junon>
is there a way to make clang/gcc accept intel syntax? I hate GAS too.
<zid>
-Mintel for binutils
<zid>
-masm=intel for gcc
<junon>
no wayyyyy you're kidding me. I've been fighting with gas syntax for a few weeks now.
<junon>
Thanks
<zid>
.syntax intel,no_prefix or something for .S files as a directive
<zid>
might need to google the exact right thing for that last one
<junon>
I guess it never occurred to me I could adjust that, figured gcc hard-required GAS
<zid>
I swapped my project to intel defualt the moment I coudln't figure out how to do a long jump
<zid>
in gas syntax
<eryjus>
zid, easier to do an iret
<zid>
turns out you just can't, in long mode, btw
<zid>
You have to iret, but if you write iret you get the wrong thing, you have to write iretq
mahmutov has quit [Ping timeout: 265 seconds]
<zid>
so it's a pretty messy situation if you've not done it before :D
mahmutov has joined #osdev
<zid>
junon: well, the fault was easy in the end at least, and hopefully you learned a bit about your tools..
<eryjus>
still forget that damned q... related to that, several bugs i have had
<junon>
yes, thank you so much zid
<junon>
Learned a lot :)
<zid>
I was fully expecting your idt entries to be fucky, surprised it was a code bug
<junon>
the next problem is that it's jumping to the wrong spot but I think this is a problem with gas again
<junon>
I need to do `call eax` but gas pukes at `call %eax` about unsized something or other
<zid>
yea you need *eax
<zid>
in gas syntax
<junon>
so I did `call *%eax`
<zid>
that's one of the major inconsitencies in gas syntax
<junon>
no I made sure my idt entries were correct and even stepped through the lidt instruction to make sure
<zid>
bochs actually has a dump idt command
<junon>
but anyway, `call *%eax` jumps to some random point in memory, gotta debug that.
<zid>
qemu lacks some of the more specific x86 interrogations sadly
<zid>
okay so check the value of eax
<zid>
and what's at [eax]
<zid>
if you're jumping to what's at [eax] we know the issue
<zid>
and just switch gdb to intel and make it disassemble that address :p
<junon>
oh man this is another gas thing isn't it
<junon>
I have a label that is the `.global func_name`
<junon>
and then `mov func_name, %eax`
<junon>
the disasm is 0x101131 <isr_thunk+22> mov 0x101b90,%eax
<junon>
it also needs the $ in front of it
<zid>
nice
<junon>
but how do you do that in gas? >.>
<zid>
(fuck gas)
<zid>
offset
<zid>
afaik
<junon>
man I'm converting this to intel after I get this working lol
<eryjus>
convert it and then get it working. lol
<junon>
oh wow you can just do $func_name?
<zid>
exactly what I did, "I need like 10 lines of assembly here I can just do it in GAS"
<zid>
8 bugs later it was all in intel
<junon>
yeah that's annoying
<j`ey>
junon: but still.. why 32-bit?
<zid>
why not?
<junon>
massive bug surface area.
<zid>
Until he wants to set up paging it's the same :P
<junon>
same boat.
<zid>
Just.. very slightly grottier
<zid>
cus more of the fields matter
<junon>
j`ey: getting my bearings.
<j`ey>
junon: I see, so you plan on doing 64-bit once youre more up to speed?
<j`ey>
I mean, if you want to do 32-bit it's fine, just wonderng!
<junon>
I started down the osdev road about 10 years ago and didn't get serious about it until about 2 years ago. 10 years ago x86-32 was all of the documentation I could really find for a beginner.
<junon>
yep
<junon>
It will support both.
<eryjus>
junon, did the same thing and last year finally threw in the towel on 32-bit. do it sooner than later -- it's not all that different
<junon>
I know x86_64 is simpler, but getting 32-bit out of the way first lets me build on what I already know about it, and also teaches me about the tools I need to develop with today anyway.
<junon>
So seemed logical.
<junon>
eryjus: yeah. the project structure already has the differentiation between the different archs so 'porting' it should be simple project-wise.
<eryjus>
awesome. But i stand on my prior statement... adding the additional arch will expose more bug than you can even imagine
<junon>
eyyyy there we go
<junon>
"FAULT: 0"
<junon>
expected output
<junon>
Yeah I'm sure it will, I'm okay with that.
<junon>
At least I have a clear design for all the pieces though
<junon>
:)
<junon>
okay looks like interrupts are working as expected, thanks everyone. Massive help <3
<zid>
64bit has issues with toolchains fwiw
<zid>
it's MUCH harder to get an image made and booting
<junon>
how so?
<zid>
grub only supports 32bit elf
<zid>
and embedding 64bit stuff inside a 32bit elf is doable but requires a bunch of binutils knowledge
<zid>
and can confuse various tools
<eryjus>
use grub2
<zid>
I still support grub1 I just provide a chainloader
<junon>
I believe I'm using grub2.
<junon>
how can you tell? the two grub commands I'm using are `grub-file` and `grub-mkrescue`.
<zid>
did you get it from your package manager? recently?
<bslsk05>
imgur.com: Imgur: The magic of the Internet
<clever>
the keyboard has a tx and rx line
<clever>
the mouse had a dedicated tx (mouse->host) line on the same connector
<clever>
the keyboard will then passthru the mouse signal and power
<clever>
so you plug the mouse into the keyboard
<Alpha2023>
I'm a big fan of the way ADB worked for that same reason
<clever>
its still a passive splitter, but the splitter is built into the keyboard
<Alpha2023>
my initial thoughts are "IBM designed the PS/2 connector like this on purpose"
<Alpha2023>
the original XT/AT connector was 5 pin. They intentionally made it 6 to support mice and keyboard at the same time for laptops
<junon>
Are PICs chips that exist directly inside the CPU? Or are they aux chips that live on the motherboard?
<clever>
junon: i think it used to be external, but has since become part of the cpu
<zid>
depends on the era
<zid>
IBM PC = PIC chips
<junon>
Gotcha
<zid>
desktop PC made within the past 30 years -> 400 gates inside some other chip -> legacy mode of the IOAPIC -> legacy legacy of the SUPER IO X2APIC LAPIC MMU BANANA
<zid>
etc etc
<junon>
So basically, the idea is that the x86 itself has a number of interrupt pins or something, and all they do is just fire off entries from the IDT. The first 32 are used internally for exceptions but can also be triggered externally. The PICs have some default mappings but the master defaults to 5-15 and the slave is mapped to 0x70 through 0x78 by default. The slave interrupts are fine but the master interrupts would otherwise conflict with the built-in exception
<junon>
interrupts, right?
<zid>
It has a little protocol it speaks
<junon>
So you re-program the PICs to not conflict, first and foremost, and then you can map them to whatever IDT entries you want
<zid>
where it gets an interrupt number
<junon>
Is that right?
<zid>
the PICs have 15 external pins (when chained) which can each have a device hooked up
<junon>
the CPU you mean? the I/O ports?
<zid>
and the PIC translates that into a little message saying 'irq 12'
<junon>
ah okay
<zid>
rather than the x86 itself having 255 pins exposed or whatever just for IRQs
<zid>
it has a little proto to send it numbers
<junon>
Right and rather than requiring every single device to speak that protocol the PICs are basically encoders
<junon>
are the pins on the pics just high/low signal gates?
<zid>
yea, edge or level should probably have come up at some point?
gxt has quit [Remote host closed the connection]
<zid>
they either go 'blip' or they hold the line high/low to signal
gxt has joined #osdev
<junon>
Not from the guides I'm reading. I'll go back and read the programmer's manual once I get some of this high level stuff figured out.
<junon>
But yeah that makes complete sense
<zid>
Just in general CS
<zid>
But generally it just needs a way to be told a thing, and to ignore that thing until it's ready for it to do it again, electrically
<zid>
which is doable just as a wire and something simple like "go high if you want me"
<zid>
try 'info pic' in qemu btw
<zid>
it dumps how the ioapic is set up in a bunch of rows
<zid>
'active-hi edge'
<junon>
Yeah okay, that makes sense. And yes I'm familiar with the line levels, at least at a rudimentary level. I haven't seen the terms come up in the guides I've seen though.
<zid>
rather than active-lo level, etc
<junon>
OH
<junon>
that's cool
<junon>
wow I had no idea qemu had such depth
<zid>
it has to know, technically, unless you want to like.. high level emulate IRQs
<junon>
you have to check with cpuid to make sure it is present, if you wanna be complete
<junon>
I remember reading that
<zid>
normal PIC is "active high" I think only, and only 8 pins, and you have to remap by adding a constant number
<zid>
you can't say 7 is 4 and 8 is 12
gxt has quit [Remote host closed the connection]
<zid>
anything you own has an ioapic
gxt has joined #osdev
<junon>
I see
<zid>
I was about to add ioapic code to my thing
<junon>
Is there a common use case for remapping individual ports instead of a constant number?
<zid>
bored of the regular pic and the LAPIC interfaces the ioapic better
<zid>
no idea :D
<junon>
Is there a way to tell qemu not to expose an ioapic, just a regular pic, if I want it to?
<junon>
Just out of curiosity
<zid>
recompile it without that printf?
<Alpha2023>
The XT class had one PIC, with IRQ lines 0-7, however intel designed the chips as cascadable, so you can have 8 PIC chips all feeding into the one connected to the INT pin
<junon>
haha but won't it still indicate it has an ioapic from the cpuid?
<zid>
couldn't you have a shit load if you were willing to chain them all off each other and ack the right set of 8394 pics?
<Alpha2023>
In AT systems, they implemented two PICs, the second was cascaded from INT2 and rerouted int2 on the bus to int 7
<Alpha2023>
Sorry not 7
<Alpha2023>
int 9
<Alpha2023>
so you have IRQ 0,1,3,4,5,6,7 and 8,9(2 on ISA bus), 10,11,12,13,14,15
<Alpha2023>
the APIC functionality is usually built into a chipset on almost every modern board, and fully supports being used as two standard PIC's
<Alpha2023>
however if you initialize the APIC, you lose the compatibility layer
<Alpha2023>
PCI buses have two types of interrupts: "legacy" interrupts that are the same as ISA bus -- Physical lines, and MSI (Message Signaled Interrupts) which are special pci packets tell the processor there's been an interrupt
GeDaMo has quit [Remote host closed the connection]
<Alpha2023>
standard MSI supports up to 32 interrupts, and MSI-X supports 2,048
<Alpha2023>
unlike legacy interrupts, the MSI interrupts are software assigned, which means you need to grab enumeration every boot
<Alpha2023>
side note -- LAPIC is the "local" pic in a multiprocessor system. it interrupts only a specific processor (or core) in a system
sprock has joined #osdev
<Alpha2023>
They can be used for signaling between different cores, which is kinda cool
<Alpha2023>
so you can imagine a system with APIC's as follows: each processor has an LAPIC. this is wired in a way that can send interrupts between cores, or to the IOAPIC.
<Alpha2023>
the IOAPIC then talks to the peripheral bus (PCI/PCIE)
<Alpha2023>
and the IOAPIC can direct any of it's interrupts to a specific LAPIC for handling
<Alpha2023>
using MSI however means you don't need an IOAPIC, since the messages get sent directly to the LAPICs and are decoded that way.
<junon>
woah
<clever>
2021-12-07 16:35:30 < junon> Right and rather than requiring every single device to speak that protocol the PICs are basically encoders
<clever>
junon: and this is probably where MSI comes into play
<clever>
i believe MSI is where you basically just configure the device to bus-master MMIO write into the irq controller
<clever>
so the irq wires are entirely done away with, and the device just bangs a control register on the irq controller chip
<Alpha2023>
any intel processor post the P54c (1996 pentium 5) will have an LAPIC on silicon, so you can use that for a low water mark
<zid>
I want a pentium 5 in 1996
<Alpha2023>
Pentium P5*
dutch has quit [Quit: WeeChat 3.3]
<junon>
I'm re-reading this a few times to fully understand
<junon>
so the IOAPIC is more or less 'legacy' with the advent of PCI 2.2
<junon>
or is it still useful alongside MSI?
<zid>
it's all legacy :D
<zid>
legacy all the way down
andreas303 has joined #osdev
<clever>
i think pci-e also did away with the irq pins as well
<Alpha2023>
yeah
<zid>
they still work in qemu? :p
<clever>
they are either emulated with a special pci-e packet?
<clever>
or the pci-e device just writes to a control register in the irq controller (MSI)
<zid>
I have no idea why they work, and I assumed they didn't, but I recompiled my code after a full vm upgrade and they suddenly worked
<junon>
From wikipedia's MSI article: "As an example, PCI Express does not have separate interrupt pins at all; instead, it uses special in-band messages to allow pin assertion or deassertion to be emulated."
<zid>
I never figured out why :(
<Alpha2023>
IOAPIC is legacy, however all MSI capable controllers have IOAPIC emulation
<Alpha2023>
so you can pretend MSI doesn't exist
<clever>
you can also get MSI on arm via the GIC
<junon>
So I can detect IOAPIC exists as a baseline and then upgrade to MSI where possible these days and be safe on most machines back to those that really matter
<Alpha2023>
are you using USB port or actual PS/2 port
<bslsk05>
web.archive.org: Wayback Machine
<Alpha2023>
because the PS/2 port is gonna be on the southbridge
<junon>
alpha2023: either, was just curious
<zid>
My plan was for a web repl rather than taking direct keyboard input cus I am weird
<zid>
so I didn't ever look at how to wire ps/2 for interrupts
<clever>
junon: that one loads
wand has joined #osdev
mahmutov has quit [Ping timeout: 265 seconds]
<Alpha2023>
if using a PS/2 port for the keyboard, the southbridge will have a built in 8042 compat PS/2 controller built in somewhere, so initialization will be the same on modern systems, however I'm unsure where the interrupt will pop up
dutch has joined #osdev
<junon>
So it will come in as an MSI interrupt somehow, you mean
<Alpha2023>
either that or it'll be polling mode only
<junon>
ah okay
<junon>
and if that's the case, once you're in MSI mode or whatever you can't access the IOAPIC functionality to get interrupts right?
<junon>
> however if you initialize the APIC, you lose the compatibility layer
<Alpha2023>
yea
air has joined #osdev
<junon>
so once you start going up the rungs of the 'legacy' PIC stuff (PIC -> APIC -> IOAPIC -> MSI) you opt-out of the compat layers, is what I'm understanding
<Alpha2023>
yeah
<junon>
cool
<Alpha2023>
same thing goes for USB I think
<Alpha2023>
once you enumerate USB and start talking USB, you lose PS/2 emulation (I think)
<junon>
Oh wait you get free PS/2 emulation over USB?
<junon>
I didn't know that
<junon>
Oh wait yes I did
<junon>
There used to be little dongles when i was younger, male PS/2 with female USB
<junon>
... I think...
<junon>
maybe it was the other way around but I kind of remember something like that
<junon>
Yeah! I knew I remembered them
<zid>
yea there's a pin compatibility that was cleverly worked in
<zid>
so that you know, you can actually use your BIOS software with a usb keyboard
<junon>
Oh yeah, makes sense
<zid>
And then my keyboard has a 'dumb USB HID with only 6 bytes' compat mode too :p
<Alpha2023>
Keyboards (for the most part) still talk the PS/2 Protocol, just using USB as an interface
<zid>
rather than my cool 13 byte version
sdfgsdfg has quit [Quit: ZzzZ]
<zid>
I'll get a full rollover antighosting keyboard one day and use the neat bitmask version
<junon>
But > once you enumerate USB and start talking USB, you lose PS/2 emulation (I think)
<junon>
Do you just mean on the CPU side?
<Alpha2023>
the little passive adapters that plug into PS/2 ports and take a USB keyboard (or mouse!) have a way of signaling the controller in the device to use the PS/2 wiring instead
<zid>
junon: usb host side
<zid>
'Talk to me using usb please'
<junon>
I see
<zid>
rather than 'talk to me using legacy ps/2' which is what the BIOS tells it to do
<junon>
Cool
<zid>
PCs are cool/weird
<junon>
Yeah this is the most fun I've had in years tbh.
<zid>
people moan about legacy crap until they plug a usb keyboard into something and it doesn't work
<Alpha2023>
tl;dr: if you use a USB keyboard, the USB controller will emulate an keyboard controller for you (it might actually be SMM, i'm not entirely sure the method)
<Alpha2023>
but once you set up the USB stack, you reinitialize the state, and therefore lose all the fun usb "emulation things"
<Alpha2023>
eg, USB floppy, keyboard, etc...
<zid>
I've never looked into how it's implemented, it could even be the southbridge doing it tbh
<zid>
it's got the usb bus on it, and connects to the superio where the keyboard controller was/is
<clever>
alpha2023: there is also a special handshake you need, to tell the emulation to stop messing with the usb controller
<clever>
alpha2023: older OS's didnt have that, so you had to turn the emulation off in the bios
<Alpha2023>
"On certain chipsets AT keyboard controller isn't present and is emulated by BIOS using SMI interrupt. On those chipsets reading from the status port may be thousand times slower than usually." -- FreeBSD Keyboard code code
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
dormito has quit [Quit: WeeChat 3.3]
<AmyMalik>
junon: Female PS/2, male USB. Keyboards compatible with this have a USB HID/PS2 dual controller inside
<junon>
Right okay, makes sense
isaacwoods has joined #osdev
wand has quit [Remote host closed the connection]
heat has joined #osdev
gog has quit [Ping timeout: 240 seconds]
ahalaney has quit [Quit: Leaving]
dormito has joined #osdev
<Bitweasil>
Yeah, USB to PS2 emulation is SMM.
<Bitweasil>
Among lots of other weird crap...
<Bitweasil>
Those USB/PS2 adapters didn't let you plug the thing into both ports at the same time... you either used the adapter to the PS2 port, or used the device as USB.
<Bitweasil>
And the lag on USB was awful for gaming.
<Bitweasil>
;)
<zid>
usb is finally decent now, if you pay £200 for the keyboard
<zid>
so that it doesn't give crap 6 byte packets over usb1.1 at 100Hz
<AmyMalik>
heh
<Bitweasil>
*sigh* Yeah.
<Bitweasil>
I've started getting mechanical keyboards after I dredged out a 30 year old Model M and realized how much it rocked.
<zid>
I really don't care for mech
<zid>
but I do care for good controllers
<zid>
and I hate RGB
<zid>
which leaves me with 0 keyboards to buy
<Bitweasil>
Welp.
rustyy has quit [Quit: leaving]
077AAB7C8 is now known as valeriusN
rustyy has joined #osdev
srjek has joined #osdev
sprock has quit [Ping timeout: 240 seconds]
dormito has quit [Ping timeout: 265 seconds]
sdfgsdfg has joined #osdev
dormito has joined #osdev
Burgundy has quit [Ping timeout: 265 seconds]
wand has joined #osdev
wand has quit [Client Quit]
heat has quit [Remote host closed the connection]
wand has joined #osdev
wand has quit [Quit: leaving]
wand has joined #osdev
wand has quit [Client Quit]
wand has joined #osdev
wand has quit [Client Quit]
wand has joined #osdev
wand has quit [Client Quit]
wand has joined #osdev
wand is now known as wando
wando is now known as wand
sdfgsdfg has quit [Quit: ZzzZ]
<geist>
CMYK all the way?
<geist>
zid: you hate RGB what?
<junon>
LAB
<junon>
or XYZ
<junon>
you're not hardcore until you use XYZ.
wand has quit [Quit: leaving]
wand has joined #osdev
<zid>
geist: You've not seen (any piece of computer hardware made in the past 10 years)?
<geist>
no of course not
<geist>
you think i live in the present? hah
<zid>
It's like there was a nuclear explosion at an LED factory
<zid>
every single device pulsates rainbow
<junon>
can confirm
<geist>
that's why i like irc, i can communicate via a tunnel to the future as long as someone still runs an irc server
<zid>
RAM, SSDs, graphics cards, cpu coolers, case fans
<junon>
my desk looks like a pride parade 24/7
<junon>
it's magnificent
<zid>
They even sell 'blank' RAM modules with JUST the lights
<zid>
for $50
<zid>
and they sell
<geist>
anyway, i call super bs on that. i have lots of nice keyboards with zero RGB lights
<zid>
when did you buy them, how much did you pay
<geist>
because i also dont particularly want a rgb lit keyboard
<junon>
zid: you probably want the custom keyboard pcbs and switches
<geist>
oh i dunno, i have a new type M. i have a relatively cheap tenkeyless corsair
<geist>
any mac keyboard
<geist>
any relatively cheap dell/HP/IBM/etc keyboard
<junon>
if you want something you can customize but also not have rgb and all the extra crap
<junon>
there are switches that feel less like mechanical anyway
<geist>
also i have a pair of daskeyboards. no RGB backlight
<zid>
I don't wanna customizer it
<zid>
I'd love a DAS
<zid>
DAS is from 2000
<zid>
meaning no RGB, and it has an n-key switch
<geist>
right. there are lots of makers of no frills non gamer good keyboards
<zid>
They're also 8x the price of what I paid for what I am using
<geist>
and even some relatively cheap ones in the gamer space (corsair, etc) that just sell the baseline version without RGB
<zid>
I got a 'razer cynosa' which has firmware controllable lights (aka I turned them off immediately, and it remembers that I did so through poweroffs) and a hotkey that enables/disables 10-key so I can still use my bios
<geist>
there ya go
<zid>
It took me about 800 amazon listings to find
<zid>
the meta key doesn't work, the keycaps are meant to be 'lit' so they're painted black to let the unpainted part shine through
<zid>
which means after 2 months the paint is all rubbing off
<geist>
i do have to say a very small amount of backlighting is nice for evening. like on my mac laptop
<zid>
and it cost 4x what I paid for my last keyboard
<zid>
and it has ghosting issues
<zid>
and it was the best I could find in 800 listings, like I said
<geist>
my two daskeyboards are both blank keycaps so there's really no point backlighting those unless you light the spaces between them
<geist>
which i guess would be helpful maybe
<zid>
mine's been fully painted then the paint laser etched, or custom painted with a mask, idk which
<zid>
the N key is almost transparent on top now :P
<geist>
anyway, i just wanted to call shenanigans on your RGB is everything. yes there are lots of RGB things but you can find it without
<geist>
but yes, it's not the gamer market
<zid>
It's just a completely dead sector now, keyboards between £10 and £40 with no RGB but with *any* sort of features, like half a dozen diodes
<geist>
reminds me what's that american psycho keyboard youtube. it's great