This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - the_mad_joob
Pages: 1 ... 5 6 [7] 8 9 ... 24
91
« on: September 15, 2014, 08:14:51 am »
Yeah, looks like that reply got lost somewhere in the wordwide flow.
Anyway, thx a lot for your interest =]
What's left to do ? Well, let me see...
For the system to be operational, i need :
> finish the RAM backup section
> define which system RAM locations will be available to the user, move the data in the system RAM, and add the equates in hybrid.inc
> same thing for system rountines (a little reformating required for some of them, cause they are currently executed from the app)
> define the location and available size of the hardware stack
> code the kernel (should include the command line interface, program loading/return code, and hybrid exiting)
> code the RAM restore section (should be way easier than the backup, but it will include a VAT update which should be a bit hardcore)
I probably forget a few things...
92
« on: September 15, 2014, 05:35:31 am »
Ah ok but if it's a shell rather than a full OS, how will it be possible to access the entire 128 KB of RAM even from the TI-OS? Or will it just be restricted to games/programs running from inside the shell? In both cases you would have to make sure that no compatibility issues occur with programs that uses extra RAM, like TI-Boy SE.
When you run the app, all the TI-OS RAM data is backed up in the archive (stuff in pages 0, 1, and 2|3). Then, page 1 in mapped in bank A, page 2 in B, and page 0 in C). As far as i know, those pages are not used for permanent storage, except by the TI-OS. By default, hybrid will not touch the other pages. But, hybrid-compatible programs will still be free to use them if they need to (for temporary or permanent storage). So bascially, like on the regular TI-OS environement, the program creator is responsible for compatibility conflicts (but also the user if he hasn't checked the program readme). I initially had the idea to be able to use some other pages for program execution using a custom page swapping method, in order to be able to run 64K programs. But i don't know if that will be possible (depending on how the project goes), but again, the user is free to decide to run such programs or not. UPDATE > re-coded a few routines : flasherase / flashwrite / flashcopy > still working on sector defragmenting (once done, i can finally code the RAM backup part)
93
« on: September 14, 2014, 02:35:35 am »
Also looking at all this RAM, I wish we could use all of it for our daily calc uses and perhaps have the programs stored in archive all the time like on newer calcs.  Had this project idea exactly for that =]
94
« on: September 14, 2014, 01:22:50 am »
They actually look pretty nice, especially the top ones which should fit well for menu titles and stuff. 
Thx for the feedback =] Yes, i used the first two lines especially for that, since those chars were initially old ASCII control characters (non-displayable), not handled by modern text editors anyway. I also added the black arrows and smileys, in the last unused slots. But everything else is following ASCII/ISO-8859-1/CP-1252. That means text data will match what you can see in a regular computer text editor. Here is an example of a title bar usage (hybrid loading screen actually) :  I hate to ask the obvious question, but is it compatible with the CSE?
Well, hybrid works almost like an OS, in the way that it is totally independant from the TI-OS. That basically means it will only run hybrid-compatible programs (you can forget about basic, TI-asm, ion, mirage, DCS, etc...). On a side note, it doesn't destroy anything already existing on your calc. In other words, you could for example have DCS and hybrid on the same calc without any problems. Then, you would use DCS to run DCS-compatible programs, and hybrid for hybrid-compatible programs. Hybrid will share the archive space with the TI-OS, but will only be able to recognize archived appvars as files. Those appvars will first include the TI-OS standard header (for you to be able to eventually manage the files in the TI-OS, but also send/receive them with TI-connect), followed by a hybrid header (defining if the file is compatible with hybrid, if the data is executable or not, and stuff like that).
95
« on: September 13, 2014, 01:39:40 pm »
UPDATE > Totally rewritten arcchk & arcenough routines (bug fixes, great speed/size ratio optim) > arcenough pass 2 coded (can now find if a sector could handle the data after a defrag, and returns the sector 1st page in that case). > Still working on the sector defrag algorithm. If i manage to make the routine light enough, i could run it in the hardware stack area, allowing to have 2 available banks (would remove the need to swap between read/write, speeding things quite a lot). In the mean time, and for the curious, hybrid system font will look like this : 
96
« on: September 05, 2014, 05:17:11 pm »
He he, thx for sharing your opinions guyz =]
And yeah, i'm pretty sure many already thought of something like that...
EDIT : Just coded pass 2 of the new arcenough routine at work. Now time to code the sector defrag...
97
« on: September 05, 2014, 05:13:58 pm »
Alright, i'm gonna re-write my arcenough routine.
My goal is to make it work the following way :
- first pass : check for space avaiability, considering deleted variables as unavailable space
- if success : return page and location to store data (no defrag + Garbage Collect required)
- if failure :
- second pass : same, but this time, consider deleted variables as available space
- if success : defrag+GC only the concerned sector, then return page & location to store data
- if failure : return error
As you can see, there are 2 things i won't handle :
- defrag+GC in apps area : It is not always the case, but i will assume all apps are deleted from the TI-OS, which already does that job.
- overall defrag+GC in vars area : Doing it for all sectors will 1) abuse flash 2) be hard/long/boring to code/debug, and i need to move on.
Let's try that and see how it goes...
98
« on: September 05, 2014, 12:45:55 am »
Hello DJ, good to see the veteran =]
I'm definitely not ready for a full OS, and that's one of the reason i came with that idea.
Also, i think it's quite important to still be able to use the TI-OS, since many have lots of stuff running from there.
And about doors/ion/mirage, i don't intend to compete them, but if things go well, you should be able to run very fat programs with hybrid (maybe 40K+).
If it sees the light, it could be quite an interesting platform for running huge RPGs, for example.
Initially, i wanted to make it handle a custom page swapping system, allowing to run up to 65K programs.
But i think i'll see how things go for now, cause there's so much to code...
99
« on: September 04, 2014, 09:49:26 pm »
Hello everyone...
Alright, i'm trying to dedicate as much time as possible on that new project of mine, and decided to create this topic on the way (not to mention some of you were curious about it).
It will be something between an OS and a shell, which explains the name.
I intend to make it some kind of dev environement too, but that part is still a bit obscure.
The main idea is to be able to run large programs (at least 32K, but probably more), while still being able to use the TI-OS for what it is supposed to be, a calculator.
The hybrid environement will be independant from the TI-OS, so rom calls won't be available at all.
I'm creating a few basic routines, but maybe libraries will be handled, not sure yet.
When using hybrid, RAM will only be used as a temporary storage.
Basically, what it does is backing up the TI-OS RAM data in the archive, making pages 0 & 1 free to use.
It will be an old-school command line interface (yeah, we're in 2014, plz stop crying).
It will only recognize archived appvars, as executable or non-executable data, but i intend to use specific headers for file types.
When loaded, everything is unlocked (flash and RAM/ROM execution).
Will be compatible with all OS and models (basic 83+ excepted, due to too much hardware differences).
memory layout project (subject to changes) :
$0000>$3FFF : reserved for TI-OS (ROM page 0)
$4000>$7FFF : free space (initially RAM page 1) (programs loaded at $4000)
$8000>$BFFF : free space (initially RAM page 2)
$C000>$FFFF : free space , hybrid routines , hybrid data , hardware stack (initially RAM page 0)
What's done so far (without using any rom call, except jforcecmdnochar ofc) :
- starting loading interface
- recognizes, saves and displays model, total RAM, and total ROM
- overall archive check for corruption (missing swap sector, invalid sector status bytes, invalid variable status bytes, variables crossing sectors, zeros in unallocated space).
- detects corrupted stack & VAT.
- check if enough archive for TI-OS RAM data (the amount should vary but never exceed 32158 bytes).
- large system font, matching ASCII, ISO-8859-1, and CP-1252, with some dedicated chars for title bars.
- a few basic optimized standalone routines, using only registers as input, which will be callable from any program :
-- lcdres (lcd clearer)
-- lcdreswin (clears all but title bar)
-- lcdset (lcd filler)
-- lcdinv (lcd inverter)
-- lcdsave (printscreen, saving to custom location)
-- lcddisp (grbufcpy, restoring from custom location)
-- lcddispchr (putmap)
-- lcddispchri (putmap inverted)
-- lcddispstr (puts, with size to be put in a register, automatic wrapping)
-- lcddispstri (same, but inverted)
-- lcdinvchr (inverts an already displayed char)
-- lcdinvstr (inverts an already displayed string, automatic wrapping)
-- arcchk (archive space check for corruption, also returns the first page of apps area)
-- arcenough (check if enough contiguous free space in archive)
current used size in the app : 4833 bytes (font itself takes 2048 bytes).
Next step : some kind of smart garbage collector / defragmenter, which will only make space for the inputted amount, without defragmenting the whole archive to save the chip's life.
More to come...
100
« on: August 22, 2014, 05:13:12 pm »
It's me, again.
So, does anybody know how i am supposed to handle batteries becoming low in the middle of a writing operation ?
I mean, is it necessary to check them before every single write attempt ?
If yes, that would slow down large writings quite a lot...
101
« on: July 06, 2014, 04:55:31 am »
Ok...
I had to ask, since wabbit says those 2 pages are empty...
I just hope it is not supposed to include such infos as app locations, cause that would mean i'd have to update that stuff, and i'm definitely lazy about that =P
102
« on: July 06, 2014, 04:44:16 am »
No, I mean, in your flash write routine, when you see an error, double check if the data is in fact different than what was intended to be written, and only report an error if it's different. This will save you from the logic of retaining the status read value in a register. Oh, my bad (thought you were talking about using the OS error handler). I think i'll use that then : ;c = byte
;de = address
ld hl,$0AAA
ld (hl),l
ld hl,$0555
ld (hl),l
ld a,$A0
ld ($0AAA),a
ex de,hl
ld (hl),c
check
ld a,c
xor (hl)
ret p
bit 5,(hl)
jp z,check
ld a,c
xor (hl)
ret p
ld a,$F0
ld ($0000),a
scf
ret
;cf = 0 (success) | 1 (failure)That sounds interesting. You have my attention. I honestly don't know if that project will see the light, but i'll do my best =] EDIT : DrDnar, You said earlier that the calc would probably crash if batteries are low during a flash operation. Isn't DQ5 (bit 5) supposed to handle that ? Anyway, i already intended to check the batteries before starting any operation, but i guess it would be hard to detect batteries becoming low enough right in the middle of an operation...
103
« on: July 05, 2014, 04:08:49 pm »
In that case, have the error handler check the data to see if it's actually different, which will be slightly faster.
Good to know. Is the error handler system-dependant ? Cause if yes, my project will be totally free from the TI-OS. I guess i would have to use IM 2 or something to be able to do that...
104
« on: July 05, 2014, 03:23:24 pm »
That can happen, and in fact probably happens a lot, but it's not a problem unless your routine also returns an error status. Issuing the reset command in read mode does nothing, so there's no reason to go out of your way to prevent that. Interesting... But yes, my code will have to specify if an error occured. Thx for your time, again =]
105
« on: July 05, 2014, 08:47:16 am »
Alright, since i didn't find much doc about that, here is the thing :
Normally, apps are automatically defragmented by the TI-OS when deleted.
However, that's not the case when they are deleted by a user program or app using _deleteapp (it just marks the app as deleted, $00 at 1st byte of 1st page).
Now, let's say i want to code a routine that will defragment the apps area.
In the case i have to erase page $68 or $69 (or both), i will of course have to erase the whole sector.
The thing is, that will include pages $6A & $6B (described as "certificate list" in the SDK).
Anybody knows what kind of data those pages are supposed to hold ?
Of course, i intend to restore them after the erase procedure, but is erasing them a problem ?
Pages: 1 ... 5 6 [7] 8 9 ... 24
|
Show Posts