Jump to content

Tim Hamilton

New Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

16 Good

About Tim Hamilton

  • Rank
    Space Invader

Profile Information

  • Interests
    Physics & astronomy, retrocomputing

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm learning assembly, and in reading the Editor/Assembler manual for the DIVision statement, I was surprised to find that if the divisor and dividend are equal, DIV doesn't return 1 with remainder=0. It sets the overflow bit. I assume that the DIV statement works by repeated subtractions. So I would naively expect that, say, 5/5 would involve subtracting 5-5, incrementing the quotient to 1, and checking the remainder (0). Why does it cause an overflow, instead? (I don't know if this is really appropriate for the Development sub-forum, but I thought it might be because of getting into the nuts and bolts of the CPU. Apologies if it's in the wrong place.) Related: I have found an error in the E/A manual for the AB command that isn't listed in the Erratum. Is anybody compiling a list of additional E/A manual errata here?
  2. OK, that makes sense to me, even with what little I know so far. Let me see if I understand: So as assembler directives, DEF, REF, and EQU don't produce words in the object file, but the DATA, TEXT, and BYTE statements do, and because they preceded START, the computer tried to execute these as machine code. So what I should do is either move my DATA, TEXT, and BYTE statements to near the end, or start the program something like this: Would that be a good structure? What approach do you prefer for your own code? I see now why I was getting the program to work fine if I entered it in E/A directly: I was choosing option 3: Load and Run, rather than option 5. But why do (improperly structured) programs work differently between these two options? Thanks a whole lot for the help, @ralphb, and the rest of y'all, too. This has taught me a lot about assembly language, in addition to fixing my mistake. Thanks especially for creating the xdt99 tools. Those have made it much easier to create my programs, so I can use a modern editor. Thanks also to @Asmusr for creating js99er, which I'm using for all of my TI work until I get my actual TI's video glitch fixed.
  3. I'm composing on Emacs running on a Mac, then assembling it with ralphb's xdt99 cross-assembler suite (I use the Emacs assembly environment that comes with xdt99). The specific commands I use to assemble it ("test11.asm" in this case) and then add to the working disk are: Then on js99er, I load the E/A disk A into disk drive 1 and the working disk into disk drive 2. In E/A, I select option 5: Run Program File, and the program runs automatically on loading.
  4. OK, thanks for the idea. I think there is a debugger in js99er; I'll have to poke around and learn how to use it. But your alternative plan is doable, too.
  5. Hey, it worked! Thanks, Stuart. Why would this be the case? Here's the source code for this version: And it works using either or Now: Why would it work when it's put at the end?
  6. Well, here's something funny—I tried out your trick, and it gave the same bug! In keeping with the minimal version I've pared it down to, I made the changes suggested by ralphb above (LIMI 0 and JMP $), and I set the message to '.X' this way: Result is again a blank screen. If I enter this directly in the emulated Editor/Assembler program in js99er.net, it runs just fine. I have produced a listing from both the version I entered into E/A and from the version I assembled with xas99.py, and as far as I can tell, they're identical. (One question on listings, though: what do 'r' and 'e' mean when appended machine code words? In E/A's listing, 'r' corresponds to a single quote, and there's nothing corresponding to the 'e'.)
  7. OK, Ralph, I've done that. Let me post the new version to make sure that I put the LIMI 0 in exactly the right place, since I haven't used it before: So the JMP $ sets up a single-instruction loop, I see. That looks much better than Molesworth's trick (DECT R11) that I had ended with. The result is the same as the buggy version earlier: When I use the string 'X.', it prints to the screen. When I use '.X', the screen goes blank.
  8. On the odd number of bytes in the string: In working up a minimal buggy example to post here, I found that it still occurs with an even number. In the two examples I posted above, I used the strings 'X.' (fine) and '.X' (buggy). I'll try your suggestion of using the BYTE to insert a period. That's a really clever idea. If we can't find what's causing the bug, at least I could work around it with this.
  9. Hi, Asmusr, Thanks for the suggestion. I've now posted the list file in my first reply above. It shows the correct bytes for the ASCII. When I reorder the characters in the string ('X.' vs. '.X'), the bytes are reordered properly, and I can see no other differences. I'm not experienced enough to know what else I can catch in the list file, but I can produce a working version and a buggy version, and the list files show that the only difference between them is the order of the bytes in that string. Is that a good way to use the list file for debugging?
  10. There's another interesting behavior I found with this. In the full version of the program, I am using VSBW to fill the screen with asterisks before I use VMBW to write the string to the display. When the buggy string is present, it clears the asterisks from the screen entirely. Here's a version that shows this behavior, where the string is '.X'. Nothing shows up on the screen by the time it freezes output. When I reverse the string to 'X.', it does what I expect: it displays 'X.' on a background of asterisks. (I'll note that as I'm learning more assembly, I've realized that I should have used more EQU's and fewer DATA statements to save space, so this is not the most efficient program.)
  11. OK, I've pared it down to a minimal program that shows the bug, and I have found that the placement of the period makes a difference, so I am posting two versions. test7.asm prints the string 'X.' without a problem. test8.asm should print the string '.X', but the screen remains blank. Here is test7.asm first. It's my first time posting code, and I don't know the right formatting in this window, so I'm quoting it. Now I'll post test8.asm: The DECT R11 near the end is something I got from Molesworth's Introduction to Assembly Language for the TI Home Computer, for freezing screen output in his tutorial programs. The list output for the two is identical, except for the order of the two bytes in the string. I've done a diff to confirm, but I'll post both here, in case there's something subtle I missed. test7.lst: And for test8.asm:
  12. Hi, all, I'm practicing assembly language with the Editor/Assembler, using the xdt99 cross-assembler with Emacs on a Mac and running it on js99er.net for the emulator. So far, everything has gone very smoothly...but this one weird bug: If I have a period in a TEXT directive string, I get unpredictable VDP results when I display it using VMBW. For example, I printed my name to the screen (along with some other text), with the text set as: MSG2 TEXT 'Timothy S. Hamilton' The other strings printed to the screen just fine with VMBW, but this one came up with the last byte displayed as a space: Timothy S. Hamilto Thinking I'd miscounted the bytes by one, I tried other combinations of characters. It turned out it was the period causing the problem. Later, after putting it back in, sending this same string to VMBW caused the screen to flash with colored noise. Another time, it made it go blank, with a solid color on the border. [Edit: It was another version of the string that caused the flashing, with one or two characters changed, but with the period still there. I haven't tried replicating that particular behavior since then.] I thought it might be some glitch in encoding the period, so I opened up my assembly source file in E/A directly and put the period in there. It displayed the period just fine. Does anybody have a suggestion as to what might be causing this and how to get around it?
  13. I think some of y'all might be interested in this book, Retrogame Archeology, by John Aycock, about the early days of home video game development. It's not just a history, though; he goes into the programming and machine-level details and tricks early programmers used, even down to how to do copy protection on cassette tapes. He covers several topics that developers here would appreciate—dealing with limited memory and slow I/O, generating procedures, and so on. It's largely concerned with 8-bit machines, but he does have some examples from the TI. It's from Springer, which is an academic publisher, and so it's...well, it's pricey. $85 just for the e-book version! I'm fortunate to have access to it as faculty on my campus.
  14. Great! Done, and thanks a lot for the quick response.
  15. @matthew180, I've been getting my old TI system back up and running, and I would love to get one of your F18A Mk. 2's. I've read a lot of the praise from people here on the original version. Is it still possible to put my name on the waiting list, and if so, where would I do so? I saw your web page and the comments there, but I didn't know if that was an "official" waiting list or not.
×
×
  • Create New...