The bad hdbdos binaries are 19 bytes too long, and the code reserves 19 bytes through rmb directives but for RAM locations outside the code segment... Hmm, hdbdos should maybe not use rmb here since nothing needs to be "reserved".
I remember having troubles in another project also due to this commit.
Last edit: Tormod Volden 2023-07-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After fine-reading the LWASM documentation the new LWASM behavior seems to do what it should.
RMB - "Reserve a number of bytes in the output."
ORG - "When using the raw target format, ORG is used only to determine the addresses of symbols."
So any RMB reservations will be added to the raw output binary at the point they appear in the code, regardless of the address they have been assigned through ORG.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This patch to hdbdos.asm makes it build with latest LWASM (identical binaries as with 4.19). I will commit these changes, unless there are other suggestions.
The old code was neater in that it showed clearly the length of each variable. But I guess with raw output, there is no way to do something à la RMB.
Thank you for looking into it.
I found the issue and I figured I better report it.
I use Linux Subsystem for Windows(Debian) and also MINGW(for building MAME) and also Raspberry Pi's for testing and building projects.
I know someone wanted the current build of the HDBDOS WAV files related to DriveWire and the Deluxe RS232-Pak and Modem Pak. Which is how I found out it wasn't building.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Additional information:
LWASM v4.21
OS: Raspberry Pi OS ARM64
OS: Debian 11 AMD64
OS: Ubuntu 18.04LTS AMD64
OS: Windows 11 AMD64 MINGW64
These are all the OS's I have currently tested under.
Thanks for the notice. It seems to be a regression in LWASM:
LWASM 4.20 has the same issue.
LWASM 4.19 works fine.
The hdbdos.asm code ends with
where MAGICDG is the address of the start (the "DK" magic).
The "fill" seems broken.Last edit: Tormod Volden 2023-07-01
It is caused by this commit: http://www.lwtools.ca/hg/index.cgi/rev/a812bb4d3a51
The bad hdbdos binaries are 19 bytes too long, and the code reserves 19 bytes through rmb directives but for RAM locations outside the code segment... Hmm, hdbdos should maybe not use rmb here since nothing needs to be "reserved".
I remember having troubles in another project also due to this commit.
Last edit: Tormod Volden 2023-07-01
After fine-reading the LWASM documentation the new LWASM behavior seems to do what it should.
So any RMB reservations will be added to the raw output binary at the point they appear in the code, regardless of the address they have been assigned through ORG.
This patch to hdbdos.asm makes it build with latest LWASM (identical binaries as with 4.19). I will commit these changes, unless there are other suggestions.
The old code was neater in that it showed clearly the length of each variable. But I guess with raw output, there is no way to do something à la RMB.
Thank you for looking into it.
I found the issue and I figured I better report it.
I use Linux Subsystem for Windows(Debian) and also MINGW(for building MAME) and also Raspberry Pi's for testing and building projects.
I know someone wanted the current build of the HDBDOS WAV files related to DriveWire and the Deluxe RS232-Pak and Modem Pak. Which is how I found out it wasn't building.
I have commit this in https://sourceforge.net/p/toolshed/code/ci/12c61f472a1b813ab54a094ce46483cb85cf044e/