6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Apr 27, 2024 11:29 pm

All times are UTC




Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Thu Dec 08, 2022 3:56 pm 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
Hello. I have forked this nice tool: https://github.com/LTVA1/siddump. In cpu.c I tried to add some illegal opcodes support (search by word "Lunatico"), but when I try to use the program on Lunatico sid files I don't get any SID registers writes but they should happen. This means that the 4 opcodes I tried to implement are done wrong. So I need help since I know almost nothing about 6502 internals and how illegal opcodes work.


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 08, 2022 4:19 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Welcome!

A quick look suggests that you'd need
WRITE(ABSOLUTE());
in some appropriate place(s).


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 08, 2022 5:13 pm 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
BigEd wrote:
Welcome!

A quick look suggests that you'd need
WRITE(ABSOLUTE());
in some appropriate place(s).

Hmm, I was worried that this might be the case since WRITE(foo) just does nothing (it has something commented out). I will try to add the actual WRITE() functionality first and see if it doesn't break.


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 08, 2022 5:37 pm 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 08, 2022 6:53 pm 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
Ok so I corrected program counter increments and now Lunatico sids actually write some data to SID registers, but it seems like the program is being stuck in short loop since after some time it starts to output repeating portions of nonsensical data (e.g. C-0 notes over and over again which isn't what the sid should play, obviously).

I updated code on github, and it's late now, so for today I won't do any further work on this.

P.S. Funny thing with this emulator is that
Code:
MEM(ABSOLUTE()) = x;
is what actually writes to some memory location, while
Code:
WRITE(ABSOLUTE());
just does nothing.

The whole issue is basically because LFT made his custom sid player to fit in like ~15 rasterlines which is apparently implying some self-modifying code (?) and clever illegal opcodes hacks.


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 11, 2022 8:17 pm 
Offline

Joined: Thu Oct 05, 2017 2:04 am
Posts: 62
LTVA wrote:
Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 12, 2022 11:18 am 
Offline

Joined: Sat Nov 11, 2017 1:08 pm
Posts: 33
I would probably check to see how good the emulation is of the instructions with https://github.com/Klaus2m5/6502_65C02_functional_tests and my cycle timing checker which includes undocumented instructions : https://github.com/dp111/6502Timing


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 12, 2022 7:08 pm 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
MicroCoreLabs wrote:
LTVA wrote:
Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino


Quite nice emulator, although it can't be easily made as a replacement in my case since in my fork there is an array which acts like C64 memory and a function that reads virtual SID registers values regularly. I like your code for illegal opcodes though, may adapt it to my program.


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 12, 2022 7:09 pm 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
dp11 wrote:
I would probably check to see how good the emulation is of the instructions with https://github.com/Klaus2m5/6502_65C02_functional_tests and my cycle timing checker which includes undocumented instructions : https://github.com/dp111/6502Timing

Actually no need now, I have the source code so I see what opcodes are implemented and what aren't.


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 12, 2022 8:49 pm 
Offline

Joined: Thu Oct 05, 2017 2:04 am
Posts: 62
LTVA wrote:
MicroCoreLabs wrote:
LTVA wrote:
Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino


Quite nice emulator, although it can't be easily made as a replacement in my case since in my fork there is an array which acts like C64 memory and a function that reads virtual SID registers values regularly. I like your code for illegal opcodes though, may adapt it to my program.


Sounds like you are all set, however note that the MCL64 has a separate Bus Interface Unit (BIU) which takes as inputs the memory read and write commands and inplements them on a physical bus signals. If you wanted to instead use an array for your memory or implement peripherals then this is the place to do this. This is how I debugged the code using command-line gcc - instead of physical interface I just used an array in the BIU...


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 13, 2022 2:18 pm 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
MicroCoreLabs wrote:
LTVA wrote:
MicroCoreLabs wrote:
LTVA wrote:
Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino


Quite nice emulator, although it can't be easily made as a replacement in my case since in my fork there is an array which acts like C64 memory and a function that reads virtual SID registers values regularly. I like your code for illegal opcodes though, may adapt it to my program.


Sounds like you are all set, however note that the MCL64 has a separate Bus Interface Unit (BIU) which takes as inputs the memory read and write commands and inplements them on a physical bus signals. If you wanted to instead use an array for your memory or implement peripherals then this is the place to do this. This is how I debugged the code using command-line gcc - instead of physical interface I just used an array in the BIU...

Okay I think I will try to use it since the in-place opcode implementation didn't work.


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 22, 2022 10:08 am 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
okay so... I could not adapt it, it just hangs on some instruction forever!
https://github.com/LTVA1/siddump/tree/broken


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 22, 2022 10:12 am 
Offline

Joined: Thu Dec 08, 2022 3:51 pm
Posts: 9
MicroCoreLabs wrote:
LTVA wrote:
MicroCoreLabs wrote:
LTVA wrote:
Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino


Quite nice emulator, although it can't be easily made as a replacement in my case since in my fork there is an array which acts like C64 memory and a function that reads virtual SID registers values regularly. I like your code for illegal opcodes though, may adapt it to my program.


Sounds like you are all set, however note that the MCL64 has a separate Bus Interface Unit (BIU) which takes as inputs the memory read and write commands and inplements them on a physical bus signals. If you wanted to instead use an array for your memory or implement peripherals then this is the place to do this. This is how I debugged the code using command-line gcc - instead of physical interface I just used an array in the BIU...


So I tried to remove internal RAM requests and all the stuff related to MCU and external signals. From what I debugged it seems like it successfully passes SID model check but then it just hangs executing 0x00, 0x40 or 0x60 forever (I made it stop on these as in original emulator but it just stops and does not advance any further; I made sure PC increments when I jump out of the loop)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: