I'm having trouble using iondetect. I've looked at the code for pheonix and for orzunoid, but I can't seem to figure out how iondetect works so I can make external levels for my program, Rush Hour Greyscale.

I've been able to figure out that each time iondetect is called, it searches for the next program in the vat (or variable in the vat, i don't know which it is), and checks if it matches a detection string that's the first line of data for that variable. However, either the documented returns are wrong, or i'm having wierd problems with Brass, I can't seem to get iondetect to detect any string.

Here's my sample code I've kind of copied and modified so I can test it.
Main program

Code:


Level program

Code:


Could someone tell me what i'm doing wrong? And no, the problem is not that I'm accidentally compiling my level program for ion/mirageos! It's being compiled correctly as nostub

I think I see what you're doing wrong. Try this instead:

Main program

Code:

hmmm... that solved half of the problem. I forgot about the first token in an asm program... the ".db $BB,$6D". I included into the level as well as the detection string, and along with the code you gave me it worked. Thanks for your help!

No problem. I thought of that token issue, but I then figured iondetect took care of it. I guess not.

Code:

Welcome back, HaveACalc! Are you going to stay awhile?

I hope so. College auditions (percussion and piano performance) start next week, and that was the reason that I put a halt to my programming in the first place back at the beginning of this schoolyear. Even though I can't be an active programmer again until around March or April, I'll try to stop by often.

What's changed? (off-topic )

Not much. The new pastime seems to be taunting Simms, Kllrnohj still flames everyone, it's been a bit slow, but in the past few days posting has picked up a bit.

Why is this topic where it is?

Oh noes, your statement is going to have tons of junk after it, haveacalc. You didn't zero-terminate!

All I did was move a block of data to the server. It's your job to decide what it means and where it ends!

Well, I use my job to decide that you copied it incorrectly.

maybe he's implying that he's writing to a 9-byte area, and the 9th byte is always 0 (to save size and time, though not much)

Anyways, back on topic:

What's ptemp and why did you choose that (I noticed the same label was used in iondetect's scource, but I was unable to find out what it's for)?
Also, I can't seem to figure out a way to show one program at a time. I can figure out how to go to the next program, I just have to call iondetect again. However, going backwards is trickier. I can't have iondetect "detect" the previous program again, unless I started from the beginning of the VAT again. Maybe I'm missing something...

Another question I had is that iondetect bcall's ROMtoRAM to unarchive archived programs. However, I didn't see anyway that it would re-archive the program. Is that up to me to make my program do that (if I have to)? And with the same thing I'm doing above, would it "overwrite" the last un-archived program? or would it try to allocate more and more memory until it couldn't anymore?

and when you say ROMtoRAM, if you're talking about FlashtoRam, that bcall will only copy a specified number of bytes in ROM to a destination in RAM pointed to by de. Most likely (haven't looked @ idetect source really), idetect only copies the beginning of the archived variable, based on the length of the detection string. Thus, the variable isn't actually unarchived, though I'm probably wrong.

I haven't taken a close look at iondetect, either. Joe was a great programmer, but he had a habit (or at least in the Ion source) of purposely not commenting it, making it hard to tell what he's trying to do.
so ld hl,(ptemp) is putting the end of the sybol table for progs appvars, etc. into hl (specifically, (ptemp) into l and (ptemp-1) into h)? Why would they want to do this (I've never been good with the symbol table)? And wouldn't it have to be un-archiving the program because it would have to allocate the necessary memory spots to put it there?

No, (ptempt) is the *address* after the last byte of the symbol table, in other words the first empty byte below the symbol table in memory. If you have a bunch of numbers which are the start of successive entries in the VAT reading from high to low memory, if any of them is the same as (ptemp), you know that and all lower ones are invalid since they're beyond the lower limit of the table. In short, it's how you know when you've reached the end of the table.

If it's archived and there's enough free RAM, it just copies the program from ROM to the empty part of RAM and returns a pointer to the location after the detection string.

Oh, that's what ptemp is for.

So iondetect's not really unarchiving a program, just copying the data? I don't need to re-archive it or anything?

That's correct. The only issue with that is it doesn't store writeback information, so don't try to store any modifiable information in levelsets unless you're prepared tp manually write back the changes. Keep such data in your main program where Ion, Doors CS, and even sometimes MirageOS () will do proper writeback for you.

oh, dang. How would I go about doing write-back to the level (in archive, if I'm correct writing to it in RAM would be done then and there)