Show Posts

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.


Topics - the_mad_joob

Pages: [1] 2
1
ASM / looking for a code exorcist
« on: December 18, 2020, 10:26:02 pm »
Welcome.

While i was randomly testing stuff on a TI-83+ (real hardware), i came across a pretty unexpected behaviour.
I isolated what's relevant in a tiny program :
Code: [Select]
.db $BB,$6D
di
xor a
out (1),a
ld bc,0
wait_key_released
in a,(1)
inc a
jp nz,wait_key_released
ret
That code does what it's supposed to do successfully.
When you press ENTER to start the program, it freezes until you release the key.
Then, when the key is released, you're back to the homescreen.

Now let's say you decide to use LD BC,1 instead.
In that case, you should expect the exact same behaviour, right ?
Well, in reality, the program exits right away, despite the key is still being pressed.
That basically means the loop is exited at some point (i suspect it's exited right away).
The very big problem i have with that, is that the LD BC,X instruction isn't supposed to have any influence on the condition check at all.
Any idea what's happening ?

EDIT 1 :

I suspected it had something to do with the proximity of the OUT & IN instructions, and i believe i was right.
Indeed, if the LD instruction is removed, the keypress is ignored aswell, probably because the TI-83+ keyboard is so slow that opening groups takes some time.
With a single NOP instruction, keypress ignored aswell.
However, 2 NOP instructions are enough.
But that doesn't solve the mystery yet, because that would mean that somehow, 2 NOPs (8 CC) take more time to process than 1 LD BC,X (10 CC).
And that still doesn't explain why the processing time of LD BC,X can vary depending on X.
Is my z80 drunk ?

EDIT 2 :

I officially entered the twilight zone.
I started to test the LD BC,X arguments, in hope of finding a pattern.
I didn't, but instead, i found out that it's even worse than i thought :
Code: [Select]
0 = keypress not detected
1 = keypress detected
WTF = RAM clear when key released

LD BC,X RESULT
$0000 1
$0001 0
$0002 1
$0010 1
$0011 0
$0012 1
$00F0 1
$00F1 WTF
$00F2 0
$00FF 0

2
ASM / investigating port $2F
« on: September 29, 2020, 06:38:45 am »
Welcome.

Long story short, i'm trying to code a new LCD tool that optimises port $2F, so i used this page as a reference.
For now, i'm only interested in the port's behaviour under CPU speed 1 (port $20), and while having ports $2A & $2E holding their default values.



DELAYS

For my project, i need to know the exact amount of cycles during which bit 1 of port $02 is reset, depending on port $2F configuration.
But since i don't precisely know when a port is considered read|written during the instruction processing, i checked the amount between them (port $10|$11 read|write <> port $02 check).
So, i was expecting smaller amounts than what's stated on the wiki (48,112,176,240).
Here are the results of my tests :

Spoiler For Spoiler:
port $2F = %------00 :

clock cycles between IN|OUT and IN A,(C) :
40- : port $02 = %------0-
41+ : port $02 = %------1-
clock cycles between IN|OUT and IN A,($02) :
41- : port $02 = %------0-
42+ : port $02 = %------1-

port $2F = %------01 :

clock cycles between IN|OUT and IN A,(C) :
104- : port $02 = %------0-
105+ : port $02 = %------1-
clock cycles between IN|OUT and IN A,($02) :
105- : port $02 = %------0-
106+ : port $02 = %------1-

port $2F = %------10 :

clock cycles between IN|OUT and IN A,(C) :
168- : port $02 = %------0-
169+ : port $02 = %------1-
clock cycles between IN|OUT and IN A,($02) :
169- : port $02 = %------0-
170+ : port $02 = %------1-

port $2F = %------11 :

clock cycles between IN|OUT and IN A,(C) :
232- : port $02 = %------0-
233+ : port $02 = %------1-
clock cycles between IN|OUT and IN A,($02) :
233- : port $02 = %------0-
234+ : port $02 = %------1-

notes :

IN|OUT : any read|write from|to port $10|$11
IN A,(C) : C register holding $02
test performed at CPU speed 1, from RAM, and with ports $2A & $2E holding system default values
It's interesting to see that though the opcode used to interact with port $10|$11 doesn't affect the delay, the one used to read port $02 does.



DISCOVERY : THE CRAZY BIT SYNDROM

We already know that port $2F affects the behaviour of port $02 bit 1.
Supposedly, only 2 events can alter the state of that bit :
1) Bit becomes 0 after interacting with a LCD port (delay counter reset).
2) Bit becomes 1 after the delay counter ended.
Well, apparently, the bit can change under other obscure circumstances :

