Jump to content
matthew180

Assembly on the 99/4A

Recommended Posts

Hmm SAMS has 4K pages at EVERY ADDRESS IN 32K and that means a single 4K page can reside at multiple locations at same time too!

                                                                PAGE S3
                              SAMS MAPPER
     ******************************************************************
     The SAMS card has tons of documents as to its function and use.
     So to re-explain these docs would be pointless. Read the docs or
     find some, sorry but the RXB package is already huge.
     In PASS mode the mapper register setup is equivalent to:

     mapper address  mapper  page num            address range
     --------------  ------  --------            -------------
      HEX     Dec            HEX  Dec            memory area
      ---     ---            ---  ---            -----------
     >4004 = 16388 is MR02 = >02 = 02 points to >2000 - >2FFF range
     >4006 = 16390 is MR03 = >03 = 03 points to >3000 - >3FFF range
     >4014 = 16404 is MR10 = >0A = 10 points to >A000 - >AFFF range
     >4016 = 16406 is MR11 = >0B = 11 points to >B000 - >BFFF range
     >4018 = 16408 is MR12 = >0C = 12 points to >C000 - >CFFF range
     >401A = 16410 is MR13 = >0D = 13 points to >D000 - >DFFF range
     >401C = 16412 is MR14 = >0E = 14 points to >E000 - >EFFF range
     >401E = 16414 is MR15 = >0F = 15 points to >F000 - >FFFF range
     (MR=Mapper Register)

     In MAP mode the mapper register setup is equivalent to: EXAMPLE1

     mapper address  mapper  page num            address range
     --------------  ------  --------            -------------
      HEX     Dec            HEX  Dec            memory area
      ---     ---            ---  ---            -----------
     >4004 = 16388 is MR02 = >10 = 16 points to >2000 - >2FFF range
     >4006 = 16390 is MR03 = >11 = 17 points to >3000 - >3FFF range
     >4014 = 16404 is MR10 = >12 = 18 points to >A000 - >AFFF range
     >4016 = 16406 is MR11 = >13 = 19 points to >B000 - >BFFF range
     >4018 = 16408 is MR12 = >14 = 20 points to >C000 - >CFFF range
     >401A = 16410 is MR13 = >15 = 21 points to >D000 - >DFFF range
     >401C = 16412 is MR14 = >16 = 22 points to >E000 - >EFFF range
     >401E = 16414 is MR15 = >17 = 23 points to >F000 - >FFFF range

     (MR=Mapper Register)

                                                            PAGE    S4
                              SAMS MAPPER
     *****************************************************************
 
     In map mode the mapper register setup is equivalent to: EXAMPLE2
 
     mapper address  mapper  page num            address range
     --------------  ------  --------            -------------
      HEX     Dec            HEX  Dec             memory area
      ---     ---            ---  ---             -----------
     >4004 = 16388 is MR02 = >62 =  98 points to >2000 - >2FFF range
     >4006 = 16390 is MR03 = >63 =  99 points to >3000 - >3FFF range
 
     >4014 = 16404 is MR10 = >64 = 100 points to >A000 - >AFFF range
     >4016 = 16406 is MR11 = >65 = 101 points to >B000 - >BFFF range
     >4018 = 16408 is MR12 = >66 = 102 points to >C000 - >CFFF range
     >401A = 16410 is MR13 = >67 = 103 points to >D000 - >DFFF range
     >401C = 16412 is MR14 = >68 = 104 points to >E000 - >EFFF range
     >401E = 16414 is MR15 = >69 = 105 points to >F000 - >FFFF range
 
     (MR=Mapper Register)
 
     In MAP mode the mapper register setup is equivalent to: EXAMPLE3
 
     mapper address mapper  page num             address range
     -------------- ------  --------             -------------
      HEX   Dec            HEX    Dec             memory area
      ---   ---            ---    ---             -----------
     >4004=16388 is MR02 =>1FF9 = 8185 points to >2000 - >2FFF range
     >4006=16390 is MR03 =>1FFA = 8186 points to >3000 - >3FFF range
 
     >4014=16404 is MR10 =>1FFB = 8187 points to >A000 - >AFFF range
     >4016=16406 is MR11 =>1FFC = 8188 points to >B000 - >BFFF range
     >4018=16408 is MR12 =>1FFD = 8189 points to >C000 - >CFFF range
     >401A=16410 is MR13 =>1FFE = 8190 points to >D000 - >DFFF range
     >401C=16412 is MR14 =>1FFF = 8191 points to >E000 - >EFFF range
     >401E=16414 is MR15 =>2000 = 8192 points to >F000 - >FFFF range
 
     (MR=Mapper Register)

