Jump to content
retroclouds

Stevie ("TiVi") Development Thread

Recommended Posts

1 hour ago, retroclouds said:

ok, I solved this stupid, stupid bug that took me too much time 😁

 

The problem was that R15 did not contain >8C02 at the time the TI-Disk Controller DSR was entered.  >8C02 is the VDP port address.

 

Might be a check to add to classic99; verify that R15 contains value >8C02 when the TI Disk Controller is entered 

 

 

That brings back memories.  When I adapted Jeff Brown's interrupt method in TIMXT terminal emulator, I encountered the same gotcha. Within the DSRLNK routine, I added code to save R15 and change its contents to >8C02 prior to calling the ROM routine; afterwards I restored R15. 

 

What I didn't see you mention is that the workspace in question is GPLWS >83E0.  The standard DSRLNK routines have their own workspace however, they use a LWPI >83E0 just before entering routine in ROM.  Depending on the calling workspace and version of DSRLNK, you may also find other values munged, including R14 and/or R13. 

  • Like 2

Share this post


Link to post
Share on other sites

Incidentally, I just found my bug where I was looking at a value to be a 1 or 0, and found that I have the variable a BSS of 1 instead of a BSS 2.

Stupid stuff, and it took me quite awhile.

 

 

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, retroclouds said:

Might be a check to add to classic99; verify that R15 contains value >8C02 when the TI Disk Controller is entered 

Done, thanks for sharing the result!

 

It'll be a while before I can push any changes, though... my local internet is extremely throttled right now.

 

  • Like 1

Share this post


Link to post
Share on other sites
41 minutes ago, InsaneMultitasker said:

What I didn't see you mention is that the workspace in question is GPLWS >83E0.  The standard DSRLNK routines have their own workspace however, they use a LWPI >83E0 just before entering routine in ROM.  Depending on the calling workspace and version of DSRLNK, you may also find other values munged, including R14 and/or R13. 

Classic99 does have a check already for GPLWS on DSR entry. I wasn't sure if there were any bits in R14 (GPL Status) that needed to be set. I know you can confuse the interrupt routine with certain settings, but not sure if the DSRs care on entry...?

 

  • Like 1

Share this post


Link to post
Share on other sites
17 minutes ago, Tursi said:

Classic99 does have a check already for GPLWS on DSR entry. I wasn't sure if there were any bits in R14 (GPL Status) that needed to be set. I know you can confuse the interrupt routine with certain settings, but not sure if the DSRs care on entry...?

 

It's easy to confuse the programmers even if the DSRs don't care. :)   I don't recall a case where R14 was problematic which doesn't mean much these days hehe.    In the Geneve environment I save GPLWS R13 (GROM) and few other bytes when emulating DSR support but I think that is specific to the dark incantations needed to force the two environments to play nicely, versus any specific requirements by the TI ROM DSRs.

 

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, retroclouds said:

ok, I solved this stupid, stupid bug that took me too much time 😁

The problem was that R15 did not contain >8C02 at the time the TI-Disk Controller DSR was entered.  >8C02 is the VDP port address.

Due to the fact that R15 was >0000 at the time the TI Disk Controller DSR was entered, obviously no byte was ever read from VDP memory and the DSR could not check if it owned the VDP file buffer itself and went into a loop between >4744 - and >4754

Might be a check to add to classic99; verify that R15 contains value >8C02 when the TI Disk Controller is entered 

 

5 hours ago, InsaneMultitasker said:

That brings back memories.  When I adapted Jeff Brown's interrupt method in TIMXT terminal emulator, I encountered the same gotcha. Within the DSRLNK routine, I added code to save R15 and change its contents to >8C02 prior to calling the ROM routine; afterwards I restored R15. 

           What I didn't see you mention is that the workspace in question is GPLWS >83E0.  The standard DSRLNK routines have their own workspace however, they use a LWPI >83E0 just before entering routine in ROM.  Depending on the calling workspace and version of DSRLNK, you may also find other values munged, including R14 and/or R13. 

 

3 hours ago, InsaneMultitasker said:

It's easy to confuse the programmers even if the DSRs don't care. :)   I don't recall a case where R14 was problematic which doesn't mean much these days hehe.    In the Geneve environment I save GPLWS R13 (GROM) and few other bytes when emulating DSR support but I think that is specific to the dark incantations needed to force the two environments to play nicely, versus any specific requirements by the TI ROM DSRs.

 

Here  is the layout of the last 3 registers of GPL Workspace expected by console and DSR routines when the GPL Workspace is current:

  • R13 (>83FA) Current GROM Port (>9800)
  • R14 (>83FC)
    • MSB (>83FC) VDP Interrupt Timer (byte at >8379) Tick (usually >01)
    • LSB (83FD) GPL Flags
      • >20 Cassette Operations
      • >10 Cassette Verify
      • >08 16 KiB VRAM
      • >02 Multicolor Mode
      • >01 Sound Table in VRAM
  • R15 (>83FE) VDP Write Address (>8C02)

...lee

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...