Oricutron 1.0 (EDIT: Now 1.2)

Comments, problems, suggestions about Oric emulators (Euphoric, Mess, Amoric, etc...) it's the right place to ask. And don't hesitate to give your tips and tricks that help using these emulations in the best possible way on your favorite operating system.
User avatar
Hialmar
Flight Lieutenant
Posts: 318
Joined: Tue Mar 04, 2014 11:25 am
Location: Toulouse, France
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Hialmar » Fri Aug 28, 2015 1:44 pm

Sourceforge is not something I would use. Some of their downloads now install adware :(
Hialmar
CEO and Silicium member.

User avatar
polluks
Officer Cadet
Posts: 52
Joined: Tue Jun 05, 2012 10:09 pm
Location: Germany
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by polluks » Fri Aug 28, 2015 1:56 pm

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 :)
cc65 development
Oric Atmos + Cumulus
Acorn Electron

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Xeron » Sat Sep 05, 2015 8:02 am

The official Oricutron repository is now here https://github.com/pete-gordon/oricutron.

The google code page redirects there.

User avatar
Hialmar
Flight Lieutenant
Posts: 318
Joined: Tue Mar 04, 2014 11:25 am
Location: Toulouse, France
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Hialmar » Sun Sep 06, 2015 8:56 pm

Nice !
Looks like everything was moved okay including reported issues.
Hialmar
CEO and Silicium member.

User avatar
iss
Flight Lieutenant
Posts: 470
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by iss » Thu Nov 05, 2015 1:44 pm

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.

User avatar
Dbug
Site Admin
Posts: 2322
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Dbug » Mon Jan 11, 2016 8:15 pm

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 :)

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Xeron » Mon Jan 11, 2016 11:15 pm

Whoops! Thanks for the heads-up. I merged the fix from Godzil.

Godzil
Squad Leader
Posts: 755
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Godzil » Sun Jan 17, 2016 6:09 pm

@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 :)

User avatar
Chema
Game master
Posts: 1972
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Chema » Sun Mar 13, 2016 9:30 pm

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.

Godzil
Squad Leader
Posts: 755
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Godzil » Sun Mar 13, 2016 11:24 pm

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.
Last edited by Godzil on Sun Mar 13, 2016 11:41 pm, edited 1 time in total.

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Xeron » Sun Mar 13, 2016 11:39 pm

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.

Godzil
Squad Leader
Posts: 755
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Godzil » Sun Mar 13, 2016 11:49 pm

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.

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Xeron » Mon Mar 14, 2016 1:08 am

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.

User avatar
iss
Flight Lieutenant
Posts: 470
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by iss » Mon Mar 14, 2016 10:16 am

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 ;)...

User avatar
Chema
Game master
Posts: 1972
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Oricutron 1.0 (EDIT: Now 1.2)

Post by Chema » Mon Mar 14, 2016 11:09 am

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 :)

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests