This comes after i discovered that the source for calcsys 1.4 is actually public since 2017, and was provided by its original developer, Dan Englender (cheers if you're reading this BTW). Since the update was obviously abandoned, i tested it and made it stable. You'll find the updated source in the attached file. To generate the application, follow the instructions in READ.TXT (windows OS required). I originally tried to contact both Dan and Detached Solutions, but the email boxes are either full, or don't exist anymore. I believe everything follows what's in the license.txt file anyway.
DOCUMENTED CHANGES :
> Flag byte 20 now displays correctly. > Displays correct size information for archived variables. > Hex Editor now views RAM pages on 84P correctly.
UNDOCUMENTED CHANGES (that i discovered, but there might be more) :
> "VAT" section : The data location for archived variables now points to the actual data, rather than the whole archive entry. > "About" section : There is now a 1 pixel space between characters.
UNOFFICIAL CHANGES (that i performed) :
> Fixed the bug that was causing many strings to not be displayed in multiple contexts. > Fixed the bug that was causing a trash character to often be displayed under the cursor during hex inputs. > "About" section : All strings are now entirely displayed. > "About" section : The release date was updated (github source date used as reference). > Missing 1.4 information was added to the documentation, including undocumented and unofficial changes. > The source is now easier to assemble.
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 :
.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 retThat 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 :
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 :
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 ?
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.
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.
COMPATIBILITY
Except if specified, all TI-8X+ models (monochrome screen) are supported. Same goes for official systems and boot codes. Everything else should be considered unsupported.
DISCLAIMER
For each routine, you are expected to follow EVERYTHING that's in the "IN" section. Also, when there's a "WARNING" section, it's to be taken seriously. If something is unclear, feel free to ask there BEFORE using : https://www.omnimaga.org/asm-language/flash-snacks/
NOTE ABOUT "OUT" SECTIONS
? means a register is to be considered destroyed.
Unlisted registers are unchanged, except for : pc,r : always destroyed af',bc',de',hl' : unchanged if interrupts disabled beforehand | destroyed otherwise
When the f register is detailed, each bit can be : 0 : zero 1 : one X : variable-known (see "flags") ? : variable-unknown (destroyed)
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.z80 font_large_system.png : system 6x8p character font preview (2.53+)
1_character_tokens.txt : token>character reference table for all valid 1-character-long tokens READ.txt : this file system_ram_structure.txt : system ram structure summary
arcpages.z80 : Identifies the reference pages of the archive. battcheck.z80 : Checks batteries. bootver.z80 : Identifies the boot code version. cpirnc.z80 : Similar to cpir, but additionally halts if a bank edge is reached. cpirz.z80 : Similar to cpir, but instead halts if the specified byte isn't found. cpirznc.z80 : Similar to cpir, but instead halts if the specified byte isn't found, and additionally halts if a bank edge is reached. flashlock.z80 : Locks the flash chip. flashmanuf.z80 : Identifies the flash chip manufacturer. flashunlock.z80 : Unlocks the flash chip. font_large_custom.z80 : Custom 6x8p character font matching ASCII|ISO-8859-1|CP-1252. guiselect.z80 : Provides interaction with a simple 6x8p-text-based option selection GUI, using a custom cursor. intdefault.z80 : Sets all hardware interrupts to the 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. 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 6x8p character font. lcdfill.z80 : Fills the screen with the same byte, mostly used to clear all pixels. lcdmode.z80 : LCD mode configuration. 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. r16strdec.z80 : Converts a 16-bit value to a decimal character string, and writes it to RAM. r8strbin.z80 : Converts an 8-bit value to a binary character string, and writes it to RAM. r8strdec.z80 : Converts an 8-bit value to a decimal character string, and writes it to RAM. r8strhex.z80 : Converts an 8-bit value to a hexadecimal character string, and writes it to RAM. 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 : Similar to ldir, but instead writes to ROM, and additionally halts if a bank edge is reached. secterase.z80 : Erases a sector. sectstate.z80 : Checks a sector for protection against write|erase operations. strdelz.z80 : Replaces the potential leading zeros of the specified character string in RAM by spaces. sysver.z80 : Identifies the system version. usbinfo.z80 : Identifies if USB is available, and its revision type.
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.
ld a,b xor (hl) bit 7,a jr z,programdone bit 5,(hl) jr z,programwaitloopWhy 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).
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.
...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.
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...
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...
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
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.
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).
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).
Show Posts
