Is is possible for INPUT to have a default value?

[alowe]

I have a program in which formulae are stored in a table that are edited using the INPUT statement.
I had successfully implemented my own input management to support ZX81 math functions, but it just got too slow.
So I have gone back to using the INPUT statement which is much simpler and quicker.

When typing with INPUT the text must be stored somewhere, even if just in the D_FILE.
Wouldn't it be possible to poke that text in place and then call INPUT in such a way that it bypasses clearing it?
The INPUT statement must have a location in memory so would it be possible to jump execution to that location while not clearing the text?

At the moment, if I use INPUT to edit a formula then the previous formula is lost. It would be nice to set the default value to the previous formula so that editing can resume rather than have to type out the whole formula again.

I'm sure it can be done.

[1024MAK]

As far as I remember, the INPUT text is stored in BASICs temporary workspace. As this is used for other things and is dynamic, I don’t think you can store text here before calling INPUT. At least, not from BASIC.

My workaround would be to hold the existing data in one variable. Then use INPUT with another variable. After the INPUT line, test the results. If they are null, use the existing value that was stored earlier.

Mark

[Paul]

Are you input numeric or string?
Both ways it's possible to use a variable as input.
For Example input a$ gives "" work cursor between the double quotes.
Delete the double Quotes and enter A$, the A$ is used for input a$ and it's not lost

[alowe]

As far as I remember, the INPUT text is stored in BASICs temporary workspace. As this is used for other things and is dynamic, I don’t think you can store text here before calling INPUT. At least, not from BASIC.

My workaround would be to hold the existing data in one variable. Then use INPUT with another variable. After the INPUT line, test the results. If they are null, use the existing value that was stored earlier.

Mark

Then I guess it'd have to be written in assembly: figure out where the dynamic location is, edit it and then call INPUT in such a way that it doesn't clear that location first.

I could test the new variable before setting it, but this wouldn't allow me to edit the existing variable using INPUT. For example, imagine you noticed a typo in your email so had to type the whole email again. INPUT is great because it's fast, but it undermines the usefulness of my program.

[alowe]

Are you input numeric or string?
Both ways it's possible to use a variable as input.
For Example input a$ gives "" work cursor between the double quotes.
Delete the double Quotes and enter A$, the A$ is used for input a$ and it's not lost

It's a string that is then parsed and evaluated as either a complex statement using ZX81 and custom functions, text or a number, depending on what it is. E.g. I can have an array of formulae and within that array, one of the formula might be the sum of all the other formula in that array, or the average, etc. That way an array can do a lot of interesting things. Later on I'll add sorting, graph making and printing. It already works really well and fast (only about a second to evaluate a mixture of custom and ZX81 functions that act on the whole array itself).

Deleting the quotes and entering A$, for example, wouldn't allow me to edit the existing formula.

e.g. if I have a formula that is "SUM(1,20)+PI**2+AVG(1,20)" then first pass replaces each custom function and arguments with the result, so you might end up with: "0.3244567+PI**2+0.7662445" and then I just pass that to VAL and it does the rest, like magic.

[dr beep]

At the input enter A

You can enter variables as value, so also its own value

[SafePit]

Or you can build your input routine using INKEY$.

[SafePit]

Or you can build your input routine using INKEY$.

Ignore, saw you tried that already. I built my own routine and it had pretty decent speed, but I hadn't implemented all the math symbols.

Is an interesting challenge. I'll be curious how you hack the ROM code to get this to work as you expect.

[alowe]

Or you can build your input routine using INKEY$.

Yes, I already did this but it was so slow even after optimising it as far as possible. I managed to write a really elegant solution but the problem was that printing the output after each keypress took 90% of the execution time. It made the program unusable so I tried it with INPUT instead and that fixed the problem. I suppose I could figure it out all again (deleted all the notes, duh). It took about a week to perfect it as I work 16 hours a day and barely get the time. Maybe poking the D_FILE directly would speed things up.

Just spent 6 hours and 30 minutes retyping the program today after discovering that the printer had somehow become disconnected . On EightyOne when you connect the printer it wipes your program. Added a couple more changes and ran out of memory with 48k. So now have to retype the whole program again after enabling RAM in 8k-16k and figuring out how to use that again.

[alowe]

3EEDDE32-20D6-42D9-B9EA-CE072553E466.png

At the input enter A

You can enter variables as value, so also its own value

I wish it was that easy.

E.g.

Code: Select all

1 LET A$="SUM(A1,A20)"
2 INPUT A$
3 PRINT A$

upon running the input displays "", not the value of A$, so it cannot be edited, only inputted afresh. INPUT was such a quick solution but without teaching myself assembly and the secrets of ZX81 which probably no one alive knows, it might just be easier just to re-write my own routine again with INKEY$ and poke output directly to the D_FILE in order to speed things up.

But on the bright side if I use my own routine for input it doesn't have to be at the bottom of the screen and can be displayed further up, relinquishing an extra 2 lines of printable screen for an even larger array.