Jump to content

ralphb

Members
  • Content Count

    702
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by ralphb

  1. If this is a stack trace, could you please post the entire stack? And if it's regular error, could also post the erroneous line, please? Edit: Even better, could you perhaps PM me the file with the error?
  2. To be honest, both plugins need some work. I noticed that the Emacs mode has problems resolving symbols, possibly because I never added colon labels to it. The IntelliJ plugin needs to updated for the latest version as well, and also to include recent changes. Which IDEA version are you using? Oh, and a video would be awesome! I hate making videos. 🙂
  3. I've released a new version of xdt99, ported to Python 3. Please uninstall Python 2 before installing Python 3. You require version 3.6 or higher. Major new features are the linker and support for TMS9995 for xas99, label-based programs for xbas99, and syntax selection for xdg99. Please see the release notes for some incompatible changes. I also revised and extended the Tutorial and the Windows Guide. I recommend both guides to all beginners and intermediate users as well as all developers who have shied away from the command line so far. As usual, please post errors or requests here, or over at the project's bug tracker (requires GitHub user). Happy developing! 😃
  4. The same is true for xdt99, in case you prefer the command line.
  5. ralphb

    SDD 99

    No, I'm still working on it, and I don't really want to predict when it is ready -- my estimates have been way off in the past. I haven't thought about prices yet, but probably somewhere between 50 and 100 Euros.
  6. Could you try 19.10? I got a build error when I tried to build on that release (but didn't analyze it).
  7. The problem with -w/-q is that it disables all warnings. Would it help if I limit the output for unused constants to, say, 10 symbols and then "(more)"?
  8. From the top of my head, try adding -w. In the new version, this will be -q for quiet.
  9. Oh, but then my description of "PIX <gas>, <gad>" is not correct either. Instead of <gad>, should it be <wa> or <imm>? Also, it has just occurred to me that we finally found a use for DXOP (which is supported by xas99)! 🙂
  10. I'm in the process of adding the 9995 instructions MPYS, DIVS, LST, and LWP to xas99. Reading the 9995 datasheet, however, I'm at a loss what the second arguments for MPYS and DIVS are -- if there are any. The description might be interpreted that the destination is always R0 (and R1). Is that correct? (That would be an unusually restrictive design, but I guess they ran out of short opcodes.) Once I updated the documentation, I can release xas99, xga99, and xbas99. 🎇
  11. And for what it's worth, xas99 also has a SAVE directive (for E/A 5 images and binaries) that will create one file each, containing the specified address range (missing addresses are set to 0). For example, file sample.a99 save >2000, >4000 ; saves >2000->3fff save >8300, >8400 ; saves >8300->83ff aorg >8300 bytes 1, 2, 3, 4 ... aorg >2000 limi 0 ... will create two files sample_2000.bin and sample_8300.bin with 8192 and 256 bytes, resp. (NOTE: This is the behavior of the upcoming version, the current xas99 also has SAVE, but might yield a different number of files.)
  12. ralphb

    SDD 99

    My goal is to offer Geneve compatibilty, but I have no idea what exactly that entails. While I do have a Geneve, I haven't powered it up yet, and want to wait until the SDD is mostly done. On the positive side, the interface for TI and Geneve is the same (PEB). Also note that the SDD logic is mostly in its firmware, so required changes could hopefully be programmed. Regarding memory, AFAIR the Geneve has more than 64K RAM, which suggests that it's using banked memory, like the SAMS. If that is the case, and the banking isn't implemented as sloppily* as the address decoder on the TI 99, I might be able to add the SDD memory in higher banks than the Geneve memory. (* I really hate how the mapping of >8000->9FFF address range was designed for the TI, where we have 4 peripherals with just a few significant addresses, but the entire range is used up.) Is there any Geneve architecture overview you can recommend? I didn't find anything on WHTech when I looked some while ago. Wifi serves two purposes: Connecting to the (file) server, and doing HTTP requests (some subset of REST). For the server, it's possible to add a "Run" call that would run any (non-TI) program on the server. For the server, any computer with network capabilities running Python will suffice, e.g., PC, Mac, RaspberryPi, ... I probably won't allow users to open sockets to arbitrary destinations, and recommend to use REST instead.
  13. I think this discussion makes no sense any more. I absolutely know what happens in the loader. That's not the point. And Lee, by "breaking" the loader you probably mean that linking must not yield a different result as the loader. Rest assured that I implemented that. But there is also a "safe" (a/k/a wrong, broken, unholy) mode that resolves conflicts. And I made my mind up how that should work.
  14. As was talking generally about linking, not loading using E/A.
  15. ... unless it's a second RORG in a program unit. The point of relocatable code is that it can be moved around. The E/A loader treats initial RORGs like offsets, but this is a choice. And regarding conflicts, it's certainly not a likely scenario. But imagine you're linking someone else's sort routine, and for some reason that uses some RORG that conflicts with some AORG area you defined -- why wouldn't you want to move the conflicting relocatable code out of the way instead of having a broken program? No, it doesn't. For E/A, there is no way I know of. For xas99, you can rebase relocatable code using the -a <base addr> option.
  16. So linking two files yields something different than COPYing them? I mean, I'm fine with that, I was just looking for a motivation. Also, about resolving conflicts between AORG and RORG: If this happens within one program unit, sure, blame the developer. But I think it's a valid conflict scenario for linking two files, potentially by two different authors. Why would I need to disassemble the object file to spot any potential conflicts? But anyway, my question was how to resolve something like this: AORG >10 DATA 1,1 linked with RORG >E DATA 2,2 Would the resulting program with conflicts resolved be equivalent to AORG >10 DATA 1,1 RORG >14 * MOVE AS LITTLE AS REQUIRED DATA 2,2 or rather AORG >10 DATA 1,1 RORG >22 * KEEP THE RORG "DISTANCE" TO OTHER SEGMENTS The answer depends on what that offset would be used for. Finally, note that such conflicts only manifest when linking into binary formats such as cartridge or E/A 5 image.
  17. Yes, I'm talking about the loader of E/A 3, which basically does the linking. I'm not preventing the use of RORG with address in sources, but I wonder (a) if I should follow the approach of E/A and waste(?) a lot of space and (b) if and how I should resolve conflicts. Another example: RORG >1000 DATA 1 and AORG >1000 DATA -1 When loading both programs in E/A 3, one program will overwrite the other, as the loader doesn't check for address conflicts between absolute and relocatable segments. And alas, so far no one could name a use for RORG <addr>, so we don't know if the offset really is waste.
  18. Oh wow, that's interesting! Thanks to all who responded. The Geneve is a good point I'll have to check. But other than that, no one is really using RORG with address -- I'll change the xas99 linker accordingly. And please keep in mind that what I stated above only applies to loading multiple object codes (with E/A #3). Using multiple RORGs with address within one program unit (i.e., everything you assemble in one go) will not be additive. For example, RORG >1000 DATA 1 RORG >2000 DATA 2 places data at >B000 and >C000, but splitting this into two programs RORG >1000 DATA 1 and RORG >2000 DATA 2 will place it >B000 and >D002. Go figure.
  19. Pardon my ignorance here, but can you invoke the xdt99 tools from the TI 99?
  20. Beery, yes, this can run on a RPi. In fact, it can run on any platform where Python is available, and that includes all the RPis. But xdt99 and core Python is less than 5 MB combined, so creating a 1 GB image just to have xdt99 seems a little wasteful. I get your point, however, and I'll think about easing installation.
  21. I have a question for all assembly developers, irrespective of particular assembler used: In your programs, have you ever used the RORG directive with an address, like RORG >1000? If so, what was your motivation for doing so, e.g., did you want to reserve memory at the beginning of the program, or did you want the listing to show a particular address range, or did you want to use the address the program will be placed at later, or ...? I'm asking this question because I'm unsure about one detail regarding the new xas99 linker. The E/A loader, on the other hand, is quite primitive. It will load any relocatable program (i.e., one using RORG) relative to memory address >A000, which means that any RORG address >6000 or higher cannot be loaded by E/A. When loading two relocatable programs, the second program will be loaded relative to the end of the first program. Thus, if you load multiple programs with RORG >1000, you'll get a lot of unused space. For compatibility, the xas99 linker uses the same logic. But there is one special case, where a RORG programs conflicts with an AORG program, which the loader ignores. For xas99, I'm thinking of two possible solutions to resolve conflicts, and for deciding on one solution I would need to know some opinions on why one would use RORG with address -- I never have used this construct. (Programs can have both RORG and AORG parts, but I dont't want to complicate things too much here.)
  22. Well, you could also have a DEF V12345 in your source, and that will create a 5/6 tag with that version symbol. Or try putting a comment after the : line, although I'm not sure if all tools can deal with that (the new xas99 linker won't). Modifying the : line itself is probably safer if you do it for the final object code.
  23. Yes, it's just a nonsensical example program, and the assembler could optimize a lot here. But this is the actual output of the Editor/Assembler (and xas99), and with that you can derive the original source again. In the above case: rorg >4 bss 2 bss 1 byte 0 rorg >8 byte -1 bss 1 rorg >20 end It's just an example of what took me a while to figure out correctly ...
  24. Thanks for the correction; I'll fix it in the upcoming release. IDLE and all the other forbidden instructions are supported, but probably not that well-tested. Regarding the new release, I noticed that I commingled changes to various programs, which means that I have to release them all at once. Right now I'm busy checking a lot of edge cases. For example, look at this object code: Can you get the original assembly source from it? 00020 A0004A0006A0006B0000A0008BFF00A00097F681F 0001 7FFC9F 0002 : xdt99 xas
  25. ralphb

    SDD 99

    Yes, that would be possible, at least with the sidecar -- the PEB doesn't carry the LOAD* signal. Right now LOAD* is only used for the debugger. I must admit, though, that I don't see any real applications for this. After all, programs must share the same screen.
×
×
  • Create New...