Assembly on the 99/4A

[HOME AUTOMATION]

8 hours ago, Vorticon said:

In the following snippet, only the second save operation actually works, while the first one does nothing even though it's completely valid.

You don't show how you execute this code.

 

...I tried this...

       DEF  RUN
       REF  VMBW,DSRLNK
PABP   DATA >0600,>0000,>0000,>1800,>000E
       TEXT 'DSK1.CAPTURE_P'
       EVEN
PABC   DATA >0600,>2000,>0000,>1800,>000E
       TEXT 'DSK1.CAPTURE_C'
       EVEN
 
* FIRST SAVE OP
RUN    LI   R0,>1F1A          VDP ADDRESS FOR PAB
       LI   R1,PABP           POINT TO PATTERN DATA PAB
       LI   R2,24             LENGTH OF PAB
       BLWP @VMBW             TRANSFER PATTERN PAB TO VDP
       LI   R6,>1F23          LOAD R6 WITH PATTERN
       MOV  R6,@>8356         REQUIRED BY DSRLNK
       BLWP @DSRLNK           SAVE TO DISK
       DATA 8                 REQUIRED BY DSRLNK
       JMP  $

...and, it seemed to work...

 

File length=1880

[Tursi]

Since you are using Classic99, make sure you checked the debug log for warnings after the operation.

 

[+Vorticon]

4 hours ago, HOME AUTOMATION said:

You don't show how you execute this code.

 

...I tried this...

       DEF  RUN
       REF  VMBW,DSRLNK
PABP   DATA >0600,>0000,>0000,>1800,>000E
       TEXT 'DSK1.CAPTURE_P'
       EVEN
PABC   DATA >0600,>2000,>0000,>1800,>000E
       TEXT 'DSK1.CAPTURE_C'
       EVEN
 
* FIRST SAVE OP
RUN    LI   R0,>1F1A          VDP ADDRESS FOR PAB
       LI   R1,PABP           POINT TO PATTERN DATA PAB
       LI   R2,24             LENGTH OF PAB
       BLWP @VMBW             TRANSFER PATTERN PAB TO VDP
       LI   R6,>1F23          LOAD R6 WITH PATTERN
       MOV  R6,@>8356         REQUIRED BY DSRLNK
       BLWP @DSRLNK           SAVE TO DISK
       DATA 8                 REQUIRED BY DSRLNK
       JMP  $

...and, it seemed to work...

 

File length=1880

This is pretty much how that snippet is supposed to run. The rest of the program is about capturing an image and storing it in the VDP. And indeed in Classic 99 this seems to work with no errors reported in the PAB or in the debug window. It does not work however on real hardware, or at least my configuration where DSK1 is a TIPI folder...

[+Vorticon]

7 hours ago, Asmusr said:

Do you have LIMI 0? 

I don't. Is it necessary?

[+mizapf]

Normally, you have to ensure that during your screen accesses, no interrupt handling can mess up your video setting. But if I remember correctly, a LIMI 0 is executed before program start in Editor/Assembler.

[+Vorticon]

Any one has a disk copy of the MG Explorer by any chance? I have the cart image but the manual keeps referring to disk executables needed to be able to load and explore other programs simultaneously...

[HOME AUTOMATION]

This?

 

MGEXPLOR.ZIP

[+Vorticon]

3 hours ago, HOME AUTOMATION said:

This?

 

MGEXPLOR.ZIP

Yup! Thanks! It should work great as a live debugger.

[+Vorticon]

I wonder if anyone here with a TIPI installed can try @HOME AUTOMATION's test code above and see if it works for them on real hardware. I just need to confirm that it's not my own hardware at fault here.

[+mizapf]

I can at least confirm that in MAME, CAPTURE_P has been created in DSK1 on TIPI (program, 6272 bytes).

[Reciprocating Bill]

Works fine, for me, writing CAPTURE_P (6272 bytes) to the TIPI on real hardware. 

[+Vorticon]

Hmmm... I wonder why it's not working on my system then...

[Stuart]

Out of interest, have you tried moving the PAB somewhere else in VDP RAM? Are you using Graphics 2 mode ... tried the PAB at >0F80?

 

As the PAB address is referenced twice, you might want to define it:

PABADR EQU >xxxx

LI R0, PABADR

...

...

LI R6,PABADR+9

[+Vorticon]

7 hours ago, Stuart said:

Out of interest, have you tried moving the PAB somewhere else in VDP RAM? Are you using Graphics 2 mode ... tried the PAB at >0F80?

 

As the PAB address is referenced twice, you might want to define it:

PABADR EQU >xxxx

LI R0, PABADR

...

...

LI R6,PABADR+9

I'm actually in bitmap mode and I have the PAB at the location of the sprite attribute table which I have disabled. But it's certainly worth a shot to try a different location. And yeah defining the PAB address in VDP would make things clearer.

One thing I want to test as well is disabling the RS232 card prior to saving the image. My program uses that card to receive outside info from a camera via the parallel port, and I only disable the card just prior to exiting the program. I wonder if that might make a difference...

[Stuart]

35 minutes ago, Vorticon said:

One thing I want to test as well is disabling the RS232 card prior to saving the image.

In my early version of the Internet Browser that used the RS-232 port, I switched off the RS-232 card before doing a disk access, then re-enabled it after the disk access. Can't remember if I found I had to do that to make the disk access work, or whether it just seemed like a 'safe' thing to do.

