Mirror of CollapseOS
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

README.md 3.7KB

5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990
  1. # emul
  2. This folder contains a couple of tools running under the [libz80][libz80]
  3. emulator.
  4. ## Build
  5. First, make sure that the `libz80` git submodule is checked out. If not, run
  6. `git submodule init && git submodule update`.
  7. After that, you can run `make` and it builds all applications.
  8. ## shell
  9. Running `shell/shell` runs the BASIC shell in an emulated machine. The goal of
  10. this machine is not to simulate real hardware, but rather to serve as a
  11. development platform. What we do here is we emulate the z80 part, the 64K
  12. memory space and then hook some fake I/Os to stdin, stdout and a small storage
  13. device that is suitable for Collapse OS's filesystem to run on.
  14. Through that, it becomes easier to develop userspace applications for Collapse
  15. OS.
  16. We don't try to emulate real hardware to ease the development of device drivers
  17. because so far, I don't see the advantage of emulation versus running code on
  18. the real thing.
  19. By default, the shell initialized itself with a CFS device containing the
  20. contents of `cfsin/` at launch (it's packed on the fly). You can specify an
  21. alternate CFS device file (it has to be packaed already) through the `-f` flag.
  22. By default, the shell runs interactively, but you can also pipe contents through
  23. stdin instead. The contents will be interpreted exactly as if you had typed it
  24. yourself and the result will be spit in stdout (it includes your typed in
  25. contents because the Collapse OS console echoes back every character that is
  26. sent to it.). This feature is useful for automated tests in `tools/tests/shell`.
  27. ## zasm
  28. `zasm/zasm` is `apps/zasm` wrapped in an emulator. It is quite central to the
  29. Collapse OS project because it's used to assemble everything, including itself!
  30. The program takes no parameter. It reads source code from stdin and spits
  31. binary in stdout. It supports includes and had both `apps/` and `kernel` folder
  32. packed into a CFS that was statically included in the executable at compile
  33. time.
  34. The file `zasm/zasm.bin` is a compiled binary for `apps/zasm/glue.asm` and
  35. `zasm/kernel.bin` is a compiled binary for `tools/emul/zasm/glue.asm`. It is
  36. used to bootstrap the assembling process so that no assembler other than zasm
  37. is required to build Collapse OS.
  38. This binary is fed to libz80 to produce the `zasm/zasm` "modern" binary and
  39. once you have that, you can recreate `zasm/zasm.bin` and `zasm/kernel.bin`.
  40. This is why it's included as a binary in the repo, but yes, it's redundant with
  41. the source code.
  42. Those binaries can be updated with the `make updatebootstrap` command. If they
  43. are up-to date and that zasm isn't broken, this command should output the same
  44. binary as before.
  45. ## avra
  46. In the `zasm` folder, there's also `avra` which is a zasm compiled as an AVR
  47. assembler. It works the same way as zasm except it expects AVR mnemonics and
  48. spits AVR binaries.
  49. ## runbin
  50. This is a very simple tool that reads binary z80 code from stdin, loads it in
  51. memory starting at address 0 and then run the code until it halts. The exit
  52. code of the program is the value of `A` when the program halts.
  53. This is used for unit tests.
  54. ## Problems?
  55. If the libz80-wrapped zasm executable works badly (hangs, spew garbage, etc.),
  56. it's probably because you've broken your bootstrap binaries. They're easy to
  57. mistakenly break. To verify if you've done that, look at your git status. If
  58. `kernel.bin` or `zasm.bin` are modified, try resetting them and then run
  59. `make clean all`. Things should go better afterwards.
  60. If that doesn't work, there's also the nuclear option of `git reset --hard`
  61. and `git clean -fxd`.
  62. If that still doesn't work, it might be because the current commit you're on
  63. is broken, but that is rather rare: the repo on Github is plugged on Travis
  64. and it checks that everything is smooth.