Jump to content

Photo

in praise of the F18a

f18a hardware tms9900

51 replies to this topic

#26 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 751 posts
  • Location:New Braunfels, Texas.

Posted Thu Apr 3, 2014 12:51 PM

I have a newer CF7+. just bought it.



#27 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Thu Apr 3, 2014 4:59 PM

@hloberg:  Can you get some numbers for me.  Put in either mini memory or editor assembler.  Go to BASIC, then CALL FILES(3).  Then CALL PEEKV(16376,A,B,C,D,E,F,G,H).  PRINT A;B;C;D;E;F;G;H and report the results here.  Thanks, I'm pretty sure we can figure this out.



#28 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Thu Apr 3, 2014 6:01 PM

@hloberg:  Can you get some numbers for me.  Put in either mini memory or editor assembler.  Go to BASIC, then CALL FILES(3).  Then CALL PEEKV(16376,A,B,C,D,E,F,G,H).  PRINT A;B;C;D;E;F;G;H and report the results here.  Thanks, I'm pretty sure we can figure this out.

 

The results for my nanoPEB v1 are

170  3  0  10  0  9  0  6

When I run fbForth v1.0, (which starts up with FILES = 3), and read >3FF8 – >3FFF, I get precisely the same thing, which in hex is

AA03 000A 0009 0006

Those 8 bytes remain the same regardless of changes to the number of files allowed simultaneously.  I changed to FILES=1 and FILES=4 with no change in those bytes for both TI Basic and fbForth.

 

The high 3 words correspond to the DSK volumes that are mounted for each of DSK1 (>000A), DSK2 (>0009) and DSK3 (>0006).  I do not know what the word (>AA03) at >3FF8 represents.

 

...lee



#29 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,362 posts

Posted Thu Apr 3, 2014 6:07 PM

This is a creative and undocumented use of the disk buffer space.  When you do a CALL FILES(n) the TI allocates disk space working down from V3FFF and sets >8370 to point to the first available memory space below the 5 byte header. That pointer lets XB know where the stack should start and probably is what tells the disk system where the buffers can be found.   I discovered that by moving that 5 byte buffer I could put it where I wanted instead of where TI thought it should be.  The disk buffers are indexed to the pointer so they just go along for the ride.  This way TML can reserve space for disk buffers AND buffers for all the bit mapped stuff.  What happens when TML starts up is that it copies the TML routines from high memory to low memory, starts up an interrupt routine, does the call files, moves the aforementioned header, changes the pointer at >8370, erases the loader program and returns to XB.  The TI then goes about business as usual with no clue that the pointers are "wrong". It can load and save programs  and doesn't seem to care about the changes.  Note that this applies to the TI and Corcomp disk controller.  The Myarc controller is a different animal - it is not indexed to the header.  It is indexed to >3FFF so the buffers don't move with the header.  So TML has to be mapped diffferently for the Myarc controller.  It may be that CF7 works like the Myarc controller or maybe completely differently from either one.  

For a clue, look for my write-up in the forum regarding CF7 and FunnelWeb and CF7 devices.   I had to modify FunnelWeb's startup sequence to avoid the eight bytes used by the CF7 as its disk indices. 



#30 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Thu Apr 3, 2014 6:25 PM

For a clue, look for my write-up in the forum regarding CF7 and FunnelWeb and CF7 devices.   I had to modify FunnelWeb's startup sequence to avoid the eight bytes used by the CF7 as its disk indices. 

 

That would be here.

 

...lee

 

{EDIT:  Oops!  I had the wrong post!  Sorry...}


Edited by Lee Stewart, Thu Apr 3, 2014 6:32 PM.


#31 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 751 posts
  • Location:New Braunfels, Texas.

Posted Thu Apr 3, 2014 6:47 PM

I haven't got a Assembler/Editor cartridge or Min mem just yet so I used a BASIC link subroutine for peekv. don't know if this helps since I wasn't able to set files but the values I got was: 170,3,0,104,0,4,0,3



#32 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,362 posts

Posted Thu Apr 3, 2014 7:23 PM

 

That would be here.

 

...lee

 

{EDIT:  Oops!  I had the wrong post!  Sorry...}

Thanks for digging that up.  I just returned home from Dallas, trying to beat all the storms around here.  I forgot you could link a forum topic!  :-o



#33 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Thu Apr 3, 2014 8:28 PM

