Posted By
Ulysses777
on 2006-01-20
14:25:20
|  What's going on with this program?
Ok, I've started on the type-ins again, and finished this one:
http://homepage.ntlworld.com/ulysses777/land_it.prg
Now after the game is started and after the graphics are drawn, different stuff happens depending on whether it's run on a real machine or on certain emulators.
On VICE, Minus4 and Winemu, it runs OK. On YAPE and Artifex, it starts producing messed up graphics and won't stop with Run/Stop. On a real machine, it comes up with an ILLEGAL QUANTITY error in line 13.
However, no errors occur if a GRAPHIC area is allocated in direct mode prior to running the game.
Any ideas? 
|
|
Posted By
retroscener
on 2006-01-20
19:42:38
 | Re: What's going on with this program?
that's pretty cool, i didn't expect the maze multiscreen action. nice use of the GRAPHIC command. where did you find that listing?
i've started work on another one the other day also, i'm around halfway through it, just been soooo busy.
|
|
Posted By
Csabo
on 2006-01-22
19:55:26
| Re: What's going on with this program?
Sounds weird. I checked it out, it IS weird. I assume you are 100% sure that the program on the real Plus/4 is byte-to-byte identical to the downloadable prg file, but I still have to ask... Are you 100% sure?
Let's start with the real machine. Line 13 is perfectly innocent, as long as we're in multicolor graphics mode. I'd guess there was a typo (or some kind of transfer error), so instead of grA3,1 is says grA1,1, so the DRAW 2, whatever throws an ILLEGAL QUANTITY. Or could there be something up with the loop counter?
About the emulation part: no idea. I'm being soo helpful, aren't I?
|
|
Posted By
Ulysses777
on 2006-01-23
10:48:26
| Re: What's going on with this program?
>I assume you are 100% sure that the program on the real Plus/4 is byte-to-byte identical to the downloadable prg file, but I still have to ask... Are you 100% sure?
Looks like it didn't transfer properly after all
I used Mike's uploader proggy the first time, so I tried it again today using cbm4win and it works fine on a real machine now
Still doesn't work properly in YAPE though...
|
|
Posted By
Csabo
on 2006-01-23
14:56:18
| Re: What's going on with this program?
So we've narrowed it down to YAPE. That's Gaia's territory. However, since it's a basic program, somehow I think there could be something else other than an actual YAPE bug... Basic programs should run fine, they are actually easier to emulate than demos or other games.
Perhaps to assist Gaia we could try to comment out lines and then run it from YAPE. Once it runs fine, we can narrow it down to the line (or statement) that causes the "crash"/messup.
|
|
Posted By
Ulysses777
on 2006-01-23
16:35:16
| Re: What's going on with this program?
Ok, I've found that the bug happens when the first GSHAPE statement is executed in line 38. Also, if you press Run/stop after the SSHAPE statements are run, then enter (eg GSHAPE B$) in direct mode, the bug happens again.
However, if A$ (in line 3) is not given a value (in other words, wait until the demo mode starts) then the game runs normally. It appears that if a string variable is given a value before the GRAPHIC 3,1 is executed in line 8, then the bug occurs when GSHAPE is executed. :/
|
|
Posted By
Crown
on 2006-01-24
05:16:11
| Re: What's going on with this program?
Have you tried to put it on a D64, and load it from there in Yape?... I would not be suprised if it would work correctly this way.
|
|
Posted By
indi
on 2006-01-24
06:07:37
| Re: What's going on with this program?
Yep, the uploader you have has a small bug in it. If you look at the first 2 bytes of the .PRG and if its not going to address $1001, then the uploader sets the start of basic wrong.
I'll upload a newone tonight. Some programs seem to save from $1000 or less for some reason, but basic and in fact all .PRG programs should start at $1001.
|
|
Posted By
Gaia
on 2006-01-24
06:38:04
| Re: What's going on with this program?
basic and in fact all .PRG programs should start at $1001.
Well... no! If you save something from MONITOR, like S "PRG",8,2000,4000 then it will load back from the BASIC start address pointed to by zero page address variables $2B/$2C (=$1001 by default) if you use the DLOAD command or LOAD"PRG",8. What the KERNAL really does, by default it loads on from the address found at $2B/$2C and throw away the first 2 bytes of the PRG. Only if you load it back from MONITOR or with LOAD"PRG",8,1 will it load back to the correct address specified as the first 2 bytes of the PRG. Note that many BASIC programs were saved after graphics were on, so their first 2 bytes of the PRG point to address $4001. You should cope with this in your transfer routine.
As for this strange bug... I did try loading it from under the fake 1551 (IEC) emulation mode from the PC directory with no luck. I'll see if D64 works out well but I doubt it... it is very strange indeed. SHAPE's are stored as strings at the end of the BASIC RAM with a pretty standard operation (memory allocation and such).
|
|
Posted By
indi
on 2006-01-24
12:46:27
| Re: What's going on with this program?
yep, I realise this... but if I "quickload" load a program to its .PRG location and then set its basic address, then this will work for 99.9% of PRG files. For those that dont have any basic attach, it doesnt matter that basic is forced to $1001, and for those that do, then it'll probably need to be there anyway.
This doesn't account for graphic program though, which if memory serves (although it's has been a while...) start after the screen.?.? Higher up in memory than $1001.
However, since Quickloading and the uploader dont go through the rom to "correctly" load programs, this is good enough.
|
|
Posted By
Litwr
on 2006-01-25
01:05:19
| Re: What's going on with this program?
I can add that standard Basic LOAD and DLOAD subroutines establish (recalculate) links (pointers to next line) between lines of Basic programs. Quickloaders of all (?) emulators don't do such recalculations.
|
|
Posted By
Csabo
on 2006-01-25
11:38:13
| Re: What's going on with this program?
Any luck with the bug, or loading the program from a D64 file?
|
|
Posted By
Ulysses777
on 2006-01-25
15:44:18
| Re: What's going on with this program?
No joy with a D64 
It's only Yape and Artifex that have problems with it, it works normally on VICE and Minus4.
|
|
Posted By
Gaia
on 2006-01-25
18:09:11
| Re: What's going on with this program?
This is weird! I have just checked... it ceased working in version 0.24 (!!!) :-D I have no idea what it is, but looks challenging for sure...
|
|
Posted By
Gaia
on 2006-01-26
17:09:49
| Re: What's going on with this program?
Well, I have found it! It is VERY weird...! The "bug" is rather one of the real machine's ROM program and is depending on the power up pattern! Up until around version 0.24 of Yape I used no pattern but simple zeroes then changed it to what it is now (and reflects one of my C16's as I recall). I have regenerated the error in VICE since it has a dialog window for setting the power up pattern of the RAM:
In the background you can see the messy screen. I secretly suspected that this could be the reason for the bug but it seemed so unlikely. Now, THIS could be a challenge to figure out!
There's one another game (at least) that has been showing similar symptoms: Menekülés. If the memory is completely zero between area $400-$700 (except for the CHRGET and CHRGOT locations of course) it will not pass the title screen after pressing F1.
|
|
Posted By
Ulysses777
on 2006-01-26
18:16:42
| Re: What's going on with this program?
That seems to be it
After reading your posts, I checked some of my other real machines, and found another Plus/4 where the power up pattern was near exact to the settings in that pic (except that the first byte is 255), and it dosen't work!
I also tried it on my C16 + 16K expansion (same power up pattern as above) and my C116 + 16K (length of constant values = 2) and it doesn't work on those either!
When I get the time, I'll check the power-up patterns on the rest of my machines
|
|
