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! Smile

I think most Cemetech members are following along as well as updates have been posted in this thread, so please by all means keep us appraised of progress! That's great news about file loading, and will certainly be helpful to me personally. Good luck with the disassembler for the debugging pane; although I am afraid I don't have the time to contribute my own expertise and experience in that area, I hope someone else will.
Have you gotten/considered getting in touch with Benjamin Moody/FloppusMaximus of the tilem2 team?
I don't know for Mateo, but I did consider it, though I haven't actually done so yet. I need to write him for other libti*-related matters anyway.
The goal was to push out something minimal, while reasonably usable, as quickly as possible. Integrating libti*, while possible due to the license, and desirable for limiting code duplication and further strengthening libti* (mutual benefit), wasn't exactly a step in that direction, for the very short term Smile
I have noticed that CEmu doesn't seem to follow all of the keyboard shortcut conventions from PindurTI and later WabbitEmu to which I'm accustomed, including [lshift] for [2nd], [rshift] for [CLEAR], [esc] for [MODE] (it looks like it might issue [CLEAR] instead?), and others. I'm not sure if the convention in use is a new one or is the one that TI SmartView uses; I think it might be more intuitive for the programming community to offer the PTI/WabbitEmu keyset.

In addition, KInfinity and pimath both seem to have problems getting the keypad to show up when building CEmu for Windows, and I can confirm under Windows 10.

Edit: I know that it's an outdated image format at this point, but given its history in the community, I'd be very interested in being able to create static GIF screenshots.

Edit #2:
chickendude wrote:
Have you gotten/considered getting in touch with Benjamin Moody/FloppusMaximus of the tilem2 team?
That actually brings up an interesting question in my mind (and not an antagonistic one, lest anyone misunderstand my tone): was there a particular design choice that made it preferable to start a new emulator rather than build CE support into TILEm? That would have saved the problem of licensing a z80 core created by a developer that as staid a community pillar as BrandonW has described as controversial, not to mention have significantly saved on development effort for screenshots, UI elements, and more.
KermMartian wrote:
I have noticed that CEmu doesn't seem to follow all of the keyboard shortcut conventions from PindurTI and later WabbitEmu to which I'm accustomed, including [lshift] for [2nd], [rshift] for [CLEAR], [esc] for [MODE] (it looks like it might issue [CLEAR] instead?), and others. I'm not sure if the convention in use is a new one or is the one that TI SmartView uses; I think it might be more intuitive for the programming community to offer the PTI/WabbitEmu keyset.

In addition, KInfinity and pimath both seem to have problems getting the keypad to show up when building CEmu for Windows, and I can confirm under Windows 10.


I believe the problem is with some missing files. I think I found the proper files and will test.

EDIT: got it working. It was a few missing files.
I got some win32 nightly builds up and running on my server: http://pimathbrainiac.me/CEmu/
Kerm: The CPU core was originally based off of z80e merely because I evaluated all of the other cores, and it was one of the simplest and easiest to read and port. A new emulator was decided because the CE is more based on the nspire CX, and there are virtually no similarities between any of the other emulators, other than the CPU core. I don't really care about the licensing, it has already changed a lot from the original. Also, it isn't even 2 months in. The keypad still has a long way to go, keypad equates are easily changeable in the code, and the plan is to make a window to change these, as in wabbit emu. Remember, the current state is still in development and a lot of things will be added and fixed before it is a user releaseable state. It was just publicly opened so everyone could combine knowledge, rather than keep it closed. People should not be using it for program development at this state. Sure, I'll add in single frame gif outputs too. Smile Also, nice work pimath Smile
So, shoudl we be submitting bug reports of the beta versions of this program, like the really obvious bugs? I have a few from pimaths build above.
Caleb_Hill wrote:
So, shoudl we be submitting bug reports of the beta versions of this program, like the really obvious bugs? I have a few from pimaths build above.

