The shoutbox is currently out of service. Join us on Discord instead.
You can help CodeWalrus stay online by donating here.

emu8x CSE

Started by Hooloowalrus, February 22, 2015, 11:56:06 pm

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


[cross post from cemetech]
I have been porting emu8x, the 81-86 emulator for the 83+SE and 84+(se) to the 84 CSE. Since the only difference between the 84+SE and the 84+CSE is the screen (and flash), I needed to add in an emulated screen. So far it works but is very very slow. I still need to work on fixing some instabilities and other issues.
Screenshot so far:

DJ Omnimaga

Wow I still remember using this a long while ago. It's a shame that it was never really continued. Will this port include some optimizations to improve speed? IIRC, I heard before that the original code wasn't very optimized since it was written several years ago. Something I am curious about is how fast it would run in 160x240 mode with doubled or interlaced pixels?

Also one other thing I was wondering that I mentionned on IRC is if you could do like TI-Boy CSE and detect in-game sprites and objects? This would allow the user to play some games in actual colors like in TI-Boy CSE.

Anyway I hope this comes to fruition because such emulator would be amazing to get on the color model. :)

Duke "Tape" Eiyeron

The TI-Boy could detect sprites because the GameBoy internal memory map contained zones about data. I don't really know if that'll be possible on such emulator as for instance we use the same sprite routine for maps and sprites (beloved Pt-On and Pt-And)

DJ Omnimaga

Well, MateoConLechuga Z80 emulator on Cemetech actually does it, but for Hooloovoo's emulator, since it runs the entire ROM as opposed to just ASM programs, there are many instances where colors would have to be turned off. Colors could probably be based on what routine is called, so if it recognizes a sprite routine then the sprite has a different color unless it's displayed through a loop (so tilemaps would have a different pixel color set), and in the case of the TI-OS, textshadow could use a different color than the rest.

Not sure how hard it would be to implement, though, and it would most likely require an option to turn that feature off. The most important right now is making sure the emulator runs fast enough. :P

Duke "Tape" Eiyeron

IMO it'd be too CPU-expensive to be really useful. I would check for something like rectangle areas of graphic changes to detect some sprites movement or scrolling happening. Oh and don't forget the z-address thing! Games using that trick (like Furious Pong, which would kill the detection routine by just seing how much a screen does change between two frames, be it the balls, the paddles or the electric fences) would get make the thing get crazy about it!

DJ Omnimaga

Scrolling will definitively be a problem. If only there was a way for Hooloovoo to detect when a routine doesn't update the entire screen so that it won't just refresh the entire emulator screen every frame.

Duke "Tape" Eiyeron

Heh, delta based double buffering. Keep the previous frame as a reference and try to see where it changes. Good luck with keeping a constant speed with that method, I can't think of another good method for solving that problem. :/

DJ Omnimaga

I don't think keeping speed identical to the original calc will be possible if he ever makes the screen larger, because of the speed bottleneck caused by the color screen and slow CPU. In the best case scenario, small screen updates will run at identical speed or faster, but full screen refreshing at 96x128 resolution (in 160x240 mode) will get 25 FPS maximum.

Powered by EzPortal