nesdev.org

lidnariq wrote:technical writeups

When the SNES and the Genesis are involved, its more like "technical" writeups.

lidnariq wrote:

Oerg866 wrote:Are you literally trolling? The Amiga is a computer designed for things like this. It has a ton of custom chips devoted to fast graphics, overhead-less digital sound and 512KB+ of memory - oh, and it isn't tilebased.

Specifically talking about the launch Amiga, not the later ones.

It's a 68k at the same speed, with (because of your choice of large cart) usually less memory available (albeit, per your complaint, more memory dedicatable to the graphics processor). Any reliance on computrons should be comparable between the two, and any substantial differences will be due to the hardware support.

Sure, the OCS has the copper function (but OD2 tentatively seems to not rely on many raster effects) and seventy-gazillion DMA channels (but OD2 streams most of the soundtrack from ROM). And despite the A500's support from its coprocessors, OD2 looks as good as a top-tier A500 demo. With better pacing ... much better.

Regardless, I will definitely enjoy reading whatever technical writeups show up as they come out.

Oh whoops, I seem to have misinterpreted what you said.

Sawwy ^^"

Oerg866 wrote:emulators (ok a non issue for snes i guess)

Higan is an impressive emulator, to be sure - but it's not perfect, not when you're trying crazy stunts. I've broken it a few times already while messing around with the PPU, and so far as I'm aware none of the cases in which that happened work perfectly yet.

Mid-scanline BGMODE write handling is much better than it was before v095; better than real hardware in fact (real hardware has worse garbage, and can't quite perfectly mask it with sprites). DMA direct colour actually works better in older versions that get mid-scanline scroll changes wrong, though every version shows the picture one scanline late for some reason. (I was actually able to debug and test a case that only showed up on other people's consoles, because bsnes v072 happened to work the way theirs did.) HDMA OBSEL writes (for OBJ data offset) had the wrong timing last I checked (v097), but for obvious reasons HDMA isn't how you should do that particular stunt...

could we bribe you to come to our side some day?

There's a MD emulator in higan. It's not very far along yet, but it's coming.

...

Anybody know if there are PAL 1/1/1 units? It could be useful to be able to use DMA and HDMA at the same time, and if it's for a demo there's no need for it to work on NTSC...

I, for one, salute our Alien Overdrives.

It's a nice and impressive demo. Good SNES (& PCE) coders shouldn't go red with rage or call foul upon seeing it, but rather say 'good show' and keep working on making their own routines better. Who gives a shit about console wars from 25 years ago, anyway? You've all got enough dough now to own both, right?

