<klange>
Don't know if this driver works on a real instance of such hardware, don't care, it works in vmware and I can play Doom with all the shotgunny goodness.
<zid>
I think my board that had it is long gone sadly
noircode has left #osdev [#osdev]
<vdamewood>
Now I wish I had an old system to try and develop a driver for the physical hardware.
<zid>
I do have one.. I'm not sure it *works*
<zid>
a P35 chipset too like qemu
* moon-child
's assembler now generates over 1mloc of automatic test cases, verified against nasm
<moon-child>
and I only had to put in two hacks to generate the same code as nasm!
<zid>
nice, sounds easier to just use nasm though ngl
<zid>
:p
<moon-child>
technically I have an excuse, which is that nasm has mad complex macros and I want to avoid all that. Better separation of concern etc.
<moon-child>
but really I just wanted an excuse to learn the instruction encodings
<moon-child>
which i kinda regret but...¯\_(ツ)_/¯ too late now
[itchyjunk] has quit [Read error: Connection reset by peer]
devcpu has quit [Quit: leaving]
<klange>
What I would like is to have the patience to sit down and write an HDA driver. The Ensoniq was, beyond parsing its spec, about as straight-forward as the ICH AC'97 we've had a driver for for ages now, it was just a matter of banging out the right bits to get it to play.
devcpu has joined #osdev
<zid>
Yea I figure most cheap sound cards are basically "This is the address you spam PCM samples to / this is the address you put the DMA location in" and some mute/vol/etc registers
<zid>
maybe if they're really fancy, it's a couple of pages in a ring buffer
<klange>
ICH AC'97 was pages in a ring buffer, this Ensoniq card is just up to 256k bytes of sample memory and you can ask it to irq you every so many samples.
<clever>
at the lowest level (usually hidden), the rpi analog audio is just a pwm controller, and a dma controller in ringbuffer mode
<clever>
and it has a sample rate of something like 400khz
<klange>
I'll be poking an RPi4 soon enough.
<zid>
klange: oh hey my intuition was pretty solid then
<clever>
so you need to up-sample the audio to insane levels
<clever>
but the closed firmware hides all of that, and presents a more sane 48khz api
<zid>
48kHz still requires me to resample literally everything tbh
<clever>
i suspect the firmware can accept other rates
<clever>
i havent investigated the api closely
<zid>
99.9% of my audio is 44.1, the other tiny bit is 48 yea
<zid>
does 48000 have good prime factors?
<clever>
> Stage 1 is source samplerate conversion (8kHz-48kHz -> 48828Hz) - this fractional conversion is required as the PWM source clock is not a power-of-two product of audio sample frequencies.
<zid>
ooh yea pretty good
<clever>
ah, so the firmware will accept 44.1khz, but internally needs it at 48.828 KHz
<klange>
I added a dumb-as-bricks sample rate converter to my MP3 player, Quake is built to generate 48khz, and Doom needs a sample rate converter regardless.
<klange>
(Doom sounds use variable sample rates)
<clever>
> Stage 2 - Oversampling by factor x8 to 390625Hz using a length=512 FIR filter with a nice, sharp cut-off.
<clever>
~390khz, i was kinda close
<clever>
> Stage 4 - 2nd-order quantisation noise shaping from 16-bit PCM at 781250Hz to 7-bit PWM samples.
<clever>
ah, but then it goes ham, to ~781 KHz!
* clever
heads to bed
GeDaMo has joined #osdev
GreaseMonkey has quit [Remote host closed the connection]
biblio has joined #osdev
<moon-child>
god fucking dammit
<moon-child>
I generate shorter code than nasm for this one thing
<moon-child>
i don't wanna intentionally generate _longer_ code just to match
<j`ey>
why does it need to match?
<zid>
mv nasm/ moonasm/ done
<zid>
now it produces identical output
<moon-child>
j`ey: because nasm probably got it right, so I use it to test that I got it right
<moon-child>
I found one nasm bug, it found probably 10 bugs in my code. Worthwhile trade
<moon-child>
maybe two nasm bugs actually. idk if this rex.w things is actually harmless or not
<zid>
nasm can't do jump size stuff perfectly
<zid>
it's specifically only limited passes
<zid>
and if you try to do it 'perfectly' you can get into annoying astable states
<j`ey>
moon-child: sorry, I thought you were compiling to asm, didnt see that you were writing an assembler
<moon-child>
:)
<moon-child>
zid: does _anyone_ do the jump size stuff perfectly?
<moon-child>
technically it's ambiguous--there can be multiple 'perfect' combinations. So I kinda wanna do PGO jump size as a stunt. But beyond that heuristic/sliding-window is good enough for real-world
<kingoffrance>
what do you mean by: "but really I just wanted an excuse to learn the instruction encodings" "which i kinda regret but..." ? when you see how the sausage is made?
<moon-child>
yes
<kingoffrance>
lol
<moon-child>
it is terrible
<moon-child>
never do x86
<moon-child>
go learn a nice arch like riscv or something idk
<moon-child>
(well, riscv is a pita to use buut)
<zid>
moon-child: It has multiple imperfect solutions is the real problem
<zid>
lengthening one jump may shorten another
<moon-child>
right, yes
<moon-child>
and hypothetically that could actually make a difference if it makes one thing straddle a cache line
<moon-child>
(though funny enough the problem only manifests if you have alignment directives! :P)
<moon-child>
well, actually, i guess. Say you have 5 jumps, you can either have 2 short/3 long or 2 long/3 short, but the former configuration the 2 short are hotter. Can that come up? I'd have to think about it but I think so
<zid>
I am hotter, that's all we need to know
<geist>
huh TIL that JUSTIN BAILEY the metroid code was not hard coded, it was simply a coincidence that it passes the checksum
<zid>
yea
<zid>
There's some cool codes for act raiser 2 like that
<geist>
really 1/256 random strings you typed in would work
<geist>
though not all bit patterns result in something valid
<zid>
But they actually unpack to like.. incredibly high difficulty modes and stuff
<j`ey>
to.. edk2-platforms? but it's not a platform!
<heat>
zid: yeah but I've upgraded from 8.1 -> 10 before and everything worked fine, I've upgraded through multiple windows 10 releases and everything worked fine, I've upgraded to w11 and it broke (somehow!). I don't even know how it broke considering grubx64.efi was still there, but I got booted straight to recovery
<zid>
ah yea efi is a little less outright bricky
<zid>
but I still don't trust windows :p
kciredor has quit [Ping timeout: 252 seconds]
<heat>
j`ey: yup, that's where I got told to put the package since it's more "advanced" I guess?
<j`ey>
weird
kciredor has joined #osdev
<j`ey>
anyway, I've been playing with rEFInd as a bootloader, I wonder if it could use that instead of the other random ext4 driver it uses
<heat>
i'm fine with it, the only issue is that OvmfPkg and ArmVirtPkg can't depend on it
<j`ey>
yeah
<heat>
j`ey: you can totally use it
<heat>
It's seeing usage by nvidia and folks in OpenCorePkg that I know of
<j`ey>
cool
<heat>
only quirk right now is that it doesn't support symlinks
<j`ey>
read only, read write?
<heat>
and it can be a bit slow on mechanical hard drives since I dont have caching just yet
<heat>
read only
<j`ey>
cool
nohit has quit [Read error: Connection reset by peer]
nohit has joined #osdev
<heat>
i think I'm finally going to invest in an simple sata ssd for my laptop
<heat>
using a computer is becoming increasingly frustrating
<heat>
either that or new laptop, but a laptop is way more expensive, no 1TB drive and you only get integrated graphics
mahmutov has quit [Ping timeout: 265 seconds]
elastic_dog has quit [Remote host closed the connection]
wootehfoot has quit [Read error: Connection reset by peer]
<sortie>
geist, just had a fun bug where recvmsg(2) fails with EFAULT if it's called twice with the same msghdr. You see it's supposed to overwrite the struct msghdr in user-space to update msg_flags and msg_controllen. But the kernel temporarily replaced msg_iov pointer with a pointer to the kernel's copy of the array and didn't restore it.
<sortie>
=> Kernel pointer leaked to user-space and user-space fed it back to the kernel with refused to access that bad pointer.
<geist>
Oooh yeah that's not good
<sortie>
I was working on my Unix socket file descriptor passing and thought my diff was bad because I had a hard time getting the unit tests to pass, but nope, unrelated kernel bug
<geist>
Kernel shouldn't ever put kernel internal stuff in user space
<sortie>
That wasn't what was happening
<geist>
Ah
<sortie>
The kernel made its own copy of the msghdr. It modified it with its own safe pointers. Then it copied it back to user-space, such that the msg_flags and msg_controllen fields got updated there.
<sortie>
Basically this whole thing was safe and then at some point I probably realized I needed to update those fields and tacked a copy-to-user-space onto it without realizing it accidentally changed unrelated fields too
<geist>
ah makes sense
<sortie>
Honestly I do not like the API design of control data.
freakazoid333 has joined #osdev
<sortie>
It's kinda tacked onto sendmsg/recvmsg as an out of band thing. It means it's not e.g. counted in the return value how much control data got processed.
<sortie>
That means that sendmsg is not able to say just how much control data it actually sent. I made my implementation be essentially an all-or-nothing approach, either it all goes through atomically, or none went through.
<sortie>
Honestly it's difficult to implement correctly and also give some safeties like that to user-space. It could maybe just have been done with a flag rather than a whole new set of buffer parameters.
zaquest has quit [Remote host closed the connection]
srjek|home is now known as srjek
zaquest has joined #osdev
<dormito>
bah. someon updated the "Global Descriptor Table" page... but they got some of it very wrong (entires are 8 bytes in i386 mode, IIRC long entries are two 8-byte entries... so sort of 16 bytes)... and I didn't get any further than that.
<gog>
segment descriptors are 8 bytes in long mode
<gog>
except TSS
<gog>
system descriptors are 16
<gog>
it's fucked up imo
<dormito>
and that is why I didn't fix the edit :p.
<gog>
286 was a mistake we're still paying for
<dormito>
x86's segmentation is... a horrible mess. I'm pretty sure every little bit made sense at the time... but it was not designed to be extensible until much later in the game
biblio has joined #osdev
biblio has quit [Client Quit]
GeDaMo has quit [Quit: Leaving.]
<Oli>
Are we talking about FAT filesystems? Individual entries are 32-byte long, and those with long filenames occupy additional one or more 32-byte length entries.
<j`ey>
Oli: GDT
<Oli>
Perhaps it is off-topic, my apologies if so.
GreaseMonkey has joined #osdev
<Oli>
Thank you, j`ey.
<j`ey>
Oli: not off topic, just wrong topic :P
<Oli>
lol
anon16_ has quit [Ping timeout: 252 seconds]
anon16_ has joined #osdev
mahmutov has quit [Ping timeout: 252 seconds]
[itchyjunk] has quit [Remote host closed the connection]
yomon has quit [Ping timeout: 252 seconds]
anon16_ has quit [Read error: Connection reset by peer]
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
kingoffrance has joined #osdev
Arthuria has joined #osdev
dude12312414 has joined #osdev
Arthuria has quit [Ping timeout: 252 seconds]
junon[m] has joined #osdev
<junon[m]>
Connecting from Matrix for the first time, is this working? lol
<junon[m]>
I'm super afraid of accidentally sending garbage or like 10 lines or something.
<clever>
junon[m]: if you try to send more then 1 line, matrix will automatically send a link to a .txt file instead
<junon[m]>
woah no way, neat
<clever>
but there will be no context on why people should click the link and read it
junon_ has joined #osdev
<clever>
so your more likely to get ignored
<junon[m]>
Oh :|
<clever>
so you need to take care to say why they should click the link, in its own 1 line message
junon[m] has quit [Client Quit]
<junon_>
makes sense I guess.
junon[m] has joined #osdev
<clever>
it also helps to keep an old irc client connected for the first week, and see how things get mangled on the other end
junon[m] is now known as junon
<junon_>
yep that's what I'm doing now
<clever>
i still prefer real irc, and i only use matrix from my phone, or when i need to upload images to irc
<junon>
yeah I'm still not 100% sold on matrix personally. The UX of it all still needs polish.
<junon>
but I've got it all set up now which is good. :)
<junon>
I'm not even 30 yet and some of this stuff makes me feel like a grandpa. I was on first on irc when I was 8.