Jump to content
IGNORED

Creating memory image files that use entire lower 8K RAM


adamantyr

Recommended Posts

Hello fellow 99'ers...

 

So I'm working on my CRPG again, as part of my re-start process I went ahead and added up the entire program size by section. I'm getting towards the end of the upper 24k RAM block, so I am doing some inventory to plan out how to organize the program effectively.

 

However, I realized the native way you create memory files is to first load them through E/A option #3, which is tagged object code. That means that the lower 8K RAM can NEVER be fully utilized because part of it is used for the loader and symbolic addresses. So you really can only have around 28-30k of code before it will run out of room.

 

This isn't going to impact game design; I can always use AORG and relocate several sections of the program into the cartridge RAM space at >6000, and use the 8K lower RAM as pure memory buffer by the program itself. So long as I keep my total program size to 32k and under I should be fine. I'm just puzzled if there is some other method I'm missing to create memory image files that will not impact the 8K space?

Link to comment
Share on other sites

Also, I am familiar (and use!) the Save #5 utility in Classic99's debugger. The trick here is, I still have to load my entire program into memory first through EA option #3. So doesn't that mess with the lower 8K RAM?

 

My xas99 assembler can create memory images directly without the need of the SAVE utility, as long as it is just one object file.

 

But I always thought that memory images have to be contiguous, so you wouldn't be able to merge both memory segments into one file?!

Link to comment
Share on other sites

TI Forth's boot program (FORTH) loads two memory images from the same file (FORTHSAVE). One image is for low RAM and the other for high RAM. FORTH (1280 bytes or less) is loaded into an area of high RAM that will not get overwritten by the image until control is handed off to the Forth interpreter. The entire FORTHSAVE file (9512 bytes) is loaded into VRAM with the disk DSR's level 3 LOAD routine; so, of course, there needs to be enough space in VRAM to hold it. With simultaneously open files set to 1, there is about 11 kB of VRAM space for this purpose. You lose 518 bytes for each additional file you need open. Once FORTHSAVE is in VRAM, the boot program copies the low-RAM segment followed by copying the high-RAM segment.

 

You do have to load the program parts with the E/A loader through option #3; but, if you structure low memory to use the loader and symbol table areas as buffer and stack space for your program with BSS directives, you can avoid overwriting them until they are no longer needed by the loader and symbol table. You could write a small save program to load into space that is unused until your program runs that will SAVE segments of your program to separate files that just such a small LOAD program can load from those same files.

 

One way to solve loading as large a segment as you wish to low RAM is to arrange assembly of the high RAM part separately from the low RAM part. Then, write the low RAM part to assemble to high RAM for SAVEing, but with labels that are not JMP targets EQUated to their low RAM destinations for later LOADing to low RAM, in exactly the same manner as you would manage copying RAM copy from cartridge space. You would still need to write that little loader to run in an unused space as mentioned above.

 

...lee

Link to comment
Share on other sites

Hmm... I just tested throwing an AORG >6000 into my compiled code... it created the object file just fine, but attempting to load it resulted in a MEMORY FULL error.

 

Anyone know a good way to make use of the Superspace cartridge RAM for loading? Maybe the E/A loader doesn't consider it legitimate space?

 

Obviously I can get cute and assemble fragments of my program and then hex-edit the files to alter the memory images to go where they need to, but I was hoping to do this a bit more elegantly...

Link to comment
Share on other sites

Ah, nevermind, figured the memory full problem out... The program labels and endings need to be within the high memory block.

 

What I'm seeing a problem with now, though, is that the Save Memory utility in Classic99 doesn't let me save the RAM that's in the cartridge space as a memory image file. It only works for low RAM and high RAM.

 

So the ONLY way I'm going to be able to load code segments is by writing my own custom loader that runs either in program to load code segments in, or hack a memory image file to update the addresses to load it into a different location. I wonder if that would even work though...

  • Like 1
Link to comment
Share on other sites

According to the SuperSpace manual you have to use the loader on Disk 1. To be perfectly honest I have not done this, yet. I assembled my cartridge and it works in Classic99 and MESS, and I have copied it over to a disk image in PROGRAM format. I will transfer that disk to my CF7+ and then load it into SuperSpace using the loader. You will probably get to yours before I do.

Link to comment
Share on other sites

Ah, nevermind, figured the memory full problem out... The program labels and endings need to be within the high memory block.

 

What I'm seeing a problem with now, though, is that the Save Memory utility in Classic99 doesn't let me save the RAM that's in the cartridge space as a memory image file. It only works for low RAM and high RAM.

 

