Dropping this topic here for me to remember. Essentially, I am in need of a way to test various z80 routines to verify their proper functioning. This project was looked at, but not as a way for testing, but as a way to make a katepart that will allow stepping through routines while writing them, logging memory accesses, registers, stack, etc. in-editor without a full emulator.
Either way, a unit testing system is planned as it will be needed for various GlassOS projects, such as gCAS3 and the FORTH-like language.
More on this later, but for now, just a reminder to work on this some more.
It's my duty to my projects to promote them, but the fact that jsTIfied is in Javascript makes it pretty easy to push random code or even opcodes at it. Plus it already has the facility to register watchpoints and breakpoints and all that stuff, so it might be possible or helpful to hook into that. On the other hand, connect that to something that isn't Javascript would be significantly challenging indeed. Good luck on this project, and I hope you come up with a good solution!
As much as I love jsTIfied, my guess is that you're better off hacking on the Wabbit core for this, since it's pretty modular C code and separate from the UI. Alternatively, if you want to go crazy and won't be messing about too much with timing-sensitive I/O stuff, dynamic recompilation would be reasonable.
I was thinking of a web solution as well. If there was an API exposed and documented that allowed me to push binary data to an address, control stepping, and catching all read/writes/port IO, then report back results (cross-domain for custom scripting and testing interface), then this would be possible.
However, having an offline version using my already-made z80 core with debugging features implemented that can be ran from text editors would seem more convenient for rapidly debugging and editing.
elfprince13 wrote:
As much as I love jsTIfied, my guess is that you're better off hacking on the Wabbit core for this, since it's pretty modular C code and separate from the UI. Alternatively, if you want to go crazy and won't be messing about too much with timing-sensitive I/O stuff, dynamic recompilation would be reasonable.
Speaking of modular C cores, PindurTI also has a really great core if you don't care too much about the TI-84+/SE series. Considering that one of AHelper's goal is GlassOS, which I believe only (?) runs on the TI-84 Plus calculators, that wouldn't help him.
Picked this up again, adding in memory access permissions, syscall hooks, assertions, and a nicer way to load binaries into memory.
The goal is to get some way to test out my floating point code and a new seecret project.
<edit>
Just added a form of memory access permissions. When trying to run code in memory without setting up permissions:
Code: ![HAL@HAL build]$ ./bfz80o
Memory Access Violation at 0100 due to User Execution violation in user mode. Register dump: 0101 bffc 01 02 00 00 00 00 00
Now, I added in a simple syscall handler for rst 0x08:Code: void syscall(Z80 *z)
{
if(z->getReg(regA) == 0)
{
// PutString
cout << "bfz80o::puts: " << z->memAt(z->getReg(regHL)) << endl;
}
}
Z80 assembly:Code: ![HAL@HAL build]$ cat test.z80
.module crt
.area _HEADER (ABS)
.org 0x100
xor a
ld hl,#text
rst #0x08
ret
text:
.asciz "Hello World"
Console output:Code: ![HAL@HAL build]$ ./bfz80o
ADDR SP AABBCCDDEEHHLL
0101 bffc 00020000000000
ADDR SP AABBCCDDEEHHLL
0104 bffc 00020000000106
bfz80o::puts: Hello World
ADDR SP AABBCCDDEEHHLL
0105 bffc 00020000000106
ADDR SP AABBCCDDEEHHLL
ffff bffe 00020000000106
AHelper,
Do you have a repository somewhere, or any documentation for this yet? Seems like it could be a nifty general-purpose tool down the road.
No repo set up yet, but I am slowly migrating my projects to bitbucket and github (migrating the ut2k4-supybot plugin repo from my own public repo server to bitbucket).
I can probably get this up on github eventually.
Cool =) I take it you ended up building it on top of C code of one sort or another?
All of the code is C++ built from nothing other than opcode charts. I really need to redo the opcode handling, it is a bit overkill in terms of decoding. I would hope to integrate some form of Lua or other scripting language to actually make this useful, rather than making you change the source of it :/
AHelper wrote:
All of the code is C++ built from nothing other than opcode charts. I really need to redo the opcode handling, it is a bit overkill in terms of decoding. I would hope to integrate some form of Lua or other scripting language to actually make this useful, rather than making you change the source of it :/
There's a really comprehensive z80 stress-tester out there (ZEXALL). Have you put your core through its paces yet?
It seems like a declarative language of some sort (e.g., something logic-programming-y) would be better suited to testing than something like Lua.
I'd stress test it if I had more than half of the opcodes implemented ;P
I'm just looking for something that can integrate into c/c++ nicely, I only have experience with python and lua integration, but any scripting language should be fine which is compatible with SWIG.
