klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
srjek has quit [Ping timeout: 268 seconds]
<geist> yay got my rosco 64k board
<geist> or the kit at least
<geist> eh 68k even
srjek has joined #osdev
C-Man has joined #osdev
mahmutov has quit [Ping timeout: 246 seconds]
asocialblade has joined #osdev
asocialblade has quit [Client Quit]
mahmutov has joined #osdev
mahmutov has quit [Ping timeout: 268 seconds]
knusbaum- is now known as knusbaum
srjek has quit [Ping timeout: 260 seconds]
gog has quit [Ping timeout: 268 seconds]
zaquest has quit [Ping timeout: 268 seconds]
eddof13 has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zaquest has joined #osdev
m3a has joined #osdev
mavhq has quit [Ping timeout: 260 seconds]
heat has quit [Ping timeout: 260 seconds]
ZipCPU has quit [Ping timeout: 260 seconds]
mavhq has joined #osdev
Burgundy has joined #osdev
ZipCPU has joined #osdev
the_lanetly_052_ has joined #osdev
rorx has quit [Ping timeout: 248 seconds]
catern has quit [Ping timeout: 240 seconds]
rorx has joined #osdev
C-Man has quit [Ping timeout: 248 seconds]
nyah has joined #osdev
GeDaMo has joined #osdev
<mrvn> Is that a MC68000?
pretty_dumm_guy has joined #osdev
<geist> 68010 i believe
<geist> not entirely sure why 010, may actually be easier to obtain nowadays. but it's pin compatible IIRC so why not
Burgundy has quit [Ping timeout: 246 seconds]
<mrvn> Would have thought you would want at least an 68030 for the MMU.
<mrvn> or does it have an external one?
gog has joined #osdev
m3a has quit [Quit: leaving]
heat has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
sprock has quit [Ping timeout: 260 seconds]
sprock has joined #osdev
gog has quit [Ping timeout: 260 seconds]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
Likorn has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 260 seconds]
srjek has joined #osdev
Burgundy has joined #osdev
C-Man has joined #osdev
heat_ is now known as heat
papaya has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Gooberpatrol_66 has quit [Remote host closed the connection]
Gooberpatrol_66 has joined #osdev
papaya has joined #osdev
Gooberpatrol_66 has quit [Remote host closed the connection]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 268 seconds]
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 256 seconds]
enkeyz has joined #osdev
edro is now known as edr
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
the_lanetly_052_ has quit [Ping timeout: 246 seconds]
fwg has quit [Ping timeout: 260 seconds]
JanC has quit [Read error: Connection reset by peer]
JanC has joined #osdev
gog has joined #osdev
<gog> mew
<heat> wem
<dzwdz> ewe
<Ermine> gog: can I pet you?
<FatalNIX> Wow.
<gog> yes
* Ermine pets gog
* gog prrs
<FatalNIX> I never looked at it before but that giant ELF walkthrough image somebody made that's up on Wikipedia is beautiful.
<FatalNIX> I love things like that.
the_lanetly_052_ has joined #osdev
<FatalNIX> That one
<dzwdz> there's a whole repo of those
<dzwdz> it's pretty neat
<FatalNIX> I'm not surprised.
<gog> yes
<Ermine> Cool
<FatalNIX> Do you know the name off hand?
<FatalNIX> I'd love to look it up.
<heat> oh that's nice
<dzwdz> i have it somewhere in my gh stars, wait a sec
<heat> it's also very incomplete
<heat> but nice regardless
<bslsk05> ​corkami/pics - Posters, drawings... (506 forks/5667 stargazers)
<FatalNIX> Thanks!
<dzwdz> ^^
<FatalNIX> These are incredible.
<gog> i'll have to have a look through these later
<gog> rn i need food
<FatalNIX> I just ate PB cookies for breakfast
<gog> i'm making lunch pasta
<gog> well late lunch
<gog> very late lunch :|
<dzwdz> oh hey, there's a cp437 diagram in there
<dzwdz> ttps://github.com/corkami/pics/blob/master/binary/charsets/ASCII-DOS.png
<bslsk05> ​github.com: pics/ASCII-DOS.png at master · corkami/pics · GitHub
<dzwdz> that's actually pretty useful
<GeDaMo> On a related note https://tls13.ulfheim.net/
<bslsk05> ​tls13.ulfheim.net: The (Updated) Illustrated TLS 1.3 Connection: Every Byte Explained
<dzwdz> also oh wow, i didn't expect the bot to handle mispasted links
<dzwdz> that's neat
<heat> huh useful links time?
<dzwdz> aw, i kinda expected this page to use random keys each time
<dzwdz> s/expected/hoped that
<heat> https://webkit.org/blog/6161/locking-in-webkit/ <--- locking under webkit
<bslsk05> ​webkit.org: Locking in WebKit | WebKit
<heat> brief overview of the linux graphics stack: https://blog.mecheye.net/2012/06/the-linux-graphics-stack/
<bslsk05> ​blog.mecheye.net: The Linux Graphics Stack | Clean Rinse
<bslsk05> ​blog.packagecloud.io: Monitoring and Tuning the Linux Networking Stack: Receiving Data | Packagecloud Blog
<heat> how to make a good drm ioctl, also makes for a decent guide in making ioctls in general: https://blog.ffwll.ch/2013/11/botching-up-ioctls.html
<bslsk05> ​blog.ffwll.ch: Botching up ioctls
<heat> blog about lots of i915 stuff and how they work: https://bwidawsk.net/blog/
<bslsk05> ​bwidawsk.net: dumbing things up — Dumbing Things Up
<heat> whew, a nice link dump
<dzwdz> is there an osdev link aggregator?
<heat> i have so many gems in my bookmarks that I just never look at
<heat> no
<heat> we could make one though 👀
<dzwdz> maybe it could just be a simple irc based one?
<GeDaMo> Does bslsk05 have a home page?
<dzwdz> you'd have a bot which'd grab all the links from a channel, grab some metadata about them, and put then on some webpage
<heat> a bot that grabs arbitrary links sounds like a horrible idea ;P
<heat> i though of a simple markdown git repo
<heat> thought*
<dzwdz> that works too
<dzwdz> but it's too hard to mess up imo
<FatalNIX> Sounds like Reddit to me
<dzwdz> eh, reddit doesn't have tags
<dzwdz> it'd be nice to tag stuff that's related to specific architectures, branches of osdev, etc
<FatalNIX> Maybe make it have an approval system so you go in and look at them (like an IRC quote DB)
<FatalNIX> and tag them there
<FatalNIX> That way CompanionCube doesn't fill it up with porn
<heat> links aren't quotes
<heat> unless you want to do !networking and have a random networking link
<dzwdz> that sounds addictive
<FatalNIX> Somebody puts a rick roll on it
<heat> these are /surprisingly/ hard to get
Gooberpatrol66 has joined #osdev
pretty_dumm_guy has joined #osdev
gildasio1 has joined #osdev
mahmutov has joined #osdev
<geist> mrvn: well, sure, but no one currently makes a 68030 board, since the pinout is substantially more complex
<zid> 20 more complex, I think
<geist> yah 030 is iirc fairly similar to 020 signal wise, though i think it's a little more complicated to support external caches more
<geist> i've been studying it a bit with the intention ot eventually making a board, but either you need a lot of external TTL logic to deal with the bus cycles or you need a CPLD/FPGA to do it
<geist> since it has a fairly complicated synchronous external bus
<geist> not insurmountable, a fpga would do fantastic, but it is defiitely somewhat of a state machine
<gog> probably easier with a CPLD than a bank of 74xx TTLs
<geist> 68000 and 68010 are simple enough that it's kinda like a fast 6800 class machine, though even the rosco board uses some PLAs for address decoding, but they could have done it with a handful of TTL chips
<geist> gog: yeah there's some stuff with the 030 bus that deals with things like unaligned accesses., it's a 32bit data bus but it is apparently free to ask for completely unaigned accessses at 8 16 or 32 bit wide
<geist> and there's some complexity about providing different bytes on different 'lanes' of the D0-D31 bus
<geist> i *think* you can cheese out and just provide 8 bit data if it's unaligned and the cpu will just keep fetching
<geist> it also has a burst mode transaction which is synchronous, it starts a sync transfer and then expects ou to deliver subsequent addresses on subsequent cycles. used to fill the internal cache
<geist> so that alone seems to mean yo uneed at least some sort of external address latch with at least a rudimentary adder
<geist> i *think* you can NAK that and it'll just treat the range as uncached
<gog> idk enough about the 68k's pipeline to really know what feeding it unaligned data would do
<gog> at least without the supporting logic
gildasio1 has quit [Quit: WeeChat 3.5]
<geist> the 030 manual talks about there being a block in the cpu that deals with bus transactions and swizzling things around. i think it would just end up stalling, waiting for data to show up
<geist> also means you can legitimately wire up say a 16 bit bus to an 030 and just NAK the high bytes on every transaction
<geist> and it'll just spend extra cycles doing what it needs to do
<geist> which some of the later, cheaper macs did, even. Mac Classic I think was an 030 with a 16 bit bus
<geist> but also i think you can simply wire up a board that only does 8 bit transfers and the cpu will just deal with it
<geist> so probably that's the best idea for getting started
<mrvn> You can buy an amiga board, or at least pre-order from the next batch they make. But then you need to buy the custom chips for it too.
<geist> yah there's someone locally selling an amiga 500 for i think $300 but that's too much
srjek has quit [Ping timeout: 268 seconds]
gildasio has quit [Remote host closed the connection]
<mrvn> way cheaper, better but some assembly required.
gildasio has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
gildasio has quit [Remote host closed the connection]
<mrvn> One of the custom chips probably handles the bus.
gildasio has joined #osdev
<geist> yah
<geist> an asic would have not a lot of trouble with it
<geist> as a side note i think the 486 bus is roughly as complicated. one *could* build a fpga or whatnot to deal with one
<geist> just folks dont get too nostalgic about 486 homebrew computers
<geist> or at least without just using existing chipsets
<geist> well maybe a it more complicated. a 486 is roughly contemporary with an 040
<geist> 386 maybe to an 020/030, and it has a fairly straightforward bus
<mrvn> but more like below 68000 in capability and speed
divine has joined #osdev
<geist> well, capability a 386 is clearly intended to be a competitor to the 030 (i think 030 was first)
<geist> but performance wise, yeah. dunno at what mhz they were equivalent
<mrvn> A 040/060 at 50MHz rivals a P90 easily.
<geist> i'd be a little doubtful of that, but have no good way to verify it
<mrvn> FPU wise maybe not but integer performance of m68k is way above x86
<geist> that sounds possibly right. the FPU of a pentium was definitely a jump forward for x86 line
<mrvn> Ram wise my Amiga had nearly double the throughput to a P90.
<geist> yah was thinking that: if it had a solid 50Mhz bus that would be pretty good. there were some mystical 50Mhz 486s in the day that were coveted for that reason
<geist> had a proper fast bus, before most of them were reduced to 25/33 mhz busses
<mrvn> Phase5 CPU boards where just amazing. You get 60+MB/s from normal ram while a P90 with EDO ram only has ~36MB/s.
<geist> but then by the time a P90 came out (1994) it would have outclassed it by a long shot
<geist> if nothing else because it was many years later, had a 60mhz bus, etc
<geist> ah possibly yeah
<mrvn> I think P90 usualy had 33MHz bus-.
<geist> what i duno is what the pipeline of an 060 looks like
<geist> i thought so too but just looked it up and it said 60. but that actually doesn't make any sense
<mrvn> I only remember it had some, was superscalar.
<geist> yah wikipedia and other ones say the whole P54 line was 50-66mhz bus, depending
<mrvn> probably only with expensive motherboards
* geist shrugs
<geist> anyway, 68k was a pretty good competitor until it just stopped competing
<mrvn> and comodore ruined the Amiga
<geist> by late 90s it was starting to get seriously outclassed. motorola wasn't keeping up
<clever> from what ive heard, the major power for the amiga was all of the hw accel outside of the cpu
<mrvn> that was a big part of it
<geist> right, definitely the case with the early amigas, which were fairly slow cpu wise, but didn't matter
<geist> or at least fairly slow in that they weren't special
<geist> ie, mac had similar cpu, etc
<clever> the pistorm guys have even been trying to replace the m68k in a mac with an rpi
<mrvn> Amigas where used for video editing a lot, even years past their prime because they could perfectly sync to the CRT and do special effects in sync.
<clever> but a lot of the rom stuff is based around amiga
<mrvn> mac? I thought the pistorm boards where for actual amigas.
<geist> there was a generic processor card slot there for a lot of the macs, and folks have been making upgrades there left and right
<clever> pistorm can basically replace an m68k cpu, in anything that used an m68k
<clever> you just have to adjust how the kickstart rom and zorro3 cards are working, to suit the new motherboard
<geist> yah, if there's a slot that's basically the bus all you really need is a card to get to the right pinout
<mrvn> and bus protocol
<clever> during boot, the reset vector is somewhere around 0 or 4 i think
<clever> and the kickstart rom is mirrored from its normal addr to 0
<mrvn> 4 is the address of the exec.library
<clever> and from there, it will jump to the proper addr of the KS rom
<mrvn> I think reset is 0.
<clever> and then the rom can instruct the mapper chips to turn the mirror off, so ram gets mapped to 0
<clever> but now you have the question, how does the mapping get changed? what addr is the rom actually at?
<mrvn> copying the rom to ram and reseting is actually a great way to speed up your amiga.
<clever> does mac and amiga use the same mechanism?
<clever> mrvn: but that also requires patching the rom, because of a lot of absolute addressing
<clever> in the case of emu68, it can optionally accept a KS rom via the initrd path in the rpi bootloader
<clever> and then it emulates the rom in "fastram"
<mrvn> it's a well established practice. don't think there is actually that must copying going on since all the access is relative to the library base address.
<clever> so any requests to the rom, get directed to the pi's dram
<clever> but you still also have to deal with the zorro3 cards
<clever> its kinda pci-ish
<clever> where you can configure each expansion card in order, reading the size of its features, and assigning an addr
<mrvn> I think it's more PCIe-ish. pci was a step back in flexibility.
<clever> emu68 will hijack attempts to do that with the motherboard, and inject its own expansion cards first, then let requests go thru to the motherboard
<clever> from what i heard, its more pci then pcie
<clever> out of reset, all cards are in a no-op mode
<clever> and via a daisy-chained signal, you put the 1st card into config mode, and it will appear at a fixed addr
<mrvn> way better than ISA and plug&play (and way before plug&play)
<clever> you can then inspect its config, and set its final addr, and tell it to enter normal mode
<clever> and the daisy-chained signal will then cause the next slot in the system to enter config mode
<clever> so you can repeat the process
<clever> unlike pci, you cant change the config afterwards, like how the pci config space is accessible forever
<clever> and one of the things you can map, is an expansion rom
<clever> which gets executed during boot, and can mutate the library system
<mrvn> but how often do you want to do that? It's not like you first boot into 16bit mode and the bios configures it, then 32bit mode and the bootloader configures it and then 64bit mode and the kernel configures it.
<clever> yeah, it also had no need to reconfigure things
<clever> emu68 uses virtual zorro3 cards to inject a device-tree and sdhost driver into the system
<clever> so your SD card shows up as a standard hard drive
<geist> re: reset, i think 040 (or maybe 030) can remap it
<clever> and other drivers can query the DTB that the firmware passed in
<geist> there's a control register with the vector base address
<mrvn> geist: yes
<geist> but of course initial reset was at 0 i'm sure
<geist> dont think there's a pin to strap it to something else
<mrvn> geist: you boot, copy rom to fast ram, reconfigure the control register, reset
<clever> in the case of emu68, the rom address is mapped to the rpi's dram, so your already in fast ram
freakazoid333 has quit [Read error: Connection reset by peer]
<mrvn> Which also means you can copy a rom file from disk to ram and then reboot into it.
<clever> oh, that reminds me about the whole kickstart floppy
<clever> they basically shipped units before the rom was finished
<clever> and included a battery backed sram card, to act as a rom replacement
<clever> and on first boot, it would initialize it from floppy
<mrvn> clever: the first amiga didn't have the rom at all. just a bootloader.
<clever> yeah
<mrvn> And not like PCs where you get a blinking "_" and then "no boot medium found". Nah, you get a graphical, animated prompt to insert the boot floppy.
<clever> yep
<clever> thats just showing off :P
<geist> yah i remember seeing one of thse modern amiga fixit things and one of the upgrades is to add more roms that has kickstart already in it
<mrvn> Only think they didn't have was heavenly music like MACs had.
<mrvn> geist: there are also upgrade kits to have multiple roms with a little toggle switch to select.
<mrvn> Like when you want an old ROM for some games that stopped working.
<mrvn> Never saw much point in that myself. As soon as you have fast ram you want the rom in fast ram and then you can load it from anywhere. No rom needed.
<clever> i dont know how exactly it works, but whdload somehow sets up VM's to deal with that
<clever> allowing you to patch compatability issues
<clever> and run different roms
<clever> i think even x86 was doing similar, bios shadowing, where you cover the bios addr up with ram, and copy it over
<clever> but modern bios are on spi flash, which becomes an actual bottleneck
<mrvn> Any proper code doesn't care since all the library interfaces had versioned functions and backward compatibility.
<clever> not a parallel rom directly on the same bus as everything else
<clever> i also discovered that the pistorm guys also have irc, #pistorm
<mrvn> here?
<mrvn> (libera)
<geist> yah i discovered the Rosco 68k thing has a fairly active Discord channel
<clever> yeah
<geist> lots of folks building boards for it, powering unices, etc
<geist> porting
<clever> > Even more bridged channels at : #pistorm-hardware #pistorm-amiga #pistorm-pi #pistorm-firmware #pistorm-chat
<mrvn> geist: how much ram does your board have?
<clever> mrvn: and a number of the discord channels are bridged, each to a diff room
<clever> bbl
<geist> 1MB but i also ordered the 4MB expansion board
<geist> just no chips, sicne there's some lead time on that
<geist> it's just using straight SRAM so cant easily cram a ton of memory on it without a dram controller
<mrvn> Nothing compared with the 130MB I have: 8-P
<geist> using 512kx8 sram which i think are some of the biggest dips you can get for fairly cheap
<gog> 130MB of SRAM?
<gog> nice
<mrvn> 2MB chip + 128MB 60ns SIMMS
<geist> yah woud need dram to go faster
<mrvn> or 50ns, can't remember
<geist> OTOH that means the SRAM on this thing is probably zero wait state
<mrvn> probably a lot faster than my chip ram since there is no gfx chip using half the cycles.
<geist> yah that too
<mrvn> chip ram is so slow you can convert chunky to planar at the speed of memcpy.
<mrvn> You decode some mpeg2, convert yuv to 256 colors and the bottle neck is writing the frame to 8 bitmaps for the gfx chip.
<mrvn> geist: does your board have the address/data bus exposed on some pin header? Can you add some extra boards like a graphics card?
<geist> yeah
<klys> which board are we talking about? r.pi4b ?
<geist> looks like there's a lot of folks building custom addon boards
<geist> rosco m68k. ordered one on tindie a few weeks ago
<klys> ah thx
<zid> could build it a 4 bit adder now, we have the schematic
<bslsk05> ​rosco-m68k.com: Home - rosco-m68k.com
<mrvn> geist: I have like 90% of a composite video board using some video ram and 74xxx chips.
<geist> it only has a single pin header, but i think folks have already made addon boards with more slots and bus transceivers etc
<mrvn> just use a through header and bus transceiver chips.
<Ermine> oh, m68k
GeDaMo has quit [Remote host closed the connection]
<bslsk05> ​findcomponents.net: PICO-69420 - Micro Chip Call 516-826-6200 - Call 516-809-7960
<gog> nice
<geist> fun thing about 68k is it's still quite hobby osdev hackable
<mrvn> it's fun to design a state machine for composite video in hardware. Just a bunch of counter register to trigger state changes and you have the hsync, vsync and data bits for greyscale composite output with a 16MHz clock.
<mrvn> Does the rosco-m68k have an fpga on it?
<mrvn> left top is the 68k. left bottom I guess is 4* ram. What are the 3 chips right top and the square thing right bottom?
<mrvn> Is the square thing the UART?
Likorn has quit [Quit: WeeChat 3.4.1]
<mrvn> *waiting for pizza, sigh*
<gog> i don't wanna wait/for my pizza to be delivered/i want to eat right now/i'm so hungry
<papaya> I feel that
<papaya> waiting is the worst
<zid> I want pizza money
<gog> best i can do is 380isk
<zid> eve or rl? :P
<gog> rl :p
<zid> I think I have like 10B in eve ISK, I don't think that's much pizza though
<kazinsal> 1b EVE ISK = 1800 RL ISK
<kazinsal> based on napkin math of current PLEX prices
<zid> £2.27 apparently, 380 ISK
<zid> so I just need about 6x that much
<clever> mrvn: thats also basically how all video outputs on the rpi work, the trigger points for each counter are just configurable
<clever> plus an optional set of vertical params for the odd field
theruran has quit [Quit: Connection closed for inactivity]
freakazoid333 has joined #osdev
<geist> mrvn: it has i think a PLA or two
<heat> https://github.com/heatd/Onyx/commit/0888ad60c00b834cc82ce73922066e5e4aa236af <-- satisfying 1 line commit that fixes my whole boot process
<bslsk05> ​github.com: bootmem: Fix bug in bootmem_remove_range · heatd/Onyx@0888ad6 · GitHub
<heat> also a great reminder that I should boot the images in CI
orthoplex64 has quit [Quit: Leaving]
<mrvn> heat: why not &phys_ranges[nr_phys_ranges] - &phys_ranges[index + 1]?
<mrvn> or sizeof(phys_ranges[0])?
<mrvn> Also: shouldn't you memmove? The ranges are overlapping
<heat> the memcpy works because I'm copying back
<mrvn> it's code that works but not correct code
<heat> the C++ standard committee can submit a pull request if they so choose
<heat> :P
<mrvn> then you get nice std:Array and ranges or views
<heat> >ranges
<heat> nah thanks
<heat> i'm good with, erm, normal arrays
<mrvn> range checked operations are a lot safer
srjek has joined #osdev
<mrvn> Wouldn't it be nice if the compiloer would warn about the previous code? sizeof(phys_range) should return a integer tagged as sizeof "memory_range*" and then warn about using a "memory_range*" size argument where a "memory_range" size argument was expected.
<mrvn> Is that code parsing the memory map from x86_64 or riscv?
<heat> it's generic code
<mrvn> Are the memory infos for both archs that similar?
<heat> erm, it's just memory?
<heat> (start, end)
<heat> or (start, size) if you prefer
<mrvn> it's an array of entries describing memory regions.
<heat> for *allocation*
<mrvn> so yeah, pretty generic I guess.
<bslsk05> ​github.com: Onyx/multiboot2.cpp at master · heatd/Onyx · GitHub
<bslsk05> ​github.com: Onyx/multiboot2.cpp at master · heatd/Onyx · GitHub
<heat> i haven't found a need to describe memory regions further anyways
<mrvn> hmm, that fails on some real hardware. mmap entries overlap
<heat> I haven't found hardware that does that
<heat> certainly not UEFI
<mrvn> I had some. verry annoying.
<mrvn> Had like a big chunk of 4GB available mem and then later in the middle of that a small entry reserved.
<Griwes> I'm very tempted to just outright not support platforms that do that
<mrvn> I think it was the PCI hole in the lower 32GB and the bios just added that as a unavailable entry without splitting up the available memory entry.
<mrvn> lower 32bit
<heat> that's not good but it's also something I could easily solve by doing bootmem_reserve
<heat> it's really nice to have a stable bootmem facility for once
<mrvn> I did 2 loops. First add all available ranges and then a second loop removing all non-available (if its marked available)
<heat> boot is way more resilient *if I don't screw up memcpys*
<mrvn> heat: I would still prefer sizeof(phys_ranges[0]) there instead of the type behind the array. I always fear that someday the array type could change and then it's broken again.
<gog> lööp
<mrvn> I wonder when gcc/clang will warn about the memcpy because it violates the restrict qualifier of the builtin type.
<mrvn> I can't believe I'm saying this but I think I ate too much pizza. Can one eat too much pizza?
<bauen1> mrvn: please don't overdose on pizza, that'd be very unfortunate
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
Likorn has joined #osdev
<papaya> overdose on pizza? no such thing
<zid> depends how much heroin you have on it
<bauen1> papaya: i'm sure there are at least several components in a pizza that is toxic at high enough concentrations, so this leaves the question if you can eat enough pizza to reach these levels before you experience too sever side effects from eating pizza that force you to stop
heat_ is now known as heat
<gog> wtk the LD50 of a standard pizza
<heat> mrvn, https://github.com/heatd/Onyx/commit/5fdda7bf56150cb2d05f732a31bec3f28d080a51 I fixed the memcpy UB because you made me feel guilty :(
<bslsk05> ​github.com: bootmem: Fix UB in bootmem_remove_range · heatd/Onyx@5fdda7b · GitHub
<heat> I still don't quite like the sizeof(phys_ranges[0]) suggestion
<heat> it's just not really my style
<heat> I sometimes do it when using malloc() but not elsewhere
vdamewood has quit [Quit: Life beckons]
<geist> mrvn: FWIW the square IC in the rosco board is a 68c681, which is a UART
<geist> a fairly new one (can buy new versions on mouser), that presumably speaks the 68k bus protocol
<clever> the rpi also has a dedicated SMI peripheral, that can speak the 68k bus protocol, as a master
<clever> but it only has a 6bit addr bus
<jimbzy> Ah, so you picked up a rosco kit?
theruran has joined #osdev
gog has quit [Ping timeout: 268 seconds]
<geist> yep! might start assembling it in a few minutes
<geist> going through the parts and printing out stuff right now
<heat> unrelated you should write a unix-like for your vax
enkeyz has quit [Quit: WeeChat 3.4]
<kazinsal> I've considered it but I haven't found much good info on vax bringup
<geist> i basically mostly just dug through what netbsd was doing to figure out the boot mechanism
<geist> it's bespoke, but not too convoluted
<geist> from then on out it's mostly just vax architecture manuals and netbsd source
Burgundy has quit [Ping timeout: 248 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]