So the ONLY way I'm going to be able to load code segments is by writing my own custom loader that runs either in program to load code segments in, or hack a memory image file to update the addresses to load it into a different location. I wonder if that would even work though...

 

I posted somewhere how I did a similar thing for fbForth 2.0. I'll look for it later this evening.

 

...lee

Link to comment
Share on other sites

...

So the ONLY way I'm going to be able to load code segments is by writing my own custom loader that runs either in program to load code segments in, or hack a memory image file to update the addresses to load it into a different location. I wonder if that would even work though...

 

OK—Here is how I coded it for ROM storage to later copy down to low RAM for program execution.

 

...lee

Link to comment
Share on other sites

Not quite what I meant... good technique though!

 

I think I have a plan on this...

1. Set up the compiled object file with AORG to put things in the right place

2. Load the object file into memory via option #3

3. Dump the memory in Classic 99

4. Get the individual segments and hand copy them into a hex editor to create the memory image files

 

It's slow and ponderous, but it should work... it makes me wish my CF7+ would emulate the ASM card so I could develop in that...

Link to comment
Share on other sites

Hey, FWIW, I successfully loaded the cartridge file output from WinAsm99 into my SuperSpace II using the CVAC utility. I mounted SuperSpace Disk 1 as DSK1 and my file in DSK2. E/A#3 DSK1.CVAC, then run program CVAC, option 2, DSK2.SOUNDTEST. Easy peasy.

 

I guess your biggest issue is exporting an image file you can use for this. I cannot help with that as I am assembling directly for cartridge with a GROM header.

  • Like 2
Link to comment
Share on other sites

Ah, my technique worked! It's definitely the hard way of doing it, but at least it works!

 

I put the AORG's in my building file to put part of my code (mostly static data, common routines) into the Cartridge RAM at >6000. The rest went into high memory. After loading it, I just do a memory dump from Classic99 and copy out the binaries. I could probably even directly edit the object code file as well for this, actually...

 

Incidentally, my favorite hex editor for this work is Hex Workshop, which works fantastically well! Well worth the $30 or so for a license.

Link to comment
Share on other sites

One small addendum...

 

So I was able to push around 6.5k of routines into the Cartridge RAM area, no problem. This has freed up just a little over 8k in high RAM, which should be sufficent for me to finish the game! Plus it lets me preserve the low RAM block for memory.

 

Curiously, though, the E/A #3 loader rejected my attempt when I had around 7.5k of code in the cartridge RAM area, reporting "memory full". It comes back IMMEDIATELY with this, which tells me that it was checking some kind of value somewhere for size and rejecting it... I wonder if it's confusing the cartridge RAM for the low RAM?

Link to comment
Share on other sites

Cartridge RAM located at >6000 to >7FFF

 

Lower 8K RAM located at >2000 to >3FFF

 

RXB has a built in Lower 8K Memory Image Loader/Saver that also can use the SAMS.

Does not cost any RAM to make work and can load the entire 1 MEG of RAM using XB program running from VDP.

How is the for efficiency?

Link to comment
Share on other sites

Just use Rag Linker. It's simple to use and will convert object code for the full 32k into EA5 image programs. Been using it for at least 20 years with nary a problem.

 

Gazoo

Does it also convert Superspace Cartridge RAM at >6000? Because that's what I need, really. I really wish I could edit topic subjects...

Link to comment
Share on other sites

Does it also convert Superspace Cartridge RAM at >6000? Because that's what I need, really. I really wish I could edit topic subjects...

 

I believe so. I've never used it for that, but I think there's an option for it if you use a Control file. It should be easy to look up in the docs.

 

Gazoo

Link to comment
Share on other sites

I believe so. I've never used it for that, but I think there's an option for it if you use a Control file. It should be easy to look up in the docs.

 

Gazoo

I also have used RAG to assemble and link DSR code in the 4000 space. Though from what I recall in that case, I had to also force the code to "live" in that address space, most likely with AORG. Whether this is required for the lower 8K or not, I cannot say. Just passing along for reference.
Link to comment
Share on other sites

... I really wish I could edit topic subjects...

 

Being a subscriber gives you 30 days of editing privileges as opposed to only an hour, otherwise. I did not become a subscriber for that purpose—I just figured I've been on here nearly 4 years and only paid my $30 once and just figured I should do it again. But—it is nice to be able to make those corrections in a more leisurely manner. I just wish I could once again edit post #1 of my magnum opus.

 

...lee

Link to comment
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...