if <[SNES] = [Possible On Scratch]> then
forever
switch costume to [Victory is mine! v]
say [YES!!!]
end
end

elgooGmirror wrote:

I know what the CPU is called. I actually used wikipedia a bit. Do you know where I could research 65c816 assembly?

• CPU (Ricoh 5A22, which is equivalent to the WDC 65C816)
  

• PPU (PPU1 and PPU2)
  

• Audio (SPC700 and S-DSP)
  

• The cartridge (memory, parsing the ROM format, and sometimes co-processors such as SuperFX)
  

• Most bitwise operations (particularly bitshifts) can be replaced with simple arithmetic operators, such as multiplication, division, addition, subtraction, floor, and modulo.
  

• Bitwise AND, OR, and XOR between two 8-bit values can be done with lookup tables that each have 65536 entries (256 x 256).
  

• Pen strokes are expensive. Fast renderers try to reduce the number of pen strokes in an image by combining pixels of the same color into
  horizontal lines, and by only drawing what pixels of the image have changed to a different color since the previous frame.
  

• When emulating an instruction set with as many opcodes as the 65C816 has, a large if/elseif/else chain is going to be pretty inefficient if it has to run hundreds of checks to find the opcode you want. There are a few methods to make decoding faster. One way is to find similarities between the functionality of different opcodes and design around those. Another way, which is the method I use, is to do binary search to find the right instruction for a certain opcode, which requires that your if/else statements are arranged into a specific structure: Essential Emulator Scripts.
  

SpinningCube wrote:

First, know that emulating the SNES is notoriously hard. There are a lot of parts operating simultaneously, each of which is pretty complicated on its own, including but not limited to:

• CPU (Ricoh 5A22, which is equivalent to the WDC 65C816)
  

• PPU (PPU1 and PPU2)
  

• Audio (SPC700 and S-DSP)
  

• The cartridge (memory, parsing the ROM format, and sometimes co-processors such as SuperFX)
  

I'd recommend first understanding the overall architecture of the system you plan to emulate.
Here's an article for that: Super Nintendo Architecture | A Practical Analysis
This is just to get to know all the various parts so you can anticipate what challenges you might have to overcome.

For specific reference, there's this SNES Development Wiki, which should have a lot of reference material about all aspects of SNES hardware and functionality, including that for the CPU. There's also this big document: fullsnes.
,
There's also this nice video about SNES graphics: Graphics & Palettes - Super Nintendo Entertainment System Features Pt. 01

There are many other resources out there besides these, and I'd strongly recommend searching for other reference material to double-check information or to find information not covered by these other sources, and just to generally make the process less painful. It would also be a good idea to review general emudev topics, like degrees of emulation accuracy and their tradeoffs.

Emulators typically take a long time to develop, and this is especially true for Scratch. Emulators written in Scratch are often designed around speed, and require heavy optimization, though that's for emulators written with the intent of running at full speed. Since the SNES is probably too slow for Scratch, perhaps you don't need to stress about speed quite as much.

I have some tips, some of which I used for my (WIP for now) NES emulator:

• Most bitwise operations (particularly bitshifts) can be replaced with simple arithmetic operators, such as multiplication, division, addition, subtraction, floor, and modulo.
  

• Bitwise AND, OR, and XOR between two 8-bit values can be done with lookup tables that each have 65536 entries (256 x 256).
  

• Pen strokes are expensive. Fast renderers try to reduce the number of pen strokes in an image by combining pixels of the same color into
  horizontal lines, and by only drawing what pixels of the image have changed to a different color since the previous frame.
  

• When emulating an instruction set with as many opcodes as the 65C816 has, a large if/elseif/else chain is going to be pretty inefficient if it has to run hundreds of checks to find the opcode you want. There are a few methods to make decoding faster. One way is to find similarities between the functionality of different opcodes and design around those. Another way, which is the method I use, is to do binary search to find the right instruction for a certain opcode, which requires that your if/else statements are arranged into a specific structure: Essential Emulator Scripts.
  

forever
set [noice v] to [1000]
end

-LevHr- wrote:

This would be impossible, right?

-LevHr- wrote:

This would be impossible, right?

Mystery96 wrote:

-LevHr- wrote:

This would be impossible, right?

scratch is turing complete so you could theoretically emulate the switch, the xbox series x, ps5, etc., albeit it running at an EXTREMELY slow rate.

SpinningCube wrote:

First, know that emulating the SNES is notoriously hard. There are a lot of parts operating simultaneously, each of which is pretty complicated on its own, including but not limited to:

• CPU (Ricoh 5A22, which is equivalent to the WDC 65C816)
  

• PPU (PPU1 and PPU2)
  

• Audio (SPC700 and S-DSP)
  

• The cartridge (memory, parsing the ROM format, and sometimes co-processors such as SuperFX)
  

I'd recommend first understanding the overall architecture of the system you plan to emulate.
Here's an article for that: Super Nintendo Architecture | A Practical Analysis
This is just to get to know all the various parts so you can anticipate what challenges you might have to overcome.

For specific reference, there's this SNES Development Wiki, which should have a lot of reference material about all aspects of SNES hardware and functionality, including that for the CPU. There's also this big document: fullsnes.
,
There's also this nice video about SNES graphics: Graphics & Palettes - Super Nintendo Entertainment System Features Pt. 01

There are many other resources out there besides these, and I'd strongly recommend searching for other reference material to double-check information or to find information not covered by these other sources, and just to generally make the process less painful. It would also be a good idea to review general emudev topics, like degrees of emulation accuracy and their tradeoffs.

Emulators typically take a long time to develop, and this is especially true for Scratch. Emulators written in Scratch are often designed around speed, and require heavy optimization, though that's for emulators written with the intent of running at full speed. Since the SNES is probably too slow for Scratch, perhaps you don't need to stress about speed quite as much.

I have some tips, some of which I used for my (WIP for now) NES emulator:

• Most bitwise operations (particularly bitshifts) can be replaced with simple arithmetic operators, such as multiplication, division, addition, subtraction, floor, and modulo.
  

• Bitwise AND, OR, and XOR between two 8-bit values can be done with lookup tables that each have 65536 entries (256 x 256).
  

• Pen strokes are expensive. Fast renderers try to reduce the number of pen strokes in an image by combining pixels of the same color into
  horizontal lines, and by only drawing what pixels of the image have changed to a different color since the previous frame.
  

• When emulating an instruction set with as many opcodes as the 65C816 has, a large if/elseif/else chain is going to be pretty inefficient if it has to run hundreds of checks to find the opcode you want. There are a few methods to make decoding faster. One way is to find similarities between the functionality of different opcodes and design around those. Another way, which is the method I use, is to do binary search to find the right instruction for a certain opcode, which requires that your if/else statements are arranged into a specific structure: Essential Emulator Scripts.
  

TechNerd64 wrote:

Wow, such a daunting task!!! Good Luck!!!

when green flag clicked

forever
set [GPUProcess] to [running]
end

TechNerd64 wrote:

I found a online 65c816 assembly tutorial that may help.
65c816 assembly tutorial

elgooGmirror wrote:

TechNerd64 wrote:

I found a online 65c816 assembly tutorial that may help.
65c816 assembly tutorial

Thanks!