<doug16k>
Oli, that bios call only affects new output. the blue line was it scrolling a new line on
<doug16k>
it doesn't mean wipe all the attributes on the screen to that
<doug16k>
ah you mean the hardware background color
<doug16k>
that isn't a thing. only the border has a color, the content gets it from the attributes
<doug16k>
there is no way for "nothing" to be in one of the character cells in text mode
<doug16k>
it's just a lot of whatever its background attribute byte says
<doug16k>
because the glyph it is showing happens to be all background color (0 bits)
<doug16k>
when "blank"
iorem has joined #osdev
<doug16k>
if a bios wiped the screen with that background colour when you invoke int 0x10/ax=0xb00 I would say it is buggy
<doug16k>
I'd be surprised if that was intended to wipe the screen's background attribute
<doug16k>
all existing text that is the same colour disappears
<Oli>
You made me realize that I was wrong in expecting the border to also be the background color of text displayed at the screen in text mode. ax=0b000 int 0x10 changes border color: But in QEMU's default BIOS it also changes text-mode text background color!
<doug16k>
printing with int 0x10 is incredibly slow on most machines
<doug16k>
so slow you sit there pondering how they could possibly have made it that slow
<doug16k>
you start wondering if it was no-cache the whole time it executed rom or something, lol
<doug16k>
you should be able to do about 2M fps in 80x25 text mode on real machine. far far less in qemu, it is hard to emulate text mode video memory, so it is slow
<Oli>
My mind got that thought flying when I changed the language in FreeDOS' v1.3 floppy disk TUI: It seemed to me like I was seeing text changing character by character.
<Oli>
Enphasis on seeing
<doug16k>
if you do direct writes I mean
<geist>
yah that is a good question, why does it take so long on bioses
<doug16k>
geist, I figure it must be terrible memory types
<doug16k>
UC rom or something dumb
<doug16k>
but yeah even in qemu efi it is pretty bad
<doug16k>
that has no memory types
<doug16k>
qemu explanation is it stalling on serial doing that thing where it sends an ansi stream out the terminal to show the screen
<Oli>
I want to clarify that I am describing my experience with FreeDOS' TUI menu booting in my hardware.
<doug16k>
I should say TCG has no memory types. they work in KVM
<doug16k>
and you see a difference in that bios call behaviour between seabios and real machine?
<doug16k>
on your real machine, your video card manufacturer implemented that bios call
<doug16k>
real machine is probably right
<Oli>
In the ax=0x0b00 bx=0x0001 int 0x10? Yes: SeaBIOS in QEMU changes the text background color as if it changed all the text cells' background attribute, while in my harware it changes the border color, leaving the text background color intact instead.
<doug16k>
seabios is wrong
<doug16k>
I would not expect that. I totally expect what real machine did
<Oli>
Yes; I was wrong in expecting otherwise, after getting familiar with SeaBIOS behavior for that BIOS call.
jaevanko has joined #osdev
<doug16k>
I can understand seabios making that mistake. even ralf brown list is vague as hell for that call
jaevanko has quit [Client Quit]
<doug16k>
it doesn't seem like a legitimate thing to do to wipe the whole background to monochrome
<doug16k>
potentially things disappearing or becoming hideously unreadable, like red on yellow
radens has quit [Quit: Connection closed for inactivity]
<Oli>
Thank you so much for pointing this out: I think would have taken me a long time to figure the difference in behavior between, without being aware of BIOS call implementation differences being a posibility for the discrepance I was seeing.
<doug16k>
if you intended to clear the screen to a new background, do that, then clear the screen
<doug16k>
glad my bootloader code doesn't trust the bios to do anything beyond preserve the stack pointer and return
<doug16k>
oh it has to return in real mode without wrecking gdt
<doug16k>
I wonder if I should be really paranoid and lgdt again there lol
<doug16k>
it should
<doug16k>
ah, it already does
<doug16k>
hey, I just realized I can handle a totally asinine bios that returns in 32 bit code segment, by putting a pair of 00 after the ljmp so a 32 bit default will pick up the same offset
<doug16k>
Oli, you increased my distrust of the bios even more by having me look at those bios call's bug lists, lol
<doug16k>
if the bios call doesn't return in long mode, I should be alright :P
<doug16k>
it would be hilarious to put a thing there that detects long mode and branches off to handle it
<moon-child>
I don't trust it...sounds like whichcraft
<Oli>
How could I find SeaBIOS' BIOS call bug list? Looking for related keywords on it's maillist didn't seem to yield many hits for.
<Mutabah>
Do you think there's a bug?
<doug16k>
did you look at the code? it might have a comment
<doug16k>
Mutabah, there's a bios call to change the background color. real machine just changes new output background color, seabios wipes screen with new background color
<Mutabah>
ah
<Oli>
I wonder if I can trust compatibility across different BIOS implementations by writting at text-mode teletype character/atribute area directly.
<doug16k>
if you write video memory directly it will be infallible
<doug16k>
doesn't get much more straightforward than ibm text mode memory
<doug16k>
each character is 16 bits, upper 8 bits is attribute
<doug16k>
half the attribute is foreground, half the attribute is background
<Oli>
No, doug16k; it just changes border color on real hardware; in SeaBIOS it has the effect of as if all character's background color attribute changed
<doug16k>
can be configured so top bit of background is either bright, or flash
<doug16k>
Oli, it changes both
<doug16k>
it changes border and new output background color
<doug16k>
emulator throws away border right?
<doug16k>
there is no border, is there?
<doug16k>
based on what you said earlier. please correct me if I am wrong
<doug16k>
8 bits is way too much information for a color
<doug16k>
it sets both the background and border
<Oli>
I haven't looked up if SeaBIOS changes border too with; indeed, border isn't visible in QEMU for me.
<doug16k>
the letterbox should follow the border colour
gog has quit [Ping timeout: 264 seconds]
<doug16k>
if you maxmized it without scale
<doug16k>
don't think it does though
<Oli>
Wait; you just made me wonder about if SeaBIOS changes a palette color, which uses for text background colot attribute.
<doug16k>
seriously doubt it
<doug16k>
palette changes are brutally slow
<doug16k>
no bios would do that. they didn't have any palette for most of them
<doug16k>
that bios call existed when there was no such thing as a palette
<doug16k>
you have to spin until a blanking interval (often vertical so you have lots of time) then change the palette, or the display will glitch during the palette ram write
<doug16k>
described as "snow" if you rapidly do it
<doug16k>
on real one
<johnjay>
hrm... am i crazy or does scp refuse to copy a file if the parent dir doesn't exist?
<doug16k>
does it ever create directories? I didn't think it did
iorem has quit [Ping timeout: 268 seconds]
<doug16k>
if you did recursive copy, of course it would
<doug16k>
but even then I'd expect the starting place to need to exist
<doug16k>
if it just created the directory, then a buggy script could cause a disaster
<doug16k>
...too easily
<doug16k>
you could ssh a `mkdir -p` before scp
<johnjay>
right that's what i did
<johnjay>
but it seemed odd
<johnjay>
-r would have to create dirs
<doug16k>
scp is one of those things that seems like it would be constant problems, but just works
<Oli>
The bit field of text-mode characters display attributes is this one: 7=blink bit 6-4=background color 3=bright foreground color bit 2-0=foreground color: One can only set brighter colors in foreground.
<Mutabah>
Depends on the VGA controller's configuration, but the above is the standard/default
<doug16k>
ah right I used wrong term. s/flash/blink/
<doug16k>
hardware accelerated blinking
<doug16k>
seemed like a good idea
<doug16k>
it does work well for drawing attention to a distant display
<clever>
i dont know the details, but the color code for blink, seems to bypass the screen blanking in the linux text console
<clever>
so blinking text is still visible when "blanked"
<doug16k>
yeah blink usually isn't emulated right
<clever>
maybe its a feature?
<Oli>
Flash is the analogous term for blink on the ZX spectrum
<doug16k>
yeah, I think everyone agrees blink drives you nuts
<doug16k>
don't do it
* clever
heads off to bed
<geist>
wow that's early for you clever
<clever>
lol
<geist>
usually you're up for another 6 or 8 hours
<clever>
i'm trying to get to bed at a reasonable time :P
<Oli>
I recall blinking text being particularly effective in Apple 2's Ultima RPG for warning me that my character was under attack.
<doug16k>
clever, now is very reasonable. good job
<geist>
hmm, kinda curious now how apple 2 circuit specifically implemented blink
<geist>
everything about apple 2 circuit was a clever woz hack, so he probably found a neat way to do it
<geist>
or, it's ust a counter somewhere
<doug16k>
hard to imagine something other than a counter, but could be
<geist>
possibly something like the A15 line of the refresh logic, etc
<doug16k>
maybe did something smart to make the blink rate configurable
<geist>
which iirc was tightly integrated with the video logic which ran continually
<geist>
iirc while you were holding reset it didn't blink, which may be a clue there too
<geist>
but the video logic still ran or the screen would stop
<doug16k>
sounds like the did a good job handling the reset then
<doug16k>
blink can't work when held in reset state, by definition(?)
<doug16k>
it's philosophical
<Belxjander>
scp does two passes for recursive operations... first pass is directory creation... whole tree... then second pass is actual file by file copying... and is not actually 100% reliable...
* Belxjander
has seen scp operations and how it works for having an "scp" based component in the AmigaOS "ssh-handler" FileSystem implimentation...
<Belxjander>
I can drag-n-drop files from one machine to another after mounting any ssh accessable target as "just another HDD" on my desktop
<Belxjander>
and that is how the recusive directories are handled...
<Belxjander>
2 passes with folders then files
<Belxjander>
but for the CLI variation... It has always refused to copy folders and only done single-depth file sets to the same target folder location
riverdc has joined #osdev
<riverdc>
anyone know of a single-board computer with an onboard sound card?
<riverdc>
I thought the raspberry pi would work but apparently it uses PWM rather than a proper DAC
<Oli>
Raspberry Pi
junon has quit [Remote host closed the connection]
<Oli>
It's GPIO supports pulse width modulation; it's audio hardware outputs to a jack 3.5.
<riverdc>
not sure I understand what you mean by "GPIO supports pulse width modulation"
<riverdc>
but regardless, PWM is what I'm trying to avoid
<Mutabah>
Why are you wanting to avoid it?
<Oli>
The hardware itself supports sending PWM signals through some of it's general purpose input/output pins: Unrelated to it, the Raspberry Pi has a normal PCM sound hardware with a jack 3.5 output.
<Oli>
That same jack 3.5 has 3 channels; audio L and R channels, and a composite video channel
<riverdc>
Mutabah: I understood PWM to be sufficient for simple sounds like UI beeps but not great for stuff like music. is that not right?
<Oli>
You are right: Pulse width modulation is a technique that can be used to move 1 bit piezo speakers faster than they reach their extremes, allowing it to produce more complex sound waves than they otherwise could.
<riverdc>
right, ok
<riverdc>
Oli: I thought the 3.5mm jack was also limited to PWM for some reason
<riverdc>
but it sounds like I'm mistaken, in which case, great! rpi should work then
<Oli>
A sound card with DAC allows to send signals that can place a speaker's magnet more accurately, allowing a more pristrine audio representation of digital pulce code modulation.
<Oli>
Yes; it supports what you describe seeking.
<Mutabah>
Also, fast enough PWM can be used to provide a semi-decent dac
<Oli>
Pulse width modulation can be used in cases a DAC isn't in the middle.
<Mutabah>
Although probably not quite at audio frequencies
<Mutabah>
Hmm... 22kHz audio with 8 steps = ~170kHz PWM frequency... fast, but not excessively
<riverdc>
looks like the onboard pi sound card doesn't have a DAC
<riverdc>
the project i have in mind is audio-focused so I don't think it would be the best choice
<Oli>
The possibility of outputting higher audio frequencies depends on clock speed of the oscillator/CPU emiting the signals. It can be demanding for a CPU.
<Oli>
The Raspberry 3b+ has a onboard audio hardware with DAC.
<riverdc>
Oli: could you link me to where you're getting that info?
<Mutabah>
Could you get an external USB sound card?
<riverdc>
Mutabah: yeah that could work. I just want to use something well documented so that writing a driver for it isn't too hard
<riverdc>
there are also add-on hardware kits for the pi for alternative soundcards, but I was concerned they might not be documented enough for writing my own driver
vdamewood has quit [Quit: Life beckons]
<riverdc>
Oli: nevermind, I found the relevant section in the pi 4 SoC datasheet. looks like you're right
<doug16k>
the ROM can't reach down to 0x200000 - too far away
<doug16k>
so what I do is map the 1st GB again at 4GB line
<doug16k>
UNRELOCATED subtracts 4GB
<gog>
ah i see
<doug16k>
after paging on not needed
<doug16k>
only needed for RAM stuff
iorem2 has quit [Quit: Connection closed]
<doug16k>
I don't touch any memory below 2MB line ever
<doug16k>
er, 1MB line
<doug16k>
stack is between 0x100000 and 0x200000
<doug16k>
ram memory begins at 0x100200000 as far as link knows
<doug16k>
when paging goes on I bump rsp up to above 4GB to same place
<doug16k>
so I stop touching the other alias
flx has quit [Remote host closed the connection]
flx- has joined #osdev
<doug16k>
MTRRs are off so my qemu patch is showing that
<doug16k>
I should submit it before the code changes out from under me and breaks patch, lol
<doug16k>
need to implement klange's good suggestion
<gog>
what's that?
<doug16k>
when it is a contiguous region, elide it with ... like a hexdump might
<gog>
ah yes
<doug16k>
just show beginning and end
<doug16k>
if same permissions and flags etc
<klange>
my hero~
<gog>
really though it's been months since you did this
<gog>
time to PR :p
<doug16k>
gog, you are right
<doug16k>
heat found a bug with his page table flags with it
<doug16k>
memory types I mean
<doug16k>
I also feel compelled to make TCG throw exceptions more than never when writing values to registers that are supposed to throw
<doug16k>
I'm at the point where I'm not sure if anything except MSR writes can throw
<doug16k>
it's full of comments that say /* XXX: should throw exception */ and just return
elastic_dog has quit [Ping timeout: 268 seconds]
<doug16k>
feel sorry for poor saps that thought testing it on qemu meant it had a chance to work on real machine
<doug16k>
bochs throws all the things
<doug16k>
bochs has qemu defeated completely as far as behaving correctly
<doug16k>
I mean, TCG
<doug16k>
bochs isn't even sure TCG emulates an x86 :P
<doug16k>
"must be some other processor"
<doug16k>
it's not good, seriously. tons of stuff that should throw #GP doesn't
<klange>
QEMU was very much written to run things that already worked, quickly.
<doug16k>
exactly
<doug16k>
it handles what a real kernel really does
<klange>
Can you make the APIC implementation not accept a quadword write to the EOI register, because my old Westmere ignored that completely.
<j`ey>
I found a similarish bug in the aarch64qemu
<doug16k>
should be doable
<j`ey>
a bit is set to trap on the next instruction.. but it just doesnt do it
<klange>
Had a couple of people arguing over whether it should have been a GPF, but as far as I can tell it just did nothing on the real hardware.
<doug16k>
it is undefined, so your machine did the right thing I think
<doug16k>
the manual says it is "implementation defined" what happens and "please access it correctly with 32 bit accesses"
<doug16k>
I think at least an output to -d guest_error would be trivial and nobody would mind
<doug16k>
I made it write some stuff there if you do UB on nvme
<doug16k>
along with the modern style tracing patch
elastic_dog has joined #osdev
<doug16k>
-trace 'nvme*'
<doug16k>
if I can find a manual citation saying it could throw I'd make it throw
<doug16k>
it's pretty bad and hard to hunt down irq related bugs, should try to help dev
<doug16k>
I could have sworn I added some exception throwing that occurs when you write reserved MTRR bits, but I can't find it in the diff
<doug16k>
the MTRRs are basically 32 bit scratch registers in TCG :P
<doug16k>
I should detect qemu and write "LOLO" "LOL" across them in TCG
<doug16k>
then sit in a loop writing random numbers to cr4 for a few seconds
<doug16k>
then next like says, // j/k and puts it back
<doug16k>
have a "TCG MTRR test" that writes the values 0 thru 0xFFFFFFFF to each one and prints "MTRRs memory test passed" :P
<doug16k>
(it should #GP)
asymptotically has joined #osdev
dormito has quit [Ping timeout: 272 seconds]
pretty_dumm_guy has joined #osdev
merry has quit [*.net *.split]
Amanieu has quit [*.net *.split]
sm2n has quit [*.net *.split]
moon-child has quit [*.net *.split]
Griwes has quit [*.net *.split]
ids1024 has quit [*.net *.split]
Benjojo has quit [*.net *.split]
nur has quit [*.net *.split]
HeTo has quit [*.net *.split]
Lucretia has quit [*.net *.split]
jstoker has quit [*.net *.split]
bleb has quit [*.net *.split]
Patater has quit [*.net *.split]
Affliction has quit [*.net *.split]
manawyrm has quit [*.net *.split]
pbx has quit [*.net *.split]
Stary has quit [*.net *.split]
ornitorrincos has quit [*.net *.split]
puck has quit [*.net *.split]
yuu has quit [*.net *.split]
ccx has quit [*.net *.split]
remexre has quit [*.net *.split]
yuriks has quit [*.net *.split]
meisaka has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
Benjojo has joined #osdev
Amanieu has joined #osdev
merry has joined #osdev
Patater has joined #osdev
ccx has joined #osdev
ids1024 has joined #osdev
HeTo has joined #osdev
sm2n has joined #osdev
Griwes has joined #osdev
jstoker has joined #osdev
moon-child has joined #osdev
bleb has joined #osdev
Lucretia has joined #osdev
Affliction has joined #osdev
pbx has joined #osdev
yuu has joined #osdev
puck has joined #osdev
manawyrm has joined #osdev
Stary has joined #osdev
ornitorrincos has joined #osdev
yuriks has joined #osdev
remexre has joined #osdev
gruetzkopf has joined #osdev
meisaka has joined #osdev
sm2n_ has joined #osdev
dormito has joined #osdev
sm2n has quit [Ping timeout: 265 seconds]
IRCMonkey has quit [Quit: .oO (bbl tc folks~!)]
ccx has quit [Ping timeout: 265 seconds]
ornitorrincos has quit [Ping timeout: 265 seconds]
ornitorrincos has joined #osdev
dutch has quit [Quit: WeeChat 3.1]
dutch has joined #osdev
dennis95 has joined #osdev
transistor has quit [Ping timeout: 244 seconds]
mctpyt has quit [Ping timeout: 272 seconds]
transistor has joined #osdev
isaacwoods has joined #osdev
<doug16k>
nice, got it so same source (except linker script) can build rom for i686 or x86_64
<doug16k>
so for arm it should just be new startup code, linker script, and arch_pci_read/arch_pci_write, bunch of crap for configure of that compiler
<klange>
\o/ I actually modeset my t410 to its native panel resolution of 1440x900 by poking the gpu!
<klange>
max it exposes over vesa is 1280x800, _but_ in that mode it has the timings all configured for the full resolution and is doing hardware scaling
<klange>
so I didn't have to do much - just turn the pipeline off, update the source size to 1440x900, turn the pipeline back on, then update the linear framebuffer stride to 1440*4 and it works :D
isaacwoods has quit [Quit: WeeChat 3.1]
iorem has joined #osdev
Oli has joined #osdev
Oli has quit [Ping timeout: 245 seconds]
iorem has quit [Ping timeout: 268 seconds]
ahalaney has joined #osdev
Oli has joined #osdev
alexander has quit [Ping timeout: 272 seconds]
mahmutov has joined #osdev
nyah has joined #osdev
alexander has joined #osdev
iorem has joined #osdev
MarchHare has joined #osdev
dennis95 has quit [Read error: Connection reset by peer]
dennis95 has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
simpl_e has joined #osdev
srjek has joined #osdev
mahmutov has quit [Ping timeout: 272 seconds]
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
nur has joined #osdev
iorem has quit [Quit: Connection closed]
janemba has joined #osdev
alexander has quit [Ping timeout: 264 seconds]
gmacd has joined #osdev
Oli has quit [Quit: leaving]
mahmutov has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
amanita has joined #osdev
<NieDzejkob>
so, how do microkernels work? For example, how is the usual filesystem API implemented? I've read somewhere that the hurd equivalent of Linux's namespaces would be done by spawning a separate e.g. PID server. Does that mean that processes are implemented outside of the kernel somehow?
gmacd has quit [Remote host closed the connection]
<clever>
NieDzejkob: my rough understanding (as an outsider), is that the filesystem driver itself runs in its own process, and any actions to a file are just an RPC from the program wanting to act on a file, to the filesystem driver
<kc8apf>
yup, that
<clever>
NieDzejkob: the root dir or working dir, is just a handle that the rpc can act on, being passed to you when your proc starts
srjek has quit [Ping timeout: 252 seconds]
<clever>
chroot would just be passing something that isnt your root, as the root pointer to your child
<NieDzejkob>
And how does the process know where to find the filesystem server? How does it establish the IPC connection?
<clever>
NieDzejkob: an IPC handle to that is passed to the process when its created, by the parent process
<NieDzejkob>
is it like a standard fd?
<clever>
depends on how you implement the IPC
<NieDzejkob>
(I mean, it could be whatever...)
<kc8apf>
For the Cortex-M microkernel we're writing at work, all tasks are known at compile time and task handles are a tuple of (reference to task structure, generation #)
<j`ey>
kc8apf: in rust?
<kc8apf>
in a more general-purpose microkernel, you often have a few bootstrap tasks that have well-known names. One of those bootstrap tasks is a lookup service for other tasks
<kc8apf>
j`ey: yes
<j`ey>
nice
<j`ey>
not open source?
<kc8apf>
not yet. Much of the design is still heavily in flux.
<clever>
my rough understanding, is that the microkernel would load a userland bootstrap process (maybe the binary is baked into the kernel at link time, or passed like an initrd blob)
<kc8apf>
we keep reevaluating when to open it up. Definitely will be before product launch. Main concern is not having enough bandwidth to foster community around it
<clever>
that bootstrap process, receives handles for driver stuff (irq's/mmio) and the process table
<clever>
it is then responsible for creating the block device server, passing it a handle to the hw
<clever>
then creating a filesystem server, passing it a block device handle
<clever>
then creating other servers, and passing them filesystem handles
<kc8apf>
clever: yup. That's certainly how Mach works. Pretty sure seL4 as well
sm2n_ is now known as sm2n
Oli has joined #osdev
<Oli>
I just tried using ah=0x0e int 0x10 to print text in a first stage bootloader, and while it works in my real hardware, it doesn't in the hardware a familiar of mine is using: However, writting to video memory directly works on both. I wonder why?
<Oli>
BIOS call*
skipwich has joined #osdev
<GeDaMo>
In what way does it not work?
<NieDzejkob>
Oli: post the code
<NieDzejkob>
what do you set BX to?
<Oli>
It didn't print the string of text my code uses ah=0x0e int 0x10 to. It just ocurred me to double check the value of the segment registers now. Here's the aforementioned bootloader code: https://pastebin.com/raw/xQh7MUzi
skipwich has quit [Changing host]
skipwich has joined #osdev
<Oli>
BX is set to 0
<Oli>
xor bx, bx sets bx to 0
<Oli>
This code uses intel syntax of GNU's assembler
<Oli>
The "Booting operating system..." string gets printed in my hardware, but it doesn't in my familiar's one.
<Oli>
The 'D' character I write at video memory gets printed in both hardware
<Oli>
There was previously a defined MBR_MEM_OFFSET symbol pointing to 0x7c00 before I set the data segment register to 0x07c0 (0x07c0*16=0x7c00), please ignore it.
<Oli>
set to*
amanita_ has joined #osdev
<GeDaMo>
Could it be the direction flag?
amanita has quit [Ping timeout: 272 seconds]
amanita_ has quit [Remote host closed the connection]
<Oli>
I currently find myself looking for information about direction flag, and reading OSDev wiki's segmentation article: Reading your message is the first instance I am conscious of hearing about in this context.
<Oli>
You just made me realize that I should read the i8086 processor manual before even talking about things differing from working. Thank you so much for sharing about, GeDaMo!
<GeDaMo>
I don't really expect it to be that but it's worth a try :P
<j`ey>
Oli: have you tried with bochs?
<j`ey>
it seems like that might be stricter than qemu
<Oli>
After being hinted at that the data segment value after transfering the program flow to a boot loader is undefined, and setting it myself instead of assuming it being 0 made that code work in my hardware, I think that it is a good idea to be extra sure and initialite what I use to ensure it is what I want it to be.
<Oli>
I am currently into trying up bochs instead of QEMU; however in this context, I am aiming to figure out discrepance between two different hardware's behavior.
Oli has quit [Quit: leaving]
Oli has joined #osdev
<Oli>
ls
<Oli>
LOL
<Oli>
My bad.
<j`ey>
Oli: everyone does it!
<GeDaMo>
Misfenestration :P
<nur>
geist, thanks for the information from last night about FUNCTION and END_FUNCTIOn in assmebly, but did you mean .func and .endfunc?
SwitchToFreenode has joined #osdev
srjek has joined #osdev
Oli has quit [Quit: leaving]
<z_is_stimky>
awoo
<geist>
nur: oh i was pointing out that you can make a macro
<nur>
hm?
<geist>
nur: which assembler are you using? if it's nasm i dont know
<bslsk05>
fuchsia.googlesource.com: zircon/kernel/include/asm.h - fuchsia - Git at Google
<geist>
the cfi_endproc is one thing, but the key is the .size one
<geist>
basically it sets the size of the symbol for the function
radens has joined #osdev
<nur>
ahhh okay
<nur>
is ".cfi_startproc" and ".cfi_endproc" a standard thing?
<kazinsal>
it's a directive that tells as/ld that a function's call frame information should be included in .eh_frame
<nur>
what is .eh frame
<kazinsal>
it's for unwinding call frames in structured exceptions
<nur>
...do I want that?
<kazinsal>
I'm going to leave that question up to someone who actually writes code that uses structured exceptions
<geist>
nur: if you dont know what it is you probably dont need it, for now
<doug16k>
nur, you want stack traces, so you probably want the have the directives in assembly. at least just enough to make the stack trace usually work
<geist>
right
<nur>
what is a structured exception
<doug16k>
nur, it's a type of control flow where the code forces is forced to return from each function until it reaches a handler, cleaning up things on the way if necessary
<doug16k>
like throw/catch
<nur>
ah
<doug16k>
setjmp/longjmp
<nur>
but that doesn't happen in an interrupt handler does it
<doug16k>
when doing a stack trace, it pretends to do that unwinding, to find the caller(s)
<doug16k>
...but doesn't actually unwind it
<doug16k>
let's say there was a #GP. the stack frame has the caller's ss esp eflags cs eip. you can add the directives that tell it how to get back, using that funny format stack frame
<doug16k>
that's probably the one stack trace you want the most - which thing threw an exception
<nur>
gosh this is complicated
<nur>
how did y'all learn all this
farcas has joined #osdev
<kazinsal>
many decades of servitude to our dark lord and master, ba'al zevuv
<nur>
does he provide health insurance
<kazinsal>
a little known fact is that hell is actually located in canada
<kazinsal>
by daylight it goes by the cover name of "edmonton"
alexander has joined #osdev
river has joined #osdev
Sos has joined #osdev
<Sos>
ahh here it is
<Sos>
hi
<geist>
hi!
<kazinsal>
aloha
<geist>
you got lost after the freenode thing?
<Sos>
haha not much, jsut sad a bit
<Sos>
but yeah i joined #uefi ##uefi and #posix-uefi before wending up here
<Sos>
was reading up on posix-uefi and wanted to see if I can get a thing working without an entire OS
<Sos>
gonna need graphics and sound for it. and as graphics sound straightforward in UEFI...
<doug16k>
it also has a usb host controller in it?
<doug16k>
s/\?/!/
<doug16k>
type-c!
<geist>
Sos: right, you can't keep usig UEFI after ExitBootServices
<geist>
except for a few calls explicitly set aside for it
<geist>
it's because UEFI loses its context and control over hardware. once you start futzing with it youself it doesn't know whats going on
<geist>
it's explicitly not intended to be a runtime driver abstraction
<Sos>
can i... never call ExitBootServices?
<GeDaMo>
The boot never ends :|
<doug16k>
yes
<kazinsal>
"can" and "should" are two drastically different things
<doug16k>
you can Exit() or return from main
<kazinsal>
"can" you? yes
<kazinsal>
"should" you? sweet infernal hades no
<Sos>
why, tho
<doug16k>
it is possible to make efi application that is not a bootloader, but unusual
<Sos>
that soudns like something I'm looking for
<kazinsal>
the boot services are intended to only work in a way where UEFI is the "OS" and the thing calling them is the "program"
<Sos>
I mean, with UEFI bastractions, I can load files, read inpout and display stuff, whyI don't really need anythign beyond that
<geist>
well, you can write a single threaded app in uefi sure
<kazinsal>
because you don't *really* have control of the machine
<geist>
good for single threaded uefi apps
<geist>
but you're running mor eor less in a DOS like environment
<kazinsal>
you are beholden to the requirements of a UEFI application
<geist>
so, if that's what you're happy with, sure.
<radens>
Programming in uefi isn't half bad imo, it's just like writing a windows driver.
<geist>
sure. but there are limitations to what you can do. so eventually you'll want to exceed those limitations and then you have to throw out all of this stuff you did
<radens>
yeah, I try and put my stuff in a lib which can be reused these days.
<radens>
And then link against a thin abstraction over uefi
<kazinsal>
yeah, and chances are everything you've written is so tightly integrated into the UEFI API that your own new native core is going to have to pretend it's the UEFI environment
<Sos>
what are the limitations?
<Sos>
can't seem to find info on that
<doug16k>
I/O is probably done with polling. single threaded
<doug16k>
those are the most crippling ones
<radens>
Well you can run across all cores pretty easily, so you can do work in parallel
<doug16k>
there is very limited support for starting code on other cpus, but they can't call any APIs
<radens>
And there are events which can be used for signaling like semaphores
<Sos>
ahh, no threads sounds like no audio
<doug16k>
there are timers though, so you can make it spam check the device
<doug16k>
I haven't done any uefi driver dev, can't say whether irq driven stuff is doable
<Sos>
irq would work
<Sos>
irq would work
<Sos>
alright guys, thanks, that's very helpful!
<Sos>
I'm gonna give it a shot and see if I can get anything actually running
dennis95 has quit [Quit: Leaving]
GeDaMo has quit [Quit: Leaving.]
dormito has quit [Ping timeout: 268 seconds]
SwitchToFreenode has quit [Remote host closed the connection]
SwitchToFreenode has joined #osdev
ecs has quit [Ping timeout: 272 seconds]
ecs has joined #osdev
<Sos>
alright, posix-uefi png example has stb_image working
<Sos>
and mouse keybaord support so nice
<Sos>
that's everything i need
<Sos>
if i won't get audio working i'll just bleep the pc speaker
<Sos>
no math functions hmmm.. msot of themare jsut single isntructions so should be fine
dnny has quit [Quit: dnny]
dormito has joined #osdev
asymptotically has quit [Quit: Leaving]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
pretty_dumm_guy has joined #osdev
alexander has quit [Ping timeout: 272 seconds]
Oli has quit [Ping timeout: 272 seconds]
theruran has joined #osdev
mahmutov has quit [Remote host closed the connection]
<NieDzejkob>
Is there a way to use int 0x10/ah=0x0e with colors?
<NieDzejkob>
I'm playing bootsector golf, so I can't really afford my own vga driver. The nice thing about ah=0x0e is that it handles control characters for me...
<NieDzejkob>
I think I'll just pass on the colors
<doug16k>
ah
<doug16k>
you can do a thing where you do 0e for ascii < 32 and 09 otherwise
<doug16k>
if you want uber small code size you might be able to hack the current attribute by poking into the bios data area
<doug16k>
might be able to just throw everything at 0e then
<kazinsal>
yeah I'd say wrapper it
<kazinsal>
should only be like six or seven bytes
<kazinsal>
hm, 09 doesn't do the teletype bits but iirc 0E keeps the existing attribute