When I was a kid I wanted an NES and my parents got me an SMS instead, because it was cheaper due to its lower popularity.

Anyhow, I think this demo is great. I've been thinking of ideas for an NES demo for years, but I'm not sure if it'll ever get priority among the stuff I want to do. I've always admired the demoscene, but as a Canadian it's never been a local thing for me.

I also think the Genesis is by far better designed. Essentially no weird quirks, things "just work", no bending over backwards to get something standard working. This is from a high-level dev POV, I mostly write C with a rare touch of asm on it. I haven't ever even seen the VDP packet format, I don't need to care about it - SGDK does that for me, I tell it to draw this here and it is done.

I only know a bit about the SNES, mostly from reading No$'s documents, never tried to do anything with it myself. And I gotta say - both systems are vastly different and both are dirty in their own way.

The Mega Drive is dirty in the sense that components run asynchronously (synchronisation is not 100% perfect with many edge cases) and the audio hardware has no hardware acceleration for sample playback at all which makes it very tricky to achieve clean sample playback.

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).

It looks like you're from the US, and thankfully game companies sometimes remember that the world is more than just your country.

Oh, I know it all too well every time I emulate a new system and have to add in PAL support.

Quote:

I also find it surprising that you think the SNES is significantly better designed than the Genesis... I don't code for either machine

Most definitely. The Genesis is easier to develop for due to having a CPU that was capable of having a reasonable C compiler for it. But from an emudev perspective, the SNES is leagues nicer to emulate than the Genesis.

Quote:

a thousand video configurations that affect how you can/can't use VRAM

That's all very configurable.

If anything, the SNES PPU is too flexible. Very hard to understand the entire process, from start to finish. I really should make a flow chart sometime of how all the various bits and settings come into play on rendering each pixel.

Quote:

a CPU that changes speed depending on what memory it uses

In practice, this is a transparent detail. Just know that for the ROM fetch portions of CPU instructions, it'll be 25% faster on FastROM. So if you can use FastROM, use it.

Quote:

When I was a kid I wanted an NES and my parents got me an SMS instead, because it was cheaper due to its lower popularity.

Remind them of that when they ask you for the nicer retirement home ... ;)

[this is obviously a joke]

Quote:

I also think the Genesis is by far better designed. Essentially no weird quirks

... wow.

You don't consider the format of bits to write to the VDP to be a weird quirk??

Quote:

I haven't ever even seen the VDP packet format, I don't need to care about it - SGDK does that for me, I tell it to draw this here and it is done.

Yeah, see ... I'm talking about from a hardware design perspective. Not from a programmer perspective. The Genesis wins handily as I said above on account of having a good C compiler for it.

Quote:

And the SNES is dirty in the sense that you need to fiddle with banks all the time

The SNES is not the NES. Just use 'HiROM', and your ROM is at $c00000-ffffff instead of the Genesis' $00000-3fffff. Very simple.

Yeah, the 'LoROM' style was funky, I'll agree with you on that.

Quote:

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

OAM was a disaster too, certainly. Having a few unused memory bits in return for a more linear format of attribute fields would've greatly helped with sprite-intensive games.

The main problem is I can't just make blind changes to run your demos.

And I wouldn't ask you to. I know how bad it can be to hack operational code to try to "fix" it without understanding what's going on.

Maybe somebody will do a logic analysis that fills in the gaps, or decap and scan out the PPU, or something. Until then, I guess we'll have to deal with "close enough", meaning perfect for most things but prone to little niggles in cases of creative hardware abuse.

Normally I wouldn't see the need to comment on this, but Oerg866 seemed to think emulator accuracy wasn't an issue with SNES, and an effort to compete with Overdrive 2 might not be well served by that assumption...

How easy is it to mod a TV to accept a modded console's output? TVs sold in the United States typically aren't specifically advertised as multi-system compatible.

Are you sure about this? I admit I don't know a lot about consumer TVs, but pretty much any CRT TV sold here since around the mid 90s (not counting cheap-ass knockoff brand 14" VCR-combo products), or maybe even earlier, supports both 50hz and 60hz TV signals - I don't think they did that to accomodate people who liked to import video games, I imagine it was just cheaper to produce tubes that could be reused across continents, but that's pure speculation on my part.If "newer" CRT TVs in USA or Canada don't share the same kind of compatibility, that's pretty baffling to me.

Either way, ya'll need to get PVMs or similar high-end monitors. Those bastards will eat anything, including the absolutely all-important RGB video signal you guys were robbed of.

I've never encountered a european TV with SCART input that doesn't do both 50 and 60Hz video if fed an RGB signal. NTSC video over composite or S-Video is another matter though, more often than not the set will sync correctly but can't decode the color information.

So although we got shafted with crap PAL conversions of 99.9% of the console games released, the connoisseurs here won out with readily available RGB options and easy 50/60Hz modding options from the 16-bit generation and onwards.

I'm a bit puzzled that a console demo in 2017 is made for PAL, though! It so greatly reduces the number of people who will be able to enjoy it properly. The majority will only ever see it on YouTube on a 60Hz display with the frame pacing destroyed, and even most people with a Mega Drive or Genesis and a good enough flash cart aren't able to run PAL software on it.

PAL gamers got the short end of the straw for years, with slow/glitchy conversions and the like, so I don't find it particularly surprising they're not too hesitant in giving the 60Hz world the middle finger for a change. But yeah, I'm kinda disappointed I can't run some of these demos on my own consoles.

And the SNES is dirty in the sense that you need to fiddle with banks all the time

Just use 'HiROM', and your ROM is at $c00000-ffffff instead of the Genesis' $00000-3fffff. Very simple.

Until you start dealing with addressing modes that support only the current data bank and have no long counterpart. There is (dd,S),Y but no [dd,S],Y. There are alalal,X and aaaa,Y but no alalal,Y. There is (dd,X) but no [dd,X]. (But that's arguably less important because the only thing I can think of that uses arrays of pointers on direct page is a music engine, and that runs on the SPC700.) MVN works on hardcoded banks. A full address doesn't fit in a register.

Optiroc wrote:

I've never encountered a european TV with SCART input that doesn't do both 50 and 60Hz video if fed an RGB signal.

I've never encountered a TV with SCART input. SCART isn't really a thing in the USA.

So the MD has a better architecture than the SNES... read the first 2 sections of that doc... remember these are the people that made the Saturn.. yeah uhuh... Small note on said doc in

Quote:

IIRC If the Z80 tries to access ROM while the VDP is doing a DMA from 68k RAM this can lead to corruption of RAM contents due to glitchy signals on the address bus (similar to the C64’s VDP bug).

I think you mean the C64 VSP bug I remember one night when the programmers were having a SNES vs MD fight, their was a quip about the MD being a machine you debug with an oscilloscope.. now I see what they meant...

Banking on the SNES shouldn't really be an issue, if you split each bank into a "namespace" then 32K should easily get you by on most things. You could even pack multiple "namespaces" into one bank. You will see this in the games, were typically you can see which banks were given to which programmers, as their style changes. So the System code, IRQ/NMI, standard library type functions bank 0, overworld code is in bank 1, the menu system bank 2, the battle bank 3 etc. Being able to switch the Data Bank Register allows you to store your data in sets in the other banks, and easily switch which "set" you code reads by changing the DB register. This allows you to make very small code that can reference N sets of things with minimal code changes and without having to have large and slow offsets, indirect pointers et al. MD coders be "so I have the nicest CPU that uses 70% of it die to give me a really nice orthogonal instruction set that eats clocks but I like to program in C because who has time for ASM. I couldn't program ASM for the 65816, its instruction set isn't orthogonal, I have to worry about an edge case like Indirect 24 Long offset with a y."

Why PAL?a.) see http://static.diffen.com/uploadz/thumb/ ... SC.svg.png then note that most SECAM countries also support PAL, yes you are that tiny red bit, yay youb.) When you make a demo, you want the best machine you can get, PAL machines will slaughter a NTSC machine.c.) Why make beautiful artwork to show off your skills and have it ruined by Never The Same Colour, how do you make a hot babe in No True Skin Colour, how do you keep colour consistent in patterns with Never Twice the Same Colour. Use Perfect All Lines d.) Because Americans got into using Carts and Consoles being consumers and didn't get into programming so they have no demo teams/scene/parties, while the PAL territories stuck with computers and have a large number of them. So them then running NTSC with voltage converters and expensive TV/projection gear at the parties so they can have a machine they have to import and can run less code and is has worse colours and sucks - Makes No Sense.

I've never encountered a european TV with SCART input that doesn't do both 50 and 60Hz video if fed an RGB signal.

I've never encountered a TV with SCART input. SCART isn't really a thing in the USA.

Yeah, my post was written from a european perspective. The SCART connector was even called EURO/EURO-AV more often than not on the early equipment I used that had it (Philips TVs and VCRs in the mid-to-late 80s). And that's in manuals, the actual connector is usually just labeled "AV".

Yeah, my post was written from a european perspective. The SCART connector was even called EURO/EURO-AV more often than not on the early equipment I used that had it (Philips TVs and VCRs in the mid-to-late 80s). And that's in manuals, the actual connector is usually just labeled "AV".

