So my girlfriend came home for the second hand store where she works with a copy of Yoshi's Island. It came boxed but without a manual.
Now there are a couple of things really strange about this version:
1. The box and cardridge both are PAL shaped, yet they are covered with Super Famicom logo's.
2. The cardridge itself is PAL shaped, but had a Hong Kong serial on it.
3. The cardridge is PAL shaped, but wont work in 50 Hertz (PAL) mode, only in 60 Hertz (NTSC) mode.
4. The box is clearly PAL (JPN games have a vertical box) yet is says:
For use with the famicom control deck only.
Not compatible with super nintendo entertainment system control deck.
Here are some pictures:
i would like to know the story behind this version and what it could be worth.
Thanks,
Peter
The system was released in twelve or thirteen regions, you probably just have a cart that's not for the US, Japan or Europe. I would guess it was intended for the Hong Kong region. Unlikely to be a pirate cart, cloning the SuperFX probably wouldn't be worth the effort.
byuu wrote:
Unlikely to be a pirate cart, cloning the SuperFX probably wouldn't be worth the effort.
If I remember correctly, YI didn't really use the Super FX except for rotating and scaling sprites. Most of the "Morphmation" stuff was Rad Racer-style graphic effects rendered with HDMA. That's why the GBA version of YI got away with not using a coprocessor: the GBA PPU has hardware affine transformation of sprites. A pirate version of YI would just have a different scaling chip. And pirates are known to make cuts when porting games to other hardware: look at the NES pirate version of Super Mario World.
Hong Kong was British during the Super NES era, which explains the general PAL-styling of the box and the English instructions.
Look at the bottom of the cart and tell us if there is just the main connector or if there are two smaller connectors on the left and right of the bigger one. Or better yet, open the cartridge and look for a chip labeled GSU-1 or GSU-2. Or just take a picture of the PCB.
Very interesting, I've documented lots of SNES serials and never knew an HKG existed. Can you open the cart and tell me the ROM serial? I'd suspect it says SNS-YI-0, the American ROM.
The japanese SFC is exactly like the PAL one, so are the cartridges (altough they have a different lockout chip). So it makes perfect sence that it's "for super famicom only" and that the cartridge is PAL shaped.
^^I have one and I can confirm this. The only differences are: 60 hz, the logo on the front and the lockout
tepples wrote:
That's why the GBA version of YI got away with not using a coprocessor: the GBA PPU has hardware affine transformation of sprites.
so the SNES couldn't scale and rotate sprites? Does that mean the koopa kids were backgrounds?
strat wrote:
Does that mean the koopa kids were backgrounds?
Yes. In
Super Mario World, Bowser and the three Koopalings that used "rotatey" effects (Morton, Ludwig, and Roy) were backgrounds in mode 7, just as lots of NES bosses were backgrounds due to the 0.25x overdraw limit. Remember how plain the sprite-based "backgrounds" in those boss rooms looked?
Lynx had sprite scaling. Neo Geo had sprite scaling (shrink only). Super NES did not.
tepples wrote:
Super NES did not.
What? But clearly many SNES games scaled sprites in mode 7. Just look at cutscenes in many popular games. Just look at racing games.
You can scale sprites in software (Zelda 3 opening), or store multiple copies at different scales in the ROM. SNES devs were masters of working around hardware limitations.
Byuu is right. F-Zero and Super Mario Kart used the same solution that NES games like Rad Racer used for sprite scaling: multiple copies of the sprites. It's just that VRAM DMA made this a lot easier to do on the Super NES than on the NES: the system could allocate one 16-tile area to each character and just blit new tile data there (is this Battletoads?).
Start Super Mario Kart battle mode: Toad vs. Koopa Troopa.[1] Inch up closer and look for the transitions where the kart's size suddenly changes. Then go far away and have the other player turn around in circles (hold right, rapidly press R). You'll see that the game has more directions for large scale than for small scale.
[1] In-joke: Wario stole Koopa's kart before MK64. Koopa died trying to get his kart back and showed up as Dry Bones in MKDS.
I'm pretty sure Chrono Trigger does software sprite scaling for the racing minigame, and that Tales of Phantasia and Star Ocean also does software scanling at various places. But none of these game can scale a lot of sprites at once, probably because it consumes a lot of CPU power.
Wow, I honestly thought that it was hardware mode scaling, especially considering the slow processor that the SNES uses. I guess any system could be programmed with a software sprite scaling routine, but it runs very smoothly on the SNES. Maybe I'm just too much of a sucker for the SNES, which seems like it's capable of such amazing special effects. What about sprite rotation? That is often used in combination with scaling effects.
The SNES CPU gets a bad wrap on being slow. It's not as fast a clock rate as the PCE or Genesis but you can still get things done, you just can't be as wasteful.
SNES isn't bad for software scaling of some sprites since you have alot of VRAM and DMA. You could have a source image and scale it making copies in VRAM to avoid having to scale to a new size between frames. On that subject it would have been interesting what could have been different if the SNES were the same except running at a higher clock rate like 5.36mhz or 7.1mhz. Maybe then you wouldn't have had people bothering so much with in-cart chips.
Ah, yes. Replace the S-CPU with the 10.5MHz SA-1, but keep the HDMA. With I-RAM you can access in one cycle at that rate, and automatic bitmap->bitplane DMA transformation, software scaling would be trivial.
Sadly, none of the SA-1 games really took advantage of the power of that chip.
I've never really seen much info about the SA-1 but I wouldn't be surprised that none of the games really pushed it. From what I've heard it would have been kick ass if more games could have used it, like if it had been included in a CD-ROM system cartridge.
As I understand it, SA-1 was supposed to be in the Super NES CD-ROM system cartridge. But when Nintendo dismissed each of its partners, they switched to an instruction set that had more of a future. Philips made CD-i (all toasters toast toast!) with a customized 68000-based CPU, while Sony used MIPS for the PlayStation.
So the obvious solution for emulating a theoretical-SNESCD would be to add SA-1 + 68k + MIPS R3000. Make it two of each, include the base unit, and it would almost be half as complicated as the Sega Saturn to program for :D
What, you think 2 x SH2 + SCU + SMPC + SCSP + 68K + VDP1 + VDP2 is complicated? ;P
Yeah, I honestly don't know what they were thinking either. Not to mention that the VDP2 manual alone is over 400 pages, written in poor english by what probably were hardware engineers.
Nintendo really showed how to make an easy-to-program-for system with the GBA.
naI wrote:
Wow, I honestly thought that it was hardware mode scaling, especially considering the slow processor that the SNES uses. I guess any system could be programmed with a software sprite scaling routine, but it runs very smoothly on the SNES. Maybe I'm just too much of a sucker for the SNES, which seems like it's capable of such amazing special effects. What about sprite rotation? That is often used in combination with scaling effects.
Rotation is a
lot harder that scaling. Shrinking an 8- or 16-pixel-wide planar sprite requires about four lookup tables, applied to an entire byte of the sprite at a time. Something like that can be done in real time on the NES, as I would
later demonstrate in a tech demo. Rotation, on the other hand, potentially involves seeking to a different row of the source sprite for
each pixel. I assume this is why Neo Geo can shrink sprites but not rotate them.
byuu wrote:
So the obvious solution for emulating a theoretical-SNESCD
For the record, not theoretical. Apparently it was to be sold not only as an attachment but also as a complete Play Station that would have included both the Super NES Control Deck and CD drive in one unit. One of the
Play Station units was found, and not by any relative of
Dudley Dursley.
tepples wrote:
I assume this is why Neo Geo can shrink sprites but not rotate them.
Pfft, Neo Geo is overrated.
The comment on the Neo Geo is correct though. Moreover, it can't scale up because that'd require being able to write to a lot of pixels in the linebuffer at once. That's doable, but would probably eat up way too much die space.
I know this sounds crazy, but I like the fact it can't enlargen sprites because it forces you to draw larger, more detailed sprites so they aren't blocky at full size like a lot of super scaler games. The Neo Geo has enough chr rom for this. Does anyone know how many 16x16 tiles that sprites on the Neo Geo can index, like how many bits there are for selecting tiles for every sprite?
> For the record, not theoretical.
Wow, I can barely remember what happened last week. You remembered and bumped a six year old thread over that Play Station prototype being found?
Would love to get my hands on that proto, but it's never gonna happen, so for all intents and purposes, to me it's still theoretical :P
I guess I'm not the only one who is skeptical about it.
If want to know how to do sprite rotation on the SNES, you could use this code.
Code:
rotate_sprites_for_modular_animation:
-;
lda $0000,y
beq +
tax
phy
jsr rotate_sprite
ply
iny #2
bra -
+;
stz {modular_animation_data}
rts
rotate_sprite:
phb
php
sep #$20
lda $0004,x
sta {rotation_step}
stz {rotation_angle}
lda $000a,x
asl #3
sta {size}
asl #2
sta {d}
lda $0000,x
stz {x_pixel}
sta {x_pixel_hi}
lda $0001,x
stz {y_pixel}
sta {y_pixel_hi}
lda $0002,x
pha
rep #$20
lda $0008,x
sta {e}
lda $0006,x
tax
plb
phd
lda #$0000
tcd
jsr convert_bitmap
pld
plp
plb
rts
new_rotation_step:
pla
sta.b {y_pixel}
pla
sta.b {x_pixel}
lda.b {rotation_step}
clc
adc.b {rotation_angle}
sta.b {rotation_angle}
cmp #$0080
bcc convert_bitmap
rts
convert_bitmap:
sep #$20
lda #$00
sta $004200
rep #$20
phx
lda.b {rotation_angle}
asl
and #$01fe
tax
lda $000000+sine,x
sta.b {sine}
lda $000000+cosine,x
sta.b {cosine}
plx
lda.b {x_pixel}
pha
lda.b {y_pixel}
pha
lda.b {sine}
clc
adc.b {cosine}
sta.b {a}
sep #$20
sta $00211b
xba
sta $00211b
lda.b {size}
lsr
sta $00211c
rep #$20
lda.b {size}
xba
clc
adc.b {a}
lsr
sec
sbc $002134
clc
adc.b {x_pixel}
sta.b {x_pixel}
lda.b {cosine}
sec
sbc.b {sine}
sta.b {a}
sep #$20
sta $00211b
xba
sta $00211b
lda.b {size}
lsr
sta $00211c
rep #$20
lda.b {size}
xba
clc
adc.b {a}
lsr
sec
sbc $002134
clc
adc.b {y_pixel}
sta.b {y_pixel}
lda.b {size}
sta.b {c}
lsr #3
sta.b {b}
lda.b {size}
asl #2
sta.b {a}
sep #$20
lda #$81
sta $004200
rep #$20
convert_bitmap_loop:
lda.b {c}
bne old_rotation_step
jmp new_rotation_step
old_rotation_step:
lda.b {x_pixel}
pha
lda.b {y_pixel}
pha
convert_line:
sep #$20
jsr convert_pixel
phb
lda.b {e}
pha
plb
rep #$20
lda.b {bitplane_0}
sta $0000,x
lda.b {bitplane_2}
sta $0010,x
plb
txa
clc
adc #$0020
tax
lda.b {b}
bne convert_line
pla
clc
adc.b {cosine}
sta.b {y_pixel}
pla
clc
adc.b {sine}
sta.b {x_pixel}
dec.b {c}
lda.b {size}
lsr #3
sta.b {b}
lda.b {size}
txa
sec
sbc.b {a}
inc #2
tax
bit #$000e
bne convert_bitmap_loop
clc
adc.b {d}
sec
sbc #$0010
tax
jmp convert_bitmap_loop
convert_pixel:
rep #$20
dec.b {b}
lda.b {y_pixel}
sta.b {scratch_pad_ram}+2
sec
sbc.b {sine}
sta.b {scratch_pad_ram}+6
sec
sbc.b {sine}
sta.b {scratch_pad_ram}+10
sec
sbc.b {sine}
sta.b {scratch_pad_ram}+14
sec
sbc.b {sine}
sta.b {scratch_pad_ram}+18
sec
sbc.b {sine}
sta.b {scratch_pad_ram}+22
sec
sbc.b {sine}
sta.b {scratch_pad_ram}+26
sec
sbc.b {sine}
sta.b {scratch_pad_ram}+30
sec
sbc.b {sine}
sta.b {y_pixel}
lda.b {x_pixel}
sta.b {scratch_pad_ram}+1
clc
adc.b {cosine}
sta.b {scratch_pad_ram}+5
clc
adc.b {cosine}
sta.b {scratch_pad_ram}+9
clc
adc.b {cosine}
sta {scratch_pad_ram}+13
clc
adc.b {cosine}
sta {scratch_pad_ram}+17
clc
adc.b {cosine}
sta {scratch_pad_ram}+21
clc
adc.b {cosine}
sta {scratch_pad_ram}+25
clc
adc.b {cosine}
sta.b {scratch_pad_ram}+29
clc
adc.b {cosine}
sta.b {x_pixel}
sep #$20
lda ({scratch_pad_ram}+2)
lsr
rol.b {bitplane_0}
lsr
rol.b {bitplane_1}
lsr
rol.b {bitplane_2}
lsr
rol.b {bitplane_3}
lda ({scratch_pad_ram}+6)
lsr
rol.b {bitplane_0}
lsr
rol.b {bitplane_1}
lsr
rol.b {bitplane_2}
lsr
rol.b {bitplane_3}
lda ({scratch_pad_ram}+10)
lsr
rol.b {bitplane_0}
lsr
rol.b {bitplane_1}
lsr
rol.b {bitplane_2}
lsr
rol.b {bitplane_3}
lda ({scratch_pad_ram}+14)
lsr
rol.b {bitplane_0}
lsr
rol.b {bitplane_1}
lsr
rol.b {bitplane_2}
lsr
rol.b {bitplane_3}
lda ({scratch_pad_ram}+18)
lsr
rol.b {bitplane_0}
lsr
rol.b {bitplane_1}
lsr
rol.b {bitplane_2}
lsr
rol.b {bitplane_3}
lda ({scratch_pad_ram}+22)
lsr
rol.b {bitplane_0}
lsr
rol.b {bitplane_1}
lsr
rol.b {bitplane_2}
lsr
rol.b {bitplane_3}
lda ({scratch_pad_ram}+26)
lsr
rol.b {bitplane_0}
lsr
rol.b {bitplane_1}
lsr
rol.b {bitplane_2}
lsr
rol.b {bitplane_3}
lda ({scratch_pad_ram}+30)
lsr
rol.b {bitplane_0}
lsr
rol.b {bitplane_1}
lsr
rol.b {bitplane_2}
lsr
rol.b {bitplane_3}
rts
byuu wrote:
Would love to get my hands on that proto, but it's never gonna happen, so for all intents and purposes, to me it's still theoretical
I sarcastically remarked on FB, if only someone would discover the prototype Secret of Mana CD to go with it. :p It would be awesome if someone got that thing running a tech demo.
strat wrote:
if only someone would discover the prototype Secret of Mana CD to go with it.
That would be pretty much the best thing to ever happen, ever. To play SoM as it was originally intended to be played would be incredible.