meybe put fuzix on this device but how boot it?

...interesting concept! 

I'd sorta contemplated CP/M, but really don't know enough about it to know /why/ I'd want to go that route, heh!

Fuzix, similarly, but having read about its ties with POSIX, and its support for many 8bit systems, I may do a little more digging. If not for this project, then maybe another. Thanks!

If anyone else tries this, I'd sure like to hear!

there are whole forums devoted to development for the z80 and ez80 processors in the context of the TI calcs... Omnimaga and Cemetech, to name a few, would be good resources to look at

Cool, Thankya! Looking up Omnimaga, I came across this, which links to some of those other such sites...

http://tistory.wikidot.com/omnimaga

Software Development Tools for Z80 Family -- many of these tools were designed ... https://tutuappvip.co  https://routingnumbers.onl

wow, now that is a LOT of z80 devel tools!

http://www.z80.info/z80sdt.htm

SDCC is open source complete toolchain for a number of old- (and also some new-) school 8-bit CPUs and MCUs, one of them being Z80. Assemblers are part of the package.

Thankya!

I was specifically looking for one that could be used on-board, making development on the unit entirely self-contained... but I wasn't clear about that, and SDCC is great to know about.

I've always wondered, though... how can something like this work with executables run from within an OS? I mean, doesn't the compiler need to know things like the memory-mapping and such? And possibly even have to provide OS-specific executable header information?

Oh, I see. You don't need SDCC or any other cross-compiler. You want the TI-86 to be the development  environment  as well as target.

WRT your questions, yes you are right, executables would need headers to provide to loader necessary data about the user program, unless the system is so simple or rigid that programs must comply to its conditions (fixed user program load address, limited user memory space length, only one loadable program possessing whole user program memory and running at any given time), in which case the loader would simply copy binary blob to RAM space starting at a well-known start address and then jump to it, either straight (power cycle to end it) or as into subroutine (it returns to OS after it completes).

Thanks for your explanation re: executables! I guess this is where I get lost, coming from AVR programming via gcc, it seems like what you code is what you get, but the fact is there's a lot going on in the background with linking and compiling in things like the c-runtime... Since AVRs only run code from FLASH, too, there's nothing with regards to relocating into and executing from RAM... basically every jump could just-as-well be to an absolute address... and I guess I don't see where the compiler knows when to use absolute calls vs relative, so then how could one know whether their code even *can* be relocated into and run from RAM...

Then you get to things like putchar() which I guess is wrapped by printf and such, and those libraries are all compiled into the same binary in AVR programming... But, say you're coding for a system which already has those libraries, (like the TI-86, or basically any other architecture other than AVR, unless you're bare-metalling the whole shebang yourself) and suddenly you need information about how to access those libraries... it's not like stdio.h knows which address putchar() is located, without some extra info from somewhere... then, further, putchar() needs to know the hardware well enough to know which address the serial port or character LCD or whatever is located, and *how* to interact with the device itself... and that too is where I get lost.

I've accepted this as a limitation of my abilities that some day I might grasp... but as it stands, the idea of cross-compiling from some generic C-compiler like sdcc or even gcc for a different architecture than the one it's running on just boggles my mind.

Seems one would need a ton of nitty-gritty information about the system they're compiling for, memory-layout, etc. that would vary greatly even amongst systems with the same CPU! And also need to know how to input that to the compiler (linker scripts? Header files?)

Similarly (and surely even more complex) trying to port Linux to different hardware... They say, for instance, it can be compiled for 68k architectures, but some of those don't have inbuilt MMUs, so, then, it's not like the MMU is always interfaced in the same way from one machine to the next, so then... something so core to the kernel's functionality needs a driver of some sort, for many such things, and that seems even more important and harder to find/implement the details of than the CPU instruction-set itself!

Mind blown.

I guess this here, understanding this side of things, is a long-term "project" (I spent months trying to understand the linker some 15 years ago, trying to relocate my bare-metal ARM code to run from the much faster RAM, to no avail).

OTOH, users of SDCC must run into this sorta thing pretty regularly, might be a good place to look for examples/tutorials. Thankya for the idea!

there are many answers here: not for the calc, but at least an idea where to start: http://www.cpcmania.com/Docs/Programming/Introduction_to_programming_in_SDCC_Compiling_and_testing_a_Hello_World.htm

From what I gather, i think your "unless the system is so rigid" is the case with the TI-86... loads to a fixed address, gives a dedicated memory bank... I think.

Well, it's a graphing calculator, not a multiuser business micro with hard disk and terminals. Expect simple solid solutions and probably as much freedom as up to "You are on your own now. We don't care, you can't screw up anything a powercycle or reset can't wash out!"

This might help... https://www.ticalc.org/pub/text/z80/

Don't @ me.

yes, i found that page, thank you.

bah! Had the idea maybe CP/M may've even been ported, so searched for /that/ and found this:

https://www.ticalc.org/archives/files/fileinfo/92/9266.html "ZAC" the TI-86 oncalc compiler /and/ IDE!

I'm surprised the vintage compy folk aren't all over a z80 pocket computer.

I was about to give you this link which has ZAC on it as well as a bunch of other stuff: https://www.ticalc.org/pub/86/asm/programs/

If you ever need something for a TI calculator, it's going to be on ticalc.org

Awesome, thankya!

I recall a few compiled games being passed around in my youth, back when AOL was king, so frankly, I somehow thought that was all done via sneaker-net. Of Course there'd be such a resource!