Author Topic: HYBRID (8X+) (Read 37769 times)

the_mad_joob · « **Reply #30 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.

the_mad_joob · « **Reply #31 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 =]

DJ Omnimaga · « **Reply #32 on:** October 21, 2014, 06:56:20 pm »

I'm glad that larger code can be ran. On 8x calcs it was annoying to be limited to 8 KB of code, although it has since been resolved (with TI making Flash APP development free then almost a decade later the many programs to remove the 8xp 8 KB of code restriction)

the_mad_joob · « **Reply #33 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).

Matrefeytontias · « **Reply #34 on:** October 22, 2014, 05:23:04 am »

How is that done ? Do you use some sort of interrupt or writing hook to swap pages when necessary ?

the_mad_joob · « **Reply #35 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 :

Code: [Select]

#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
    ret

I 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).

Matrefeytontias · « **Reply #36 on:** October 22, 2014, 07:20:26 am »

Quote from: the_mad_joob on October 22, 2014, 07:13:13 am

Well, just remember hybrid is 100% free from the TI-OS code and RAM.

Not quite true. At that point the TI-OS still clutters $0000-$3FFF.

Quote from: the_mad_joob 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.

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.

Quote from: the_mad_joob on October 22, 2014, 07:13:13 am

$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

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.

the_mad_joob · « **Reply #37 on:** October 22, 2014, 07:42:48 am »

Quote from: Matrefeytontias on October 22, 2014, 07:20:26 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).

Quote from: Matrefeytontias on October 22, 2014, 07:20:26 am

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 =]

Quote from: Matrefeytontias on October 22, 2014, 07:20:26 am

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).

the_mad_joob · « **Reply #38 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...

TIfanx1999 · « **Reply #39 on:** October 26, 2014, 09:08:57 pm »

Just wanted to stop in and say that this looks pretty neat. Also, I'm rather curious why this won't work with the 83+BE. I didn't think the hardware was that much different between the 83+BE and the 83+SE/84+/84+SE. The only thing that really comes to mind is the slower processor in the 83+BE and the lack of crystal timers (and USB of course, but that shouldn't matter). *edit* Forgot to mention the lesser archive space of the 83+BE, but I don't think that matters either in regards to this project. However, IIRC the 83+BE also has less of the extra RAM pages, and I guess that could be an issue?

the_mad_joob · « **Reply #40 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...

the_mad_joob · « **Reply #41 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.

Sorunome · « **Reply #42 on:** April 01, 2015, 02:12:04 pm »

Wha, welcome back!
Also good luck on picking up your project again, it can be quite tough to pick up old projects.

the_mad_joob · « **Reply #43 on:** April 09, 2015, 11:20:14 am »

Basic keyboard input routines coded.
I'm currently working on an effective way to detect multiple keypresses.
I found out that it would be faster to actually "ask" for a specific combination, instead of scanning the whole keyboard each time.

I'm also trying to code "softpoweroff" & "softpoweron".
Using the HALT z80 instruction works like a charm, except that i need to have interrupts enabled to make it work.
That is a problem, cause i cannot use IM 1, since bank B won't hold what it is supposed to.
Currently, the only workaround i see is to use IM 2 instead, but that implies wasting 257 bytes just for that.

More to come...

chickendude · « **Reply #44 on:** April 11, 2015, 10:03:16 am »

I was just wondering what was going on with this project, glad to see you working on it again!

Author Topic: HYBRID (8X+) (Read 37769 times)

the_mad_joob

Re: HYBRID (8X+)

the_mad_joob

Re: HYBRID (8X+)

DJ Omnimaga

Re: HYBRID (8X+)

the_mad_joob

Re: HYBRID (8X+)

Matrefeytontias

Re: HYBRID (8X+)

the_mad_joob

Re: HYBRID (8X+)

Matrefeytontias

Re: HYBRID (8X+)

the_mad_joob

Re: HYBRID (8X+)

the_mad_joob

Re: HYBRID (8X+)

TIfanx1999

Re: HYBRID (8X+)

the_mad_joob

Re: HYBRID (8X+)

the_mad_joob

Re: HYBRID (8X+)

Sorunome

Re: HYBRID (8X+)

the_mad_joob

Re: HYBRID (8X+)

chickendude

Re: HYBRID (8X+)