dphirschler Posted September 16, 2014 Share Posted September 16, 2014 I am having trouble loading games from my NanoPEB. It boots up into my game disk just fine, just as it used to back in the day. But the games just don't load. Can it be a problem with the NanoPEB and the way this game disk was written? The game disk has a bunch of cart games (some Atarisoft, TI and Parker Bros games). And it is designed to auto load into XB giving you a menu. That much works. But when you select a game, it just goes blank. The loader/linker program was written by my friend long ago. The menu was written by me in XB. I haven't yet tried loading the games through EA yet. I suppose that is the next test. But I really wanted it to work like it used to. I'd appreciate it if some of you could test out my game disk on your NanoPEB/CF7+ and also on real hardware. I'll attach the dsk image. Darryl 07_games_bones.dsk 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 16, 2014 Share Posted September 16, 2014 I am having trouble loading games from my NanoPEB. It boots up into my game disk just fine, just as it used to back in the day. But the games just don't load. Can it be a problem with the NanoPEB and the way this game disk was written? The game disk has a bunch of cart games (some Atarisoft, TI and Parker Bros games). And it is designed to auto load into XB giving you a menu. That much works. But when you select a game, it just goes blank. The loader/linker program was written by my friend long ago. The menu was written by me in XB. I haven't yet tried loading the games through EA yet. I suppose that is the next test. But I really wanted it to work like it used to. I'd appreciate it if some of you could test out my game disk on your NanoPEB/CF7+ and also on real hardware. I'll attach the dsk image. Darryl I seem to remember having trouble with straight-up copies of DSK images to my nanoPEB when those images were not 400KB. What I had to do was to create a 400K image with TI99Dir and copy the files from the old DSK image to the new one before transferring it to my nanoPEB. ...lee Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted September 16, 2014 Share Posted September 16, 2014 (edited) The first thing I noticed, the disk is 1440 sectors. Was it originally DSDD? I tried the original image first, and the menu came up just like you mentioned, but when I selected a game... BLUE SCREEN. So copied everything over to a new DSSD 80 track disk to use on my HxC on the real hardware. Same thing... BLUE SCREEN. I also tried a couple games without your loader, one loaded, one did not. My guess is that this copy somehow got corrupted and affected the data library calls in your loader program. Sorry I could not help. ** EDIT ** It's FUBAR in Classic99 too. Edited September 16, 2014 by --- Ω --- Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 16, 2014 Share Posted September 16, 2014 Is that loader supposed to only work with a nanoPEB? I found a hidden machine language loader at the end of the LOAD program which contains a fixed branch to address 4080. This will likely send the TI into the jungle if it uses other controllers. Quote Link to comment Share on other sites More sharing options...
dphirschler Posted September 17, 2014 Author Share Posted September 17, 2014 Ahh! That rings a bell. I remember that. But we had this working on original equipment. Maybe a Myarc Mem Exp. at most. I tried loading the same files in MESS and they also failed. So I am not sure why it fails. Has anybody tried it on real equipment yet? My PEB is still dead so I cannot test it. I did try my super Scott Adams Adventure disk on the NanoPEB and it worked just fine, so I know the NanoPEB works now. Darryl Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted September 17, 2014 Share Posted September 17, 2014 Was your original disk formatted on a CorComp controller using Disk Manager 1000? That sometimes does really bad things to the disk (and produces symptoms just like you're having when another controller is reading them). Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted September 17, 2014 Share Posted September 17, 2014 Is that loader supposed to only work with a nanoPEB? I found a hidden machine language loader at the end of the LOAD program which contains a fixed branch to address 4080. This will likely send the TI into the jungle if it uses other controllers. What is also weird is there does not appear to be a DSRLNK routine in the loader, even though the code BLWP's to one in low memory. This makes me wonder if there is an XB variant out there that loads additional assembly utilities into low memory, including DSRLNK? This loader seems to be configured for some very specific hardware. Quote Link to comment Share on other sites More sharing options...
RXB Posted September 17, 2014 Share Posted September 17, 2014 Yes matter of fact RXB 1005 had a updated version that loaded the Miller Graphics GPLDSRLINK when you did a CALL INIT2 Quote Link to comment Share on other sites More sharing options...
dphirschler Posted September 17, 2014 Author Share Posted September 17, 2014 Was your original disk formatted on a CorComp controller using Disk Manager 1000? That sometimes does really bad things to the disk (and produces symptoms just like you're having when another controller is reading them). Very likely. I remember having a battery backed clock. But I thought it was the Myarc. Could it be that the disk-reading software (TI99-PC) has a problem with these types of disks? It seemed to read them fine, and the loader program seemed to work... well, it maybe isn't loading the hidden code properly. How exactly did you discover it, Mizapf? But I also remember doing something to convert DIS/VAR to PGM format. I just don't remember what. I also remember having some game disks that were made to be loaded in Minimem. Darryl Quote Link to comment Share on other sites More sharing options...
dphirschler Posted September 17, 2014 Author Share Posted September 17, 2014 Yes matter of fact RXB 1005 had a updated version that loaded the Miller Graphics GPLDSRLINK when you did a CALL INIT2 Could this loader have been dependent on the presence of a Gram Kracker? We (my friend and I) both had one. Darryl Quote Link to comment Share on other sites More sharing options...
RXB Posted September 17, 2014 Share Posted September 17, 2014 (edited) Could this loader have been dependent on the presence of a Gram Kracker? We (my friend and I) both had one. Darryl No it was loaded just like CALL INIT but just had the additional Miller Graphics GPLDSRLNK with a LINK address as GPLDSR that came up in the list. Edited September 17, 2014 by RXB Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted September 17, 2014 Share Posted September 17, 2014 No it was loaded just like CALL INIT but just had the additional Miller Graphics GPLDSRLNK with a LINK address as GPLDSR that came up in the list. 1 DATA BIGFOOT,CHISHOLM,CONGO,D-STATION,D-STATION2,DEFENDER,FROGGER,GUARDIAN,JUNGLEHUNT,MOONPATROL,MSPACMAN 2 DATA MUNCHMOBIL,PACMAN,PARSEC,POLEPOS,POPEYE,PROTECTOR2,Q*BERT,STARFORT,STARTREK,STATION1 3 @=21 :: A=@/2+.5 :: DIM @$(36) :: CALL CLEAR :: CALL SCREEN(5) :: FOR B=0 TO 14 :: CALL COLOR(B,16,1) :: NEXT B :: DISPLAY AT(2,1):"FASTLOAD BY BYTE THE BIG ONE" 4 FOR B=1 TO @ :: READ @$(B) :: NEXT B :: FOR B=1 TO A :: DISPLAY AT(B+3,1):CHR$(B+64);" ";@$(B) :: NEXT B :: FOR B=A+.5 TO @ :: DISPLAY AT((B+3)-A,15):CHR$(B+64);" ";@$(B) :: NEXT B :: DISPLAY AT(A+4.5,1):"CHOICE :" 5 CALL HCHAR(A+4.5,11,30) :: FOR B=1 TO 5 :: CALL KEY(3,C,D) :: IF D<>0 THEN 9 6 NEXT B 7 CALL HCHAR(A+4.5,11,32) :: FOR B=1 TO 5 :: CALL KEY(3,C,D) :: IF D<>0 THEN 9 8 NEXT B :: GOTO 5 9 IF C<65 OR C>64+@ THEN 5 ELSE CALL HCHAR(A+4.5,11,C) :: CALL INIT :: CALL LOAD(8192,254,70) :: CALL LINK("WCM","DSK1."&@$(C-64)) I just curious, does anyone remember "WCM" in a hardware data library? It would be interesting to know, just for the hell of it. Anyway, do you have your heart set on reproducing the original diskette or would you settle on a substitute loader? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 17, 2014 Share Posted September 17, 2014 Very likely. I remember having a battery backed clock. But I thought it was the Myarc. Could it be that the disk-reading software (TI99-PC) has a problem with these types of disks? It seemed to read them fine, and the loader program seemed to work... well, it maybe isn't loading the hidden code properly. How exactly did you discover it, Mizapf? I wondered what the last BASIC line was intended to do, since there was no CALL LOAD with a machine language program. So I concluded that there is a hidden loader, something that I actually learnt of in this forum some time ago. My TIImageTool did not help at first because it autodetected it as a BASIC program and only listed the BASIC lines, so I exported the file to the file system, clipped away the first 256 bytes (thus breaking the BASIC header in order to trick my own program), reimported it into the DSK, and doing a disassembly. Got this: FE3A: LWPI >83E0 02E0 83E0 FE3E: CLR R0 04C0 FE40: LI R1,>0001 0201 0001 FE44: LI R2,>FFE7 0202 FFE7 FE48: BLWP @>2014 0420 2014 FE4C: LI R12,>1100 020C 1100 FE50: SBO 0 1D00 FE52: STWP R4 02A4 FE54: LI R5,>0002 0205 0002 FE58: LI R11,>FE6C 020B FE6C FE5C: B @>4080 0460 4080 FE60: NOP 1000 FE62: SBZ 0 1E00 FE64: LI R0,>01C0 0200 01C0 FE68: BLWP @>2118 0420 2118 FE6C: LI R0,>071C 0200 071C FE70: BLWP @>2118 0420 2118 FE74: LI R0,>030E 0200 030E FE78: BLWP @>2118 0420 2118 FE7C: LI R0,>0401 0200 0401 FE80: BLWP @>2118 0420 2118 FE84: LI R0,>0040 0200 0040 FE88: MOVB R0,@>8C02 D800 8C02 FE8C: SWPB R0 06C0 FE8E: MOVB R0,@>8C02 D800 8C02 FE92: LI R1,>2020 0201 2020 FE96: LI R2,>0300 0202 0300 FE9A: MOVB R1,@>8C00 D801 8C00 FE9E: DEC R2 0602 FEA0: JNE >FE9A 16FC FEA2: CLR R1 04C1 FEA4: LI R2,>0080 0202 0080 FEA8: MOVB R1,@>8C00 D801 8C00 FEAC: DEC R2 0602 FEAE: JNE >FEA8 16FC FEB0: LI R1,>1C00 0201 1C00 FEB4: LI R2,>0080 0202 0080 FEB8: MOVB R1,@>8C00 D801 8C00 FEBC: DEC R2 0602 FEBE: JNE >FEB8 16FC FEC0: CLR R1 04C1 FEC2: LI R2,>0C00 0202 0C00 FEC6: MOVB R1,@>8C00 D801 8C00 FECA: DEC R2 0602 FECC: JNE >FEC6 16FC FECE: LI R0,>0900 0200 0900 FED2: MOV R0,@>834A C800 834A FED6: BLWP @>20FC 0420 20FC FEDA: DATA >0018 FEDC: LI R0,>0B00 0200 0B00 FEE0: MOV R0,@>834A C800 834A FEE4: BLWP @>20FC 0420 20FC FEE8: DATA >004A FEEA: LI R0,>01E0 0200 01E0 FEEE: BLWP @>2118 0420 2118 FEF2: LI R0,>0F80 0200 0F80 FEF6: LI R1,>FFDE 0201 FFDE FEFA: LI R2,>0020 0202 0020 FEFE: BLWP @>210C 0420 210C FF02: LI R0,>0F89 0200 0F89 FF06: MOVB @>FFE7,R1 D060 FFE7 FF0A: SRL R1,8 0981 FF0C: A R1,R0 A001 FF0E: MOV R0,@>23FC C800 23FC FF12: LI R0,>FF34 0200 FF34 FF16: LI R1,>2400 0201 2400 FF1A: LI R2,>0800 0202 0800 FF1E: MOV *R0+,*R1+ CC70 FF20: DEC R2 0602 FF22: JNE >FF1E 16FD FF24: B @>2400 0460 2400 FF28: LWPI >20BA 02E0 20BA FF2C: LI R5,>2500 0205 2500 FF30: LI R0,>0F86 0200 0F86 FF34: LI R1,>3000 0201 3000 FF38: BLWP @>2108 0420 2108 FF3C: LI R0,>0F89 0200 0F89 FF40: MOV R0,@>8356 C800 8356 FF44: BLWP @>211C 0420 211C FF48: DATA >0008 FF4A: JEQ >FFB4 1334 FF4C: LI R0,>1000 0200 1000 FF50: LI R1,>23F0 0201 23F0 FF54: LI R2,>0006 0202 0006 FF58: BLWP @>2114 0420 2114 FF5C: MOV @>23F4,*R5+ CD60 23F4 FF60: MOV @>23F2,R2 C0A0 23F2 FF64: MOV @>23F4,R1 C060 23F4 FF68: LI R0,>1006 0200 1006 FF6C: BLWP @>2114 0420 2114 FF70: MOV @>23FC,R0 C020 23FC FF74: BLWP @>2110 0420 2110 FF78: AI R1,>0100 0221 0100 FF7C: BLWP @>2108 0420 2108 FF80: MOV @>23F0,@>23F0 C820 23F0 23F0 FF86: JNE >FF30 16D4 FF88: LWPI >83E0 02E0 83E0 FF8C: MOV @>8370,R4 C120 8370 FF90: LI R3,>8300 0203 8300 FF94: LI R2,>00A0 0202 00A0 FF98: CLR *R3+ 04F3 FF9A: DECT R2 0642 FF9C: JNE >FF98 16FD FF9E: MOV R4,@>8370 C804 8370 FFA2: LI R4,>9E7E 0204 9E7E FFA6: MOV R4,@>8372 C804 8372 FFAA: LWPI >20BA 02E0 20BA FFAE: MOV @>2500,R0 C020 2500 FFB2: B *R0 0450 FFB4: MOVB @>23F8,@>9800 D820 23F8 9800 FFBA: NOP 1000 FFBC: MOVB @>23F9,@>9800 D820 23F9 9800 FFC2: BLWP @>0000 0420 0000 2 Quote Link to comment Share on other sites More sharing options...
dphirschler Posted September 17, 2014 Author Share Posted September 17, 2014 I just curious, does anyone remember "WCM" in a hardware data library? It would be interesting to know, just for the hell of it.Anyway, do you have your heart set on reproducing the original diskette or would you settle on a substitute loader? > I just curious, does anyone remember "WCM" in a hardware data library? It would be interesting to know, just for the hell of it. WCM is my friend’s initials. So he must have named the routine after himself. > Anyway, do you have your heart set on reproducing the original diskette or would you settle on a substitute loader? Certainly, I’d be happy with another loader program. But I am more interested in solving this puzzle. This was a cool loader. And if something is wrong with it with today’s emulation software and updated hardware, I’d like to know why. At the moment, I suspect the disk transferring software… especially since it seems to be behaving the same in MESS, on the NanoPEB, and on real hardware. The only thing common there is the software used to transfer the floppy. I vaguely remember attaching machine code to XB programs somehow (using Disko perhaps?). It would load with the XB program, but would show up as garbled characters in the listing. I don’t see any of that here. That’s the main reason I suspect the TI99-PC disk transferring software. Perhaps it sees XB programs and ignores the non-ascii characters when transferring(?). We did all kinds of goofy things back then just because we could. I used ‘@’ as a variable name. We named disks “NONO…..1” (note the period chars were illegal) using Disko. Attached machine code to XB programs in weird ways. Ripped carts using the Widget and load interrupt switch. And who knows what else? I know we also had some game loaders that required Mini-Mem, but I cannot remember why. Maybe that was one of the cart ripper programs. Darryl Quote Link to comment Share on other sites More sharing options...
dphirschler Posted September 17, 2014 Author Share Posted September 17, 2014 I wondered what the last BASIC line was intended to do, since there was no CALL LOAD with a machine language program. So I concluded that there is a hidden loader, something that I actually learnt of in this forum some time ago. My TIImageTool did not help at first because it autodetected it as a BASIC program and only listed the BASIC lines, so I exported the file to the file system, clipped away the first 256 bytes (thus breaking the BASIC header in order to trick my own program), reimported it into the DSK, and doing a disassembly. Got this: FE3A: LWPI >83E0 02E0 83E0 FE3E: CLR R0 04C0 FE40: LI R1,>0001 0201 0001 FE44: LI R2,>FFE7 0202 FFE7 FE48: BLWP @>2014 0420 2014 FE4C: LI R12,>1100 020C 1100 FE50: SBO 0 1D00 FE52: STWP R4 02A4 FE54: LI R5,>0002 0205 0002 FE58: LI R11,>FE6C 020B FE6C FE5C: B @>4080 0460 4080 FE60: NOP 1000 FE62: SBZ 0 1E00 FE64: LI R0,>01C0 0200 01C0 FE68: BLWP @>2118 0420 2118 FE6C: LI R0,>071C 0200 071C FE70: BLWP @>2118 0420 2118 FE74: LI R0,>030E 0200 030E FE78: BLWP @>2118 0420 2118 FE7C: LI R0,>0401 0200 0401 FE80: BLWP @>2118 0420 2118 FE84: LI R0,>0040 0200 0040 FE88: MOVB R0,@>8C02 D800 8C02 FE8C: SWPB R0 06C0 FE8E: MOVB R0,@>8C02 D800 8C02 FE92: LI R1,>2020 0201 2020 FE96: LI R2,>0300 0202 0300 FE9A: MOVB R1,@>8C00 D801 8C00 FE9E: DEC R2 0602 FEA0: JNE >FE9A 16FC FEA2: CLR R1 04C1 FEA4: LI R2,>0080 0202 0080 FEA8: MOVB R1,@>8C00 D801 8C00 FEAC: DEC R2 0602 FEAE: JNE >FEA8 16FC FEB0: LI R1,>1C00 0201 1C00 FEB4: LI R2,>0080 0202 0080 FEB8: MOVB R1,@>8C00 D801 8C00 FEBC: DEC R2 0602 FEBE: JNE >FEB8 16FC FEC0: CLR R1 04C1 FEC2: LI R2,>0C00 0202 0C00 FEC6: MOVB R1,@>8C00 D801 8C00 FECA: DEC R2 0602 FECC: JNE >FEC6 16FC FECE: LI R0,>0900 0200 0900 FED2: MOV R0,@>834A C800 834A FED6: BLWP @>20FC 0420 20FC FEDA: DATA >0018 FEDC: LI R0,>0B00 0200 0B00 FEE0: MOV R0,@>834A C800 834A FEE4: BLWP @>20FC 0420 20FC FEE8: DATA >004A FEEA: LI R0,>01E0 0200 01E0 FEEE: BLWP @>2118 0420 2118 FEF2: LI R0,>0F80 0200 0F80 FEF6: LI R1,>FFDE 0201 FFDE FEFA: LI R2,>0020 0202 0020 FEFE: BLWP @>210C 0420 210C FF02: LI R0,>0F89 0200 0F89 FF06: MOVB @>FFE7,R1 D060 FFE7 FF0A: SRL R1,8 0981 FF0C: A R1,R0 A001 FF0E: MOV R0,@>23FC C800 23FC FF12: LI R0,>FF34 0200 FF34 FF16: LI R1,>2400 0201 2400 FF1A: LI R2,>0800 0202 0800 FF1E: MOV *R0+,*R1+ CC70 FF20: DEC R2 0602 FF22: JNE >FF1E 16FD FF24: B @>2400 0460 2400 FF28: LWPI >20BA 02E0 20BA FF2C: LI R5,>2500 0205 2500 FF30: LI R0,>0F86 0200 0F86 FF34: LI R1,>3000 0201 3000 FF38: BLWP @>2108 0420 2108 FF3C: LI R0,>0F89 0200 0F89 FF40: MOV R0,@>8356 C800 8356 FF44: BLWP @>211C 0420 211C FF48: DATA >0008 FF4A: JEQ >FFB4 1334 FF4C: LI R0,>1000 0200 1000 FF50: LI R1,>23F0 0201 23F0 FF54: LI R2,>0006 0202 0006 FF58: BLWP @>2114 0420 2114 FF5C: MOV @>23F4,*R5+ CD60 23F4 FF60: MOV @>23F2,R2 C0A0 23F2 FF64: MOV @>23F4,R1 C060 23F4 FF68: LI R0,>1006 0200 1006 FF6C: BLWP @>2114 0420 2114 FF70: MOV @>23FC,R0 C020 23FC FF74: BLWP @>2110 0420 2110 FF78: AI R1,>0100 0221 0100 FF7C: BLWP @>2108 0420 2108 FF80: MOV @>23F0,@>23F0 C820 23F0 23F0 FF86: JNE >FF30 16D4 FF88: LWPI >83E0 02E0 83E0 FF8C: MOV @>8370,R4 C120 8370 FF90: LI R3,>8300 0203 8300 FF94: LI R2,>00A0 0202 00A0 FF98: CLR *R3+ 04F3 FF9A: DECT R2 0642 FF9C: JNE >FF98 16FD FF9E: MOV R4,@>8370 C804 8370 FFA2: LI R4,>9E7E 0204 9E7E FFA6: MOV R4,@>8372 C804 8372 FFAA: LWPI >20BA 02E0 20BA FFAE: MOV @>2500,R0 C020 2500 FFB2: B *R0 0450 FFB4: MOVB @>23F8,@>9800 D820 23F8 9800 FFBA: NOP 1000 FFBC: MOVB @>23F9,@>9800 D820 23F9 9800 FFC2: BLWP @>0000 0420 0000 Holy crap, that is clever! Darryl Quote Link to comment Share on other sites More sharing options...
RXB Posted September 18, 2014 Share Posted September 18, 2014 I wondered what the last BASIC line was intended to do, since there was no CALL LOAD with a machine language program. So I concluded that there is a hidden loader, something that I actually learnt of in this forum some time ago. My TIImageTool did not help at first because it autodetected it as a BASIC program and only listed the BASIC lines, so I exported the file to the file system, clipped away the first 256 bytes (thus breaking the BASIC header in order to trick my own program), reimported it into the DSK, and doing a disassembly. Got this: FE3A: LWPI >83E0 02E0 83E0 FE3E: CLR R0 04C0 FE40: LI R1,>0001 0201 0001 FE44: LI R2,>FFE7 0202 FFE7 FE48: BLWP @>2014 0420 2014 FE4C: LI R12,>1100 020C 1100 FE50: SBO 0 1D00 FE52: STWP R4 02A4 FE54: LI R5,>0002 0205 0002 FE58: LI R11,>FE6C 020B FE6C FE5C: B @>4080 0460 4080 FE60: NOP 1000 FE62: SBZ 0 1E00 FE64: LI R0,>01C0 0200 01C0 FE68: BLWP @>2118 0420 2118 FE6C: LI R0,>071C 0200 071C FE70: BLWP @>2118 0420 2118 FE74: LI R0,>030E 0200 030E FE78: BLWP @>2118 0420 2118 FE7C: LI R0,>0401 0200 0401 FE80: BLWP @>2118 0420 2118 FE84: LI R0,>0040 0200 0040 FE88: MOVB R0,@>8C02 D800 8C02 FE8C: SWPB R0 06C0 FE8E: MOVB R0,@>8C02 D800 8C02 FE92: LI R1,>2020 0201 2020 FE96: LI R2,>0300 0202 0300 FE9A: MOVB R1,@>8C00 D801 8C00 FE9E: DEC R2 0602 FEA0: JNE >FE9A 16FC FEA2: CLR R1 04C1 FEA4: LI R2,>0080 0202 0080 FEA8: MOVB R1,@>8C00 D801 8C00 FEAC: DEC R2 0602 FEAE: JNE >FEA8 16FC FEB0: LI R1,>1C00 0201 1C00 FEB4: LI R2,>0080 0202 0080 FEB8: MOVB R1,@>8C00 D801 8C00 FEBC: DEC R2 0602 FEBE: JNE >FEB8 16FC FEC0: CLR R1 04C1 FEC2: LI R2,>0C00 0202 0C00 FEC6: MOVB R1,@>8C00 D801 8C00 FECA: DEC R2 0602 FECC: JNE >FEC6 16FC FECE: LI R0,>0900 0200 0900 FED2: MOV R0,@>834A C800 834A FED6: BLWP @>20FC 0420 20FC FEDA: DATA >0018 FEDC: LI R0,>0B00 0200 0B00 FEE0: MOV R0,@>834A C800 834A FEE4: BLWP @>20FC 0420 20FC FEE8: DATA >004A FEEA: LI R0,>01E0 0200 01E0 FEEE: BLWP @>2118 0420 2118 FEF2: LI R0,>0F80 0200 0F80 FEF6: LI R1,>FFDE 0201 FFDE FEFA: LI R2,>0020 0202 0020 FEFE: BLWP @>210C 0420 210C FF02: LI R0,>0F89 0200 0F89 FF06: MOVB @>FFE7,R1 D060 FFE7 FF0A: SRL R1,8 0981 FF0C: A R1,R0 A001 FF0E: MOV R0,@>23FC C800 23FC FF12: LI R0,>FF34 0200 FF34 FF16: LI R1,>2400 0201 2400 FF1A: LI R2,>0800 0202 0800 FF1E: MOV *R0+,*R1+ CC70 FF20: DEC R2 0602 FF22: JNE >FF1E 16FD FF24: B @>2400 0460 2400 FF28: LWPI >20BA 02E0 20BA FF2C: LI R5,>2500 0205 2500 FF30: LI R0,>0F86 0200 0F86 FF34: LI R1,>3000 0201 3000 FF38: BLWP @>2108 0420 2108 FF3C: LI R0,>0F89 0200 0F89 FF40: MOV R0,@>8356 C800 8356 FF44: BLWP @>211C 0420 211C FF48: DATA >0008 FF4A: JEQ >FFB4 1334 FF4C: LI R0,>1000 0200 1000 FF50: LI R1,>23F0 0201 23F0 FF54: LI R2,>0006 0202 0006 FF58: BLWP @>2114 0420 2114 FF5C: MOV @>23F4,*R5+ CD60 23F4 FF60: MOV @>23F2,R2 C0A0 23F2 FF64: MOV @>23F4,R1 C060 23F4 FF68: LI R0,>1006 0200 1006 FF6C: BLWP @>2114 0420 2114 FF70: MOV @>23FC,R0 C020 23FC FF74: BLWP @>2110 0420 2110 FF78: AI R1,>0100 0221 0100 FF7C: BLWP @>2108 0420 2108 FF80: MOV @>23F0,@>23F0 C820 23F0 23F0 FF86: JNE >FF30 16D4 FF88: LWPI >83E0 02E0 83E0 FF8C: MOV @>8370,R4 C120 8370 FF90: LI R3,>8300 0203 8300 FF94: LI R2,>00A0 0202 00A0 FF98: CLR *R3+ 04F3 FF9A: DECT R2 0642 FF9C: JNE >FF98 16FD FF9E: MOV R4,@>8370 C804 8370 FFA2: LI R4,>9E7E 0204 9E7E FFA6: MOV R4,@>8372 C804 8372 FFAA: LWPI >20BA 02E0 20BA FFAE: MOV @>2500,R0 C020 2500 FFB2: B *R0 0450 FFB4: MOVB @>23F8,@>9800 D820 23F8 9800 FFBA: NOP 1000 FFBC: MOVB @>23F9,@>9800 D820 23F9 9800 FFC2: BLWP @>0000 0420 0000 Is this the original version of Systex? It looks like it. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted September 18, 2014 Share Posted September 18, 2014 Certainly, I’d be happy with another loader program. But I am more interested in solving this puzzle. This was a cool loader. And if something is wrong with it with today’s emulation software and updated hardware, I’d like to know why. At the moment, I suspect the disk transferring software… especially since it seems to be behaving the same in MESS, on the NanoPEB, and on real hardware. The only thing common there is the software used to transfer the floppy. The disk transfer doesn't appear to be at fault. The disassembled routine is not garbled. It is most likely your friend directly accessed the Myarc FDC's emulated CALL INIT (CALL ILR) from his loader. I base this on the direct branch into the card at CRU 0x1100 and the method employed to return to the loader. This utility would load support routines into low memory, similar to those found in the EA Cart. FE4C: LI R12,>1100 020C 1100 FE50: SBO 0 1D00 FE52: STWP R4 02A4 FE54: LI R5,>0002 0205 0002 FE58: LI R11,>FE6C 020B FE6C FE5C: B @>4080 0460 4080 A quick comparison of this loader's source to the SmartProgrammer E/A Utility reference gives us another clue: the BLWP vectors match up to the expected utilities with one caveat: each utility location is offset by 4 bytes. I don't have my other resources handy to determine if this is (1) a SmartProgrammer documentation error or (2) your controller's DSR EPROM at the time did not match the documented standard. The loader will -not- function with the standard Extended BASIC routines. And if the latter is correct, it may only work with the specific card it was programmed for. I suggest you continue with a different loader code. There are few out there that were written nearly in the same manner and can be called from XB, so you could combine your XB code with a new loader. Quote Link to comment Share on other sites More sharing options...
dphirschler Posted May 22, 2016 Author Share Posted May 22, 2016 So I am ready to tackle this problem again. I am convinced my friend and I were using this code that used either the corcomp hardware or the myarc. I'd like help changing this loader code. I haven't worked with this ti stuff in a long time. Darryl 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.