senior_falcon Posted June 7, 2015 Share Posted June 7, 2015 Even if the correct value is presumed, but Playground trashes the relevant 5 bytes below the disk buffers (possible with CF&/nanoPEB controllers), they would also need to be restored to proper values. Assuming these controllers can load a BASIC program (a safe assumption!) there shouldn't be any problem with that. The loader is a BASIC program and the only bytes that it changes are in the scratchpad. One possible way to restore >8370 would be to peek the value at that address using e/a or xb. That could be added to the BASIC loader and the information passed by putting it on the screen with HCHAR, then the loader reads it so it knows what the value should be. Not completely automatic, but it should be workable - you'd only have to do it once. Another possibility is that there is a CALL FILES subprogram in the DSR. That should set everything up correctly. Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 7, 2015 Author Share Posted June 7, 2015 (edited) 1. Lee verified that his BwG controller reserves 2 bytes of VDP at 0xfffe-0xffff. The ">AA" is at location 0x37d6. 2. The CF7/nanopeb devices reserve 8 bytes of VDP from 0xfff8-0xffff. ">AA03" is located at 0x37d0. (This usage doesn't conform to the full 5-byte validation header normally constructed by the floppy controllers.) 3. CorComp FDC, Myarc FDC, Myarc HFDC (at 1100 only), and TI controller locate ">AA" at 0x37d8. If we can limit the loader to systems that use only CorComp FDC, Myarc FDC, Myarc HFDC (at 1100 only), TI and CF7/nanoPEB controllers, then we only need to check >3FF8 for >AA03 to determine that we are dealing with a CF7/nanoPEB. If it is a CF7/nanoPEB, we need to restore >8370 with >37CF and all the others with >37D7. It would then be advisable to restore the 5 bytes of VRAM above that value with >AA3FFF1103. If we wish to include the BwG controller in the mix, we need to also check >3FFF for >AA and then restore >8370 to >37D5 and the relevant 5 bytes above to >AA3FFD1103. That will get most disk controllers except for the ones that Tim mentioned in post #16 that are not included here. There seems to be confusion on where to check for the >AA. For the BWG, should v>37D6 (Insane) or v>3FFF (Lee) be checked? For the CF/Nano, should v>37D0 (Insane) or v>3FF8 (Lee) be checked? I've got code that should work, just need to plug in the proper 2 values. Gazoo Edited June 7, 2015 by Gazoo Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2015 Share Posted June 7, 2015 Assuming these controllers can load a BASIC program (a safe assumption!) there shouldn't be any problem with that. The loader is a BASIC program and the only bytes that it changes are in the scratchpad. One possible way to restore >8370 would be to peek the value at that address using e/a or xb. That could be added to the BASIC loader and the information passed by putting it on the screen with HCHAR, then the loader reads it so it knows what the value should be. Not completely automatic, but it should be workable - you'd only have to do it once. Another possibility is that there is a CALL FILES subprogram in the DSR. That should set everything up correctly. I changed >8370 on the real iron with CorComp and nanoPEB controllers and MESS with a BwG controller. Then I tried the equivalent of TI Basic's CALL FILES(3) (I am using fbForth 2.0 for all of these operations) in an attempt to let the DSRs reset >8370. No Dice. If >8370 has the wrong information, all three DSRs hang. The only way I see to get around divining the correct value for >8370 and the values in the lowest 5 bytes of DSR-reserved VRAM, is to set >8370 to >3FFF and invoke the DSR's power-up routine—I do not know how to do that. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2015 Share Posted June 7, 2015 There seems to be confusion on where to check for the >AA. For the BWG, should v>37D6 (Insane) or v>3FFF (Lee) be checked? For the CF/Nano, should v>37D0 (Insane) or v>3FF8 (Lee) be checked? I've got code that should work, just need to plug in the proper 2 values. Gazoo There is no confusion. Tim's checks are for what should be in the lowest byte of the DSR-reserved VRAM space (true for all disk DSRs) if that part of VRAM has not been trashed. My checks at high VRAM space are for what should be there for the two controllers you mentioned, which will determine which, if any, of those two controllers is present. Most (all?) other controllers will not have >AA at the top of VRAM. Their top of VRAM will be the filename-comparison buffer. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2015 Share Posted June 7, 2015 I should add to my last post that for the two controllers mentioned (CF7/nanoPEB and BwG), the >AA value is actually in two places. For a 3-file max, CF7/nanoPEB should have it at >37D0 and >3FF8; BwG should have it at >37D6 and >3FFF. The checks at the high location are to determine where the >AA byte should be at the other end of the DSR-reserved space: >37D0, >37D6 or >37D8. ...lee Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 7, 2015 Author Share Posted June 7, 2015 060715XB27.dsk This version of BASICLOAD should work with all controllers, except maybe the 2 odd ones Ksarul mentioned. That is, if I understood the info provided. Tested so far with TI Controller. Gazoo The current source code is below: DEF START Show where program starts. AORG >3000 START B @START1 Go to actual start of program. PAB DATA >0500,>0FF0,>0000,>2000 Data for PAB BYTE >00 FILENM BYTE >0D Length byte, pathname.filename TEXT 'DSK1.GROMLOAD ' EVEN VDPWA EQU >8C02 VDP WRITE address register VDPRD EQU >8800 VDP READ DATA REGISTER BUFFER EQU >0FC0 PABADR EQU >0F80 CFNANO DATA >AA3F,>FF11,>0300 BWG DATA >AA3F,>FD11,>0300 CHECK DATA >0000 WR BSS >20 Save space for workspace. START1 LWPI WR Load workspace. CLR @>837C LI R0,>3FF8 Get word at v>3FF8 LI R1,CHECK LI R2,>0002 BLWP @VMBR MOV @CHECK,R1 CI R1,>AA03 Check for CFNANO JNE NEXT not found LI R1,>37CF Restore highest available VDP MOV R1,@>8370 LI R0,>37D0 Restore additional data LI R1,CFNANO LI R2,>0005 BLWP @VMBW B @MOVEON Move on NEXT LI R0,>3FFF Get byte at v>3FFF LI R1,CHECK BLWP @VSBR CLR R1 MOVB @CHECK,R1 CI R1,>AA00 Check for BWG JNE NEXT1 not found LI R1,>37D5 Restore highest available VDP MOV R1,@>8370 LI R0,>37D6 Restore additional data LI R1,BWG LI R2,>0005 BLWP @VMBW B @MOVEON Move on NEXT1 LWPI >83E0 Load workspace. CLR R0 LI R1,>D237 37D2 swapped MOVB R1,*R15 SWPB R1 MOVB R1,*R15 now it's in the right order MOVB @>8800,R0 get byte CI R0,>AA00 is it AA? JEQ YAYSAV LI R1,>37D8 37D8 YAYSAV DEC R1 MOV R1,@>8370 save value LWPI WR MOVEON LI R0,>0000 Set VDP register 0. BLWP @VWTR LI R1,>E000 MOVB R1,@>83D4 LI R0,>01E0 Set VDP register 1. BLWP @VWTR LI R0,>0200 Set VDP register 2. BLWP @VWTR LI R0,>030E Set VDP register 3. BLWP @VWTR LI R0,>0401 Set VDP register 4. BLWP @VWTR LI R0,>0717 Set VDP register 7. BLWP @VWTR LI R0,>0380 Get ready to load color table. LI R1,>1717 Set reg. 1 to color >17. TABLE BLWP @VSBW Load 1 byte. INC R0 Increment one byte. CI R0,>03A0 Done yet? JNE TABLE No, load another byte. FILE1 LI R0,PABADR Set up PAB LI R1,PAB LI R2,26 BLWP @VMBW LI R6,PABADR+9 MOV R6,@>8356 BLWP @DSRLNK Load the program DATA 8 NOP LI R0,>0FF6 Move the program to Ram LI R1,>A000 LI R2,>1FFA BLWP @VMBR NOP B @>A000 Execute the program *********************************************************** * UTILITIES * *********************************************************** SET DATA >2000 SAVE DATA 0 REGS BSS 32 EVEN VMBW DATA REGSV,V1 REGSV DATA 0,0,0,>8C02 DATA >8C00,0,>8800,0 DATA >4000,>8000,0,0 DATA 0,0,0,0 V1 MOV R13,R7 MOV *R7+,R0 MOV *R7+,R1 MOV *R7+,R2 SWPB R0 MOVB R0,*R3 SWPB R0 SOC R8,R0 MOVB R0,*R3 NOP V2 MOVB *R1+,*R4 DEC R2 JNE V2 RTWP VSBW DATA REGSV,V3 V3 MOV R13,R7 MOV *R7+,R0 SWPB R0 MOVB R0,*R3 SWPB R0 SOC R8,R0 MOVB R0,*R3 NOP MOVB *R7,*R4 RTWP VWTR DATA REGSV,V4 V4 MOV *R13,R0 SOC R9,R0 SWPB R0 MOVB R0,*R3 SWPB R0 MOVB R0,*R3 RTWP VSBR DATA REGSV,V5 V5 MOV R13,R7 MOV *R7+,R0 SWPB R0 MOVB R0,*R3 SWPB R0 MOVB R0,*R3 NOP MOVB *R6,*R7 RTWP VMBR DATA REGSV,V6 V6 MOV R13,R7 MOV *R7+,R0 MOV *R7+,R1 MOV *R7+,R2 SWPB R0 MOVB R0,*R3 SWPB R0 MOVB R0,*R3 V7 MOVB *R6,*R1+ DEC R2 JNE V7 RTWP DSRLNK DATA REGSD,D1 REGSD DATA 0,0,0,0,0 DEVA DATA 0,0,0,0,0,0,0,0,0,0,0 DCRU DATA 0 DSENT DATA 0 DLEN DATA 0 DPAB DATA 0 DVERS DATA 0 DEV DATA 0,0,0,0 PERIOD TEXT '.' HEXAA BYTE >AA DFLAG DATA 0 D1 CLR @DFLAG MOV *R14+,R5 SZCB @SET,R15 MOV @>8356,R0 MOV R0,R9 AI R9,-8 BLWP @VSBR MOVB R1,R3 SRL R3,8 SETO R4 LI R2,DEV D2 INC R0 INC R4 C R4,R3 JEQ D3 BLWP @VSBR MOVB R1,*R2+ CB R1,@PERIOD JNE D2 D3 MOV R4,R4 JEQ D88 CI R4,7 JGT D88 CLR @>83D0 MOV R4,@>8354 MOV R4,@DLEN INC R4 A R4,@>8356 MOV @>8356,@DPAB D4 LWPI >83E0 CLR R1 LI R12,>0F00 D5 MOV R12,R12 JEQ D55 SBZ 0 D55 AI R12,>0100 CLR @>83D0 CI R12,>2000 JEQ DX MOV R12,@>83D0 SBO 0 LI R2,>4000 CB *R2,@HEXAA JNE D5 A @DEVA,R2 JMP D66 D6 MOV @>83D2,R2 SBO 0 D66 MOV *R2,R2 JEQ D5 MOV R2,@>83D2 INCT R2 MOV *R2+,R9 MOVB @>8355,R5 JEQ D77 CB R5,*R2+ JNE D6 SRL R5,8 LI R6,DEV D7 CB *R6+,*R2+ JNE D6 DEC R5 JNE D7 D77 INC R1 MOV R1,@DVERS MOV R9,@DSENT MOV R12,@DCRU BL *R9 JMP D6 SBZ 0 LWPI REGSD MOV R9,R0 BLWP @VSBR SRL R1,13 JNE D9 RTWP D8 LWPI REGSD D88 CLR R1 D9 SWPB R1 MOVB R1,*R13 SOCB @SET,R15 RTWP DX MOV @DFLAG,@DFLAG JNE D8 SETO @DFLAG LI R12,>0F00 JMP D5 *********************************************************** END Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 7, 2015 Share Posted June 7, 2015 060715XB27.dsk This version of BASICLOAD should work with all controllers, except maybe the 2 odd ones Ksarul mentioned. That is, if I understood the info provided. Tested so far with TI Controller. Gazoo The current source code is below: BLWP @VMBW B @MOVEON Move on NEXT1 LWPI >83E0 Load workspace. CLR R0 LI R1,>D237 37D2 swapped MOVB R1,*R15 SWPB R1 MOVB R1,*R15 now it's in the right order MOVB @>8800,R0 get byte CI R0,>AA00 is it AA? JEQ YAYSAV LI R1,>37D8 37D8 YAYSAV DEC R1 MOV R1,@>8370 save value LWPI WR Looking good, but the line in red above still needs to be fixed. The test is incorrectly failing for the TI controller with potential for a false positive. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2015 Share Posted June 7, 2015 ... This version of BASICLOAD should work with all controllers, except maybe the 2 odd ones Ksarul mentioned. That is, if I understood the info provided. Tested so far with TI Controller. Gazoo The current source code is below: ... Damn! You beat me to it. I was almost done coding the changes. I still do not understand the code between NEXT1 and MOVEON. I do not understand the switch to GPL workspace and the checking of the byte at >37D2. I would change that code to NEXT1 LI R0,>37D8 Restore additional data for other DSRs LI R1,CFNANO same data as CF7/nano LI R2,>0005 BLWP @VMBW LI R1,>37D7 >37D7 = highest available VRAM MOV R1,@>8370 save value MOVEON ... ...lee Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 7, 2015 Share Posted June 7, 2015 Damn! You beat me to it. I was almost done coding the changes. I still do not understand the code between NEXT1 and MOVEON. I do not understand the switch to GPL workspace and the checking of the byte at >37D2. I would change that code to Changing the workspace to GPLWS (0x83E0) is only necessary to utilize R15 as VDPWA. (The TI Controller, for example, uses this value HEAVILY, which is why I mentioned validating it was intact earlier in this thread). The rest of the code sets the VDP write address (LSByte first) then reads the value and compares to the validation code 0xAA. I'm guessing the value 0xD237 was a typo as the value should be 0xD837. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2015 Share Posted June 7, 2015 Changing the workspace to GPLWS (0x83E0) is only necessary to utilize R15 as VDPWA. (The TI Controller, for example, uses this value HEAVILY, which is why I mentioned validating it was intact earlier in this thread). The rest of the code sets the VDP write address (LSByte first) then reads the value and compares to the validation code 0xAA. I'm guessing the value 0xD237 was a typo as the value should be 0xD837. Thanks. Then my code should work—and, I do think it is just as important to restore the bottom 5 bytes of DSR-reserved VRAM for the controllers starting at >37D8 as for the other two. ...lee Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted June 7, 2015 Share Posted June 7, 2015 Another possibility is that there is a CALL FILES subprogram in the DSR. That should set everything up correctly. I was just thinking this while reading everything -- some way to "ask" the DSR to correct everything as if at power-up. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 7, 2015 Share Posted June 7, 2015 Thanks. Then my code should work—and, I do think it is just as important to restore the bottom 5 bytes of DSR-reserved VRAM for the controllers starting at >37D8 as for the other two. ...lee yep. To be honest, I still don't see much value in restoring the VDP header, since we are already relying upon it to be present for the test to succeed, i.e., if the header is destroyed, we'll never find >AA nor can we call the device. The important thing is whether or not 8370 can be set properly to match the header which, presumably, the playground is not touching. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2015 Share Posted June 7, 2015 yep. To be honest, I still don't see much value in restoring the VDP header, since we are already relying upon it to be present for the test to succeed, i.e., if the header is destroyed, we'll never find >AA nor can we call the device. The important thing is whether or not 8370 can be set properly to match the header which, presumably, the playground is not touching. It looks as though the loader might step on that part of VRAM (the lower part), so, even if >8370 is properly set, it still will not work if the DSR cannot find the validation byte or its CRU ID. The only checking that is necessary, IMHO, is the >AA byte in high VRAM to see whether the controller is a CF7/nanoPEB or a BwG. Otherwise, we just presume it is a “normal” controller with the low end of VRAM at >37D8, never checking the validation byte, but “restoring” the critical 5 bytes at the bottom. ...lee Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 7, 2015 Share Posted June 7, 2015 It looks as though the loader might step on that part of VRAM (the lower part), so, even if >8370 is properly set, it still will not work if the DSR cannot find the validation byte or its CRU ID. The only checking that is necessary, IMHO, is the >AA byte in high VRAM to see whether the controller is a CF7/nanoPEB or a BwG. Otherwise, we just presume it is a “normal” controller with the low end of VRAM at >37D8, never checking the validation byte, but “restoring” the critical 5 bytes at the bottom. ...lee Could you point out there the loader might step on VRAM and where? I'm not seeing it... Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 7, 2015 Author Share Posted June 7, 2015 Neither of the 2 versions that check for the TI controller as the 3rd step work. Would it still work properly if the TI controller was checked for as the first step? Gazoo Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 7, 2015 Author Share Posted June 7, 2015 060715XB27.dsk I got it to work, don't know what happened first time around. This works ok with the TI controller, could someone please check the other devices? Gazoo Source: DEF START Show where program starts. AORG >3000 START B @START1 Go to actual start of program. PAB DATA >0500,>0FF0,>0000,>2000 Data for PAB BYTE >00 FILENM BYTE >0D Length byte, pathname.filename TEXT 'DSK1.GROMLOAD ' EVEN VDPWA EQU >8C02 VDP WRITE address register VDPRD EQU >8800 VDP READ DATA REGISTER BUFFER EQU >0FC0 PABADR EQU >0F80 CFNANO DATA >AA3F,>FF11,>0300 BWG DATA >AA3F,>FD11,>0300 CHECK DATA >0000 WR BSS >20 Save space for workspace. START1 LWPI WR Load workspace. CLR @>837C LI R0,>3FF8 Get word at v>3FF8 LI R1,CHECK LI R2,>0002 BLWP @VMBR MOV @CHECK,R1 CI R1,>AA03 Check for CFNANO JNE NEXT not found LI R1,>37CF Restore highest available VDP MOV R1,@>8370 LI R0,>37D0 Restore additional data LI R1,CFNANO LI R2,>0005 BLWP @VMBW B @MOVEON Move on NEXT LI R0,>3FFF Get byte at v>3FFF LI R1,CHECK BLWP @VSBR CLR R1 MOVB @CHECK,R1 CI R1,>AA00 Check for BWG JNE NEXT1 not found LI R1,>37D5 Restore highest available VDP MOV R1,@>8370 LI R0,>37D6 Restore additional data LI R1,BWG LI R2,>0005 BLWP @VMBW B @MOVEON Move on NEXT1 LI R0,>37D8 Restore additional data for other DSRs LI R1,CFNANO same data as CF7/nano LI R2,>0005 BLWP @VMBW LI R1,>37D7 >37D7 = highest available VRAM MOV R1,@>8370 save value MOVEON LI R0,>0000 Set VDP register 0. BLWP @VWTR LI R1,>E000 MOVB R1,@>83D4 LI R0,>01E0 Set VDP register 1. BLWP @VWTR LI R0,>0200 Set VDP register 2. BLWP @VWTR LI R0,>030E Set VDP register 3. BLWP @VWTR LI R0,>0401 Set VDP register 4. BLWP @VWTR LI R0,>0717 Set VDP register 7. BLWP @VWTR LI R0,>0380 Get ready to load color table. LI R1,>1717 Set reg. 1 to color >17. TABLE BLWP @VSBW Load 1 byte. INC R0 Increment one byte. CI R0,>03A0 Done yet? JNE TABLE No, load another byte. FILE1 LI R0,PABADR Set up PAB LI R1,PAB LI R2,26 BLWP @VMBW LI R6,PABADR+9 MOV R6,@>8356 BLWP @DSRLNK Load the program DATA 8 NOP LI R0,>0FF6 Move the program to Ram LI R1,>A000 LI R2,>1FFA BLWP @VMBR NOP B @>A000 Execute the program *********************************************************** * UTILITIES * *********************************************************** SET DATA >2000 SAVE DATA 0 REGS BSS 32 EVEN VMBW DATA REGSV,V1 REGSV DATA 0,0,0,>8C02 DATA >8C00,0,>8800,0 DATA >4000,>8000,0,0 DATA 0,0,0,0 V1 MOV R13,R7 MOV *R7+,R0 MOV *R7+,R1 MOV *R7+,R2 SWPB R0 MOVB R0,*R3 SWPB R0 SOC R8,R0 MOVB R0,*R3 NOP V2 MOVB *R1+,*R4 DEC R2 JNE V2 RTWP VSBW DATA REGSV,V3 V3 MOV R13,R7 MOV *R7+,R0 SWPB R0 MOVB R0,*R3 SWPB R0 SOC R8,R0 MOVB R0,*R3 NOP MOVB *R7,*R4 RTWP VWTR DATA REGSV,V4 V4 MOV *R13,R0 SOC R9,R0 SWPB R0 MOVB R0,*R3 SWPB R0 MOVB R0,*R3 RTWP VSBR DATA REGSV,V5 V5 MOV R13,R7 MOV *R7+,R0 SWPB R0 MOVB R0,*R3 SWPB R0 MOVB R0,*R3 NOP MOVB *R6,*R7 RTWP VMBR DATA REGSV,V6 V6 MOV R13,R7 MOV *R7+,R0 MOV *R7+,R1 MOV *R7+,R2 SWPB R0 MOVB R0,*R3 SWPB R0 MOVB R0,*R3 V7 MOVB *R6,*R1+ DEC R2 JNE V7 RTWP DSRLNK DATA REGSD,D1 REGSD DATA 0,0,0,0,0 DEVA DATA 0,0,0,0,0,0,0,0,0,0,0 DCRU DATA 0 DSENT DATA 0 DLEN DATA 0 DPAB DATA 0 DVERS DATA 0 DEV DATA 0,0,0,0 PERIOD TEXT '.' HEXAA BYTE >AA DFLAG DATA 0 D1 CLR @DFLAG MOV *R14+,R5 SZCB @SET,R15 MOV @>8356,R0 MOV R0,R9 AI R9,-8 BLWP @VSBR MOVB R1,R3 SRL R3,8 SETO R4 LI R2,DEV D2 INC R0 INC R4 C R4,R3 JEQ D3 BLWP @VSBR MOVB R1,*R2+ CB R1,@PERIOD JNE D2 D3 MOV R4,R4 JEQ D88 CI R4,7 JGT D88 CLR @>83D0 MOV R4,@>8354 MOV R4,@DLEN INC R4 A R4,@>8356 MOV @>8356,@DPAB D4 LWPI >83E0 CLR R1 LI R12,>0F00 D5 MOV R12,R12 JEQ D55 SBZ 0 D55 AI R12,>0100 CLR @>83D0 CI R12,>2000 JEQ DX MOV R12,@>83D0 SBO 0 LI R2,>4000 CB *R2,@HEXAA JNE D5 A @DEVA,R2 JMP D66 D6 MOV @>83D2,R2 SBO 0 D66 MOV *R2,R2 JEQ D5 MOV R2,@>83D2 INCT R2 MOV *R2+,R9 MOVB @>8355,R5 JEQ D77 CB R5,*R2+ JNE D6 SRL R5,8 LI R6,DEV D7 CB *R6+,*R2+ JNE D6 DEC R5 JNE D7 D77 INC R1 MOV R1,@DVERS MOV R9,@DSENT MOV R12,@DCRU BL *R9 JMP D6 SBZ 0 LWPI REGSD MOV R9,R0 BLWP @VSBR SRL R1,13 JNE D9 RTWP D8 LWPI REGSD D88 CLR R1 D9 SWPB R1 MOVB R1,*R13 SOCB @SET,R15 RTWP DX MOV @DFLAG,@DFLAG JNE D8 SETO @DFLAG LI R12,>0F00 JMP D5 *********************************************************** END Quote Link to comment Share on other sites More sharing options...
Gazoo Posted June 8, 2015 Author Share Posted June 8, 2015 It's been reported that the BWG code works. Thanks Atrax! I was able to verify that it works with a Myarc FDC with 80 track eprom. Gazoo Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 8, 2015 Share Posted June 8, 2015 It's been reported that the BWG code works. Thanks Atrax! I was able to verify that it works with a Myarc FDC with 80 track eprom. Gazoo I will check my nanoPEB tomorrow. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 8, 2015 Share Posted June 8, 2015 Could you point out there the loader might step on VRAM and where? I'm not seeing it... I got it from these lines of Harry’s post #48 of his “Playground” thread: SAVE this program as DM1000BX, then look into VDP with the classic99 debugger. "STARTBUFFER" began at >3066 in VDP ram. The second program below will copy >0772 bytes from CPU ram starting at >3000 and put them into VDP ram starting at >0366, then return to BASIC. Save and assemble this. I may be misreading the above or it may not be relevant to BASICLOAD; but, if it puts the code destined for RAM >3000 in VRAM at >3066 and it's >772 bytes long, it will just fill the top of available VRAM, stopping just short of >37D8, but definitely clobbering all of the CF7/nanoPEB’s lower 5 bytes and the validation code of the BwG controller. I just figured that, if it got any bigger with our mods, that all of that area for any controller gets clobbered. Like I said, I may be misunderstanding exactly what is going on with the embedding process. ...lee Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 8, 2015 Share Posted June 8, 2015 I got it from these lines of Harry’s post #48 of his “Playground” thread: SAVE this program as DM1000BX, then look into VDP with the classic99 debugger. "STARTBUFFER" began at >3066 in VDP ram. The second program below will copy >0772 bytes from CPU ram starting at >3000 and put them into VDP ram starting at >0366, then return to BASIC. Save and assemble this. I may be misreading the above or it may not be relevant to BASICLOAD; but, if it puts the code destined for RAM >3000 in VRAM at >3066 and it's >772 bytes long, it will just fill the top of available VRAM, stopping just short of >37D8, but definitely clobbering all of the CF7/nanoPEB’s lower 5 bytes and the validation code of the BwG controller. I just figured that, if it got any bigger with our mods, that all of that area for any controller gets clobbered. Like I said, I may be misunderstanding exactly what is going on with the embedding process. ...lee The first time I read the thread, I thought these steps were only needed to generate the files. Of course, the clobber would then happen at this stage and the nano/BwG would be unable to save the program to disk. I wonder if this can be (has been?) modified to respect the CF7/nanopeb device VPD usage. Definitely a good question for Gazoo and/or Senior Falcon. The VDP information we've all been poking at would be good to consolidate and save somewhere like ninerpedia. This area of VDP is most challenging Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 8, 2015 Share Posted June 8, 2015 The first time I read the thread, I thought these steps were only needed to generate the files. Of course, the clobber would then happen at this stage and the nano/BwG would be unable to save the program to disk. I wonder if this can be (has been?) modified to respect the CF7/nanopeb device VPD usage. Definitely a good question for Gazoo and/or Senior Falcon. The VDP information we've all been poking at would be good to consolidate and save somewhere like ninerpedia. This area of VDP is most challenging Agreed—good question and suggestion! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 8, 2015 Share Posted June 8, 2015 ... I got it to work, don't know what happened first time around. This works ok with the TI controller, could someone please check the other devices? Gazoo ... Woohoo! BASICLOAD works with my nanoPEB! I still get the red FCTN+6 screen; but, everything I have checked so far works. The only extra step for me was to copy the files from 060715.DSK to a 1600-sector, CF7+ image of the same name via TI99Dir. I would not think that should matter. ...lee Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted June 8, 2015 Share Posted June 8, 2015 Would BASICLOAD load any EA5 file as long as the length byte and pathname were correct? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 8, 2015 Share Posted June 8, 2015 Would BASICLOAD load any EA5 file as long as the length byte and pathname were correct? Looks like it should. You could probably make the program a general-purpose EA5 loader without a lot of work! ...lee Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 8, 2015 Share Posted June 8, 2015 I got it from these lines of Harry’s post #48 of his “Playground” thread: SAVE this program as DM1000BX, then look into VDP with the classic99 debugger. "STARTBUFFER" began at >3066 in VDP ram. The second program below will copy >0772 bytes from CPU ram starting at >3000 and put them into VDP ram starting at >0366, then return to BASIC. Save and assemble this. I may be misreading the above or it may not be relevant to BASICLOAD; but, if it puts the code destined for RAM >3000 in VRAM at >3066 and it's >772 bytes long, it will just fill the top of available VRAM, stopping just short of >37D8, but definitely clobbering all of the CF7/nanoPEB’s lower 5 bytes and the validation code of the BwG controller. I just figured that, if it got any bigger with our mods, that all of that area for any controller gets clobbered. Like I said, I may be misunderstanding exactly what is going on with the embedding process. ...lee I have added some edits to post #48 mentioned above which should help clarify things. These are highlighted in blue. Basically follow the recipe in that post. Since you are making a BASIC program it should work fine without modifying VEP ram that you care about. The CF7 should take care of the extra 5 bytes automatically. Naturally, if the loader is a different length than the one in post #48 then you have to modify the programs to embed a buffer that is the right length and move the right number of bytes into the buffer. 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.