S-C Macro Assembler v2.0 question

8 posts / 0 new
Last post
Offline
Last seen: 3 days 18 hours ago
Joined: Oct 27 2020 - 02:21
Posts: 18
S-C Macro Assembler v2.0 question
AttachmentSize
File S-C Assembler Question.docx805.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.

Offline
Last seen: 1 week 5 days ago
Joined: Jun 25 2020 - 17:00
Posts: 219
S-C Assembler 2.0

What Apple II ROM are you referencing?

 

Offline
Last seen: 1 week 5 days ago
Joined: Jun 25 2020 - 17:00
Posts: 219
LaserMaster wrote:What Apple
LaserMaster wrote:

What Apple II ROM are you referencing?  Applesoft I reckon.

$#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.

 

 

Offline
Last seen: 1 week 5 days ago
Joined: Jun 25 2020 - 17:00
Posts: 219
I read your docx again

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?

Offline
Last seen: 3 days 18 hours ago
Joined: Oct 27 2020 - 02:21
Posts: 18
Response to LaserMaster

FileLaserMaster Response.docx  Please see the attached MS Word document for the response.

Offline
Last seen: 3 days 18 hours ago
Joined: Oct 27 2020 - 02:21
Posts: 18
LaserMaster Response 2

FileLaserMaster Response2.docx

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.

Offline
Last seen: 1 week 5 days ago
Joined: Jun 25 2020 - 17:00
Posts: 219
sbaker51 wrote:LaserMaster
sbaker51 wrote:

FileLaserMaster Response.docs and LaserMaster Response2.docx

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.

 

Offline
Last seen: 1 week 5 days ago
Joined: Jun 25 2020 - 17:00
Posts: 219
Our IIe's must have drastically different configurations
LaserMaster wrote:

 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?

 

Log in or register to post comments