I remembered right - TML clears out all the video memory up to >3FFF.  Here's one more thing to try:

CALL INIT
OLD DSKn.TML
CALL LOAD(-7283,13)

CALL LOAD(-7237,14)
RUN
and then try loading and running TMLDEMO

This will avoid overwriting those 8 bytes at the top of VDP memory.  

If it doesn't do the trick then I'll have to read up on the CF7.



#34 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 751 posts
  • Location:New Braunfels, Texas.

Posted Thu Apr 3, 2014 8:45 PM

I remembered right - TML clears out all the video memory up to >3FFF.  Here's one more thing to try:

CALL INIT
OLD DSKn.TML
CALL LOAD(-7283,13)

CALL LOAD(-7237,14)
RUN
and then try loading and running TMLDEMO

This will avoid overwriting those 8 bytes at the top of VDP memory.  

If it doesn't do the trick then I'll have to read up on the CF7.

didn't work. 



#35 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Fri Apr 4, 2014 12:01 PM

I will write a simple program that remaps the VDP the way TML and XB256 expect.  I will fully comment it so it can be understood and then post it here so that someone who actually has a CF7 can determine if this can be done.  Also, does TML run when there is no disk access?  The one line circle drawing program in post #6 should be enough to know.



#36 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 751 posts
  • Location:New Braunfels, Texas.

Posted Fri Apr 4, 2014 1:02 PM

problem never been running a program. I can run a program fine. your circles program runs fine.

problem been loading and saving. it always locks up trying to do that.



#37 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Sat Apr 5, 2014 11:01 AM

OK, I'm ready to throw this effing computer in the trash.  I wrote the test program mentioned above.  Standard assembly language, nothing unusual. It assembles fine, but cannot load in XB - I keep getting an "unrecognized character" error.  I have looked closely at the program and can see nothing suspicious. When running under TI BASIC using the E/A cartridge it loads and runs fine with no complaints from the computer. WTF!!! I've attached the source code.  Can someone explain to me why this keeps giving this error. 

Attached Files



#38 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,506 posts
  • Location:Germany

Posted Sat Apr 5, 2014 11:27 AM

Unlike the E/A loader, the Extended Basic loader cannot load compressed object code. You must assemble the code without C option.

#39 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Sat Apr 5, 2014 11:54 AM

Come now, I'm not exactly a newbie at this.  I wish it were that simple. I tried assembling both compressed and uncompressed, and the files are clearly different from each other. I transferred everything over to Win994a and the results are exactly the same.  Maybe it's my equipment telling me I need to get another hobby.  Why don't you try assembling and loading and see if you get the same results.  



#40 Ksarul OFFLINE  

Ksarul

    Quadrunner

  • 5,146 posts

Posted Sat Apr 5, 2014 12:12 PM

If it does the same thing in WIN994A, it isn't an equipment problem. It is probably something really subtle in the code that will have you smack your head in disbelief once you do find it. I don't know enough Assembly to help more than this, I'm afraid, but I'm sure that one of the programming gurus will find it in short order.

 

It sounds like it is about time for a relaxing brew! :)



#41 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,506 posts
  • Location:Germany

Posted Sat Apr 5, 2014 12:23 PM

Come now, I'm not exactly a newbie at this.

 

 

OK, I'll try once more, as you seem to be experienced. You know that the Extended Basic loader is not a linking loader? It does not know REF.



#42 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Sat Apr 5, 2014 12:27 PM

Thank you, that is the answer-I forgot that you had to supply the addresses for VSBW etc.  Boy do I feel dumb! What I have been writing lately generally contains its own utilities and I just plain forgot about that feature.That sound you hear is me smacking my head in disbelief!  


Edited by senior_falcon, Sat Apr 5, 2014 12:31 PM.


#43 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Sun Apr 6, 2014 8:10 PM

Now that I've gotten over spending several hours on a rookie mistake, I have one more thing to ask before posting my program:  Can someone with a CF7 use EA or minimemory and do the following:

CALL PEEKV(14296,A,B,C,D,E,F,G,H,I,J,K,L,M)

PRINT A;B;C;D;E;F;G;H;I;J;K;L;M

Thanks!



#44 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Mon Apr 7, 2014 6:04 AM

Now that I've gotten over spending several hours on a rookie mistake, I have one more thing to ask before posting my program:  Can someone with a CF7 use EA or minimemory and do the following:

CALL PEEKV(14296,A,B,C,D,E,F,G,H,I,J,K,L,M)

