about summary refs log tree commit diff stats
path: root/baremetal/boot.hex
Commit message (Collapse)AuthorAgeFilesLines
* 7567 - baremetal: shift-key supportKartik Agaram2021-01-271-29/+117
|
* 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-241-23/+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-241-118/+242
| | | | | | | | | | | | | | | | | 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-241-60/+60
| | | | | | 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
|
* 7547 - baremetal: rpn calculatorKartik Agaram2021-01-221-5/+8
| | | | | | | | 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.)
* 7539 - baremetal: handle unrecognized keysKartik Agaram2021-01-221-7/+11
|
* 7529 - baremetal: fake screenKartik Agaram2021-01-161-2/+2
|
* 7489 - include GNU UnifontKartik Agaram2021-01-091-4/+247
| | | | | | | 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.
* 7485Kartik Agaram2021-01-091-8/+10
|
* 7484Kartik Agaram2021-01-091-0/+1
|
* 7480 - baremetal/ex3.hex now draws multiple pixelsKartik Agaram2021-01-071-6/+13
| | | | | | | | | | I was wrong in commit 7437 that only one keystroke was working. The problem was just that I was getting _too_ many events. I wasn't handling key-up events, and they were entering the buffer, and I was not skipping null events since the circular buffer is currently considered to be null-terminated. ex3 isn't done yet; it can only handle 16 events. Apps need to be clearing the keyboard buffer.
* 7479Kartik Agaram2021-01-071-3/+3
|
* 7461Kartik Agaram2020-12-291-1/+1
|
* 7437 - baremetal: draw pixel on keyboard eventKartik Agaram2020-12-281-7/+11
| | | | | It's now clear that our keyboard handler doesn't trigger after the first event.
* 7436Kartik Agaram2020-12-271-19/+19
| | | | 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-271-54/+50
| | | | | | 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
|
* 7424 - baremetal: downsize graphics resolutionKartik Agaram2020-12-271-2/+2
| | | | | | | | 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.
* 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.
* 7418 - baremetal: adjust entrypoint addressKartik Agaram2020-12-261-4/+147
| | | | | | | | | | | 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-261-1/+2
|
* 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
|
* 7411Kartik Agaram2020-12-261-1/+1
|
* 7404 - baremetal: first example programKartik Agaram2020-12-261-0/+338
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.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-07-08 16:21:11 +0000