CAUSE :

That occurs if not enough time was spent between A & B (in that order).
A : any write to port $20, or any read|write from|to port $10>$13
B : any write to port $2F

CONSEQUENCE :

After the write to port $2F, bit 1 of port $02 becomes unstable.
That means you cannot rely on it anymore as a LCD busy state checker.
That instability can take 2 different forms :

> The bit toggles by itself for an unknown duration, with no apparent reason.
It's similar to what you would expect from a bouncing behaviour.

> The bit becomes permanently reset.
That one will cause all codes that poll it to enter an endless loop.
That includes of course the famous lcd_busy routine, called by the OS before pretty much all interactions with the LCD.

HOW TO PREVENT :

The duration to wait between A & B can vary depending on several factors, and i'm afraid i don't have enough time to test that deep (anybody welcome).
From what i've experienced, it's way shorter than this, but since writes to port $2F aren't really supposed to occur that often, i recommend the following each time you write to it :

ld b,0
djnz $
out ($2F),a

3
ASM / [8X+] port $24 question
« on: July 31, 2019, 01:32:14 am »
Welcome.

I'm currently writing a tiny routine that makes all ROM space executable.
So, it will of course write to ports $22 & $23, but i'm not sure about how they both interact with port $24.
According to the wiki, bits 0 & 1 of port $24 are working as bits 8 of ports $22 & $23 respectively.
Fine.
So, i would expect that no matter how those 2 bits are configured, it would not change anything to the actual execution permission range defined by $22 & $23, since no 8X+ calculator has more than 256 rom pages.

But then, here comes that statement, that makes no sense if those bits are actually ignored :
"Since no 8 MB flash chip exists, this port in effect overrides port 23 and is overridden by port port 22."
How should i understand it ?
Like, let's say i have port $22 set to $80, and port $24-bit0 set to 1.
Does that mean that the ASIC will allow execution on all pages below $180, in other words all of them ? (instead of pages below $80 like i expected)
Even if that's true, i still don't understand why port $24 would "override" port $23 but not $22.
Am i the only one confused ?

Thanks in advance for your time.

4
ASM / [8X+] keyboard - passive monitoring
« on: July 18, 2019, 12:05:30 pm »
Hello there.

While testing a routine designed to check multiple key presses, i made an interesting discovery.
I didn't find anything about it anywhere, wikiti included, so the least i can do is to share it here.
Still can't believe i found that in 2019...

I decided to call the behaviour i'm about to describe "passive monitoring", as opposed to "active monitoring".

Active monitoring refers to the way most of you already know about, which is the regular sending to port $01, allowing you to specify which group(s) you want to monitor when reading the port afterwards.
Except for the need to use a variable delay between writings & readings, the port does what you expect it to do.
If you're new to that, you might want to check my old relic.

Passive monitoring is basically an alternate way to monitor groups, but you don't control it by writing to the port at all, instead, it is triggered by pressing specific keys.
Fortunately for you, i believe i understood how it works in its entirety.
I'm gonna first summarise how it works with just 1 sentence :
"When monitoring the group of a pressed key, you are also monitoring all other groups that have a key of the same bit pressed."
I know that sounds ugly, but i'm afraid that's the easiest way to describe it.
EDIT : Such "connections" aren't limited to 2 groups only, so with the proper pressed keys, you can actually monitor the entire keyboard, while actively monitoring only 1 group.

A visual representation might help to understand :

To be clear, in both scenarios, only group 4 was asked to be actively monitored, by sending %11101111 to the port beforehand.
In scenario A, group 4 is monitored and group 3 is ignored, as expected, so you would read %11111010 from the port.
But as soon as you press 1 (scenario B), group 3 gets instantly added to the list of monitored groups, so you would actually read %11110000 from the port, this time.
In short, having both 1 & 2 pressed together creates a bridge that "spreads" the monitoring from group 4 to group 3, because those 2 keys share the same key bit (1).

Fortunately, using bit checking|masking instead of the CP instruction helps us to filter potential trash keys in passively monitored groups.
However, there are some situations where such tricks simply don't work, depending on what you look for, see below.

A concrete example that shows how nasty passive monitoring can be :

Let's say you want to code a loop that waits until DOWN, LEFT, ENTER, and +, are all pressed together.
Despite the fact that those keys aren't in the same group, that's actually impossible, even by reading groups sequentially, thanks to passive monitoring.
But let's pretend that you can do it, to understand why you can't.
The most obvious algorithm would be something like :
1) Send group 0.
2) Read group 0, check DOWN & LEFT, repeat if not both pressed.
3) Send group 1.
4) Read group 1, check ENTER & +, go to 1) if not both pressed.
In this case, the problem isn't that the loop will never exit, but that it will once 3 of those keys are pressed, instead of all 4.
And there's absolutely nothing you can do to prevent it, it will behave like that no matter how you code it, and no matter in which order you press the keys.
For the sake of simplicity, let's say you press them in this order, to understand what happens :
DOWN : Nothing unusual. Reading group 0 would return %11111110, and reading group 1 would return %11111111.
DOWN+LEFT : Still nothing unusual. Reading group 0 would return %11111100, and reading group 1 would (still) return %11111111.
DOWN+LEFT+ENTER : The fun begins. No matter which group you asked the port to monitor, you will read both of them.
The unfortunate consequence is that when reaching step 4), you'll read %11111100, despite + was never pressed, but LEFT, which shares the same key bit, is.

Testing passive monitoring in known projects :

Pick any game, that allows you to move a unit diagonally using the arrow keys.
Now, press & hold DOWN,0,1.
If i'm right about all this, there is a decent chance that the unit will move south-west.

5
ASM / [8X+] universal snacks
« on: June 28, 2019, 09:38:06 am »
INTRODUCTION

This is a pack of routines and various files i've built over the years.
I can't say i haven't been inspired by others, so some stuff expands|fixes existing work.
Optimisation is mostly towards speed, and system code is used as rarely as possible.
Each file includes deep documentation, please read everything before using.
feedback & questions : https://www.omnimaga.org/asm-language/flash-snacks/



COMPATIBILITY

Except when specified, all TI-8X+ models (monochrome screen) are supported.
Same goes for official systems and boot codes.
Everything else should be considered unsupported.



CONTENT & OVERVIEW

keyboard.inc : keyboard include file
ti83plus.inc : ultimate TI-83+|TI-83+SE|TI-84+|TI-84+SE include file
font_large_custom.png : preview of what's in font_large_custom.txt
font_large_system.png : system large character font preview
1_character_tokens.txt : token>character reference table for all valid 1-character-long tokens
font_large_custom.txt : custom 6x8p character font matching ASCII|ISO-8859-1|CP-1252
font_large_system.txt : information about system large character font
READ.txt : this file
system_ram_structure.txt : system ram structure summary
arcpages.z80 : Identifies key pages in the archive.
battcheck.z80 : Checks batteries.
bootver.z80 : Identifies the boot code version.
cpirnc.z80 : Cpir, but additionally halts if a bank's edge is reached.
cpirz.z80 : Cpir, but instead halts if the specified byte isn't found.
cpirznc.z80 : Cpir, but instead halts if the specified byte isn't found, and additionally halts if a bank's edge is reached.
flashlock.z80 : Locks the flash chip.
flashmanuf.z80 : Identifies the flash chip manufacturer.
flashunlock.z80 : Unlocks the flash chip.
intdefault.z80 : Sets all hardware interrupts to their default system configuration.
intdisable.z80 : Disables and acknowledges all hardware interrupts.
keybcheck.z80 : Checks if at least one key is pressed, and if it's [ON].
keybdebounce.z80 : Waits long enough for released keys to stop bouncing.
keybscan.z80 : Scans the whole keyboard, [ON] key excepted.
lcdcfg.z80 : common LCD configuration
lcddisp768.z80 : Fills the screen using a custom byte.
lcddispbuf.z80 : Displays the content of a custom fullscreen buffer.
lcddispchr.z80 : Displays a 6x8p character, using a custom font.
lcddispstr.z80 : Displays a string of 6x8p characters, using a custom font.
lcddisptxt.z80 : Displays the content of a custom fullscreen text buffer, using a custom font.
lcdsavebuf.z80 : Stores the display to a custom fullscreen buffer in RAM.
poweroff.z80 : Turns off the calculator, and waits for an [ON] key press.
prgmedit.z80 : Exits, opens the program editor for the specified program, and sets the cursor to the specified location.
ramlock.z80 : Sets RAM execution permission to the system default configuration.
ramsize.z80 : Identifies the physical RAM size.
ramunlock.z80 : Makes all RAM executable.
romlock.z80 : Sets ROM execution permission to the system default configuration.
romsize.z80 : Identifies the physical ROM size.
romunlock.z80 : Makes all ROM executable.
romwrite1.z80 : Writes a byte to ROM.
romwritex.z80 : Ldir, but instead writes to ROM, and additionally halts if a bank's edge is reached.
secterase.z80 : Erases a sector.
sectstate.z80 : Checks a sector for protection against write|erase operations.
sysver.z80 : Identifies the system version.
usbinfo.z80 : Identifies if USB is available, and its revision type.



NOTE ABOUT OUTPUTS

pc, r, and registers equal to ? are to be considered destroyed.
Unlisted registers are unchanged, except when specified.

When the f register is detailed, each bit can be :
0 : zero
1 : one
X : variable-known (described in the "flags" section)
? : variable-unknown (destroyed)

6
ASM / 8X+ > finding last app page
« on: September 26, 2014, 01:55:19 am »
Welcome...

Alright, here is the thing :
I already coded a routine to find the last app page (start of the apps area).
But today, while i was reading some stuff on wikiti, i just saw that port 23 holds the last app page - 1 : http://wikiti.brandonw.net/index.php?title=83Plus:Ports:23
Of course, it would be quite a speed & size inprovement to just read that port, but i'm not sure how safe it is to rely on it.
I mean, if it was so easy, why would this page tell how to find it manually : http://wikiti.brandonw.net/index.php?title=83Plus:OS:Variable_Storage_in_the_User_Archive

Should i replace my routine by just a simple port read or should i be paranoid ?

7
TI Z80 / HYBRID (8X+)
« 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...

8
ASM / 8X+ > flash writing question
« on: June 27, 2014, 12:39:06 am »
Welcome...

Alright, i'm about to code a few routines that will write to archive space.
Of course, i'm gonna have to follow what is written on that page : http://wikiti.brandonw.net/index.php?title=83Plus:OS:Raw_Flash_Commands
Still, there is a part of the code that i don't understand :
Code: [Select]
ld a,b
xor (hl)
bit 7,a
jr z,programdone
bit 5,(hl)
jr z,programwaitloop
Why using XOR (HL) and checking bit 7 of A where a CP (HL) would be faster ?
Also, i really have no idea what is the point of checking bit 5 of (HL).

Any clarification greatly appreciated =]

9
ASM / clean asm program exiting
« on: May 20, 2014, 06:49:14 am »
Hello =]

It's been a while since i wanted to find a way to exit an asm program, the "clean" way.
By "clean", i mean by restoring all the previous home entries properly, and eventually the graph screen (in case the program was executed in horiz mode), without any unwanted effects.
In other words, you get what you would have after executing a basic program, no matter what you've been displaying.
The challenge was to make it without using any custom ram locations, as well as stack entries.
Also, the code is compatible with all 8X+ models (CSE excluded), and all OS (mathcrap included).
Of course, i guess that is mainly useful for standalone programs (nostub).
It is optimized in favor of size.

Here is the magic formula :

HEADER

Code: [Select]
.db t2bytetok,tasmcmp
    bit 5,(iy+$44)
    jr nz,backup_over
    ld a,(currow)
    ld (textshadcur),a
backup_over
Your code starts here...

TAIL

Code: [Select]
...Your code ends here.
    bit 5,(iy+$44)
    jr nz,restore_mp
    ld a,(flags+sgrflags)
    rra
    jr nc,restore_home
    bcall(_grbufcpy)
restore_home
    bcall(_rstrshadow)
    ret
restore_mp
    ld a,3
    out (5),a
    ld b,64
    ld hl,$DA7E
    bcall(_restoredisp)
    xor a
    out (5),a
    ret

NOTES

If you intend to use _clrscrn, _clrscrnfull, or any large character displaying rom call, just add "res apptextsave,(iy+appflags)" after the header, as well as "set apptextsave,(iy+appflags)" before the tail.
Basically, if textshadow or cmdshadow are altered, the home screen won't be what it was before the program execution.
Same goes for plotsscreen for the graph screen.

