-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merlin DSK ESDOS Error #15
Comments
Just some update on this: I've modified my code in order to make it work properly, but I still need to modify the DSK and the BASIC program so it really works as expected.
Those bytes will be completely ignored once the dsk image gets generated. Hence the program will start at the indicated ORG instruction.
instead of
which should be the correct way of coding IMHO.
It seems that the code responsible for generating the dsk is not correct. Here is the complete code modified:
|
Hi, I believe I understand now what is happening. I still think there is something wrong with the way the disk gets created. I am having to add a 4 byte to my string as well as an initial opcode that gets stripped out from the file in disk. My working code now is:
The ADR and NOP opcodes should be listed on the disk's binary file. However, they get lost when the binary code gets transferred to disk. So the first line at address 300 will actually be the LDX - which is the main program. Everything else gets generated as it was supposed to be, except the ASC data. Since there is an "extra" 4 bytes in the binary code generated by Merlin32, I had to add an extra 4 bytes before the actual string. So the LDA will point to mySTR at position 4 instead of 0 which would string 4 characters from the word Hello. All of this seems to be a workaround situation and shouldn't be required in a simple Merlin code as this. Best regards, |
Thanks for the report. I m currently busy with my job and will reply here as soon as I can. |
Hi,
I am trying to compile a simple source code with Merlin32 and run it with AppleWin1.30.13.0.
The compilation process works and it automatically creates a DSK file that can be used to run the application on the emulator.
However, this DSK is formatted with ESDOS(??) and the file attributes are kind of weird.
If I create an empty ProDOS1.4.1 and copy the ".b" file with CiderPres into it I am able to run it by changing the file type to $06 and Aux Type set to the same address value as what I have in my ORG directive (ORG $8000).
While examining the DSK generated by WUDSN the file has the correct file type but the Aux Type is wrong. Instead of having it with 8000 (same as ORG in the source code) it has the value 1620. If I open it with CiderPress and view this binary file it displays the code starting at $1620. In addition to it, the code stored on this file is very different. The first opcode used on my program should be "20 EC 80" and instead the file starts with "7F".
So when I run this disk on the emulator, I get a monitor prompt instead of the application running:
The emulator states "Loading Balls"
80F0 - A-16 X=9D Y=00 P=36 S=F0
If I go to address $1620 I see the same opcodes I see via CidePress which is probably what is performing a jump to subroutine at address $80EC (which kind of looks like why it terminates at address 80F0).
Am I missing something or doing anything that is not supported?
Would it make more sense to have settings related to disk image (OS templates to be used for the disk) and file attributes, etc?
This way we could control how the disk image gets generated. It would also allow you to have a Hard Disk Image (2mg format) to run on the emulator which would contain additional tools and your binary file.
BTW: I am using Eclipse Version: 2023-06 (4.28) with the following plugins:
WUDSN Base Feature 1.7.2.202303171941 com.wudsn.ide.base.feature.feature.group WUDSN
WUDSN IDE 1.7.2.202303171941 com.wudsn.ide.feature.feature.group WUDSN
Best regards,
Ivan
The text was updated successfully, but these errors were encountered: