The Sinclair QL Forum

I think I have asked this before but cannot find the thread.

In SuperBASIC, can you code it so that some text/command is in #0 as if it has been typed in in #0, and if that is possible, can the Return/Enter command be done the same way?

I think you are looking for something like the Turbo Toolkit command - COMMAND_LINE (?)

There is also a TYPE_IN procedure - I think that is from DIY Toolkit...

Both COMMAND_LINE and TYPE_IN are from Turbo Toolkit.

- COMMAND_LINE picks SuperBASIC #0 into the foreground to receive input (Much like HOT_PICK)
- TYPE_IN x$ behaves as if x$ would have been typed from the keyboard into the current keyboard queue

If you want TYPE_IN to also add a LF at the end, just add it to x$ like
TYPE_IN x$&CHR$(10)

Tobias

tofro wrote:Both COMMAND_LINE and TYPE_IN are from Turbo Toolkit.

- COMMAND_LINE picks SuperBASIC #0 into the foreground to receive input (Much like HOT_PICK)
- TYPE_IN x$ behaves as if x$ would have been typed from the keyboard into the current keyboard queue

If you want TYPE_IN to also add a LF at the end, just add it to x$ like
TYPE_IN x$&CHR$(10)

Tobias

Thank you for the clarification - I wonder what the command is in DIY Toolkit.....

Thanks guys, I now have a couple of very small routines that help greatly in editing and programming SuperBASIC.

Moving on from the original question I now have another. (VP its a shame there isn't a Coding only section on the forum )

Anyhoo, I have TK2 and Turbo Toolkit installed as standard on the BBQL

I wish to save an area of the screen, print draw something to it and then restore the original screen back. Now I think know I can do this for the whole screen but that uses 32K of memory. Also I might adapt this to maybe do successive or recursive 'windows', 32K a pop is rather extravagant. More like a notification message I suppose.

I know there are other extensions out there, but I dont want to add any further ones to those i already have. Is this possible?

In pseudo code is would think it would be something like:
or

Hi,

If you are using Minerva, you can use the extended MODE command to switch between the First and Second screen.

You could write on Screen 1 then change to Second 2 or vice versa.

The syntax for the extended MODE command is in the Manual, it has been nearly 15 years since I thought of this.

I did write some extensions to use the second screen, but I can not find them at present.

Derek

Mr_Navigator wrote:I know there are other extensions out there, but I dont want to add any further ones to those i already have. Is this possible?

Lee,
if you have Turbo TK already, have a look at MOVE_MEMORY and the examples in the manual and on file - It describes some cases for saving parts of the screen..

You could assume the screen to start at $20000, but probably shouldn't if you want to be compatible with higher res screens and/or Minerva. You could also assume the length of one scan line to be 128 bytes (and probably shouldn't, for the same reason). But finding out would need something like display_cde - That's not part of Turbo TK.

Regards,
Tobias

tofro wrote:

Mr_Navigator wrote:I know there are other extensions out there, but I dont want to add any further ones to those i already have. Is this possible?

Lee,
if you have Turbo TK already, have a look at MOVE_MEMORY and the examples in the manual and on file - It describes some cases for saving parts of the screen..

You could assume the screen to start at $20000, but probably shouldn't if you want to be compatible with higher res screens and/or Minerva. You could also assume the length of one scan line to be 128 bytes (and probably shouldn't, for the same reason). But finding out would need something like display_cde - That's not part of Turbo TK.

Regards,
Tobias

Moderately tricky one this, if wishing to avoid use of external extensions.

Firstly, screen address. A degree of assumption can be made for QDOS, and then use SBASIC extensions SCR_BASE and SCR_LLEN for SMSQ/E perhaps. Something like:

screen_address = 131072:line_length=128 : REMark QDOS defaults
IF VER$ = 'HBA' THEN screen_address=SCR_BASE:line_length=SCR_LLEN

There are a couple of IF...BUTS... here, though:

1. Does not cater for Minerva second screen, or for uQLx's selection of extended screen sizes.
2. I am not sure it would compile on Turbo (not saying it wouldn't, I just don't know), I know older versions of Turbo might choke when the compiled job is run on a system not having compiled extensions installed.

Next, we come to the issue of the number of bytes per pixel. It is 2 bytes per group of 8 pixels in mode 4, one byte per pixel in mode 16 (Aurora/QPC2 256 colour mode) and two bytes per pixel in modes 32 and 33 (QPC2, QXL, Q40, Q60). This would need DISP_xxx extensions to return the mode and allow you to work out where along the lines the area starts. It's actually easier in high colour modes because mode 4 means you'd have to make sure you work in multiples of 8 pixels which are all word aligned. It can get very fiddly.

Certainly, Display_Cde (which can be linked to Turbo or QLib programs and supplied with other software free or commercial) can give you the information to build your own routines based on the above information. There is a demo routine with it which stores the whole screen, but not partial windows, maybe that's make an interesting little extra demo if I get time to write one if ever I get on top of current projects!

Personally, I use Easyptr 4 and QLiberator for this kind of thing, where commands like WSAIN, WSARS etc allow you to save and restore window areas with ease. Haven't used the TurboPTR package enough to know if there's and equivalent in there for use with Turbo, although George did do some work on Turbo a year or two ago to try to ensure it could compile Easyptr stuff.

There's also software on Quanta library disk GR01 called VIRTUAL_SCREENS by Ron Dwight which may be useful. And on GR02 there's WINDOWS. I have no idea if either of these works on extended screens. Just browse the library guide searching for WINDOWS to find them.

Something along the lines of this would probably work, I guess (untested, will also only work for screen areas that are byte-aligned )
ScrPut would work simply the other way round

Note the width and height of the save area needs to be saved as well in order to get the screen area right when restoring an image.

Tobias