| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|