10
ASM / port 1 stuff
« on: May 15, 2014, 04:34:23 am »
At first, i was kinda curious to know why sending $FF would remove the necessity to wait for a delay between writing & reading.
I couldn't believe that sending that was processed somehow differently than sending anything else.
After many boring tests, here is what i discovered :

> About sending $FF :

Sending that to port 1 was called a "reset" by some.
It is true in the fact that it disables the scanning of all groups.
But, i can confirm that it doesn't have any additional effects.
I mean, sending $FF has the exact same effect as sending $7F (the unused group).
It just disables all groups, and is interpreted by port 1 like any other sending.

> About the (famous) needed delay :

Whenever you need to check specific keys (IN), you sometimes have to send one or more group map(s) first (OUT), to be sure that the key presses will be detected.
Sometimes, a delay is needed between OUT & IN, sometimes not.
First, you have to understand that the port always remember the last group map you have sent to him.
We'll call it the current group map.
If you really want to optimize your code, you'd better know what the current group map is, each time you intend to update it.
In other words, each time you use an OUT, it's better to know what you last sended to the port with the previous OUT.
When you update the current group map, here is how it works :

1) You write a 0 to a group bit.
Technically, it can be :
- sending a 0 over a 0 : It has no effect on the concerned group. > No delay is required before reading keys in that group.
- sending a 0 over a 1 : You actually ask the port to enable a group. Fortunately, it is done almost instantly. > No delay is required before reading keys in that group.
In other words, if you don't disable any group(s), you're free to use a IN right after a OUT without fear, even at 15Mhz.

2) You write a 1 to a group bit.
Technically, it can be :
- sending a 1 over a 1 : It has no effect on the concerned group. > No delay is required cause all the keys in that group should already be disabled.
- sending a 1 over a 0 : You actually ask the port to disable a group. > A variable delay is required before all the keys in that group are disabled.
Disabling a group actually means that you don't need to check keys in it anymore.
However, if some of those keys are pressed when you read the port, and are not disabled yet, they will return a zero bit if pressed, even if you think you are reading another (enabled) group.
So, basically, if you don't care if the keys in a disabled group are pressed or not, you don't need to wait.
But, if you want to be 100% sure that all the keys in that group have been disabled, continue reading.
When you disable a group, the keys in it are not disabled simultaneously.
Actually, some take more time than others.
Here is what i gathered :
- Disabling only one group :
Strangely, the more keys are being pressed during the disabling process, the faster it is.
The slowest scenario is when only one key is pressed.
The highest needed delays measured were 7 cycles at 6 Mhz, and 31 at 15 Mhz (Using 8 & 32 would be safe enough.).
- Disabling multiple groups :
The delay can go pretty high.
The slowest scenario is when you disable the entire keyboard (changing the group map from %00000000 to %11111111).
In that case, The delays measured were 46 cycles at 6 Mhz, and 125 at 15 Mhz (Using 48 & 128 would be safe enough.).
According to several tests, what makes that delay so high is that many keys of the same key bit are being pressed at the same time (The keyboard needs a huge time to disable those.).

> Note :

The way i made my tests, all delays refer to the needed cycles between a OUT (1),A line and a IN A,(1) line.
Those values were all obtained by checking pressed keys.
Due to how the keyboard works, the real time it needs to enable|disable unpressed key(s) remains unknown...

11
ASM / 8x+ > flash locking
« on: May 03, 2014, 09:28:15 pm »
I know how to unlock it, thx thepenguin77 btw =]
Now, i'd like to know a method to lock it back.
I already tried to zero port $14, without success.
I guess there's some kind of special sequence to achieve that (similar to unlocking it).
Help appreciated...

12
ASM / 8x+ > ram questions
« on: April 22, 2014, 11:53:14 am »
Hey there, it's me, again.
Several questions about ram usage :

1) Are pages $82 to $87 altered by a ram|mem clear ?
Before you ask, yes, i'm lazy to check it by myself XD

2) The following questions will refer to that page : http://wikiti.brandonw.net/index.php?title=83Plus:OS:Ram_Pages
In fact, i need to be 100% sure that non of the TI-OSes (including the later "heavy" ones) use pages $82>$87, even for temporary storage.
I'm specially interested in $4100>$433A on page $83 : which code uses that ? the TI-OS ?
If yes, i'm curious to know why would TI have chosen to use that page instead of $82.

Thx in advance for your time =]

