I have all the levels unarchived and they work fine...no resetting or anything! Hmmmm...

This problem has only been happening on the 83+SE. The 83+ and 84+/SE should work (or they have been working)...

I doubt this is the case (see below...)

Very, very impressive; much better than my own. I could play this all day!

How about some high scores?

It does have a highscore feature or are you asking for our highscores?

Yes, what are your high scores? So far, my highest is 24112 in Gaia (and I can back that up with a screenie) But it is subject to change ... :)

Ha! 61090 in Gaia for me! :-)

Thanks to TilEm's new tracing and symbol loading capabilities... :) </plug>

I've located the bug that causes it to crash under low-RAM conditions on the 83/83+. Under certain conditions, it will try to decompress the table data into free RAM when there is in fact far too little free RAM available. The result is massive stack corruption.

Here's the problematic bit of code (PINBALL.asm line 143; conditional on 83/83+)

ld de,(MEMEND) ; Checking free memory before doing anything (83 and 83+)
ld hl,(MEMSTART)
ld bc,MEMUSED
add hl,bc
sbc hl,de
ret nc ; Exit if there isn't enough memory

Anyone see a problem with it? I didn't at first. The problem is that if (MEMSTART) + MEMUSED is greater than the end of memory, the 'add hl,bc' carries... and the result is still less than (MEMEND). So just throw a 'ret c' in there after the 'add hl,bc'. And it works.

As to why some people were seeing it and some weren't? I'd guess because some people were impatient enough to load all four table files, and some weren't.

Yes, it's a very stupid mistake. I also tested it with all four tables present, but apparently the memory wasn't low enough, so it quit nicely. Thanks for spotting it, update coming. The power of open source! :)

Given enough eyeballs, all bugs are shallow!

Ok... can somebody figure out how to make it mirageos compatible????

In what way isn't it compatible with Mirage?

MirageOS Doesn't even "see" the file (It doesn't come up in the list of programs...

It does for me...

OH MY GOD... I didn't scroll all the way down... It was at the bottom instead of with the rest of my "P" games. My bad.

(: Laughs at how common sense is not present in my head :)

This is a great game, very fast on my 84+ (yikes!), best physics of any pinball i have played (other than real pinball, and it works fine with one or two tables in the ram with Ion. It works in MirageOS on my calculator, but sometimes it crashes. I don't get this problem in Ion.
I usually have over 10,000 bytes of ram free before i run
Ion.
By the way, I made a table that works fine the first time you try it, but if the ball gets stuck somewhere, and you push 2ND to quit, why does the program quit right after you start if you try the table again? ?? I have to delete it and load it again to play it!! Shoule I just fix my table?

Fast for the 84+? Yes. But faster on the 83+. All ASM programs are faster on the 83+ then the 84+. I ran multiple ASM games side by side on both calcs and found the 83+ to be actually alot faster, by at least 6 pixels a sec. The 84+ just runs basic programs faster.

There are safeguards in the program to make a clean quit if it encounters an unrecoverable error. I've never seen this in action after every event was coded. You could also send me the xagt source of the table causing the error, maybe I can spot something.

OK. I can't get it to crash anymore. It works fine on MirageOS.
I think it's fast, but i don't have a 83+ to compare it to.

Speaking of open source, what is the license for this game?

It's in the public domain.

Hmmm...how would MEMUSED+(MEMSTART) ever be larger than $FFFF? (unless one of them got corrupted by a buggy program)

If my guess is right, MEMEND is not always $FFFF. It is only the RAM of the calculator which can be way lower than $FFFF...

Just a guess???

(MEMSTART) is the beginning of free RAM, which can potentially be as high as $FE66 if you have no variables. Well, actually, if it were that high, TIOS would crash because you'd be missing a lot of variables that aren't supposed to be deleted... not to mention the question of exactly what is taking up 24k of RAM if not a variable... but that's not the point. The point is that (MEMSTART) can easily be greater than $ED00.

And MEMUSED is a constant ($1300) set by me. A table needs 3840 ($f00) bytes for the slope information (which is stored in a compressed form in the file) and the rest (1k) is reserved for the data of the interactive elements. The editor doesn't let you export a table if the overall size of the gadgets surpasses the 1k limit.

Sorry for my stupidity. For some strange reason, I had been thinking that MEMUSED was the total amount of used RAM (*bangs head against wall*)...