blu
Wants the largest console games publisher to avoid Nintendo's platforms.
That's exactly what wikipedia says, save for the main-ram/vram split in your post.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
Cool visual effects in 16bit console games.
- Thread starter nkarafo
- Start date
dr. apocalipsis
Banned
I'm pretty confused about how a knowledgeable guy like you is so, well, confused about this.
You have to load stuff into RAM to make use of it. The ability to DMA transfer stuff directly from cart to RAM doesn't change this. Melody data and sound driver are actually loaded into Z80's 8KB of RAM. While most advanced sound drivers can make use of it as a buffer to avoid bus contention (responsible of low quality samples most games deliver), it has to hold the sound driver (Unless you are using 68k for this, so it would use main 64KB of RAM).
Then, the RAM split I pointed on MegaCD not detailed in wikipedia is important for this very same thing. Every pool of RAM have it's own function and own bandwidth:
MegaCD:
Main RAM: 23.84 MB/sec
VRAM: 11.92 MB/sec
Audio RAM: 23.84 MB/sec
You just can't add it up. You don't work directly from cartridge, it is just a storage media. Nothing else.
I'm not confused about anything, nor am I disputing anything you're saying. You apparently aren't understanding the conversation at hand. To DMA anything, it needs to be addressed. You cannot DMA from a CD rom, you instead transfer assets to a contiguous piece of RAM, which then gets DMA's to component ram. That's what the 4 Mb + 2Mb is for. You don't need these types of contigous pieces of RAM on the genesis, because the cart itself is addressed. You don't move stuff from the cart to ram to component ram, you move directly from the cart to component ram. Contrast with a CD, where you move from CD to Ram to Component Ram.
None of this has anything to do with the conversation at hand.
Sure I can. Your clarification does nothing to change the point of my post.
ioriyagami
Member
Xbudz
Member
Beautiful!!
On real hardware, it just keeps going and going. It's the longest fatality in the game, I cut a lot of the fatality where the character is just falling for long periods out of those gifs. There is also a long loading period before it begins. Whole thing takes maybe 30-45 seconds, which is quite a long time for a death move.
blast processed
Member
This is awesome, what game is this?
dr. apocalipsis
Banned
I'm replying to this quote:
And it is factually wrong.
You have to copy any given tile from catridge to VRAM *at the very least if you aren't processing it in any way* for it to display it. You don't display directly from cartridge, and you are limited by VRAM for the total numbers of tiles available for every screen. Megadrive works as any other system, the only difference being that you don't need to preload all the stuff from a slow storage system first. As fast as it is, it isn't fast enough to load more than a few new tiles each time. You have to load your program code on main RAM, you don't run it directly from cartridge, your tiles on VRAM and your sound driver+data somewhere depending on if you are using Z80 or M68k for feeding Yamaha. Megadrive main RAM is pretty flexible and can hold more things apart from code, but it is just as needed as any other system.
Bank switching wouldn't be possible in any other way. Megadrive can only address 4MB from cartridge, so for larger games like SSFII it has to remap any 512KB chunk beyond that to the addressable 4MB ROM space, load the needed info on RAM and then remap back as needed.
Also, DMA transfers halts main CPU bus, limiting your raw processing power, so you want to limit DMA transfers as much as possible. That's why having a MegaCD plugged in allows you to perform some nice tricks, since you can basically kill Genesis 68k for bandwidth.
And, of course, you just can't "devote 6 Mb to a single stage and 2 fighters at once" on MegaCD. It doesn't adds like that.
And it is factually wrong.
You have to copy any given tile from catridge to VRAM *at the very least if you aren't processing it in any way* for it to display it. You don't display directly from cartridge, and you are limited by VRAM for the total numbers of tiles available for every screen. Megadrive works as any other system, the only difference being that you don't need to preload all the stuff from a slow storage system first. As fast as it is, it isn't fast enough to load more than a few new tiles each time. You have to load your program code on main RAM, you don't run it directly from cartridge, your tiles on VRAM and your sound driver+data somewhere depending on if you are using Z80 or M68k for feeding Yamaha. Megadrive main RAM is pretty flexible and can hold more things apart from code, but it is just as needed as any other system.
Bank switching wouldn't be possible in any other way. Megadrive can only address 4MB from cartridge, so for larger games like SSFII it has to remap any 512KB chunk beyond that to the addressable 4MB ROM space, load the needed info on RAM and then remap back as needed.
Also, DMA transfers halts main CPU bus, limiting your raw processing power, so you want to limit DMA transfers as much as possible. That's why having a MegaCD plugged in allows you to perform some nice tricks, since you can basically kill Genesis 68k for bandwidth.
And, of course, you just can't "devote 6 Mb to a single stage and 2 fighters at once" on MegaCD. It doesn't adds like that.
I don't see why when I've already simplified it down to a single point:
And that's not how bank switching works. SSFII's bankswitching mechanism resides on the cartridge itself. Your address is nothing more than a pointer. It points to a scratch area on the cart itself, and the cart handles transfering data in and out of this scratch area. The Genesis does not move SSFII data in and out of ram like you're assuming.
Yeah, it does.
nkarafo
Member
Eternal Champions.
MrCunningham
Member
It is either Eternal Champions for the Genesis or Eternal Champions: Challenge from the Dark Side for the Sega CD.
dr. apocalipsis
Banned
Sweet lord, I really can't understand where you want to go.
And you simplified it wrong. You have to copy stuff to RAM from any given storage to being able to work with it. When you unpack tiles, you do it on main RAM and then move it to VRAM.
And what the hell are you calling component RAM?
Again, you don't move in and out nor I'm saying that at all, not like you can write to cartridge anyway. You copy from the viewable mapped area to RAM. In the case of SSF2 it preloads into VRAM background tiles stored in the latter 1MB of the cartridge, remaps and then transfers fighters tiles to VRAM as needed.
Trying to correct me about bank switching like this is pretty weird from your part.
You have 512KB of main RAM to hold and run code, shared with as much stored stuff as you can fit in the remaining RAM, then 256KB of VRAM just for rendering purposes, not to store stuff. You don't have 768KB just to store stuff.
And you simplified it wrong. You have to copy stuff to RAM from any given storage to being able to work with it. When you unpack tiles, you do it on main RAM and then move it to VRAM.
And what the hell are you calling component RAM?
Again, you don't move in and out nor I'm saying that at all, not like you can write to cartridge anyway. You copy from the viewable mapped area to RAM. In the case of SSF2 it preloads into VRAM background tiles stored in the latter 1MB of the cartridge, remaps and then transfers fighters tiles to VRAM as needed.
Trying to correct me about bank switching like this is pretty weird from your part.
You have 512KB of main RAM to hold and run code, shared with as much stored stuff as you can fit in the remaining RAM, then 256KB of VRAM just for rendering purposes, not to store stuff. You don't have 768KB just to store stuff.
Right back at you.
No, you don't have to copy stuff to RAM to work with it, good god. You can DMA directly from cart to vram, tons of games do it. Yes, obviously if your data is compressed and in an unsuitable format for VRAM, you need a place to decompress to before DMA. But if your art is not compressed, there is no reason to do that at all. If I'm writing to VRAM, and I don't need to do any operation on my art, I'm not going to copy to ram then to VRAM for no reason.
Component RAM the ram of any component of the Genesis beyond the M68k. i.e. VRAM, CRAM, etc.
The bank switching mechanism in fact does have a piece of RAM to handle bankswitching. Works like so:
[sega genesis] -> 0x00000-0x3FFFFF -> eight 512Kb bank addresses <-> [ROM (which contains ten 512 banks]
? Your entire post has been nothing but nitpicky fluff, beginning with your assertion that 512 KB + 256 KB != 6 Mb.
Hairs = split
ss_lemonade
Member
Might be the sega cd sequel to Eternal Champions. I don't remember any stage fatalities like that on the genesis one.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
Ok, I never touched an MD, but just out of curiosity went to look up on it.
As per the above doc, this is not correct - you can DMA from ROM directly to VRAM. Surely you can DMA from main RAM too, but if something is already in a displayble format on the cart nothing mandates that thing's detour via main RAM.
panama chief
Member
This has always been one of my favorite things to look at.
dr. apocalipsis
Banned
Bro, you can even run Sonic removing cartridge carefully with the only side effect of garbled new tiles when they fail to load on demand. Because everything from code to map is loaded into RAM. You only DMA transfer selected stuff, not everything. And I never said you need to copy from cartridge to RAM to VRAM. Stop trying to mess things.
Then, nitpicky is trying to correct me about bank switching with unneeded explanations and turnarounds. Not clarifying you dont have 768KB of unified RAM to throw there a full game like Sonic 1 and make it run as is.
Your 'Component RAM' definition makes no sense at all.
Then, nitpicky is trying to correct me about bank switching with unneeded explanations and turnarounds. Not clarifying you dont have 768KB of unified RAM to throw there a full game like Sonic 1 and make it run as is.
Your 'Component RAM' definition makes no sense at all.
...because Sonic's art uses LZ77 compression in the ROM, hence it needs to be uncompressed in ram first.
And no, you can DMA anything within the addressed range (ok - one caveat - there is an access restricted area of RAM used for Sega CD IO when a Sega CD is connected)
neat.
dr. apocalipsis
Banned
I never said that you need to do that. I mean any working RAM. This includes transfering a sound sample to Z80's RAM.
Perfect example, by the way. If you don't transfer enough samples to Z80 and start doing DMA transfers, you will halt bus and get a scratchy sample playback instead. You can't just DMA wildly.
As I said earlier:
You're wrong there, too. You can DMA to the Z80 ram from ROM.
You absolutely do not have to go to the working ram if your data does not need to be worked.
This is in stark contrast to how a CD (Or SD Card, or virtually any other storage device) works, where all data must be transfered to RAM to be accessed, regardless of whether they are operated upon or not.
stan423321
Member
The convention really is to not refer to specialized RAM just as RAM (edit: or even worse working RAM). Sound RAM is its own separate thing in mind of mostly everyone.
stan423321
Member
It's basically about the ability of postman dropping your parcel directly into the fridge. I think.
I also think the easiest way to deal with it would be to draw a diagram of various memory "banks" including CDs and arrows showing possible DMAs.
He's basically upset that I didn't go into finer detail about the RAM configuration of the Sega Genesis when that sort of detail was not essential to my point to begin with. My point, essentially, is that every time the Sega CD loads, it can directly address (read: access instantly) 6 megabits of data, roughly the size of an entire Sega Genesis cartridge, from a larger overall pool of data. Asked why the Sega CD version might look or sound better, my explanation is because it can basically devote an entire genesis cartridge's worth of data to those assets. To understand why it can access what is essentially an entire sega genesis' cart's worth of data, I contrasted to directly accessing piece of data on a ROM cartridge, which is possible because a ROM cartridge is also addressed for instant access, like RAM.
It does my explanation no good to go into detail about a small piece of ram devoted to the Video Chip or practical reasons why one might copy and access data from a small set of work ram in the Genesis rather than from the ROM, which is what he's upset that I didn't mention. Which is silly, because by using the term "conventional" and giving an example of specialized RAM (cram) in my post was my way of acknowledging the difference.
But, to try to support his pedantry, he is arguing that practical reasons for working from RAM must always be adhered to (i.e. you are trying to save space in your cart, so your art is compressed, so you need to uncompress it into RAM). But if we're being pedantic, then that's not true - you don't always have to do this, and many games did not.
And, truthfully, if I wanted to get more pedantic, in the cases he's talking about, I would more argue that you are creating new data from directly addressed data in the first place. You can't do that from a CD.
Essentially: "but technically...." "But TECHNICALLY..."
Rayforce baby. It is hella cool. And really good.
it's also called layer section, galactic attack and gunlock.
Here's another gif I made of it a while ago.
I had never heard of this game until this thread. Played a bit of it just now and damn that's a fun/hard game!
Yeah, it's a good one. Make sure you lock on to as many enemies as you can before shooting. You get way more points that way. Only problem is it's kinda distracting...
Sapiens
Member
I hate seeing Sonic and Tails fight.
dr. apocalipsis
Banned
For some reason my ISP died and I have to post using phone, so I will be short.
Well, at this point I have no doubt you are just being idiotic. I said nothing about not being able to do DMA to Z80 RAM, I said doing a DMA transfer on main bus will halt any transfer to Z80 producing garbled playback.
But you won't admit ever that saying Megadrive's RAM is useless because cartridge is a foolishness. So good luck making playable games without RAM and 7KB of bandwidth each 1/60th second with system bus halted more often than not.
Stop being salty for a correction.
With working RAM I was pointing to the local RAM each processor uses for their own needs. In the phrase Krejlooc keeps quoting senseless I was pointing to *any* RAM, since I never especified any RAM, as opposed to cartridge ROM. Just like Z80 has its own 8KB of working RAM. Of course I'm not saying you need to DMA from cartridge to Z80 RAM to 68K RAM to VRAM. And the most stupid thing of trying to interpret this is I already said in my earlier quote that you don't need any other step when moving uncompressed tiles from cartridge to VRAM. Calling working RAM to any given processor RAM is nothing I invented and it is widely used. So stop pretending I used working RAM referring exclusively to main RAM, because that is ridiculous. And more in a system like Megadrive where each proccessor can read and/or write each other processor's working RAM with some limits.
Well, at this point I have no doubt you are just being idiotic. I said nothing about not being able to do DMA to Z80 RAM, I said doing a DMA transfer on main bus will halt any transfer to Z80 producing garbled playback.
But you won't admit ever that saying Megadrive's RAM is useless because cartridge is a foolishness. So good luck making playable games without RAM and 7KB of bandwidth each 1/60th second with system bus halted more often than not.
Stop being salty for a correction.
With working RAM I was pointing to the local RAM each processor uses for their own needs. In the phrase Krejlooc keeps quoting senseless I was pointing to *any* RAM, since I never especified any RAM, as opposed to cartridge ROM. Just like Z80 has its own 8KB of working RAM. Of course I'm not saying you need to DMA from cartridge to Z80 RAM to 68K RAM to VRAM. And the most stupid thing of trying to interpret this is I already said in my earlier quote that you don't need any other step when moving uncompressed tiles from cartridge to VRAM. Calling working RAM to any given processor RAM is nothing I invented and it is widely used. So stop pretending I used working RAM referring exclusively to main RAM, because that is ridiculous. And more in a system like Megadrive where each proccessor can read and/or write each other processor's working RAM with some limits.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
Well, that's how your statement in the part I quoted read. Local/specialized RAM is local/specialized RAM, main RAM is just RAM. When you say something needs to go through RAM that's what most people would understand.
Well, I haven't seen anybody claiming one can DMA wildly - doing a DMA on the MD takes the main bus away from all other agents using that bus (again, going entirely off that doc). Clearly the timing of DMA transfers has to be considered in the grand scheme of things.
Basically, you're saying for best performance a processor might need to buffer data in its local memory pool. Which is fine, but that does not contradict what Krejlooc has been saying - that DMA can copy from cart to VRAM (and for Sound-RAM the Z80 can do the copies from ROM on its own, akin to a bus-master DMA agent), thus cart data that is in a displayable format might have no business going via main RAM before reaching VRAM. Same with sound data on the cart - it can go from ROM directly to S-RAM, no main RAM detours.
255...is that why the flames only go partway up the screen?
The effect covers the entire background, you just aren't noticing it on the darker part of the screen.
Running code is the only prove.
conversation would be more than enough.
Btw; https://www.youtube.com/watch?v=YbX0wwp-nlI
Well, none talks like an engineer. But that's not needed at all. A normal
conversation would be more than enough.
Btw; https://www.youtube.com/watch?v=YbX0wwp-nlI
('Why You Can't Win Arguments Online')
What's the resolution the game is running at?
320 x 224
billythemule
Member
I've had this thought myself but you've got to take into consideration that when you're conversing online, the person who you're addressing isn't usually the only one who can read your lines. This means that if you want to change or shape someones opinion, think of the entire audience. That being said, there is so much that could be erased from this conversation without losing any valuable information. It's something to consider next time you want to rub it in someone's face how ''wrong'' they are and subsequently lose your credibility or respect in the eyes of others.
stan423321
Member
The entire reason I posted is that I saw you referring to audio RAM as "any working RAM". This is simply against existing nomenclature for people dealing with this sort of hardware a lot. I am aware this is not what you're trying to say so I ask you to stop it. Work RAM is basically the way to describe main CPU's biggest RAM bank, so I think for clarity you shouldn't put anything else under that umbrella.
Bruno_Arrais85
Member
Indeed. Could had been a very interesting discussion without all these
colorings at every corner. But well, I think we're not done with this thread,
yet. Plenty of pages to go for some more smooth and steady discussions.
These are my favorites
Amazing thread.
Dynamic lighting in Ranger X.
ThunderForce IV had the coolest parallax I'd seen up to that point:
You can see how there's a vertical gap just large enough that the game doesn't have to render both the upper clouds and lower water/mountains.
Shadow of the Beast
ActRaiser - diving to fight on the surface:
R-Type 3 has so many, just in the first level, including a ton of rotation, scaling, convincing 3D-like hexagonal rotation, and this one, zooming out from your ship's core and into gameplay:
hmmmm how to class the pc engine / turbografx-16
Afterburner II - scaling
Rayforce baby. It is hella cool. And really good.
it's also called layer section, galactic attack and gunlock.
Here's another gif I made of it a while ago.
These 2 are from the arcade version.
Amazing thread.
stan423321
Member
Gotcha.
The Mega CD "VRAM" (actually not called VRAM in documentation) is a completely different beast than regular VRAM which is not surprising given Mega CD has no video output whatsoever. The aforementioned memory bank needs not to be accessed through ports and such, it's basically another bank of RAM that happens to have yet another processor connected to it, except that processor is not really programmable. You can just turn it off, ignore it and use it as regular RAM for one of 68k's. Or split it in half for both of them.
If anything this looks like the most sane part of Mega CD RAM since everything else has some oddities like BIOS variables and bank switching.
dr. apocalipsis
Banned
I'm not the one overseeing any other quotes and taking them out of context to try to show someone is saying something he isn't saying.
I'm annoyed and dissapointed at the reaction of some guy with my same hobby and interests after I corrected some inaccurate stuff from him on a discussion board. More than legit when used to a Megadrive comunity known for being extremely friendly unlike others.
So do you really think I explained, one post earlier, what would be a perfect case for DMA transfer from cartridge to VRAM (uncompressed tiles copy), and brought to this discussion that concept before anyone else to then deny, one post later, that such a thing is even possible?
Reply in all honesty, please.
DMA has its uses and its cons. You just can't use it to bypass RAM (whatever RAM) as suggested here.
Please, try not to put affirmations in any others keyboard. What I am denying is this:
Megadrive has conventional RAM and works like any other system on that regard. It has to preload stuff just like any other system before a level starts. The only difference being that with any given CD system you need to preload *more* stuff because you don't have the ease to load stuff during blanking periods as you have with cartridges. But those DMA transfers aren't as wild card as they sound, because they have severe limitations. Everytime you start a DMA transfer M68k enters into wait state, taking a performance hit, so you want to use RAM (whatever RAM) as much as possible with manual copies using CPU. Bandwidth isn't that stellar neither, just enough to load some stuff during blank periods without affecting display/gameplay if you are careful enough. Even then, you have plenty of cases of halted gameplay during DMA transfers around, like when action stops while loading a boss in several beat 'em ups. And, of course, the trademark Megadrive scratchy samples playback when poor sound drivers do nothing to prevent bus contention.
When you are displaying anything you are limited at any given moment to the tiles VRAM can hold, not whatever cartridges is storing. Then, VRAM access time is around 100~120ms, while cartridge ROM can be as high as 300ms and beyond.
To summarize: Saying you just load stuff from cartridge at will with DMA and than Megadrive doesn't have conventional RAM is fully nonsense.
There is no such a thing like audio RAM on Megadrive. Those 8kb work like a scratchpad for Z80. Z80 is pretty autonomous inside the Megadrive design and it is a general purpose CPU, not a sound one like SPC700 on SNES. It was there instead of a cheaper chip to allow backwards compatibility with Master System to start with. Then most uses it got during lifecycle were mostly afterthoughs, since it was overkill for just feeding Yamaha YM2612, but at the same time too weak to allow sound sample decompression.
This is as good time as any other to show you Stef's XGM driver sample ROM (Use any Megadrive emu or flashcart).
It uses Z80 as a software mixer for being able to playback 4 PCM @14 Khz samples simultaneously without any limitation on the FM(6 full channels or 5 channels+4PCM)+PSG (3+noise) side. For comparison, SSF2 is doing 2PCM @4.8 Khz. Having this back then would have changed the history.
blast processed
Member
Watching the floor break away after a mini boss fight in M.U.S.H.A is a cool effect.
Or the enemies coming through the clouds during a lightning storm
stan423321
Member
True. I'm not sure what exactly was going on there. What could be said instead is that a cartridge console is not as relying on RAM. However it's not due to DMAs only. A lot of things can be read directly from the cartridge at a price cost.
Which basically makes it the audio processor of MD. If we go and claim it's not audio processor since you technically can do something else with Z80, then SNES has no audio RAM either since if you really want to you can put game logic on SPC700 and pump it out through the ports. Also of note is that Saturn had a 68k as audio CPU. So you could technically run quite a few MD games' logic on it, not that anyone did this.
I'll take a look at it later. Sounds interesting.
Okay, so, this is a personal and somewhat complex web of nonsense involving a highly unstable individual I was friends and briefly FWBs with, but I can only assume there will be a never-ending clusterfuck on gaf now until the end of time, which inevitably involves you guys and gals on the mod team in some way, so I'm an open book here. The woman in question ended up being completely psychotic and held a grudge against me after a bizarre love triangle situation developed a few years ago between me, her, and another girl (the other girl I ended up in a long-term relationship with shortly thereafter). This NOLA story she apparently just put up on social media is a delusion of a deeply disturbed person who had a total psychological breakdown as a result of me and the other girl getting together, because she (phew, yeah...) became obsessively infatuated with the other girl (she's bi) on sight when the three of us met up. I wanted to just stay friends with the girl making the accusation and made it super super clear ahead of time that me and the other girl were interested in each other romantically and that could play out as such when we met up. Supposedly this was not a problem for her from accusation, but in reality she uhhh wanted me to die painfully after seeing me and the other girl interact. Plus she became infatuated with the other girl simultaneously to this (she's bi), which created the aforementioned bizarre love triangle that ended up causing her to implode and have an apparently very intense and long-lasting grudge. The whole story about how that love triangle thing played out is, frankly, nuts and scary, and involves this girl bringing us to a compound of dangerous scientology spinoff cultists on that same trip, who roofied us, attempted to recruit/scam me and attempted to abduct/rape the girl I ended up dating, in what was a fucking scary situation that resulted in me and the other girl and the rest of my friend circle never speaking to this girl from the accusation again.