Jump to content

Photo

Detecting Extended BASICs

XB

52 replies to this topic

#26 RXB OFFLINE  

RXB

    River Patroller

  • 3,513 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jan 31, 2019 12:43 PM

 

 

The VRAM info depends on disk controllers.  For instance, if a CF7+ or nanoPEB is installed, >37D8 will definitely NOT have those values.  They will have moved down 8 bytes.  At least one disk controller does not use VRAM buffers, so, even checking >8370 in scratchpad RAM for top of available VRAM will not help.

 

...lee

Hmmm  why does the CF7+ and nanoPEB not operate like RAMDISK or Disk or SCSI or WSD does and put those bytes at proper place?



#27 Opry99er ONLINE  

Opry99er

    Quadrunner

  • 10,607 posts
  • Location:Hustisford, WI

Posted Thu Jan 31, 2019 12:48 PM

I'm pretty sure for this particular project, the CF7 offset isn't a huge concern....

#28 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Thu Jan 31, 2019 12:50 PM

Hmmm  why does the CF7+ and nanoPEB not operate like RAMDISK or Disk or SCSI or WSD does and put those bytes at proper place?

 

CF7+ and nanoPEB do put those values in proper places.  They have simply (and legitimately) reserved the uppermost 8 bytes of VRAM for their own use and updated >8370 accordingly.

 

...lee



#29 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 626 posts
  • Location:Germany

Posted Thu Jan 31, 2019 1:00 PM

Actually, I really like the DSK1.LOAD idea.  :thumbsup:  And since, in my case, this is intended for the SDD 99, which emulates a disk drive, I just need to check if an OPEN or LOAD for a file named LOAD arrives.  :idea:   I don't even need to write and run assembly code for it!

 

