Jump to content

Photo

DSRLINK Code Tutorial


88 replies to this topic

#26 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,692 posts
  • Location:Silver Run, Maryland

Posted Mon Jan 8, 2018 6:03 PM

Here is a link to the TurboForth source for Willsy’s modified MG GPLLNK routine:  1-16-Initialise.html

 

Here is my latest assembler listing for fbForth 2.0:11 (still in beta):  Attached File  fbForth200.lst   1.26MB   7 downloads  MG’s GPLLNK (followed by MG’s DSRLNK) starts at line 11390.

 

...lee



#27 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,692 posts
  • Location:Silver Run, Maryland

Posted Mon Jan 8, 2018 10:42 PM

If you don't care about GROM DSRs or tape casette I/O, here is Paolo Bagnaresi’s DSRLNK extracted from Willsy’s 1-06-Blocks.html:

 

Spoiler

 

...lee



#28 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 566 posts
  • Location:Germany

Posted Tue Jan 9, 2018 6:54 AM

R13,R14,R15, in GPLWS ... copies FAC off to VDP ... That nop ... Do you mean sbz on your second to last line?

 

Those are some good points, but the entire routine is running in User WS, with only the jump using GPL WS.  You can see that I only modify R9 and R12.

 

I didn't know about FAC restauration, but this does not cause my endless loop.

 

The NOP is only temporary, but you're right about the sbo that should be a sbz.

 

Unfortunately, all this doesn't really explain why my DSRLNK doesn't work.  Does the peripheral need more data in the FAC area besides >8354 and >8356?



#29 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 566 posts
  • Location:Germany

Posted Tue Jan 9, 2018 6:56 AM

If you don't care about GROM DSRs or tape casette I/O, here is Paolo Bagnaresi’s DSRLNK extracted from Willsy’s 1-06-Blocks.html:

 

Excellent!  Thank you, Lee!



#30 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Tue Jan 9, 2018 7:52 AM

You could try a debug session in MAME to watch the register contents. Or send me your test program so I can check it.



#31 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 566 posts
  • Location:Germany

Posted Tue Jan 9, 2018 11:32 AM

You could try a debug session in MAME to watch the register contents. Or send me your test program so I can check it.

 

Ugh, I tried that, but lost patience.  It starts alright for the first three or so loop iterations within the TIFC, but it's just one bad breakpoint and BOOM!

 

I would never foist this on you.   ;)



#32 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 566 posts
  • Location:Germany

Posted Tue Jan 9, 2018 11:41 AM

Stuart, thanks for the Bagnaresi code, but there are some undefined symbols:

.

HAA  FLGPTR  NAMSTO  SAVLEN  SAVPAB  SAVVER   SAVENT  SAVCRU  SAV8A

.

HAA I can guess, but where should the others be?  Inside the upper workspace, or just somewhere?



#33 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,692 posts
  • Location:Silver Run, Maryland

Posted Tue Jan 9, 2018 12:03 PM

Stuart, thanks for the Bagnaresi code, but there are some undefined symbols:

.

HAA  FLGPTR  NAMSTO  SAVLEN  SAVPAB  SAVVER   SAVENT  SAVCRU  SAV8A

.

HAA I can guess, but where should the others be?  Inside the upper workspace, or just somewhere?

 

They are nothing special.  Each one is just a word (2 bytes) in RAM except for NAMSTO, which is the name buffer and 8 bytes long.  Willsy put them in high expansion RAM, I think.

 

...lee



#34 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 566 posts
  • Location:Germany

Posted Tue Jan 9, 2018 12:14 PM

They are nothing special.  Each one is just a word (2 bytes) in RAM except for NAMSTO, which is the name buffer and 8 bytes long.

 

OK, now it's working ...  I used just a word for NAMSTO, so it got overwritten by the other variables and the device/file would not be found.

 

Finally!  A working DSRLNK.   :)



#35 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Wed Jan 10, 2018 6:42 AM

but it's just one bad breakpoint and BOOM!


Anyone injured?
 

I would never foist this on you. ;)


I believe I've gained some experience with the MAME debugger.

 

<shrug> Well, I can't do more than offer to help. :)



