Linking loader for PC

[Asmusr]

Has anyone written a linking loader that works on a PC? Something that can turn an object file into a binary file without going through the steps of loading the object file into an emulator and dumping the RAM. The use case is for creating a cartridge image from the output of WinAsm99 plus some data files.

[Gazoo]

One would assume that you are using an emulator to test the object code. Why not just use RAG LINKER at that point to create the image files, it will only take a few seconds more.

 

Gazoo

[Asmusr]

I have heard about the RAG linker a few times, but I don't know anything about what it does or how it works.

Here is some more background information about what I'm trying to do:

I'm thinking about how you would go about implementing an assembly game targeted for release in cartridge only. I'm not thinking about anything as advanced as running code across multiple banks or even running it from cartridge space at all. What I have in mind is simply a cartridge that copies all program code to the 32K RAM and uses the rest of the cartridge banks as a static data store for maps, graphics, etc. (far more data than fits into RAM). The question is how to implement a manageable program-assemble-run test cycle. With ordinary assembly programming using WinAsm99 and Classic99 you can assemble your code and run it about 10 secs, and I want something similar to that.

As I see it, the most desirable would be to keep you program separate from you data until the time you're ready to build the final cartridge. You program would be loaded from E/A#3 as usual and the data would be 'mounted' in a cartridge. But the problem is how to switch the cartridge in Classic99 without resetting the TI-99?

If that's not possible then you have to build the full cartridge file for each test cycle. For this you would need to convert the object file into a binary file, which is the reason I asked about the linker.

There is also the issue about how to refer to your data from your program code. Having to maintain a list of EQUates for each 'data object' could become a nightmare depending on how many objects you have and how often you need to change the data, so it would be nice if you could refer to the data using ordinary labels. WinAsm99 seems to support multiple segments in the same memory region. So I'm thinking if it would be possible to assemble a project consisting of one code segement AORG >A000 and several data segments AORG >6000. Before you accessed any data from the cartridge you would have to add the right bank switching code, of course, but apart from that you could use labels to refer to the data (assuming no data block is longer that 8K). The linker in this case would have to be able to identify the >6000 segments as banks that should undergo special treatment.

Sorry for rambling. Has anyone else thought about this?

[RXB]

I sent this in another post so here is a duplicate or RAG stuff.

RAG.zip

Edited September 5, 2014 by RXB

[+Lee Stewart]

I have a method for managing copying a block of code from ROM to RAM that does not involve maintaining a list of EQUates. You do need to use the same EQUate form for each and every label that is not a jump target:

SRCBEG                   <--source beginning address for copying to RAM
DST    EQU  >A000        <--RAM destination address
LABEL1 EQU  DST+$-SRCBEG
       <code>
LABEL2 EQU  DST+$-SRCBEG
       <code>
LABEL3 <code>             <--jump target
       <code>
LABEL4 EQU  DST+$-SRCBEG
       <code>
LABEL5 EQU  DST+$-SRCBEG
       <code>
LABEL6 <code>             <--jump target
       <code>
LABEL7 EQU  DST+$-SRCBEG
       <code>
SRCEND                    <--source ending address for copying to RAM

The only tedious part of this procedure is remembering that every label between SRCBEG and SRCEND that is not a jump target must be the same EQUate (LABELx EQU DST+$-SRCBEG). This insures that the actual RAM addresses are properly calculated. As to the EQUate, "$-SRCBEG" calculates the proper offset to add to "DST" for each label. Obviously, the jump targets should not be EQUates.

 

For the data blocks, you would need to know, of course, what bank has the data you want for proper switching. The beauty of your plan is that you would not need to do anything but switch to the desired bank to retrieve data. For fbForth 2.0, I absolutely must return to either the calling bank or bank 0 because I am executing from ROM space.

 

...lee

[Asmusr]

It has taken me ages to work out how to do this, but I finally have a solution that allows me to compile and build a cartridge file in two simple steps. The cartridge loads program code into RAM but keeps all major data in ROM to save the RAM for the program.

 

The assembly is done with WinAsm99. I use a CSEG directive to separate each 8K cartridge bank. This is output as a P tag in the object file.

 

Each data bank has AORG >6000 and starts with the header followed by the data at >6100. Each program bank is also starts with AORG >6000 for the header, but is then followed by program code AORG >A000 or >C000. This way I don't have to use Lee's otherwise excellent method for assembling code in one location that is targeted for another location. The program banks are copied to RAM by the cartridge header program.

 

I have written my own loader in Java that converts the object code into a cartridge file. When it sees a CSEG directive it moves the loading address to the next bank. It also relocates the program code into cartridge space, so even though it's AORG >A000 it goes into a cartridge bank, e.g. at >6100-. This is all very easy to do with your own loader, and all you have to do is assemble first and then run the loader. You can then try the cartridge immediately in Classic99, and it only takes a few seconds to test a change.

 

Now I can add more sprites patterns, music, etc. to Sabre Wulf.

[+Ksarul]

Nice--at this rate, we'll have a complete cartridge IDE for PC-side manipulation very soon!

[+retroclouds]

..

I have written my own loader in Java that converts the object code into a cartridge file. When it sees a CSEG directive it moves the loading address to the next bank. It also relocates the program code into cartridge space, so even though it's AORG >A000 it goes into a cartridge bank, e.g. at >6100-. This is all very easy to do with your own loader, and all you have to do is assemble first and then run the loader. You can then try the cartridge immediately in Classic99, and it only takes a few seconds to test a change.

 

 

Hi Rasmus,

 

any chance you can publish your loader? I'd like to create a cartridge image for the Tomy Tutor.

winasm99 does only allow me to create a cartridge binary if the AORG is in the >6000 - >7FFF range, which is not the case for the tomy tutor (must AORG to >8000).

 

Thanks

Filip

[+retroclouds]

I quickly rolled a poor man's loader that will have to do the job for now

[Asmusr]

I quickly rolled a poor man's loader that will have to do the job for now

 

Cool. The reason I haven't posted my loader before is that it's not a general purpose program. It doesn't even have a user interface but is hard coded to specific projects. But here's the Java source code in case you need it.

Loader.zip

[+retroclouds]

Thanks! I appreciate it a lot