CIO S: Screen editor usage from Assembler - extra cursor characters problem

[E474]

Hi,

 

   I wanted to try out using the S: CIO screen editor in Assembler, but I'm not sure I am going about it in the right way. When I do an OPEN, PRINT "Hello World", CLOSE, I get the attached screen, but it has 2 cursors in column 0, and a cursor after the "Hello World". The code is quite simple, and uses the OPEN, PRINT and CLOSE macros from Mac65.

 

									
	*= $5000
	
	JMP PROGRAM_INIT
;
; MAC65 Macro files. Mainly used for I/O Macros
;

	.INCLUDE "SYSEQU.M65"
	.INCLUDE "IOMAC.LIB"
	.INCLUDE "OS.asm"
	
	
PROGRAM_INIT


	LDA #<END_OF_PROGRAM_MEMORY
	STA APPMHI
	LDA #>END_OF_PROGRAM_MEMORY
	STA APPMHI+1
	 
	LDA #1
	STA CRSINH
	
	LDA #0	
	STA LMARGN
	
	OPEN 1,12,0,"S:"
	
;	PRINT 1," "
	
	LDA #20
	STA COLCRS
	
	LDA #0
	STA COLCRS+1
	STA ROWCRS
	
	
	PRINT 1,"Hello World  "

	CLOSE 1

LOOP1
	JMP LOOP1

	RTS	
	
END_OF_PROGRAM_MEMORY	


	*=$2E0

	.WORD PROGRAM_INIT
	

I've also attached the ATR containing the executable (T1SET.EXE).

 

Is there any way of getting rid of the extra cursor characters (actually all 3 of them)? I thought they would not be present as I set CRSINH to 1 right at the start of the program. At the moment I am working from Chapter 8 of the Atari System Reference manual by Bob Duhamel - if anyone can point me to any other info on using the S: device from Assembler, that would also be appreciated. 

 

The reason I'm looking at this is that I saw this post: 

 and started to wonder about using the S: driver, which I haven't used before (I'm planning on converting the screen I/O in ATR Maker Deluxe - and other programs - to use the S: device, but I want to write some test programs first to make sure it works OK).

 

Also, I'm not sure if I am setting APPMHI correctly, this is required according to the Reference Manual, but not something I can recall using before.

 

Any help would be appreciated!

t1set.atr

[Rybags]

With CSRINH set you shouldn't be getting this problem.

Maybe check your object code in memory (emulator monitor) and make sure it's setting the right address.

[phaeron]

CRSINH is reset by S: open. You need to set it after the open command.

 

You don't have to set APPMHI. It's only necessary if you want the display code to detect when it doesn't have enough memory and fail the OPEN if so, falling back to reopening the GR.0 screen. It's most useful for programs like BASIC that run in a lot of different memory configurations and need to be able to handle that error gracefully. Not really needed if either you have a guaranteed memory layout or failing to open the screen is fatal anyway.

 

[E474]

Hi,

 

   Thanks very much, when I set CRSINH to 1 after the OPEN, it's down to 1 extra cursor (first screen grab, below).

 

   When I uncommented the PRINT macro, it gets rid of the cursor entirely, as shown in the second screen grab, below.

 

Amended code is:

 

;	LDA #1
;	STA CRSINH
	
	OPEN 1,12,0,"S:"
	
	LDA #1
	STA CRSINH

	LDA #0
	STA COLCRS
	STA COLCRS+1
	STA ROWCRS

	
	PRINT 1," "
	

 

I'm guessing it's better to set COLCRS and ROWCRS explicitly, rather than relying on them being zero. 

 

Also, thanks for the info on APPMHI, I think I will add some error handling code for the CIO OPEN code, just in case anyone with a 16K Atari wants to run my utilities (I guess I can test for error situations by adjusting the size of memory in an emulator, and then just setting END_OF_PROGRAM_MEMORY to higher and higher values until I get into an error state). I have read that a 16K machine can run with DOS (not sure which DOS though), though there is not a lot of memory left for programming (in Assembler), though if I start the code at $2000, there should be 8K free, though just over 1K will be used for the screen display, and I am not sure if there is more memory allocated for a screen buffer too.

 

Forgot to add that changing the origin from $5000 to $2000 works fine.

 

Edited August 27, 2019 by E474

[vitoco]

"S:" device is an output only device, so the OPEN statement should be:

 

  OPEN 1,8,0,"S:"

 

Of course, the opening mode is ignored, even a zero will work!!! And trying to read from "S:" device in any I/O mode will trigger an error.

 

Also, the default behavior of that driver is to left a cursor every time a EOL (char 155=$9B) is printed or a POSITION is performed.

 

 

[xxl]

57 minutes ago, vitoco said:

"S:" device is an output only device, so the OPEN statement should be:

you can PUT pixel to screen

you can GET pixel from screen

so...

[vitoco]

11 minutes ago, xxl said:

you can PUT pixel to screen

you can GET pixel from screen

so...

so you must use "E:" device ?

[xxl]

E(ditor): to GET pixel?

 

[E474]

Hi,

 

  I read in the Atari Reference Manual that S: is a read/write device - you can write to the screen, or read data from the screen. Also, E: is read/write, but you are reading from the keyboard, or writing to the screen. In some of the utilities I have written, I have been opening E: to write data to the screen, and opening K: as a separate channel to get keys from the keyboard. This has been with linear type utilities where I can just give a line by line progress report as the utility runs. It's pretty much the simplest way to program.

 

Possibly I could just use E: to read keys and write text to the screen, but I want to position the cursor to output rows/fields, so I'm probably better off reading from K: and writing to S:

 

   All this is going from the Atari Reference Manual, so there are probably a few more things to sort out before the code is finished.

 

The bit from the Atari Reference Manual for opening the S: device is:

 

OPENING A CHANNEL TO THE SCREEN HANDLER
When a channel is opened to the screen handler the following actions take place: 
The area of memory to be used for the screen data is cleared. 
A display list (program for the ANTIC chip) is set up for the proper graphics mode. 
The top−of−free−memory pointer, MEMTOP [$02E5,2 (741)], is set to point to the last free 
byte before the display list. 
Before opening a channel to the screen handler, the pointer to the highest memory address 
needed by the program, APPMHI [$000E,2 (14)], should be properly set. This will prevent the 
screen handler from erasing part of the program when it sets−up the screen data region. 
When the channel is opened, two special options can be sent with the direction parameter 
(ICAX1). 
 ICAX1 for screen open
 7 6 5 4 3 2 1 0
 −−−−−−−−−−−−−−−−−
 | C S W R |
 −−−−−−−−−−−−−−−−−
 1 6 3 1 8 4 2 1
 2 4 2 6
 8
 C 1 = don’t clear the screen
 S 1 = split screen
 R 1 = input
 W 1 = output
Before the open command, the graphics mode number is placed into ICAX2. 
 ICAX2 for screen open
 7 6 5 4 3 2 1 0
 −−−−−−−−−−−−−−−−−
 | : mode |
 −−−−−−−−−−−−−−−−−
 mode = $00 through $0B (0 − 11 (0 − 15 on XL/XE))
To open a channel to the screen in BASIC use the GRAPHICS command.

 

Not sure how well this will come out when posting from my phone though.

[vitoco]

Thanks for the clarification. Then, I'll have to check why I was getting an error trying to read from screen (not using #6).

[xxl]

11 minutes ago, vitoco said:

I'll have to check why I was getting an error trying to read from screen (not using #6).

#6 = Screen S:

not #6 ... not S: (in simplification)

[Rybags]

The IOCB number isn't really important (though by default #0 gets opened by the OS to E: )

#6 for S: is a Basic thing, in a bare environment it's free to use for any other purpose (same with #7 )

Even #0 you could close then reopen to some other device type.

[xxl]

of course, but instructions like Plot/locate won't work in Basic, and I think that's how he checked.

[thorfdbg]

One of the problems is that in the original Atari Os implementation, S: and E: are not very well isolated. Essentially, if you open S: in graphics mode 0, you get almost an E: output, except that (as you observed) the cursor handling is broken. This is not a problem of your program, it is a defect in the S: implementation, and the partial sharing of the S: source with that of E: In Os++, this should work correctly.

 

[+Stephen]

Been using my Atari since 1982.  I just yesterday decided to try copying a binary file from DOS to the S handler, rather than E.  It's much faster and I like the fact the control characters print, rather than move the cursor.  Felt pretty dumb - why did that take me 37 years to do?

[E474]

Hi,

 

   I always copy to E: when I want to see the contents of a file in DOS, just tried copying to S: (for the first time!), and it is different than copying to E:, and perhaps a bit more useful. Also managed to introduce a few bugs because if you use the Mac65 IOLIB macros, they work with IOCBs 0 - 7, but if you are working directly in assembler, you're referencing the IOCBs with the X-register, and they are indexed #$0 - #$70 (e.g. in multiples of $10). I'm partway through converting ATR Maker Deluxe from using writes to screen memory to setting the X and Y cursor positions, and then using CIO to output text - I think this is probably a better approach, and also I don't have to worry about working with .SBYTE values or doing the .BYTE string conversion to .SBYTE string (or vice versa). So far screen updates have been fast enough, but I haven't got as far as changing the code for the status bar - this updates the current sector number while reading sectors from the disk so this has to be done as quickly as possible.

 

  Thanks for all the help!

[ricortes]

Something nobody asked for.  Use P/M graphics for cursor. 

[thorfdbg]

21 hours ago, Stephen said:

Been using my Atari since 1982.  I just yesterday decided to try copying a binary file from DOS to the S handler, rather than E.  It's much faster and I like the fact the control characters print, rather than move the cursor.  Felt pretty dumb - why did that take me 37 years to do?

Problem is that this already mixes E: and S: functionality. For example, scrolling. If you copy to S:, and have a graphics screen open, then S: forwards the scrolling to E:, and instead of scrolling the entire screen (e.g. 192 lines), it only scrolls the first 24 lines. S: should rather be a "frame buffer", i.e. you copy in it, but it should not scroll. Scrolling and interpretation of control characters is up to E:

[_The Doctor__]

still can be use of though :)