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 ... 3 4 [5] 6 7 ... 24
61
« on: April 25, 2019, 12:13:59 am »
Oh, great news! I've had a few big projects like that (lost and then years later found a place that had an earlier backup). Good luck; it's a lot of work trying to relearn your old code.
I'm not there yet, but that part will come soon enough, i hope. ##### Aight, just finished reconstructing everything i could. The result is pretty encouraging, i have almost everything back, including the full 120KB latest source. The only thing absolutely unrecoverable is a tiny text file that holded some data about the ti-os ram backup structure, but it looks possible to rebuild it from scratch without too much trouble. More to come...
62
« on: April 24, 2019, 12:03:01 am »
Hello there.
Not sure if that has been solved yet, but i remember having discovered long ago that BMP files can actually have 2 different file stuctures, depending on the software used for saving.
If zstart only handles 1 of them, that could explain the issue.
63
« on: April 23, 2019, 11:43:09 pm »
I'm excited to see where you go with this  With that "Disp(1337)", not far... ##### GL xedy
64
« on: April 23, 2019, 09:49:05 pm »
Hello there, good old omni-folks =]
First of all, sorry for the lack of news.
Long story short, 4 years ago, the whole source (and something like 15 years of personal data) got properly nuked by a ransomware, all different backups i had.
Pretty recently, i found an unexpected clean backup on my WW1 laptop, not the most recent one though, but pretty close to it.
I'm currently in the process of crossing the data with some cheese i was able to recover from the crypted files.
I'll keep you updated on how far the project has a chance to resurrect, but it looks like there may be decent hope.
In the mean time, kisses !
65
« on: June 07, 2015, 04:13:56 pm »
Alright, so, looks like wabbitemu is more a liar than i expected (had some funky surprises on real hardware). I am currently recoding lots of stuff. The good point is that i already updated around 75% of the source (mainly everything lcd/keyboard/GUI related). Was a great opportunity to optimize here & there. In the mean time, a quick overview of "hybchoice", a high level routine that will be available to coders :  What you see is easily performed with the following code : ...
ld hl,hybchoice_example
call hybchoice
...
hybchoice_example
.db 7 ; (7 lines total)
.db "choice ? " ; (line 1 used for title)
.db " one " ; (line 2 used for choice 1)
.db " two " ; (line 3 used for choice 2)
.db " three " ; (line 4 used for choice 3)
.db " four " ; (line 5 used for choice 4)
.db " six " ; (line 6 used for choice 6)
.db " five " ; (line 7 used for choice 5)
.db 0 ; (separator)
.db 2 ; (choice 1 located line 2)
.db 3 ; (choice 2 located line 3)
.db 4 ; (choice 3 located line 4)
.db 5 ; (choice 4 located line 5)
.db 7 ; (choice 5 located line 7)
.db 6 ; (choice 6 located line 6)
.db 0 ; (separator)What i actually do is pressing down 5 times, then up 5 times. The routine supports 1-7 lines, but scrolls if necessary (the whole block is handled as a home entry). Also, like "hybpause" & "hybprompt", it can be exited with ENTER or QUIT (a bit like Ctrl+C in DOS), and automatically handles key repeat and a 3 minutes APD.
66
« on: May 12, 2015, 12:56:58 pm »
It sounds like things are coming along really well. The only thing i really use bcalls for is to mess with the VAT (find files, appvars, etc.) and for hooks, i don't think most games will miss TI's routines.
It's good that you talk about the VAT, cause there are things i didn't mention. Hybrid won't use any form of alloc table, only realtime archive space read/write. It may be slower than using a table in RAM, but i really hate the idea to be restricted by RAM just for that. BUT, things are not so easy, since i also want files created/deleted under hybrid to be handled properly under the TI-OS. That means i have to keep track of the available RAM for VAT entries. Also, before returning to the TI-OS, i have to actually rebuild a part of the VAT when restoring RAM, which will definitely represent some boring coding sessions. PROGRESS : I just finished coding/debugging "fileinfo" & "filedel". "fileinfo" returns the following informations : file size, starting page & adress, and the same things for the actual data. "filedel" handles the following error situations : missing/corrupted files, low batteries, and flash errors. On my way to code "filenew", which promises to be quite tricky due to possible VAT interactions. EDIT : "filenew" coded successfully =] It handles everything for the user, including sector defragmenting if necessary. Time to code probably the last 2 user-available routines, "filewrite1" & "filewritex". "filewritex" should definitely be hot, since source data can potentially start in a bank and end in another. Hopefully, the low level code i'm gonna use automatically detects bank overflows =P
67
« on: May 09, 2015, 12:39:18 am »
A few things to keep those interested updated : I'm still working on the high level archive routines. Things are going pretty well so far, but i can say that 100% of my coding concentration is definitely required  The idea is to make things simple, like handling page swapping automatically, as well as using memory offsets as inputs (for example, 0 would mean the very first byte of the actual data of the file). About the memory layout : Since things are currently being more & more precise, i finally had to make the choices i needed to make. RAM pages 0 & 1 will be reserved for program execution in banks 1 & 2 ($4000>$BFFF). RAM page 2 will be reserved for the system in bank 3 ($C000>$FFFF). 1024 bytes will be reserved for the stack, which will be located at $FC00>$FFFF (SP initialized at $0000). The other RAM pages will be usable for temp or permanent storage, but will require to be manually swapped. So, basically, hybrid will handle 32768 bytes programs, which is still way better than under the TI-OS. About the initial setup : CPU at 15MHZ Entire RAM executable Flash unlocked by default, but don't be scared, hybrid routines cannot write anything outside of the archive area reserved for variables, and the probability to actually code a flash write sequence by mistake is so damn close to zero. About limitations : The hybrid environement will pretty much be a great solution on many aspects, but recommended for experienced coders. No interaction with the TI-OS whatsoever. No TI-OS ROM calls, only hybrid RAM calls (regular CALL instruction). No RST instructions. No interrupt mode 1, only mode 2. About file formats : As already mentioned, hybrid will be able to read/write appvars. Executable code will require an additional header. Things are not done yet, but i intend to be able to have multiple programs inside one appvar. Haven't decided yet if a batch system will be handled or not. I'm also thinking of making writeback possible. What won't be available in the first release (for sure) : Basically, there won't be any link/USB RAM calls, but who knows in the future...
68
« on: May 07, 2015, 10:33:45 pm »
I don't get it, so is his a shell or os?  How can an os be "hybrid" and be in a the shape of an app for a different os?
Well, i decided to use that name because it shares the properties of both a shell & an OS. Technically, it is executed from the original OS, like a shell, but once it's loaded, 100% of both executable & non-executable data is standalone. That means it uses its own low level interactions with the hardware, and is free to use every single byte of RAM, just like an OS does. Hybrid starts from the TI-OS, whereas an OS starts from the boot code. Apart from that, there is not so many differences.
69
« on: April 30, 2015, 11:41:11 pm »
Well, it seems that i didn't have that much bugs in my flash routines. I was expecting some hard debugging, since i barely tested them, 1 and a half year ago. To give you an idea of the speed, here is a quick screenshot. What the routine does is copying 65536 bytes from ROM to ROM, directly (no RAM buffer at all). The busy cursor (upper right corner) is used as an indicator of the duration. That is at 15MHZ minus the tiny slowdown from wabbit & imgur. There you go : 
70
« on: April 29, 2015, 02:33:07 am »
Thx TheMachine02 =]
To tell the truth, i'm kinda proud to have a working CLI without having used a single byte from TI.
If everything goes well with my flash routines, i'm gonna code some little higher level archive interaction stuff soon.
More to come...
71
« on: April 27, 2015, 12:26:51 pm »
72
« on: April 22, 2015, 03:36:13 pm »
Thx chicky ! Successfully coded poweroff, hypause, and hybchoice. The next one, hybprompt, definitely promises to give me some nice headaches After that, the CLI input/output system will be complete. I promise a few screenies at that point =]
73
« on: April 20, 2015, 06:40:44 am »
CLI PROGRESS
After some long thoughts, i decided to make it ins/del only (no overstrike input).
It is gonna use a 128 chars buffer, similar to TI's textshadow, which will basically be used for refresh.
Vertical scrolling will definitely be handled.
However, the entries will only scroll up, not down (basically, no history access apart from what you can see on the screen).
Currently, about 50% of it has been coded.
Wasn't easy, as like most of what i write, everything must be usable from both the kernel and user programs.
done :
lcddisphyb (shadow display)
lcdinvcur (cursor blinking display, subroutine)
hyboutclr (clears everything except title bar)
hyboutnl (newline, automatic scrolling)
hyboutchr (putc, automatic scrolling)
hyboutstr (puts, automatic scrolling)
hybinclr (clears current input field or screen if empty, subroutine)
hybinchr (character insertion at current cursor, subroutine)
hybindel (character deletion at current cursor, subroutine)
in progress | to do :
poweroff (manual & automatic power off, subroutine)
hybpause (waits for ENTER)
hybchoice (custom arrow-based choice input)
hybprompt (effect very similar to when using the input token in a basic program)
ROM USAGE
The low-level part is already coded.
I will have the following main routines to code once i'm done with the CLI :
fileinfo (checks if an appvar exists, and returns the start of the actual data)
filenew
filedel
RAM USAGE
Definitely have some things left to figure out there.
About program execution space, i'm still hesitating between only 32768 bytes, or more.
About the TI-OS RAM backup, i am currently considering to allow the usage of extra RAM on 128K models, to reduce flash abuse.
Also, i'm already thinking of potential compatibility problems between versions...
74
« on: April 15, 2015, 10:49:03 am »
Wha, welcome back!
Also good luck on picking up your project again, it can be quite tough to pick up old projects.
Thx ! Especially with asm. Fortunately, i did my best to document my own code enough =] I was just wondering what was going on with this project, glad to see you working on it again!
Glad to see some interest =] These days, i currently have my head straight on the CLI routines. Also, i decided to let the user decide if he wants to backup the TI-OS RAM at startup, rather than making it automatic.
75
« 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...
Pages: 1 ... 3 4 [5] 6 7 ... 24
|
Show Posts
