I really don't know what do you mean here. If you have some info about IRQ7 not working on a DS (or on a 3DS) or not being triggered by SIO/RTC ... please share them with us. Thanks.
I really don't know what do you mean here. If you have some info about IRQ7 not working on a DS (or on a 3DS) or not being triggered by SIO/RTC ... please share them with us. Thanks.
Well, actually it really works correctly, also on hardware (well, at least on my NDS Lite).
The libnds configures the RTC so that it generates a steady 1Hz interrupt on ARM7' IRQ7, and it uses it to keep the time going (all that happens on the ARM7 side)
So maybe it doesn't work on 3DS?
Try that using the 'RealTimeClock' nds example.
The libnds configures the RTC so that it generates a steady 1Hz interrupt on ARM7' IRQ7, and it uses it to keep the time going (all that happens on the ARM7 side)
So maybe it doesn't work on 3DS?
Try that using the 'RealTimeClock' nds example.
I have tried that example, the clock doesn't update. Nothing that relies on IRQ7 going off seems to work on the 3DS.
That's interesting. I'll report a bug to the libnds guys. Thanks!
edit: BTW you could comment out the call to initClockIRQ() in your ARM7 code and add a counter in the VBlank handler (again on ARM7 code, of course), incrementing the time every 60 frames. This way the same code should work on both NDS and 3DS.
That's interesting. I'll report a bug to the libnds guys. Thanks!
edit: BTW you could comment out the call to initClockIRQ() in your ARM7 code and add a counter in the VBlank handler (again on ARM7 code, of course), incrementing the time every 60 frames. This way the same code should work on both NDS and 3DS.
That's right. In this way that file manager's clock is also fine now... Thank you for the idea, windwakr and sverx.
Vblank isn't exactly 60 frames per second, so the time would slowly become inaccurate this way. I'll just go ahead and merge windwakr's solution.That's interesting. I'll report a bug to the libnds guys. Thanks!
edit: BTW you could comment out the call to initClockIRQ() in your ARM7 code and add a counter in the VBlank handler (again on ARM7 code, of course), incrementing the time every 60 frames. This way the same code should work on both NDS and 3DS.
Inaccuracy is around 0,5%, so there will be approx. 1 second error every 200 seconds (3 minutes and 20 secs). If you think this isn't anyway accurate enough, you could change the ARM7 code so that is reads the RTC each VBlank... this would be very accurate and should work on 3DS too.
Just a curiosity...
Which emulator is more energy efficient ..Lameboy or GameYob? ...maybe the code in Gameyob (or in the newgfx version) is cleaner, and it would use less battery overall ...or the difference would be irrelevant?
Which emulator is more energy efficient ..Lameboy or GameYob? ...maybe the code in Gameyob (or in the newgfx version) is cleaner, and it would use less battery overall ...or the difference would be irrelevant?
Both will push the CPU to its limits and both have bottom screen turn off, so the difference should be negligible.
Last I checked the DS's clock rate is non-variable. The only power differences are when powering physical carts.
Putting the ARM9 to sleep until an interrupt is more energy-efficient, in addition to the savings caused by using a more energy-efficient cart. If the processing is done faster for a Game Boy frame, the ARM9 sleeps longer.
I've got borders down - both sgb borders and arbitrary borders. Right now it's reading the file "border.bmp" in the root directory as a border. It needs to be a 256x192, uncompressed, 15-bpp bitmap. No limit on colours. This is the border I was testing with.
I don't understand the last part of what you said - the whole point is that the RTC is broken, so where do I read it from...? Anyway a small error is acceptable, but since I still have a few spare timers, I might as well go with the more accurate method.
In theory since GameYob is running faster than Lameboy, it is "sleeping" a larger percentage of the time, thus saving more power. But I don't think there's a major difference.
Would be cool if it was possible to keep the custom borders even after resizing (when keeping the aspect ratio ...not the full screen obviously).
I don't know if you already implemented it though..
I don't know if you already implemented it though..
I don't have a 3DS so I might be wrong, but it seems to me the problem isn't reading the RTC but having it call the IRQ7 once a second, to increment the unixtime variable without having to read again RTC. So the question is: the clock in GameYob is correct on a 3DS when you start it? If it's so, it means there's no problem in reading the RTC.
Here's some things I noticed on the newest version. On SGB mode prefer GBC isn't working, when I turn off borders I'm getting an off white background, when I use a custom boarder I'm getting some banding though the boarder. If I want to use GBC palates I have to turn off SGB and I can't use the SGB borders. It would be super cool to be able to use the GBC palates and SBG borders together. You are probably already aware of this stuff but anyways I'm totally in love with this version
- I've never had a problem with "prefer GBC". Note that "GBC Mode" should be "On" for this to work. The result is that games compatible with both sgb and gbc will default to gbc.
- Can you post a picture of the "banding"? And if you're not using my border, can you link to the border you're using?
- Since the SGB and GBC are 2 completely separate kinds of gameboys, using sgb borders on gbc games requires some hax. It's possible in most cases (goomba does it) but I haven't gotten around to it.
Actually this is implemented in the non-scaling branch. (newgfx is getting really far behind now...) When I do it in the scaling branch it will scale along with the game itself.
Ah, that sounds right. I don't have a 3ds either but from what I've heard, the time is correct at the start. Thanks for clearing that up.I don't have a 3DS so I might be wrong, but it seems to me the problem isn't reading the RTC but having it call the IRQ7 once a second, to increment the unixtime variable without having to read again RTC. So the question is: the clock in GameYob is correct on a 3DS when you start it? If it's so, it means there's no problem in reading the RTC.
How do I use the show image button so this can be minimized? Here's the banding I was taking about. It's pretty faint. This slight banding doesn't happen with the SGB backgrounds. I'm on an XL so that might have something to do with it. Prefer GBC is still not working for me. I'm using a DSTWO and GBC mode is on.
Hmm, I don't know what could be causing that, there isn't any noticeable banding on my dsi... about GBC mode, note that Megaman V doesn't support the gbc. If you put a non-gbc game in a gameboy color the bios adds its custom palette - that's what it's doing with Megaman V. In this case, super gameboy mode will kick in even if set to "Prefer GBC". Games which truly support both the super gameboy and the gameboy color include Link's Awakening DX, Pokemon Trading Card Game, Pokemon Gold/Silver, and Dragon Warrior 1&2.
Edit: Is the 3ds scaling the image? Does the banding occur when scaling is disabled with the START+SELECT combination?
Similar threads