[+InsaneMultitasker]

33 minutes ago, Vorticon said:

One thing I want to test as well is disabling the RS232 card prior to saving the image. My program uses that card to receive outside info from a camera via the parallel port, and I only disable the card just prior to exiting the program. I wonder if that might make a difference.

If the RS232's ROM is enabled and visible at the >4000 space, then yes, it could definitely interfere with other DSR operations.  The DSRLNK routine scans the peripherals by turning each card on and off to find the requested device name or subroutine.  Perhaps the DSRLNK is turning off the RS232 during the first save operation, which sets up the second save operation for success (since the RS232 is now off).  You may have found the answer   <fingers crossed>

 

[apersson850]

On 9/26/2023 at 7:57 PM, InsaneMultitasker said:

Perhaps the DSRLNK is turning off the RS232 during the first save operation, which sets up the second save operation for success (since the RS232 is now off).

Very probable.

A "standard" DSRLNK call will turn each card in the CRU address range first on, then off, in the search for the correct DSR. If you are looking for a disk controller DSR, which normally is at >1100, it will not be found if the card at >1300 is enabled at the same time. Two data buffers will try to overdrive each other. Scanning will continue and soon enable the card at >1300 (which doesn't change anything, since it already is enabled), find the RS232 card, realize it's not the card searched for, disable the card and continue the search. But the disk controller at >1100 will not be found, because looking for that has already passed.

Next time the DSRLNK is called, provided nothing turned that RS 232 card on again in between, all cards are off and the disk controller will be found at >1100.

Edited September 28, 2023 by apersson850

[+Vorticon]

That was it! Disabling the RS232 prior to saving solved the issue. Amazing how one keeps learning about this 30+ year old system...

Thanks for the help guys.

[+Vorticon]

2 hours ago, apersson850 said:

Vary probable.

A "standard" DSRLNK call will turn each card in the CRU address range first on, then off, in the search for the correct DSR. If you are looking for a disk controller DSR, which normally is at >1100, it will not be found if the card at >1300 is enabled at the same time. Two data buffers will try to overdrive each other. Scanning will continue and soon enable the card at >1300 (which doesn't change anything, since it already is enabled), find the RS232 card, realize it's not the card searched for, disable the card and continue the search. But the disk controller at >1100 will not be found, because looking for that has already passed.

Next time the DSRLNK is called, provided nothing turned that RS 232 card on again in between, all cards are off and the disk controller will be found at >1100.

Great info! One question though: since the disk controller is at a lower address than the RS232, why is it not found first during the scanning process?

[JasonACT]

It is found.  The >AA byte will be found, because the 2 enabled ROMs have the same byte value at position 0...  The rest of the bytes in the ROMs will be scrambled though with your 2 pieces of hardware fighting on the data bus (don't do this, you will eventually need to replace the line drivers when they fail due to conflicts).

[+Vorticon]

I want to also take the opportunity to give a plug to the MG Explorer package. It's a really fantastic debugging tool on real hardware far better than any other debugger I have used in the past. A really under-appreciated piece of software. And by the way the cart image is pretty much useless since one cannot simultaneous load the program to be debugged with it. Only the disk image is usable.

[+Vorticon]

4 minutes ago, JasonACT said:

It is found.  The >AA byte will be found, because the 2 enabled ROMs have the same byte value at position 0...  The rest of the bytes in the ROMs will be scrambled though with your 2 pieces of hardware fighting on the data bus (don't do this, you will eventually need to replace the line drivers when they fail due to conflicts).

But then shouldn't the RS232 also not be recognized as well?

[JasonACT]

1 minute ago, Vorticon said:

But then shouldn't the RS232 also not be recognized as well?

 

Only in the very temporary time period the DSR scanning routine is running and looking for the disk drive name.  And once it completes and doesn't find the device you specified, yes, the RS232 card will be switched off and won't respond to whatever your non-standard card access routines are trying to read.

 

[+Vorticon]

25 minutes ago, JasonACT said:

 

Only in the very temporary time period the DSR scanning routine is running and looking for the disk drive name.  And once it completes and doesn't find the device you specified, yes, the RS232 card will be switched off and won't respond to whatever your non-standard card access routines are trying to read.

 

I see. So to make sure I am understanding this fully, on the first pass in this situation, the scanning routine essentially turns off all the cards it comes across (including the disk controller I assume) since it cannot recognize the device specified, then on the second DSRLNK call, now that all the cards are off, the disk controller is activated first since it's at a lower address and is properly recognized. 

Now since my TIPI is at >1000, if it gets switched off on the first scanning pass, how come it remains active subsequently?

[JasonACT]

5 minutes ago, Vorticon said:

So to make sure I am understanding this fully, on the first pass in this situation, the scanning routine essentially turns off all the cards it comes across (including the disk controller I assume) since it cannot recognize the device specified, then on the second DSRLNK call, now that all the cards are off, the disk controller is activated first since it's at a lower address and is properly recognized. 

One by one, it turns them on first, scans, then turns them off, but if a card with a higher address is already on by some non-standard user logic - you will get a conflict.  On the 2nd pass, they will all be off, because that's how the scan works.

6 minutes ago, Vorticon said:

One last question: my TIPI is at >1000. Does the DSR scanning only start at >1100 or is there some other trick going on here?

There's no trick, it starts at >1000.