13
ASM / 8X+ > questions about archive structure
« on: April 18, 2014, 08:36:45 am »
Hey there.
I have 2 questions, actually :

1) the swap sector
According to TI offcial documentation (pdf), it can only be either the first ($08>$0B) or the second ($0C>$0F).
According to wikiti, it can be any of the sectors.
I made some quick tests, and it seems that the OS uses only the first & second, but i'd like to be sure...

2) the sector status byte
We're assuming the sector i'm talking about doesn't include any app data at all.
From what i've tested, $FF specifies an empty sector, $F0 a sector used for variable data, $FE a sector used for swap.
What is $FC supposed to specify ? (according to wikiti, it can start with that byte).

Thx in advance =]

14
TI Z80 / edit8X+
« on: April 12, 2013, 07:21:56 am »
A new project on its way...

edit8X+ will mainly be a text viewer|editor.
The main idea is to be able to read text imported from a computer.
I know that doesn't sound very original, but i really wanted to code my own.
Also, i might use it later for a larger purpose.
A challenge will be to make the code OS-independant (avoiding system routines when possible).

*****

PLANNED FEATURES :

compatibility with as many models as possible
The default large font will be used but the characters order will match :
 ASCII printable characters (full compatibility)
 ISO-8859-1 printable characters (partial compatibility)
 CP-1252 printable characters (partial compatibility)
block selection , cut , copy , paste
undo
compatibility with the tab control character
compatibility with different versions of the enter control character :
 $0A
 $0D
 $0D,$0A
temporary system & extra ram usage during edition
view-only mode for archived files too large to be edited (if unsufficient free ram)
new , save as , save
backspace (maybe)
horizontal scrolling
...

*****

WHAT'S DONE FOR NOW :

The font :

242 printable characters
153 of them are compatible with notepad (instead of 92 in the original system font).
The other 89 are specific to the calculator (I needed them for another project).

11 undefined characters (dedicated sprite)

The 3 remaining slots are used for control chars (tab & enter).

*****

Any suggestions are welcome =]

15
ASM / 8X+(se) testers needed...
« on: April 11, 2013, 11:50:32 am »
Hey there =]

If you don't already know, a delay is needed between writing and reading to the keyboard (using port 1).
The problem is, that the needed time is not accurately known.
Since there seems to be many different opinions about the subject, i decided to code a program to test that up.
The main purpose is to be able to have a better knowledge of the hardware, allowing more optimised low level operations.
Also, maybe we'll have some surprises (ti likes to change hardware pieces).

COMPATIBILITY

TI-83 Plus
TI-83 Plus.fr
TI-83 Plus Silver Edition
TI-84 Plus
TI-84 Pocket.fr
TI-84 Plus Silver Edition
TI-84 Plus Pocket Silver Edition
TI-84 Plus C Silver Edition

All official OS are compatible, as long as you TURN OFF MATHPRINT.

INSTRUCTIONS

Simply execute from the homescreen and follow instructions.
Important : When pressing the 0 key, you must HOLD it until the end of the test.

DOWNLOAD

black & white models : http://www.omnimaga.org/index.php?action=dlattach;topic=16102.0;attach=15043
TI-84 Plus C Silver Edition : http://www.omnimaga.org/index.php?action=dlattach;topic=16102.0;attach=15044

RESULTS

The displayed value(s) are the needed delays (in cycles) for each CPU speed mode (order : 0,1,2,3).
A question mark specifies an unknown delay.
Please don't forget to specify the model and serial number end (at the back of your calc, in the form X-XXXXX).

Code: [Select]
OWNER MODEL SERIAL DELAY-0 DELAY-1 DELAY-2 DELAY-3

the_mad_joob 83+ I-0299A 6
bhtooefr 83+ S-0504E 0
chickendude 83+ N-0305H 5

fortytwo 83+SE I-0501 4 23 30 37 overclocked

Darl181 84+ S-0305B 6 29 29 29
Streetwalker 84+ S-0107G 4 21 21 21

the_mad_joob 84+SE S-0404 6 29 29 29
DrDnar 84+SE S-0605D 4 19 19 19
fortytwo 84+SE P-0410O 4 17 17 17
willwac 84+SE P-0410O 4 20 20 20
chickendude 84+SE ? 4 18 18 18

DrDnar 84+CSE ? 22 72 72 72

THANKS IN ADVANCE FOR YOUR PARTICIPATION =]

Pages: [1] 2