about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 7420Kartik Agaram2020-12-261-1/+2
|
* 7419Kartik Agaram2020-12-261-0/+1
|
* 7418 - baremetal: adjust entrypoint addressKartik Agaram2020-12-264-8/+151
| | | | | | | | | | | We need a few pages of data for the keyboard mappings. If I moved them to some later address I'd be able to keep the nice round starting address unchanged. But that seems like a superficial aesthetic concern. There's really no value in having an array of hex bytes represented in SubX rather than just raw hex. And it's better to colocate data near the handler code which uses it (and which runs instructions SubX doesn't support).
* 7417 - baremetal: drawing on LFB in BochsKartik Agaram2020-12-262-2/+3
|
* 7416 - baremetal: drawing on frame bufferKartik Agaram2020-12-261-6/+17
| | | | | This currently works on Qemu, but not on Bochs. I'm now trying to make sense of https://wiki.osdev.org/Bochs_VBE_Extensions#Using_a_linear_frame_buffer_.28LFB.29
* 7415 - baremetal: locate the linear frame bufferKartik Agaram2020-12-261-6/+55
| | | | | 0xa0000 only contains a single bank's worth of memory-mapped video RAM. The LFB is supposed to have everything.
* 7414Kartik Agaram2020-12-261-14/+14
|
* 7413Kartik Agaram2020-12-261-4/+4
|
* 7412 - drawing pixels to screenKartik Agaram2020-12-264-3/+32
| | | | | This works, but colors are unexpected. 0xff isn't white. Lots of colors are black. Perhaps I need to initialize a palette.
* 7411Kartik Agaram2020-12-261-1/+1
|
* 7410Kartik Agaram2020-12-261-1/+1
|
* 7409Kartik Agaram2020-12-261-1/+1
|
* 7408Kartik Agaram2020-12-261-2/+2
|
* 7407Kartik Agaram2020-12-261-1/+4
|
* 7406Kartik Agaram2020-12-261-0/+2
|
* 7405Kartik Agaram2020-12-264-36/+920
|
* 7404 - baremetal: first example programKartik Agaram2020-12-263-0/+378
| | | | | | | | | | Design choice: all programs will use a graphics mode (1280x1024) with 256 colors. That should be fairly widely available. (It turns out text modes larger than 80x25 are not widely available even among modern emulators. Mu will need fonts sooner rather than later.) Mu will never try to be smart and do things like autodetect your hardware. We _will_ help you modify Mu for your hardware.
* 7403 - baremetal/ for apps without a kernelKartik Agaram2020-12-2611-12/+16
|
* 7402Kartik Agaram2020-12-261-3/+3
|
* 7401 - clean up support for non-Linux platformsKartik Agaram2020-12-2510-205/+478
|
* 7400Kartik Agaram2020-12-252-6/+0
| | | | | Turns out the default 8MB stack is quite enough for the programs I'm currently running.
* 7399Kartik Agaram2020-12-241-3/+3
|
* 7398Kartik Agaram2020-12-232-4/+4
|
* 7397Kartik Agaram2020-12-231-346/+376
| | | | Some manual tweaks to boot.hex.html
* 7396Kartik Agaram2020-12-231-0/+371
|
* 7395 - boot.hex: recognize '1' press on keyboardKartik Agaram2020-12-231-5/+9
| | | | | https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel is right, no need to mess with the status port at the start.
* 7394Kartik Agaram2020-12-231-1/+1
| | | | | | I think https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel has more insight to provide. Among other things the comment about grub may answer the distinction between entry 0x21 and entry 9.
* 7393Kartik Agaram2020-12-232-9/+49
| | | | | | | | | | | | | | Snapshot. Keyboard interrupt being triggered. This was hard to debug until https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel reminded me that I'd forgotten to enable IRQ1 on port 0x21. For a while I was confused by never hitting a breakpoint at the start of the keyboard handler. Then I found https://sourceforge.net/p/bochs/discussion/39592/thread/5e397455 and started skipping one instruction in my breakpoint. I still don't understand the discrepancy between some people installing the handler at entry 9, and others installing at entry 0x21 = 33.
* 7392Kartik Agaram2020-12-231-2/+2
|
* 7391Kartik Agaram2020-12-231-62/+9
| | | | | | | | Turns out we just need a null handler at offset 8 rather than offset 9. If the keyboard handler is indeed at offset 9 as https://alex.dzyoba.com/blog/os-interrupts says (I don't understand why), then the clock handler's at offset 8, which makes sense.
* 7390 - null interrupt tablesKartik Agaram2020-12-231-11/+69
| | | | | Looks like the reset loops stop if we create null handlers for the first 10 indexes in the IDT.
* 7389 - snapshotKartik Agaram2020-12-231-6/+6
| | | | | | | | | | | | | Ok, we're back at the reset loop. Let's keep going; maybe having a decent keyboard handler will fix it. The bug I fixed here was caused by misunderstanding what m16&32 mean in the Intel manual. It's still a regular regmem operand that uses all of the ModR/M byte (which can be interpreted in 16-bit mode, adding to the complication). It's just constrained to not allow direct addressing (mod 00). I needed to better internalize the format of the instruction set references at the start of Volume 2, Chapter 3.
* 7388 - snapshot initializing interrupt tableKartik Agaram2020-12-231-24/+69
| | | | | | | | | | | | | | | | | | | | | | | | | I'm now back at the state of commit 7382 (including 7376). The existing print to screen surprisingly seems to work without reset-looping, but when I step through I notice that the lidt isn't doing what I expect. Desired: at address 0x7cce, the processor executes: 0f 01 1e 00 7f # lidt ds:*idt_descriptor Observed: at address 0x7cce, the processor executes: 0f 01 1e # lidt ds:*esi As a result the next instruction is: 00 7f fb So the `fb` isn't interpreted to enable interrupts. So the problem of commit 7376 is latent. Past this point the instruction stream is lined up again, and everything occurs as it should. Purely by chance. I fully expect all hell to break loose again, like it did in commit 7376, once I debug the lidt encoding. There's still something I don't understand about enabling interrupts. Perhaps I need to fill in more entries in the table.
* 7387Kartik Agaram2020-12-231-3/+4
| | | | | | Redo commit 7381. There was a bug. Current state: commit 7381 excluding 7376.
* 7386Kartik Agaram2020-12-231-2/+3
| | | | Commit 7380 excluding 7376.
* 7385Kartik Agaram2020-12-231-6/+6
| | | | Commit 7379 excluding 7376.
* 7384Kartik Agaram2020-12-231-4/+23
| | | | | Currently at commit 7378 (reset the A20 address line) except without 7376 (enabling interrupts).
* 7383Kartik Agaram2020-12-231-101/+36
| | | | | Currently at commit 7377 except without 7376 (enabling interrupts). Works as advertised.
* 7382 - snapshotKartik Agaram2020-12-231-21/+62
| | | | | Turns out I've been "testing" with a stale file since commit 7373. We need to go over everything since then.
* 7381Kartik Agaram2020-12-231-3/+3
|
* 7380Kartik Agaram2020-12-231-2/+3
|
* 7379Kartik Agaram2020-12-231-6/+6
|
* 7378Kartik Agaram2020-12-231-4/+23
| | | | | | | | Turns out we only had access to 50% of RAM so far. Closing my nose and moving right along.. Though this _does_ give me practice interacting with ports. That'll be handy for the keyboard.
* 7377Kartik Agaram2020-12-231-5/+5
| | | | | | | Ooh, look at that, the device number comes conveniently initialized in the right register. No need to hardcode it. https://wiki.osdev.org/MBR_(x86)
* 7376Kartik Agaram2020-12-231-3/+7
|
* 7375Kartik Agaram2020-12-231-9/+20
| | | | A little more robustness after reading https://stackoverflow.com/questions/43786251/int-13h-42h-doesnt-load-anything-in-bochs/43787939#43787939
* 7374Kartik Agaram2020-12-211-3/+16
|
* 7373Kartik Agaram2020-12-211-1/+1
| | | | | apps/boot.hex doesn't need much by way of syntax highlighting. Have it work even for people who haven't installed subx.vim
* 7372 - successful read from disk using BIOSKartik Agaram2020-12-211-13/+48
|
* 7371Kartik Agaram2020-12-211-1/+1
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-06 20:49:51 +0000