RXB Posted January 31, 2019 Share Posted January 31, 2019 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? Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 31, 2019 Share Posted January 31, 2019 I'm pretty sure for this particular project, the CF7 offset isn't a huge concern.... Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 31, 2019 Share Posted January 31, 2019 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 Quote Link to comment Share on other sites More sharing options...
ralphb Posted January 31, 2019 Author Share Posted January 31, 2019 Actually, I really like the DSK1.LOAD idea. 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. 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.) Quote Link to comment Share on other sites More sharing options...
+9640News Posted January 31, 2019 Share Posted January 31, 2019 Actually, I really like the DSK1.LOAD idea. 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. 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........... 3 Quote Link to comment Share on other sites More sharing options...
RXB Posted January 31, 2019 Share Posted January 31, 2019 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 31, 2019 Share Posted January 31, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 31, 2019 Share Posted January 31, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted January 31, 2019 Share Posted January 31, 2019 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 Quote Link to comment Share on other sites More sharing options...
RXB Posted January 31, 2019 Share Posted January 31, 2019 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. 3 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 31, 2019 Share Posted January 31, 2019 That is a gotcha I would not have anticipated! ...lee 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted January 31, 2019 Share Posted January 31, 2019 That is a gotcha I would not have anticipated! ...lee Well my new RXB SIZE will help figure out what is going on..... Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 31, 2019 Share Posted January 31, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 31, 2019 Share Posted January 31, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted January 31, 2019 Share Posted January 31, 2019 Here is another oddity at >8318 in start up of XB it >37D7 But at >8318 in start up of TI Basic is >37D6 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 1, 2019 Share Posted February 1, 2019 And what about looking for write operations to 6000/2? Quote Link to comment Share on other sites More sharing options...
RXB Posted February 1, 2019 Share Posted February 1, 2019 (edited) 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 February 1, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 1, 2019 Share Posted February 1, 2019 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. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 2, 2019 Share Posted February 2, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted February 2, 2019 Author Share Posted February 2, 2019 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.) Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 2, 2019 Share Posted February 2, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
ralphb Posted February 2, 2019 Author Share Posted February 2, 2019 You're right, Michael, I had not thought of that. Quote Link to comment Share on other sites More sharing options...
Ed in SoDak Posted February 2, 2019 Share Posted February 2, 2019 (edited) 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 February 2, 2019 by Ed in SoDak 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted February 3, 2019 Share Posted February 3, 2019 (edited) 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 February 3, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
ralphb Posted February 3, 2019 Author Share Posted February 3, 2019 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? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.