Alternatively you could just do something similar to what the OS does for hooks on the z80 series: add a short header to the start of the library, if the header matches then you can rest relatively assured that the library is loaded where it should be. Otherwise, you can just exit the program.

I also think a CE version of ion wouldn't be bad, many of us were around before apps were a common thing on the z80 and grew up using CrASH/ASH, AShell, SOS, ion, etc. until MirageOS got popular in the early 00s.
Thanks Mateo, I followed your tutorial and it builds and converts successfully.

I don't have the calculator to test it on - is there an emulator for it at all please?
amazonka wrote:
I don't have the calculator to test it on - is there an emulator for it at all please?
Unfortunately, there is not yet a TI-84 Plus CE emulator from the community (and if there was, it would require a ROM dumped from your real calculator). Texas Instruments has a product called TI Smartview CE, and is the only existing TI-84 Plus CE emulator.
Kerm mentioned earlier that C was not suitable for the existing Z80 processors. Why is this ?
We are not talking about a z80 powered calculator in this topic, that's why.
Great ! That's not like my old ti-82 stats.fr where there was not C or Axe... Razz
By the bye, do you think there will be axe on the Ti-84+ CE ?

Quote:
Unfortunately, there is not yet a TI-84 Plus CE emulator from the community (and if there was, it would require a ROM dumped from your real calculator). Texas Instruments has a product called TI Smartview CE, and is the only existing TI-84 Plus CE emulator.


If you want to pay $230... seriously, why is it so expansive just for an emulator that you will be able to find its free equivalent in 2 months ?
p'Ti rageur wrote:
Quote:
Unfortunately, there is not yet a TI-84 Plus CE emulator from the community (and if there was, it would require a ROM dumped from your real calculator). Texas Instruments has a product called TI Smartview CE, and is the only existing TI-84 Plus CE emulator.


If you want to pay $230... seriously, why is it so expansive just for an emulator that you will be able to find its free equivalent in 2 months ?

Where did you see $230?
By googling "CE84EMU/VP/ESW" you can see $78 prices.
But anyway, being a teacher helps getting it for cheaper, and maybe free.
BUMP

Okay, so I'm still looking for a few ideas, but here is what I think I will be doing in the near future:
    Library functions, such as LCD methods and file IO, along with everything else such as key input, will be contained within a single AppVar, written entirely in assembly.
    This AppVar will reside in the archive, and a function call from within the C program will copy the AppVar to the linear SafeRam location, which is a perfect size fit, and allows for 5kb of already allocated RAM, without having to use any other methods just yet.
    This means that library execution will be from RAM, which avoids the flash wait states.
    In addition, since it is archived, it will be persrved during a RAM clear.
    Of course, it will be open source, and tottaly addable to.
    Relocation is tottaly a possibility, but as of right now, I don't see too much need for it, but that is something for the future.
    Also, access to the stack and maybe a custom heap would be fun ideas.

Please, let me know your thoughts on this. I understand the implications of flat addressing, but even if it were to change, it wouldn't be too much trouble to change. On the user end, updating isn't really that hard, especially if you already have the software to transfer. But this is just what aspects I will be a-doing, so that's about it. Plus the library functions will also be available to assembly programs as well.
Bump. Thanks guys. Smile I just wanted to pass some ideas around really quick. See above.
Bump again. Going to just go ahead with my ideas, in order to make development super easy. Thanks! Smile
MateoConLechuga wrote:
make development super easy

that's also a good idea - thanks and looking forward to your progress with this
MateoConLechuga wrote:
Library functions, such as LCD methods and file IO, along with everything else such as key input, will be contained within a single AppVar, written entirely in assembly.
A single AppVar? I don't think that's a great idea. I would prefer a stdio-like AppVar and a graphics AppVar, at the very least. I do understand that that would make relocatable code necessary, but surely at X point in the future we'll need more than a single library, and then all hell will break loose. My experiences with the 83+/84+ and then the 84+CSE have increasingly taught me that we need to future-proof our work in every possible way.

Quote:
In addition, since it is archived, it will be persrved during a RAM clear.
Would you consider the ability to execute Archived ASM programs directly particularly cool? Would that be relevant to this project?
To add on to what Kerm said, you should really take a read through the discussion of program formats and library dependencies in the 84+CSE Consortium thread.
Thanks everyone. Smile That's exactly what I was looking for. Executing Archived ASM programs sort of defeats the whole purpose of running library code in RAM. Are you suggesting that having multiple appvars and opening them when a program loads into somewhere in UserMem, either in SafeRam or elsewhere?

Elfprice: Thanks. Smile
Actually, I do like the idea of having multiple appvars for different things, much like the normal C way of doing things. Would it make sense to have these libraries exist in archived appvars, copy them to RAM in a successive manner, and have a relocation table in each library so that it can use its own functions whenever needed? Because the main program will also need to figure out the location of the library functions then too... Thoughts? How should relocation be done properly and sanely? Thanks! Smile
The TI-68k series' PreOS provides technical solutions which work, AFAICT.
Thanks for the info! Will take a look at that. Smile I'm thinking a shell might be the best route to go, of course.

Okay, now I have refined my thoughts a bit. We will have a 'kernel' like system, which will handle finding libraries. The kernel will be responsible for finding said library somewhere in the calculator, extracting it go RAM, and relocating the addresses within the library itself. However, this is where I run into a dilema. How will the program itself know where the location of each library function is, and for that matter that it will be run from the same memory location each time? If TI were to change the layout of RAM, that would be quite unfortunate. The only way I see around this is static rather than shared libraries, but that is just a complete waste of space that we don't have. Thoughts? Smile
Okay, now head is spinning a little after thinking more about this. In order to create dynamically linked shared libraries, here is what I think I understand thus far:

1: Library code will be copied to RAM, where relative address will be filled in by the kernel. If a library references functions from within another library, it must also resolve those addresses. How?
2: Once all the library things have been accounted for, the the actual executable must locate the new addresses of each library function. How?

In other words, would someone with more experience with this kind of thing mind outlining the steps for creating shared libraries? Some puesdo code would be great, if possible. Thank you! Smile
#cemetech wrote:
23:16] <EinHelfer> Mateo, from what I remember from the ELF format (someone can boop me if I am way off), a binary that references external symbols has a LUT with pointers to everything it references
[23:17] <EinHelfer> When you run the dynamic linker to load the elf, the ELF's referenced symbol table is checked for what files it wants and the symbols it requests
[23:17] <EinHelfer> Then it maps the object(s) into memory
[23:18] <EinHelfer> Your ELF's LUT is then built in RAM. For each symbol, it searches for it in the other ELF's symbol table, grabs the base pointer, calculates the mapped position (offset + where the binary was mapped to), and stores it in your ELF's LUT
[23:18] <saxjax> (C) [MateoConLechuga] An infinite area is partly black, partly white.
[23:19] <saxjax> (C) [MateoConLechuga] Ah, thank you. Would you mind posting that in the topic, so I don't accidentally loss it?
[23:20] <EinHelfer> In the end, you'll have a list of pointers to the target data. The locations are, well, dynamic, so you have a ... I forget the name, you'll have a indexing register pointing to the start of your ELF's LUT
[23:21] <EinHelfer> With that register, you'll just dereference an offset to get the data or function or w/e
[23:21] <EinHelfer> Most of this came from a combo of objdump'ing ELFs and Tari
[23:21] <saxjax> (C) [MateoConLechuga] Ah, I see. So I need to build a table with a bunch of free ram, perhaps a hash table if I so desire?
[23:22] <EinHelfer> But that's the gist of it
[23:22] <EinHelfer> You won't need a hash table, your program uses fixed indexes in that LUT
[23:23] <EinHelfer> You can for the symbol tables, but that is time spent only loading (searching symbol tables, copying the resulting pointer to the fixed index in the LUT)
[23:23] <saxjax> (C) [MateoConLechuga] Ah, so I fix them, then replace.
[23:24] <EinHelfer> So if you have a program that uses does, say, printf("Hello world is overrated\n");, print is an external symbol in the ELF
[23:24] <EinHelfer> It'll reserve, say, entry 0 in the LUT
[23:25] <saxjax> (C) [MateoConLechuga] Then when the program wants to use print, it just calls entry 0?
[23:26] <EinHelfer> Yup
[23:26] <saxjax> (C) [MateoConLechuga] Or is the entry 0 address copied into the program itself?
[23:26] <saxjax> (C) [MateoConLechuga] Oh, never mind about that then.
[23:27] <EinHelfer> In a perfect world, you would do call (ix+0)
[23:27] <EinHelfer> idk if ez80 makes this much easier
[23:27] <saxjax> (C) [MateoConLechuga] Yay, that means I don't need to change the program; just the library code, right?
[23:28] <saxjax> (C) [MateoConLechuga] Not too bad. The hard part is going to be resolving the addresses witthin the libraries.
[23:28] <EinHelfer> Well, you'll need to use a binary format that stores the needed sections as well as having a dynamic linker to load the program code
[23:29] <EinHelfer> (load program code, meaning in the end having a LUT with valid pointers)
ELF is powerful because it provides nice concepts, but it is basically unusable for the TI-Z80, TI-eZ80 and TI-68k series at the very least.
Even on the Nspire series, the experiments showed several horrible size blowups (in the KBs range) on simple things, while others admittedly worked well. This eventually led to the making of a custom executable format for the newest Ndless releases.
BFLT was mentioned by multiple persons and considered, but then it's simplistic and limited, although the 256-library limitation would effectively be less of a problem on a TI-(e)Z80/TI-68k than on a Nspire.

PreOS's documentation of the program formats and RAM_CALLs is quite good: http://www.yaronet.com/t3?id=11 n, under the sdk/doc folder of the downloaded 7z file.
Obviously, a number of things don't apply to any platform but TI-68k/AMS, but others do: variables ("RAM_CALLs" in TI-68k "kernel" parlance) containing the calculator model, the hardware version (huge differences between TI-68k HW1 and HW2), OS version, LCD width in pixels / height in pixels / width of a line in bytes / full size in bytes. The flash memory base RAM_CALL, for instance, makes less sense on the TI-eZ80 series than on the TI-68k series: 0x200000 for 89 and V200, 0x400000 for 92+, 0x800000 for 89T.

I'd add API/ABI version of the "kernel" / its libraries to those RAM_CALLs relevant to the TI-eZ80 series, possibly with "kernel"-provided functionality for checking version numbers.

Maybe I already wrote some of that in the 84CC or another topic, I don't remember. As before, the goal of my posts is to try and provide some ideas and help reduce wheel reinvention, based on the experience of the TI-68k series, to which the TI-eZ80 series is far more similar than the TI-Z80 series was, over the past nearly 20 years Smile
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 5
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement