Hello everyone. :) Early last month I started work on a CE calculator emulator, and it has now progressed to a nice development stage. Jacobly, Adriweb, and Lionel were very helpful along the way, and fixed a lot of the bugs I always seemed to make, and of course did an amazing job at implementing a lot of the more wild things. But now it is in working stages; support for ROM dumping from a real calculator is supported, it can boot and operate exactly like a normal TI-OS, except for file transfers, which requires emulating USB, which will take some time. There is no release yet; only a source release (which you can build yourself and play with if you so desire), and if you have sufficient knowledge in anything you feel could help out, feel free to send a pull request my way or ask nicely and I can add you as a collaborator. :) Rather than talk some more about it; Adriweb came up with a nice article that will explain a lot, I hope. Still a lot to do, but yay.
So, give it a test drive, and report any bugs/features/comments that you have or would like implemented, and they will be added to the todo list. Enjoy. :)
It has its own ROM dumping method, much like the rom8x of days past, but now a nice GUI to tell you everything. And a progress bar. Those are cool. Of course, Lionel and jacobly added ROM dumping support to TILP here. (https://www.cemetech.net/forum/viewtopic.php?p=243671#243671)
Source code on GitHub : https://github.com/MateoConLechuga/CEmu
Cross news post:
CEmu: What is it?To sum up: a
portable and open-source TI-84 Plus CE and TI-83 Premium CE emulator.
The 84+CE and 83PCE
(TI-eZ80 series) hit the market over half a year ago. However, there was no third-party emulator, and the official emulator in TI-SmartView CE does not provide the features most community programmers have come to expect from well-behaved emulators: an accurate emulation core, a debugger with a way to inspect and modify registers and memory, a disassembler, etc. Teachers, who are SmartView's main target audience, hardly need such features.
The lack of a proper emulator is a significant roadblock to making TI-eZ80 native code programming popular in the community, which is a shame because the platform is a great improvement over the 84+CSE: faster CPU, more RAM, etc. Therefore, for the community's sake, such a situation shouldn't last for long - hence, the making of an emulator ;)
CEmu is open source (and even free software, under the GPLv3), like nearly all community-made emulators, and made in C/C++. A native code emulator makes perfect sense for both efficiency and versatility; in the longer term, retargeting the code at browsers (JavaScript, WebAssembly) is possible nowadays, thanks to Emscripten.
The team behind CEmuMatt "MateoConLechuga" Waltz started the project and remains the main contributor.
More recently, Jacob "jacobly" Young was invited to join the fun, and he has so far worked quite a bit on improving the CPU and ASIC core (as well as integration thereof with the UI), mainly.
The CEmu code base leverages both Firebird (https://github.com/nspire-emus/firebird) (TI-Nspire emulator) and z80e (https://github.com/KnightOS/z80e) (TI-Z80 emulator for KnightOS, and to which jacobly is a contributor) open-source projects.
There are also other contributions, from non-TI-(e)Z80 experts: Adrien "Adriweb" Bertrand, Lionel Debroux, Fabian "Vogtinator" Vogt.
And in the future... well, potentially anyone with sufficient knowledge, that's precisely part of the power of open source :)
If you want to chat, we're on IRC (EFNet), on channels such as #ez80-dev and #cemu-dev :)
Features- Portable emulation core written in C
- Decent emulation accuracy yielding the ability to boot all of TI's CE OS's, browse around, execute self test successfully, and run programs.
- Portable GUI written in C++ using Qt (making it run on Windows, Mac OS X, Linux, Android, and iOS!)
- Docks/Tabs-based graphical UI (which you are able to customize)
- Integrated setup wizard with ROM dumper for your calculator (there's another one in TILP beta)
- Simple debugger (read CPU registers, flags, ASIC state) and port monitor/writer
- Animated (GIF) and still (PNG) screenshots
What it looks likeHere is what a recent build on Mac OS X looks like:
(https://i.imgur.com/L9nuir2.png) (https://i.imgur.com/0BJsPoG.png)
Of course, using the docking system, all windows are completely resizeable, movable, and translatable.
Short-term todo list- Continue implementing the ASIC emulation core: remaining devices/ports, etc.
- Implement file transfers (implementing USB is not an easy task, so that will probably take a while)
- Make the debugger more useful: disassembly view, stepping, breakpoints...
- Finish 83PCE support (e.g. keypad and skin - emulating the 83PCE already works)
- Test the emulator and hunt bugs, even more!
In the future...- Provide more translations (for now, it's available in English and French). If you want to help, tell us, or send patches / pull requests!
- Make a web-based version of CEmu, like there's a web-based version of z80e for trying out KnightOS. Compiling the CEmu core to JavaScript (and later WebAssembly), using Emscripten, is already known to work: Adriweb has been able to get an Emscriptened CEmu core to boot a ROM and get to the home screen (confirmed by dumping the LCD buffer) :)
- Think about CEmu's core's integration on third-party projects, like TI-Planet's Project Builder - for instance, in C projects, in order to directly test the program, and eventually (if someone has enough time...) have live source-level debugging!
- Look at this gdb-z80 (https://github.com/legumbre/gdb-z80) project (code from 2011...); try to see if it can be updated for eZ80, and used with a CEmu GDB stub. Mainlining such code is highly preferable.
- ...
ConclusionTo sum up: CEmu is the community's open-source, native, portable, TI-84 Plus CE / TI-83 Premium CE emulator, that has been developed over the past few weeks, and of course, still is currently under development.
We all hope you'll enjoy it :)
Download : Soon ! There is no binaries to download yet, you'll have to be a little more patient ;)
Source code on GitHub : https://github.com/MateoConLechuga/CEmu
In the meantime, you can simply build one yourself from the source code (instructions here (https://github.com/MateoConLechuga/CEmu#how-to-build))
Merry (belated) Christmas! :)
whoa, thats really awesome :D Nice job you did there :)
Even though I was a little bit involved in the dev too, congratulations, especially to Mateo and Jacobly :D
Good job on this one guys. :D
Now @DJ Omnimaga can't complain anymore : PBy the way regarding licensing, the MIT license requires you to include the full copyright line like so for z80e code: "Copyright (c) 2014 The KnightOS Group", not sure how the GPL works for Firebird/libti* code but I think "many thanks" is not enough from a legal point of view.
I don't want you guys to get in trouble (even though I don't think the original authors would bother taking legal action against you for this).
Quote from: Streetwalrus on December 30, 2015, 09:37:02 AMBy the way regarding licensing, the MIT license requires you to include the full copyright line like so for z80e code: "Copyright (c) 2014 The KnightOS Group", not sure how the GPL works for Firebird/libti* code but I think "many thanks" is not enough from a legal point of view.
I don't want you guys to get in trouble (even though I don't think the original authors would bother taking legal action against you for this).
Yep, apparently we forgot to do the proper required acks. Should be fixed in a few minutes :)
Edit: well, IANAL but with this commit (https://github.com/MateoConLechuga/CEmu/commit/828351dd1ce7bfa521ee990fa596be4ab34e7b54), it's probably better. it's open to PRs anyway, so anyone who can do better, well, just propose the change :)
Cool. I'm not a lawyer either but this should clarify things. I know that re-licensing MIT code to GPL is ok since the former is a permissive license though.
Nice work! I looked through the code, though, and the licensing issues are still not quite right. In the readme, it says that the code is "inspired" by z80e, which seems to be untrue - this looks like you started with a copy of the z80e code and modified it, so you need to avoid implying that it's an original creation that was "inspired" by the z80e code. You should copy and paste all of the licenses into your LICENSE file and include a summary of what code came from which project. Check this out for an example:
https://github.com/KnightOS/libc/blob/master/LICENSE
Also, if you're interested in contributing your improvements to CE support in z80e upstream, then it'd be nice if you called out what portions of the code are GPL'd and what portions are MIT licensed, so that we know what we can integrate upstream.
Well I haven't myself contributed to the core, so I wouldn't know all the details (nor how compatible it would be for merging some things upstream), but yes, some parts are directly taken from z80e and Firebird.
If it's just a phrasing issue and a matter of copying the proper license text, though, this can be fixed quickly.
Edit : proper license copies in appropriate files now done, by mateo in this commit (https://github.com/MateoConLechuga/CEmu/commit/8a1afbace01881f526af5355d2c584f9fac40f56).
The project uses GPLv3 code; everything is built by the same Makefile and linked together statically.
Awesome news Mateo and great job to everyone who participated to the development of this emulator. Not to mention that it's open-source, so people will still be able to maintain it even when the original authors are inactive. :)
Thanks for the cross-post as well. Hopefully when this emulator will have full file transfer support (unless it does already?) it will kickstart CE development (a lot of people were not interested because there was no emulator available) :)
Looks interesting. Fun fact, if you have Arch Linux, you should be able to get cemu-git (https://aur.archlinux.org/packages/cemu-git/) from the AUR.
That reminds me, while there are no binaries available yet, can compiling the source allow us to run the emulator on Windows immediately?
i had a quick try at it but it couldn't find my compilers, though it vould find the debuggers.
Quotecan compiling the source allow us to run the emulator on Windows immediately?
Yup, the MinGW-based Qt SDK works. Support for older, broken versions of MSVC is in progress.
Ah that's good then. :) I don't need it immediately but if I start coding again soon then it could be handy :) (if I manage to compile it, that is :P)
Shouldn't this me moved to news or linked from the news ?
Yup, definitely.
I think Ivoah added it to articles yesterday but he doesn't have sufficient privileges to approve it so I had to do it.
We will provide binaries, of course, but we want the codebase to get a bit more stable first :)
Quote from: Streetwalrus on December 31, 2015, 11:21:01 AM
Yup, definitely.
I think Ivoah added it to articles yesterday but he doesn't have sufficient privileges to approve it so I had to do it.
Yeah we need to fix that. And I agree about the news :3=
Hello all! Don't know how much anyone has been following along, but some hacky file transfer has been implemented recently, so you can now send all file types except for TI apps and OS. Here's a gif of PacMan. I would really appreciate any help at all on making the disassembler (which is already prepared), and other parts and pieces of the debugger. Thanks to anyone who can lend a hand, and enjoy! :)
(http://myimages.wikidot.com/local--files/start/PacMan.gif)
Awesome Mateo. I can't wait to try it. By the way, do you plan to upload the emulator to ticalc.org in the future for more visibility, even if it means it's not always up to date?
Nah, I don't believe so. It just means another hassle all around. Just the release page on GitHub is where releasable versions for different platforms will be. Also, somewhat of an update: breakpoints for read/write/exec are done. We still need the disassembler and memory views though for actual debugging.
Wow! great work, I have to try this out soon, exept school has now started again <_<
Quote from: MateoConLechuga on January 04, 2016, 02:55:58 AM
Nah, I don't believe so. It just means another hassle all around. Just the release page on GitHub is where releasable versions for different platforms will be. Also, somewhat of an update: breakpoints for read/write/exec are done. We still need the disassembler and memory views though for actual debugging.
Ah ok, but the issue is that ticalc.org is the main hub for calculator downloads, yet the last emulator ever released on ticalc.org is VirtualTI, back in 2000, so when people visit ticalc.org to look for a TI-83+/84+/CSE/CE emulator, that's all they find. It's still even 3rd in the weekly downloads list.
It's your choice, though.
Maybe it's time for Travis and Nikky to consider adding support for Github repositories for important open-source calculator releases or allow you to just upload a link to the Github repo? TI-Planet allows external download links to specific websites, same for CodeWalrus. (EDIT: It seems that their emulator pages now includes off-site emulators and even encourages people to use them. See http://www.ticalc.org/programming/emulators/software.html . It would still be cool if people could upload download links in ticalc archives, though, for special files like those)
Also I'm glad to see new additions :)
So apparently
@Adriweb made this O.O
(https://i.imgur.com/fzGfCbo.png)
I am curious about how fast it will run if a TI-Nspire port gets finished.
Also, Pimath posted binaries for Win32 on Cemetech, but I cannot get them to work because the file has no .exe/.msi extension.
Quote from: DJ Omnimaga on January 06, 2016, 02:26:02 AMSo apparently @Adriweb made this O.O
(https://i.imgur.com/fzGfCbom.png)
I am curious about how fast it will run if a TI-Nspire port gets finished.
It's pretty slow right now... probably because I'm memcpying the LCD buffer of the CE to the Nspire's (I'm looking into how I can just tell the LCD controller to use another address...)
But hey, it works.
Quote from: DJ Omnimaga on January 06, 2016, 02:26:02 AMAlso, Pimath posted binaries for Win32 on Cemetech, but I cannot get them to work because the file has no .exe/.msi extension.
Eh, his nightlies are just .zip files. So, add the extension if it's missing, extract it, and launch the .exe, there's no installer :)
I see, and thanks for the advice :3=
Meh, it's fast enough to be showable... (the boot is slow, yes):
https://www.youtube.com/watch?v=DzpmJoQHOwI
Not bad. The startup is slow, but typing stuff can be quite tolerable. Hopefully there can be more speed improvements in future versions, although for now I assume it would be better to focus on getting the PC emu fully functional.
Did it require many modifications, by the way?
Quote from: Adriweb on January 06, 2016, 02:30:45 AM
It's pretty slow right now... probably because I'm memcpying the LCD buffer of the CE to the Nspire's (I'm looking into how I can just tell the LCD controller to use another address...)
But hey, it works.
What about using the address to the Nspire's LCD buffer directly as the CE's? Otherwise, that's pretty cool.
Quote from: Juju on January 06, 2016, 05:13:16 AMWhat about using the address to the Nspire's LCD buffer directly as the CE's? Otherwise, that's pretty cool.
Yeah, I ended up telling the Nspire's LCD controller to directly get its data from the CE's VRAM.
Quote from: DJ OmnimagaDid it require many modifications, by the way?
Not much at all, that's the nice thing about the core being well separate from the rest. I put some code here: https://tiplanet.org/forum/viewtopic.php?short=1&p=194523#p194523
We'll have to decide/find a way to cleanly integrate different targets (desktop, mobile/tablet, web, nspire) to the build process...
Yeah that would be better for when Mateo fixes bugs. Imagine having to update multiple versions everytime there are bug fixes. >.<
I've also ported it to the Apple Watch :)
QuoteThis is an Apple Watch.
And it's joining the club of devices capable of running CEmu \o/
(https://i.imgur.com/XgzBduE.png)
- Sorry for the bad quality :P
- Yes, I know, the colors are messed up, I probably shifted some RGB bits a bit too hard, I'll fix that soon...
- Yes, it's running natively on the watch, not on the iPhone.
- No, it's not usable for now (no input etc.), I'm just showing that the core works.
- If/When a download gets available, it will be here: https://github.com/MateoConLechuga/CEmu
Video showing the speed:
https://www.youtube.com/watch?v=xGh3T_o-E_Q
Source: https://tiplanet.org/forum/viewtopic.php?f=41&t=17746&p=194641#p194641
The future is here, guys. You can now have a graphing calculator on a watch (https://en.wikipedia.org/wiki/Calculator_watch). That's... pretty useless, with no input... Still, that's pretty nice.
That is awesome Adriweb. I wonder if it could be ported to iOS easily, especially with their restrictions on emulators and stuff in the past (are those still active?)
The emulator (etc.) restriction is only for the App Store. Doesn't matter if you don't plan to distribute your app there (it's now free to run your own compiled apps on your iOS device, so... there's that)
But it runs perfectly on iOS (The Qt version directly, like on Desktop) already (especially on iPad with the bigger screen) :)
Ah ok, so this is a Cydia program? (or whatever jailbreak tools are called now. THe last time I used an iPod Touch we used Cydia and I had to reformat my phone twice in a week)
Nope, no jailbreak required, as it doesn't do anything out of the ordinary :)
Quote from: DJ Omnimaga on January 08, 2016, 08:15:35 AM
That is awesome Adriweb. I wonder if it could be ported to iOS easily, especially with their restrictions on emulators and stuff in the past (are those still active?)
The restriction you're probably thinking about is that a JIT isn't possible on iOS without jailbreak, as a program isn't allowed to map memory with PROT_EXEC.
CEmu doesn't have a JIT, so it is fine.
Ah I see. Back in the days, I thought, however, that it was against the appstore rules to publish apps that contains a programming language, such as a TI-84 Plus emulator. But I guess this either changed or TI received a special treatment with TI-Nspire iOS app.
It's because it's not an emulator at all, rather the whole natively compiled phoenix engine + a native UI :)
Like TINCS.
Emulators are allowed on the App Store, but they're not allowed to load ROMs provided by a user. That essentially means that the only allowed way of loading ROMs is getting permission from the copyright holder to distribute the ROMs on the App Store. There are some classic games that have been released in this way.
What Adriweb is also true. The TI-Nspire software doesn't need to emulate the TI-Nspire hardware.
Also, DJ Omnimaga: With iOS 9, that something can't be in the App Store doesn't necessarily mean that it requires a jailbreak. Apple added the ability to sideload apps so you can install whatever you want (as long as it doesn't have something like a JIT), but I think you need to set up a developer environment on a Mac before you can use it.
Oh I see now. That's cool that they lifted some of their restrictions. Using an iOS device in the past seemed like living in North Korea: You were restricted with anything and the minute you tried to circumvent restrictions, you were "punished" for doing it (by being forced to reformat your phone because once jailbroken it had 50% chances of suddenly being one step close to bricked for absolute no reason)
So I finally tried this and was happy that it came with a ROM dumper built-in. Very good job so far, as it was quite easy to get to run and I could also run games flawlessly. My only gripe is that the 2nd key is not mapped to Shift like in WabbitEmu, but I guess that can be changed easily.
Test screenshot (set at lowest frame rate for size reasons):
(https://img.ourl.ca/ffmfcemutest2.gif)
EDIT: Another issue is that it doesn't remember the last directory when sending files, which can get annoying. And when I opened the setup screen, hitting cancel (the X button at the top) caused a RAM reset.
Quote from: DJ Omnimaga on January 09, 2016, 10:37:57 PM
Oh I see now. That's cool that they lifted some of their restrictions. Using an iOS device in the past seemed like living in North Korea: You were restricted with anything and the minute you tried to circumvent restrictions, you were "punished" for doing it (by being forced to reformat your phone because once jailbroken it had 50% chances of suddenly being one step close to bricked for absolute no reason)
Have you actually used a jailbroken iDevice? I jailbroke my my iPad, and have never had issues, nor have I ever heard of other people having issues with jailbroken devices. Also, I highly doubt that CEmu (or Firebird) would be allowed on the appstore, because it is an emulator. It's easy enough to get it on an iDevice though if you have a mac, because you can just build the program yourself and put it on as a testing thing.
Yes I did. It was an iPod Touch 4. The day after I installed Cydia on it, I was greeted with the Apple logo on a black screen and the only way to fix it was to reset my device to factory setting. Afterwards I tried jailbreaking it again, only to be greeted by the same screen again a few days later. I eventually gave up and just switched to an Android device.
Hm, bad luck I guess, then. Never had an issues on my iDevices so far.
Anyway, got any suggestions/ideas ? Don't hesitate to create a ticket here: https://github.com/MateoConLechuga/CEmu/issues/ :)
Regarding the RAM Clear when cancelling the setup, hm, maybe it restarts the emulation, which would explain it... we'll have to look
Ah that might explain things. Perhaps cancel acts as confirm. :P
In any case, now we got a full emulator to test games. Is the debugger done? I don't know ASM so I can't really tell from other posts.
Also we need to get ticalc.org to add the emulator to their emulators list and also they need to create a TI-84 Plus CE page for more visibility. I hope this tool convinces more people to develop for the TI-84 Plus CE.
New screenshot showing some of the latest features:
(https://i.imgur.com/NfgJS4n.png) (https://i.imgur.com/9WFnNJd.png)
Thanks for posting those. THis looks very nice, as always :), and I'm glad this emulator is getting more features.
So we can snap the keyboard below the screen without having a huge resolution now?
"Cross-proposition" with TI-Planet : I and Lionel Debroux propose to integrate CEmu's code into TilEm's one, to have only one emulator for all (e)z80. :D
I did think about it before the public release of CEmu, and Benjamin started working on that on his side a while ago anyway.
TilEm is the obvious choice for a portable TI-Z80 emulator, it's native code, one variant has a Qt-based UI (though I don't know how complete and up to date it is - I've never used it), and the license enforces good community behaviour.
One of the important goals for what became CEmu was quickly releasing a native code, GPL'ed emulator that works. A side effect is throw spokes in the wheels of proprietary software makers, of course. None of the persons involved in the initial development of CEmu was familiar with the TilEm code base, and a single person was familiar with libti* - so some time would have been invested in diving into the code base, but using TilEm as a starting point would have saved some time on other fronts. Hard to tell whether using TilEm would have saved some time in the short term :)
Another important goal would have been harder to achieve with TilEm in the short term: there's no Emscripten port of Glib at the moment...
Integration with TilEm would be nice, providing that the code is easy to decipher and easily re-useable. I think WabbitEmu is open-source, but it has lots of bugs and some innacuracies (older versions are more stable but less accurate). But I think I would understand if it was left as standalone emulator, because as Lionel said, the goal was to get an open-source CE emulator out soon, to make it easier to develop programs, since it became clear that no other alternative would come out in the near future.
So thanks for the initiative of starting a CE emulator. :)
Hello again all! If you would like to make to icon for this program, feel free! Open to all, but of course it will be narrowed down to one. Icons should be in svg format, or 512x512 minimum in size. Vector based is preferred, of course. Thanks!
If it wasn't for making CEmu sound like a CodeWalrus release rather than community release, I would have at least 160 icons to give you :P (I could maybe modify the 84+ Walrii to be a CE, though :P)
Quote from: STV on January 12, 2016, 11:57:00 AM
"Cross-proposition" with TI-Planet : I and Lionel Debroux propose to integrate CEmu's code into TilEm's one, to have only one emulator for all (e)z80. :D
Any interest in a merge with z80e upstream? I want to iterate more on scas and kcc's integration with z80e to enable source level debugging of assembly and C code.
Quote from: DJ Omnimaga on January 15, 2016, 05:04:19 AM
If it wasn't for making CEmu sound like a CodeWalrus release rather than community release, I would have at least 160 icons to give you :P (I could maybe modify the 84+ Walrii to be a CE, though :P)
NOO!!!! Don't touch the precious TI-84 Plus! :P
By the way, for those who don't know where they're located, the win32 nightlies for CEmu (which are now actually nightly because I got cron working) are located here (http://pimathbrainiac.me/CEmu/).
Yeah, I had issues getting those to work at first, because they had no extension, so I thought that despite being win32 they were for Linux only or something. But then I got told which extension to add and I think this problem has been fixed ever since. :P
Yeah I was prodded to fix the extension a little after your post on #cemu-dev. They have the .zip now, though :P
Thanks to a complete keypad overhaul by Jacobly, upcoming versions will soon not require QML/QtQuick(/OpenGL?) stuff, making everything much easier and lightweight (in addition to being even more nice-looking than the current one) :)
Quote from: pimathbrainiac on January 27, 2016, 02:59:43 AM
Yeah I was prodded to fix the extension a little after your post on #cemu-dev.
I never posted in this channel O.O
Quote from: Adriweb on January 27, 2016, 07:25:56 PM
Thanks to a complete keypad overhaul by Jacobly, upcoming versions will soon not require QML/QtQuick(/OpenGL?) stuff, making everything much easier and lightweight (in addition to being even more nice-looking than the current one) :)
Nice to hear. By the way what is the final consensus about key choices? Will it use Wabbit's, TilEm, VTI or will we be able to change the key mapping?
I was prodded by Adriweb. I meant I was prodded on #cemu-dev after your post.
Quote from: DJ Omnimaga on January 27, 2016, 08:01:33 PMNice to hear. By the way what is the final consensus about key choices? Will it use Wabbit's, TilEm, VTI or will we be able to change the key mapping?
The default is (and always will be) CEmu's, but the user can also choose Tilem, WabbitEmu... And maybe one day there will be a feature to completely customize the keymapping :)
Quote from: pimathbrainiac on January 27, 2016, 08:09:22 PM
I was prodded by Adriweb. I meant I was prodded on #cemu-dev after your post.
Oh ok lol.
Quote from: Adriweb on January 27, 2016, 08:11:23 PM
Quote from: DJ Omnimaga on January 27, 2016, 08:01:33 PMNice to hear. By the way what is the final consensus about key choices? Will it use Wabbit's, TilEm, VTI or will we be able to change the key mapping?
The default will be CEmu's, but the user can also choose Tilem, Wabbit... And maybe one day there will be a feature to completely customize the keymapping :)
That is cool. There seemed to be some concerns about the different keys. While getting used to the new mapping isn't too hard, it might have gotten confusing for people who constantly switches back and forth between WabbitEmu and CEmu or people who used PTI/Wabbit for a decade.
Is it possible to load a .8eu file? If not, will this be added?
.8pu and .8eu files are OS upgrades for the TI-eZ80 series, but those are insufficient for emulating the calculator (unlike what happens on the TI-68k series), so adding support for loading those file formats wouldn't do much good.
In order to emulate the calculator, you also need a dump of the boot code, which can be obtained by the offline dumper in CEmu, or the online dumper in TILP 1.18 beta.
So there is essentially no legal way to use this emulator if you dont have a physical model?
Sounds about right, lest someone makes a FreeBoot-type program for the TI-eZ80 series. But a large part of the English-speaking community strongly frowns upon FreeBoot, sadly.
Yeah the main concern would be that people could make their own ROM without buying the calculator itself and while this is more a gray area and perhaps not illegal, TI would not like that.
That reminds me, I tried the latest version of a few days ago and I like the speed. Even at 500% it won't eat all my CPU, unless I resize the window to fit the screen.
With Smartview the speed was just atrocious.
If thats such a concern, then how can WabbitEmu get the rom from the os file? ???
Precisely thanks to BootFree. And that functionality was eviscerated from some unofficial, crippled forks of WabbitEmu.
What is BootFree exactly?
There's a complicated explanation on the thread I made asking for a TI-84+ ROM back when I had one, and when I didn't know transferring ROMs was illegal.
I think it is this thingy that lets you load thingies that are TI-OS files to emulator thingies without needing ROM thingies that you would normally need for emulator thingies. :P
i.e. something that TI absolutely hates, even more than things like Ndless.
What's Ndless? ???
TI-Nspire jailbreak.
http://ndless.me
(Google is your friend, by the way)
Ah. Okay.
Quote from: Cumred_Snektron on February 09, 2016, 10:19:21 PM
What is BootFree exactly?
The software on a (e)z80 TI calc with flash memory consists of two parts: the boot code and the OS. You need both in order to be able to use the calculator, both on hardware and on emulators. TI distributes OSes on their website, so those are easy to get*, but they don't distribute the boot code in the same way. Because of that, the only legal way to get TI's boot code is to dump it from your calculator. So does that mean that you can't legally get any boot code if you don't have a real calculator? Well, you won't be able to get TI's boot code, but what you can do is to get an alternate boot code that someone else made. That's exactly what BootFree is – a replacement for TI's boot code that you can download freely. Wabbitemu has it built in.
* Before you download OS files and use them in emulators, you should read the license that's on the download page. I think they added a clause a few years ago that forbids you from using downloaded OSes with unofficial emulators.
If WabbitEmu has it built in, then how come it wouldn't accept my OS file for the TI-84+? I had to do that ROM dumping thing. And now that I no longer have a TI-84+, it's a good thing I still have that ROM file.
WabbitEmu accepts the OS file I use for the TI-84 Plus...
Also, why don't you have a TI-84 Plus anymore?
I posted this somewhere, but it's a long story. Look it up. I used the words "it's a long story." If you find a topic where I used those exact words, then I explained there.
Okay, thanks.
Did you find it?
QuoteIf WabbitEmu has it built in, then how come it wouldn't accept my OS file for the TI-84+?
Are you using one of the crippled unofficial forks, or did the crippling become part of upstream WabbitEmu ?
Quote from: Lionel Debroux on February 11, 2016, 06:29:13 AM
QuoteIf WabbitEmu has it built in, then how come it wouldn't accept my OS file for the TI-84+?
Are you using one of the crippled unofficial forks, or did the crippling become part of upstream WabbitEmu ?
/me mutters something about actually using and liking said fork
I wouldn't call it crippled. For most people, BootFree isn't necessary. For some people, yes, it is, but since TI has changed the EULA on their OSs to explicitly disallow the use of the OS files for use in an emulator other than smartview (as JosJuice has pointed out), I think it is safe to say that BootFree is no longer even legal :P
/me mutters something incomprehensible revolving around the words 'not' and 'care'
BootFree also causes issues running some apps, from what I remember, unless this was fixed. It didn't happen with all of them. A few years ago I remember that many apps in WabbitEmu greeted me with a BootFree splash screen instead of said app.
It's because some apps use bootcode routines for ie, writing to flash (like Axe) which are not implemented by bootfree, or at least not correctly.
So i guess because ti smartview is a simulator it doesnt need the bootcode or what?
Last I've heard of it smartview wasn't an emulator, but that was the 84+ version so yeah.
Errr what are you all saying.
SmartView CE is an emulator, not a simulator (yes it has a full rom inside, how would it run otherwise?). (Also obviously you can't share it or whatever - see its terms of use / license)
Its core is written in JavaScript, actually, which is why it runs crappily under the Java host (smartview program itself), and runs too fast in recent browsers.
Then wouldn't you theoretically be able to rip the rom from smartview
Quote from: Adriweb on February 11, 2016, 01:06:57 PM
Errr what are you all saying.
SmartView CE is an emulator, not a simulator (yes it has a full rom inside, how would it run otherwise?). (Also obviously you can't share it or whatever - see its terms of use / license)
Its core is written in JavaScript, actually, which is why it runs crappily under the Java host (smartview program itself), and runs too fast in recent browsers.
I was talking about the 84+ version, not the CSE (does it exist ?) or the CE version.
Quote from: Adriweb on February 11, 2016, 01:06:57 PM
Errr what are you all saying.
SmartView CE is an emulator, not a simulator (yes it has a full rom inside, how would it run otherwise?). (Also obviously you can't share it or whatever - see its terms of use / license)
Its core is written in JavaScript, actually, which is why it runs crappily under the Java host (smartview program itself), and runs too fast in recent browsers.
Didn't Smartview use to be a simulator way back in the days, though?
Quote from: pimathbrainiac on February 11, 2016, 10:38:27 AM
since TI has changed the EULA on their OSs to explicitly disallow the use of the OS files for use in an emulator other than smartview (as JosJuice has pointed out), I think it is safe to say that BootFree is no longer even legal :P
No, BootFree itself still legal. That you can't use it with TI-OS doesn't mean that you can't use it with other OSes.
Quote from: JosJuice on February 12, 2016, 02:24:53 PM
Quote from: pimathbrainiac on February 11, 2016, 10:38:27 AM
since TI has changed the EULA on their OSs to explicitly disallow the use of the OS files for use in an emulator other than smartview (as JosJuice has pointed out), I think it is safe to say that BootFree is no longer even legal :P
No, BootFree itself still legal. That you can't use it with TI-OS doesn't mean that you can't use it with other OSes.
Well then using BootFree on TI-OS (which is what most people use it for) is illegal :P
Not if you own a physical calc from which you can dump the ROM yourself, then you can do whatever you want (as long as you don't share it, as usual).
Quote from: Adriweb on February 12, 2016, 04:36:26 PM
Not if you own a physical calc from which you can dump the ROM yourself, then you can do whatever you want (as long as you don't share it, as usual).
Yes, but then you aren't using BootFree :P
But nothing is preventing you to do so :P
Where can I get BootFree, and how do I use it?
BootFree is only available through WabbitEmu AFAIK, which lacks CE emulation.
Bug report:
When I uncheck the "Throttle" option, CEmu crashes instantly. (It says CEmu has encountered a problem and must close)
WabbitEmu has gotten rid of BootFree in some recent versions, IIRC.
Regarding the Throttle issue, make sure you have a recent versions.
Ah ok. I thought WabbitEmu (at least the regular versions, not the forks by Geekboy1011) still had BootFree.
This emu is going to come in very handy very soon :D
Did you buy a CE or something?
Quote from: DJ Omnimaga on March 17, 2016, 12:01:00 AM
Did you buy a CE or something?
Yes :w00t: :w00t: :crazy: :crazy: :w00t:
Glad to hear. Hopefully you have fun with it :)
Also question about CEmu: Why does it open two windows instead of one now? It used to only open the emulator window, but now it opens an extra empty Command Prompt window that we can't close. ???
Quote from: DJ Omnimaga on March 17, 2016, 12:06:16 AMAlso question about CEmu: Why does it open two windows instead of one now? It used to only open the emulator window, but now it opens an extra empty Command Prompt window that we can't close. ???
Thank Windows that can't handle stdout without a console showing :/ and To get such output you *need* one... On Linux/Mac, you can launch an app normally, and if you want stdout, you can launch the binary in a terminal, that's all...
Anyway, for dev. builds (ie until there's a proper release), it's useful for developers as they can track what's going on with more ease.
It'll be gone later.
Ah ok I was wondering, since it wasn't there before. Some other TI softwares do that (TilEm or TIEmu IIRC) and I always close the command window by accident >.<
Several of my TILP releases did have a console window on Windows. It was removed at some point, and the output redirected to a file, because Windows' console is so slow that the mere action of displaying stuff there was acting as a bottleneck when communicating with Nspires... Terminal emulators on *nix OS yield no such behaviour.
Later, libhpcalcs taught me that the Windows console and probably other subsystems of the OS (Windows 7, at the time), were even worse: unless output occurred to a file instead of the console, up to three quarters of the packets were simply lost in a ~20 KB file transfer ! The HID protocol used by the Prime is based on interrupt transfers, whereas TI's vendor-specific devices use protocols based on bulk transfers, and interrupt transfers are more time-sensitive. The fact that such catastrophic losses occur speaks volumes to the sorry technical state of the implementation of several areas of Windows.
Now to think that Windows 10 will be the final version of Windows (or at least, version number. I hope they don't stick to its flaws or future flaws for 20 years. For example, in Windows 7, we still have the dozens of svchost processes in the task manager and we are still stuck with the horrible Windows update system that forces us to reboot after every update.
Quote from: DJ Omnimaga on March 17, 2016, 08:08:47 AM
Now to think that Windows 10 will be the final version of Windows (or at least, version number. I hope they don't stick to its flaws or future flaws for 20 years. For example, in Windows 7, we still have the dozens of svchost processes in the task manager and we are still stuck with the horrible Windows update system that forces us to reboot after every update.
It seems so, with the new editions and the whole "free 1st year" thing.
Microsoft actually planned and created a Windows 9, though. But they just never released it.
I hope there are improvements, though. There are a few things that should probably be changed.
What do you mean by free 1st year? Do you mean the free versions of Windows 10 they handed will only provide 1 year of update or are actually a 1 year trial?
Also on the topic of CEmu, do you guys plan to continue supporting Windows 7 in long terms? I know Windows 7 is old and will be discontinued in 3 years, but several people still use it.
Quote from: DJ Omnimaga on March 17, 2016, 06:19:47 PMAlso on the topic of CEmu, do you guys plan to continue supporting Windows 7 in long terms? I know Windows 7 is old and will be discontinued in 3 years, but several people still use it.
I don't see any reason not to support it, in fact I'm pretty sure we'd have to do something very special to actively break the compatibility :P
Ah ok, just making sure, since some developers tend to discourage using old versions of Windows, even though they're still maintained, and would rather have everyone upgrade :P (same for companies)
Quote from: DJ Omnimaga on March 17, 2016, 06:19:47 PM
What do you mean by free 1st year? Do you mean the free versions of Windows 10 they handed will only provide 1 year of update or are actually a 1 year trial?
No, I meant that everyone with an eligible computer with any version of Windows 7 or 8(except Enterprise) can upgrade for absolutely free until a year after the official Windows 10 release date, meaning if you have not upgraded to Windows 10 for free and you could have, then after sometime near July(beginning? end?), you will have to pay full price for it.
Quote from: DJ Omnimaga on March 17, 2016, 06:19:47 PM
Also on the topic of CEmu, do you guys plan to continue supporting Windows 7 in long terms? I know Windows 7 is old and will be discontinued in 3 years, but several people still use it.
I know companies do it, but Windows 7 is like Apple's revolutionary breakthrough with iOS 7. People will still use it for 3 reasons: Some devices cannot be upgraded past Windows 7, they can't upgrade for free, and because it's the oldest Windows OS that is not slow and is quite smooth.
I like the Aero theme that came along with Windows 7(and the multitasking feature, [Start]+[Tab]), but many people and schools have either upgraded to Windows 8(like colleges, because of new services) or kept Windows 7, because they can't or won't.
Oh I see now. I seriously hope that they fix the issues it had beforehand. It would suck if they waited on purpose or something to make people miss out on the promotion.
Windows 7 is seriously heavyweight, actually, especially in terms of disk space. Newer versions are slightly more nimble, but still not really light on storage or RAM...
Windows 10 IoT is an unusably limited joke, based on both hearsay on the Internet and real-world experience from a colleague I trust, and who has significant experience of both Windows and Linux, on a RPi 2.
Do you mean limited in what you can run on it, Nspire style, or limited as in lack of features/options?
Lack of features: various APIs which can be taken for granted on Windows don't exist on Win 10 IoT (kinda like the former Windows CE now renamed to "Embedded Edition" or something like that), the UI is either very basic or nonexistent, etc.
Switching from Linux to Windows 10 IoT on a RPi 2 is a huge feature regression. My colleague was curious about what this platform could offer, but he's probably not about to test this PoS again any time soon, let alone switch the box to it ^^
His domotics software works very well from the usage bliss and low weight of Linux.
Dang. I hope I can stick to seven for a while then. Besides, I heard that 8.1 can't even run Brood War anyway. Anyway, I'm going back on topic :P
I was going to say that Microsoft has apparently already dropped Windows 7 Media Support, but then I noticed your last sentence there. :P
To get back on topic, I got the latest nightly build and tried it.
What might be wrong with my laptop if I keep getting this?
(http://i.imgur.com/F2xWGN4.png)
It's the same issue as before; the keypad still isn't finished yet. That will clear up the bug entirely :) Your computer may just not support OpenGL 2.0, which is solvable by following the answer detailed here: http://superuser.com/questions/458629/updating-opengl-to-2-0
Is your graphic card from 1992? O.O
Quote from: MateoConLechuga on March 19, 2016, 07:42:50 PM
It's the same issue as before; the keypad still isn't finished yet. That will clear up the bug entirely :) Your computer may just not support OpenGL 2.0, which is solvable by following the answer detailed here: http://superuser.com/questions/458629/updating-opengl-to-2-0
I couldn't figure out which vendor I'm supposed to go to for a new driver. Intel's tool told me no drivers were available for my device, and I'm not sure what to do now.
Image:
(http://i.imgur.com/MwhPN86.png)
[spoiler=Open GL Details]
Renderer: GDI Generic
Vendor: Microsoft Corporation
Memory: 0 MB
Version: 1.1.0
Shading language version: N/A
Max texture size: 1024 x 1024
Max texture coordinates: 0
Max vertex texture image units: 0
Max texture image units: 0
Max geometry texture units: 0
Max anisotropic filtering value: 0
Max number of light sources: 8
Max viewport size: 16384 x 16384
Max uniform vertex components: 0
Max uniform fragment components: 0
Max geometry uniform components: 0
Max varying floats: 0
Max samples: 0
Max draw buffers: 0
Extensions: 3
GL_EXT_bgra
GL_EXT_paletted_texture
GL_WIN_swap_hint
Core features
v1.1 (100 % - 7/7)
v1.2 (12 % - 1/8)
v1.3 (0 % - 0/9)
v1.4 (0 % - 0/15)
v1.5 (0 % - 0/3)
v2.0 (0 % - 0/10)
v2.1 (0 % - 0/3)
v3.0 (0 % - 0/23)
v3.1 (0 % - 0/8)
v3.2 (0 % - 0/10)
v3.3 (0 % - 0/10)
v4.0 (0 % - 0/14)
v4.1 (0 % - 0/7)
v4.2 (0 % - 0/13)
v4.3 (0 % - 0/23)
v4.4 (0 % - 0/10)
v4.5 (0 % - 0/11)
vARB 2015 (0 % - 0/13)
OpenGL driver version check (Current: 1.1.0, Latest known: 1.1.0):
Latest version of display drivers found
According the database, you are running the latest display drivers for your video card.
No ICD registry entry
The current OpenGL driver doesn't expose the SOFTWARE/Microsoft/Windows (NT)/CurrentVersion/OpenGLDrivers registry entry. Unable to detect the driver version, driver revision name and filename.
No multitexturing support
This may cause performance loss in some applications.
No secondary color support
Some applications may not render polygon highlights correctly.
No S3TC compression support
This may cause performance loss in some applications.
No texture edge clamp support
This feature adds clamping control to edge texel filtering. Some programs may not render textures correctly (black line on borders.)
No vertex program support
This feature enables vertex programming (equivalent to DX8 Vertex Shader.) Some current or future OpenGL programs may require this feature.
No fragment program support
This feature enables per pixel programming (equivalent to DX9 Pixel Shader.) Some current or future OpenGL programs may require this feature.
No OpenGL Shading Language support
This may break compatibility for applications using per pixel shading.
No Frame buffer object support
This may break compatibility for applications using render to texture functions.
Few texture units found
This may slow down some applications using fragment programs or extensive texture mapping.
Extension verification:
GL_EXT_color_subtable was not found, but has the entry point glColorSubTableEXT
[/spoiler]
Quote from: DJ Omnimaga on March 19, 2016, 08:03:43 PM
Is your graphic card from 1992? O.O
Maybe...
@MateoConLechuga @Adriweb I cant seem to run this. Once i select my ROM file from my PC and click finish, it crashes :(
(http://imgur.com/u6OM8q6.png)
I am using the 3-18 build found here http://pimathbrainiac.me/CEmu/
What does the "problem details" give?
More technical info would be useful
Quote from: Adriweb on March 20, 2016, 12:12:36 AM
What does the "problem details" give?
More technical info would be useful
QuoteProblem Event Name: APPCRASH
Application Name: CEmu.exe
Application Version: 0.0.0.0
Application Timestamp: 56e62a31
Fault Module Name: CEmu.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 56e62a31
Exception Code: c0000005
Exception Offset: 01416dc5
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\windows\system32\en-US\erofflps.txt
@c4ooo , could you post your system specs?
Quote from: DJ Omnimaga on March 20, 2016, 12:26:53 AM
@c4ooo , could you post your system specs?
Why does this post show up in my mentions list?
You did not mention me, but that's what it says... ???
Quote from: Adriweb on March 17, 2016, 06:25:10 PM
Quote from: DJ Omnimaga on March 17, 2016, 06:19:47 PMAlso on the topic of CEmu, do you guys plan to continue supporting Windows 7 in long terms? I know Windows 7 is old and will be discontinued in 3 years, but several people still use it.
I don't see any reason not to support it, in fact I'm pretty sure we'd have to do something very special to actively break the compatibility :P
I think in my builds (https://oss.jfrog.org/artifactory/list/oss-snapshot-local/org/github/alberthdev/cemu/git/) (and likely pimath's (http://pimathbrainiac.me/CEmu/) as well), XP should also still be supported as well. Yay for 15 year OS backward compatibility! :P
Regarding console output: There's a new feature that lets you hide this debug console! My latest build (https://oss.jfrog.org/artifactory/list/oss-snapshot-local/org/github/alberthdev/cemu/git/201603/20160320/cemu-20160320_063947-git-06c7d63/cemu-20160320_063947-git-06c7d63-win32-release-static.zip) should have this feature built in. If you prefer pimath's builds (http://pimathbrainiac.me/CEmu/), they should have this new feature by sometime tonight!
@Dudeman313: Try this build (https://dl.dropboxusercontent.com/u/1016340/CEmu-dev-qt56rel-06c7d63.zip) and see if it works!
EDIT: Just checked - the latest build online does NOT work, because there was a bug (https://bugreports.qt.io/browse/QTBUG-50188) that broke XP support. However, the ZIP linked above for Dudeman313 should work, since it's built with the released (stable) version of Qt 5.6.0! Screenshots for fun:
(http://i.imgur.com/KRMQyub.png)
Quote from: Dudeman313 on March 20, 2016, 03:17:23 PM
Quote from: DJ Omnimaga on March 20, 2016, 12:26:53 AM
@c4ooo , could you post your system specs?
Why does this post show up in my mentions list?
You did not mention me, but that's what it says... ???
Oh sorry about that. At first I asked you as well because I missed your post above. When I saw your post I edited mine to remove your name.
Quote from: alberthrocks on March 20, 2016, 04:25:56 PM
@Dudeman313: Try this build (https://dl.dropboxusercontent.com/u/1016340/CEmu-dev-qt56rel-06c7d63.zip) and see if it works!
EDIT: Just checked - the latest build online does NOT work, because there was a bug (https://bugreports.qt.io/browse/QTBUG-50188) that broke XP support. However, the ZIP linked above for Dudeman313 should work, since it's built with the released (stable) version of Qt 5.6.0!
This does indeed work for me! Thank you!
Quote from: DJ Omnimaga on March 20, 2016, 05:44:05 PM
Quote from: Dudeman313 on March 20, 2016, 03:17:23 PM
Quote from: DJ Omnimaga on March 20, 2016, 12:26:53 AM
@c4ooo , could you post your system specs?
Why does this post show up in my mentions list?
You did not mention me, but that's what it says... ???
Oh sorry about that. At first I asked you as well because I missed your post above. When I saw your post I edited mine to remove your name.
Oh, thanks for clearing that up.
So I found a strange issue with CEmu: When CEmu is running, ePSXe Playstation 1 emulator will not load any game. It will either freeze (requiring killing the process) or remain stuck on a black screen. Closing CEmu fixes it.
Does the opposite situation of ePSXe PS1 emulator running and in a working state, and then launching an instance of CEmu which does not work, occur ?
Quote from: Lionel Debroux on March 23, 2016, 08:13:28 AM
Does the opposite situation of ePSXe PS1 emulator running and in a working state, and then launching an instance of CEmu which does not work, occur ?
Nope, CEmu launches fine in that case. It's only the other way around that I have problems. Not that it's likely to happen much, especially to other people, but I thought I would let you guys know, in case there might be similar problems with other softwares. Also I think I use OpenGL plugins with ePSXe, so maybe it's related to OpenGL?
Also it seems the throttle crashes are still there, but not as much. Now if I uncheck the box, it only crashes about 1 seconds after starting to hold down keys.
The GPU things related to the keypad widgets will be gone eventually with the keypad overhaul by jacobly.
It should solve the issue...
Ah I see. Was this why Dudeman and someone else had troubles getting the emulator to launch after loading a ROM? I forgot. IIRC, Dudeman has on-board Intel graphics from almost a decade ago.
Quote from: DJ Omnimaga on March 29, 2016, 02:32:54 AM
Ah I see. Was this why Dudeman and someone else had troubles getting the emulator to launch after loading a ROM? I forgot. IIRC, Dudeman has on-board Intel graphics from almost a decade ago.
Probably. It's actually from 1998. <_<
Darn, it's even older than I thought then. I had a 8 MB graphic card from Intel and all it could run was UT99, Stsrcraft, TI Flash Debugger, PindurTI and Virtual TI.
Yeah, I know. I can't even use my Acer Aspire now due to a critical charging port error that also melts my computer's casing. Until the charging port's fixed, I'll be managing and working with a Lenovo x61s(a Thinkpad). I'll see to its own graphic drivers and then test CEmu on it.
Random side note: This Thinkpad has a UK keyboard with this on it: ¬
So I can do this: (¬_¬)
I've added (main commit (https://github.com/CE-Programming/CEmu/commit/4eb7c63af02dea772427420b5cd84ae4d94504f7)) a feature to CEmu's GUI, allowing to visualize some variables' contents (programs, equations, numbers), from the variables dock panel.
For variables larger than 500 bytes, you have to double-click on the variable's cell in the table, as indicated.
Moreover, the display popup has a button that lets you toggle between displaying the original content and a "reformatted" one, useful when you want to see reindented Basic code :D
This feature leverages code from tivars_lib_cpp (https://github.com/adriweb/tivars_lib_cpp) :)
It looks like this:
(https://i.imgur.com/TJXrssg.png)
Good job. I liked that feature in WabbitEmu but you seem to have taken it even further :D. Can we export variables?
Yeah, you can select them and click on the "Save select" button
That's good. Any chance of drag-and-drop support in the future? Also, what was cool with WabbitEmu was the ability to drag and drop screenshots from the screen to an image editor or WIndows Explorer.
Could you create an issue about drag and drop support on https://github.com/CE-Programming/CEmu ? The open issues list contains nothing of that sort, AFAICS :)
I really need to learn how to use Github properly. The last time I reported a bug there I was lambasted by the author for not using Github properly. I'm way behind since it's not common to see TI-BASIC projects hosted on Github. <_<
Github might've been especially useful when you had TI-BASIC games with a whole lot of components.
Yeah true. Strangely, Github doesn't seem to be commonly used among Basic programmers. I think it's because we can open the code on-calc or several editors, even if the program is locked. But it can be handy for backing up or when people wants to help.
Yeah. A whole lot of programs are lost by data crashes and what-not. :(
But what I get about editing on-calc is that everything is at your fingertips, and you can do it anywhere.
Yeah I agree, and if you are used to typing on the calculator keypad, then entering commands is very fast since you just insert tokens. We should stop hijacking this topic, though. :)
I wonder if new CEmu features are being worked on right now?
Not so long ago, we were still trying to investigate the timing/delay issue sometimes visible if you do a timed pause (either correct on some computer (and not always), either not on some other computers, where it would take exactly twice the time). No luck finding where the bug comes from, yet...
More recently, Jacobly has been experimenting with USB-related things (https://github.com/CE-Programming/CEmu/tree/usb) (and it's not very easy).
Things to figure out before a v1 release, hopefully: https://github.com/CE-Programming/CEmu/milestones/v1.0%20target
I see. Is it related to the calculator clock or the emulator running faster/slower than the real calculator? I am not tech-savy about that stuff.
On a side note, sometimes I noticed that APD won't work in CEmu when it's in the background. I don't know if it's because the emulator is running in the background while I use TokenIDE or browse the web, or if it's because of the weird CE Textlib hax I am using, but I doubt it's the latter because I never saw it happen on a real calculator in the entire time I've been abusing CE Textlib.
Good luck on fixing the three issues for v1, the timing issues and the USB things :)
Bump for feature suggestion:
In the calculator variable browser, would it be possible to make it so that if only 1 variable is checked, that it allows us to save it as is on the PC rather than a group (8xg) file? TokenIDE doesn't support ungrouping so it's annoying to have to open TI-Connect CE all the time to ungroup the file prior opening it in TokenIDE.
EDIT: Even worse: TI-Connect doesn't have any option to ungroup files (you can only edit them).
Also bug report: Sending a program to the emulator while the variable list is open freezes CEmu.
Quote from: DJ Omnimaga on April 27, 2016, 01:13:23 AM
Bump for feature suggestion:
In the calculator variable browser, would it be possible to make it so that if only 1 variable is checked, that it allows us to save it as is on the PC rather than a group (8xg) file? TokenIDE doesn't support ungrouping so it's annoying to have to open TI-Connect CE all the time to ungroup the file prior opening it in TokenIDE.
EDIT: Even worse: TI-Connect doesn't have any option to ungroup files (you can only edit them).
Also bug report: Sending a program to the emulator while the variable list is open freezes CEmu.
Awesome; thanks for the bug reports :) All of these have been fixed and pushed to the repository, and should hopefully be in the builds directory within the next 48 hours or so.
Good to hear :). On a side note, I am curious about how up to date is the TI-Nspire CX version of CEmu compared to the PC version? Someone reminded me that CEmu was available for the Nspire CX recently and I was curious. Also I wonder if it runs at full speed?
I haven't touched the CX version since the first time I tried to port it :P
I wasn't full speed nor very usable (only 16bpp was supported as I was doing some fancy LCD hack and not taking into account any settings the CE might have) - basically only a proof-of-concept showing that it's feasible, though it's not a very enjoyable experience (at least with the way I ported it, it wasn't that great, maybe there are optimizations to be done, but then again, I don't really see where, since it was already doing the bare minimum)
Hm I see. Sorry to hear that it's not fast. I guess it was a nice try, though. Hopefully there is a way to make it faster.
A few updates I've made recently :
- Fix possible crash at launch after initial setup
- Better variable list view: now sortable, has a context menu to show item in memory and launch programs directly
- Fix LCD-related issue (bad masking on LCD port write handler)
- Fix Mac UI spacing in the popout LCD
- Various minor bugs fixed
A bit before that, Mateo had fixed a crash related to breakpoints/watchpoints handling in certain cases, and added some port mirroring support.
More details: https://github.com/CE-Programming/CEmu/commits/master
Also, good news,
jacobly resumed his work on the new keypad, lighter, prettier, faster, more customizable, more powerful, etc. :P
pretty nice. When is there an official build coming out?
Probably when the new keypad is ready and DMA has been figured out enough to be emulated correctly.
That's basically the two things todo before a good official v1.0
I should really update my copy of CEmu. I am way behind and I am curious if newer ones fixed the weird static on Sprites v3.x startup that doesn't happen on a real calc (or if this new update itself fixes it). Thanks for the great work on this :)
On a side note I was considering making a sub-forum for this if you would like one. It could make it easier if you want a release topic to showcase the biggest updates and a general discussion/help topic plus it would give the project extra visibility (like WabbitEmu on Omni back then)
Perhaps at some point CEmu can emulate the calculator in 3D, like 3DNES.
That would be cool actually, but I wonder how sprite tracking would work?
Bug report: Emulator doesn't handle 8xg file transfer properly. When sending a 8xg file to the calculator, it only ungroups the first program that was in it. Also there's no way to send the group without auto-ungrouping it.
Hm, yeah, I think that makes sense: in sendVariableLink() (link.c), the file size isn't read, only the var size at 0x39, which corresponds, in a group, to the first variable.
Since groups are just files concatenated, it might be enough to just loop on that main part of the code as long as more variables are there...
I'll write an issue on GitHub
The "only 1st file being ungrouped" bug is actually present on several other emulators or older versions. Even Flash Debugger and WabbitEmu had it at some point in the past. But since many old games, as well as SourceCoder exporting feature, uses groups, having 8xg support would be a nice addition to CEmu.
Not that we need it much for older games, since they are for monochrome calcs, but some people might still want to try them anyway or port them. Plus there's no way to bulk-export SC3 files into a zip file rather than a 8xg.
So I encountered another strange issue, but I had similar ones in the past. I have an hard time recreating it, though:
Sometimes, during animated GIF capture, keyboard controls will become much less responsive. In Wal-Rush! CE, for example, most keypresses are missed, while in one occasion in Calcuzap the Left and Right arrows stopped working until I stopped GIF capture.
Quote from: DJ Omnimaga on July 24, 2016, 05:40:30 AM
Bug report: Emulator doesn't handle 8xg file transfer properly. When sending a 8xg file to the calculator, it only ungroups the first program that was in it. Also there's no way to send the group without auto-ungrouping it.
Fixed this, hopefully it will be updated in the builds soon. There are actually two types, 8xg files which are just concatenations of variables in a linear order, and another where the 8xg is the variable itself. It's impossible to send some groups without auto-grouping them if they fall into the first category, because there is no name for the group nor does it have any structure. BTW, groups are now .8cg files. :P
Glad to see it fixed. So few TI emulators handle 8xg files properly, even though the format has been out there since 1999. I didn't know there were two types, though. Also I didn't know they were 8cg files either. People should be careful when uploading CE programs, because I swear I saw some 8xg out there.
I regret to inform you that my VPS is going to be shutdown for the foreseeable future due to money issues. This means that CEmu will not have nightly builds hosted by me until I can maintain $20/month specifically for the VPS. Thank you.
Thanks for all your help! I'll look around :)
Thanks for your contributions Pi. I hope your money issues aren't causing you too much troubles in real life. Good luck! :3=
To appease the minds of some people:
Quote from: AdriwebQuote from: KermMartianQuote from: pimathbrainiacI regret to inform you that my VPS is going to be shutdown for the foreseeable future due to money issues. This means that CEmu will not have nightly builds hosted by me until I can maintain $20/month specifically for the VPS. Thank you.
I'd be happy to take it over here on Cemetech if that's desired. Let me know.
The TI-Planet server could probably be an alternative as well, however:
Travis and/or OBS can be used for deployments, as it's been done for some repos already, so it would be better if it's directly integrated within GitHub.
Alberthro and I (and Vogtinator for Firebird) are looking into that.
I think there was another mirror, right? But it would be nice to have multiple mirrors in case one or two are down or blocked on some connections.
yes, alberthro's builds, although they are not exactly the same (but there are more options)
Ah right, that was him. I hope they remain online. :)
And as a continuation of
Quote from: Adriweb on September 13, 2016, 05:13:00 PM
To appease the minds of some people:
Quote from: AdriwebQuote from: KermMartianQuote from: pimathbrainiacI regret to inform you that my VPS is going to be shutdown for the foreseeable future due to money issues. This means that CEmu will not have nightly builds hosted by me until I can maintain $20/month specifically for the VPS. Thank you.
I'd be happy to take it over here on Cemetech if that's desired. Let me know.
The TI-Planet server could probably be an alternative as well, however:
Travis and/or OBS can be used for deployments, as it's been done for some repos already, so it would be better if it's directly integrated within GitHub.
Alberthro and I (and Vogtinator for Firebird) are looking into that.
Quote from: pimathbrainiacI'm going to put the server back online for a few minutes so I can make a backup. So long as you guys are running linux on your servers (because I was using mxe as the environment, which requires linux :P), I don't mind giving both of you the relevant portions of the backup.
Cool. I wonder if CW would be able to host such thing? Would it take too many resources and disk space?
Quote from: DJ Omnimaga on September 14, 2016, 05:35:36 AM
Cool. I wonder if CW would be able to host such thing? Would it take too many resources and disk space?
I probably won't mind. Please contact me if you want to host things at CW.
Also, you can definitely host builds on GitHub, corresponding to tags in git, in the releases section of the project.
Does Github support automated builds?
I don't think so, but it does integrate with such services.
Ah ok. I was wondering since most people seemed to provide builds off-site instead of on Github.
I've updated the link (https://git.io/vio5e) to alberthro's appveyor deployments for now, until we have something more directly integrated to the upstream repo
FYI, I've pushed some commits on tivars_lib and CEmu that make it able to now read/preview lists and matrices :)
(https://i.imgur.com/N0RtZMr.png)
(Also, some bugs in the Real vartype handler have been fixed)
Nice. I always wondered if that would be possible. :)
One nice feature by the way would be that thing WabbitEmu had when drag and dropping files into the screen. One side of the screen let you send the file to RAM and the other side to Archive. Being able to send some files straight to archive would be handy.
Complex vartypes has been added as well, recently.
Also, jacobly's new keypad has been merged into master and Mateo quickly added skin support:
(https://i.imgur.com/vp3c1B4.png)
It should look fine on Linux, Windows and Mac, now, too, thanks to some fine-tuning from the three of us on those platforms.
But on a more serious/developer-oriented note, several core fix/additions have been committed, and more are coming hopefully soon.
Only DMA stuff is now required for us to release a v1.0 :)
Looks pretty good. Nice work :)
Quote from: DJ Omnimaga on September 18, 2016, 11:04:53 PMOne nice feature by the way would be that thing WabbitEmu had when drag and dropping files into the screen. One side of the screen let you send the file to RAM and the other side to Archive. Being able to send some files straight to archive would be handy.
Post and you shall receive :) Dropping anywhere other than the screen will send it based on the file properties.
(https://usercontent.irccloud-cdn.com/file/shaVxKLF/cemuimg.png)
Isn't that nice :D
I've also added smooth interpolation for < 100% LCD scaling, as well as a -u/-unthrottled CLI option (Hayleia needed that one :P) to launch CEmu without emulation speed throttling.
Quite a few commits lately :)
I created a buildbot for my server so there are now windows CEmu builds for 32-bit (http://104.238.135.171:8080/CEmu/master/latest/CEmu32.exe) and 64-bit (http://104.238.135.171:8080/CEmu/master/latest/CEmu64.exe) which are updated every time someone commits.
Glad to see skin support and sending to archive added :D
On a side note, I noticed that VTI has no keyboard key assigned for the ON key O.O (I tried every single key on my PC keyboard, to no avail)
I added 83PCE's exact vartypes handling:
(https://i.imgur.com/EM4pZ2S.png)
Is there a version of CEmu now that works properly(for the most part) and works on Windows XP or Vista computers and graphics?
Quote from: jacobly on September 28, 2016, 07:13:19 PM
I created a buildbot for my server so there are now windows CEmu builds for 32-bit (http://104.238.135.171:8080/CEmu/master/latest/CEmu32.exe) and 64-bit (http://104.238.135.171:8080/CEmu/master/latest/CEmu64.exe) which are updated every time someone commits.
Hopefully this :)
It works great on my computer! Speedy and everything! Thanks!
Only one issue: On the keypad, the green alpha letters sit on top of the 2nd functions.
I think you may need an updated version, try here: http://104.238.135.171:8080/CEmu/master/latest/CEmu64.exe
Oh nevermind, it is like that on windows.
Oh, okay.
Major bug when transfering files:
1) Open the variables list in the emulator (which seems to pause emulation) to save files on your computer.
2) Forget to resume emulation
3) Drag and drop some files from your PC to the emulator screen to transfer them
4) Emulator will freeze, to the point where your PC might even stop responding for a few seconds
5) Restart the emulator, only to find out that none of the keys are responding (keyboard and the on-emu keypad). Resetting the calculator, reloading the ROM and restarting the emulator won't fix it.
6) Basically, the bug causes keys to stop responding entirely and the only way to fix it is to close the emulator, rename the ROM file then selecting the ROM at the startup again. This will result into a "Windows has encountered error and must close", but if you hit Cancel quick enough, you can continue using CEmu again afterwards.
Reloading a saved state from when the bug was active will disable all keys again and force you to repeat step 6.
Quote from: DJ Omnimaga on November 14, 2016, 06:43:59 AM
Major bug when transfering files:
1) Open the variables list in the emulator (which seems to pause emulation) to save files on your computer.
2) Forget to resume emulation
3) Drag and drop some files from your PC to the emulator screen to transfer them
4) Emulator will freeze, to the point where your PC might even stop responding for a few seconds
5) Restart the emulator, only to find out that none of the keys are responding (keyboard and the on-emu keypad). Resetting the calculator, reloading the ROM and restarting the emulator won't fix it.
6) Basically, the bug causes keys to stop responding entirely and the only way to fix it is to close the emulator, rename the ROM file then selecting the ROM at the startup again. This will result into a "Windows has encountered error and must close", but if you hit Cancel quick enough, you can continue using CEmu again afterwards.
Reloading a saved state from when the bug was active will disable all keys again and force you to repeat step 6.
Fixed with commit e8b1ffd (https://github.com/CE-Programming/CEmu/commit/e8b1ffd922fd93a1bac4badc7cdff5106a541d5f). This just prevents file transfers using the screen when in this mode. Thanks for the report! :)
That's good to hear. :) Hopefully it should prevent accidents
BTW, I've started Lua scripting integration:
(https://i.imgur.com/YjtrCQL.png) (https://i.imgur.com/YjtrCQL.png)
Though what I think will be the most interesting is events-based things: the script could register/subscribe to some events (GUI or core ones), and do stuff when they fire.
I am not sure if I understand the use of Lua in CEmu, other than the script side of things. Is it for custom features/add-ons or are you adding Lua support to the CE?
This is for scripting CEmu itself, so as to be able to do things not possible in any other way before.
See this for some details: https://github.com/CE-Programming/CEmu/issues/19
Bug report: ICE Compiler no longer works in CEmu. Note that I have just updated to the most recent version of CEmu, the newest version of ICE and my ROM to 5.2.0 (same as on my calc), so I am unsure in which software the bug was introduced, but on my other version of CEmu, ICE and ROM 5.1.5, I could compile ICE programs fine. Now it just freezes once I press Enter.
EDIT: Also, you know how the LCD dims when you don't use the calc for 1 minute, right? Well, now in CEmu, even once you start using the calc again, the LCD still remains dimmed. The only way to fix it is to change the contrast.
(http://img.codewalr.us/cemubug.png)
That's because you didn't transfer at an empty homescreen. So you had an edit buffer open when you started transfers. This is not currently fixable without proper usb emulation.
Oh I see. I didn't realize it was transfer-related. I thought it was a newnbug with menus.
Quote from: Adriweb on November 14, 2016, 08:18:43 PM
BTW, I've started Lua scripting integration:
(https://i.imgur.com/YjtrCQLt.png) (https://i.imgur.com/YjtrCQL.png)
Though what I think will be the most interesting is events-based things: the script could register/subscribe to some events (GUI or core ones), and do stuff when they fire.
Some updates:
- Other bindings
- Syntax Highlighting
- An REPL Lua tab
(https://i.imgur.com/vtkwernm.png) (https://i.imgur.com/vtkwern.png)
(https://i.imgur.com/0rOIhSGm.png) (https://i.imgur.com/0rOIhSG.png)
(https://i.imgur.com/qyJs4mrm.png) (https://i.imgur.com/qyJs4mr.png)
I've just added quite a few new Lua bindings, for things like GUI/emu/debug/autotester/etc. features.
For instance:
(https://i.imgur.com/HLLXHqk.png)
or...:
(https://i.imgur.com/INCImQB.png)
Source: https://github.com/CE-Programming/CEmu/commit/a2675e86f36717fed7aa23077b1b5526f36dc87c
Nice Adriweb. :) I wonder... how well does CEmu's automatic program loading on TI-Planet work? For example, can it detect if a file must be archived or not if in the zip file it's inside a folder called Flash or Archive? Also would the emulator be easy to integrate on other sites like CodeWalrus?
If I remember correctly, it's just calling the linking routine with the parameter to let the file itself decide if it should go to archive or ram (since there's a flag for that in the var header). Which also means that (in a perfect world :P) there shouldn't be archives with such directories, it's better if it's within the files already.
On TI-Planet it's extracting the zip on the server-side if needed, or just sending the thing if it's not an .zip.
It shouldn't be that hard to do the same on CW, though if you end up doing it, you might as well wait for an update, since there will have to be one (better keypad, libs transfer, some bugs to fix, etc.)
Ah ok. Back in the days TI Graph Link did not keeep such flag intact so all my old games had the RAM flag on by default or not at all IIRC. Even with TI-Connect, though, we usually tried to flag our programs as RAM files all the time, because back then, the only decent 83+ emulator available (PindurTI) did not accept files with the archive flag on.
Also yeah we are not in a big hurry. Besides, first we need to start splitting the archives per category because we're starting to have many games listed there, especially for the CE and regular 84+. Also yeah to be honest, while the online CEmu is awesome, I find the keypad to be a serious issue because it only uses the computer mouse, not keyboard, making it impossible to play games such as Oiram. Our only request for such emu on CW, though, would be that the user is forced to provide his own ROM image to use it and that it never gets stored on the server, since our site is hosted in the United States of DMCA.
CEmu v1.3 has been released! (https://github.com/CE-Programming/CEmu/releases/tag/v1.3)
Quite a big changelog - happy emulating!
________________________________________________________________________________
In other news, some time ago, for fun (until it's much cleaner and integrated properly with the rest), I've made a ti-basic live execution viewer thingy [...][/quote]
MateoConLechuga has since picked up the work I left there, and did quite some improvements to the code, while also adding awesome features :)
We now have:
- A new part of the GUI (not yet finalized ...) dedicated to TI-Basic debugging
- A visualizer (with highlighting) of the currently running TI-Basic code (and the contents of the temporary parser, in the tab next to it)
- The ability to see the current execution "live", or the current fetch (what the parser looks at then run - not necessarily very useful, but why not)
- The ability to pause and step / step next
There is more to come, and probably soon: GUI additions (most notably, variables and their current values), and breakpoints on TI-Basic code...
A quick preview:
(https://thumbs.gfycat.com/AnxiousSevereAstarte-size_restricted.gif)
If you want to try, it's on this branch: https://github.com/CE-Programming/CEmu/tree/feature/basic-dbg
Nice update for TI-BASIC programmers :O