Why PAL?a.) see http://static.diffen.com/uploadz/thumb/ ... SC.svg.png then note that most SECAM countries also support PAL, yes you are that tiny red bit, yay youb.) When you make a demo, you want the best machine you can get, PAL machines will slaughter a NTSC machine.c.) Why make beautiful artwork to show off your skills and have it ruined by Never The Same Colour, how do you make a hot babe in No True Skin Colour, how do you keep colour consistent in patterns with Never Twice the Same Colour. Use Perfect All Lines d.) Because Americans got into using Carts and Consoles being consumers and didn't get into programming so they have no demo teams/scene/parties, while the PAL territories stuck with computers and have a large number of them. So them then running NTSC with voltage converters and expensive TV/projection gear at the parties so they can have a machine they have to import and can run less code and is has worse colours and sucks - Makes No Sense.

I'm not talking voltage or PAL vs NTSC (which only was a problem if you were into LaserDisc in Europe, never for consoles really), rather PAL50 vs PAL60 (actually PAL doesn't really come into the equation here if you're using RGB connectors, as you should). Any console nut in europe worth his salt has a 50/60Hz switch installed so games can be enjoyed at their proper refresh rate, which in no way affects color reproduction.

Anyway, my argument isn't about that but rather about how people are likely to watch anything nowadays – on a fixed 60Hz computer screen (or television set). PAL50 content will always have the frame pacing destroyed for those. For the same reason I've been arguing with my pals who still make Amiga demos that PAL60 would be the better choice (especially since they do most development in an emulator on a fixed 60Hz display anyway).

For 8-bit computer/console demos I realize that 50Hz is really the only option here in europe, but Amiga and 16-bit consoles always have had the 60Hz option and would now be better off if it was used.

It's not a choice for video colors or something like "revenge of the blue apples and red cucumbers VS the world" .PAL machines are the best choice for their extended vblank if you need huge VRAM transferts .

I think the first OD demo was pal at start for commodities (to don't worry about VRAM transferts optimisation for the party), but was thinked for 60 fps in mind,and the second was really for pal machines, to benefit from their DMA .

Why PAL?a.) see http://static.diffen.com/uploadz/thumb/ ... SC.svg.png then note that most SECAM countries also support PAL, yes you are that tiny red bit, yay youb.) When you make a demo, you want the best machine you can get, PAL machines will slaughter a NTSC machine.c.) Why make beautiful artwork to show off your skills and have it ruined by Never The Same Colour, how do you make a hot babe in No True Skin Colour, how do you keep colour consistent in patterns with Never Twice the Same Colour. Use Perfect All Lines d.) Because Americans got into using Carts and Consoles being consumers and didn't get into programming so they have no demo teams/scene/parties, while the PAL territories stuck with computers and have a large number of them. So them then running NTSC with voltage converters and expensive TV/projection gear at the parties so they can have a machine they have to import and can run less code and is has worse colours and sucks - Makes No Sense.

I'm not talking voltage or PAL vs NTSC (which only was a problem if you were into LaserDisc in Europe, never for consoles really), rather PAL50 vs PAL60 (actually PAL doesn't really come into the equation here if you're using RGB connectors, as you should). Any console nut in europe worth his salt has a 50/60Hz switch installed so games can be enjoyed at their proper refresh rate, which in no way affects color reproduction.

Anyway, my argument isn't about that but rather about how people are likely to watch anything nowadays – on a fixed 60Hz computer screen (or television set). PAL50 content will always have the frame pacing destroyed for those. For the same reason I've been arguing with my pals who still make Amiga demos that PAL60 would be the better choice (especially since they do most development in an emulator on a fixed 60Hz display anyway).

For 8-bit computer/console demos I realize that 50Hz is really the only option here in europe, but Amiga and 16-bit consoles always have had the 60Hz option and would now be better off if it was used.

I made the same argument to the VICE team. Make a 60hz PAL C64 for emulator smoothness. Deaths ear. The issue is mainly the Scene is held up by the Hardware purists, who if it doesn't work on hardware then it is not real. The Social Elite as it were. So if I make the Game work on 60hz PAL, what do the social elite get, is it to slow? Do we speed up the SID to run at 50hz or 60hz timings? If we make the SID 60, on a real PAL the music will sound bad, if you don't convert it to 60 then all your frame counters are out for the update of Music. So basically you then forsake the hardware all together and just make this new thing which won't be right on a PAL or an NTSC machine, so why not add a 256 colour mode and 4mhz CPU while you are at it? However these days we now have GSync and FreeSync which should allow us to get 50 on a monitor Just to get the Emulator teams to actually use it/port it to linux so they don't get on high chair about it Also I think it would be interesting to see what happens on a 120Hz monitor, it still won't be dead perfect 50, but it will be closer, maybe close enough.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum