nesdev.com

If you miss VBLANK, the read/write just won't have any effect; it won't crash the system. Same goes for accessing 'invalid' memory areas.

It will come, but it's easier said than done. It's not just about how hardware features were used, some effects (esp. the rotozoomer) have a mathematical background I don't want to leave unexplained, but this will take time, I want to make sure that most people will actually understand it. I will probably draw lots of pictues and diagrams too.

But once it's done I'll post it wherever people might be interested including this place.

Thanks a lot,the first one was very interesting to read

VRAM is locked outside VBlank, yes (as far as I know - fullsnes suggests that there could be holes in the timing). But OAM and CGRAM aren't, and you can in principle corrupt them by writing outside the appropriate blanking times (VBlank/forced blank for OAM and additionally HBlank for CGRAM) because the writes go to the current PPU read address instead of the CPU write address. The DMA direct colour trick (analogous to FantomBitmap on the Mega Drive) exploits this behaviour by writing to CGRAM during active display. To my knowledge, the only successful non-blanked OAM exploit to date is whatever Uniracers does with HiOAM during HBlank.

Pretty much. The 65816 issues has been beaten to death here, obviously, but it is indeed a shame that WDC didn't go for something a bit more expensive, and spent those transistors on for example a couple of 24-bit address registers. Having register/memory size encoded in the instructions instead of relying on status bits would've been nice, too. But hey, the machines are what they are and we love them with all their faults and imperfections... (:

Anyway, congratulations to an absolutely mindblowing demo! One of few "proper psycho code" level demos ever done for consoles, really...


Looking forward to that! That rotozoomer is a damn head scratcher. The greetings scroller is also really something else... The interference, blending and plasma effects are obvious how you do after reading the technical write-up, but nontheless impressive and you just gotta love this kind of "world's first" hardware exploitation effects.

I got 8 layers of strips moving onscreen. Now I need to turn these strips into checkered squares.

Something I forgot the 68000 had was a MOVEM instruction that could move several registers to memory in 1 instruction. I wouldn't be surprised if the rotozoomer used it. You can store a 8x8 tile inside the 68000 registers and send it straight to VRAM (if there is enough bandwidth) with MOVEM.

Wait, it just occurred to me. What if the fractal rotozoomer really is just 2 layers with AND-masking, like the plasma transparency effect was?, but there's 6 colors so I don't know how that would map out.

1 instruction, but a metric fuckton of cycles. Worst case 18+4n.



No, you can't. The movem instruction sends it to a continous set of addresses. So if you were to do

movem.l d0-d3, ($C00000)

it would write these to $C00000, $C00004, $C00008, $C0000A - a sure-fire way to completely and utterly crash everything.

The movem instruction is intended for stack operations.



As I said earlier: You know nothing.

Please calm down everyone. We were half joking when we said that, it was rather meant as: "your turn, SNES scene". But seeing how everyone in here is getting busy we succeeded

Given that it almost took us 4 years to make this and we don't have much SNES experience don't expect to see anything on the SNES from us anytime soon. Also, Overdrive 2 isn't over yet. We have documents to write (the tech doc was only so quickly done because I wrote it in parallel with making the demo so just had to proof-read and fill in some extra notes and stuff), incompatibilities to track down and fix if possible, make carts, etc.

And please don't just try to copy effects. Sure, many effects are easy to do on the SNES due to its superior graphics capabilities (3rd layer for rain, mode 7 for rotating cube / rotozoom, etc.), but please try to make a whole and unique demo instead of just saying "the SNES can do this and that too! or better!"

Anyway, I'm looking forward to seeing your SNES demos.

(And movem is actually useful for quickly copying data in RAM or loading/storing registers in some cases, but it depends on the use case, 25% speed gain compared to other 68k instructions in best case. But as oerg866 said you can't use it to write to video memory, all you can do is writing to RAM and then doing a DMA later on, but it's usually faster to just do a DMA from the source data in the first place and not waste CPU cycles on movem.)

You can take you're time writing you're document.

It started to calm down until:


@Oerg866: You seem convinced that people are trying to attack you ever since your first post on this thread, which isn't true.

This has been a super fun thread to lurk on, and in saying that I haven't seen any good reasons to become hostile toward others on here. Almost makes me wanna poke some fun accusations at the Sega 16-bit community for having problems with just that, but I wouldn't know.

I understand the impulsive reaction to try and recreate the exact same effects, to prove that "the SNES can do it too", but ultimately, being creative and thinking of new ways to combine the things the SNES does best might give more interesting results, and will probably be less frustrating than trying to figure out how each effect was implemented.

Okay I've done some more research into this, there is no free lunch. PAL-60 is a lie.
Basically there is the 6526 PAL-N and the 6527 PAL-M but
PAL-N is 65/312 at 50hz so it still gives you 50fps
PAL-M is 65/262 at 60hz so it still gives you 60fps.
Now the PAL-M has the same number of clocks per frame as normal NTSC, so while it has the PAL colour encoding, it can't match a PAL machine, it is still lacking 2626 clocks. Its just a slightly better NTSC.
PAL-N while being the fastest machine, in that it will give you an extra 624 clocks per frame, not to be sniffed at, but it is still 50fps so you will still get the jerk on PC monitors.

This is something that's been on my mind for a while. Here are my thoughts:

A lot of demoscene stuff is basically smoke and mirrors. I get that the whole point is to optimize around a lack of interaction but I'd think the majority of people don't realize this. The effect is that you have people who think you can create an interactive game using all of these effects (see: YouTube comments section, but then, I should probably get back to blocking the comments, as they are rarely insightful). A lot of stuff is at least partially faked or pre-computed (Second Reality 3D scene), which strikes me as rather dishonest.

There's also an obscene amount of elitism in the scene. The constant platform wars are incredible exhausting and I don't understand how anyone can even cope in such an environment. When even Speccy coders do it, you know your community has problems (I realize this is possibly a joke but it has all the rhetoric of platform elitism).

Having said all that, I might be interested in contributing to a SNES demo, assuming that the project isn't run by assholes. I would probably be the Awkward Outsider though as I'm not from a PAL region (though I am interested in the possibilities afforded by the additional DMA headroom provided by the 50hz format). Even if I don't work on a demo though, I still want to work on software for the SNES. The PPU has some interesting bells and whistles. I can render VSTs from Renoise and import them straight to the SNES as game audio. That's really cool! The CPU is weird but I find it a fun challenge to work with (it also helps that despite any awkwardness, I can still do 16-bit arithmetic which really does wonders). I also hope that maybe I can help other people realize the joy of developing for this weird machine. And if anyone wants to shame me for liking the SNES, they're terrible people.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627

It hit the low point when the Amstrad team(s is there more than one?) got personal https://www.youtube.com/watch?v=YJosZfm560Q actually calling out effects by groups, C64 groups.
At least it is a quality demo