about summary refs log tree commit diff stats
path: root/baremetal
Commit message (Collapse)AuthorAgeFilesLines
* 7676Kartik Agaram2021-01-301-3/+5
|
* 7674 - beginning of mouse driverKartik Agaram2021-01-281-12/+199
| | | | | | | | | | | | | | No handler yet, just initialization. Bochs boots up; Qemu gets into a reboot loop. Unlike the keyboard where I did the minimum necessary for Qemu, here I am blindly copying something alleged to work on "real hardware." Makes no difference to the failure modes I'm seeing. Even in this tiny endeavor I see the abyss open up. Poke bytes at some sequence of ports, read back bytes from some sequence ports; it's like sending out prayers.
* 7673Kartik Agaram2021-01-282-2/+2
|
* 7672Kartik Agaram2021-01-272-51/+55
|
* 7671Kartik Agaram2021-01-275-53/+56
| | | | Make some room for a mouse handler.
* 7670Kartik Agaram2021-01-271-23/+24
|
* 7569Kartik Agaram2021-01-271-2/+10
|
* 7568Kartik Agaram2021-01-271-0/+5
|
* 7567 - baremetal: shift-key supportKartik Agaram2021-01-273-31/+119
|
* 7566Kartik Agaram2021-01-271-3/+3
|
* 7565Kartik Agaram2021-01-241-1/+1
| | | | Somehow everything worked with this bug.
* 7564Kartik Agaram2021-01-241-18/+16
|
* 7563Kartik Agaram2021-01-241-45/+13
| | | | Yup, a single read suffices. Might not work on real hardware, but YAGNI.
* 7562 - bochs working againKartik Agaram2021-01-242-24/+28
| | | | | Holy crap, perhaps the limitations of int 13h were all a mirage. I just needed to initialize the stack.
* 7561Kartik Agaram2021-01-241-11/+35
| | | | | Another attempt at reorganizing how I read disks. Everything continues to work in Qemu, but Bochs still doesn't love me.
* 7560Kartik Agaram2021-01-241-1/+1
|
* 7559 - reorganize sectors built in raw hexKartik Agaram2021-01-248-131/+256
| | | | | | | | | | | | | | | | | 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.
* 7558Kartik Agaram2021-01-244-63/+63
| | | | | | Bochs is still broken, but before we can fix it we need to make some room in the boot sector. So we'll spend a few commits reorganizing things.
* 7557Kartik Agaram2021-01-241-1/+1
| | | | | | | | | | | | Oh, stupid mistake in segmented address calculation. Now Qemu's working again everywhere. Bochs is again broken everywhere. But I think we're getting closer. I think Bochs's BIOS implementation for reading sectors has two interacting constraints: - Can't write to more than 0x10000 bytes past segment register. - Can't write across segment alignment boundaries. Qemu only cares about the first.
* 7555 - snapshotKartik Agaram2021-01-241-13/+30
| | | | | | | | | | | | | | | | | | | While baremetal has been working with Qemu, it's been broken with Bochs since commit 7547, where we started reading more than 63 sectors (1 track) from disk. Good to know that Bochs simulates native hardware with so much verisimilitude! Unfortunately things aren't fixed yet. The current state: - Qemu - - Bochs - ex2.hex never switches modes works ex2.subx never switches modes works ex2.mu never switches modes fails unit tests It sucks that Bochs doesn't have strictly superior verisimilitude compared to Qemu :(
* 7554 - bug in an error handlerKartik Agaram2021-01-241-1/+1
|
* 7553Kartik Agaram2021-01-241-1/+17
|
* 7552 - I better understand a couple of thingsKartik Agaram2021-01-231-2/+14
|
* 7551Kartik Agaram2021-01-231-2/+2
|
* 7550Kartik Agaram2021-01-231-3/+2
|
* 7548 - baremetal: better cursor managementKartik Agaram2021-01-236-44/+73
|
* 7547 - baremetal: rpn calculatorKartik Agaram2021-01-229-6/+4217
| | | | | | | | Still in progress. Known bugs: * Cursor management is broken. Every line currently seems to leave behind a shadow cursor. * No shift-key support yet, which means no addition or multiplication. (This app doesn't have division yet.)
* 7545Kartik Agaram2021-01-221-28/+32
|
* 7543Kartik Agaram2021-01-221-11/+11
|
* 7542 - baremetal: support cursor on a graphemeKartik Agaram2021-01-224-18/+36
| | | | | | | | | | | | | | | So far we've drawn a space implicitly at the cursor. Now I allow drawing an arbitrary grapheme when drawing the cursor. But the caller has to specify what to draw. (The alternative would be for layer 103 to track every single grapheme on screen along with its color and any other future attributes, just to be able to paint and unpaint the background for a single character.) I've modified existing helpers for drawing multiple graphemes to always clear the final cursor position after they finish drawing. That seems reasonable for terminal-like applications. Applications that need to control the screen in a more random-access manner will need to track the grapheme at the cursor for themselves.
* 7541 - baremetal: debug screen test helpersKartik Agaram2021-01-221-7/+25
|
* 7540 - baremetal: cursorKartik Agaram2021-01-222-9/+19
| | | | | | | | | | | | | | | | | | | | I spent over a week agonizing over this. * I had to come to terms with the fact that I don't really know how to make pixel graphics testable. ASCII art on a pixel by pixel basis feels inhuman. Just focus on text mode for now. * I had to set aside the problem of non-English family languages. Languages like Arabic that can stack complex graphemes together likely can't be fixed-width. But I don't know enough at the moment to solve for them. * I spent a while trying to juggle two cursors, one invisible output cursor for tracking the most recent print, and one visible one that's just a hint to the user of what the next keystroke will do. But it looks like I can fold both into a single cursor. Drawing things updates the location of the cursor but doesn't display it. Explicitly moving the cursor displays it, but future drawing can overwrite the cursor.
* 7539 - baremetal: handle unrecognized keysKartik Agaram2021-01-221-7/+11
|
* 7538 - baremetal: screen coords in graphemesKartik Agaram2021-01-224-42/+54
|
* 7537 - baremetal: start of cursor supportKartik Agaram2021-01-193-7/+10
|
* 7536Kartik Agaram2021-01-191-7/+7
|
* 7535Kartik Agaram2021-01-176-14/+14
|
* 7534Kartik Agaram2021-01-172-25/+47
| | | | Don't assume screen dimensions.
* 7533Kartik Agaram2021-01-163-0/+23
| | | | Both issues of commit 7531 fixed.
* 7532Kartik Agaram2021-01-161-2/+2
|
* 7531 - checking fake screensKartik Agaram2021-01-161-0/+145
| | | | | | This uncovers two open issues: * incrementing the cursor after drawing a single grapheme * needing to clear background pixels when drawing a grapheme
* 7530 - baremetal: print ints to screenKartik Agaram2021-01-166-2/+807
|
* 7529 - baremetal: fake screenKartik Agaram2021-01-163-7/+214
|
* 7528 - heap allocatorKartik Agaram2021-01-164-4/+843
|
* 7527Kartik Agaram2021-01-162-0/+3
|
* 7525Kartik Agaram2021-01-161-1/+35
| | | | | | Bring back runtime support for bounds-checking arrays. Again, the error messages kinda suck, because I can't yet print integers. But something is better than nothing.
* 7524 - bring back some abort messagesKartik Agaram2021-01-153-6/+33
| | | | | | | | | | | Our infrastructure for displaying errors is far more rudimentary in baremetal. Many ways things can go wrong. But making the attempt seems better than not. I'm also making some effort to keep it easy to see what has been copied over from the top-level, by not modifying copied code to use syntax sugar and so on. It may not be an important enough reason to mix notations in a single file.
* 7523Kartik Agaram2021-01-155-4/+18
| | | | | | | | | | | | | | | | | | | | There's a dependency cycle here: - draw-grapheme (Mu) uses read-grapheme (Mu) to be unicode-aware. - read-grapheme uses read-byte (SubX). Streams are a fundamental data structure in Mu. For the Mu compiler to be able to reason about the safety of stream operations, they need to be an opaque type. All stream primitives are written in SubX. To manipulate a stream's internals we force people to reach for SubX. That way if there's no SubX code there's confidence that things are safe. - read-byte and other stream operations have unit tests, like they should. The unit tests need to print data to screen when say a test fails. To do this they use various check- functions (SubX) that take a string argument. - Printing a string to screen uses draw-grapheme (Mu). Perhaps I should maintain variants of drawing primitives that operate only on ASCII.
* 7522 - bring back a few tests in .subx filesKartik Agaram2021-01-155-5/+744
| | | | | | | | Even though baremetal has tests in SubX, they can only run in Mu programs since the test harness is currently in a Mu layer. Baremetal isn't really intended for running SubX programs at the moment. Is this a step down the slippery slope towards C compilers that I complained about in http://akkartik.name/akkartik-convivial-20200607.pdf?
* 7521 - new plan for testsKartik Agaram2021-01-1511-78/+124
| | | | | | | | | | It's not really manageable to make the fake screen pixel-oriented. Feels excessive to compare things pixel by pixel when we will mostly be writing text to screen. It'll also make expected screen assertions more difficult to manage. So I'm not sure how to make assertions about pixels for now. Instead we'll introduce fake screens at draw-grapheme.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-03 09:24:26 +0000