PRINT A;B;C;D;E;F;G;H;I;J;K;L;M

Thanks!

 

My nanoPEB (should be the same) gives all zeroes.

 

...lee



#45 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 751 posts
  • Location:New Braunfels, Texas.

Posted Mon Apr 28, 2014 10:22 PM

Did Senior Falcon ever get X256 or TML working with the CF7 ?



#46 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Mon Apr 28, 2014 10:37 PM

No, not yet.  I will post a program that may help diagnose the problem.  It's written, just not posted yet.



#47 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 751 posts
  • Location:New Braunfels, Texas.

Posted Tue Apr 29, 2014 1:04 PM

No, not yet.  I will post a program that may help diagnose the problem.  It's written, just not posted yet.

thanks. finally got my E/A cartridge and a stable CF7 so whenever you need some help just let me know.



#48 senior_falcon ONLINE  

senior_falcon

    Stargunner

  • 1,374 posts
  • Location:Lansing, NY, USA

Posted Sat May 3, 2014 8:46 PM

Here is a test program that allocates memory the way that TML does.  (XB256 is similar and if it will work with TML then it can be made to work with XB256)  The source code is included "CF7TEST-S.TXT" and it has way more comments than normal for me.  The object code is: "CF7TEST-O".  Rather than rewrite a bunch of stuff I have pasted instructions from the comments.  This program describes what TML does with the disk buffer spaces.  Someone who actually has a CF7 and some knowledge of assembly may be able to figure out if it is possible to modify this code so that disk access will work with the CF7 while reserving the memory spaces in VDP needed by TML.

*******************************************
*These subroutines mimic what happens to the VDP ram when TML or XB256 run
*First, we change the pointer to top of memory to reserve space for our routines to use
*in this case we reserve the addresses used by TML, but XB256 works similarly
*Then we write >E5 to all the VDP memory used by TML
*try various disk operations, then check the VDP to see if there are any changes to it.
*They are used this way:
*CALL INIT
*CALL LOAD("DSKn.CF7TEST-O")
*CALL LINK("MOVHDR")
*NEW
*SIZE
*CALL LINK("WRITE5")
*Try disk access - load program, save program, open DV80 and write or read
*file, close file, etc.
*Assuming the disk access works then:
*CALL LINK("CHKVDP") to see whether using the disk system modified
*the VDP memory needed by TML
*
*When you run MOVHDR from XB it starts with CALL FILES(3) set by default in XB
*The subroutine will move the header in the disk buffering area to a new
*location in VDP RAM. When using a TI disk controller,>8370 contains >37D7
*with call files(3). This points one byte below the 5 byte header.
*With the TI controller the header contains:
*>37D8 validation code for the disk controller dsr (>aa)
*>37D9 points to top of vdp memory (>3fff)
*>37DB CRU base identification (11 for CRU 1100)
*>37DC maximum number of opened files (3 by default)
*The CF7 puts 8 more bytes in front of the header and adjusts the pointer
*at >8370 accordingly. (I have no idea what those bytes contain)
*MOVHDR moves the 13 byte header (8+5 bytes) to a new location in VDP RAM
*This lets an XB program run with less stack space and with the VDP RAM
*from >2000 to >3DEE reserved so it is not be used by XB or when
*performing disk operations. The VDP memory above the header is set to zero
*except for the area from >2000 to >3DEE (TML uses this) which is set to >E5 for testing
*purposes. CHKVDP copies VDP ram to >B000 where it can be examined
*from XB using CALL PEEK if necessary. It then checks VDP from >2000 to
*>3DEE to see if the memory there has been changed when using disk.
*It prints "PASS" or "FAIL"
******************************************************

Attached Files


Edited by senior_falcon, Sun May 4, 2014 6:35 AM.


#49 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 751 posts
  • Location:New Braunfels, Texas.

Posted Sun May 4, 2014 7:51 PM

Out of town. If no one get's to it before I get back Tuesday, I'll run the test. Anguish to see what the results are. 



#50 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 751 posts
  • Location:New Braunfels, Texas.

Posted Tue May 6, 2014 4:56 PM

Here is the results.

Nothing will load  after CALL LINK("MOVHDR") I get ERROR 2 if I try to load anything.

but, memory size is: 24488 & 4168

result of CHKVDP is PASS







Also tagged with one or more of these keywords: f18a, hardware, tms9900

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users