about summary refs log tree commit diff stats
path: root/apps
Commit message (Collapse)AuthorAgeFilesLines
* 7730 - baremetal/shell: boolean valuesKartik K. Agaram2021-02-122-3/+3
| | | | | In the process I found a bug in the Mu compiler. Limitations of just asserting the emitted code but not running it.
* 7700Kartik Agaram2021-02-091-0/+73
|
* 7692Kartik Agaram2021-02-073-6/+33
| | | | | It's bad enough that metadata comments are restricted to integer literals; let's at least make them work on _all_ integer literals.
* 7690Kartik Agaram2021-02-0732-436/+436
| | | | Convert comments about magic constants into metadata.
* 7689 - permit metadata on Mu literal integersKartik Agaram2021-02-062-0/+33
| | | | | | | | | | | | | | Metadata is always ignored. It's purely for documentation purposes. But as long as Mu has no named constants it's starting to feel increasingly essential. I'm still not going to bother to add metadata to other parts of the language. Let's see if we need them. Even though it's a little warty that the rules vary throughout the stack: - bare SubX: metadata everywhere - SubX with syntax sugar: no metadata in calls or addressing-mode sigil-expressions - Mu: metadata only for literal integers
* 7559 - reorganize sectors built in raw hexKartik Agaram2021-01-242-17/+17
| | | | | | | | | | | | | | | | | This was tedious for three reasons beyond the usual one of having to track and update offsets several time while I debug: - The Bochs troubles of the previous commit kept polluting my brain even though they were irrelevant. - I had to keep some changes locally to allow myself to use Bochs, which polluted my working directory. - I had to travel the long way to the realization that I'm not actually initializing the stack anywhere. BIOS was starting my stack off at 0x10000, which was promptly clobbered by my second read from disk. The good news: while I'm here I grow the interrupt descriptor table. So I don't have to go through this exercise when I get back to supporting the mouse.
* 7526Kartik Agaram2021-01-1615-0/+0
|
* 7490 - baremetal: draw a grapheme to screenKartik Agaram2021-01-091-0/+2
|
* 7489 - include GNU UnifontKartik Agaram2021-01-092-17/+17
| | | | | | | https://en.wikipedia.org/wiki/GNU_Unifont#The_.hex_font_format http://unifoundry.com/unifont/index.html Since GNU Unifont is covered under the GPL v2, so I believe is this repo.
* 7462 - SubX version of baremetal/ex2.subxKartik Agaram2020-12-292-1/+1
|
* 7460 - baremetal backend for SubXKartik Agaram2020-12-292-2178/+214
|
* 7459Kartik Agaram2020-12-292-102/+199
| | | | Bring baremetal variant up to date with recent changes.
* 7458Kartik Agaram2020-12-292-90/+184
| | | | Switch survey_elf to the new approach.
* 7457Kartik Agaram2020-12-282-10/+14
|
* 7456Kartik Agaram2020-12-281-2/+1
|
* 7454Kartik Agaram2020-12-284-338/+119
| | | | Go back to commit 7448.
* 7453Kartik Agaram2020-12-281-74/+23
| | | | | Snapshot: this approach of disambiguating /disp32 based on metadata doesn't work. The `survey` phase runs after `pack`, which gets rid of most metadata.
* 7452Kartik Agaram2020-12-284-24/+286
|
* 7451Kartik Agaram2020-12-284-20/+28
|
* 7450Kartik Agaram2020-12-282-2/+2
|
* 7447Kartik Agaram2020-12-282-2/+2
|
* 7446Kartik Agaram2020-12-282-185/+0
|
* 7445Kartik Agaram2020-12-282-185/+0
|
* 7444Kartik Agaram2020-12-281-1/+1
|
* 7443Kartik Agaram2020-12-282-0/+4772
| | | | | A new phase for baremetal compilations. Doesn't work yet, but it passes all its tests, so we can add it to CI.
* 7442Kartik Agaram2020-12-281-0/+0
|
* 7441Kartik Agaram2020-12-2816-16/+16
|
* 7439 - start translating Mu programs to baremetalKartik Agaram2020-12-283-6/+6
|
* 7403 - baremetal/ for apps without a kernelKartik Agaram2020-12-2610-905/+0
|
* 7402Kartik Agaram2020-12-261-3/+3
|
* 7399Kartik Agaram2020-12-241-3/+3
|
* 7398Kartik Agaram2020-12-231-2/+2
|
* 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-231-9/+46
| | | | | | | | | | | | | | 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.