Jump to content
IGNORED

TIPI - TI-99/4A to Raspberry PI interface development


Recommended Posts

1 hour ago, jedimatt42 said:

I think if you are seeing 1000 0011 in the high byte of >83F2 then you are not using the GPLWS when calling the routine and I should fix it to not make that assumption.

>83F2 was from an equate in your code for the cleanunit code.  As I think about it now, that is an address and not the contents for the SZC source part of the instruction.  OK, that makes sense to me now for the SZC instruction.

 

I am using >83E0 for GPLWS.

 

So, let me ask this as I have been reading a number of messages on this subject in this topic.

 

The code I have works fine for transfer to VDP so the only changes were to deliver to CPU.

 

If I change the unit number in subprogram >14 from >00 to >80, then change the buffer address from >1000 in VDP to >A000 in CPU, the subprogram should send the data to CPU when reading from DSK0?

 

Looking at the DSR source for subprogram >14, it does not look like anything else is expected differently.  What I am not seeing is tipi.log showing any errors, etc. with that option. 

 

In various iterations of code changes, I saw unprintable characters for a filename that was not found, so I went through some code changes to have things in CPU rather than VDP thinking that was the cause without solving the issue. 

 

Going to make a backup of my current work, and start back with the original source again that works with VDP transfers.

 

  • Like 1
Link to comment
Share on other sites

On 7/5/2024 at 12:25 PM, 9640News said:

In various iterations of code changes, I saw unprintable characters for a filename that was not found, so I went through some code changes to have things in CPU rather than VDP thinking that was the cause without solving the issue. 

@9640News After our conversation today, I took a look at the loader source.  One of the program's subroutines is coded to use two DATA parameters:

 

BL  @GETPARMS

DATA ADDRESS1,ADDRESS2

 

Unfortunately, the second address is not used by the subroutine.  The return address (R11) is only advanced 1 word instead of 2, so when the subroutine returns, the program executes ADDRESS2 as if it were an instruction.  In the case of the working VDP loader, the assembled address was the equivalent of "COC *R12+,R7" which doesn't affect any important registers nor does it interfere with the next instruction.  However, in the non-working VDP loader, the 2nd address assembles to a 2-word instruction that consumes the first word of the next 2-word instruction (a MOVB @address,register) and corrupts the program.  R0 is never set to a valid length byte, VMBW writes >FFFF bytes to VRAM, the level 2 access code >0114 is overwritten, and the whole load fails.  

 

As you changed the program, ADDRESS2 changed and so did the assembled code. Nasty little bug.  With luck, you can re-implement your CPU RAM-based instructions with success this time around. I'll send you the fixed routine via PM.  I'm guessing the bug has been lurking since the loader was written. 

 

 

  • Like 2
Link to comment
Share on other sites

@jedimatt42, @mizapf, @InsaneMultitasker

 

Well, I finally got the code to work loading MDOS straight into CPU ram instead of through VDP and then copying into CPU ram with Matt's unreleased eprom.  Turns out, much simpler than I was making it out to be and I think it has more to do with my lack of understanding on the implementation of the level 2 subroutines.

 

From the tipi.log file, the actually loading of MDOS was reduced from about 7.5 seconds to 5 seconds though the entire loading time while using MAME.  On MAME, my PC was only reduced by around 2 seconds from a 25 second to a 23 second cycle until the AUTOEXEC was starting to load.

 

I want to add a screen like what is with the SCSI/IDE to indicate the TIPI loader is loaded, then the next step will be to burn an eprom and test on real hardware to get timing from the log files.

 

Beery

  • Like 3
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...