#36 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 566 posts
  • Location:Germany

Posted Wed Jan 10, 2018 11:28 AM

Thanks for the offer again, I'd pick it up, but I made some progress by finding the bug in the test program.  Do you notice something about this code?   :P

.

start:
       limi 0
       limi >8300

test1:
       li   r0, >3000
       li   r1, pab_open
       li   r2, pab_open_end - pab_open
       bl   @vmbw
       mov  @c_3009, @>8356
       bl   @dsrlnk
       data 8
;      ...

.

After I fixed my test program, my DSRLNK is suddenly working.  I shouldn't code for that long ...



#37 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Wed Jan 10, 2018 12:22 PM

  • Did you rewrite DSRLNK and VMBW to work without context switch?
  • How does the linker find the lowercase symbols for both?


#38 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 566 posts
  • Location:Germany

Posted Wed Jan 10, 2018 12:44 PM

  • Did you rewrite DSRLNK and VMBW to work without context switch?
  • How does the linker find the lowercase symbols for both?

 

Yes, my versions work with BL instead of BLWP, and symbols are case insensitive.  The missing symbols like PAB_OPEN are just somewhere, so this is not the bug ...



#39 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,082 posts

Posted Wed Jan 10, 2018 2:58 PM

Workspace is not declared properly.



#40 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Wed Jan 10, 2018 3:28 PM

Hmmm ... you certainly know that your interrupt mask constant is equivalent to 0, since only the last four bits are considered...

 

(you might as well try another instruction with it which sounds similar ... ;) )



#41 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,692 posts
  • Location:Silver Run, Maryland

Posted Wed Jan 10, 2018 7:13 PM

Well—your statement “li   r2, pab_open_end - pab_open” is not going to work as it appears you intend with those 3 spaces in the operand field, is it?  Should it not be “li   r2,pab_open_end-pab_open”?

 

...lee



#42 ralphb OFFLINE  

ralphb

    Dragonstomper

  • 566 posts
  • Location:Germany

Posted Wed Jan 10, 2018 11:56 PM

Yes, I wrote LIMI >8300 instead of LWPI >8300, but this sequence of LIMI 0 LWPI ws is so common I rarely look at it.  :)   The missing LWPI caused the test program and thus the DSRLNK to run at >83e0, which caused havoc with the actual >83e0 part.  I took me several hours to find the bug.

 

The spaces are fine, as xas99 is more tolerant than E/A.

 

EDIT: clarification


Edited by ralphb, Wed Jan 10, 2018 11:58 PM.


#43 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Thu Jan 11, 2018 12:55 AM

The spaces are fine, as xas99 is more tolerant than E/A.

 

I suppose line end comments require something like a leading "*"?



#44 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,062 posts
  • Location:Uzbekistan (no, really!)

Posted Thu Jan 11, 2018 9:36 AM

Leading * ??

Yack! Leading ; or death! ;-)

#45 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 606 posts
  • Location:The Great White North

Posted Sun Mar 11, 2018 8:28 PM

So I am working DSRLINK the hard way... of course I am. 

Trying to write as much In Forth as I can. You know, for the fun of it.

 

 

And I found this table:

Bytes       Content

-----------------------------------------------------------

>x000    >AA indicates a standard header

>x001    Version number

>0xx2    Number of programs (optional)

 >x003   Not used

>x004    Pointer to power-up list (>0000 if none)

>x006    Pointer to program list (>0000 if none)

>x008    Pointer the DSR list (>0000 if none)

>x00A   Pointer to subprogram list (>0000 if none)

 

I am reading the code by Signore Paolo Bagnaresi (Riposare in pace Senore)
 

So am I to understand that the only reason that   "BLWP @DSRLNK"  is followed by a literal number '8' is because that is the offset into the ROM table????

If so I am stunned.

 

It reminds of that famous saying:

 

" Eschew Obfuscation.   

  Be perspicuous!"

 

B    :grin:


Edited by TheBF, Sun Mar 11, 2018 8:30 PM.


#46 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,692 posts
  • Location:Silver Run, Maryland

Posted Mon Mar 12, 2018 8:27 AM

So I am working DSRLINK the hard way... of course I am. 

