Input Strings in Graphics mode 2

[Grevle]

The input command for inputing strings seems to only work in mode 0 when using Basic , So in my program i would like to input strings in Graphics mode 2+16 , But the input command just bumps the mode back to mode 0.

 

 

Is there a fairly easy way to input strings via keyboard in graphics mode 2+16 when using basic ?, Im sure i could figure out some sort of routine but i dont have mutch time to spend on that now.

 

Thanks.

[Rybags]

The Basic INPUT statement assumes IOCB #0 is opened which won't be the case in fullscreen graphics.

 

The INPUT #<iocb> form allows input from any device supporting it but in graphics and text modes that all generally use S: the Get Characters works differently in that data is simply read from where the graphics cursor is positioned so won't give you what you want. Also I believe an EOL (Return) is expected which in graphics mode won't occur. Not sure what would happen, I expect probably a truncated record or cursor out of range error would occur.

 

You could probably do a workaround - use CLOSE/OPEN #6 to open the graphics mode rather than the GRAPHICS statement, IOCB #0 should remain open (I think)

 

Then use POSITION and POKE 87,0 to make the OS think you're in Graphics 0 text mode. You won't get a block cursor though, although in some text modes the text colour should change if the cursor hovers over a character. POKE 87 back with the active graphics mode once input is finished.

 

Alternate to that is to just use the K: device - advantage there is you can regulate what characters are allowed and how much data can be entered although you've got to keep track of things and also echo to the screen what input is occurring.

Edited February 24, 2013 by Rybags

[phaeron]

Having reimplemented S: and E: from scratch, I can relate some (nasty) details about how the two work together....

 

IOCB #0 is still open when a full-screen GRAPHICS statement is executed -- it's just that any time E: is used, the screen editor will force a re-open to gr.0 if there is no text window. For the most part, the only part of the OS that cares about whether the S: or E: device is "open" is CIO, which tracks the IOCB state, i.e. whether #0 or #6 is open. The display itself is always open, even auto-reopening to gr.0 if there is an open failure, and closing S: or E: generally does nothing. The one special exception is if you have fine scrolling enabled, in which case closing the display will cause a reset to a non-scrolled gr.0.

 

Besides E: forcing gr.0 if it isn't active, there are a ton of places in the main display code where text window features are only magically enabled if the current mode is gr.0. This includes left/right margins and logical line handling. Changing DINDEX to 0 as Rybags suggests (POKE 87,0) will enable this, but the problem is that it also enables gr.0 addressing, which means 24 rows of 40 character wide lines. Since gr.2 uses 20 character wide lines, this will give double spacing. There is no way to get the display handler to use different line widths for screen editor functionality as various multiples of 40 are hardcoded throughout. You could fake it out by moving in the right margin and a custom display list to run gr.2 with a 40 character pitch, but at that point it's easier just to write a custom line input routine on top of K: and S:.

 

The division of functionality between E: (#0) and S: (#6) is pretty different than what you would expect from the descriptions of the screen editor and display handler. On the input (get byte) side, it's pretty clean -- E: reads keys through K:, echos chars through S:, and then reads the line from the screen through S:. The S: get byte routine is almost identical between text and graphics mode except that in gr.0 it wraps the cursor within the margins. On the output (put byte) side, it's a mess. All control characters except for CLEAR and EOL are handled in E: while S: handles the raw output, but in gr.0 S: also does scrolling and logical line handling. Cursor handling is ugly as S: almost handles the cursor by itself except that it tends to dribble them behind on EOLs.

[Grevle]

Wow, thanks for the detailed explanation.

 

Well i think i will have to create a routine that simply put one character on screen when a keyboard are pressed and then move it one position right,then use the keycodes and transform the into the proper screen codes for that key and then do some string work so it will become a string, so i can,t escape using some time on this...

 

or i could try have text window in my mode 2.

 

But luckily when the routine is done, i dont need to learn it in the future because i will keep the routine

Edited February 24, 2013 by Grevle

[Rybags]

I should have suggested another easy alternative - the display handler allows addressing the full 192 pixels of a graphics/other text portion even when the text window is active.

 

You could open the graphics mode with the text window enabled, then alter the display list to suit your needs. Then either point the text window as seen by the OS to the input area you want or point that portion of your display window to the text window in the DList.\

 

Locations dec. 660-661 (TXTMSC) point to where the 4 line text window resides. But if you decide to clear the text window the results will probably be that it clears the entire portion until the end of display if you change that pointer to coincide with part of the main screen window.

 

Ultimate choice is up to you - personally I'd probably go with the K: option. That way you can filter unwanted keys out as well as control what actions are allowed, e.g. don't just allow the user to delete large portions of the display.

Not having a proper cursor can be a pain but there's ways around it, e.g. just use the underline character for where keystrokes will appear, use a missile or have a custom charset with a solid block character.

[Grevle]

I found this routine on the net that does what i want, I have alreday modified the code into a new code with string capabilities that does exactly what i want, to input strings

while typing in mode 2+16 .

 

I also probably will add a player as a cursor.

The listing below is the unmodified one that i found on the net.

 

 

Thanks for your help guys

 

 

1 REM : I=INPUT, L=LINE, R=ROW, T=TIME

10 OPEN #1,4,0,"K:"

15 GRAPHICS 2+16:L=0

20 POKE 16,112

25 FOR R=0 TO 20:IF R=20 THEN R=0:L=L+1

30 POSITION R,L

35 GET #1,I

40 IF I=155 AND L=11 THEN GOTO 15

41 IF I=155 THEN R=-1:L=L+1

42 IF R=18 AND L=11 THEN GOTO 15

45 PRINT #6;CHR$(I)

50 SOUND 0,2*I,10,8:SOUND 1,2.5*I,8,10:FOR T=1 TO 75:NEXT T

51 SOUND 0,0,0,0:SOUND 1,0,0,0

55 NEXT R

Edited February 24, 2013 by Grevle

[Synthpopalooza]

Another way is to directly alter the display list, like this:

 

10 GRAPHICS 0

20 DL=PEEK(560)+256*PEEK(561)

30 POKE DL+3,7+64

40 FOR I=6 TO 17

50 POKE DL+I,7

60 NEXT I

70 POKE DL+18,65

80 POKE DL+19,PEEK(560):POKE DL+20,PEEK(561)

 

Now you can directly print to the screen like in Graphics 0 and use INPUT as well