• Please review our updated Terms and Rules here

XTIDE Universal BIOS v2.0.0 beta testing thread

@Malc @ConiKost - the builds should all now be present on the binaries page. Instead of adding yet another commit, I've adjusted the build script to filter Revision.inc to contain exactly [version-number][space] only thus:

Bash: 
head -n 1 Inc/Revision.inc | sed 's/[^0-9]//g' | tr -d '\n' | sed '$s/$/ /' > Inc/Revision2.inc; rm Inc/Revision.inc; mv Inc/Revision2.inc Inc/Revision.inc

Any trailing characters break the build process, indeed this is noted in the sources. And evidently it is not possible to save a file without a trailing line-feed using nano.
 
FWIW, I've built this toolchain to automate/streamline building XUB on Linux (with on-the-fly makefile Unix-ness patching), either with Docker so no prereqs are installed on your host, or 'natively' if you prefer.

github.com

GitHub - RetroSwimAU/xtidebuilder: Streamlined Builder for XTIDE Universal BIOS

Streamlined Builder for XTIDE Universal BIOS. Contribute to RetroSwimAU/xtidebuilder development by creating an account on GitHub.
github.com github.com

Hopefully it's useful to somebody!
 
As a follow up to this, I've been experimenting with GitHub Actions, and created a workflow that builds the "all" binaries with Linux, and compares them with the pre-built binaries on the XUB website, as a kind of sanity check. I remove the first handful of bytes from each, as the build date is stamped there, and compare a hash of the remainder.



In the end I found that NASM is deterministic enough that this process works.... On Debian Linux.



When I was previously using Alpine Linux (the preferred lightweight distro for Docker containers), the resulting binaries differed in a couple dozen places.



I ran objdump, and it looks like they only differ by the order of the operands on some XCHG instructions: https://gist.github.com/RetroSwimAU/ae03cb8fbface5f2f58d7757e12ba93f



The binaries work, of course, but I don't understand why they would be different. Is it a glibc vs musl thing? I don't know enough to make a call, or even to confidently say my objdump was done correctly.



I know Windows is the sanctioned build environment, so I'm not asking for troubleshooting or support, I just wanted to mention it as a curiosity.



In any case, the current iteration of the toolchain, using the Debian base image, indeed produces binaries identical to the official ones using the "all" target, which I consider a win, or at the very least a
good sanity check! :)
 
OK, no, never mind, it's just caused by the different versions of NASM. Alpine gets 2.16.03 from apk, whereas Debian Bookworm and Ubuntu Noble (Docker debian:latest and ubuntu:latest respectively) get 2.16.01.

The latter just happens to align with the build setup in the official build environment, I guess. Mystery solved in any case hahaha!
 
Last edited:
The XUB site runs on and builds with Linux.

@Krille - sorry missed this. Forgive my ignorance but can you explain the issue with the COM file please?
 
It builds ok (with compression) in a temp folder now and on a backup from a couple of weeks ago, so I’m not sure. Permissions and path looks ok.
 
pearce_jj said:
It builds ok (with compression) in a temp folder now and on a backup from a couple of weeks ago, so I’m not sure. Permissions and path looks ok.
Click to expand...
I just committed r631 and XTIDECFG.COM is, again, not compressed. Note that the makefile target should be "release" for UPX to be invoked. If it's "xt" then it will be uncompressed.
 
@pearce_jj Thanks! This was not a problem before. What broke and how did you fix it?

I'm sorry to say though. You've made a mess again. Revision.inc *must* be updated with *every* commit. That's why I made the hook scripts in \Tools (and I spent quite a bit of time on that). If you're doing the commits from Windows then they should be used so that you don't have to remember to update it manually. If you're using TortoiseSVN it's really simple.
 
OK, so I've reverted to R631 commit. Auto-make script fix (below) is in place. I won't make another commit - but the next actual commit should work. TortoiseSVN didn't auto-advance Revision.inc for me but I have no experience with that tool other than testing it just now.

The fix was to include the path when calling make. It's an odd problem because calling echo in the makefile works on the preceding lines. However, there are numerous forum posts about this going back some period of time so maybe we have just been lucky to avoid it up until now. So, make is called in the auto-make script thus:

Code: 
# Build the code and copy the binaries out
env PATH=/usr/bin:$PATH make 2>&1 | (logger -t auto-make)
 
Last edited:
pearce_jj said:
TortoiseSVN didn't auto-advance Revision.inc for me but I have no experience with that tool other than testing it just now.
Click to expand...
Right click the checkout folder and select TortoiseSVN -> Settings. Then just add the hook scripts. Should look something like this;

Hook Scripts.png
Note! I'm using Windows 7 so I haven't tested the scripts on newer versions of Windows.
 
You must log in or register to reply here.
Back
Top