Latenite - 1.0.6.1 Update [Monday 20/08/2007]

Post by **tr1p1ea** » Mon 22 May, 2006 11:37 am

Looking really good Ben. Coding and debugging is going to be so much different from the old days ... for the better!

.

Jim e · Post by **Jim e** » Mon 22 May, 2006 12:15 pm

That looks nice, I see the break points are tied to the source, can I assume that I can actually see the source in the debugger?

Post by **benryves** » Mon 22 May, 2006 12:27 pm

There is no debugger (in terms of a disassembler), though as it sits on top of Latenite it'll highlight the lines on the original source when it hits breakpoints.
Breakpoints are inserted using the .breakpoint directive in Brass, or by right-clicking an address in the memory viewer and selecting 'Add Breakpoint'. As this (latter) method has to guess where the breakpoint's been added is, it'll only add the file/line data if the breakpoint falls on an existing label.
Brass exports a debugging file (in the form of an XML document) containing all the modules, labels and breakpoint information.

Timendus · Post by **Timendus** » Mon 22 May, 2006 3:15 pm

That's pretty nice. It looks so much clearer than other debuggers, plus it uses PTI, plus it works as part of Latenite... I'm going to love this

The only thing that bothers me in working on my current project (CLAP) is that when I run PTI from Latenite, I get only one emulated calc. So I still have to run a seperate PTI with four screens, build the binary, drag and drop it to all four PTI screens, connect them with the virtual hub, and run the program on all four... Quite annoying, especially when I manage to crash them all, but I don't see any way to automate that. Suggestions, Ben or CoBB..?

so much different from the old days ... for the better!

Heheh... Back when I wrote code in Notepad, compiled on the command line with TASM, sent the binary to my calc, borrowed my brother's calc again, sent the program over to his calc, connected them, ran the software, watched everything crash hopelessly, and went back to Notepad... Nowadays I complain that I have to drag and drop a file

Post by **benryves** » Mon 22 May, 2006 3:23 pm

Multiple calculators is mainly up to CoBB at the moment, as there's no way of me getting the emulated calculators talking to each other*. Same goes for editing memory or registers - until CoBB exposes that functionality in PindurTI, I can't do anything about it. When that's done, I'll extend the scripting (which has already been reworked) to support setting up multiple calculators.

However, at least now I've caught up with some of the features that CoBB had added.

One feature of Latenite I should add that'll probably be useful is a Deploy button that runs every build script for your project - currently rebuilding for each platform is a little tedious!

*Though each emulated calculator runs x cycles every 'frame', each emulated calculator is run separately. As the calcs don't all run synchronised on the same clock, it could make linking rather interesting, unless CoBB adds a run-all sort of command.

Post by **kv83** » Mon 22 May, 2006 4:08 pm

Sooo... the EM "workaround" is going to be fixed aswell, right?

CoBB · Post by **CoBB** » Mon 22 May, 2006 4:12 pm

Timendus wrote:The only thing that bothers me in working on my current project (CLAP) is that when I run PTI from Latenite, I get only one emulated calc. So I still have to run a seperate PTI with four screens, build the binary, drag and drop it to all four PTI screens, connect them with the virtual hub, and run the program on all four... Quite annoying, especially when I manage to crash them all, but I don't see any way to automate that. Suggestions, Ben or CoBB..?

For the time being you can substitute drag and dropping with that lovely little send.exe, if you modify it a bit. Basically you can simulate a drop into any desired slot by sending a WM_COPYDATA message to the PTI window (can be found by looking for the "PindurWnd" class, see send.c) with lParam pointing to the COPYDATASTRUCT with the following data at its lpData:

ofs+0: slot number; 255 for current slot
ofs+1: strlen(path) (yeah, 255 characters at most

)
ofs+2..: null terminated path

The current executable has the slot value hardcoded to zero. With a bit of extra tinkering you can extend it to be read from the command line, and there you go.

Post by **benryves** » Mon 22 May, 2006 4:24 pm

kv83 wrote:Sooo... the EM "workaround" is going to be fixed aswell, right?

When I get around to it, yes. Just nag (I now have work that extends in to what was free time, the result being barely any time to work on anything. Sorry).

Timendus · Post by **Timendus** » Mon 22 May, 2006 5:29 pm

benryves wrote:until CoBB exposes that functionality in PindurTI, I can't do anything about it. When that's done, I'll extend the scripting (which has already been reworked) to support setting up multiple calculators.

Thanks a lot in advance

One feature of Latenite I should add that'll probably be useful is a Deploy button that runs every build script for your project - currently rebuilding for each platform is a little tedious!

Ah, yes, I intended to request that

For the time being you can substitute drag and dropping with that lovely little send.exe, if you modify it a bit.

I guess I could if I knew what I should compile it with

I'm not very good with compiled computer languages. I guess it's C? So I should use gcc for Windows or something?

CoBB · Post by **CoBB** » Mon 22 May, 2006 5:53 pm

Timendus wrote:I guess I could if I knew what I should compile it with I'm not very good with compiled computer languages. I guess it's C? So I should use gcc for Windows or something?

Ah, you. I updated it just for you.

The first parameter should be a single-digit number, preferably between 0 and 3, and each of the following ones will be interpreted as a file name to send.

Timendus · Post by **Timendus** » Mon 22 May, 2006 6:05 pm

You're the man!

Thanks CoBB!

Andy_J · Post by **Andy_J** » Mon 22 May, 2006 10:31 pm

benryves wrote:There is no debugger (in terms of a disassembler), though as it sits on top of Latenite it'll highlight the lines on the original source when it hits breakpoints.

So SMC will break it horribly?

Post by **benryves** » Tue 23 May, 2006 9:30 am

Indeed. I can't really do much about that :\

silver calc · Post by **silver calc** » Wed 24 May, 2006 8:40 pm

Been a while...
Yes, proposing to drop Pindur TI wasn't such a great idea.

Reasons for this (AKA pros):
I'm sort of new to programming ASM, and Pindur TI doesn't have a keyset for use with the keyboard like Tilem and VTI/Flash Debugger.
It also won't support my 83+ SE (As previously mentioned).

Reasons for my bad comment (AKA cons):
If you say it emulates the calc hardware better, I'll take your word for it (It can adjust the calc speed, which isn't in Tilem or VTI/Flash Debugger).
Pindur TI also seems to work really well with LateNite (can create a .debug file to execute anything!)
It's suppose to have breakpoints (haven't seemed to get this to work, yet)
The screen is much better than Tilem or VTI/Flash Debugger

As I can see, the cons out way the pros

.

Post by **tr1p1ea** » Thu 25 May, 2006 4:20 am

People just think that the emulator isnt as 'complete' because it lacks a user-friendly interface.

PindurTI is far more accurate than any other 83+ emulator on a very low level. VTI does a lot of things incorrectly which is the reason why so many people can make programs run in VTI when in fact they will crash if ran on actual hardware. VTI doesnt implement proper interrupt timing, not to mention a lot of the ports are not implemented and no Flash support. TilEm has Flash and APP support, but it still inherents most of VTI's other deficiencies.

For developing programs that dont need super accurate timings, dont use flash and dont have to use certain ports, VTI is ok. If you need those things plus you want a good screenshotter, a decent debugger and if you want to see how your program will most likely run on actual hardware, use PindurTI.