It is currently Fri Oct 20, 2017 5:48 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 135 posts ]  Go to page 1, 2, 3, 4, 5 ... 9  Next
Author Message
PostPosted: Sat Aug 04, 2012 6:40 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Well, here's the deal. Not long ago, a demo for Mega Drive was released that effectively would output a high color (512 colors!) linear bitmap on screen. Pretty stable, at that, the only serious issue being that VRAM refresh cycles causes some columns to be wider. Well, also that the massive DMA eats up practically all CPU time and that it needs more memory than available in RAM, but it's still useful when put together with the Mega CD (which in fact even allows hardware-based double buffering with this method, hah). Here is the demo, if anybody cares (run on real hardware, no emulator will get this right at all).

For those curious, what the demo does is disable display and then pull off a massive DMA to the background color, which overwrites the color being shown on screen as it's being output (which results in something akin to a bitmap). Yes, this also means even the border area is affected... so you could easily output a widescreen image with this method too. That's pretty darn overkill for a 4th generation console =P

Now, the SNES is generally known as being able to output more colors, so getting something similar there should be easy, right? ...or so I thought, even reading through Nintendo docs I seem to be unable to come up with a way to do it. I really never programmed for the SNES so I'm most likely missing a lot of stuff (help filling in the gaps?), but whatever, this is what I came up with and why it wouldn't make a suitable replacement:

DMA: the most obvious trick would be to do exactly the same thing, right? Except that DMA on the SNES is limited to 64KB (as opposed to the 128KB of the Mega Drive), which means only half the amount of pixels (it may be possible to work around this by using two DMA channels, but no idea how well would that work). Moreover, it's byte-based instead of word-based, and I have no idea if CRAM entries are updated only when both bytes are overwritten or they change immediately (in the latter case you have even more issues as every half pixel would have the wrong color).

H-DMA: why not just split it into multiple DMAs and let the hardware do the synchronization for us, while we're at it? Sounds like the best thing we could do, right? Except H-DMA is limited to 1, 2 or 4 byte transfers. Definitely not what we need here. H-DMA is out of the question.

CG Direct: should have looked at this before, the SNES has its own way to output high color graphics! Up to 2048 colors with this method. Sadly, it doesn't seem to be well documented at all. How is this meant to work? Also the bottom bits of the R, G and B values are taken from the palette. Does this even have pixel granularity? We'd like to be able to manipulate all the RGB values individually in all the pixels of the image. Also VRAM usage may be an issue.

Blending: another idea was to use the blending hardware (in additive mode) to merge two colors into one and get a more colorful output. Sadly, palette limitations kick in... The only mode with a large palette (256 colors) is mode 7 which only has one tilemap (we need two) and a limited amount of tiles. The other modes offer at most 16 colors per tile, and we can only mix two layers, so that means we can get at most 256 colors... at which point mode 7 seems more useful (may be useful for YUV or YCrCb though!). Again, VRAM usage may also be an issue. I suppose that you could also try to mix mode 7 with the sprite layer... not sure how well would that work though.

I'm running out of ideas. Does anybody else know what other options would be out there? Did I get any of the technical facts wrong?


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 7:16 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Sik wrote:
DMA: the most obvious trick would be to do exactly the same thing, right? Except that DMA on the SNES is limited to 64KB (as opposed to the 128KB of the Mega Drive), which means only half the amount of pixels (it may be possible to work around this by using two DMA channels, but no idea how well would that work).

You can transfer more than 64KBytes using multiple DMA channels; e.g. for 128KBytes you could use channels 0 and 1. There are are total of 8 channels available to use. The CPU will block (wait) until all selected DMA transfers are done (register $420B selects which channels you want to initiate transfers on), and they are done in sequential order (e.g. if you picked 2 channels (0 and 1) of 64KBytes each, channel 0 would transfer first, then channel 1 would transfer next, then control would be relinquished back to the CPU).

Sik wrote:
Moreover, it's byte-based instead of word-based, and I have no idea if CRAM entries are updated only when both bytes are overwritten or they change immediately (in the latter case you have even more issues as every half pixel would have the wrong color).