93143 wrote:better than real hardware in fact (real hardware has worse garbage, and can't quite perfectly mask it with sprites).

There's no such thing as "better than real hardware"! "Lack of glitches" isn't what makes an emulator good, the "presence of glitches similar to those of the real hardware" is.

Different people have different definitions of a "good" emulator. Some prefer accuracy, such as homebrew developers. Others prefer enhancements of various sorts.

Oerg866 wrote: @Oziphantom: There are many reasons why MD demos or console demos in general will never reach the quality of effects you get on C64 and Amiga. (Tiles vs. Linear bitmap / bitplanes /etc., video memory not being mapped to the CPU address bus, closedness and unknownness of many parts of the systems, memory size, lack of good dev environments and/or emulators (ok a non issue for snes i guess) and most importantly those platforms having a 30+ year head start.) - but again let me just ask you to attempt something like this before calling our efforts trivial.

I'm not calling it "trivial", just explaining that the trick is coming up with ways to limit the number of calculations you do with clever lookup tables and pallet effects. Coming up with these that both work and are pretty is an "Art", not trivial. But I probably also suffer from C64 snobbery as in the C64 world when an effect is "just speed code" we tend to just be "oh you make some tables and do some speed code - yah" as we now focus more on discovering more hardware tricks or ways to combine tricks, or limiting ourselves to 256B or 4K.. Amazingly we are still finding them 30 years later XD

psycopathicteen wrote:My idea wouldn't work because there wouldn't be enough dma for 2 layers, even in PAL.

@Oziphantom, I'm still confused. Wouldn't there need to be so many prerendered tiles of different scroll values, and scaling rotation amounts that you might as well just prerender the whole thing?

You don't pre-render, you build the screen out of lookups into the tables, chars etc, but clever setup of the tables, chars allows you to greatly reduce the number of calculations you need to do. The trick is not remove doing any maths, but to find ways to reduce as much maths as possible. Have a look at http://codebase64.org/doku.php?id=base: ... ng_carpets it is the only one with pictures and C code to help explain the type of tricks better sadly there is not one that covers a bitmap zoomer.

tokumaru wrote:

93143 wrote:better than real hardware in fact (real hardware has worse garbage, and can't quite perfectly mask it with sprites).

There's no such thing as "better than real hardware"! "Lack of glitches" isn't what makes an emulator good, the "presence of glitches similar to those of the real hardware" is.

I understand that. But surely it's clear what I meant? Changing BGMODE mid-scanline, for the purpose of juxtaposing BG graphics in two different modes on the same scanline, works better in higan v095+ than on real hardware, in much the same way that sending graphics to VRAM during active display works better in ZSNES than on real hardware. (Okay, maybe that's a bit extreme...)

I suppose a creative 'scener could come up with a use for the garbage pixels. So far, though, whenever anyone's tried it, the mode switch has been the singular goal and the garbage an unfortunate side effect.

...

I'm a bit late with this, but Overdrive 2 is a most impressive demo. I do hope the SNES community rises to this challenge eventually...

93143 wrote:in much the same way that sending graphics to VRAM during active display works better in ZSNES than on real hardware. (Okay, maybe that's a bit extreme...)

That's the exact analogy I'd use! You don't normally want the emulator to show cleaner results for a special trick than the hardware does, you want the emulator to behave the SAME, ideally. If you use inaccurate emulation as a reference point, you're just making higan/zsnes/nesticle programs rather than programs for the actual consoles.

I'm a bit late with this, but Overdrive 2 is a most impressive demo. I do hope the SNES community rises to this challenge eventually...

I agree! the more the better!

Oziphantom wrote:

psycopathicteen wrote:My idea wouldn't work because there wouldn't be enough dma for 2 layers, even in PAL.

@Oziphantom, I'm still confused. Wouldn't there need to be so many prerendered tiles of different scroll values, and scaling rotation amounts that you might as well just prerender the whole thing?

You don't pre-render, you build the screen out of lookups into the tables, chars etc, but clever setup of the tables, chars allows you to greatly reduce the number of calculations you need to do. The trick is not remove doing any maths, but to find ways to reduce as much maths as possible. Have a look at http://codebase64.org/doku.php?id=base: ... ng_carpets it is the only one with pictures and C code to help explain the type of tricks better sadly there is not one that covers a bitmap zoomer.

Can you post a picture of what you mean? Lookup tables can mean anything. The "codebase64.org" doesn't help because I already know how all those tricks work.

Cool demo. I like the music a lot (because it sounds so atypical for Mega Drive).

If you want to compete, remember that even the best code does not seem all that impressive (to most audiences) without good design, graphics and audio to complement it.

Oerg866 wrote:Guys, you're freaking hilarious and just absolutely full of it. The salt level in this thread is insane. :)

The allegations are hilarious. Custom chip? Prerendering? Playing an animation? This is not the SNES and we most definitely don't need half a dozen Super FX, DSP or other helper chips to do something useful. Just grab a calculator and you'll end up with ~350 bytes per frame.

Don't worry, that's probably the highest compliment you can get. But if it makes you feel any better, I believed this was running on a stock Genesis :)

I think there's a very good reason why absolutely nothing technically impressive has come out of the SNES homebrew / demo scene in 27 years, sans the recent efforts by elix.

Everyone knows the Genesis CPU is significantly superior to the SNES CPU. Just like the SNES PPU runs circles around the Genesis' VDP. The sound chips are a wash, based on personal preference.

The SNES vs Genesis fight ended 25 years ago :P

I wrote an SNES emulator first, because it has the vastly superior library of commercial releases. At least for the genre I care about most (JRPGs). But there are still great Genesis games (Shining Force I&II, Phantasy Star IV, etc), so I wrote a Genesis emulator too.

Enjoy both systems for what matters: the actual games that were released for them :D

could we bribe you to come to our side some day? ;)

I don't really have the ten years of my life to invest into researching the system as thoroughly.

