Closed ivop closed 2 months ago
Hmm, that's weird. Mametest ran successfully on my branch. It seems to error out on a missing sound device?
CI keeps failing during the Oric mametest with: fail ALSA lib seq_hw.c:466:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory
But it passes on my branch.
Very nice! Possibly less buggy than qe, too... question: do you want this in apps or would you rather it went into third_party, to make it clear that it's yours? This is probably a large enough piece of work to matter.
Re the Oric mame failure: that warning always appears. Chances are that it's a timing edge case caused by the disk being fuller and it taking longer to do the disk seeking, but it's weird it's only happening on the CI system. Maybe a different version of mame? You might try editing src/arch/oric/mame-test.lua
and increasing the wait values.
Thanks. I moved it to third_party. I left zmalloc.c in lib as it is usable by other future projects and people might otherwise not notice its existence.
Edit: as for the Oric/mametest failure, I cannot test whether changing the wait values works because in my fork/branch here: https://github.com/ivop/cpm65/tree/dwarfstar the CI does not fail :) Which is pretty strange. You'd think that the merge test and CI here as a pull request should result in the exact same tree as my fork and both should behave identical, but they don't.
Looks like I'm fixing the test failure on master, then... merging. Thanks very much!
I always wanted to write a text editor, so here's my take on it. Because qe is already a a gap-buffer based text editor, I tried the "Build Your Own" text editor approach, which is a vector of pointers to lines. It's a little less memory friendly, but on the other hand a lot easier to render to the screen. It includes a malloc implementation (other programs can use it, too) that's somewhat tweaked for decent performance, but also overallocs a bit to reduce memory fragmentation, at the cost of four bytes on average for each allocation. I also found that allocating at the end of free blocks is a lot faster, but reduces overall memory utilization, so I decided against it and switched back to allocating at the beginning of free blocks. Once the cpm65 target of llvm-mos grows heap support we could switch to that and see how it performs. I found it non-trivial to add to llvm-mos, and I've always wanted to write my own malloc, too :)
Currently it is installed on the Oric, Atari, nano6502 and neo6502 ports. The other ports don't have enough free disk space. It would be nice if they gained multi drive support, because recently I briefly looked into adding all native asm sources to the "distribution" and several ports couldn't fit them on their disk either.
Anyway, here's DwarfStar.
Oric: Atari: BBC: (I disabled atbasic and ansiterm to test it)