matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<klange>
EL0-EL1 sync exception is a fault or system call from userspace, 2 is just the pid
<klange>
ESR=0x56000000 = system call, ESR=0x2000000 = no f***ing clue ("unknown cause")
<klange>
i just `git checkout`'d my mmu code after butchering it with magic incantations and I've managed to get things back to a working state
<klange>
(I had changed some things in the earlier bootstrap, so things I was attempt to do to compensate for doing something wrong earlier were just breaking things more)
<klange>
that's dozens of startup processes working
<klange>
timer was turned off for this, trying with it turned on - dang thing takes a few minutes to boot every time I modify the SD card, I think it's doing consistency checks when it finds the FAT has been modified, but I'm not sure how
<klange>
okay with timer interrupts it's broken in init...
<klange>
possibly not sufficiently flushing out to the hardware when it handles the interrupt
<heat>
vdamewood, do it
<heat>
it's not hard
<heat>
i've been working on it for the past week or so
<vdamewood>
I need and RV system first.
<zid>
vdamewood: we all have moments of weakness where we think maochistic thoughts, you'll be okay
<vdamewood>
zid: moments?
<vdamewood>
s/and/an/
<zid>
ah so you're just searching out *how* you want to punish yourself, I see
<vdamewood>
Make it hurt so good!
<vdamewood>
If I really wanted to go masochistic, I could try to program an R32I (no G)
<bauen1>
vdamewood: how about RV32E ?
<bauen1>
vdamewood: only ~~16~~ 15 registers
<vdamewood>
bauen1: The point is to torture myself, not go suicidal
<vdamewood>
The register file has ben filed off.
<vdamewood>
But in all seriousness, programming boot code for x86 feels like the real self-torture.
<vdamewood>
Though, I was programming for a BIOS-based start up. UEFI was much better. I could even have an entry point in C.
<zid>
yea, not using grub or anything for x86 is pretty tortuous
<vdamewood>
zid: Yeah. Gotta give the grub devs tons of respect.
<klange>
you _have_ to have an entrypoint in C in UEFI, nothing else is defined :)
<vdamewood>
klange: You can write it in assembly, making sure to implement the UEFI C abi.
<klange>
(practically, yeah, of course you can write that in assembly...)
<vdamewood>
I'm sure freestanding C++ would work too.
<gog>
it does work as long as the entry point is MSABI and extern "C"
<klange>
I had this whole grand plan of writing a fully scriptable bootloader, but, I just stopped caring.
* vdamewood
gives gog a fishy.
<vdamewood>
klange: That happens a lot.
<gog>
my bootloader was very complicated and i was spending a lot of time working on it until i realized i was putting a lot of effort into code that only runs a short time
<klange>
okay if I set my timer interrupt to 1s, it does indeed fire after one second and then continuously trigger an interrupt, so I'm not clearing the interrupt status correctly for this GIC
<klange>
excellent, just need to fix that we should have a working system... with no input devices...
<klange>
But we'll wait for lunch for that.
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
<heat>
vdamewood, good luck getting a riscv system lol
<heat>
im just using tcg rn
EtherNet has quit [Ping timeout: 250 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
EtherNet has joined #osdev
sdfgsdfg has joined #osdev
<klange>
And now I'm getting a spurious irq, a timer irq, and then despite resetting the timer I get nothing after that... boots to desktop and gets to the idle task and then nothing wakes it from the wfi...
<clever>
arm generic timer or rpi vpu timer?
<klange>
arm generic
<clever>
probably unrelated, but i discovered that linux doesnt mask out the arm-generic timers on early boot
<clever>
so the instant it enables irq's, it gets deadlocked in a timer irq it wasnt expecting yet
<clever>
i had to modify my bootloader to disable them
<klange>
I have irqs masked in kernel space before turning on the timer the first time
<clever>
double-checking the src to see exactly what i had done
<bslsk05>
github.com: lk-overlay/intc.c at master · librerpi/lk-overlay · GitHub
<clever>
ah, i was just masking things out in the broadcom custom irq controller
<clever>
ive not played with the gic yet, so i dont know how the 2 controllers interact
<clever>
and the official arm stub likely never enables them
xenos1984 has joined #osdev
nyah has quit [Ping timeout: 272 seconds]
<geist>
wasn't there a switch in the boot.ini file for rpi concerning using the arm generic or the rpi timer? I assume it's just consumed by the kernel, but possibly its some hardware setup? do you hvae it set?
gog has quit [Quit: byee]
<clever>
geist: ive never seen one for that
<clever>
only gic vs broadcom controller
<clever>
and i'm fuzzy on what that actually did, it might only be a DT level flag
<geist>
hmm, thought there was. maybe it was only preset on the rpi3
<klange>
Well, the timer is at least working for one tick. Maybe I'm not configuring it right for the next ticks.
<geist>
it was basically to the effect of 'if you want to ues KVM set the arm one, otherwise the rpi one is better for some esoteric reason'
<clever>
pi2/pi3 have an arm generic timer, and basically need it because of the quad-core arm, so you have no choice there
<klange>
Since I'm actually talking directly to real hardware now, I get to experience all the fun of making sure my mmio is actually going through...
heat has quit [Remote host closed the connection]
<klange>
But hey, I got to a desktop - and when I was doing a bunch of prints and it was taking long enough to time out various things without a timer signal I even got a panel to show.
<geist>
hmm, only thing i see in theLk code is i clear and set bit 1 in the CTL register to enable/disable it
heat has joined #osdev
<geist>
but otherwise since its a match register and IIRC level triggered as far as I know if you set it to something > count it should arm again
<geist>
i'd double check your math there maybe
<klange>
I do that once, and then every time I see it I put 1/100th the frequency back into the CNTV
<clever>
what is the frequency?
<klange>
5.4mhz or some shit
<clever>
i think i saw a flag to select between 1mhz and crystal (54mhz)
<klange>
ah probably 54
<geist>
you put it back or you add it to the current one?
<clever>
the vc4 line (pi0-pi3) is 19.2mhz crystal
<klange>
geist: I put CNTFRQ_EL0/100 into CNTV_TVAL_EL0... which is working on QEMU, my read of the manual says those values tick down at CNTFREQ? Should I try to use something absolutely timed instead and place CNTFREQ*101/100 in it?
<klange>
Or maybe I've not probably configured it for level-triggered and I'm missing the second tick?
<clever>
count-down mode sounds far safer
<clever>
no race condition where you wind up setting a timer to fire in the past
<klange>
properly*
<geist>
i thought it was a match register? that's how my code is written
<geist>
if it's a match register then it's (current time + interval)
<klange>
there are a few different things in there >_>
<klange>
let me find the ol' pdf again
sonny has joined #osdev
<klange>
"When CNTV_CTL_EL0.ENABLE is 1, the timer condition is met when (CNTVCT_EL0 - CNTV_CVAL_EL0) is greater than or equal to zero. This means that TimerValue acts like a 32-bit downcounter timer."
<klange>
CVAL is an upcounter, TVAL is a downcounter
<klange>
"On a write of this register, CNTV_CVAL_EL0 is set to (CNTVCT_EL0 + TimerValue), where TimerValue is treated as a signed 32-bit integer."
<klange>
So TVAL takes a relative offset into the future and populates CVAL with the absolute offset.
<geist>
ah yeah. it's basically different ways to view the same thig
<geist>
but since you're not resetting the up counter to 0 you're always putting a thing in front of it
<klange>
Maybe I'm not acknowledging the interrupt correctly.
<klange>
I might be missing an unmask step.
<clever>
checking the official arm stubs and the arm arm, i can see that CNTFRQ_EL0 is just set to 54mhz by the rpi firmware
<bslsk05>
github.com: lk/arm_generic_timer.c at master · littlekernel/lk · GitHub
<klange>
I recall reading something about that? GICs can have two EOI modes? One where just the EOI write is enough, one where there's two steps I need to do?
<geist>
basically an optimization: if the interval is small enough (32bits) use tval, otherwise compute and set cval
<clever>
and like on arm32, its basically just a scratch register, and has no actual function
<geist>
but that's cute. i forgot that whole thing. it is a clever way of doing both a upcounter/downcounter mode and a match mode depending on how you hold it
<geist>
one EOI should be good enough
<clever>
i just noticed a bit of an issue with the design of CNTFRQ_EL0, its a 32bit value, so just north of 4ghz, it will overflow
<clever>
but is anybody feeding the generic timer off the cpu freq itself?
<geist>
iirc there's some statement in the manual that gates basically the range it should be
<clever>
ah
<klange>
the spec says it "should" be between certain ranges
<geist>
intel has similar verbiage. ie, the tick rate shall be faster than X but slower than Y where Y allows a 64bit counter to tick for so many years
<clever>
and i assume it should also not scale with cpufreq scaling?
<geist>
correct. and verey importantly all cpus in the system shall see the exact same counter
<geist>
very nicely specced, relative to x86 world
<klange>
I basically just slapped the full counter into where I was using the tsc on x86 and it's working great for that
<klange>
the interrupt is for preemption and timeouts, I don't really care how accurate it is, hence generally run it around 100Hz
<clever>
the rpi also as an ST_CLO and ST_CHI register pair, that count how many uSec the soc has been running (1mhz tick rate)
<klange>
https://www.youtube.com/watch?v=UCc285CrJyc had to take a video for this since the compositor clears the screen, but I see a 1023 spurious and then the timer and then nada
<bslsk05>
'2022年2月16日' by K Lange (00:00:11)
<geist>
oh one thing to try is double check you're using the right interrupt.
<klange>
yeah, I get 27 which is what I expect
<geist>
soetimes docs, etc are written with interrupt 0 being the base SPI interrupt
<geist>
ie, irq 32
<geist>
kk. and that's absolutely the right of the physical/virtual/etc?
<clever>
not doing serial debug?
<klange>
I get the right interrupt, at the right time, and I identify it correctly. But I only get it once.
<geist>
one thing you could do is spin and watch the raw GIC 'is interrupt set on this line' register. that's handy to see ifit's a maskig problem or not
<geist>
tends to bifurcate the problem into interrupt controller vs the device not reasserting
<geist>
reason i say this is its possible the first irq you thought you got wasn't actually the right irq. since you only got one you dont precisey if it was yours or wasn't an irq set by something else
<geist>
(i have been bitten by that before)
<clever>
what is the difference between `core n V timer` and `core n PS timer` ?
<geist>
virtual vs physical vs secure timer are really separate timers
<clever>
PPI 27 is virtual
<geist>
the physical one is the Real Timer, basically running against the real counter. may ormay not be available in non secure mode. virtual timer is the same as physical but can have an offset applied to it
<clever>
29 is PS physical, and 30 is PNS (nonsecure?)
<klange>
< clever> not doing serial debug? ← I have had so much trouble the TTL adapter I picked up I just gave up on it before even getting my kernel running, even on Linux I couldn't consistently get the thing to work.
<clever>
ah
<clever>
one trick ive sometimes done, is to just use another pi as the uart
<geist>
*generally* for a non secure EL1 you want to use virtual. but yah trying physical may be a good idea
<clever>
just cross-link the 2, and open /dev/serial0
<klange>
I have an original Model B I could use for that, but getting my framebuffer text driver up has served me well so far
<clever>
the hardware compositor also allows multiple independant framebuffers
<klange>
So, I see a 1023 - that's one of the spurious indicators. Then I see the 27 immediately after returning from that. In theory I'm resetting the timer and writing to the EOI register with the IAR value from that, but no more IRQs arrive.
<clever>
2 text consoles, a 3d render, a 2d animation, and a wallpaper (the grid)
<klange>
Does it alphablit those surfaces?
<clever>
linux is only aware of the tiny text console
<clever>
yeah
<klange>
How many can I have?
<clever>
ive done up to 13 huge sprites, or 70 tiny sprites
<clever>
the limit is more about the total number of pixels your asking it to draw
<klange>
A lot. 1080p desktop :)
<clever>
and pixels your covering up still count, it doesnt do occlusion testing
<clever>
the pi4 can do 4k
<clever>
https://www.youtube.com/watch?v=JFmCin3EJIs is an example of 13 seperate sprites (all technically sharing the same framebuffer), and changing the XY pos on every vsync
<bslsk05>
'Chaos, 13 sprites randomly bouncing around' by michael bishop (00:00:12)
<heat>
geist, do you have any idea why you need to call firmware to program a timer on riscv? it seems pretty dumb to me
<geist>
because there's only one timer
<geist>
(per core)
<geist>
so anythig lower than machine mode has to have it virtualized
<geist>
and thus there's a SBI call to do it
<heat>
because machine mode might be using it?
<geist>
right
<clever>
arm fakes it, by letting the hypervisor set an offset between physical and virtual, but i think riscv just does that all in software
<geist>
right. i think i heard theremay be some future extension thta allows for proper hardware supervisor timer support
<geist>
probably because a lot of folks found this to be kida dumb
<clever>
instead of wasting gates on an extra register and a virtual count, it just throws software at it
<heat>
yeah i'm literally doing a system call to set a timer
<geist>
yah that also means the timer fires in machine mode and then it reflects it down to supervisor mode
<geist>
though theres pretty good support for that sort of thing in riscv
<heat>
i miss the point for a timer in fw that's running all the time and doesn't have much to do
<geist>
in not too many instructions you could (in machine mode) figture out what's going on and then set the 'supervisor timer happened' bit and then eret to supervisor excception handler
<bslsk05>
github.com: linux/vc4_plane.c at rpi-5.10.y · raspberrypi/linux · GitHub
<bslsk05>
github.com: lk-overlay/hvs.c at master · librerpi/lk-overlay · GitHub
<bslsk05>
blog.benjdoherty.com: Exploring Hardware Compositing With the Raspberry Pi
<geist>
it's the design of SBI. it's supposed to be for both a hardware abstrction (you dont have to know how timers work) and to provide a consistent interface while being virtualized
<clever>
vc4_plane.c is the linux source to drive the compositor, its a bit tricky to read due to supporting every mode on 2 models
<clever>
hvs.c is a boiled down example of supporting plain rgb sprites with no scaling, but thats the non-pi4 part (scroll up for untested pi4 mode code)
<geist>
but yeh making the physical sytem pay for the pentalty of 'maybe you're being virtualized' is a bit of a big pill to swallow
<clever>
and the 3rd link is an overview of how it works (non-pi4 example code)
<heat>
yes, but you do since it's a CPU detail, and I don't understand how it's an interface for being virtualised when that would be running as a hypervisor
<heat>
and SBI runs in m mode
<heat>
not h mode or whatever they call it
<clever>
once you write a complete display list into the special dlist ram, you just set SCALER_DISPLIST${n} to the index the list begins at
<clever>
and the hardware will respect the new list on the start of the next scanline
<clever>
hvs.c also has vsync code, so you can flip on vsync
<heat>
though tbf, the hypervisor extensions were made long after riscv came out
zaquest has quit [Remote host closed the connection]
<geist>
heat: again the SBI interface is the interface
<geist>
OpenSBI is simply the m mode implementation of it for whenyour'e not running on a hypervisor
<heat>
can you ecall straight to h mode?
<geist>
if you were on a hypervisor then somethig else provide sit
<geist>
it'll trap it yes
<heat>
ahh
<heat>
that makes more sense
<heat>
wonder if there is an actual latency for the timer and stuff
<heat>
when doing an sbi call to set the timer
<heat>
or if its mostly insignificant
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
zaquest has joined #osdev
<klange>
ah, got it, I _was_ messing up the mmio to the gic
<klange>
wasn't mapping it through my interface that sets it up as device memory
<clever>
ahh
<klange>
the spurious interrupt was the hint, suggested I was reading iar incorrectly
<clever>
that sounds like it will really screw things up
sdfgsdfg has joined #osdev
<clever>
oh, and i also learned some other neat facts about the pi internals
<klange>
just need to clean up those prints and we'll see if we have a ticking clock and I'll call that done until the weekend when I'll focus on getting pcie set up and doing xhci
<clever>
on the VPU side, there is a load-many opcode, if you tell it to load 4 x 32bit from MMIO into r0/r1/r2/r3, then r0==r1, and r2==r3
<clever>
the theory, is that the cpu is doing a 64bit load into 2 registers at once
<clever>
but the MMIO is matching on the starting addr, and repeating the answer on the 2 32bit halves of the bus
<clever>
and expecting the cpu core to select the upper or lower half of the bus
<klange>
oops missed one debug print
<clever>
based on that, i can see how flushing a cache line into mmio can malfunction, it may be doing 64bit writes to 32bit mmio, and then a 32bit slice gets written to every 2nd register
<klange>
okay framebuffer is kinda slow, but I think I just straight-up have it mapped uncached - still faster than it was on the M1 with that dirty tracking bug, though
<klange>
we have a full desktop and a ticking clock
<clever>
nice
heat has quit [Ping timeout: 250 seconds]
<klange>
I need a few more things in place before I dare look into spinning up cores, but at least as far as kernel changes go I've managed to restrict this patch set to just a few little changes here and there in the aarch64 main.c
<clever>
the rpi is using spin-tables, where you write an entry-point to a special addr in ram, and then sev to wake the other cores
<clever>
DT should tell you what address
<klange>
Mostly worried about whether things will work after those cores are started.
<clever>
`root@pi400:~# dtc -s /proc/device-tree | less` under linux says: cpu-release-addr = < 0x00 0xe0 >; for each core
<bslsk05>
github.com: tools/armstub8.S at master · raspberrypi/tools · GitHub
<clever>
i think the only thing you need to do, is get the MMU going, configure some routing in the gic, and setup the arm timer on each core?
<clever>
yep, and those addresses are repeated in the DT, if you wish to avoid hard-coding things
<clever>
just implement the standard enable-method = "spin-table" stuff, and it will just work for any soc using that method
* klange
pushes this code to a branch
ElectronApps has joined #osdev
dmh has joined #osdev
<Jari-->
morning
<sonny>
gm
<klys>
hihi
valerius_ has quit [Ping timeout: 256 seconds]
bradd has quit [Remote host closed the connection]
mlombard has quit [Ping timeout: 252 seconds]
bradd has joined #osdev
masoudd has joined #osdev
the_lanetly_052 has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
sdfgsdfg has joined #osdev
<geist>
ugh, ust spent the last 2 hours fighting with SDL 2 and i still dont have my stuff rendering properly
<klys>
I think dgos used that
<geist>
i think it's because it's just so picky about what threads can access what
<geist>
but it's underdocumented and the general failure mode is to simply silently fail
Jari-- has quit [Ping timeout: 240 seconds]
<geist>
basiucally it seems that all textures/renderers/blitting/etc must be performed on the main thread
<geist>
but if you try to do it on not the main thread it pretends to work but doesn't do anything
<geist>
i was just locking/fiddlingwith/unlocking a SDL_TExture in a thread, and it seems to work, but when i go to render it (on the main thread) i jsut gets black
<geist>
ugh.
mlombard_ has joined #osdev
mlombard_ is now known as mlombard
mavhq has quit [Ping timeout: 256 seconds]
rwb has joined #osdev
rb has quit [Read error: Connection reset by peer]
sonny has quit [Remote host closed the connection]
masoudd_ has joined #osdev
mavhq has joined #osdev
gog has joined #osdev
masoudd has quit [Ping timeout: 252 seconds]
ElectronApps has quit [Remote host closed the connection]
Starfoxxes has quit [Ping timeout: 256 seconds]
GeDaMo has joined #osdev
wootehfoot has joined #osdev
woky has quit [Quit: Nothing in this world is hopeless!]
woky has joined #osdev
woky has quit [Remote host closed the connection]
woky has joined #osdev
dennis95 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
Burgundy has joined #osdev
zid has quit [Ping timeout: 240 seconds]
<klange>
Hm, I don't think my framebuffer is slow, I think these config options for clock rate just aren't something the firmware handles...
zid has joined #osdev
<klange>
The complicated animations have terrible framerates, but they're appearing on screen pretty immediately with each frame, so the flip is just fine, it's the transforms + transparency adjustments + window blits that aren't doing great
<klange>
also my gzip decompression is taking far longer than it should with all the memory caching correctly configured
<bslsk05>
github.com: Mailbox property interface · raspberrypi/firmware Wiki · GitHub
X-Scale has joined #osdev
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
Mutabah has quit [Ping timeout: 240 seconds]
ElectronApps has quit [Remote host closed the connection]
Mutabah has joined #osdev
pretty_dumm_guy has joined #osdev
<klange>
added 'initial_turbo=60' to the config.txt and now things look good [and a minute just passed since boot and the difference is night and day... I think the default is 700MHz and the turbo speed is 1.8GHz?]
<j`ey>
is that CPU freq?
<klange>
700MHz and 1.8GHz? yeah
<j`ey>
cool
lkurusa has joined #osdev
Mutabah has quit [Ping timeout: 240 seconds]
Mutabah has joined #osdev
<klange>
okay, mailbox magic incantation done and removed that config option, now we're running 'full' speed on our own and the doom demo is much smoother
<klange>
some animations are still touchy, but my software transforms choke a bit trying to draw mulitple windows on a 1080p display so that's understandable
<klange>
also the gzip decompression of the ramdisk is nice and fast now
dormito has joined #osdev
sortie has quit [Remote host closed the connection]
sortie has joined #osdev
<geist>
yay
woky has quit [Quit: Nothing in this world is hopeless!]
woky has joined #osdev
masoudd_ is now known as masoudd
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<g1n>
hello
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
nyah has joined #osdev
mctpyt has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
diamondbond has joined #osdev
diamondbond has quit [Client Quit]
mctpyt has quit [Ping timeout: 240 seconds]
* g1n
just compiled x86_64 gcc :D
<g1n>
will be porting orion to it, but later
<sortie>
g1n, woohoo :D
<g1n>
sortie: :)
dude12312414 has joined #osdev
zid has quit [Remote host closed the connection]
zid has joined #osdev
blockhead has quit []
the_lanetly_052 has joined #osdev
[itchyjunk] has joined #osdev
srjek_ has joined #osdev
ahlk has quit [Ping timeout: 240 seconds]
Raito_Bezarius has quit [Ping timeout: 240 seconds]
elastic_dog has quit [Ping timeout: 240 seconds]
vdamewood has quit [Ping timeout: 240 seconds]
srjek|home has quit [Ping timeout: 240 seconds]
vdamewood has joined #osdev
ahlk has joined #osdev
Raito_Bezarius has joined #osdev
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 252 seconds]
X-Scale` is now known as X-Scale
matrice64 has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
<mrvn>
klange: Doom on RPi barebone?
vdamewood has joined #osdev
<mrvn>
klange: do you have Descent?
<clever>
mrvn: i'm working on porting openlara to the rpi, lol
<bslsk05>
'Speedruns of TERRIBLE Doom Ports' by Karl Jobst (00:16:07)
<zid>
karl jobst is cancelled for being a nazi btw
<mrvn>
Doom on a pregnancy test? WTF?
<mjg>
have you seen his video on the subject/
<mrvn>
it's in the first few seconds
terminalpusher has quit [Remote host closed the connection]
<mjg>
i meant the nazi allegations
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
FatalNIX has joined #osdev
<Bitweasil>
... erm. Sorry, isn't a pregnancy test just a few chemicals on a stick? How on earth does that run DOOM?
<FatalNIX>
Wait what
<FatalNIX>
what did I miss
<GeDaMo>
I think they actually replaced the display with a small screen
<FatalNIX>
Also the at home self covid test kits look exactly the same as pregnancy tests do..
<Bitweasil>
Oh.
<Bitweasil>
> By removing most of the interior of the test, including the original CPU, Foone Turing used its tiny one-color display first to stream video of the classic video game, and then actually play it.
<FatalNIX>
I should (as a guy) use one and then post online "well it looks like I'm not pregnant" lol
<bslsk05>
geekologie.com: Doom running on a digital pregnancy test - Geekologie
<Bitweasil>
Yeah.
<Bitweasil>
That makes an awful lot more sense.
<Bitweasil>
I mean, none at all, but... still.
<FatalNIX>
I didn't think there was a chip in the pregnancy tests at all
<FatalNIX>
I figured it was pure chemical
<Bitweasil>
I thought so too, apparently there are some digital ones now?
<Bitweasil>
"Stick a chip in it, yeah, yeah, stick a chip in it!"
<FatalNIX>
That's what she said
<Bitweasil>
To paraphrase a kid's oven toy that talks about putting eggs on everything.
<FatalNIX>
Do good toys even exist anymore?
<FatalNIX>
Man when I was young vac man was the shit
<Bitweasil>
Sure, you find them used.
<Bitweasil>
Or build them.
<Bitweasil>
Nerf guns have rather drastically improved over the years.
<Bitweasil>
And then there's a huge modding community.
<Bitweasil>
For when you want yours to pack a proper punch.
<FatalNIX>
tbf the 90s commercials for nerf guns were the only cool thing about them
<Bitweasil>
You can mod a Vulcan (belt fed full auto) to about 500 rounds a minute.
<Bitweasil>
Burns through a 25 round chain in a hurry.
<Bitweasil>
And most of the others, if you drill out the air restrictor and upgrade the spring, will pack a legitimate punch.
<FatalNIX>
Does nobody bring their kids paintballing anymore?
<Bitweasil>
Mine are a bit on the young side for that.
<FatalNIX>
I must have been in late middle school when I started
<FatalNIX>
Just a guess
<FatalNIX>
Yeah actually that makes sense. I went hunting before I did paintball, so it would have had to be late middle school
<Bitweasil>
I would be totally fine with that when they're that age. :)
vdamewood has quit [Read error: Connection reset by peer]
<FatalNIX>
I got my hunting license when I was 13, which was common at the time. No idea what it is today.
<Bitweasil>
Not sure, I don't hunt. Not opposed to it, just never have gotten the chance to, and haven't gone out of my way to seek it.
<FatalNIX>
But I don't actually hunt, I only did it because it was the only time I really got to spend with my grandfather
vdamewood has joined #osdev
<FatalNIX>
It's kind of customary here that when you become of age you get your hunting and often also trapping license
<FatalNIX>
Even if it's not something you end up doing really
<Bitweasil>
*nods*
<FatalNIX>
People here value the hunting and trapping safety courses they put kids through so they understand more about things like that.
<Bitweasil>
Not sure what country you're in, I'm in the US, I fully support firearms safety training being mandatory in schools
<Bitweasil>
Because even if you don't care for guns, you're still likely to come across them at some point in your life, and ought to be able to safely handle and clear one.
<FatalNIX>
Maine in particular.
<Bitweasil>
I don't care if you can shoot it or not, as long as you know how to *not* shoot your friend or your foot or something while clearing and safing it.
<Bitweasil>
The number of "I'm sure it wasn't loaded!" guns putting random holes in floors and walls during cleaning should be zero, and it's not.
<Bitweasil>
Because that's just basic failure to perform the clearing actions every time you pick up a gun.
<FatalNIX>
It's pretty dumb
<Bitweasil>
You should be able to safely handle and clear: Semi-auto handgun, revolver, pump action shotgun, break action shotgun, semi-auto shotgun, bolt action rifle, semi-auto rifle.
<Bitweasil>
If you can handle one or two of each type there, you'll be fine in 99% of cases.
the_lanetly_052_ has quit [Ping timeout: 252 seconds]
<FatalNIX>
I have a break action 20 guage and a 44 magnum bolt action rifle myself. I just don't use them. My grandfather had 46 guns we pulled out of the house when he died and I remember using a fair ammount of them on different occasions.
<_eryjus>
<Bitweasil> Because even if you don't care for guns, you're still likely to come across them at some point in your life, and ought to be able to safely handle and clear one. -- Just ask Baldwin.
<FatalNIX>
I will say that the first time you ever open up a break action shutgun after firing and get bopped in the face with an empty shell is a priceless moment for everyone
<Bitweasil>
Who? Baldwin?
<Bitweasil>
FatalNIX, lol, yup!
<Bitweasil>
And it's usually still warm enough to get your attention.
<Bitweasil>
Oh, was Baldwin the actor who killed someone on set with a "not loaded gun"?
<vin>
Would it be possible to represent 1e+12 values with a variable smaller than 5B?
<GeDaMo>
Depends on how much precision you want
<FatalNIX>
I came up with a number encoding format ince that is 16 bits and uses engineering notation as a signed set of bits
<FatalNIX>
once*
<FatalNIX>
the idea is that you placed multiple of them in a row to achieve more resolution
<FatalNIX>
like a string
<GeDaMo>
Variable length encoding like UTF-8?
<FatalNIX>
Ok this baldwin thing is stupid. We have had electronic gun effect systems for decades,
<FatalNIX>
Why are there real guns on the set in the first place
<FatalNIX>
Yeah basically GeDaMo I used it like you knew ahead of time how many butes a number was going to take\
<FatalNIX>
bytes*
<FatalNIX>
I still want to come up with a hardware ALU implementation to try something like this in a toy architecture though
<zid>
congratulation you invented IEEE floating point :P
<FatalNIX>
haha yeah but it doesnt use the fraction system
<FatalNIX>
instead there's no real limit to how acurate you can be except if you run out of exponent figures.
<zid>
I need about 1 bit to track numbers that are greater than 1e12 or not
<zid>
It's just bit * 1e12
<zid>
it supports 0, and 1e12
<FatalNIX>
so there are no error margains or anything
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
matrice64 has joined #osdev
heat has joined #osdev
GeDaMo has quit [Remote host closed the connection]
masoudd_ has joined #osdev
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
masoudd has quit [Ping timeout: 240 seconds]
dormito has quit [Quit: WeeChat 3.3]
sdfgsdfg has joined #osdev
vancz has quit [Quit: vancz]
terminalpusher has joined #osdev
wolfshappen has quit [Ping timeout: 256 seconds]
vancz has joined #osdev
mahmutov has quit [Ping timeout: 240 seconds]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
k8yun has joined #osdev
dormito has joined #osdev
terminalpusher has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
ggherdov has quit [Ping timeout: 240 seconds]
paulbarker has quit [Ping timeout: 252 seconds]
snickerbockers has quit [Read error: Connection reset by peer]
geist has quit [Ping timeout: 250 seconds]
SanchayanMaity has quit [Ping timeout: 250 seconds]
Benjojo has quit [Read error: Connection reset by peer]
mxshift has quit [Read error: Connection reset by peer]
mats1 has quit [Read error: Connection reset by peer]
snickerbockers has joined #osdev
mxshift has joined #osdev
Benjojo has joined #osdev
mats1 has joined #osdev
paulbarker has joined #osdev
SanchayanMaity has joined #osdev
ggherdov has joined #osdev
geist has joined #osdev
matrice64 has joined #osdev
sonny has joined #osdev
<sonny>
What does the strong trend of software defined networks mean wrt to OS design?
<klys>
well I have been trying to find a way to get a vm bridged to the local wifi. ethernet can be bridged with parprouted (I have a small client mode router that does proxyarp, so proof of concept.) qemu as of yet does not support bridging via proxyarp.
<klys>
so I guess the deal is I can "bridge" wifi to an external ethernet interface, plug it into another external ethernet interface, and use qemu that way. well, I've had a qemu-kvm vm on the local wifi for a while via the client mode router. as far as doing both tasks with the same pc, I still need to try that.
xenos1984 has quit [Read error: Connection reset by peer]
sdfgsdfg has joined #osdev
<klys>
there's another way more freed up networks can bridge via proxyarp to wifi, called 4addr. my local wifi does not support 4addr and will kick me off if I enable it.