Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Deep Thought wrote:
Nice description Smile
Will KnightOS accept ASM/BASIC programs?
Hopefully not TI-BASIC, as that would require implementing a TI-BASIC parser, including the large swaths of OS code that would need to go with it. I would hope you'd implement some kind of powerful interpreted language, though.
Razz if your booting from a flash ROM than wouldn't that mean the potentially it could boot a binary file like ROM for a GameBoy game? I do believe that Game Boy games contain their code intirely in their binary themselves and not in any way connected to the system, so technically, you could play game boy games on it, right?

And for what Kerm said, why not build a multilingual assembler like TASM in it? People could create ".tab" programs for custom languages like z80, javascript, c, or whatever they want.
Well, I'm planning to port Mosaic and include it for z80, and I will probably write a seperate interpreter program that will interpret some sort of Basic. But all of this is months away.
xenonparadox, there is no way that will work. Period.
Well, they do have a GameBoy oncalc emulator for the TI-83/84 plus silver edition...
That is true, it is an emulator. However, you cannot simply boot to a gameboy rom on a calculator. There will be several limitations on booting to a flash drive, anyway.
Enlighten me as to how much restriction you can have with a 10GB flash drive.... Wink
Well, the OS you boot to may be required to run the KnightKernel.
I would like to remind everyone here that many of these features are months away, and I refuse to guarantee a single one. The entire OS and its usage is constantly fluctuating, and you can expect almost nothing to stay the same, because there is a good chance that it won't.
xenonparadox wrote:
Razz if your booting from a flash ROM than wouldn't that mean the potentially it could boot a binary file like ROM for a GameBoy game? I do believe that Game Boy games contain their code intirely in their binary themselves and not in any way connected to the system, so technically, you could play game boy games on it, right?
Because the gameboy hardware, even though it's a z80 processor, is completely different from the calculator's hardware. The keypad is completely different and needs to be translated, the LCD is completely different and needs to be translated, etc. Calc84's GB emulator is just that, an emulator. It doesn't just load in the ROM to the calculator's memory and hand over control.

xenonparadox wrote:
And for what Kerm said, why not build a multilingual assembler like TASM in it? People could create ".tab" programs for custom languages like z80, javascript, c, or whatever they want.
Well, I don't think you'd really want to compile Javascript on your calculator, although a C compiler would be nice. Of course, you'd need a whole library of standard routines like sscanf() and open() and ftoa() and all those other amazing C routines.
SirCmpwn wrote:
Eeems, how the filesystem driver works is that it only copies files to RAM for viewing and editing, and then copies them back to the filesystem. (Potentially). To boot from the USB, it just copies files from the flash drive to RAM, instead of ROM to RAM.
Yeah that's what I meant. You could have a menu and it would choose where to grab the OS from on boot, so like it would load from ROM or USB to the RAM, so you could have it test on boot to see if a USB device is connected and if it is it can ask if it should boot from there... this way we can make OS's that are beyond the ROM limits Very Happy
Wouldn't that be massively slow, since it would sometimes need to constantly swap out pages between the ROM and the external storage under some execution scenarios? And if you did something intelligent to prevent page thrashing, wouldn't you need dynamic paging of some sort, which could quickly become a huge headache?
yeah,,,true...oh well, that was a good idea in theory...
Eeems wrote:
yeah,,,true...oh well, that was a good idea in theory...
I'm not saying it wouldn't be a good idea, as it would indeed be very cool. It just requires a lot of thought to be executed the right way.
KermMartian wrote:
Eeems wrote:
yeah,,,true...oh well, that was a good idea in theory...
I'm not saying it wouldn't be a good idea, as it would indeed be very cool. It just requires a lot of thought to be executed the right way.
yeah it does...well, maybe someday in the future.
SirCmwn: how are you handling tasks and such btw? like how do you register and manage them?
KermMartian wrote:
Wouldn't that be massively slow, since it would sometimes need to constantly swap out pages between the ROM and the external storage under some execution scenarios? And if you did something intelligent to prevent page thrashing, wouldn't you need dynamic paging of some sort, which could quickly become a huge headache?

Well, no. It would pull the data into RAM, and execute it from there. Only the kernel really executes from ROM for now.
SirCmpwn wrote:
KermMartian wrote:
Wouldn't that be massively slow, since it would sometimes need to constantly swap out pages between the ROM and the external storage under some execution scenarios? And if you did something intelligent to prevent page thrashing, wouldn't you need dynamic paging of some sort, which could quickly become a huge headache?

Well, no. It would pull the data into RAM, and execute it from there. Only the kernel really executes from ROM for now.
Indeed, as is always the case. However, given all the features you're planning on putting in, it'll be a huge kernel. The discussion was what would happen if one made an OS bigger than the calculator's ROM size, in which case pages would need to be occasionally swapped out between the external storage and the ROM as different features and ROM calls were used. In a worst-case scenario, features or calls on two mutually-exclusive pages would be used, leading to some constant swapping. We were discussing possible effects of this and ways to avoid the same.
KermMartian wrote:
xenonparadox wrote:
Razz if your booting from a flash ROM than wouldn't that mean the potentially it could boot a binary file like ROM for a GameBoy game? I do believe that Game Boy games contain their code intirely in their binary themselves and not in any way connected to the system, so technically, you could play game boy games on it, right?
Because the gameboy hardware, even though it's a z80 processor, is completely different from the calculator's hardware. The keypad is completely different and needs to be translated, the LCD is completely different and needs to be translated, etc. Calc84's GB emulator is just that, an emulator. It doesn't just load in the ROM to the calculator's memory and hand over control.

Actually, it's not even a z80. It's very similar, but it's not binary compatible. Otherwise, I might have written something that *does* hand over control and I would do the rest of the emulation through interrupts. But alas, it wasn't possible.
Calc84maniac wrote:
Actually, it's not even a z80. It's very similar, but it's not binary compatible. Otherwise, I might have written something that *does* hand over control and I would do the rest of the emulation through interrupts. But alas, it wasn't possible.
Ah, seriously? Then there's a common misconception that I had no idea about. And I also didn't know that the Gameboy handled the display and keypad as an interrupt, that's fascinating.
KermMartian wrote:
Calc84maniac wrote:
Actually, it's not even a z80. It's very similar, but it's not binary compatible. Otherwise, I might have written something that *does* hand over control and I would do the rest of the emulation through interrupts. But alas, it wasn't possible.
Ah, seriously? Then there's a common misconception that I had no idea about. And I also didn't know that the Gameboy handled the display and keypad as an interrupt, that's fascinating.

It doesn't handle the display directly (except for writing to VRAM and some memory-mapped ports), so an interrupt can be used to handle the non-CPU hardware. And... actually, the keypad might be an issue.
Good to know, calc84maniac. Smile So SirCmpwn, does that explain what Eeems and I were going on about in our theorizing?
Somewhat off-topic, but I was day dreaming about a third-party OS that supported something like AXE. I think it'd be pretty cool to have AXE integrated into an OS, once AXE becomes healthy enough. However, it may be important to implement some sort of crash-detection, since AXE does translate directly into ASM and could potentially harm the calculator. But yeah, just a random idea.

Just something to think about since you all were talking about TI-BASIC and ASM support... Anywho, continue on with the rest of the topic. Razz
  
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 29
» 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