(This will NOT work if a user has a physical DSK1 in the system, but this I won't recommend anyway.)



#30 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 818 posts
  • Location:Campbellsburg, KY

Posted Thu Jan 31, 2019 2:37 PM

Actually, I really like the DSK1.LOAD idea.  :thumbsup:  And since, in my case, this is intended for the SDD 99, which emulates a disk drive, I just need to check if an OPEN or LOAD for a file named LOAD arrives.  :idea:   I don't even need to write and run assembly code for it!

 

(This will NOT work if a user has a physical DSK1 in the system, but this I won't recommend anyway.)

 

Glad my idea had some merit.  Sometimes the simplest things can be overlooked...........



#31 RXB OFFLINE  

RXB

    River Patroller

  • 3,513 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jan 31, 2019 2:56 PM

 

CF7+ and nanoPEB do put those values in proper places.  They have simply (and legitimately) reserved the uppermost 8 bytes of VRAM for their own use and updated >8370 accordingly.

 

...lee

So a SIZE reports 8 bytes less than normal XB?

 

Or are those 8 bytes in the Buffer area?

 

And what happens if you do a CALL FILES(1)?

 

How does SIZE report that?

 

Just wondering as I try to keep RXB standards of most devices unless they break those standards.



#32 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,365 posts

Posted Thu Jan 31, 2019 3:23 PM

Another possible alternative would be to read the current GROM address and if it is <0x6000 you are using BASIC GROMs and >0x6000 it is an extended basic variant grom.   Might need to first save then later restore the address for stability.



#33 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Thu Jan 31, 2019 4:05 PM

So a SIZE reports 8 bytes less than normal XB?

 

Or are those 8 bytes in the Buffer area?

 

And what happens if you do a CALL FILES(1)?

 

How does SIZE report that?

 

Just wondering as I try to keep RXB standards of most devices unless they break those standards.

 

 

Those 8 bytes are above the buffer area at >3FF8 – >3FFF.

 

A CALL FILES(1) will simply collapse the buffer space to what is necessary for one open file, which, for CF7+/nanoPEB, begins at >3BDC, i.e., >8370 will contain >3BDB.  For the TI disk controller, that would be >3BE4 and >3BE3, respectively.

 

Curiously, when I tried SIZE, nothing seemed to change.  Peeking >8370 did, however, give the correct values as in the last paragraph.

 

...lee


  • RXB likes this

#34 RXB OFFLINE  

RXB

    River Patroller

  • 3,513 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jan 31, 2019 4:42 PM

Another possible alternative would be to read the current GROM address and if it is <0x6000 you are using BASIC GROMs and >0x6000 it is an extended basic variant grom.   Might need to first save then later restore the address for stability.

 

How about ROM at >6000 all the XB ROMs are the same from >6000 to >600F



#35 RXB OFFLINE  

RXB

    River Patroller

  • 3,513 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jan 31, 2019 4:53 PM

 

 

Those 8 bytes are above the buffer area at >3FF8 – >3FFF.

 

A CALL FILES(1) will simply collapse the buffer space to what is necessary for one open file, which, for CF7+/nanoPEB, begins at >3BDC, i.e., >8370 will contain >3BDB.  For the TI disk controller, that would be >3BE4 and >3BE3, respectively.

 

Curiously, when I tried SIZE, nothing seemed to change.  Peeking >8370 did, however, give the correct values as in the last paragraph.

 

...lee

 

OH I SEE A PROBLEM! 

SIZE is hard coded and >8370 is changeable. 

 

I guess as long as you stick to CF7 or nanoPEB environment it is fine but adding normal devices will create problems for ROMs garbage collection routines.

I imagine they assumed you would not mix and match devices like that so should be fine, but still violates normal standards by TI devices.

 

Additionally RXB 2019 has CALL VDPSTACK allows you to change location of the VDPSTACK in VDP RAM.

And RXB 2019 has CALL PRAM allows you to change memory size of 24K RAM.

 

Unknown what kind of problems this creates down the line.



#36 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Thu Jan 31, 2019 4:56 PM

That is a gotcha I would not have anticipated!

 

...lee


  • RXB likes this

#37 RXB OFFLINE  

RXB

    River Patroller

  • 3,513 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jan 31, 2019 5:02 PM

That is a gotcha I would not have anticipated!

 

...lee

Well my new RXB SIZE will help figure out what is going on.....

 

 



#38 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,365 posts

Posted Thu Jan 31, 2019 5:05 PM

 

How about ROM at >6000 all the XB ROMs are the same from >6000 to >600F

Hmm, not sure, it sounded like the need is to determine which environment is in use.  Checking ROM would confirm the XB cartridge is present but wouldn't tell you if you are /using/ BASIC or XB.   My suggestion is made with the assumption that XB isn't rummaging around in the BASIC grom address space and vice versa. 



#39 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Thu Jan 31, 2019 5:12 PM

Hmm, not sure, it sounded like the need is to determine which environment is in use.  Checking ROM would confirm the XB cartridge is present but wouldn't tell you if you are /using/ BASIC or XB.  ...

 

My sentiments exactly.

 

...lee


  • RXB likes this

#40 RXB OFFLINE  

RXB

    River Patroller

  • 3,513 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jan 31, 2019 5:19 PM

Here is another oddity at >8318 in start up of XB it >37D7

 

But at >8318 in start up of TI Basic is >37D6 



#41 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,506 posts
  • Location:Germany

Posted Fri Feb 1, 2019 7:56 AM

And what about looking for write operations to 6000/2?

#42 RXB OFFLINE  

RXB

    River Patroller

  • 3,513 posts
  • Location:Vancouver, Washington, USA

Posted Fri Feb 1, 2019 1:40 PM

XB ROMs are exactly the same from >6000 to >7FFD

Something else is the difference in XB ROMs at >7FFE ROM BANK 1

  4152 7FFE              AORG >7FFE   
  4153 7FFE 9226         DATA >9226   
  4154                
  4155            ************************************************************
  4156                
  4157                   END  

ROM BANK 2

  4416 7FFE              AORG >7FFE   
  4417 7FFE C68C         DATA >C68C   
  4418            ************************************************************
  4419                   END  

Edited by RXB, Fri Feb 1, 2019 1:41 PM.


#43 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,506 posts
  • Location:Germany

Posted Fri Feb 1, 2019 1:53 PM

What I mean is that write operation to the 6000 area are a good indication that Extended Basic is being used, and not only present in the cartridge slot.



#44 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Fri Feb 1, 2019 8:46 PM

Here is another oddity at >8318 in start up of XB it >37D7

 

But at >8318 in start up of TI Basic is >37D6 

Rich may be on to something. With TI BASIC running, >8318 seems to always be even, regardless of how many files you have open.

With XB running >8318 is always odd.


  • RXB likes this

#45 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 626 posts
  • Location:Germany

Posted Sat Feb 2, 2019 4:24 AM

What I mean is that write operation to the 6000 area are a good indication that Extended Basic is being used, and not only present in the cartridge slot.

 

Nice idea, but wouldn't this also hold for Pac-Man?  (Well, not actually Pac-Man, which uses weird bank switching addresses, but any other cart with bank switching.)



#46 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,506 posts
  • Location:Germany

Posted Sat Feb 2, 2019 7:04 AM

In combination with a ROM contents check? You can then first check whether Exbasic is plugged in, and by monitoring the write accesses, whether it is in use. I don't know what kind of actions you consider possible for your application, whether hardware- or software-based.



#47 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 626 posts
  • Location:Germany

Posted Sat Feb 2, 2019 7:14 AM

You're right, Michael, I had not thought of that.



#48 Ed in SoDak OFFLINE  

Ed in SoDak

    Moonsweeper

  • 430 posts
  • Location:Black Hills of South Dakota

Posted Sat Feb 2, 2019 1:00 PM

Beery wrote: " ...Perhaps I am killing my own idea, but was there a mod somewhere that holding the space bar down, bypassed an attempt to load DSK1.LOAD?"

 

SXB has the spacebar LOAD bypass. TIXB does not. I didn't test other XB variants.

-Ed


Edited by Ed in SoDak, Sat Feb 2, 2019 1:02 PM.

  • RXB likes this

#49 RXB OFFLINE  

RXB

    River Patroller

  • 3,513 posts
  • Location:Vancouver, Washington, USA

Posted Sat Feb 2, 2019 8:39 PM

 

Beery wrote: " ...Perhaps I am killing my own idea, but was there a mod somewhere that holding the space bar down, bypassed an attempt to load DSK1.LOAD?"

 

SXB has the spacebar LOAD bypass. TIXB does not. I didn't test other XB variants.

-Ed

 

RXB has a very different start up  screen and start menu.

 

Push any key for DSK#.LOAD will use any key to select LOAD thus pushing A will use LOAD off of RAMDISK A

Push ZERO KEY and then press number key for WDS#.LOAD which works for SCSI or IDE or MFM hard drives.

 

Push ENTER KEY and same menu works for EA 5 DSK#.UTIL1 thus pushing A will use UTIL1 off of RAMDISK A

After you push ENTER KEY you can push ZERO KEY and a NUMBER KEY and will load WDS#.UTIL1 (same as the LOAD above)

 

Push COMMA key and same menu works for running a batch file DSK#.BATCH that works like 4A DOS text file 

 

 

Or press SPACE BAR to go to EDIT MODE of XB.


Edited by RXB, Sun Feb 3, 2019 12:17 AM.


#50 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 626 posts
  • Location:Germany

Posted Sun Feb 3, 2019 4:06 AM

In light of that, maybe checking ROM space in combination with Michael's bank switching idea is a safer bet.  Although I'd have to check exactly when XB is switching banks.

 

Any ideas on how to trash my latest plan?  :)







Also tagged with one or more of these keywords: XB

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users