Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: qazz42 on January 02, 2011, 02:55:07 pm
-
Crosspost from cemetech by Sircmpwn
Hello,
I'm announcing the first project for KnightOS. When it's done, I'll get started on Compat8x. Like Wine for Linux, Compat8x will be a compatibility layer allowing TIOS programs to run under KnightOS. I will support PartesOS as well when it's released, and the reverse (KOS on TIOS) could also be possible. How it works is this (for TIOS on KOS):
The program is copied to RAM twice. Compat8x looks through the first copy for CALL, JP, and LD. I'll talk about that in a moment. It needs to know if a given address lies within the program, and that can be calculated like so:
TIOS programs run from $9D95
If a program is $200 bytes, all addresses between $9D95 and $9F95 are internal.
Compat8x will set aside RAM that will mock SafeRAM from TIOS. When it encounters a load, if it is external, it changes the address to the corresponding mocked SafeRAM. If it's internal, it changes to the second copy in RAM.
Compat8x will also keep a jump table that leads to the KnightOS equivalent routines to commonly used bcalls. All external cals/jps/bcalls/bjumps are changed to their corrponding values in the jump table.
I know it wouldn't be perfect, but it could allow few programs to run.
apparently SirC could not make it to post here because there is no copy-paste feature on his phone :w00t:
-
Well, that's amazing. I'm working on my own secret project about this... *evil laugh*
Good luck Sir. The copying twice things would probably be bad for huge programs. I bet you could get around that in some way.
-
Well, KOS will have double the executable RAM available, so even large programs will probably run. Plus, execution can start as early as $8000, which gives an extra $1D95 bytes for programs. So the only size issue is with programs that execute up to $C000 and have huge data sections.
-
I am utterly ignorant of the finer nature of Assembly mechanisms and terminology, and because I cannot tell from context, I'll ask a noobish question:
Will Compat8x handle TI-Basic programs or Assembly programs? (or both?)
-
I am utterly ignorant of the finer nature of Assembly mechanisms and terminology, and because I cannot tell from context, I'll ask a noobish question:
Will Compat8x handle TI-Basic programs or Assembly programs? (or both?)
Assembly programs only, I'm afraid.
EDIT: apparently, I might be wrong. See next post.
-
TI-Basic will be supported, though.
-
TI-Basic will be supported, though.
What do you mean? I thought you were only talking about assembly with compat8x. Are you saying KOS will support basic?
-
crosspost:
I implied elsewhere, I think, that I will be writing a similar program using the double-copy idea.
SirCmpwn, another idea: for what is probably a good number of programs, they can be divided into code and data sections. We could compile a table of where the split(s) are located for common programs, and having this knowledge would make it possible to need only one copy.
-
Sounds awesome! Can't wait for the release of KnightOS.
-
calcdude, that would be very size inefficient, it would be better to manually port existing programs and release a new version.
-
Perhaps it would be better to port them, but could you explain how that would be inefficient with respect to size? I'm not exactly sure how; the table wouldn't be anything extremely large. ???
-
Well, there are a lot of duplicate program names out there (Phoenix, for example) so a simple and size efficient check wouldn't work well.
-
Checking size or doing a simple checksum wouldn't be too bad, but I see your point.
Perhaps a possibility for manual input, at least as an option?
-
Probably a computer side manual converter would be best.
-
Hm, sounds good. A database could be kept there and programs could be converted either way easily.
Good luck on this! :)
-
Thanks!
-
This sounds cool. I'm sure it'll ease the transition from the TI-OS to KOS. :) Good luck. :D
-
I saw mention of this in the PartesOS thread. This is awesome! =)
-
This sounds awesome, I remember hearing about porting ASM programs to KOS once it's done but this would make it much easier. Good luck on this :)
-
so what all types of functions would be realistically feasible for being run under this? would all bcalls work? and i heard some people asking about the VAT
regardless, compatibility of any kind would be extremely helpful!
-
so what all types of functions would be realistically feasible for being run under this? would all bcalls work? and i heard some people asking about the VAT
The VAT will be a fake VAT set up with any .8x* files from the current directory. Any changes to it will be reflected upon exit.
For the record, multitasking will be disabled, and I'll try to set up the RAM as best I can to mirror TIOS.
Compatible routines will probably be everything relating to text, and drawing. Ion/MirageOS support will be there, and perhaps DCS7 if I can make the KOS GUI system look similar. Most VAT editing things will probably be mirrored. Hooks will not be supported, but it will not crash when you try to make one. Ans will be faked. Depending on how I handle it in KOS itself, floating point support will be considered. Any routines from KOS that are similar to any routine from TIOS will be supported. Any bcall that is unsupported will instead point to a routine that quietly returns. Flash writing will not be enabled, and will in fact be completely sealed off. Flash will be locked, and if at any time during the application's execution the boot page is swapped in, it immediately swaps in something different via the interrupt. I'll probably check the program to see if it wants to write flash and tell the user it would be dumb to run it before executing it.
I will also make a fake bcall that can be used to determine if your program is running under Compat8x or not.
-
so Phoenix on KOS is a no go?
still, this sounds very impressive.
-
I plan to natively support Phoenix :) however, I see no reason why it couldn't run...