This from RXB 2020 documents.

So the SAMS blows away any other Memory type of device as you can have copies of same memory location in SAMS at same time.

One page could have self modified code and another copy could be a back up to restore everything back to original and a third another version and a forth so on.........

Share this post


Link to post
Share on other sites
11 minutes ago, RXB said:

Hmm SAMS has 4K pages at EVERY ADDRESS IN 32K and that means a single 4K page can reside at multiple locations at same time too!

                                                                PAGE S3
                              SAMS MAPPER
     ******************************************************************
     The SAMS card has tons of documents as to its function and use.
     So to re-explain these docs would be pointless. Read the docs or
     find some, sorry but the RXB package is already huge.
     In PASS mode the mapper register setup is equivalent to:

     mapper address  mapper  page num            address range
     --------------  ------  --------            -------------
      HEX     Dec            HEX  Dec            memory area
      ---     ---            ---  ---            -----------
     >4004 = 16388 is MR02 = >02 = 02 points to >2000 - >2FFF range
     >4006 = 16390 is MR03 = >03 = 03 points to >3000 - >3FFF range
     >4014 = 16404 is MR10 = >0A = 10 points to >A000 - >AFFF range
     >4016 = 16406 is MR11 = >0B = 11 points to >B000 - >BFFF range
     >4018 = 16408 is MR12 = >0C = 12 points to >C000 - >CFFF range
     >401A = 16410 is MR13 = >0D = 13 points to >D000 - >DFFF range
     >401C = 16412 is MR14 = >0E = 14 points to >E000 - >EFFF range
     >401E = 16414 is MR15 = >0F = 15 points to >F000 - >FFFF range
     (MR=Mapper Register)

     In MAP mode the mapper register setup is equivalent to: EXAMPLE1

     mapper address  mapper  page num            address range
     --------------  ------  --------            -------------
      HEX     Dec            HEX  Dec            memory area
      ---     ---            ---  ---            -----------
     >4004 = 16388 is MR02 = >10 = 16 points to >2000 - >2FFF range
     >4006 = 16390 is MR03 = >11 = 17 points to >3000 - >3FFF range
     >4014 = 16404 is MR10 = >12 = 18 points to >A000 - >AFFF range
     >4016 = 16406 is MR11 = >13 = 19 points to >B000 - >BFFF range
     >4018 = 16408 is MR12 = >14 = 20 points to >C000 - >CFFF range
     >401A = 16410 is MR13 = >15 = 21 points to >D000 - >DFFF range
     >401C = 16412 is MR14 = >16 = 22 points to >E000 - >EFFF range
     >401E = 16414 is MR15 = >17 = 23 points to >F000 - >FFFF range

     (MR=Mapper Register)

                                                            PAGE    S4
                              SAMS MAPPER
     *****************************************************************
 
     In map mode the mapper register setup is equivalent to: EXAMPLE2
 
     mapper address  mapper  page num            address range
     --------------  ------  --------            -------------
      HEX     Dec            HEX  Dec             memory area
      ---     ---            ---  ---             -----------
     >4004 = 16388 is MR02 = >62 =  98 points to >2000 - >2FFF range
     >4006 = 16390 is MR03 = >63 =  99 points to >3000 - >3FFF range
 
     >4014 = 16404 is MR10 = >64 = 100 points to >A000 - >AFFF range
     >4016 = 16406 is MR11 = >65 = 101 points to >B000 - >BFFF range
     >4018 = 16408 is MR12 = >66 = 102 points to >C000 - >CFFF range
     >401A = 16410 is MR13 = >67 = 103 points to >D000 - >DFFF range
     >401C = 16412 is MR14 = >68 = 104 points to >E000 - >EFFF range
     >401E = 16414 is MR15 = >69 = 105 points to >F000 - >FFFF range
 
     (MR=Mapper Register)
 
     In MAP mode the mapper register setup is equivalent to: EXAMPLE3
 
     mapper address mapper  page num             address range
     -------------- ------  --------             -------------
      HEX   Dec            HEX    Dec             memory area
      ---   ---            ---    ---             -----------
     >4004=16388 is MR02 =>1FF9 = 8185 points to >2000 - >2FFF range
     >4006=16390 is MR03 =>1FFA = 8186 points to >3000 - >3FFF range
 
     >4014=16404 is MR10 =>1FFB = 8187 points to >A000 - >AFFF range
     >4016=16406 is MR11 =>1FFC = 8188 points to >B000 - >BFFF range
     >4018=16408 is MR12 =>1FFD = 8189 points to >C000 - >CFFF range
     >401A=16410 is MR13 =>1FFE = 8190 points to >D000 - >DFFF range
     >401C=16412 is MR14 =>1FFF = 8191 points to >E000 - >EFFF range
     >401E=16414 is MR15 =>2000 = 8192 points to >F000 - >FFFF range
 
     (MR=Mapper Register)

This from RXB 2020 documents.

So the SAMS blows away any other Memory type of device as you can have copies of same memory location in SAMS at same time.

One page could have self modified code and another copy could be a back up to restore everything back to original and a third another version and a forth so on.........

 

Can you map memory into >6000 to >6FFF and >7000 to >7FFF?  Or are those pages blocked as I noticed the mapper registers from >4008 to >4012 are not listed?  And yes, I understand one can map in/out memory from the 32K range, just trying to understand if I can expand to 40K by opening up the >6000 to >7FFF range from within SAMS.

 

 

Share this post


Link to post
Share on other sites
15 minutes ago, 9640News said:

 

Can you map memory into >6000 to >6FFF and >7000 to >7FFF?  Or are those pages blocked as I noticed the mapper registers from >4008 to >4012 are not listed?  And yes, I understand one can map in/out memory from the 32K range, just trying to understand if I can expand to 40K by opening up the >6000 to >7FFF range from within SAMS.

 

 

You can only map >2000, >3000, >A000, >B000, >C000, >D000, >E000, >F000

  • Like 2

Share this post


Link to post
Share on other sites

The E/A cart doesn't provide RAM at >6000->7FFF unless it's also a Super Cart.

Edited by Asmusr
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
1 hour ago, Asmusr said:

The E/A cart doesn't provide RAM at >6000-7FFFF unless it's also a Super Cart.

It's one of my favourite enhancements. :) 

 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Asmusr said:

The E/A cart doesn't provide RAM at >6000->7FFF unless it's also a Super Cart.

It is for my requirements, thus I have 40K of useable ram.  I needed the extra ram for that program with the new features that were added and the extra code for the TIPI interface.

Share this post


Link to post
Share on other sites

I have built, hmm.. sitting here 4ea 32k supercarts. As a normal routine for each I copy >2000 through all the ea utils that are tabled, like lee explained, and I copy that to one of my 4 banks of supercart space, then I can always push that table back to >2000 again to make my utils always available to my ea programs.

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, retroclouds said:

You can only map >2000, >3000, >A000, >B000, >C000, >D000, >E000, >F000

Again 1 Meg, how much can you map into >6000 to >7FFF and the answer is half as much which is 512K at most.

 

Also the SAMS has the special issue of being able to have same thing being changed at same time in another address let me explain:

I put a Assembly program that modifies itself at >A000 and that same routine is at >B000 as both of those 4K pages are the same page say page 76 in SAMS.

So SAMS page 76 resides at both >A000 and >B000 so any change to >A000 will be exactly duplicated in >B000 so do you see the implications for SELF MODIFIED CODE?

That means if you modifiy code at >B000 it will be exactly duplicated at >A000 thus you can make a copy of page 76 into another page say 86 now you have a restore.

I used this feature to do a RXB SECTOR COPY of a disk that removed the copy protections and copied the results from DISK 1 to DISKS 2, 3 and 4.

 

I can see the fixation on Cartridge RAM but it is ONLY 8K not 32K!!!!

Share this post


Link to post
Share on other sites
On 8/30/2021 at 5:25 PM, 9640News said:

Got a question.  Is there a way with the Editor/Assembler module present, to use GPL code to load an EA #5 file (4 parts), into memory?

 

What I would like to do would be to have a keypress detected in a running assembly program, that would load a revised version of the program replacing itself.  It would load the program from >A000 to >FFFC and from >6000 to ~>7A00.


Beery

Maybe I am having a “senior” moment, but if you press 1 from the EA menu, does it not load an EA5 program EDIT1 etc, and if you press 2 does it not load EA5 program ASSM1 etc?

  • Like 1