Trying to write as much In Forth as I can. You know, for the fun of it.

 

 

And I found this table:

Bytes       Content

-----------------------------------------------------------

>x000    >AA indicates a standard header

>x001    Version number

>0xx2    Number of programs (optional)

 >x003   Not used

>x004    Pointer to power-up list (>0000 if none)

>x006    Pointer to program list (>0000 if none)

>x008    Pointer the DSR list (>0000 if none)

>x00A   Pointer to subprogram list (>0000 if none)

 

I am reading the code by Signore Paolo Bagnaresi (Riposare in pace Senore)
 

So am I to understand that the only reason that   "BLWP @DSRLNK"  is followed by a literal number '8' is because that is the offset into the ROM table????

If so I am stunned.

 

It reminds of that famous saying:

 

" Eschew Obfuscation.   

  Be perspicuous!"

 

B    :grin:

 

Yes!

 

...lee



#47 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Mon Mar 12, 2018 8:46 AM

So am I to understand that the only reason that   "BLWP @DSRLNK"  is followed by a literal number '8' is because that is the offset into the ROM table????

If so I am stunned.

 

This is not so uncommon. There are two typical ways of parameter passing: using registers, or using a memory location behind the call. You find lots of examples in assembly code where you have a BL @SOMEWHERE with one or more DATA items afterwards; the subprogram can retrieve the values using *R11+. The same is true for BLWP and XOP, where *R14+ must be used.



#48 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 606 posts
  • Location:The Great White North

Posted Mon Mar 12, 2018 8:51 AM

 

This is not so uncommon. There are two typical ways of parameter passing: using registers, or using a memory location behind the call. You find lots of examples in assembly code where you have a BL @SOMEWHERE with one or more DATA items afterwards; the subprogram can retrieve the values using *R11+. The same is true for BLWP and XOP, where *R14+ must be used.

 

I guess my surprise is around the fact that I believe all the ROMS mapped to >4000. It seems a needless complication to supply only the offset.

I suppose it is the ultimate in optimism.

 

<dream_sequence_music>

 

    "We might have a 32bit TI-99 one day...

 

</dream_sequence_music>

 

:-)


Edited by TheBF, Mon Mar 12, 2018 8:51 AM.


#49 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,692 posts
  • Location:Silver Run, Maryland

Posted Mon Mar 12, 2018 9:05 AM

 

I guess my surprise is around the fact that I believe all the ROMS mapped to >4000. It seems a needless complication to supply only the offset.

I suppose it is the ultimate in optimism.

 

<dream_sequence_music>

 

    "We might have a 32bit TI-99 one day...

 

</dream_sequence_music>

 

:-)

 

Well, for one thing, the TI-99/4A spec does not require DSRs to all start at >4000 ROM.  They are allowed to start in GROM space, as well.

 

EDIT:  I should add that Bagnaresi’s and the E/A’s DSRLNK routines do not check for GROM DSRs, but the console's GPL DSRLNK does.  It is the GPL DSRLNK that fbForth 2.0 uses via the MG (Millers Graphics) DSRLNK.  This allows tape cassette usage as well as any GROM DSR one (not I) might invent.

 

...lee



#50 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 606 posts
  • Location:The Great White North

Posted Mon Mar 12, 2018 7:53 PM

 

Well, for one thing, the TI-99/4A spec does not require DSRs to all start at >4000 ROM.  They are allowed to start in GROM space, as well.

 

EDIT:  I should add that Bagnaresi’s and the E/A’s DSRLNK routines do not check for GROM DSRs, but the console's GPL DSRLNK does.  It is the GPL DSRLNK that fbForth 2.0 uses via the MG (Millers Graphics) DSRLNK.  This allows tape cassette usage as well as any GROM DSR one (not I) might invent.

 

...lee

 

Ah yes the GROMs.  Ok I will relent.

 

On another matter.  I have created Forth words to turn on the disk card and I can read the header, and search for DSR names.

But from what I see in CLASSIC99 the address for DSK1 is >4800.  However when I dump the ROM at address 4800 I see only zeros?

What am I missing here?

 

The screen shows my partially completed DSRLNK word operating... partially. 

Attached Files






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users