Plus, a lot of what made bsnes so great were all the people that helped me along the way. Most of those people were into Nintendo consoles more, and many are now gone :(

There's some really great Genesis emudevs too, but I think their efforts are kind of overshadowed by how far behind Genesis emulation still is.

Probably about a year out from even attempting to work on things like the VDP test registers and 128K VRAM mode, sorry.

Also yeah this was meant as a callout to the SNES homebrew/demo community. Been a while since we've heard from you.

It's because of what I said above: the SNES CPU is much less capable of computations for software-rendered effects. And it's also less fun to program for than a 68K. Yet it has a very strong PPU compared to the Genesis.

As a result, you have commercial titles that are absolutely gorgeous like Tales of Phantasia, Bahamut Lagoon and Star Ocean. SNES games don't have to rely on undocumented VDP test registers to pull off translucency.

So yeah, add all that up and it's no surprise Genesis tech demos are more impressive. As you said, the best trick on the SNES is to use FMV, eg Super Road Blaster.

I'll tell you any day of the week that the Genesis is better designed

... the SNES feels like a coherent, custom-fit design.

The Genesis feels like someone went on a shopping spree at the computer parts store.

Just look at the -batshit insane- format you have to use to send commands and write to the VDP memory or set register values. That is not an elegant design: it's a "how can we glue these two disparate components into a working system?" design.

Look at all the ways you can deadlock the Sega Genesis by doing "disallowed things." There was only one known CPU crash on the SNES, it was tricky to do (DMA right as HDMA started), and was fixed in revision 2.

The big problem was that Nintendo was classic Nintendo, the same Nintendo they've always been, with their "innovative uses for withered technology" motto, and they kneecapped the SNES in the CPU department. If Nintendo had thrown in a fast 68K CPU and fast RAM, nobody would be having these SNES vs Genesis discussions.

Higan is an impressive emulator, to be sure - but it's not perfect, not when you're trying crazy stunts. I've broken it a few times already while messing around with the PPU, and so far as I'm aware none of the cases in which that happened work perfectly yet.

I got all of your demos to run. The only one that doesn't work now is your palette RAM DMA, because fixing that throws off timings in other games.

I need those timing numbers for PPU fetches from jwdonal, because I've reached the end of what I could work out using pure software analysis.

There's no such thing as "better than real hardware"!

Everyone here knew what he meant :)

The garbage on the SNES is due to more state being latched longer than it is in higan.

I have the SNES PPU designed in such a way that these changes would be trivial ... but only if we knew what they were. It's vastly too difficult (for me) to build test cases and try to turn garbage pixels on the screen into concrete understandings of what was being latched at what cycle.

If I can at least get the VRAM fetch timings from jwdonal, then I will at least have a *start* for trying to eke out this information from specially crafted test ROMs.

byuu wrote:Don't worry, that's probably the highest compliment you can get. But if it makes you feel any better, I believed this was running on a stock Genesis

It was running on a stock PAL Mega Drive. To the best of my knowledge, all Genesis systems are NTSC, and with the demoscene primarily confined to mainland Europe, demos like this tend to be PAL exclusive.

byuu wrote:Enjoy both systems for what matters: the actual games that were released for them

Including or excluding the creation of new games for them in 2017?

byuu wrote:... the SNES feels like a coherent, custom-fit design.

The Genesis feels like someone went on a shopping spree at the computer parts store.

So in other words, the Genesis looks more like a PC, and it is the master in the computing speed race.

byuu wrote:Just look at the -batshit insane- format you have to use to send commands and write to the VDP memory or set register values. That is not an elegant design: it's a "how can we glue these two disparate components into a working system?" design.

Or a "how can we have a machine that runs games from this generation and the previous generation?" The format resembles that of the Master System, which in turn resembles that of the TMS9918 series VDP in the TI-99/4A, CreatiVision, ColecoVision, and SG-1000.

byuu wrote:Look at all the ways you can deadlock the Sega Genesis by doing "disallowed things."

Some of that might be tradition: 68000 systems are more likely to assert /BERR than 65816 systems are to assert /ABORT. When the 68000 came out, workstations and servers were moving toward memory protection rather than just letting programs run by one user of a time-sharing system stomp all over those run by another, while 65816 systems were either upgrades for 6502 systems (CMD SuperCPU for Commodore 64), backward-compatible successors to 6502 systems (Apple IIGS), or systems where backward compatibility with a previous 6502 platform was considered at least at the early design phase even if ultimately discarded (Super NES).

Or are there ways to lock a Genesis so hard that it can't even call the bus error handler? At least the 68000 can reset the Z80 in a Genesis; the same can't be said for the 65816 and SPC700 in a Super NES.

All the oddities of VDP access and weird scattering of bits in registers stems directly from TMS and SMS VDP.

Example from my work in progress VDP doc (MD - SMS - TMS) : And as far as lock up conditions go, they only happen if you access 8th and 9th MByte (no !DTACK generated in hardware), when accessing ranges of unused addresses in VDP space (10th and 11th MByte), when you make the VDP give you a read or write and you do the opposite (no !DTACK generated then) and when you set up DMA registers and don't do a DMA but a regular access instead (VDP seems to barf entirely in that case, I am still investigating this behaviour).

!BERR is tied high in MD, bus error will never happen. On Neo Geo there's a jumper to trigger a bus error manually.