Share this post


Link to post
Share on other sites

Pressing 1 loads the editor but note, there are other menus depending on the first menu selections.

Edited by GDMike

Share this post


Link to post
Share on other sites

Well REA still has those keys you can use 1, 2, 3, and 5 for same menu items but the screen shows something diffrent:

1126657260_REAScreen.thumb.png.359197e82c0df6fb4d2608e600060e4b.png Also S path sets your Editor or Assembler so you never have to type it in twice.

 

Edited by RXB
missing text

Share this post


Link to post
Share on other sites

I have been using the standard TI assembler to create ALC support for my current XB project, but unfortunately the ALC source code has gotten too large for the E/A editor. What I usually do is create the source in Notepad++ then copy and paste into the EA editor then assemble (I know... I'm old fashioned that way!). I wanted to used Stevie instead but it does not run in Classic99 and so I can't paste into it. I still managed to get around the problem by simply breaking up the source code into 2 files and using the COPY directive of the EA assembler to assemble them together. It works, but now I have to maintain 2 files instead of one.

So I dug up the Win99asm cross-assembler that is part of the Win994a emulator suite and it had no problem assembling the entire file in less than a second with no errors and dutifully produces the compressed object code file I need. Unfortunately, when I try to load that file from XB, I'm getting a tag error, which is telling me that the required -O tag is not being generated by the assembler. Has anyone here encountered this issue?

 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Vorticon said:

I have been using the standard TI assembler to create ALC support for my current XB project, but unfortunately the ALC source code has gotten too large for the E/A editor. What I usually do is create the source in Notepad++ then copy and paste into the EA editor then assemble (I know... I'm old fashioned that way!). I wanted to used Stevie instead but it does not run in Classic99 and so I can't paste into it. I still managed to get around the problem by simply breaking up the source code into 2 files and using the COPY directive of the EA assembler to assemble them together. It works, but now I have to maintain 2 files instead of one.

So I dug up the Win99asm cross-assembler that is part of the Win994a emulator suite and it had no problem assembling the entire file in less than a second with no errors and dutifully produces the compressed object code file I need. Unfortunately, when I try to load that file from XB, I'm getting a tag error, which is telling me that the required -O tag is not being generated by the assembler. Has anyone here encountered this issue?

 

@VorticonI do have a version of Stevie that runs on classic99, I haven't shared that one yet, as I haven't tested it much. Will send it to you as a PM. Perhaps you might want to give it a try.

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Vorticon said:

So I dug up the Win99asm cross-assembler that is part of the Win994a emulator suite and it had no problem assembling the entire file in less than a second with no errors and dutifully produces the compressed object code file I need. Unfortunately, when I try to load that file from XB, I'm getting a tag error, which is telling me that the required -O tag is not being generated by the assembler. Has anyone here encountered this issue?

 

The XB loader cannot handle compressed-object-code files.

 

...lee

  • Like 3

Share this post


Link to post
Share on other sites
4 hours ago, Lee Stewart said:

 

The XB loader cannot handle compressed-object-code files.

 

In general that's true. However, the loader in XB 2.8 G.E.M. can indeed handle compressed object code files.

 

I have never figured out how to generate compressed object code files with Assm994a. Uncompressed has worked fine for my purposes, but I think compressed loads a little faster.

 

(Edit) - I played around with Assm994a and finally got it to produce a compressed object file, but XB 2.8 G.E.M. could not load this. I got a memory full message

The TI assembler can be used to make a compressed object file, and this can be loaded by XB 2.8 G.E.M.

Edited by senior_falcon
  • Like 2

Share this post


Link to post
Share on other sites

I maintain several separate assy files for one program. And some are just support files that I can use along with other future programs.

It's orderly, and nothing out of the ordinary to use the "copy" to next file to process an object file for me for very large programs, as it's actually standard for me to do and actually breaking down each source file gives me better handling on what and where things are, especially for debugging. But that's me, I kinda like using the link to file approach this way.

 

 

 

Share this post


Link to post
Share on other sites
7 hours ago, Lee Stewart said:

 

The XB loader cannot handle compressed-object-code files.

 

...lee

Well it does not seem to handle uncompressed object code either unfortunately...

Share this post


Link to post
Share on other sites
2 hours ago, senior_falcon said:

In general that's true. However, the loader in XB 2.8 G.E.M. can indeed handle compressed object code files.

 

I have never figured out how to generate compressed object code files with Assm994a. Uncompressed has worked fine for my purposes, but I think compressed loads a little faster.

 

(Edit) - I played around with Assm994a and finally got it to produce a compressed object file, but XB 2.8 G.E.M. could not load this. I got a memory full message

The TI assembler can be used to make a compressed object file, and this can be loaded by XB 2.8 G.E.M.

There is a check box for compressed object code in Asm994a, at least in the latest version. And it does not run with XB 2.8 GEM, and neither does the uncompressed object code...

Attached is a zip file with the compressed (.cob) and uncompressed (.obj) produced in case anyone is interested. I'm stumped...

KPSUPi.zip

Share this post


Link to post
Share on other sites

KPSUP.GIF.584b3fd90ada4ed2fa83d99368e1b7c0.GIF

Loads fine with the uncompressed object code. As noted earlier, .COB files generated by Assm994a cannot be loaded for unknown reasons.

First free address is >365E. The last free address is >4000, which means you haven't added anything to the DEF table.

(By the way, did you notice how quickly the file was loaded?)

 

In general this should not be a problem when writing support routines for XB, but this paragraph from the XB 2.8 G.E.M. manual is important:

CALL LOAD(filename) now uses the fast assembly language loader from the minimemory cartridge. This is about 20x faster than the normal loader used by other Extended BASICs. You can now load compressed code, use REFs and most of the other features missing from the normal XB loader. Do not AORG code to memory from >2008 to >20F7. This ram is temporarily used by the loader. When the loader is finished these addresses are then reset to the normal values provided by CALL INIT. Error messages are the same as in XB: DATA ERROR is used for CHECKSUM ERROR, and UNRECOGNIZED CHARACTER is used for ILLEGAL TAG.

Edited by senior_falcon
  • Like 2

Share this post


Link to post
Share on other sites

Strange. I'm getting an "UNRECOGNIZED CHARACTER" error when attempting to LOAD the uncompressed object file. This means that it's a tag issue. Assembling the file using the TI assembler then loading it works fine.

Would you mind attaching your copy of Asm99? 

Share this post


Link to post
Share on other sites

What I loaded was what you posted. This was created with your copy of Asm99, so I think the problem lies elsewhere. Can you load the file using normal XB?

If you want to try, my copy of Asm99 is included with the XBGDP. I should add that your setup should follow the instructions for using the compiler and Asm99.

Edited by senior_falcon

Share this post


Link to post
Share on other sites

ASM994A creates uncompressed files without a carriage return at the end of each line.. it's not standard Windows text format. I had to write special case code in Classic99 to be able to read them. Maybe that's the issue?

 

(Edit: this is untrue, it was xas I had to write special read code for)

Edited by Tursi

Share this post


Link to post
Share on other sites

OK figured out the issue: in the asm994a project window I was removing the extension of the output object file, i.e changing it from .obj to no extension prior to assembling (I dislike extensions with TI files), and that was causing the problem. Unclear if the issue is with asm99a or Classic 99 or as to why this is even problematic. Keeping the .obj extension solved it...

Share this post


Link to post
Share on other sites

Ah, well, that's clear then. The output of Asm994a -- even object files -- is Windows text. It's not a TI file. When you remove the extension, Classic99 is no longer instructed to consider it a Windows text file (only .OBJ and .TXT are). It can't find a header, so it assumes the type must be DF128 as per the standard. This would have shown in the debug log.

 

With extension:

DSR opcode >0 (OPEN) on PAB >3755, filename DSK0.TEST.OBJ
Opening DSK0.TEST.OBJ on drive type FIAD
PAB requested file type is DF0
Allocating file buffer 0
Detected d:\classic99\dsk1\TEST.OBJ as a Host TEXT file
d:\classic99\dsk1\TEST.OBJ read 9 records

Without:

DSR opcode >0 (OPEN) on PAB >36E1, filename DSK0.TEST
Opening DSK0.TEST on drive type FIAD
PAB requested file type is DF0
Allocating file buffer 0
Detected d:\classic99\dsk1\TEST as a PC (headerless) file - read as DF128.
d:\classic99\dsk1\TEST read 6 records

Debug log. Why guess when the information is right there? ;)

 

Edited by Tursi
  • Like 1

Share this post


Link to post
Share on other sites

I really, really, really need to make better use of the Classic 99 debugger :)

Good info. Thanks!

Now back to our regular programming...

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...