Out of curiosity, how does the interpreter really work? Is it partitioned in a particular segment of code in the OS?

Also, does this thread belong in the TI-BASIC section, or is it fine here?

I think that this subforum actually makes more sense for this thread. Anyway, it's hard to give you a concise answer for your question, because the parser is a hugely complex and bloated beast, but I'll do my best to try. No, it's not fully segmented, although the bulk of the routines for the parser are indeed grouped together. There's the main engine of the parser that does lexing and deals with separating out things like arguments and operator order, then there are all the functions and bcalls that perform the actual operations, for example taking the cosine of a number. Many of those calls are affected by system flags, such as the degree/radian flag in the cos() example case.

I think I understand that the b_calls and flags are in their own isolated segments of ROM/RAM, but I'm more interested in the parser/lexer. Does the parser have its own special place in the OS?

BTW, is there any documentation on this or anything? I'm probably boring you with all my noob questions

It's been a while since I was looking into the interpreter, but here goes. Well, I don't really remember how it works, but it's not at all recursive as one would expect. It reads one byte at a time. I really wish I took notes on how it worked back when I was studying it. Maybe if you have more specific questions, I could answer some though.

Edit: there's some documentation on it, but I remember it being hard to find. I think the documentation for parser hooks has some relevant stuff in it though. TI's big secret is the part in charge of order of operations, I seriously doubt there is ANY documentation on it.

You could take a look at the following link for starters, but sadly, there is very very little documentation out there, because all the information out there has been gleaned when I have looked through to find how the TI-OS is breaking Doors CS or (mostly) when BrandonW has painstakingly looked through to try to figure out how it works. If you have the patience to go through the parser and map it out, you'd both find some very interesting stuff out and probably lose your mind in the process.

http://wikiti.brandonw.net/index.php?title=Category:83Plus:BCALLs:By_Name:Parser

Oh yay, sounds fun . Where exactly is the parser located anyways?

All over the place. The main entry point is _ParseInp, but once you got in, you end up skipping all over the pages. Indeed, one of the main reasons we ended up trawling through pieces of it was trying to track down how TI broke parserhooks in 2.53MP, and then coming up with awkward workarounds to deal.

The interpreter sounds a lot less enticing now. How do you study the parser, though? Do emulators work, or do you have to look into the calculator itself?

Emulators are great, since you can step through one instruction at a time and see where it's jumping around. Are you planning to do something with the interpreter?

I don't have plans to do anything practical yet. For now, I'm just curious . Also, assembly is starting to get really tedious with me, so I kinda want to take a short 'break'.

Don't start with something challenging, then, start with something more fun! A game perhaps? Messing with the DCS GUI? Trying out CALCnet? As far as tracing the parser goes, you could either do it by tracking control flow in an emulator, or tracing code in a disassembly. You'd probably want to try a combination of the two, so that you can jot down things like guesses for label names.

I dunno, I already programmed TI-BASIC games for a year. An assembly game sounds like fun, but I have no idea what type of game I should make; it seems that every genre has been taken or abused, and I'd need a lot of creativity to fill in the empty niches, which I sadly lack...

I might look into DCS or CALCnet this weekend, I've been way too busy this week to do any of that stuff.

Also, are you sure that an emulator contains the proper code? I'm thinking about trying it out, but I'm hesitant that the emulator (I'm using Tilem, BTW) won't have the correct code.

The emulator only emulates the hardware. The emulated hardware then runs the actual software, so the code will be correct.

Exactly this. You should theoretically load the ROM from your physical calculator into the emulator as its operating system, so as long as the hardware emulation of your emulator is correct (you're using either WabbitEmu or PindurTI, right?) you'll be all set, as Will_W said.

Actually, I'm using Tilem, as it is the only emulator I know that works with the TI-84+; does it work as well as WabbitEmu or PindurTI?

Yes; WabbitEmu is the best overall, and I believe PTI is the best for testing link stuff.

WabbitEmu works with the TI-84+(SE) and I think it's much better than TiLem, but it's not a native Linux program.

If I recall, it does not run properly under WINE either.

I have heard others dislike WabbitEmu because it doesn't properly emulate the hardware (read: flash, and other low-level things), and that TI Flash Debugger does it better. But meh. I use WabbitEmu on Windows and TiLem on Ubuntu.

PindurTI is my favorite of the emulators for hardware accuracy. It has a tiny, tiny problem with interrupts (and it's only something that matters to an interrupt writer), so other than that it's extremely accurate. The one downside for newbies is that it has no onscreen skin/keyboard, so you have to have all the key mappings memorized. WabbitEmu is reasonably accurate for all intents and purposes, although it has a few very minor inaccuracies.