Dean/dev/v2.1

[vipoo]

Hello,

Not sure if you are still active on this repo or accepting PRs. This PR does appear quite large (sorry). If u dont have time or inclination to look at this - no worries.

This is my attempt to build the platform using linux and make. It's still a work in progress -- at this stage i have built sunrise rom and nextor.sys/command.com and a couple of tools- tested using blueMSX image.

Testing at this stage is no more than ---- do i have an A> prompt? .... probably needs more rigour in the testing.

I was not able to get the windows build script to work for the v2.1 branch - there seems to be a few issues -- i think some of the errors i see are meant to be ignored - but the main issue is when it attempts to apply the drivers to the base image - complains that the driver has already been applied - it looks like the bank count in the first page is 0 - not 7.

I initially built and tested the build process on the v2.0 branch -- i was able to build all units from windows - so this enabled me to compare the produced binaries - as well as test under bluemsx.

I am very new to MSX and Nextor - so there is a lot i am probably not aware of.

So if u feel inclined to give me feedback -- be great - not sure if you are interested in having a linux build image.

Things i would like to do next:

• Add the remaining tools and ROM images (although i am not 100% sure how to test all of these).
• Add a CI build environment - i usually use travis - nice and easy.
• for myself, i want to create a disk driver for my specific hardware kit (rc2014).

Summary of changes in PR:

1. A bunch of new Make files specific for linux.
2. A readme.md file can be found in linuxtools briefly describing the process - still need to add more notes.
3. Many of the files had LF line endings - and not the CPM CRLF endings - this caused a few issues for me - so some of the big file changes are simply the line ending changes.
4. Added newlines to the end of some files - some files had the end on the last line with no newline - this seem to cause some issues for me.
5. Some code changes required due to case sensitivity of filenames in linux.
6. Added a conditional assembly switch EX_RUSSIAN - to exclude the russian keyboard stuff - this code seem to use a call that is not supported in cbios. ... (0D89H)

Advantages of the linux build process

• Parallel builds supported.
• Only builds what's changed.
• Stops on error - (created wrappers for M80 and L80 to parse output and exit as appropriate).
• Colour coding of output to make it easy and quicker to see key build information.

[vipoo]

Additional:

• I have been developing this using ubuntu on Windows Subsystem for Linux.
• Recommend when using the make process to use the linux volume, eg: ~/nextor/..., and not the windows mounts /mnt/c/.. -- found when running on the windows mount is quite slow.

[grauw]

As a macOS user this looks interesting to me. Can I ask how you run the CP/M utilities under Linux?

[vipoo]

CPM is run using https://github.com/jhallen/cpm emulator. It's very similar to the one nextor uses for windows. But it has a command line length limit -and was chopping off the trailing part of the M80 and L80 commands. So i did a bit of process piping to submit to the underlying process.

I have not considered mac os much -- its very possible i am using something thats not POSIX compliant - grep and sed some times have subtle differences that have caused me pain with my osx colleagues.

[lvitals]

I've been working on build for Linux for a few days using Make for Nextor. I used the same emulator for CP / M, but another tool for hex2bin with the same result. In this your MR is missing from SymToEqus how are you doing it?
My proposal is different without make install-prereq, the SDCC is present in the repositories of the main Linux distributions, I don't see the need to make a wget for later combining. For
external tools like git@github.com: jhallen / cpm.git could use git submodule.

[vipoo]

Hi Leandro,

What a strange coincident. Be interested in seeing what you have done - i am no make expert.

your MR is missing from SymToEqus how are you doing it?

I solved the symtoequs issue with a few lines of bash - have a look at the file linuxtools/symtoequs.sh. This seem simpler that getting dot.net code compiled. (If that is what you were asking about?) This is the sort of stuff linux/bash really excel at..

the SDCC is present in the repositories of the main Linux distributions, I don't see the need to make a wget for later combining

I probably could have used the distro's SDCC - I use z88dk a bit, and that likes to install a patched version of sdcc - i guess i was just repeating myself without thinking...

For external tools like git@github.com: jhallen / cpm.git could use git submodule.

I decided against the use of submodules - i generally prefer submodules when i will be iterating on the sub module code - not anticipating needing to make changes to cpm. The little script to get cpm does a shallow copy - so nice and quick. But it's not a big deal.

I also set the path to the local sdcc, cpm and hex2bin - so as to avoid potential conflicts (I have a patched cpm instance on my machine that i use for testing code i target to my RC2014/RomWBW image - didnt want that version used)

My biggest challenge was getting a baseline comparison - as I have mention in this PR, and in a issue on the repo, I was not able to get the 2.1 and 3.0 branches to compile using the windows scripts. I later noticed a bunch of makefiles - that i guess are for Windows (dont have make on windows - dont generally dev on windows) - do u have any insights into the windows build process?

Cheers
Dean

[Konamiman]

Hi @vipoo. That's fun, because I've been working on basically the same thing for the last couple of months, and I have this near finished and about to being merged: #80

However, I really appreciate your efforts, and while I don't think I'll merge this pull request in its actual form it would be utterly awesome to have proper makefiles for Nextor - in fact I was planning to do them myself in the future but the prospect of having to learn the intricacies of Make didn't make (ha!) me particularly happy.

So, to reiterate: thank you very very much for this, and my recommendation for you is: wait until I have my pull request merged, and then adapt yours (or create a new one) to whatever you think you could improve on what I've done - very especially the makefiles, oh yes, I would love so much to have working makefiles!

[vipoo]

Hi mate,

That's fair enough - this is your gig. I am not sure what part of my changes will make sense with your new branch - the approaches will probably be in conflict a bit.

And this PR is now out of date - i have done a lot of updates to the Makefile build process since - if interested have a look at this commit (dinoboards@5cd1f2a)

Some of my goals/thoughts/approach when developing the build scripts were:

1. Proper dependency management - to allow for concurrent building and only builds what's needed. This means if I change the driver code, only the driver gets rebuilt. Quick build times. (I find a lot of make systems are very imperative in approach - Make works best when approached in a declarative model.)
2. Source code for everything. As much as possible, avoid checking in binaries - always have units built
3. Stop on assembly/compile errors - make sure errors are very visible - in the early development, the lack of this caught me out a few times - errors scrolled off screen - and then strange things happened during testing.
4. Use bash to wrap M80, L80 to return processes exit codes, and colourised output.
5. Updated mknexrom to support correct use argument switches (slashes to dashes).
6. Use bash script for symbol extraction
7. I use a small number of bash scripts to help out - no need for c# code, and another tool chain. This included a script to clean up cpm text files, with trailing junk after the CTRL+Z. The extra bytes confused the hex2bin utility i was using.
8. Target a bin directory for all build artifacts - makes for a very simple make clean approach - only need to delete the bin directory. Also keeps the gitignore file simple. I use symlink a lot to facilitate this. Symlinking also allows for managing of name conflicts.
9. Within my custom build branch, I further enhanced your conditional assembly approach. I noticed the condasm.inc file. I created configuration files (std.inc and rc2014.inc) and through the use of env var (BUILD_TYPE) symlinked in the correct file. This allowed me to customise the build for my RC2014 image.

Cheers
Dean

[grauw]

A lot of those sound like good ideas to me, so if the two changes can be combined…

[vipoo]

Oh and another thing I had changed, was to ensure all MAC files had CRLF line endings.

[vipoo]

As I recreated some branches - my commit id has changed: dinoboards@5cd1f2a