about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 7700Kartik Agaram2021-02-091-0/+0
|
* 7699Kartik K. Agaram2021-02-082-11/+442
| | | | Gap buffer with a more testable interface for rendering to screen.
* 7698 - starting to test-drive baremetal shellKartik Agaram2021-02-074-5/+259
|
* 7697Kartik Agaram2021-02-071-4/+6
|
* 7696Kartik Agaram2021-02-071-1/+0
|
* 7695 - baremetal: second bg assertion for spacesKartik Agaram2021-02-071-1/+60
| | | | | | When I'm also checking graphemes I assume that spaces can be in other bg colors. However, if I want to closely check the bg color for a cell with a space in it (ahem, cursor), I have to check the color in isolation.
* 7694 - baremetal: asserting bg color in testsKartik Agaram2021-02-072-7/+103
|
* 7693 - baremetal: pass background color everywhereKartik Agaram2021-02-0714-117/+137
|
* 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.
* 7691Kartik Agaram2021-02-072-5/+21
|
* 7690Kartik Agaram2021-02-0751-662/+662
| | | | 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
* 7688Kartik Agaram2021-02-061-1/+1
|
* 7687Kartik Agaram2021-02-051-0/+3
|
* 7686Kartik Agaram2021-02-041-2/+2
|
* 7685Kartik Agaram2021-02-032-739/+727
|
* 7684 - baremetal will have no mouseKartik Agaram2021-02-032-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I spent a week on trying to support it, and I am now past the five stages of grief. -- Important things I read https://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html https://web.archive.org/web/20040604043149/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/mouse/mouse.html https://wiki.osdev.org/index.php?title=Mouse_Input&oldid=23086#Waiting_to_Send_Bytes_to_Port_0x60_and_0x64 says command 0xa8 is optional SaniK: https://forum.osdev.org/viewtopic.php?t=10247 recommends command 0xa8 before setting Compaq Status byte Setting Compaq status byte before 0xa8: https://forum.osdev.org/viewtopic.php?f=1&t=19873 This thread also suggests that keeping reads from keyboard vs mouse straight is non-trivial. -- Where I got stuck Following SaniK's recipe doesn't seem to work. It seems like not sending the 0xa8 command gets us a little closer. I saw the mouse handler trigger, but it seems to not actually happen in response to mouse events (vector 0x74 in the interrupt descriptor table). -- Other options that may be worth considering USB mouse Serial mouse Implementing a PS/2 handler in SubX would require somehow referring to SubX labels in this file It seems clear that a mouse driver is complex enough to need a higher-level language than just hex bytes. But it's _not_ clear how to _explain_ a mouse driver. There's just a lot of random rules, historical anecdotes, just-so stories and sheer black magic here. I'm going to try to do without it all. Mu will be a keyboard-only computer for the foreseeable future.
* 7683Kartik Agaram2021-02-011-1/+1
|
* 7682Kartik Agaram2021-02-012-32/+20
|
* 7681Kartik Agaram2021-02-011-4/+3
|
* 7680Kartik Agaram2021-01-319-624/+681
|
* 7679 - baremetal: delete mouse handlerKartik Agaram2021-01-311-203/+14
| | | | What I have so far is crap. Roll baremetal/boot.hex back to commit 7673.
* 7678Kartik Agaram2021-01-301-0/+1
|
* 7677Kartik Agaram2021-01-301-48/+0
|
* 7676Kartik Agaram2021-01-301-3/+5
|
* 7675 - drop Travis CIKartik Agaram2021-01-282-26/+0
|
* 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-2410-148/+273
| | | | | | | | | | | | | | | | | 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.
* 7556Kartik Agaram2021-01-242-2/+2
|
* 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-232-232/+256
|
* 7551Kartik Agaram2021-01-232-4/+4
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-25 04:36:18 +0000