don't click here

Quick question

Discussion in 'Engineering & Reverse Engineering' started by Cinossu, Dec 28, 2005.

Thread Status:
Not open for further replies.
  1. LocalH

    LocalH

    roxoring your soxors Tech Member
    Going purely by the specs, the CRAM is made up of 64 9-bit words, and since each color is made up of three components of three bits each, it would seem to me that the low bit simply wouldn't be there to read back. I haven't tested it on hardware, however, so I don't know for sure.

    As for that high nybble, I'm not sure either. As far as the values stored in CRAM, same as with the low bit - by the spec, since the color words are 9-bit, I don't think that they exist. I haven't tested this either.

    I'll try to write some test code in the next few days and see exactly what happens when you write to those unused bits and then re-read them. Charles MacDonald's doc only talks about the CRAM address lines and how all but bits 6-1 are ignored (CRAM access is of course word-wide).
     
  2. Sonic Hachelle-Bee

    Sonic Hachelle-Bee

    Taking a Sand Shower Tech Member
    806
    200
    43
    Lyon, France
    Sonic 2 Long Version
    You are wrong. I have done that in Sonic 2 Daytimes to do my fade pallet effect. Remember, it was the last Summer. It was working extremely fine as far as I can tell. The subroutine needed some optimizations, it's done since October.

    No, that's not the case. Lost Wood zone already use ALL the available size for the background. Chemical Plant, Oil Ocean and Mystic Cave have several Y lines of 128x128 tiles (but X wrapping, that's right), and they use "ripple effects". And sometimes, your background don't need the whole size to look nice. Wrapping is more than enough, and most Sonic levels use wrapping.

    ? My effects are already done LOst, and that's not a failure. Maybe we aren't talking about the same effects... I have tested that with the most accurrate emulator that I have, very close to real hardware (unlike Gens and others). It works fine for now. Obviously, I will not try to do better than Sonic 3 backgrounds, but I try at least to do the same. At the "raster effects" subroutine (Sonic 2), there is a huge RTS: my own subroutine handle all these calculations in RAM ($A800 and $E000), as fast as possible, and the Sonic Engine do the rest. Simple enough.

    LOst, I know we aren't working the same way, but don't be afraid to forget a bit the original program sometimes, and don't be afraid too, to use it when you really need it. Backgrounds (as the foreground) are very easy to control, but the "raster effects" subroutine in Sonic games makes them hard to understand, because they are very level specific. Most of these calculations aren't needed at all to make a basic background. And obviously, I'm not going to remake the work about how to display the result on screen, the game contains already some nice routines to do that just fine. I'm making a playable game after all, certainly not a hacked program that only his author is fool enough to understand and see the difference.
     
  3. Qjimbo

    Qjimbo

    Your friendly neighbourhood lemming. Oldbie
    Oooo this information could be handy, I'm planning to make an MP3 tool plugin for Gens+ that can read a varaible from ram to control the music, making it more flexible for hackers. Though not everyone approves of mp3 tool in hacks I know :P
     
  4. Mask of Destiny

    Mask of Destiny

    Tech Member
    87
    0
    6
    Beware. Even the most accurate Genesis emulator (probably Kega Fusion at the moment) is not designed to make things break that break on real hardware only to make things that work on real hardware work.

    For instance storing data in the upper nibble of CRAM will probably not work on the real hardware; however, it's much easier for an emulator writer to make CRAM a full 16-bit and since no games depend on the 9-bit behavior laziness wins the day.

    Raster FX timing is very nasty. You've only got a few cycles to get everything done or else you end up with nasty side effects. These side effects tend not to be emulated for the same reasons as the 9-bit CRAM thing.
     
  5. drx

    drx

    mfw Researcher
    2,254
    350
    63
    :rolleyes:
    I wrote an emu, which emulated those bad things. Shame I lost the source =/
     
  6. Dr. D'nar

    Dr. D'nar

    I wouldn't trust me if I were you Member
    Self Modifing Code (SMC) has been comon practice on TI-83+ series calculators. Of course, it's a Z80 chip and there's nothing import to fuck up, but still, it's worked for like decade now.
     
  7. Sonic Hachelle-Bee

    Sonic Hachelle-Bee

    Taking a Sand Shower Tech Member
    806
    200
    43
    Lyon, France
    Sonic 2 Long Version
    Not the upper nybble of CRAM, but the upper nybble of what's in the RAM. That's a small difference. Anyway, I will verify with LocalH if my cycling pallets work again...

    I know that this has to be fast enough. Do you really think that I haven't looked at what's already programmed in the ROM? Basically, there is nothing more than $E0 long moves to RAM (one for each line on screen, one word for foreground and one for background), which is slow already. This is even slower when you have "16 lines" blocks defined, because of the subroutine at $D69E, and it's used by most levels in Sonic 2. The "fastest" background is Metropolis zone background, but you can do even faster with wrapping. Now, instead of always moving the negation of the "foreground camera ($EE00)" $E0 times in RAM, you can do a very small calculation before some moves (addq or subq for example), like the upper part of EHZ background, and with the appropriate lines of code (no loop for example), this might be fast enough, huh?... :)

    EDIT: Speaking of "fast enough", take a look at the "raster effect" for 2p mode in MCZ...
     
  8. LocalH

    LocalH

    roxoring your soxors Tech Member
    Do you still have the binary? =P
     
  9. drx

    drx

    mfw Researcher
    2,254
    350
    63
    :rolleyes:
  10. Mask of Destiny

    Mask of Destiny

    Tech Member
    87
    0
    6
    I believe we're talking about the same thing here. Anyway since CRAM isn't a separate RAM chip and is instead a part of the VDP I suspect that the unused bits aren't actually stored to save on transistors. Unless you're talking about a copy of the pallete data living in Genesis work RAM (I.e. the RAM from FF0000 to FFFFFF).

    You've lost me here. Apart from split-screen mode, what does level wrapping have to do with HBlank routines? Even if you're doing some kind of ripple effect, you'd probably just want to use the line scroll mode of the VDP rather than mucking with the scroll values each HBlank. Or are you actually talking about a VBlank routine here? To clarify VBlank occurs once per frame inbetween each frame and is relatively long. HBlank occurs once per line and is barely long enough to swap a few pallete entries.

    Split screen is an easy HBlank effect. Particularly since you can usually get away with turning off the display for a couple of lines. Rewrite the horizontal and vertical scroll values, maybe change the sprite list pointer and you're done. It's a bit messier if you actually need to DMA tiles, but if you can afford to turn off the display for a few lines it's not hard to get away with.

    The bigger problem is you now have to effectively calculate two frames of data in the same time it took to calculate just one in normal mode.
     
  11. Sonic Hachelle-Bee

    Sonic Hachelle-Bee

    Taking a Sand Shower Tech Member
    806
    200
    43
    Lyon, France
    Sonic 2 Long Version
    Yes, the topic is about unused space in RAM for Sonic 2...
    You probably know that the pallets are stored in RAM at $FFFB00 and $FFF080 (underwater).
    I guess these same pallets are loaded in CRAM, each frame, by a routine.

    Now, I'm lost too. Nevermind. =P
    Okay, I confused some things. I don't need HBlank to make my background effects. I can see why LOst wrote something about background wrapping, but now, I can't understand why LOst wrote something about HBlank and my effects, while I was writing about level layouts...

    That's true.
     
  12. LOst

    LOst

    Tech Member
    4,891
    8
    18
    Guess? You should know by now that the Vblank routines word copy $FB00 to CRAM using DMA. As well as you should know the same routines copy the scroll table at $E000, as well as SAT at $F800 into VRAM using DMA.

    I thought you knew so much you had jumped on the Hblank train. I was wrong.
     
  13. Quickman

    Quickman

    be attitude for gains Tech Member
    5,595
    18
    18
    :x
    omg porjcet
    I'm assuming DMA is faster than any alternative methods?
     
  14. Ultima

    Ultima

    Games Publisher Tech Member
    2,398
    1
    18
    London, England
    Publishing mobile games!
    DMA's as fast as you can get for data trasnfer. Well, there may be exceptions for very small amounts of data due to overhead (at least on the GBA there is).
     
  15. Sonic Hachelle-Bee

    Sonic Hachelle-Bee

    Taking a Sand Shower Tech Member
    806
    200
    43
    Lyon, France
    Sonic 2 Long Version
    Not "guess", I "know a part" of it.
    What's amazing here is that you wrote something about HBlank: see, it's really worthless for me and my project, and for about all hackers here, to try to understand fully and work directly with the HBlank. These VBlank routines (and you know that) are more than enough to make what I need for backgrounds and others effects. Once again LOst, it's a game I'm making. If something is worthless for it, I'm not going to research on it: I have no time to spend, and I'm certainly not (and I certainly don't want to become) the "ASM Hacking God" that you think. Once again, besides the ASM programming, I have to do the work of several artists, to make graphics, level layouts, mappings... etc. This was their almost full time job, this is what I'm doing alone when I have free time. This represents more than half of the work, and unfortunately for you, it seems this is a domain you don't know quite right, by not having any small experience: knowing how things works internally is one thing, applying that to a real and fully playable game, making this game fun to play and original, is really another...

    These times, and you can't say at all I'm wrong, you seem to constantly trying to stop me and my project, trying to make my knowledge looks ridiculous compared to yours, ruining a cool and interesting topic. Are you afraid of something? I'm not afraid of you, LOst. Be sure of one thing, I will finish what I'm doing. And even if it's not the way YOU would have done that, I really don't care! Thank you.

    </offtopic>
     
  16. Ultima

    Ultima

    Games Publisher Tech Member
    2,398
    1
    18
    London, England
    Publishing mobile games!
    Handbags away plz
     
  17. Hivebrain

    Hivebrain

    Administrator
    3,047
    154
    43
    53.4N, 1.5W
    Github
    [​IMG]
     
  18. Sonic Hachelle-Bee

    Sonic Hachelle-Bee

    Taking a Sand Shower Tech Member
    806
    200
    43
    Lyon, France
    Sonic 2 Long Version
    I have saw a lot of wierd things and jokes before on this forum, but for this one, I can't see... :blink:

    Well... Case closed I guess.
     
  19. Cinossu

    Cinossu

    Administrator
    2,832
    44
    28
    London, UK
    Sonic the Hedgehog Extended Edition
    .. um, wow. I only wanted around 4 bytes to store a few values, guys.. XD; Thanks for all the extra info though..
     
  20. LOst

    LOst

    Tech Member
    4,891
    8
    18
    You got me wrong. I am not after killing your hack or your dreams. After what you have siad the last year, I had the impression that you were doing something big. I was frightened since I didn't know what you were doing. I am not scared anymore. I know where you stand, and I know what you know and can handle. I will look forward to your hack now. You don't need to be worried.

    As for ruining Cinossu thread, I don't see how. If I did, then, Cinossu, I am sorry.
     
Thread Status:
Not open for further replies.