Omnimaga
Omnimaga => Completed => Our Projects => TI-Boy SE - Game Boy Emulator For TI-83+SE/84 => Topic started by: calc84maniac on February 09, 2014, 10:43:52 am
-
Now that a CSE-compatible Wabbitemu came out (thanks Buckeye!) I continued working on the ROM-based TI-Boy CSE implementation (by ROM-based I mean I built it as a TI-84+CSE rom image) and finished off the (unscaled) graphics. Then DrDnar supplied me with a flash unlock exploit so I was able to port over the setup/teardown code from TI-Boy Beta, and I'm surprised to say I can actually run it on my TI-84+CSE!
There are still a few issues with this, like it doesn't properly handle the CSE-specific data on the extra RAM pages yet, so there's probably some corruption going on. I also need to put in a proper splash/loading screen and a better exit screen, plus port over Makeapp and modify my paging code accordingly.
As far as performance goes, it's certainly not as fast as the latest TI-Boy SE Beta, but I'd say it's still playable, perhaps on the level of TI-Boy SE Alpha. Unfortunately there's not much I can do about that, without some sort of crazy dynamic recompilation or something (maybe I'll actually implement that one of these days, but I'd rather put out something that works first).
Sadly, it's not likely that I'll be supporting audio in TI-Boy CSE, because it won't play well with my optimized graphics code. But you never know, I also said that for TI-Boy SE Beta, and I proved myself wrong on that. Here's hoping!
-
:o It is amazing ! I think you were expecting this, but I can't wait :P
-
Let's go TI-Boy!
This looks great. Can't wait to see more in the future!
-
Wow I am amazed that you could pull this off. Good job. :D
-
This is looking amazing!
Great job! :thumbsup:
-
calc84maniac, you son of a beep. How could you torment me by hiding this for so long?
Of course any form of working Game Boy emulator is, by default, fantastic. Nobody else can do the amazing stuff you do. But to nitpick already:
- How intelligent is display updating? Does it employ any time-saving shortcuts, like avoiding redrawing sprites (or rows of sprites) that haven't changed?
- Does it support palette swaps, à la Pokemon Red/Blue?
- Will you ever add all the other cool features I pestered you endlessly about for the old TI-Boy to either version? Savestates and a GameShark-like governor come to mind.
- EDIT: Pokemon wait state fix?
-
You don't even know how long I've been waiting for that.
And I realize that I wrote that post before giving you a +1.
-
Btw, do you think you'll be able to use 160x240 mode with the ability to scroll the LCD around? The GB screen is 160x144 pixels, so at 160x120, a bunch of rows of pixels would be missing and in order to achieve much speed you would need to only use every two row of the calc pixels, but it would make the GB screen much larger and easier to see (you could allow the user to scroll up and down to see the missing portion of the screen).
-
I believe a full-screen, 320x240 mode is planned for development. He will try to support stretching the screen to completely fit, so 2x horizontal scaling and 1.66x vertical scaling (probably without any interpolation). I guess a clipped mode with 2x vertical scaling is also possible, but I don't think he's as interested in supporting that, at least not yet, as one of the nice benefits of the larger screen was ditching the screen scrolling code that TI-Boy for monochrome calcs needed.
-
That is incredible. Keep up the good work!
-
Hey, nice to see you've managed to get this running. It's an awesome accomplishment. I really wasn't sure how well this was/is going to work out. Since it's you though, I won't be surprised if you somehow manage to squeeze some more performance out of it, being the Z80 wizard you are. :P
-
The I exploit I provided is just the one BrandonW initially gave me last spring; I didn't write it. It has the deficiency that it only works on boot code 4.0 (it depends on the exact placement of certain code), albeit with the upshot that never references any OS code. You should ask BrandonW (or perhaps thepenguin) for a better one.
-
The I exploit I provided is just the one BrandonW initially gave me last spring; I didn't write it. It has the deficiency that it only works on boot code 4.0 (it depends on the exact placement of certain code), albeit with the upshot that never references any OS code. You should ask BrandonW (or perhaps thepenguin) for a better one.
Well, either way it should probably be boot-code based (or at least not reference ROM pages 0-3, which are destroyed during TI-Boy execution).
-
Will custom palettes or Super Gameboy palettes be supported? Also I recall that some late GB games had colors assigned to them so that when you play them on a GBC they use the proper colors. Will such feature be supported?
-
Will custom palettes or Super Gameboy palettes be supported? Also I recall that some late GB games had colors assigned to them so that when you play them on a GBC they use the proper colors. Will such feature be supported?
SGB is not likely, but I am planning on supporting various colorization palettes like on the GBC. I'm not sure if I'll do auto-colorization, but it could be possible on a game-by-game basis (some games were hardcoded into the GBC bootstrap code to use certain palettes).
-
Ok cool to hear. Good luck :D
-
So, a small progress update. Since the first post, I've made the following changes/additions:
- Changed: App is now built with makeapp
- Changed: cmdPixelShadow is now saved/restored, home screen is redrawn properly on exit
- Changed: Exit sequence now draws the homescreen at the very start (minus the status bar)
- Changed: Crash recovery now seems to actually work properly. It also no longer requires pressing ON twice.
- Added: Power-saving mode (CLEAR button)
- Added: Backlight control (* and / buttons)
- Added: Changeable color palettes (the 12 palettes available on the GBC for GB games)
- Added: Zoomed-in mode (scales horizontally only, still need to implement vertical scaling)
Now I suppose the main things I need to do before a public release are:
- Add some sort of splash/loading screen
- Port my "release-build" makeapp which uses librabbitsign and has no external dependencies
- Make a readme!
At some point, I'd like to add proper fullscreen scaling, but that would probably cause too much delay if I want to get this released soon. I think at first I'll release only on the forums, anyway, so I can work out any unforeseen issues.
-
Nice job on the progress. Has any research been done into the late-era Game Boy games that try to provide their own limited form of palette color data (of course we're talking about Pokemon)? It's entirely possible that the palettization they do only looks simple and is in fact much more complicated under the hood, but I'm pretty sure that a large portion of TI-Boy users use it to play that (especially now with the guaranteed ROM and RAM space).
If you're not that interested in researching it to support it, I could offer to try.
-
Nice job on the progress. Has any research been done into the late-era Game Boy games that try to provide their own limited form of palette color data (of course we're talking about Pokemon)? It's entirely possible that the palettization they do only looks simple and is in fact much more complicated under the hood, but I'm pretty sure that a large portion of TI-Boy users use it to play that (especially now with the guaranteed ROM and RAM space).
If you're not that interested in researching it to support it, I could offer to try.
Actually, how it works is that there is a list of games hardcoded into the GBC boot code (or rather, checksums of the names of those games), which indexes a list of predefined palettes. I think I may try to replicate this behavior, but perhaps not for the first release (it would require a good bit of reverse engineering).
-
Nice to hear. Btw for vertical zoom, will you just draw every 2 row of pixel like this to save speed? Not sure how this would look like on the CSE, but on the HP Prime it actually looks fine.
-
Nice to hear. Btw for vertical zoom, will you just draw every 2 row of pixel like this to save speed? Not sure how this would look like on the CSE, but on the HP Prime it actually looks fine.
You mean leaving rows blank? I suppose that could be possible, but keep in mind that the image will be scaled by something less than 2x, so it won't be evenly spaced and might not look great. Another thing is that I'm using the window wrapping to move from line to line after outputting each set of 8 pixels from a tile, so it's a choice between outputting the same 8 pixels again (which doesn't have much overhead with my rendering algorithm) or manually changing the position to output after each 8 pixels (which perhaps takes the same amount of effort as outputting 3-4 pixels as a rough estimate).
-
Oh right I forgot you didn't plan to add scrolling. It would actually have only worked with scrolling. My bad x.x
-
It's getting closer...!
-
Nice to see that TI-Boy is coming to the CSE. :) Thou, Sir, art awesome./me draws hat
-
That new splash screen looks really great! :D
-
Looks really cool! But are you going to keep the top status bar and/or make the splash screen in color? Also, it would be cool if while you are playing, since it isn't full screen, it could show like a little Game boy shell? Just some ideas. Oh, and would Pokemon Gold and Silver be in color? Because they work on the Game boy, but they are in color.
-
Also, it would be cool if while you are playing, since it isn't full screen, it could show like a little Game boy shell?
You can't see it, but behind the scenes, the 80 pixels of black on left and right sides of the game window (160 in total) are used as a buffer to render the next frame to. So the full horizontal width of the screen is actually used up already. The black parts directly above and below the game (each 160x48) are available for use, though, so that's possibly worth considering. Although I'm really waiting for the fullscreen emulation mode which, while a bit slower, won't have any black space anywhere. :P
Oh, and would Pokemon Gold and Silver be in color? Because they work on the Game boy, but they are in color.
Those are Game Boy Color games. The Game Boy color is not supported for emulation due to a number of increased technical difficulties in emulating it.
-
Oh, and would Pokemon Gold and Silver be in color? Because they work on the Game boy, but they are in color.
Those are Game Boy Color games. The Game Boy color is not supported for emulation due to a number of increased technical difficulties in emulating it.
Correction: Those games ARE Gameboy games. They were released right when the Gameboy Color was first released and so retained backwards compatibality with the Gameboy. I can prove this because I have a Gameboy original that can play Pokemon Silver. When run on a Gameboy, it simply uses monochrome textures.
-
Oh, and would Pokemon Gold and Silver be in color? Because they work on the Game boy, but they are in color.
Those are Game Boy Color games. The Game Boy color is not supported for emulation due to a number of increased technical difficulties in emulating it.
Correction: Those games ARE Gameboy games. They were released right when the Gameboy Color was first released and so retained backwards compatibality with the Gameboy. I can prove this because I have a Gameboy original that can play Pokemon Silver. When run on a Gameboy, it simply uses monochrome textures.
Really? I always knew they were shaped like Game Boy cartridges, so I guess it isn't that surprising. Maybe with some work, they could function in full color, but I certainly wouldn't hold my breath for this. I guess we'd have to wait to hear what calc84maniac thinks of its feasibility/infeasibility.
EDIT: Confirmed that Pokemon Silver does indeed run, although it suffers from the inability to save properly like the other Pokemon games currently. A note to anyone who does want to load up a generation 2 game, though: they seem in general to run more slowly. Regardless of the frameskip setting I was using, it took about 2 seconds longer to walk 8 squares in Silver than in Red in their respective starting towns.
-
Great work! Btw, how is the black space used, exactly? Is it just used as a gbuf to get around the fill effect of updating so many pixels at once? I'm also curious what tricks are used to avoid redrawing the full screen every frame.
I still can't believe that this is even possible!
-
Great work! Btw, how is the black space used, exactly? Is it just used as a gbuf to get around the fill effect of updating so many pixels at once? I'm also curious what tricks are used to avoid redrawing the full screen every frame.
I still can't believe that this is even possible!
Your supposition as to what the black space is used for is precisely correct. And I already asked him about any tricks he uses to avoid some redraw. :P But at least for now, the answer is none are used. I'd still like to see him try, though.
-
Oh, and would Pokemon Gold and Silver be in color? Because they work on the Game boy, but they are in color.
Those are Game Boy Color games. The Game Boy color is not supported for emulation due to a number of increased technical difficulties in emulating it.
Correction: Those games ARE Gameboy games. They were released right when the Gameboy Color was first released and so retained backwards compatibality with the Gameboy. I can prove this because I have a Gameboy original that can play Pokemon Silver. When run on a Gameboy, it simply uses monochrome textures.
Really? I always knew they were shaped like Game Boy cartridges, so I guess it isn't that surprising. Maybe with some work, they could function in full color, but I certainly wouldn't hold my breath for this. I guess we'd have to wait to hear what calc84maniac thinks of its feasibility/infeasibility.
GS only provides proper color if it detects the GSC hardware, and I assume that it also would try to use other non-emulated features of the hardware if it detects it. If it doesn't detect a GBC but the console tries to run the game GBC-style anyway, you get some pretty weird colors, like 1:22 and on in this video: