about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 7440Kartik Agaram2020-12-282-18/+18
|
* 7439 - start translating Mu programs to baremetalKartik Agaram2020-12-2810-19/+19
|
* 7438Kartik Agaram2020-12-283-244/+600
|
* 7437 - baremetal: draw pixel on keyboard eventKartik Agaram2020-12-282-7/+68
| | | | | It's now clear that our keyboard handler doesn't trigger after the first event.
* 7436Kartik Agaram2020-12-272-22/+22
| | | | Start highlighting lines that may need to be recomputed when offsets change.
* 7435 - baremetal: buffer for keyboard eventsKartik Agaram2020-12-271-20/+49
| | | | | | | | | I'm trying to read the status register, but I'm still not seeing the breakpoint being hit a second time. (And I again ran into the Bochs bug that breakpoints at the first instruction of an interrupt handler don't work.) Maybe this is just a debugger issue. Let's keep going, and try to start using the keyboard events.
* 7434Kartik Agaram2020-12-271-1/+1
| | | | Fix a stale displacement.
* 7433 - some major layout changesKartik Agaram2020-12-272-55/+51
| | | | | | I'd missed that VBE call 0x4f01 (get video mode) can write up to 256 bytes. Unexpected areas were getting clobbered because I wasn't reserving enough space.
* 7432Kartik Agaram2020-12-271-5/+5
| | | | | Bugfix: 32-bit code in 16-bit mode. Seems like it was benign, maybe.
* 7431Kartik Agaram2020-12-271-1/+1
| | | | Typo.
* 7430Kartik Agaram2020-12-271-1/+1
|
* 7429Kartik Agaram2020-12-272-0/+7
|
* 7428Kartik Agaram2020-12-278-555/+0
|
* 7427Kartik Agaram2020-12-274-4/+4
|
* 7426Kartik Agaram2020-12-273-57/+154
|
* 7425 - baremetal: render the paletteKartik Agaram2020-12-271-6/+5
| | | | | It's now very obvious that we don't actually have 256 unique colors by default in 256-color graphics modes.
* 7424 - baremetal: downsize graphics resolutionKartik Agaram2020-12-274-6/+7
| | | | | | | | If it's large enough that I have doubts whether my top-of-the-line Mac is showing the bottom of the screen inside an emulator, it's too large. This way I also feel more confident that most modern hardware will support this graphics mode, and that these programs will work for others.
* 7423Kartik Agaram2020-12-271-6/+15
|
* 7422Kartik Agaram2020-12-261-2/+1
|
* 7421 - baremetal: beginnings of keyboard mapKartik Agaram2020-12-261-16/+37
| | | | First keypress is detected, but we need to ack it somehow.
* 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.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-23 04:28:40 +0000