Count9929A Posted January 25, 2018 Share Posted January 25, 2018 Hello, I am a newbe of assembly programming on TI. I recently bought a mini memory with LBLA on cassette. The cart seems to work well, even if the battery has not been changed. Also the LBLA cassette is fine, it loads the LBLA and I can start entering a new program with the NEW command. However, the OLD does not work properly: at launch, it display very briefly the number of unresolved references (it's so quick that I cannot read the number) and then it behaves exactly as NEW, i.e., the symbol table is empty and the location counter is >7F00. using EasyBug I can check that the old symbol table is still in memory, but the LBLA thinks it's empty. What could be wrong? Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 25, 2018 Share Posted January 25, 2018 If you type in a few lines of code after NEW, exit the LBLA, then come back to it with OLD, is your code preserved or is it corrupted? Quote Link to comment Share on other sites More sharing options...
Count9929A Posted January 25, 2018 Author Share Posted January 25, 2018 I am almost sure that the code is preserved. i will double check because I have few experience with 9900 opcodes, but I am pretty confident. As I said, also the content of the symbol table is preserved. But the LBLA does not "remember" that the entries are valid and does not remember the previous location counter. Quote Link to comment Share on other sites More sharing options...
Stuart Posted January 26, 2018 Share Posted January 26, 2018 To confirm the way it should work: do NEW and it should start assembling at >7D00. Enter a few instructions and labels, then SYM to check the symbol table, then END to return to the MiniMem screen. Then OLD and it will briefly flash a message about the number of unresolved references (it's not meant to do this - it's just the way it clears the screen buffer) and then show the address after the last instruction entered (with previous instructions being retained). If you then do SYM it should show the symbol table from the previous session. If you're losing the symbol table and the location counter is >7F00 - what address range are you assembling at? Wondering if you could be overwriting some of the LBLA data? What happens if you assemble just a few instructions at >7D00? You're NOT powering off between the NEW and OLD sessions (just in case the cartridge battery is flat and you're losing some data from the RAM)? Also note that there is a bug in the LBLA which can affect instructions with two symbolic addressing operands. See http://www.stuartconner.me.uk/ti/ti.htm#minimem_lbla_bug for the details and a fix. Quote Link to comment Share on other sites More sharing options...
Count9929A Posted January 26, 2018 Author Share Posted January 26, 2018 I checked again proceeding as Stuart described, and replicating everything I did in Classic99. Classic99 did exactly what Stuart expected (which was also my understanding), the real thing not: symbol table empty and location counter back to >7D00 (in my first post I wrongly stated that the location counter was set to >7F00, my mistake). Never powered off the TI. Also, I tried loading LBLA from both side of the tape, and nothing changed. This suggest a bug in the cart. I have to say that the first few times that I tried the cart, it didn't work well. The memory was unreliable (i.e. in EasyBug I modified a location but the read value was different). However after a couple of re-trying, everything else I tried is ok (apart from this LBLA bug): saving BASIC program in MINIMEM (once also in EXPMEM2), the LINES demo, the NEW command and also the Mini-writer program (even though I only tested basic usage because I don't know how to use it). Both BASIC and ASM programs are retained also after powering off and removing the cart from the console. It seems strange that a hardware bug affect so selectively a functionality. I have tried to compare the first few opcodes of the OLD command in the real TI with that in Classic99. The only difference is in an address inside the code: >718e in Classic99 while >713E in the minimem. Content of those addresses are different. But for now I am unable to understand more of how OLD works Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 26, 2018 Share Posted January 26, 2018 I checked again proceeding as Stuart described, and replicating everything I did in Classic99. Classic99 did exactly what Stuart expected (which was also my understanding), the real thing not: symbol table empty and location counter back to >7D00 (in my first post I wrongly stated that the location counter was set to >7F00, my mistake). Never powered off the TI. This is what you also see in MAME. I don't quite understand the effect of OLD either, because you start at 7D00 again, just like NEW. mame64 ti99_4a -cart minimem Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 26, 2018 Share Posted January 26, 2018 Here is the difference between OLD and NEW OLD - 71AC NEW - 71A6 NEW 71A6 04E0 clr @>718e CLEAR FLAG AT 718E 718E 71AA 1002 jmp >71b0 OLD 71AC 0720 seto @>718e SET FLAG AT 718E 718E 71B0 C80B mov R11,@>7182 CONTINUE HERE EITHER WAY 7182 71B4 02E0 lwpi >7138 7138 ... 7226 0560 inv @>718e TEST FLAG AT 718E 718E 722A 1307 jeq >723a SKIP AHEAD FOR 'OLD' 722C 0200 li R0,>7d00 SET WORK ADDRESS TO >7D00 7D00 7230 04E0 clr @>7190 CLEAR SYMBOL COUNT 7190 7234 04E0 clr @>718e CLEAR FLAG FOR NEW 718E 7238 C240 mov R0,R9 SAVE WORK ADDRESS 723A 0420 blwp @>79d2 CONTINUE HERE EITHER WAY 79D2 The workspace is in the MiniMemory, so if it's being preserved correctly the skipped initialization shouldn't hurt anything. On hardware I'd suggest to try replacing the battery in case the reset is corrupting something. I can't explain MAME - is there a memory difference in the MiniMemory RAM after you reset? I've got a supercap in my MiniMemory at home, I'll see if I can find a way to load the LBLA and try it. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 27, 2018 Share Posted January 27, 2018 (edited) The difference is here: The words at 71A8, 71AE, and 7228 are all 713E. The rest is the same (including the value 718E at 7236). Do we have a broken LBLA copy? 71A6: CLR @>713E 04E0 713E : 71A6 71AA: JMP >71B0 1002 : 71AA 71AC: SETO @>713E 0720 713E : 71AC 71B0: MOV R11,@>7182 C80B 7182 : 71B0 71B4: LWPI >7138 02E0 7138 : 71B4 ... 7226: INV @>713E 0560 713E : 7226 722A: JEQ >723A 1307 : 722A 722C: LI R0,>7D00 0200 7D00 : 722C 7230: CLR @>7190 04E0 7190 : 7230 7234: CLR @>718E 04E0 718E : 7234 7238: MOV R0,R9 C240 : 7238 723A: BLWP @>79D2 0420 79D2 : 723A Edited January 27, 2018 by mizapf Quote Link to comment Share on other sites More sharing options...
Count9929A Posted January 27, 2018 Author Share Posted January 27, 2018 The difference is here: The words at 71A8, 71AE, and 7228 are all 713E. The rest is the same (including the value 718E at 7236). Do we have a broken LBLA copy? 71A6: CLR @>713E 04E0 713E : 71A6 71AA: JMP >71B0 1002 : 71AA 71AC: SETO @>713E 0720 713E : 71AC 71B0: MOV R11,@>7182 C80B 7182 : 71B0 71B4: LWPI >7138 02E0 7138 : 71B4 ... 7226: INV @>713E 0560 713E : 7226 722A: JEQ >723A 1307 : 722A 722C: LI R0,>7D00 0200 7D00 : 722C 7230: CLR @>7190 04E0 7190 : 7230 7234: CLR @>718E 04E0 718E : 7234 7238: MOV R0,R9 C240 : 7238 723A: BLWP @>79D2 0420 79D2 : 723A I have 713E at 71A8 and 71AE too. I have to check the words at 7228 and 7236. My LBLA tape is an original one, and seems in very good conditions. Also, I am almost sure that I have tried both sides. In any case, I have a question. In my poor understanding of TI-ASM beginner, why does Mizapf code don't work properly? Since the flag address is the same in both the places where it is set (71A8, 71AE) and the place where it is tested (7228) the Old command should skip, as intended, the "reset-case". I can't see the purpose of the instruction at >7234. Am I wrong? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 27, 2018 Share Posted January 27, 2018 Here is a longer piece, filling the gap. 71A6: CLR @>713E 04E0 713E 71AA: JMP >71B0 1002 71AC: SETO @>713E 0720 713E 71B0: MOV R11,@>7182 C80B 7182 71B4: LWPI >7138 02E0 7138 71B8: LI R1,>7944 0201 7944 71BC: MOV *R1+,R0 C031 71BE: JLT >71C6 1103 71C0: BLWP @>6034 0420 6034 71C4: JMP >71BC 10FB 71C6: MOVB @>7947,@>83D4 D820 7947 83D4 71CC: LI R0,>08F8 0200 08F8 71D0: LI R1,>7E7E 0201 7E7E 71D4: LI R2,>0008 0202 0008 71D8: BLWP @>6024 0420 6024 71DC: INC R0 0580 71DE: DEC R2 0602 71E0: JNE >71D8 16FB 71E2: LI R0,>1000 0200 1000 71E6: MOV R0,@>7186 C800 7186 71EA: LI R1,>2020 0201 2020 71EE: LI R2,>3580 0202 3580 71F2: BLWP @>6024 0420 6024 71F6: JMP >71FC 1002 71F8: MOVB R1,@>8C00 D801 8C00 71FC: DEC R2 0602 71FE: JNE >71F8 16FC 7200: LI R3,>0260 0203 0260 7204: LI R1,>0A00 0201 0A00 7208: BL @>7ACE 06A0 7ACE 720C: LI R3,>0199 0203 0199 7210: LWPI >7118 02E0 7118 7214: BLWP @>79D2 0420 79D2 7218: DATA >7992 721A: MOV @>793E,@>713E C820 793E 713E 7220: BLWP @>79D2 0420 79D2 7224: DATA >79A9 7226: INV @>713E 0560 713E 722A: JEQ >723A 1307 722C: LI R0,>7D00 0200 7D00 7230: CLR @>7190 04E0 7190 7234: CLR @>718E 04E0 718E 7238: MOV R0,R9 C240 723A: BLWP @>79D2 0420 79D2 723E: DATA >7972 At address 71B4, the workspace is set to address 7138. This means that address 713E is actually R3 in that workspace. However, R3 is used in that part of the code, e.g.g at address 7200. This operation overwrites the contents of 713E. When you use OLD, the entry point is at 71AC, setting 713E to FFFF. Line 7226 produces the one's complement, which is 0000, and compares it to 0. This yields EQ=1, which should make the JEQ jump to 723A. However, since R3 is overwritten by something like 0260, inverting it does not result in 0000, which is the same effect as if 713E was set to 0000 and then inverted to FFFF. Thus, NEW=OLD. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 27, 2018 Share Posted January 27, 2018 I don't have an original LBLA, these files were provided to me years ago. It's not impossible that there was a bug and someone patched it -- but I don't remember ever having a problem back in the day. I learned assembly on the MiniMemory with the LBLA. (Also possible, I guess, more than one release...) Maybe we can get someone else to load the LBLA from tape and check those addresses in MiniMemory as a tie-breaker? Quote Link to comment Share on other sites More sharing options...
Stuart Posted January 27, 2018 Share Posted January 27, 2018 I've got an original which I disassembled years ago to port to my TM990 system. It used the value >718E, which is used when entering a program to store the number of unresolved references. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 27, 2018 Share Posted January 27, 2018 Here is a longer piece, filling the gap. <snip> At address 71B4, the workspace is set to address 7138. This means that address 713E is actually R3 in that workspace. However, R3 is used in that part of the code, e.g.g at address 7200. This operation overwrites the contents of 713E. When you use OLD, the entry point is at 71AC, setting 713E to FFFF. Line 7226 produces the one's complement, which is 0000, and compares it to 0. This yields EQ=1, which should make the JEQ jump to 723A. However, since R3 is overwritten by something like 0260, inverting it does not result in 0000, which is the same effect as if 713E was set to 0000 and then inverted to FFFF. Thus, NEW=OLD. ...but at >721A, >713E (R3 of WS = >7138) gets overwritten with whatever is at >793E, three instructions before the INV. ...lee Quote Link to comment Share on other sites More sharing options...
Count9929A Posted January 27, 2018 Author Share Posted January 27, 2018 @mizapf: thanks for the explanation, now it's clear! The 9900 is really a nice little strange beast! I've got an original which I disassembled years ago to port to my TM990 system. It used the value >718E, which is used when entering a program to store the number of unresolved references. So this confirms that mizapf and I have buggy copies. It's unlikely that they both are result of tape corruption. More probably TI issued a batch of tapes with a buggy version of LBLA 1 Quote Link to comment Share on other sites More sharing options...
Stuart Posted January 27, 2018 Share Posted January 27, 2018 So this confirms that mizapf and I have buggy copies. It's unlikely that they both are result of tape corruption. More probably TI issued a batch of tapes with a buggy version of LBLA So can you patch those addresses in Easy Bug, save it back to a new tape, and see if it then works as it should? (Although there may of course be differences elsewhere in the code.) There's a .wav file of the 'good' version at http://www.stuartconner.me.uk/ti/cassette_wavs/lbla.wav if you have the means of playing that into your TI. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 27, 2018 Share Posted January 27, 2018 (edited) ...but at >721A, >713E (R3 of WS = >7138) gets overwritten with whatever is at >793E, three instructions before the INV. right, there is another point of overwriting. In the MAME debugger, breakpoint at 7226, I found the value 0278 at address 713E. I got the copy of the LBLA from WHTech; I do not have a genuine copy. It would indeed be interesting to find out if there were a batch of broken LBLA. Hopefully there is someone with a real tape who can create a WAV from it. Edit: Just saw your message. I tried to load it in MAME, but I'm getting a NO DATA FOUND after some time. I'll try to run some filters from Audacity over it. @Count9929A: We may have downloaded the same copy. Still, it is very unlikely that this is a result of a corrupted tape recording. Data records on the tape are always backed up with an identical copy (thus it always sounds like Beeeee ... AA-BB-CC-DD- ...), and the changes affect a single value at different locations. Also, I find it high interesting that the difference is between 713E and 718E, which seems as if someone typed in those values from a bad printout, reading a 3 instead of an 8. Edited January 28, 2018 by mizapf Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 28, 2018 Share Posted January 28, 2018 Also, I find it high interesting that the difference is between 713E and 718E, which seems as if someone typed in those values from a bad printout, reading a 3 instead of an 8. That's sort of what crossed my mind when I saw it, too, it's not a single bit error but makes sense as a human read error. We'll probably never know. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 28, 2018 Share Posted January 28, 2018 I'll check my LBLA cassette on real hardware today and see what I get. I have to correct the symbolic addressing bug anyway. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 28, 2018 Share Posted January 28, 2018 (edited) @Stuart: I'm pretty sure that the WAV file behind that link does have the 713E bug: I managed to read it in MAME (need to resample to 44100 Hz); I found the 713E value I used Sven Dyroff's standalone cassette reader tool that he developed some years ago: michael@capella:~/mame/ti/andere/sven> ./load ~/mame/cassettes/lbla_good.wav Channels: 1 Sampling: 22050 Hz Framesize: 2 Bytes Sample: 16 Bits (Bytes per Second: 44100) ======== New file with 65 blocks ========================================================== Channel 1, Block 1 of 65: A p....Z..............................}.................N.......: 70 00 10 00 a5 5a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7f b2 7f e8 7d 9e 00 00 00 00 00 00 00 00 00 00 10 01 06 1a 11 00 4e dc 00 04 10 0e 00 01 3a 20 Channel 1, Block 2 of 65: A 99/4 AS 20 20 20 20 20 20 39 39 2f 34 20 41 53 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 Channel 1, Block 3 of 65: A 0038DSK1.......`......p...........`t... |...p.b...}... 20 20 20 20 20 20 20 20 20 20 30 30 33 38 44 53 4b 31 2e 00 00 00 00 00 85 60 c0 00 10 01 00 00 70 8f 00 09 00 05 00 08 00 00 00 00 60 74 10 01 83 20 7c de c4 00 70 d8 62 fe c0 00 7d 9e 00 00 Channel 1, Block 4 of 65: A ..................`...........p;.O.:..|.o....:..c.cN..p.b....... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 9c 00 00 00 00 00 00 00 00 00 00 70 3b 00 4f 00 3a 00 c0 7c d6 6f 08 7f b2 00 3a 00 00 63 80 63 4e 00 00 70 b8 62 d6 c0 00 00 00 00 00 Channel 1, Block 5 of 65: A ..........................................{...}.r.`............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 e0 ff ff 00 00 ff dd 00 0d 00 03 00 2e 7b d2 00 00 7d 00 72 e4 60 9c 0d 00 00 00 ff ff 00 00 0a 0b 1f 20 Channel 1, Block 6 of 65: A ...yr..........z.z.z.q.t. . 20 00 03 b9 79 72 01 00 00 df 00 00 00 00 00 00 7a f4 7a 16 7a fc 71 18 74 f2 20 00 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 Channel 1, Block 7 of 65: A ..`....P................................q>... q>..q...q8..yD 20 20 20 20 00 00 60 9c 03 98 10 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 04 e0 71 3e 10 02 07 20 71 3e c8 0b 71 82 02 e0 71 38 02 01 79 44 In the last block shown here (7 of 65), after the 00 values, there is 04e0 713e, which means CLR @>713E. Please try to read that file on your system. Edited January 28, 2018 by mizapf Quote Link to comment Share on other sites More sharing options...
Stuart Posted January 28, 2018 Share Posted January 28, 2018 @Stuart: I'm pretty sure that the WAV file behind that link does have the 713E bug: Hmmm ... that's very strange. I can't test the .wav easily without getting lots of things out of cupboards and soldering up an audio cable. All the LBLA listings I have use the >718E value. I'm starting to wonder if I was actually given that .wav file by someone else, and they had a dodgy tape ... Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 28, 2018 Share Posted January 28, 2018 I have confirmed the bug with my original LBLA tape on real hardware. All the 3 locations mentioned above contain >713E and OLD indeed wipes the symbol table but preserves the program starting at >7D00 although it does not remember the last address entered and always starts at >7D00. I'm starting to think that this is a widespread issue and I wonder why no one brought it forth before... So I fixed the addresses in Easy Bug, saved the whole thing back to tape then tried again: this time OLD behaved as it should with the symbol table preserved and the program counter picking up where it left off. Easy fix I suppose 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 28, 2018 Share Posted January 28, 2018 (edited) It seems as if we have a buggy original LBLA, and possibly another version that was patched by someone and distributed. @Vorticon: Do you have the patched version as a WAV file? I'd say we should quickly upload that patched version (as lbla_patched.wav, the other being lbla_orig.wav) to WHTech. I could save it from MAME as well, it produces a square wave output, however, but this should be working on the real hardware as well. I can upload to WHTech. Edited January 28, 2018 by mizapf Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 29, 2018 Share Posted January 29, 2018 What is the best way to convert to wav format? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 29, 2018 Share Posted January 29, 2018 You said you have a real tape - then you could record the tape with your PC via your sound card. Or this way: How do I save the fixed LBLA? S7000 TO 7FFF? Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 29, 2018 Share Posted January 29, 2018 I'll give it a shot later today. And yes that's how you save the LBLA. 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.