See register $43x0, bits 2-0, for how the writes can be done, as well as bit 3 (which controls/refers to the data being read from the source and how). It's entirely dependent upon what/where you're writing to (see other bits for that register, as well as register $43x1); for destination increment methods available see register $2115 bits 3 through 0. Registers $2118 and $2119 in the official docs also explain what happens.

Also, there is no such term "CRAM" (this is the first time I've ever heard of it). I believe what you're trying to say is, simply, either VRAM or PPU RAM (same thing); RAM is RAM. You tell the SNES which areas of RAM you want to use for which purpose. The purposes are:

- OBJ ("OBJ Base Address"; see register $2101)
- BG SC ("background screen character", e.g. actual tile data; see registers $2107 through $210a)
- BG NB ("background name base", e.g. tile layout data; see registers $210b and $210c)
- CG (colour/palette; see register $2121)

Hope that clarifies some of the technical aspects, since the last line of your post did ask if you understood things correctly (technically).

The bottom line is this: the SNES is not intended to do "full screen graphics changes" -- by this I'm referring to things like playing back full-screen movies (every pixel changing, etc.). It just doesn't have the capabilities or CPU time to do it. From developers I know who worked at Tiburon and one who worked for Konami, this was one of (many) reasons why the Playstation product for the SNES was scrapped.

I say this up front without having checked out the demo/thing you wrote. The Genesis/Megadrive is a very, very different beast altogether.

I would say that byuu probably has some better insights as to what you may/may not be able to do with the console, so don't take my word as purely authoritative.


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 7:33 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
koitsu wrote:
You can transfer more than 64KBytes using multiple DMA channels; e.g. for 128KBytes you could use channels 0 and 1. There are are total of 8 channels available to use. The CPU will block (wait) until all selected DMA transfers are done (register $420B selects which channels you want to initiate transfers on), and they are done in sequential order (e.g. if you picked 2 channels (0 and 1) of 64KBytes each, channel 0 would transfer first, then channel 1 would transfer next, then control would be relinquished back to the CPU).

OK, so that part seems to be a non-brainer unless it breaks timing somehow... which is what I wonder since it's one of those things that can break badly by being just one cycle off =S

koitsu wrote:
Also, there is no such term "CRAM" (this is the first time I've ever heard of it).

Right, forgot that CRAM is Sega's term and Nintendo used CG (CRAM stands for Color RAM).

koitsu wrote:
The bottom line is this: the SNES is not intended to do "full screen graphics changes" -- by this I'm referring to things like playing back full-screen movies (every pixel changing, etc.). It just doesn't have the capabilities or CPU time to do it. From developers I know who worked at Tiburon and one who worked for Konami, this was one of (many) reasons why the Playstation product for the SNES was scrapped.

Nor was the Mega Drive. We're talking about abusing the hardware like crazy =P

koitsu wrote:
I say this up front without having checked out the demo/thing you wrote. The Genesis/Megadrive is a very, very different beast altogether.

Er, it isn't mine, I thought the ZIP included some README inside or something o_O' It was Oerg866's (and Jorge's, though no idea how much he contributed). I only provided the image (which has 336 colors - no, we couldn't find anything with more colors, seriously).


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 7:56 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Sik wrote:
koitsu wrote:
You can transfer more than 64KBytes using multiple DMA channels; e.g. for 128KBytes you could use channels 0 and 1. There are are total of 8 channels available to use. The CPU will block (wait) until all selected DMA transfers are done (register $420B selects which channels you want to initiate transfers on), and they are done in sequential order (e.g. if you picked 2 channels (0 and 1) of 64KBytes each, channel 0 would transfer first, then channel 1 would transfer next, then control would be relinquished back to the CPU).

OK, so that part seems to be a non-brainer unless it breaks timing somehow... which is what I wonder since it's one of those things that can break badly by being just one cycle off =S


I don't know how DMA can ""break timing"". The CPU is held/suspended while the DMA transfers happen, so it's not like your underlying 65816 program would have any idea what's going on. DMA transfers for large sums of data are by far, "cycle-count-wise" (for lack of better term), faster than a native 65816 rolled loop, unrolled loop, or using MVN/MVP opcodes.

I believe VBlank can happen in the middle of DMA, but I don't know the repercussions (I don't think there are any, at least not like the NES -- I guess it depends greatly on what B-Bus address you're writing to in the PPU). If you can find the SNES Developers Manual (send me a PM if you're interested) there is a known quirk with HDMA (not DMA) and "timing", but it's documented + known in the manual itself.

In general, maybe you could accomplish something on the SNES similar to blargg's wild-wacky-crazy-awesome-neat palette/colour demo, but I'm not sure how to get *that* degree of control over the underlying video circuitry. Writing to VRAM during HBlank, for example, I'm pretty sure you can do + get some neat effects. Possibly palette adjustments can be done in this way, thus gaining more than the stock number of colours than if you weren't to adjust things during HBlank.

I'd need byuu to chime in about now, since it's been a very long while (maybe 10 years or so) since I've worked on a SNES/SFC console and tinkered about with things to this degree. :-)


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 8:21 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
koitsu wrote:
I don't know how DMA can ""break timing"". The CPU is held/suspended while the DMA transfers happen, so it's not like your underlying 65816 program would have any idea what's going on. DMA transfers for large sums of data are by far, "cycle-count-wise" (for lack of better term), faster than a native 65816 rolled loop, unrolled loop, or using MVN/MVP opcodes.

The switch between both DMAs (since you'd need to issue two DMAs to fill the entire screen). I have no idea how many cycles it takes up for DMA to start, and this delay will happen between both DMAs and needs to be taken into account. Although I suppose it's always the same amount so it shouldn't be hard to synchronize (although since transfers are byte-based, there's the chance the second DMA may be shifted by half a pixel rather than a whole amount - good luck fixing that if it happens, maybe you'd need to somehow issue two DMAs in a row to get the delay twice).

koitsu wrote:
I believe VBlank can happen in the middle of DMA, but I don't know the repercussions

Display would be disabled, so for all we know the PPU is in a permanent VBlank state.

Another thing is that I have no idea about the refresh cycles. Remember, I mentioned the Mega Drive trick suffers from having wider columns (every 31th column has double the width, more specifically) because in those columns a VRAM refresh happens and no transfer is performed (causing the previous color to repeat). No idea why it affects all of VDP memories (CRAM and VSRAM shouldn't need refresh), but that's how it works. The SNES may suffer from the same issue, though no idea to what degree, and if it's even stable enough to work around it.


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 8:30 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Sik wrote:
The switch between both DMAs (since you'd need to issue two DMAs to fill the entire screen). I have no idea how many cycles it takes up for DMA to start, and this delay will happen between both DMAs and needs to be taken into account. Although I suppose it's always the same amount so it shouldn't be hard to synchronize (although since transfers are byte-based, there's the chance the second DMA may be shifted by half a pixel rather than a whole amount - good luck fixing that if it happens, maybe you'd need to somehow issue two DMAs in a row to get the delay twice).


You issue two DMAs (e.g. transfer of 64KBytes of data using channel 0, and 64KBytes of data using channel 1) using a single write to $420b. I don't know how long (meaning on the hardware itself, in microseconds/milliseconds or whatever) the actual DMA initialisation takes. I'm sure it would be easy enough to find out, but there may be highly technical documents out there (written from a hardware engineering point of view) that document how long it takes. The official Developers Manual may have this in it somewhere too (I believe it has it in it for HDMA, but could be wrong).

The point I'm trying to make is that you can do back-to-back transfers of data using DMA without relinquishing control back to the CPU between those two transfers -- you can do it in one single write to $420b.

If you want me to write you some example 65816 code that shows how to do it (it's very very simple, nothing magical or amazing -- just standard code) I can do so.

Sik wrote:
Display would be disabled, so for all we know the PPU is in a permanent VBlank state.


Well then not much to worry about there! :-)

Sik wrote:
Another thing is that I have no idea about the refresh cycles. Remember, I mentioned the Mega Drive trick suffers from having wider columns (every 31th column has double the width, more specifically) because in those columns a VRAM refresh happens and no transfer is performed (causing the previous color to repeat). No idea why it affects all of VDP memories (CRAM and VSRAM shouldn't need refresh), but that's how it works. The SNES may suffer from the same issue, though no idea to what degree, and if it's even stable enough to work around it.


Sorry, no idea -- what you just described to me is completely and totally over my head.


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 8:46 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
koitsu wrote:
If you want me to write you some example 65816 code that shows how to do it (it's very very simple, nothing magical or amazing -- just standard code) I can do so.

Nah, I was talking about the time it takes for the PPU in itself to start the DMA (since I assume it does the initialization for each of the DMA channels). Although the PPU is always in sync with itself (d'oh) so it's probably a nobrainer unless it turns out it takes too long to be usable (but then we'd have some serious issues there overall, DMA init shouldn't take that long...).

Which reminds me, there also needs to be a way to synchronize the 65816 with the PPU, and more specifically, to a given position in screen. The 65816 running at different clock speeds depending on which address range it access doesn't make things any easier, we'd need to mess with all of them while trying to look for the timing.

On the Mega Drive synchronization is done by turning on display, overflowing the FIFO in active scan (so the VDP forces the 68000 to halt - this is where both get in sync), then turning off display and starting the DMA. Is it possible to do something similar with the 65816 and the PPU?


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 9:10 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Sik wrote:
Nah, I was talking about the time it takes for the PPU in itself to start the DMA (since I assume it does the initialization for each of the DMA channels). Although the PPU is always in sync with itself (d'oh) so it's probably a nobrainer unless it turns out it takes too long to be usable (but then we'd have some serious issues there overall, DMA init shouldn't take that long...).


DMA capability previously discussed is either done within the physical CPU (e.g. some extension/capability Sony added to the chip) itself or a separate chip on the mainboard somewhere. It is definitely not done within the PPU.

Per the official developers documentation:

* NOTE: If 2 or more channel are designated, the DMA transfer will be performed continuously according to the priority order described on page B-1. The CPU will also stop operation until all general purpose DMAs are completed.

* Page B-1 shows that channel 0 has higher priority than channel 1, channel 1 has higher priority than channel 2, etc... all the way down to channel 7.

* Page B-1 also shows that DMA being done between the CPU (A-BUS) and VRAM (B-BUS) should be done during VBlank (or, obviously, when the screen is off). HDMA, on the other hand, can be done per-scanline between the CPU and VRAM.

* Section 25.1 documents the known issue (mentioned previously in my post) with HDMA vs. DMA timing and discloses some timing variables, also citing that "a real time trace function of the ICE can be utilised to confirm timing problems". Apparently, at least with HDMA, one horizontal line takes 63.5 microseconds, and an increment of the H-count timer (HTIME; see below) equates to 0.186 microseconds.

* Table 2-17-1 indicates in a footnote that "in the case of a screen with 224 scanline resolution, general purpose DMA can transfer 6KBytes of data maximum in the VBlank period".

So there's no official statement (from what I can discern) how long things take, but you can get a general idea. I'm sure someone with some kind of hardware analyser could figure it out for certain.

Sik wrote:
Which reminds me, there also needs to be a way to synchronize the 65816 with the PPU, and more specifically, to a given position in screen. The 65816 running at different clock speeds depending on which address range it access doesn't make things any easier, we'd need to mess with all of them while trying to look for the timing.


I'm not sure what you mean by "to a given position in screen". Are you requesting that the SFC/SNES have some way to get X/Y coordinates of the electron gun while the PPU + video hardware draws pixels?

The options as I see them are:

1. Use of HDMA, which won't give you locations of things, but does guarantee during which HBlank scanline you'll be doing PPU modifications.
2. Register $2137 (SLHV) can be used as a "software latch" for H/V location per the correlating $213c (OPHCT / Horizontal) and $213d (OPVCT / Vertical) registers. Both latter registers are dual-read and return 9 bits of data. You have to read $213f (STAT78) to "reset" the latch registers to make sure you get the correct low byte/high byte (bit) values from $213c/$213d.
3. Registers $4207 and $4208 (HTIME; horizontal), and $4209 and $420a (VTIME; vertical). These can be used to generate an IRQ when the electron gun is at specific horizontal and vertical locations.
4. Cycle counting (known to have been used in games like Chrono Trigger).

Sik wrote:
On the Mega Drive synchronization is done by turning on display, overflowing the FIFO in active scan (so the VDP forces the 68000 to halt - this is where both get in sync), then turning off display and starting the DMA. Is it possible to do something similar with the 65816 and the PPU?


See above for your options, unless byuu knows of others.


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 9:14 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
What about changing the palette each scanline? It worked on the Game Boy Color. But I'm not as familiar with the SNES's architecture, so I don't know if that works there too.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 9:15 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Dwedit wrote:
What about changing the palette each scanline? It worked on the Game Boy Color. But I'm not as familiar with the SNES's architecture, so I don't know if that works there too.


Yes, I believe that's doable (*especially* with HDMA -- that's partially what it's for!), but for whatever reason Sik is looking at things from a different perspective (mainly from a "comparison to the MegaDrive/Genesis" viewpoint). The two consoles are significantly different, thus accomplishing Fun Thing X on the MegaDrive is very different than on the SFC/SNES.


Top
 Profile  
 
PostPosted: Sat Aug 04, 2012 9:28 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
koitsu wrote:
DMA capability previously discussed is either done within the physical CPU (e.g. some extension/capability Sony added to the chip) itself or a separate chip on the mainboard somewhere. It is definitely not done within the PPU.

Is this not mentioned anywhere in the docs? Is this done by the bus controller, by any chance? (also H-DMA implies the PPU is involved somehow, since only the PPU knows when a line starts)

koitsu wrote:
I'm not sure what you mean by "to a given position in screen". Are you requesting that the SFC/SNES have some way to get X/Y coordinates of the electron gun while the PPU + video hardware draws pixels?

That can be useful, but I'm not necessarily talking about that - I was talking about getting the 65816 and the PPU in sync when the beam hits exactly a specific position of the screen. It's the only feasible way to do the DMA trick - otherwise we'll have to resort to other methods.

koitsu wrote:
Yes, I believe that's doable (*especially* with HDMA -- that's partially what it's for!), but for whatever reason Sik is looking at things from a different perspective (mainly from a "comparison to the MegaDrive/Genesis" viewpoint). The two consoles are significantly different, thus accomplishing Fun Thing X on the MegaDrive is very different than on the SFC/SNES.

It's that I find it pathetic that the one console known for sucking at color count badly can pull off an image with this amount of color precision but the SNES can't. There must be some way to get a similar effect on the SNES (be it the same approach or not).

Also the documentation implies that HDMA is limited in the amount of data you can transfer... I repeat, it's 1, 2 or 4 bytes per line, we're looking at transferring many more if we go the DMA route.


Top
 Profile  
 
PostPosted: Sun Aug 05, 2012 1:05 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7231
Location: Chexbres, VD, Switzerland
What are you talking about ?
The SNES' mode 3, 4 and 7 can have 256 colour BG. The palette is 256 colours anyways so you can only have more by changing the palette midframe with HDMA, which is possible, as Secret of Mana does it.

But can you really see the difference between a 256 colour image and 512 colour ? I think you wouldn't note any differences.


Top
 Profile  
 
PostPosted: Sun Aug 05, 2012 2:17 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Bregalad wrote:
What are you talking about ?
The SNES' mode 3, 4 and 7 can have 256 colour BG. The palette is 256 colours anyways so you can only have more by changing the palette midframe with HDMA, which is possible, as Secret of Mana does it.

Wait, so it isn't just mode 7? Then the blending idea would work because there's quite a large amount of colors to use - enough to give us some reasonable amount of precision per component. Then the issue would be to see if there's enough VRAM to hold it all XD (otherwise we'd have to resort to something that isn't fullscreen)

Bregalad wrote:
But can you really see the difference between a 256 colour image and 512 colour ? I think you wouldn't note any differences.

Why are we using higher color depths these days? =P Well, that, and the ability to manipulate each individual color of the RGB component individually, which can help with some stuff. And really... just a way to prove it can be done on the SNES >_>

Also I swear, Nintendo's docs are a complete disaster when it comes to organization. It's nearly impossible to find what I'm looking unless I already know where it is.


Top
 Profile  
 
PostPosted: Sun Aug 05, 2012 2:52 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7231
Location: Chexbres, VD, Switzerland
Quote:
Then the issue would be to see if there's enough VRAM to hold it all XD (otherwise we'd have to resort to something that isn't fullscreen)

In mode 7, you only have 256 tiles, and only the first 32k half of the VRAM is used, so no full-screen without repeated tiles.

However with mode 3 or 4 you have 1024 tiles, and if all of them are defined it takes exactly the entiere 64k VRAM. Therefore you'll have to reserve at least 1024 bytes for the map, but then 63k of RAM, or 1008 tiles. Because at most "only" 32x30 = 960 tiles are visible on the screen, it is possible to make a full-screen image in 256 colours without even resorting to any "dirty tricks".

Quote:
Why are we using higher color depths these days?

You're confusing the number of colours available (the depth of the palette) and the number of colours used at a time (the size of the palette).
If you take a high resolution image, and save it as a 256 colour BMP (3, 3, 2 bit RGB) chances are you'll immediately note a huge loss of quality.

However if you reduce the number of colours to 256 and save it as PNG, chances are you won't notice a difference, or a very slight one, especially if dithering is used.

Quote:
Also I swear, Nintendo's docs are a complete disaster when it comes to organization. It's nearly impossible to find what I'm looking unless I already know where it is.

Why not use Anomie's docs then ?


Top
 Profile  
 
PostPosted: Sun Aug 05, 2012 3:08 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Bregalad wrote:
However with mode 3 or 4 you have 1024 tiles, and if all of them are defined it takes exactly the entiere 64k VRAM. Therefore you'll have to reserve at least 1024 bytes for the map, but then 63k of RAM, or 1008 tiles. Because at most "only" 32x30 = 960 tiles are visible on the screen, it is possible to make a full-screen image in 256 colours without even resorting to any "dirty tricks".

The problem is that with the blending method (which is what we'd be using there) we need to use two tilemaps, so we'd need to store double the amount of tiles (assuming we don't repeat anything), meaning that in practice only half the screen can be filled that way =/ (also I don't care if the second tilemap has less colors, because we could just put two of the RGB components into the 256 colors tilemap and the other component in the other tilemap and still get a decent amount of colors).

Maybe some way to work around it? Just thinking, since the Mega Drive demo has pixels that are double the width as usual (so it'd be only fair to let the SNES do that too for this idea if needed), could we use mosaic mode to skip every other horizontal pixel? Then we'd need to store only half the amount of pixels in each tile. Then what can we do is fill the top half with all 960 tiles, then reuse those tiles in the bottom half but scroll the tilemaps horizontally by 1 in that area (so the remaining pixels are shown instead). Dunno if it's understandable what I'm trying to say.

On that note: the Mega Drive in NTSC mode can only show 224 lines (28 tiles vertically), so I guess it's fair game to just do 32×28 tiles and still claim it's fullscreen with the SNES.

Bregalad wrote:
Why not use Anomie's docs then ?

Because Nintendo's docs are what I have here right now >_>

EDIT: it seems mosaic mode must have the same value both horizontally and vertically... *sigh* So that'd make 2×2 pixels, not 2×1 pixels. It'd be worse than what we had before, but it's an improvement I guess. I suppose we could use H-DMA and change the vertical scroll every line to work around this?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 135 posts ]  Go to page 1, 2, 3, 4, 5 ... 9  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 10 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group