Page 6 of 15

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Fri Aug 28, 2015 1:44 pm
by Hialmar
Sourceforge is not something I would use. Some of their downloads now install adware :(

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Fri Aug 28, 2015 1:56 pm
by polluks
Hialmar wrote:Sourceforge is not something I would use. Some of their downloads now install adware :(
Well, you can still use Peter's download site and I have no trouble with git :)

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Sat Sep 05, 2015 8:02 am
by Xeron
The official Oricutron repository is now here https://github.com/pete-gordon/oricutron.

The google code page redirects there.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Sun Sep 06, 2015 8:56 pm
by Hialmar
Nice !
Looks like everything was moved okay including reported issues.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Thu Nov 05, 2015 1:44 pm
by iss
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.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Mon Jan 11, 2016 8:15 pm
by Dbug
I just found a triple-A mega blocker exploit in Oricutron:

Code: Select all

if( read_config_string( &sto->lctmp[i], "jasminrom",    jasmnromfile, 1024 ) ) continue;

; Filename of the Jasmin ROM
;jasmnrom = 'roms/jasmin'
Just kidding, but I guess fixing the config file with jasminrom instead of jasmnrom would probably help :)

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Mon Jan 11, 2016 11:15 pm
by Xeron
Whoops! Thanks for the heads-up. I merged the fix from Godzil.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Sun Jan 17, 2016 6:09 pm
by Godzil
@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 :)

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Sun Mar 13, 2016 9:30 pm
by Chema
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:

Code: Select all

caseA
   lda idishere,y
   .byt $2c
caseB
   lda idisthere,y
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.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Sun Mar 13, 2016 11:24 pm
by Godzil
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.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Sun Mar 13, 2016 11:39 pm
by Xeron
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.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Sun Mar 13, 2016 11:49 pm
by Godzil
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.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Mon Mar 14, 2016 1:08 am
by Xeron
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.

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Mon Mar 14, 2016 10:16 am
by iss
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 ;)...

Re: Oricutron 1.0 (EDIT: Now 1.2)

Posted: Mon Mar 14, 2016 11:09 am
by Chema
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 :)