| Attachment | Size |
|---|---|
 S-C Assembler Question.docx | 805.75 KB |
The question regards why there is a difference in the result of the LINPRT function ($ED24) when executing inside the S-C Assembler v2.0 compared to how the exact same code example runs when assembled under the Merlin assembler.
The particulars are included in the attached 'S-C Assembler Question.docx' file.
As always, any offered insights are appreciated.
What Apple II ROM are you referencing?
$#ED24 handles floating point and is more than you need for your purpose.
$E51B handles integers and would be more efficient. Ooops, this is an Interger Basic routine.
Why the two assemblers give different results is an interesting question.
Once S-C source code is compiled to $800 why even use MGO $800 as opposed to 800G from Monitor or Call 2048 in FP?
The attached file (respponse 2) shows the results of the three line code example assembled, linked and executed by Apple's EDASM editor/assembler and the ORCA v4.1 assembler/editor.
Hmm, interesting results. Give me a day or so and I'll fire up my IIe with my S-C 2.0 and see if I get the same results.
Thanks for both of your follow-up documents. I tested your code with my S-C 2.0 Assembler running on my US made IIe and get different results. I've tested this two ways, one with my boot disk first installing S-C at $D000 and then copying D1 and D2 to RAMdrive and the other, not using RAMdrive at all.
Of course, without an .OR statement to define the code's starting address the code defaults to compiling at $800. I enter your code and it compiles with no assembly errors, same as your screenshots but MGO DOIT or MGO $800 only results in a screen line of "0800 DOIT" (since I used a "DOIT" label on the first line of code), but nothing else appears on the screen. Once a MGO is performed the lines of assembly code no longer exist. However, after assembly if I exit to monitor and do a $800L I see the complied lines of code. Performing a $800G does nothing.
Interestingly, changing the JPM $ED24 to a JSR results in my FID program executing (which is on my boot disk along with the S-C Assembler and other files).
This makes me think this is a memory management problem but then I'm not familiar with the ROM code that starts at $ED24 on my IIe without further investigation.
It is an interesting problem though. I will close with the following:
$800 (Decimal 2048) is the default RAM space for loaded Basic programs in addition to the default S-C Assembler compiled code starting location. Normally, when compiling code to $800 the resulting code is then BSAVE'd to disk. FP's or BASIC's LOMEM command would then be used to raise the "available lower memory space" so that the compiled binary code can run without interference while also protecting the memory space used by other programs. Once LOMEM has been raised above Decimal 2048 to accomodate memory space for your code example, then the resulting compiled binary code can be loaded and executed from there ($800/2048).
Could it be that the other assemblers you used are in effect doing the above for you?