Oricutron 1.0 (EDIT: Now 1.2)
- Hialmar
- Flight Lieutenant
- Posts: 349
- Joined: Tue Mar 04, 2014 11:25 am
- Location: Toulouse, France
- Contact:
Re: Oricutron 1.0 (EDIT: Now 1.2)
Sourceforge is not something I would use. Some of their downloads now install adware
Re: Oricutron 1.0 (EDIT: Now 1.2)
Well, you can still use Peter's download site and I have no trouble with gitHialmar wrote:Sourceforge is not something I would use. Some of their downloads now install adware
Re: Oricutron 1.0 (EDIT: Now 1.2)
The official Oricutron repository is now here https://github.com/pete-gordon/oricutron.
The google code page redirects there.
The google code page redirects there.
- Hialmar
- Flight Lieutenant
- Posts: 349
- Joined: Tue Mar 04, 2014 11:25 am
- Location: Toulouse, France
- Contact:
Re: Oricutron 1.0 (EDIT: Now 1.2)
Nice !
Looks like everything was moved okay including reported issues.
Looks like everything was moved okay including reported issues.
Re: Oricutron 1.0 (EDIT: Now 1.2)
Thanks to christian (aka assinie) copy/paste for X11 works again (it's fixed for SDL and SDL2).
I created a pull-request in github.
I created a pull-request in github.
Re: Oricutron 1.0 (EDIT: Now 1.2)
I just found a triple-A mega blocker exploit in Oricutron:
Just kidding, but I guess fixing the config file with jasminrom instead of jasmnrom would probably help
Code: Select all
if( read_config_string( &sto->lctmp[i], "jasminrom", jasmnromfile, 1024 ) ) continue;
; Filename of the Jasmin ROM
;jasmnrom = 'roms/jasmin'
Re: Oricutron 1.0 (EDIT: Now 1.2)
Whoops! Thanks for the heads-up. I merged the fix from Godzil.
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: Oricutron 1.0 (EDIT: Now 1.2)
@Chema: it seems that this issue is form you: https://github.com/pete-gordon/oricutron/issues/47
Could you please, when you have time, check that it still happen with the latest versions? (and put a comment if or not it still happen)
Thanks
Could you please, when you have time, check that it still happen with the latest versions? (and put a comment if or not it still happen)
Thanks
My Projects: Replic'Oric Project - StratoCumulus Project
Re: Oricutron 1.0 (EDIT: Now 1.2)
Hi guys. I found an inconsistency between Oricutron and my real Oric. When testing OASIS on my real Oric I found it hanged sometimes when trying to load resources from disk.
After some hours of debugging, I found the culprit to be this code:
Which is obviously wrong. The .byt $2c thing is commonly used with lda inmediate. My code even if it worked in Oricutron, failed in the real Oric.
As a summary, the thing is that, if entering the code from caseA, the byt $2c is taken as a BIT instruction with the 2-byte parameter resulting from the lda opcode + the immediate value, basically skipping the second lda altogether.
This is not true if the addressing mode is not immediate, as there is an extra byte.
The isthere label is at address $401, which, if I am correct, means that there is an opcode 04 being executed, which it undocumented (IRC it skips one byte, but...).
Anyway, I corrected my code and it works, but wanted to share here in case this is a bug in the emulation or someone can explain what went wrong in the real Oric.
After some hours of debugging, I found the culprit to be this code:
Code: Select all
caseA
lda idishere,y
.byt $2c
caseB
lda idisthere,y
As a summary, the thing is that, if entering the code from caseA, the byt $2c is taken as a BIT instruction with the 2-byte parameter resulting from the lda opcode + the immediate value, basically skipping the second lda altogether.
This is not true if the addressing mode is not immediate, as there is an extra byte.
The isthere label is at address $401, which, if I am correct, means that there is an opcode 04 being executed, which it undocumented (IRC it skips one byte, but...).
Anyway, I corrected my code and it works, but wanted to share here in case this is a bug in the emulation or someone can explain what went wrong in the real Oric.
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: Oricutron 1.0 (EDIT: Now 1.2)
The problem will come from the unknown opcode $04 if your explanation is correct, I have to check, but I suspect that Oricutron just ignore it and may act as a NOP, so ignoring this byte and then move to the next one. Emulating "non official" opcode is I think a bad practice (because it encourage the use of them, and some of them depends on the manufacturer and they do not exist on 65C02 and 65C816, but at least Oricutron should issue a warning or fatal in case such an instruction is executed.
I'm going to look at the CPU emulation, but I suspect it's what happen currently.
Edit: right problem found, the emulated 6502 just add cycles (from where I don't know) and just ignore the opcodes:
https://github.com/pete-gordon/oricutro ... 02.c#L1921
I will see to make a patch to issue a warning/message box, or jump to the debugger with a "Trying to execute non existing opcode 0xZZ @0xHHLL"
Chema: could you please share your test case? (even privately if needed) it will makes my test easier
Edit2: Ok. I'm going to add a debug option to jump to the debugger if activated if any non official opcode is going to be executed, this will not impact execution as the test is only going to be on non official opcode.
I'm going to look at the CPU emulation, but I suspect it's what happen currently.
Edit: right problem found, the emulated 6502 just add cycles (from where I don't know) and just ignore the opcodes:
https://github.com/pete-gordon/oricutro ... 02.c#L1921
I will see to make a patch to issue a warning/message box, or jump to the debugger with a "Trying to execute non existing opcode 0xZZ @0xHHLL"
Chema: could you please share your test case? (even privately if needed) it will makes my test easier
Edit2: Ok. I'm going to add a debug option to jump to the debugger if activated if any non official opcode is going to be executed, this will not impact execution as the test is only going to be on non official opcode.
Last edited by Godzil on Sun Mar 13, 2016 11:41 pm, edited 1 time in total.
My Projects: Replic'Oric Project - StratoCumulus Project
Re: Oricutron 1.0 (EDIT: Now 1.2)
Hmmm... according to the documents I could find online, opcode 04 is essentially a "nop", but it should consume an immediate operand.
Looking at the code, I made it count the cycles correctly, but not consume the operand.
No need for a message box. If you make all the "DOP" instructions add 1 to PC, and all the "TOP" instructions add 2, it should behave the same as the real oric.
Looking at the code, I made it count the cycles correctly, but not consume the operand.
No need for a message box. If you make all the "DOP" instructions add 1 to PC, and all the "TOP" instructions add 2, it should behave the same as the real oric.
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: Oricutron 1.0 (EDIT: Now 1.2)
I'm sorry, but I think it's more important to clearly show that an illegal opcode is going to be executed than trying to "emulate" them correctly.
The non official opcode could have much more effect than "documented" as there are different manufacturer of the 6502 and the behaviour could change depending on them.
As Oricutron is a debug tool and as using these opcode is a really bad practice there should be an option totrigger the debugger when such an opcode is going to be executed.
All current Oric development should be compatible with the 65C02 or the 65C816, and hopefully there is no known Oric software that use the non official opcode, so adding a facility to detect such bad opcode would make everyone life easier, and Chema would have find that much more earlier (and easier) than what happened.
The non official opcode could have much more effect than "documented" as there are different manufacturer of the 6502 and the behaviour could change depending on them.
As Oricutron is a debug tool and as using these opcode is a really bad practice there should be an option totrigger the debugger when such an opcode is going to be executed.
All current Oric development should be compatible with the 65C02 or the 65C816, and hopefully there is no known Oric software that use the non official opcode, so adding a facility to detect such bad opcode would make everyone life easier, and Chema would have find that much more earlier (and easier) than what happened.
My Projects: Replic'Oric Project - StratoCumulus Project
Re: Oricutron 1.0 (EDIT: Now 1.2)
I don't entirely agree.
I think the current compile-time option should be made a configuration option. Oricutron is attempting to emulate a real piece of hardware, including quirks.
A better solution than not emulating illegal opcodes would be adding options to select 6502, 65c02 or 65816 emulation.
I think the current compile-time option should be made a configuration option. Oricutron is attempting to emulate a real piece of hardware, including quirks.
A better solution than not emulating illegal opcodes would be adding options to select 6502, 65c02 or 65816 emulation.
Re: Oricutron 1.0 (EDIT: Now 1.2)
In my opinion Oricutron should behave as the real Oric. Dos-8D and some other nice software are using illegal instructions and all works perfectly in current version of Oricutron.
Else, maybe the best will be to have run-time option which enables/disables switch to debug mode on illegal instruction.
I like adding 6502, 65c02 and 65816 to emulation - actually I need it right now ...
Else, maybe the best will be to have run-time option which enables/disables switch to debug mode on illegal instruction.
I like adding 6502, 65c02 and 65816 to emulation - actually I need it right now ...
Re: Oricutron 1.0 (EDIT: Now 1.2)
Hi guys!
I know very little about the undocumented opcodes in the 6502 family, but in my humble opinion, Oricutron should emulate the hardware with all its quirks, as Xeron said. This means that if an undocumented instruction does the same for all the 6502 chips fitted in an Oric (Rockwell, Synertec,...) then go ahead and emulate it. If it only works on some Orics due to differences in the processor brand, then halt or something like that. Mostly because the code won't work on every Oric anyway.
But that does not mean Oricutron should support other chips that were not fitted in Orics at that time. Why should it support 65816? Would anybody produce Oric software that needs another processor to run? If it runs out of the box, it is ok, but interfering with the correct emulation of a real Oric just to support it... I am not sure.
In any case, add it as an emulation option.
What should not happen, imho, is that code that does not work on a real Oric, works on the emulator, or the same code does different things. That is confusing
Just my 2cents
I know very little about the undocumented opcodes in the 6502 family, but in my humble opinion, Oricutron should emulate the hardware with all its quirks, as Xeron said. This means that if an undocumented instruction does the same for all the 6502 chips fitted in an Oric (Rockwell, Synertec,...) then go ahead and emulate it. If it only works on some Orics due to differences in the processor brand, then halt or something like that. Mostly because the code won't work on every Oric anyway.
But that does not mean Oricutron should support other chips that were not fitted in Orics at that time. Why should it support 65816? Would anybody produce Oric software that needs another processor to run? If it runs out of the box, it is ok, but interfering with the correct emulation of a real Oric just to support it... I am not sure.
In any case, add it as an emulation option.
What should not happen, imho, is that code that does not work on a real Oric, works on the emulator, or the same code does different things. That is confusing
Just my 2cents