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 ... 4 5 [6] 7 8 ... 24
76
« on: April 01, 2015, 08:01:51 am »
After a total 1-and-a-half years break, looks like i decided to continue the project  Started to re-read what i had written like, a weak ago. Hopefully, not much troubles about understanding myself. Currently coding some keyboard routines. I also intend to create some kind of custom APD feature. More to come. Peace bros.
77
« on: October 27, 2014, 05:47:38 am »
Hello Art_of_camelot. First, thx for your support =] About the 83+BE : The list of reasons is quite huge, in fact. Most of all, the idea of this project was to take the maximum advantage of RAM for execution and storage, and with the 83+BE, the gain would be quite unsignificant compared to the TI-OS environement (a few K's more is no big deal). But additionally : - small archive space : Hybrid uses that area to save files (appvars), and too many defragmentations could potentially end up being annoying for the user. - ports : Many are not present, especially port $23, which appears to be really useful to quickly get the start of the apps area (requires quite a heavy routine with the 83+BE, and implies saving the page number to RAM to save speed, which is way more dangerous if you think of it). - Only 2 RAM pages changes things quite a lot in my code (which is using the first 3 by default). - different keyboard delays (6MHZ CPU) - no possibility to change the RAM page in the last bank without changing the memory map mode - ... All those changes would basically represent the need to create a separate app just for the 83+BE, because handling those in one app for all models would represent a significant "unoptimization", mainly due to many hardware checks. Last reason : laziness, of course EDIT : Just finished the routine =] Hybrid will officially be able to defragment a whole sector ! Considering the complexity of that routine, that's already a great personal achievement. Now, let the debugging begin, which promises to be a pain if i f***ed up too much...
78
« on: October 26, 2014, 12:01:38 am »
Alright, finished the hard part of my sector defrag routine (the one that copies valid entries to the swap, and updates DAL/DAH/page on the way).
That was kinda hardcore, but it's finally done =]
Now, i need to :
- erase sector to defrag
- copy defragmented content from swap
- erase swap
Can't wait to see if my algo actually works, and how fast it is...
79
« on: October 22, 2014, 07:42:48 am »
Not quite true. At that point the TI-OS still clutters $0000-$3FFF. By "free", i was of course meaning that i don't use it, not that i removed it (i would have builded an OS in that case). Of course I wasn't talking about TI-OS's hooks. I know the RAM chip has execution hooks, so I thought maybe it had read/write hooks too. Oh, my bad. I don't intend to implement any hooks for the moment (so much to do yet). On a side note, some of the routines used by the CLI have already been coded so that the user can call them =] You can't write to $4000-$7FFF, as it is not RAM, unless you map a RAM page to it, but in this case it won't be compatible with TI-83+ BE which only have 2 RAM pages for $8000-$FFFF. Well, you can actually write to $4000>$7FFF, even if it's not RAM, but anyway, like i said, RAM page 1 will be mapped in this region by default. And like i stated in my very first post, i don't intend to make hybrid compatible with 83+BE hardware at all (not enough time to handle those annoying hardware differences =P).
80
« on: October 22, 2014, 07:13:13 am »
Well, just remember hybrid is 100% free from the TI-OS code and RAM.
That means TI-OS hooks aren't available at all.
$0000>$3FFF : unused (shame)
$4000>$7FFF : RAM page 1 - free to use for both execution & storage
$8000>$BFFF : RAM page 2 - free to use for both execution & storage
$C000>$? : RAM page 0 - free to use for both execution & storage
$?>$FFFF : RAM page 0 - some hybrid routines + hybrid data + stack
Inputting a command in the CLI causes the system to find the matching appvar in the archive space.
Then, its content is copied at $4000, and executed.
It can then freely cross banks a/b/c without having to worry about swapping at all (since it's contiguous RAM).
That basically means hybrid-compatible programs will start with a ".org $4000" directive, just like apps do.
About the system routines located in the app page :
I didn't want to mess up with IM2, to allow the user to use it without restrictions.
I will use the following code :
#define hcall(xxxx) call hybcall \ .dw xxxx ; available in hybrid.inc
hybcall ; This routine will be available in ram page 0, in order to be accessed from anywhere.
ex (sp),hl
ld a,(hl)
ld (hybcall_id),a
inc hl
ld a,(hl)
ld (hybcall_id+1),a
inc hl
ex (sp),hl
in a,($06)
ld (hybcall_backup),a
.db $3E ; ld a,
hybcall_page
.db 0 ; replaced by the app page during system initialization
out ($06),a
.db $CD ; call
hybcall_id
.dw 0 ; updated by the code above
.db $3E ; ld a,
hybcall_backup
.db 0 ; updated by the code above
out ($06),a
retI know what you're thinking.
That sucks many cycles, but remember i don't want to use interrupts and must avoid destroying too many registers.
Don't hesitate to let me know if you see a faster way (only A must be altered).
81
« on: October 22, 2014, 05:21:55 am »
Yep, already heard about such interesting solutions, like crabcake or similar.
However, hybrid will allow to run contiguous code on the 3 available banks.
Another good point is the usage of RAM for temporary storage.
Indeed, you will be able to use A LOT (not only those tiny ram locations provided by the TI-OS).
It will be as easy as just putting a label at the very end of your program, and refer to it to read/write data.
Such space will be as high as what you have left after the program has been loaded, without having to swap anything (128K RAM model users will still be able to use the additional 5 pages if necessary, of course).
82
« on: October 21, 2014, 06:07:10 pm »
Small update...
Hybrid will basically use 2 types of routines :
1) routines located in bank C : code only executable from ram, but also code reading/writing huge amount of data (that could potentially be located on the 3 banks).
2) other routines, that will directly be executed from the app page (basically, routines using only registers as input/output, or dealing only with ports).
I just implemented a dedicated code to call those, that handles automatic page restoration.
It will be easily usable with a macro, defined in hybrid include file : hcall(xxxx).
Was a bit tricky, but i managed to make it alter nothing except the accumulator (had to modify a few routines actually using it).
On a side note, i can confirm that hybrid will allow to run code bigger than 32768 bytes (very probably more than 40K).
It should be (i hope) especially useful for low ram model users.
The way it currently goes, the app itself shouldn't exceed 1 page.
Also, i'm thinking of leaving the possibility to chose to backup the TI-OS RAM or not, at startup.
That way, users not using it at all could add extra life to their flash chip.
Chosing "no" would cause a RAM clear upon exiting hybrid, ofc.
It should particularly be appropriate for testing and debugging =]
83
« on: September 30, 2014, 12:19:57 pm »
Well, erasing the OS itself is no big deal, but the boot code would definitely be annoying.
Fortunately, it cannot directly be erased, but the certificate, however, can.
Anyway, such things shouldn't happen cause my flash write routines automatically return if you attempt to write anywhere else than bank A or B, as well as if the page swapped in is not included in the archive space reserved for variables (making it impossible to damage applications too).
But, since it will still be possible to jump after the implemented security, i'm thinking of putting those routines in a dedicated 1024 bytes area with execution restriction, that the system unlocks when needed.
That way, accidental jumps would be handled, except if you manually unlock that region first of course.
84
« on: September 26, 2014, 11:57:18 am »
He he, of course.
My flash routines can only write to archive space =P
My LCD routines are safe too, in case the user inputs bad values potentially leading to test mode (lcd bleading).
86
« on: September 24, 2014, 07:11:53 am »
I'm currently reformating some routines, again, but that definitely needs to be done now, while i still understand my own code It's a bit of a headache, since i have to make them compatible both for the app and for the user. I've decided to follow some kind of a scheme. Reading ROM will always be performed in bank A, and writing in bank B. That means i will have to run my defrag code from bank C during the app execution, which promises to be kinda tricky, since i don't want to touch any RAM not used by the system. Indeed, that code will be too large to fit in the stack area, so i will probably do the following : 1) Backup the 1536 bytes used by mathprint (page 2 or 3 depending on calc) into savesscreen & appbackupscreen (appears to fit just right). 2) Map page 2|3 into bank C and use those 1536 bytes for my code, a bit of data, and a reallocated stack. 3) Restore stuff when done. That will save many complicated page swaps and should definitely speed up the defrag job. Let's try that...
87
« on: September 23, 2014, 04:53:49 am »
Will the utility have routines to make it easier to use sound inside games and perhaps Calcnet stuff?
Well, i don't intend to implement such routines in the early release, but that would sound great in the future, if it's possible =]
88
« on: September 20, 2014, 01:39:18 pm »
2 new routines, used by the kernel, but which will also be available to the developper who wishes to use the system CLI for input/output, for simple interactions with the user :
hybdispchr : displays a character at the current cursor location (scrolling handled). That one will actually be called every time you type something.
hybdispstr : same thing but for strings (wrapping+scrolling handled).
I will code hybnextline and hybclr tonight (easy), and the output part of the CLI will pretty much be ready.
More to come...
EDIT :
Alright, the output part is now done (so far : hybclr, hybclrin, hybnextline, hybdispchr, hybdispstr).
Despite those routines are initially for output, some are also designed to make the main input code easier (especially hybclrin & hybdispchr).
During the coding, i also had to decide which pointers i'll use.
Only 3 will be needed : the cursor (only one value), the start of the current input, and the end of it.
I made things so that the programmer should not need to adjust them.
The system is currently using a 144 bytes text shadow (128 + 16 spaces only used for scrolling).
89
« on: September 16, 2014, 01:09:13 pm »
Don't worry, a CLI won't represent much trouble (i easily "see" the algorithm in my mind). About arguments, that was just an old idea, in the middle of a many. That would imply handling specific headers, and such new formatting could be annoying for the developper, which will already have to adapt to hybrid basic rules. Instead, i could, later on, create a program that automatically handles data input/output such as parameters, file names, etc... I will probably go for that solution, cause i'm sure parameters will complicate the CLI way too much for me But i must say a batch system (without params, just to automate the run of multiple programs) sounds really appealing to me =P
90
« on: September 15, 2014, 09:34:48 am »
Quite a lot to do, indeed... Well, the CLI will be quite minimalist. There won't be many features, just the essentials. Mainly because i think the most important things should be done by the programs themselves (at least on a calculator). Every command that you enter will cause the kernel to search the archive space for an appvar with that name, check if it contains hybrid-compatible executable data, verify the size, load the stuff @ $4000, and jump to it. The commands history will scroll down, but there won't be any way to scroll it up (i want to avoid wasting some precious RAM, yeah, that's an excuse ). But still, i intend to reserve 112 bytes for some kind of txtshadow, for when you exit a program. You will be able to enter lower and uppercase letters, numbers, and that's all (following the appvars name formatting). The input line length will probably be restricted to 1 line. As you can see in one of the previous screenshots, the char @ (15,0) will be reserved for busy state, as well as current type mode. The only available special key combinations will be [ENTER], [CLEAR] (clears the current line, or the whole window if the line is empty), and [2ND]+[MODE] (back to TI-OS). After that, and due to how it works, special commands could simply be added by making tiny programs that you normally run (a bit like in .COM files in our good old DOS). I had some projects about handling special programs, a bit like batchs, but i need to code a proper text editor first (not for tomorow).
Pages: 1 ... 4 5 [6] 7 8 ... 24
|
Show Posts