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.Stef wrote:I should have been more specific: outside the HDMA channels.Don't tell that to the -nearly every game in the library- that used HDMA and per-scanline IRQs to do exactly that ... :/
They are here for that but still, if you don't properly time your code and your VRAM writes goes a bit outside the VBlank period, bang! On the MD, nothing wrong happen... you just lost a bit of time.
To be honest that happen on many old systems and probably on the SNES as well. Still if you access invalid memory area mean you probably have something really wrong in your code!And how easy it is to hard-lock the memory controller.
- For making cartridges of your Super NES games, see Reproduction.
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
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.psycopathicteen wrote:Isn't there supposed to be another write up that explains how the effects were done?
But once it's done I'll post it wherever people might be interested including this place.
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.creaothceann wrote: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.
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... (:Kabuto wrote:And the SNES is dirty in the sense that you need to fiddle with banks all the time (not needed on the MD due to its 16 MB linear address space) and Nintendo was stingy with register and memory bits, forcing programmers to fiddle with bits too (they e.g. crammed sprite coordinate bits together whereas on the MD the 9 bit sprite X coordinate just lives in a 16 bit memory slot with the upper 7 bits left unused).
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.Kabuto wrote: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.
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.
- checkerboard demo.zip
- (2.43 KiB) Downloaded 110 times
psycopathicteen wrote:I got 8 layers of strips moving onscreen. Now I need to turn these strips into checkered squares.
1 instruction, but a metric fuckton of cycles. Worst case 18+4n.psycopathicteen wrote: Something I forgot the 68000 had was a MOVEM instruction that could move several registers to memory in 1 instruction.
No, you can't. The movem instruction sends it to a continous set of addresses. So if you were to dopsycopathicteen wrote: 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.
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.psycopathicteen wrote: 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.
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.)
- Drew Sebastino
- Formerly Espozo
- Posts: 3503
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
It started to calm down until:Kabuto wrote:Please calm down everyone.
@Oerg866: You seem convinced that people are trying to attack you ever since your first post on this thread, which isn't true.Oerg866 wrote:As I said earlier: You know nothing.
Okay I've done some more research into this, there is no free lunch. PAL-60 is a lie.Oziphantom wrote:There are PAL-M C64s, they are called "Drean" which was the name of the Argentinean company that made and sold them. This gives the follow setstokumaru wrote:And then there's Brazil, which occupies a huge portion of that map, and despite being lumped together with the other PAL countries, actually uses PAL-M. The name of that standard is very deceiving, because PAL software doesn't work on our consoles, and our TV's don't support PAL video. PAL-M timing is compatible with NTSC timing, so we always used NTSC software on consoles that output NTSC-compatible video but with different color encoding. NTSC was even widely used in Brazil in rental VHS tapes (maybe as a crude form of copy protection, since most VCRs couldn't record NTSC? I don't know...).Oziphantom wrote:Why PAL?
a.) see http://static.diffen.com/uploadz/thumb/ ... SC.svg.png
Code: Select all
Machine Clocks/Lines PAL-I/G/B 63/312 NTSC R56A 64/262 NTSC R8 65/262 Drean 65/312The point of making a 60hz PAL but with 63 clocks rather than 65 clocks was "not real" - and it would be to make the emulator experience better as if you view something that scrolls at 50hz on a 60hz machine it is going to be jerky. Adding Drean support helps this but doesn't help the vast library of existing games.tokumaru wrote:Oh, I see... Well, I guess it's OK to include features in an emulator replicating mods that can be done on hardware, but developers targeting these special "modes" should know that their audience will be severely cut down due to the fact that most people can't or won't mod their hardware.tepples wrote:I read Oziphantom's comment as implying that the scene would think a Commodore 64 modded to output PAL60 or PAL-M is "not real".
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.
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.