Page 1 of 1
Opcode 52 executed at 024D
Posted: Tue Apr 09, 2019 4:53 am
by NekoNoNiaow
Hello,
as the title indicates, this is the error I get in Oricutron when executing a newly compiled C program.
Here is what I am doing:
- Compile a C program using the OSDK (1.13).
This builds fine and produces a .TAP file of 23 774 bytes, which is quite on the big side.
- Launch Oricutron (using osdk_execute.bat).
This immediately selects "OSDK.TAP" as the tape to load and issues automatically a CLOAD"".
Then, instead of seeing the program execute normally, as it usually does with my own (small) programs, the Oricutron monitor gets displayed with the message
As you can see in the attached image, the PC does not point to anything remotely executable.
The weird part is that, for a time, I have been able to work around this issue by following this procedure in Oricutron:
- When the message appears: press F1 to make the menu appear.
- Select Reset
- Insert Tape
- Select the OSDK.TAP file
- manually type CLOAD""
This used to make the program run normally without encountering this weird opcode error.
Alas, this has stopped working with my latest tests.
Would anyone have any idea as to what exactly is happening here?
Re: Opcode 52 executed at 024D
Posted: Tue Apr 09, 2019 12:30 pm
by Symoon
I would bet for a zero page variable not initialized somewhere?
Re: Opcode 52 executed at 024D
Posted: Tue Apr 09, 2019 12:38 pm
by iss
IMO, the size is not an issue. Attached is TAP file with 23774 bytes length and the source, which is:
Code: Select all
static char buf[22721] = "Hello world! sizeof(buf)=%d%d\n\x00";
void main(void) { printf(buf, sizeof(buf)/100,sizeof(buf)%100); }
You can adjust the buffer size to achieve desired TAP file length...
And it works:
Re: Opcode 52 executed at 024D
Posted: Tue Apr 09, 2019 1:31 pm
by Chema
I doubt it is a problem of size... I am quite sure I've seen this before, but cannot remember where. Are you doing something strange, such as playing with irqs or something along that line?
It would help if you posted the C code...
Re: Opcode 52 executed at 024D
Posted: Wed Apr 10, 2019 2:58 am
by NekoNoNiaow
iss wrote: ↑Tue Apr 09, 2019 12:38 pm
IMO, the size is not an issue. Attached is TAP file with 23774 bytes length and the source, which is:
Indeed, thanks for testing!
And I confirm that adding few printf() calls to the program, which increases its size, can sometime help make it work.
Symoon wrote: ↑Tue Apr 09, 2019 12:30 pm
I would bet for a zero page variable not initialized somewhere?
This is actually very portable, "normal", C, which does not do anything Oric specific and is extremely unlikely to contain any bugs.
And sometimes, just adding a printf() here and there makes it work...
Chema wrote: ↑Tue Apr 09, 2019 1:31 pm
I doubt it is a problem of size... I am quite sure I've seen this before, but cannot remember where. Are you doing something strange, such as playing with irqs or something along that line?
It would help if you posted the C code...
As I just replied to @Symoon above, the program is not at all Oric specific and only does a few computations and printf() calls.
Also, I already had the issue once in a blue moon with my own very small test programs, usually, changing a few lines and rebuilding solved it and I would never see the problem again before a long time.
I kinda suspect this may be a bug in Oricutron since resetting the machine and reloading the tape sometimes makes it work just fine.
Re: Opcode 52 executed at 024D
Posted: Wed Apr 10, 2019 3:54 am
by Symoon
NekoNoNiaow wrote: ↑Wed Apr 10, 2019 2:58 am
Symoon wrote: ↑Tue Apr 09, 2019 12:30 pm
I would bet for a zero page variable not initialized somewhere?
This is actually very portable, "normal", C, which does not do anything Oric specific and is extremely unlikely to contain any bugs.
And sometimes, just adding a printf() here and there makes it work...
I have no idea how the code generated by the C compiler or libraries or whatever is working, but that's a guess based on the fact that in case of random behaviour, problems came at 90% (personal and asbolutely no scientific value
) from inititalization problem.
Remember the RAM content is not always the same at start on real machines, and on emulators depends on the chosen RAM pattern at start.
Did you try your program on Euphoric?
BTW what are its start/end addresses?
It would really help if you shared the source or TAP file, unless of course if it's a super-secret-surprise project