KermMartian wrote:
That's awesome! I'll have to put together a secondary batch file for the Doors CS SDK that lets it launch WabbitEmu and load DCS and the file created to allow for easier testing.
You mean you're gonna make what I made with SPASM?
Code:
import os
filename = raw_input()
os.system("wabbitemu.exe DoorsCS7.8xk %s" % filename)
This could already be done before, so yeah I'd like it in DCS7 (even though I have it already, as default would be cool)
If all you're doing is sending files to wabbit you don't need the DLL, you can pass them as args in on the command line. The DLL provides access to the internals of the calculator (memory, apps & symbols, ports, etc). If you don't need access to that you can just as easily use a batch file
ScoutDavid wrote:
Code:
import os
filename = raw_input()
os.system("wabbitemu.exe DoorsCS7.8xk %s" % filename)
Python feels like overkill to me when you can just have a batch file that does "wabbitemu.exe DoorsCS7.8xk %1". 
KermMartian wrote:
ScoutDavid wrote:
Code:
import os
filename = raw_input()
os.system("wabbitemu.exe DoorsCS7.8xk %s" % filename)
Python feels like overkill to me when you can just have a batch file that does "wabbitemu.exe DoorsCS7.8xk %1".
Sorry I don't use Batch, I'm a Linux user. But yeah it can also be done in Bash.
However, Python makes it cooler because I can make it a text editor with a save function that calls wabbitemu, like Assemblex.
Funnily enough, the bash script "wabbitemu.exe DoorsCS7.8xk $1" would do the exact same thing.
You certainly could make an IDE/editor that invokes it, although I'd prefer to use vim in one terminal window or tab to edit code, and the script in another terminal to assemble and run the program.
Update to the wabbitemu debugger, you can now view 24 bit addresses. Also fixed a small bug with resending files to a different location
SPASM is giving me some grief. In the following file:
Code: .org $4000
ret ; Safety
OutputProtectedPort:
ret
The output is a single 0xC9.
I'm outputting to a .bin file.
Solution: use Brass?
What makes you think that Wabbit is at fault here
Why settle for an inferior assembler?
Kerm it wont post for me. Anyway I already told him the solution it was use whitespace before the first ret.
BuckeyeDude wrote:
Why settle for an inferior assembler?
Kerm it wont post for me. Anyway I already told him the solution it was use whitespace before the first ret.
Why settle for an inferior assembler is my point exactly. Glad to hear that you solved it. While we're on the subject, what's happening with WabbitEmu/
I work on it when I have time but time has been lacking unfortunately. Been doing some work on the debugger to make it a little better for more veteran assembly coders to track down difficult bugs
BuckeyeDude wrote:
I work on it when I have time but time has been lacking unfortunately. Been doing some work on the debugger to make it a little better for more veteran assembly coders to track down difficult bugs
That would be greatly appreciated. And if you could improve the linking ability, you'd give me a reason to switch back from using PindurTI for all my CALCnet testing.
*bump* For the first time in a long time, I powered up Wabbit because I didn't need PTI for linking for what I was testing; I was surprised to discover that regardless which side of the screen I dragged a program onto, it ended up in RAM. Is this a known glitch?
@Kerm yes this issue was fixed a while ago. I believe it was tifreak8x who found and had me fix it.
Also in the land of the wabbit debugger, I've finished implementing 24 bit addressing for both memory and disassembly (before I had implemented just the memory). I also implemented a watch tab a while back which is very handy for monitoring variables you store in memory (as opposed to having to switch places a lot in the memory tab).
I'm also in the process of documenting a lot of SPASM commands, as much of their functionality was a secret passed on to only the wisest and most experienced assembly programmers. Or whoever needed it and knew to talk to me. Hopefully this should help make clearer some of the nuances of SPASM, and reveal some particularly useful things (some of which were even new to me).
http://wabbit.codeplex.com/documentation
Download link for the lazies:
http://wabbit.codeplex.com/releases/view/44625
Buckeye, ah, ok. I had to downgrade from the latest version because it would slam my CPU to 100% for some reason; perhaps I'll try the latest build again and see if that issue went away.
The CPU issue is partially calc84's fault. There was an issue with interrupts not exectuing fast enough and the quick fix required a lot of extra code running each instruction. I'm working on a fix but its a change to how interrupts are handled
BuckeyeDude wrote:
The CPU issue is partially calc84's fault. There was an issue with interrupts not exectuing fast enough and the quick fix required a lot of extra code running each instruction. I'm working on a fix but its a change to how interrupts are handled
Would a glance at the PTI source help at all? I have a copy of the source under examination/modification for an upcoming project of mine.
KermMartian wrote:
Would a glance at the PTI source help at all? I have a copy of the source under examination/modification for an upcoming project of mine.
I have the source of some version and while there are a lot of things wabbit stole, interrupts aren't one of them.
Also progress.
I am using the WabbitCode 2.2(1) for Mac OS X, on OS 10.8.2. The software crashes frequently, often when I attempt to save.
Also, when I create a project and set my "target input file" to the main Z80 source file, then I attempt to save and the main source file's name (in the project view only) changes to a random string of numbers, plus the extension. The build configuration reports that it is broken and any subsequent attempts to save cause a hang then crash.
I suspect you need to pester on Revsoft, where active development is sort of taking place. Also look at Github.