No, because the program isn't in beta stages. It's not even in alpha stages. It's still in development, and will remain as such until we find time to finish it. Of course, help is much appreciated. Smile Haha, of course you can post bug reports though. Don't know why we are providing builds when everything is still broken though :p
MateoConLechuga wrote:
Kerm: The CPU core was originally based off of z80e merely because I evaluated all of the other cores, and it was one of the simplest and easiest to read and port. A new emulator was decided because the CE is more based on the nspire CX, and there are virtually no similarities between any of the other emulators, other than the CPU core.
Fair enough; thank you for explaining your reasoning.
Quote:
The keypad still has a long way to go, keypad equates are easily changeable in the code, and the plan is to make a window to change these, as in wabbit emu.
Perfect.
Quote:
It was just publicly opened so everyone could combine knowledge, rather than keep it closed. People should not be using it for program development at this state. Sure, I'll add in single frame gif outputs too. Smile Also, nice work pimath Smile
Hooray, and thanks. I may ignore you on the program development front, but I won't pester you with too many bug reports at this stage.
Hello again! There is now a disassembly view (not very useful at the moment, but it works). I have ideas on how to perform backwards disassembling, but I was wondering if anyone had a super neat way of doing it. I'm still surprised by how fast wabbitemu is able to fill the disassemly table so quickly. Does anyone have any thoughts on this? Thanks! Smile
I can at least tell you what I do in jsTIfied: I start disassembling at the beginning of an $FF-byte-long block, and because z80 opcodes are relatively unambiguous, it will naturally fall into correct opcode boundaries very quickly. If you want to be safer, you can start XX bytes (at most $40 or $80, I'd say) before the beginning of the pane, and it will almost definitely be correctly-aligned by the desired starting address. There's no point going back to an arbitrary point like the beginning of memory, obviously, because at any point you can run over data sections that will throw you off.
Thanks! That works perfectly, and I can simply test if it syncs with the desired pane, and if not, repeat up to 6 bytes backwards until it does. Still might have issues with data, but there's really no way to differentiate between data and code 100%. Anywho, you can now set breakpoints and single step through code; yet I was wondering about stepping over. It appears that if you hit an instruction such as ldir or some repeating function, it executes it until completion, and moves to the next line. However, for calls and subroutines, are these entered? If so, if the call goes into an infinite loop, when does it return? Thanks! Smile (Also, I will probably have a question about stepping out, so if anyone has any advice there, feel free to share Smile )
On TilEm2, stepping over (i assume that means running until the next line and not skipping a line) will just pause the debugger until it's reached the next line. If a call ends up being an infinite loop, you can see what's going on in the LCD and press keys etc. but the debugger is blocked until it reaches the next line (or perhaps a ret? I can't recall off the top of my head what happens when the stack pointer gets changed and returns to a different location). You can of course pause the debugger to see what code it's currently running within the loop, though.

EDIT: As for stepping out, i assume it should run until reaches a ret at the current SP value (so calling other routines won't cause the debugger to stop, since the SP is different). Again, i'm not sure what should happen if the SP gets changed, but i don't think that's a very common scenario.
Thanks chickendude! That makes a lot more sense now Smile

Anywho, somewhat of some updates:

1) Pipeline is now emulated
2) GIF bug has been repaired
3) Debugger shows disassembly view, with ability to jump to certain addresses
4) Breakpoints now work properly, and can be set from the disassembly view (Right click to toggle)
5) "Set to PC" right click added
6) Step and Step Over have now been implemented

Some big todos:
1) Finish the Hex Editor views
2) Fix some file transfer bugs
3) Make window for altering keyboard equates (Redacted)

4) Fix single GIF frame output
5) Fix LCD interrupts
6) Add slider for emulation speed
I started testing CEmu this morning and so far I am VERY impressed.

I had asked for a couple of things that Mateo was kind enough to look into:
- Re-sizable LCD pop-out window
- Remembering last directory when sending files
- Emulation speed (tricky one)

I second the suggestion that the keymap be updated to match other emulator's. Though looking at the source that is a simple fix.

I managed to test some parser hook stuff too:
Awesome, looking great Smile

I added these things in recently, so that should be nice:
tr1p1ea wrote:
- Re-sizable LCD pop-out window
- Remembering last directory when sending files


As for the following, I will change those as well to match the previous emulators' equates at some point, but Qt doesn't seem to support a difference between left and right Shift, so I will look more into that Smile
tr1p1ea wrote:
I second the suggestion that the keymap be updated to match other emulator's. Though looking at the source that is a simple fix.


EDIT: Actually, the above thing about keyboard equates has been redacted. It simply doesn't make sense to break functionality of the shift key, as it is now usable to type things like parentheses, use of the addition/subtraction button, and many others. The current layout works pretty well once you get used to it; the only differences are the functionality of the [CLEAR] and [2ND] keys:

Clear - Backspace
2nd - Tab/Semicolon

Edit 2: Mode has been remapped to both the Esc and Home keys, to maintain some standard.
New screenshot showing some of the latest features:
So key will not be configurable then? Ahh well.

If you have the file transfer window open it appears that the calc can still enter APD ... it doesnt appear to affect the transfer however.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, ... 13, 14, 15  Next
» View previous topic :: View next topic  
Page 2 of 15
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement