I/O Pic loading in ALTIRRA

[ac.tomo]

I wonder if someone can help me, I'm trying to load a standard 62 sector picture file in using ALTIRRA but ain't getting anywhere, here's what I got:

 

10 GRAPHICS 15+16:MEM=7680

20 DATA 104,104,104,170,76,86,228

30 FOR I=0 TO 6:READ D:POKE 1536+I,D:NEXT I

50 HI=INT(MEM/256):LO=MEM-HI*256

60 OPEN #1,4,0,"D:FILENAME.PIC"

70 POKE 849,1:POKE 850,7

75 POKE 852,PEEK(88):POKE 853,PEEK(89)

80 POKE 856,LO:POKE 857,HI

85 POKE 858,4

90 I=USR(1536)

95 CLOSE #1

 

It's actually for my book so if anyone can give me the answer then they will be credited, thanks.

 

[dmsc]

46 minutes ago, ac.tomo said:

Hi!

 

A couple of problems with your code:

 

46 minutes ago, ac.tomo said:

I wonder if someone can help me, I'm trying to load a standard 62 sector picture file in using ALTIRRA but ain't getting anywhere, here's what I got:

 

10 GRAPHICS 15+16:MEM=7680

20 DATA 104,104,104,170,76,86,228

30 FOR I=0 TO 6:READ D:POKE 1536+I,D:NEXT I

50 HI=INT(MEM/256):LO=MEM-HI*256

60 OPEN #1,4,0,"D:FILENAME.PIC"

70 POKE 849,1:POKE 850,7

75 POKE 852,PEEK(88):POKE 853,PEEK(89)

80 POKE 856,LO:POKE 857,HI

85 POKE 858,4

90 I=USR(1536)

 

Your machine language code expects on argument, the I/O channel multiplied by 16, so you need:

  I=USR(1536,16)

 

46 minutes ago, ac.tomo said:

 

95 CLOSE #1

 

After this, the OS will switch to graphics 0, so you will not see the picture.

Add some delay, or an infinite loop at the end.

 

Have fun!

 

46 minutes ago, ac.tomo said:

 

[ac.tomo]

3 hours ago, dmsc said:

Hi!

 

A couple of problems with your code:

 

Your machine language code expects on argument, the I/O channel multiplied by 16, so you need:

  I=USR(1536,16)

 

 

After this, the OS will switch to graphics 0, so you will not see the picture.

Add some delay, or an infinite loop at the end.

 

Have fun!

 

Many thanks for that DMSC, as I believe the program works fine on the real hardware, it's obviously a difference with ALTIRRA, although I'm not sure since it's been a long time since I tried it on the real ATARI, but thanks again, unfortuneatly your name will now appear in my book, unless ofcourse you don't want it too. thanks.

[bfollett]

I don't remember the source I got it from, but back in the day, I had a string variable containing a file I/O routine you could call with the USR function.  Here's a screenshot of it from a program I wrote back then.  If your interested in it I can point you to a source.

 

[dmsc]

Hi!

On 3/28/2023 at 5:44 PM, ac.tomo said:

Many thanks for that DMSC,

You are welcome  

On 3/28/2023 at 5:44 PM, ac.tomo said:

as I believe the program works fine on the real hardware, it's obviously a difference with ALTIRRA, although I'm not sure since it's been a long time since I tried it on the real ATARI

No, the program as posted does not work in real hardware, as the missing parameter to the USR means the only way it will load something is that by chance the X register is 16, and this will not be true.

 

On 3/28/2023 at 5:44 PM, ac.tomo said:

, but thanks again, unfortuneatly your name will now appear in my book, unless ofcourse you don't want it too. thanks.

ha ha, no problem, but IMHO, my contribution is too small.

 

On another topic, your program is much simpler in FastBasic:

GRAPHICS 15+16
OPEN #1,4,0,"D:FILENAME.PIC"
BGET #1,DPEEK(88),7680
CLOSE #1
GET K

 

The last line waits for a key press, so you can see the image.

 

Attached is an ATR with the fixed BASIC program and the FastBasic version, you can test it by typing "FB" to load the IDE, then pressing CONTROL-L (load), type PROG.FB , then you can run it with CONTROL-R. With CONTROL-S you can save the program and CONTROL-Q quits.

 

Have Fun!

 

loadpic.atr

[TGB1718]

Using good old BASIC, you could use this sort of routine to load your picture, this code is used in

an Art program I wrote bitd in BASIC, uses BASIC to load the CIO registers and calls a short USR routine

to then call CIO.

 

This program was using Graphics 9 or 11 but still uses the same memory as your pictures

MEM/MEM1 are pointing to the screen (locations 88 and 89)

LENLO/LENHI is the size of the load

 

850 OPEN #1,4,128,A$
860 POKE 106,160:GRAPHICS GRAF+32
870 POKE 850,7:POKE 852,MEM:POKE 853,MEM1

872 POKE 856,LENLO:POKE 857,LENHI

875 X2=USR(ADR(B$))
880 CLOSE #1

 

This is the USR routine

700 DATA 104,162,16,76,86,228
710 RESTORE 700
711 REM   PLA            68
712 REM   LDX  #10       A2 10
713 REM   JMP  E456      4C 56 E4
720 FOR I=1 TO 6:READ A:B$(I,I)=CHR$(A):NEXT I
730 RETURN  

 

I use the same method to to save the pictures

[ac.tomo]

18 hours ago, dmsc said:

Hi!

You are welcome  

No, the program as posted does not work in real hardware, as the missing parameter to the USR means the only way it will load something is that by chance the X register is 16, and this will not be true.

 

ha ha, no problem, but IMHO, my contribution is too small.

 

On another topic, your program is much simpler in FastBasic:

GRAPHICS 15+16
OPEN #1,4,0,"D:FILENAME.PIC"
BGET #1,DPEEK(88),7680
CLOSE #1
GET K

 

The last line waits for a key press, so you can see the image.

 

Attached is an ATR with the fixed BASIC program and the FastBasic version, you can test it by typing "FB" to load the IDE, then pressing CONTROL-L (load), type PROG.FB , then you can run it with CONTROL-R. With CONTROL-S you can save the program and CONTROL-Q quits.

 

Have Fun!

 

loadpic.atr 90.02 kB · 2 downloads

 

I tried the program (as it was) on the real hardware and it (as I remember) does work, obviously on the real hardware the OPEN function places the channel number on the stack whereas on ALTIRRA it does not.

 

But thanks everyone for your help.

 

Edited March 30, 2023 by ac.tomo

[dmsc]

2 hours ago, ac.tomo said:

 

I tried the program (as it was) on the real hardware and it (as I remember) does work, obviously on the real hardware the OPEN function places the channel number on the stack whereas on ALTIRRA it does not.

 

But thanks everyone for your help.

 

Mmm..... no.

 

I also tried it in my 800xl and it did not work. There is no "stack" where to put the channel number - you must have tried a different code.

 

Have Fun!

 

     Daniel.

[ac.tomo]

mmm, puzzling. I did try the original program.

[TGB1718]

As @dmsc said, the original needs a parameter passing in i.e. the channel to put in the 'X' register (Decimal 16).

Calling the use(1536) without any parameters is very likely to crash as the first 3 instructions pull

one byte of data each off the stack, without a parameter you will pull the return address off the stack

so when the OS does a return from the CIO call it will crash.

 

This program work exactly the same on real hardware or Altirra.

 

Your right that the channel would be on the stack, but only if you pass it in as a parameter,

maybe that's what has confused you ?

[_The Doctor__]

so the program requires input or hard code that needs to be put on the stack as part of let's say asking for a Drive/filename or a default.

 

[TGB1718]

The program has already opened the file in basic and has also set the buffer address and filesize

it only requires the channel number passing into the X register before calling CIO

[ivop]

On 3/30/2023 at 11:00 AM, TGB1718 said:

712 REM   LDX  #10       A2 10

 

ldx #$10

 

[ac.tomo]

To be honest I haven't "made sure" about this issue as my 65XE is down my mothers and not up my flat and I only have one DOS 2.5 disk and for some reason the disk is loading slow and troubled and there's obviously some problems there, actually I'm just going up my flat now to 'hopefully' find a working disk to try, I do understand completely what your all saying, I do know the PLA's are looking for what would be the ",16" lsb/msb's but for some reason I seem to remember it working as it is, it isn't actually my program, I got it from somewhere several years ago, I'll get back to you when I've tried a working disk.

[_The Doctor__]

well you are going to want to check everything on real hardware, and have others proof read whatever is going to be in print

[TGB1718]

1 hour ago, ivop said:

ldx #$10

All the bytes are hex

 

[ac.tomo]

I've just got back from getting the disk and trying it out, your correct DMSC, not that I thought you were wrong, I just felt adamant that it would work as it was (as this is how I remembered it), I don't remember the ",16" being in the original program, obviously by the look at it it was, somewhere along the line this ",16" has been overlooked, I could see that the USR argument required some bytes on the stack but I thought the OPEN operation done that, obviously not, but thanks for making me see the correct method, otherwise there would have been an error in my book. Thanks again.