Yo Streety =]
Something between an OS and a shell...

Thx a lot for all that in-depth infos DrD =]
Just a question, what you mean by "the code is no longer relocatable" ?

Also, i have another question now.
I was thinking of optimizing the 4 bus cycles part, using registers as much as possible.
As a result, the commands may be sent faster, maybe too fast.
Is a delay needed between the unlocks, write command, and data sending ?

I think the "trick" here is that bit 7 will always be the opposite of the byte you're trying to write (here in b), so if bit 7 of b is 1, bit 7 of (hl) will be 0 (so XORing the two will always give you 1). If it's finished, then you'll get the same bit that's in b, so XORing them will give you 0 (so z will be set). I don't really know how all of it works, that's just what i got from calc84's message.

EDIT: And (hl) doesn't really return the value of (hl) but rather a status byte, so i think you could read from anywhere in flash (like "ld a,($4000) \ xor b") and it would return the same thing until the thing finishes. Also, if you just cp (hl) there's a chance that the status byte has the same value as the byte you're trying to write.

That is how i understood it, too.
2 cases :
1) writing complete, reading will return the effective byte at the address, therefore all bits will match between the write & the read.
2) writing incomplete, reading will return a status byte which bit 7 is the opposite of bit 7 of the byte you asked to write (ugly sentence, i know ).
The thing is, that if bit 7 of the status byte is "guaranteed" to be the opposite, then i don't see how there is a chance to have a match when comparing the 2 bytes.
I mean, comparing byte %1XXXXXXX and byte %0XXXXXXX can never set the zero flag, so why wasting some cycles with that slow BIT instruction ?

Sorry again to bother you with that guyz, but that's important, cause such code can be iterated a lot when writing to flash and highly deserves to be speed-optimized.

No, haven't tried yet any attempt to write.
You know, that's the kind of thing you want to understand before trying on real hardware =P
I don't really believe it, but i could potentially imagine that the flash chip behaves differently when he hasn't totally finished accepting a write attempt (depending on the used op code).

Quote from: Streetwalrus on May 20, 2014, 02:00:15 am

Wow. Your research is making this hardware sound more and more obscure. What the hell TI ?

This behavior is most likely due to capacitance in the keyboard traces. When you select a group for reading, charge almost instantly rushes onto the group traces on the PCB, so you can read instantly. But when you unselect a group, TI makes no effort to discharge the traces. (They're also too cheap to add a 1-cent diode to each key so that we could detect multiple key presses without ghosting.) The pins that control the group traces simply go into a high-impedance state, meaning change can't flow back into them. As a result, electric charge stays on the traces until internal resistance dissipates it. When you read from the keyboard right after disabling a group, the charge that was previously on the keyboard traces is still there, giving you the false signal. The capacitance effect is small and the charge dissipates in just a few microseconds, but the Z80 is running fast enough that we can see those microseconds.

Excellent, some hardware explanations =]
Makes me remember how far my knowledge of electronic suck

I still need at least a few testers (prgm available @ my previous post).
 

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

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

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

Did some new tests.
I can say i was a bit surprised by the results.

Examples of some delays my program returns.
The values are the needed delay to disable those keys while being pressed, at 15 Mhz :

DOWN : 21
LEFT : 21
RIGHT : 22
UP : 20
DOWN+LEFT : 15
DOWN+LEFT+RIGHT : 13
DOWN+LEFT+RIGHT+UP : 12
As you can see, it appears that the more keys are being pressed in the same group, the faster it takes to disable them.

And now, some results in different groups :
LEFT+-+9+(+SIN+MATH+DEL : 24
LEFT+++3+2+1+STO+TRACE : 123
It took me a while to figure out why such a huge difference.
In the first case, all keys correspond to different key bits, and in the second, to the same.