| Author |
Message |
|
calcdude84se
Member
Joined: 09 Aug 2009
Posts: 207
|
 Posted: 11 Nov 2009 05:36:50 pm Post subject: |
|
|
Due to the success of the factoring of the OS signing keys, there will be more 3rd party OS's. I created this thread so that anyone who wants to start working on an OS can find all the info they need in one spot (If info already exists in the forum, just link to it)
I'll start it off by saying that TI-83+ OS Tools contains tools useful for creating *.8Xu files. |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
|
| Back to top |
|
|
calcdude84se
Member
Joined: 09 Aug 2009
Posts: 207
|
| Posted: 11 Nov 2009 06:57:31 pm Post subject: |
|
|
Probably the most important issue is the calculator hardware: keys, lcd, link port, usb port (84+(SE)), reading/writing flash, behavior of interrupts, etc.
Actually linking is a pain if you must write the code yourself.
Link to writing flash: XOS |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 15 Nov 2009 03:14:03 pm Post subject: |
|
|
Galandros wrote: Hardware info and CPU docs (especially interrupts) would be good. Z80 User Manual. |
|
| Back to top |
|
|
calcdude84se
Member
Joined: 09 Aug 2009
Posts: 207
|
| Posted: 15 Nov 2009 05:15:01 pm Post subject: |
|
|
The main problem is that there is no "Create your own OS" tutorial. There are tutorials for ASM, BASIC, etc., but none for an OS.
I want to write my own, but I have to ask a question first: Besides Page 0, which is always in memory addresses $0000 - $3FFF, what other ROM pages do I use? Am I forced to use specific ones? |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 15 Nov 2009 05:53:17 pm Post subject: |
|
|
Thanks ben. I was looking for that.
calcdude84se wrote: The main problem is that there is no "Create your own OS" tutorial. There are tutorials for ASM, BASIC, etc., but none for an OS.
I want to write my own, but I have to ask a question first: Besides Page 0, which is always in memory addresses $0000 - $3FFF, what other ROM pages do I use? Am I forced to use specific ones?
See the Memory bank ports in WikiTI. |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 15 Nov 2009 06:32:46 pm Post subject: |
|
|
| When you're finished with the Z80 user's manual, The Undocumented Z80 Documented contains pretty much everything else you need to know. (Bearing in mind, of course, that most undocumented features won't work correctly on the Nspire.) |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 16 Nov 2009 03:04:32 am Post subject: |
|
|
calcdude84se wrote: Besides Page 0, which is always in memory addresses $0000 - $3FFF, what other ROM pages do I use? Am I forced to use specific ones?
If you want to write to protected ports (so lock/unlock flash among other things) you need to use page 1C (3C or 7C on 84+ and SE respectively). Other than that you can use at least pages 01 02 03 and 1D (3D, 7D resp).
Theoretically the OS transfer protocol does not restrict the range of pages on which to flash the OS but the calc may actually perform some checks... |
|
| Back to top |
|
|
Mapar007
Advanced Member
Joined: 04 Oct 2008
Posts: 365
|
| Posted: 16 Nov 2009 11:05:59 am Post subject: |
|
|
Furthermore, the user flash space shouldn't be affected by an OS transfer/update. Keeps apps and stuff. The OS reserved space is the whole flash disk minus user archive and boot code.
Well, yeah, theoretically you could use everything, but... |
|
| Back to top |
|
|
calcdude84se
Member
Joined: 09 Aug 2009
Posts: 207
|
| Posted: 16 Nov 2009 04:54:51 pm Post subject: |
|
|
fullmetalcoder wrote: Theoretically the OS transfer protocol does not restrict the range of pages on which to flash the OS but the calc may actually perform some checks...
And nobody wants to try...
Thanks for the info.
We have all the tools we need (see first post) and all the documentation (WikiTI, z80 documentation, etc.). Now we just need that tutorial... |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 16 Nov 2009 08:42:40 pm Post subject: |
|
|
Well, writing an OS that's actually useful will take a lot of work
If you're unsure about how to initialize the hardware, where the magic bytes go, and that sort of thing, look at the existing examples (PongOS, CEPTIC, CSX, etc.)
If you're wondering how to actually assemble the thing... it's the same process that you would use to assemble a multi-page app, except that the first page starts at address 0000h instead of 4000h. Thus, you probably want to use an assembler that natively supports multi-page programs, such as tpasm, ZDS/zmasm, or brass.
You also need to define an OS header, which you can either write by hand (it's not hard) or include it in your code, like so:
Code:
org $1A4000
db $80,$0F, 0,0,0,0 ; start of OS header
db $80,$11, SIGNING_KEY; Key used to sign this OS
db $80,$21, MAJOR_VERSION; Major version number
db $80,$31, MINOR_VERSION; Minor version number
db $80,$81, NUMBER_OF_PAGES; Number of OS pages
db $80,$A1, HARDWARE_COMPATIBILITY; Max. hardware version supported (0 = 83+ BE, 1 = 83+ SE, 2 = 84+ BE, 3 = 84+ SE)
db $80,$7F, 0,0,0,0 ; end of OS header
If you have any specific questions, fire away  |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 17 Nov 2009 02:21:30 am Post subject: |
|
|
FloppusMaximus wrote: If you're wondering how to actually assemble the thing... it's the same process that you would use to assemble a multi-page app, except that the first page starts at address 0000h instead of 4000h. Thus, you probably want to use an assembler that natively supports multi-page programs, such as tpasm, ZDS/zmasm, or brass.
Though any assembler will do if you merge the various pages using multihex.
FloppusMaximus wrote: You also need to define an OS header, which you can either write by hand (it's not hard) or include it in your code, like so:
Errr... no you don't... packxxu and rabbitsign can take care of that.
Taking a look at XOS build script might be of some help to newcomers to kernel space : http://code.google.com/p/8xpos/source/brow.../trunk/build.sh |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 17 Nov 2009 10:20:41 pm Post subject: |
|
|
You're right, of course, packxxu does that just fine. I wasn't thinking.
With regard to assemblers - there are plenty of options, but some are definitely better than others. Try a few and see what works best for you. |
|
| Back to top |
|
|
Taricorp
Member
Joined: 09 Mar 2006
Posts: 188
|
| Posted: 18 Nov 2009 10:07:54 am Post subject: |
|
|
calcdude84se wrote: Link to writing flash: XOS
If you really want to mess with Flash, I highly recommend reading through the Flash chip datasheet. Combine that with a little reference to existing code (the flash stuff in PongOS is very well documented), and you should be able to figure out which actions in the CPU correspond to various commands to that chip. |
|
| Back to top |
|
|
brandonw
Advanced Member
Joined: 12 Jan 2007
Posts: 455
|
| Posted: 18 Nov 2009 03:12:10 pm Post subject: |
|
|
| Perhaps I'm missing something, but what benefit is there to using the Flash chip commands yourself? The boot code is never going away and already implements this for you. |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 18 Nov 2009 05:00:58 pm Post subject: |
|
|
Speed? I haven't tried it myself, but I expect you could dramatically improve programming speed with better-optimized code.
You could also arrange to do other things, such as reading from the link port or decompressing a compressed data stream, while waiting for the Flash chip to complete a program or erase operation. While waiting for an erase to finish, you could halt the CPU to reduce power consumption (as well as reducing the likelihood of a brownout if battery power is low.) |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 18 Nov 2009 05:08:37 pm Post subject: |
|
|
It would also free you from being forced to reimplement the bcall mecanism (not a big deal admittedly but...).
Besides, using the boot code means you have no control over which ram areas are used, which can be slightly embarassing... |
|
| Back to top |
|
|
calcdude84se
Member
Joined: 09 Aug 2009
Posts: 207
|
| Posted: 18 Nov 2009 08:51:53 pm Post subject: |
|
|
Unless you're really lazy, you would probably want to implement flash editing yourself. (Even I'm not that lazy.) Again, it's faster, customizable, you're in complete control, and you don't have to trust TI's code quality :biggrin:.
Last edited by Guest on 18 Nov 2009 08:52:25 pm; edited 1 time in total |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 19 Nov 2009 12:42:32 am Post subject: |
|
|
| I don't think speed is really an issue with the flash chip. The flash chip is so slow that the speed of the code doesn't really make a difference---a write operation can take up to two thousand clock cycles. (Although, apparently fifty clock cycles is "typical.") You might be able to get away with using a much shorter fixed delay, but then you might not. I think you could get much better garbage collection performance by using the extra RAM pages for buffering rather than trying to make writing go faster. |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
