| Author |
Message |
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
 Posted: 04 Oct 2009 12:21:20 pm Post subject: |
|
|
Since the success of the RSA factoring project I've been working (somewhat irregularly due to real life leaving me very little coding time) on a pet project of mine : XOS (name may change...)
The vision :
- an OS that takes advantage of SE hardware
- an OS that gives lots of power to coders
- a (relatively) simple OS that focus on doing well what it does (so no fancy math for instance, this belongs to userspace)
I started with CSX sources, reorganized them, rewrote large portions and added quite a lot of things.
The result so far :
- a decent filesystem : 64kb of data storage, filenames can be longer than 8 chars, filesizes can go up to 64kb (theoretically, in practice the limit is slightly lower due to the presence of some metadata)
- linking : the "host" command turns the calculator in host mode. It can then communicate with a PC (or another calc) using TIOS protocol and send/receive files
- program execution : z80 programs of up to 32kb can be executed (no exec restriction)
- extensive API with fast calling convention (simple call instead of bcall)
- dynamic libraries : programs can load dynamic libraries in prog space (provided some room is left in the 32kb of prog space). Relocations are performed automatically if needed and again the calling convention is fast (simple call to a jump table entry)
- a command line interface : simple but much nicer than that of CSX -> command memory, cursor can move around for better editing experience
So, even though my work is far from finished the foundations are pretty solid already.
The source code is available under BSD (unless specifically notified, e.g for code taken from GPL'd soft).
The next items I'd like to tackle are flash support (using flash as "regular" data storage, send/receive flash apps, execute flash apps) and some TIOS backward compat (the bcall code is already working, what's left to do is the emulation of all the bcalls). Concerning the last one there will of course be many limits but it'd be nice to keep compatibility with as many TIOS progs/apps as possible.
Any (constructive) feedback is welcome. |
|
| Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009
Posts: 291
|
| Posted: 04 Oct 2009 12:35:36 pm Post subject: |
|
|
| Is there going to be an API faster than TI-Basic but easier than ASM? |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 04 Oct 2009 12:56:45 pm Post subject: |
|
|
| are you taking into account the recent developments of P vs S calcs? |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 04 Oct 2009 11:10:13 pm Post subject: |
|
|
It's always fun to see people working on alternative OSes. :)
Something to ponder before you solidify your API too much: if you ever want to be able to run TIOS programs, you'll need to be able to provide the TIOS page-0 calls:
0008 = rOP1TOOP2
000B = LCD_BUSY_QUICK
0010 = rFINDSYM
0018 = rPUSHREALO1
0020 = rMOV9TOOP1
0028 = rBR_CALL (B_CALL handler)
0030 = rFPADD
0050 = BRT_JUMP0 (B_JUMP handler)
0059 = APP_PUSH_ERRORH
005C = APP_POP_ERRORH
In any case, I've often thought that it would be nice for the RST routines to be hookable - that could be useful for a variety of purposes beyond emulating the TIOS. |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 05 Oct 2009 01:51:08 am Post subject: |
|
|
ztrumpet wrote: are you taking into account the recent developments of P vs S calcs?
I've followed the development but I have not implemented a software check to detect faulty RAM yet.
Anyway calcs with faulty/reduced RAM will not be supported very well : it will be possible to execute
programs but there won't be room for data storage...
FloppusMaximus wrote: It's always fun to see people working on alternative OSes. 
It's quite fun to work on it as well. :)
FloppusMaximus wrote: Something to ponder before you solidify your API too much: if you ever want to be able to run TIOS programs, you'll need to be able to provide the TIOS page-0 calls:
0008 = rOP1TOOP2
000B = LCD_BUSY_QUICK
0010 = rFINDSYM
0018 = rPUSHREALO1
0020 = rMOV9TOOP1
0028 = rBR_CALL (B_CALL handler)
0030 = rFPADD
0050 = BRT_JUMP0 (B_JUMP handler)
0059 = APP_PUSH_ERRORH
005C = APP_POP_ERRORH
In any case, I've often thought that it would be nice for the RST routines to be hookable - that could be useful for a variety of purposes beyond emulating the TIOS.
Annoying... I hadn't considered that (apart from the bcall handler which I put at 0028) and it kinda sucks because it drastically reduces the usefulness of rst
Having "hookable" rst should be pretty easy to do but it will bring too much overhead for rst to be interesting anymore for the routines I placed there (deref_hl, offset_hl, cmp_hlde). |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 05 Oct 2009 10:09:59 am Post subject: |
|
|
Here's a fairly simple hooking routine:
Code:
push hl
ld hl,(rst_jump_10);or similar
ex (sp),hl
ret
And if people are worried about speed for those simple routines you mentioned, they would inline them anyway. Rst is more for saving bytes. |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 06 Oct 2009 02:25:23 am Post subject: |
|
|
calc84maniac wrote: Here's a fairly simple hooking routine:
Code: push hl
ld hl,(rst_jump_10);or similar
ex (sp),hl
ret
And if people are worried about speed for those simple routines you mentioned, they would inline them anyway. Rst is more for saving bytes.
Well that's the one I used for rst 30h which was already hookable and as I couldn't think of anything faster I just reused it for the others...
I added some #ifdef blocks to determine at build time whether to enable TIOS compat (which includes hookable rst and several other things).
I've managed to successfully launch MirageOS and Chip's challenge (the later actually got beyond the splash screen!  ) but they crashed at the first bcall since I have not added the vector table and emulation yet.
By the way, does nayone know where I could find informations on TIOS flash storage model? I know app sectors start with $80, free sectors with $FF, arch sector with $F0 and temp sectors with $FE but it looks like the pages of a single app are not stored sequentially... which makes it hard to support app-level bcalls. |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 06 Oct 2009 06:47:47 am Post subject: |
|
|
| App pages are stored sequentially, but backwards. |
|
| Back to top |
|
|
DrDnar
Member
Joined: 28 Aug 2009
Posts: 116
|
| Posted: 06 Oct 2009 07:15:39 pm Post subject: |
|
|
I don't know if the write to flash routines on the boot page will be of use to you because they use fixed constants and memory locations and stuff. You can use this routine to write to flash instead. Returns NZ on fail. Does not save the page in the 4000h bank.
Code:
programByte:
; Flash program sequence
; The standard interrupt must not trigger during this sequence or the flash chip
; will not get the write command.
di
; Select page
out (6), a
; First bus cycle---unlock
ld a, 0AAh
ld (4AAAh), a
; Second bus cycle---unlock
ld a, 55h
ld (4555h), a
; Third bus cycle---write command
ld a, 0A0h
ld (4AAAh), a
; Fourth bus cycle---program data
ldi
; Wait for data to be good
; "During the Embedded Program Algorithm, an attempt to read the devices will
; produce the complement of the data last written to DQ7. Upon completion of the
; Embedded Program Algorithm, an attempt to read the device will produce the
; true data last written to DQ7"
; "DQ5 will indicate if the program or erase time has exceeded the specified
; limits (internal pulse count). If this occurs, reset the device with command
; sequence."---Fujitsu documentation
ld a, (hl)
ex de, hl
programWaitLoop:
ld b, a
xor (hl)
bit 7, a
ld a, b
jr z, programDone
bit 5, (hl)
jr z, programWaitLoop
push af
ld a, 0F0h
ld (4000h), a
pop af
programDone:
ex de, hl
ei
ret
I've tested this code and know it works.
You can use this routine to erase flash sectors. I haven't tested it, but it should work. Do make an attempt to understand what this code is doing before using it. It has code for testing the erase suspend, which you may want to remove. It does not save the page in the 4000h bank.
Code:
eraseSector:
; Erase a sector of flash
; Input:
; - A: Page
; This routine will not erase OS or certificate pages.
; Returns z for failure
push af
cp 7
jr c, eraseSectorBadSector
ld b, a
ld a, (lastPageTable)
add a, 4
cp b
jr nc, rawEraseSector
eraseSectorBadSector:
xor a
pop af
ret
rawEraseSector:
pop af
; Flash erase sequence
; This is being done according to how the datasheet says it should be done.
; The standard interrupt must not trigger during this sequence or the flash chip
; will not get the write command.
di
out (6), a
; First bus cycle---unlock
ld a, 0AAh
ld (4AAAh), a
; Second bus cycle---unlock
ld a, 55h
ld (4555h), a
; Third bus cycle---write command
ld a, 080h
ld (4AAAh), a
; Fourth bus cycle---unlock (again)
ld a, 0AAh
ld (4AAAh), a
; Fifth bus cycle---unlock (again)
ld a, 55h
ld (4555h), a
; Sixth bus cycle---select sector
ld a, 30h
ld (4000h), a
; Wait for data to be good
; "During the Embedded Erase Algorithm, an attempt to read the device will
; produce a '0' at the DQ7 output. Upon completion of the Embedded Erase
; Algorithm an attempt to read the device will produce a '1' at the DQ7 output."
; "DQ5 will indicate if the program or erase time has exceeded the specified
; limits (internal pulse count). If this occurs, reset the device with command
; sequence."---Fujitsu documentation
eraseWaitLoop:
ld a, 0FDh
out (1), a
nop
nop
in a, (1)
cp 0BFh
jr z, abortErase
cp 0FDh
jr nz, eraseWaitLoopCont
ld a, 0B0h
ld (4000h), a ; This suspends the erase operation so we
ld a, "+" ; can read data from the flash chip again.
b_call(_PutC)
ld a, 30h ; This resumes the erase operation.
ld (4000h), a ; NOTE: Suspend is untested. Might not work.
eraseWaitLoopCont:
ld a, (4000h)
bit 7, a
jr nz, eraseDone
bit 5, a
jr z, eraseWaitLoop
abortErase:
ld a, 0F0h
ld (4000h), a
xor a ; flags
ret
eraseDone:
ei
ret
You should also check out the erase suspend feature. Erase operations can take up 30 seconds by the book, during which all reads from the flash chip return status information on the write instead of data. The flash chip can suspend the erase operation so you can read data again normally. Thus you could display a status bar during the erase operation.
The code in my avatar is the full chip erase code. Should kill the certificate but not the boot code.
The included file, rawflash.asm, has a few routines to test the autoselect commands, which don't seem to work. It does a few extra things when writing and erasing sectors you don't need to do.
BrandonW's archive.txt is also included. Some of the information is wrong. Namely, archive data cannot space sector boundries. Also, IIRC, applications and archive data are never on the same sector, which is why you sometimes can't send applications even when you have enough free space.
UPDATE: The archive.txt is superseded by the Wiki: http://wikiti.brandonw.net/index.php?title...he_User_Archive . Consult that for information.
The certificate list the SDK talks about is garbage. The OS and boot code always preserves all data there, so you can use it as you please.
Last edited by Guest on 18 Nov 2009 03:06:07 pm; edited 1 time in total |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 07 Oct 2009 01:33:34 am Post subject: |
|
|
calc84maniac wrote: App pages are stored sequentially, but backwards.
I infered that from the SDK but thought it might be wrong after analyzing the content of the flash on my calc. I guess I'll just assume this to be true and see if multipage apps work.
[quote name='Dr. D'nar' post='137219' date='Oct 7 2009, 02:15 AM']I don't know if the write to flash routines on the boot page will be of use to you because they use fixed constants and memory locations and stuff. You can use this routine to write to flash instead. Returns NZ on fail.
Code:
programByte:
; Flash program sequence
; The standard interrupt must not trigger during this sequence or the flash chip
; will not get the write command.
di
; push af
; xor a
; out (6), a
; reset bus (not needed by the books)
;ld a, 0F0h
;ld (4000h), a
; First bus cycle---unlock
ld a, 0AAh
ld (4AAAh), a
; Second bus cycle---unlock
ld a, 55h
ld (4555h), a
; Third bus cycle---write command
ld a, 0A0h
ld (4AAAh), a
; Fourth bus cycle---program data
; pop af
; out (6), a
ldi
; Wait for data to be good
; "During the Embedded Program Algorithm, an attempt to read the devices will
; produce the complement of the data last written to DQ7. Upon completion of the
; Embedded Program Algorithm, an attempt to read the device will produce the
; true data last written to DQ7"
; "DQ5 will indicate if the program or erase time has exceeded the specified
; limits (internal pulse count). If this occurs, reset the device with command
; sequence."---Fujitsu documentation
ld a, (hl)
ex de, hl
programWaitLoop:
ld b, a
xor (hl)
bit 7, a
ld a, b
jr z, programDone
bit 5, (hl)
jr z, programWaitLoop
push af
ld a, 0F0h
ld (4000h), a
pop af
programDone:
ex de, hl
ei
ret
I've tested this code and know it works.
You can use this routine to erase flash sectors. I haven't tested it, but it should work.
Code:
eraseSector:
; Erase a sector of flash
; Input:
; - A: Page
; This routine will not erase OS or certificate pages.
; Returns z for failure
push af
cp 7
jr c, eraseSectorBadSector
ld b, a
ld a, (lastPageTable)
add a, 4
cp b
jr nc, rawEraseSector
eraseSectorBadSector:
xor a
pop af
ret
rawEraseSector:
pop af
; Flash erase sequence
; This is being done according to how the datasheet says it should be done.
; The standard interrupt must not trigger during this sequence or the flash chip
; will not get the write command.
di
out (6), a
; reset bus (not needed by books)
;ld a, 0F0h
;ld (4000h), a
; First bus cycle---unlock
ld a, 0AAh
ld (4AAAh), a
; Second bus cycle---unlock
ld a, 55h
ld (4555h), a
; Third bus cycle---write command
ld a, 080h
ld (4AAAh), a
; Fourth bus cycle---unlock (again)
ld a, 0AAh
ld (4AAAh), a
; Fifth bus cycle---unlock (again)
ld a, 55h
ld (4555h), a
; Sixth bus cycle---select sector
ld a, 30h
ld (4000h), a
; Wait for data to be good
; "During the Embedded Erase Algorithm, an attempt to read the device will
; produce a '0' at the DQ7 output. Upon completion of the Embedded Erase
; Algorithm an attempt to read the device will produce a '1' at the DQ7 output."
; "DQ5 will indicate if the program or erase time has exceeded the specified
; limits (internal pulse count). If this occurs, reset the device with command
; sequence."---Fujitsu documentation
eraseWaitLoop:
ld a, 0FDh
out (1), a
nop
nop
in a, (1)
cp 0BFh
jr z, abortErase
cp 0FDh
jr nz, eraseWaitLoopCont
ld a, 0B0h
ld (4000h), a ; This suspends the erase operation so we
ld a, "+" ; can read data from the flash chip again.
b_call(_PutC)
ld a, 30h ; This resumes the erase operation.
ld (4000h), a ; NOTE: Suspend is untested. Might not work.
eraseWaitLoopCont:
ld a, (4000h)
bit 7, a
jr nz, eraseDone
bit 5, a
jr z, eraseWaitLoop
abortErase:
ld a, 0F0h
ld (4000h), a
xor a ; flags
ret
eraseDone:
ei
ret
You should also check out the erase suspend feature. Erase operations can take up 30 seconds by the book, during which all reads from the flash chip return status information on the write instead of data. The flash chip can suspend the erase operation so you can read data again normally. Thus you could display a status bar during the erase operation.
The code in my avatar is the full chip erase code. Should kill the certificate but not the boot code.
The included file, rawflash.asm, has a few routines to test the autoselect commands, which don't seem to work. It does a few extra things when writing and erasing sectors you don't need to do.
BrandonW's archive.txt is also included. Some of the information is wrong. Namely, archive data cannot space sector boundries. Also, IIRC, applications and archive data are never on the same sector, which is why you sometimes can't send applications even when you have enough free space.
The certificate list the SDK talks about is garbage. The OS and boot code always preserves all data there, so you can use it as you please.[/quote]
Thanks but I already got that (and some more) from PongOS source code so I'm good on the low-level part of flash writing. my main concerns are related to the lifetime of the flash chip and the necessity to avoid sector erasing as much as possible while minimizing the space used to store data...
I made some progress in the emulation layer but I'll have to "emulate" the VAT to get interesting apps to work and that will be complicated...  |
|
| Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009
Posts: 291
|
| Posted: 07 Oct 2009 01:43:42 am Post subject: |
|
|
| You still didn't answer my question, lol! Although, I guess I should rephrase it. Are there going to be API functions not included in standard Ti-Basic, and will you be able to store pictures of different sizes and with different names? |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 07 Oct 2009 03:00:50 am Post subject: |
|
|
Hot Dog wrote: You still didn't answer my question, lol! Although, I guess I should rephrase it. Are there going to be API functions not included in standard Ti-Basic, and will you be able to store pictures of different sizes and with different names?
As stated in the README (but I guess you did not read it) there won't be BASIC support. There might be BBC basic support -if either the source code is released and ported or the compat layer allows the BBC basic app to be emulated properly - or support for another interpreted language if someone writes an interpreter for it but I am not going to do it.
On a related note, once the API is set in stone, the compat layer is ready and the top items of my todo list are dealt with I plan to wrap sdcc (Small Device C Compiler) to make it possible to write C programs for XOS easily which would provide a significantly higher level language than assembly, which would still be order of magnitudes faster than BASIC and would come at little cost for me. |
|
| Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009
Posts: 291
|
| Posted: 07 Oct 2009 03:12:33 am Post subject: |
|
|
Quote: As stated in the README (but I guess you did not read it)
Opps, I forgot to do my homework! |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 07 Oct 2009 02:56:06 pm Post subject: |
|
|
fullmetalcoder wrote: On a related note, once the API is set in stone, the compat layer is ready and the top items of my todo list are dealt with I plan to wrap sdcc (Small Device C Compiler) to make it possible to write C programs for XOS easily which would provide a significantly higher level language than assembly, which would still be order of magnitudes faster than BASIC and would come at little cost for me. |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 07 Oct 2009 09:49:54 pm Post subject: |
|
|
| Very little or a lot, depending on who you ask. Most C programs are, or can be easily turned into, valid C++ programs as well. So if you write C++ like I do (not very often), it looks and feels a lot like C. But if your C++ code uses a lot of inheritance and interfaces and operator-overloading and namespaces and (shudder) templates, then C may seem completely alien to you. |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 29 Oct 2009 12:12:18 pm Post subject: |
|
|
Here's a quick summary of my progress thus far :
* proper list/search of flash apps
* execution of flash apps
* basic TIOS compat layer (flash apps wouldn't be of much use otherwise)
* floating point math (+ - * / shift and compare only atm)
* much improved on-calc debugging tools : at any time, provided interrupts are enabled, pressing On+Del will bring up a pretty register/stack dump and allow to either resume execution (Clear), return to OS console (Mode) or open hex editor and jump to the selected address (Enter). If the later is chosen, quiting the hex editor will bring you back to the dump with the same choices.
* support for the screenshot command of the link protocol (though no very useful atm since you need to manually enter host mode for it to work)
another noteworthy thing I've done recently is porting Ben Ryves Expression Evaluator to XOS and significantly improving it : it now sports functions that take arbitrary number of parameters, can run with interrupts enabled, has several new operators and there's more to come.
next on my todo list :
* send/receive flash apps (its a bit annoying to be forced to temporarily reload TIOS to manage flash apps...)
* TIOS program execution (the 8k limit will be a *hard* limit due to XOS system memory layout)
* proper emulation of VAT I/O (can read but cannot write atm...)
* ...
oh and if this catch anyone's interest I'll be glad to release more frequently or even to create a SVN repo, just ask... |
|
| Back to top |
|
|
hotdog1234
Advanced Member
Joined: 14 Aug 2009
Posts: 291
|
| Posted: 29 Oct 2009 12:18:39 pm Post subject: |
|
|
| I would enjoy a SVN repo |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 29 Oct 2009 01:18:18 pm Post subject: |
|
|
fullmetalcoder wrote: There might be BBC basic support -if either the source code is released and ported or the compat layer allows the BBC basic app to be emulated properly - or support for another interpreted language if someone writes an interpreter for it but I am not going to do it. The source code for BBC BASIC (Z80) itself is not available (I don't have it). Richard Russell kindly sent me the relocatable modules, which I linked into a static binary under CP/M and implemented the various routines that it relies on to work. I could release the source for the host interface, but that's mostly text input, text output, graphics routines and file I/O routines (though, thankfully, mostly OS agnostic - the TI-OS is involved as little as possible, mainly for file I/O). Let me know if there's something I could do to help!
Quote: another noteworthy thing I've done recently is porting Ben Ryves Expression Evaluator to XOS and significantly improving it : it now sports functions that take arbitrary number of parameters, can run with interrupts enabled, has several new operators and there's more to come. Interesting. The interrupt limitation was mostly due to BBC BASIC's FPP implementation (which uses all registers, including shadow registers). How have you replaced BBC BASIC's FPP? |
|
| Back to top |
|
|
fullmetalcoder
Member
Joined: 01 Aug 2009
Posts: 139
|
| Posted: 29 Oct 2009 02:20:25 pm Post subject: |
|
|
Hot Dog wrote: I would enjoy a SVN repo
Here you go : a Google code project. I have already committed my code to the SVN repo. (for some reason the name xos was not allowed as a project name so I choose the first alternative that came to me...)
benryves wrote: The source code for BBC BASIC (Z80) itself is not available (I don't have it). Richard Russell kindly sent me the relocatable modules, which I linked into a static binary under CP/M and implemented the various routines that it relies on to work. I could release the source for the host interface, but that's mostly text input, text output, graphics routines and file I/O routines (though, thankfully, mostly OS agnostic - the TI-OS is involved as little as possible, mainly for file I/O). Let me know if there's something I could do to help! Well in this case it will be simpler to just emulate all the required function and use it as an app since the end result will be the same. Or maybe not... Depends how much file I/O is involved (VAT emulation is quite a fearsome beast). The first thing you can do (and probably the simplest) is to give me the list of bcalls used in the host interface.
Quote: nteresting. The interrupt limitation was mostly due to BBC BASIC's FPP implementation (which uses all registers, including shadow registers). How have you replaced BBC BASIC's FPP?
Well, I simply replaced all calls to BBC basic FPP with calls to XOS fp routines and altered the memory/register uses accordingly : it only needs to maintain the addressses of two fp accumulators in hl and de. |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 29 Oct 2009 03:35:46 pm Post subject: |
|
|
fullmetalcoder wrote: Depends how much file I/O is involved (VAT emulation is quite a fearsome beast). The first thing you can do (and probably the simplest) is to give me the list of bcalls used in the host interface. The complication arises from the fact that the TI-OS doesn't have very good file manipulation routines, so I had to emulate a set of nice handle-based file manipulation on top of the TI-OS. If you then have to emulate the TI-OS file stuff this adds an extra level of indirection. :-)
The internal set of file manipulation routines in BBC BASIC are OSFIND (opening a file), OSBGET (reading from a file) and OSBPUT (writing to a file). There are then utility routines that can be used to query and set the file cursor position and file length, again by handle. How easy do you think it would be to write a wrapper around your API? |
|
| Back to top |
|
|
|
Project Ideas/Start New Projects => Your Projects
