So this is my project of creating an 83+/84+ app that is basically something between Calcsys and an emulator. No, not something between them, it's just both of them. Two people showed interest (Xeda and LogicalJoe, though the latter was sceptical), which was my condition to continue development. Development is now ongoing.

I'll explain the exact inner workings of it in the style of a Q&A:
  • How do you get the RAM you need to run this if you want to give it to the emulated program?
    I create an appvar that contains the app's data. This RAM area is then protected by the emulator and you should have no reason to access it. Any extra RAM pages your model has are free to be used by you. This also ensures compatibility with the 83+ (basic edition)
  • What exactly are you emulating?
    The Z80 CPU, memory banks (RAM), and the parts of the hardware that I need to emulate (which is: interrupts, keyboard, LCD, timers, flash unlock mechanism...)
  • What about the I/O port and USB?
    These are not emulated, but connected immediately to the real calculator. Interrupts are also forwarded. That way, TI-OS just takes care of handling it, while I supply it with the ports it needs. Actually, all non-emulated ports and interrupts are just forwarded. Mirrored ports
  • How much of the OS do you use?
    I use BCALLs to allocate the appvar when starting, to remove it when exiting, to archive the settings appvar, and to exit the app. Everything else is directly using INs and OUTs (as we can't have the OS interfere with its emulated self). This actually gives me an excuse to "reinvent the wheel" as they call it in the programming world, although I am borrowing some routines from Xeda (thanks for those, by the way).
  • What debugging features will there be?
    Disassembler, register view, ram inspector, view emulated LCD, hardware monitor, breakpoints/watchpoints/io monitor, base converter, step, step over, step out, run, a few basic alerts like stack overflow or rom write attemts.
  • How slow is it?
    Smart of you to ask "slow" and not "fast". It will probably be about 1000 times slower than the real calculator. You won't be playing games with this, but I'll probably add an option to speed up the interrupts so that TI-OS at least seems usable.
  • What can it all debug? Programs, apps, shell programs?
    Everything. When you run it, it immediately starts the emulator and goes to the homescreen. You can then stop the emulation, set a breakpoint to $9d95, continue, and start your program, and start debugging.
  • How do you exit the app?
    You see, the problem here is that the calculator's state might not be the same, which may cause all kinds of nasty stuff like memory leaks and ram clears. You have, in fact, several options:
  1. The user opens the debugger app from within the emulated environment. As the emulated calculator's state right now is identical to the real one, we can exit safely. The emulator detects that the app has been opened and gives you two options:
    1. Exit peacefully. (this is the safest way to exit)
    2. Restart the emulator.
  2. Pressing CLEAR in the debugger will give you three options:
    1. A simple bcall(_jforcecmdnochar) (warning for memory leaks included).
    2. Resume emulated as real (which means: copy the emulated calculator's state to the real calculator's state and continue where it left off) (this one does need to delete the appvar, which might cause a slight problem in some cases, although I have found a way to make the OS delete it when it can).
    3. Executing a RST 00 (warning for ram clear included).

Currently, this is the progress. Color shows progress, size shows how hard it is or how long it might take.
initialization 80% (I will now only have to add things once I need them)
GUI 0% (will split this into multiple parts once I get started with it, currently I just made it bigger)
disassembly 5% (let's just say that I have read some documents about decoding Z80 opcodes) (this is just converting an opcode to a string)
z80 emulation 40% (all of the instructions without prefix byte are implemented, but many still need to be debugged)
memory emulation 60% (can almost successfully read/write a byte from an address on the virtual calculator, but still need to implement watchpoint checking)
lcd emulation 100% (including timing)
interrupts 90% (still need to handle USB interrupts)
text printing 100 (uses a pretty fast custom 4x6 font)
keyboard 100% (including custom keymaps)
flash emulation 0% (unlocking flash, sending commands to flash, operating delay, etc)
flash driver 0% (this can unlock flash, send commands and wait until they are executed before returning to the app)
keyboard emulation 20% (this will not be that hard)
generic I/O emulation 0% (not that hard, just check if this port should be handled specially and otherwise just forward it to the real hardware, this also includes interrupts)

Original post 2020-02-22:
fghsgh wrote:
I've been thinking about this idea for a long time. It started because of two reasons:
  1. I want to extend Mimas to also have a debugger, to be a more complete IDE, making calculator development more practical. (though this would be its own app, not part of Mimas)
  2. The hardware emulation on most emulators is either not very good, or missing completely (I'm talking about USB for example, no emulator I know of emulates USB because we don't know well enough how it works).
Currently, I have everything planned out and written the initialization, lcd routines, and I have started the Z80 emulation itself. Now my question to the community is: will anyone benefit from this? Should I continue development?

The idea is this:

So, when making a debugger, I would need a complete Z80 emulator (written in Z80 of course). Every RAM access would be checked against a list of breakpoints or watchpoints and stop execution whenever for example a stack overflow occurs, as a basic measure to stop most RAM clears before they happen.

In order to emulate a program, the debugger itself would need enough RAM for itself. We can't take away any RAM from the debugged program though, so we need to find a way to claim some RAM for ourselves. My solution for this was to create an appvar and delete it on exit, and protect it from the emulated program (stopping the emulation when an attempt is made to change it).
Also, because the emulation will be very slowed down (the Z80 is 100% emulated so naturally, it can't reach the speeds of the Z80 that is emulating it), I need to reimplement the timers using emulated clock cycles to make sure the OS doesn't lock up.
Because the OS may change some flags or something and mess with the emulated program, I need to rewrite basic routines like _PutS.
Some hardware (like the link port) will not be emulated, but rather directly connected to the real hardware. Any interrupts that are received from the hardware are forwarded to the emulated calculator.
Also, why implement a dialog for choosing which program to run when you can equally well just emulate the OS and let the user run any program they want?

The planned feature list:
  • step, step over, step out, continue, pause
  • disassembler
  • RAM inspector
  • view LCD contents (including settings like contrast)
  • hardware monitor (like how Calcsys gives you access to I/O ports)
  • view/edit registers
  • view/edit stack
  • breakpoints, watchpoints, I/O listeners
  • configurable key layout
  • ldir dialog (just copy random blocks of RAM)
  • restore the current state of the emulated calculator to the state of the real calculator and continue
So once again, I will continue with this project if enough people (one or two) show interest.
I think it would be pretty cool tbh. I've considered it myself, but I never could find the motivation. I saw some of the comments in the chat, and I don't think it is too important that you strictly emulate stuff. I would personally want to use a program like this to test code that might crash, so a safe way to just step through code would be nice.
  
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
Page 1 of 1
» All times are GMT - 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