Jump to content

ralphb

Members
  • Content Count

    696
  • Joined

  • Last visited

  • Days Won

    1

ralphb last won the day on May 2 2017

ralphb had the most liked content!

Community Reputation

915 Excellent

2 Followers

About ralphb

  • Rank
    Dragonstomper

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    Developers, developers, developers, developers

Recent Profile Visitors

7,733 profile views
  1. 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)"?
  2. From the top of my head, try adding -w. In the new version, this will be -q for quiet.
  3. 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)! 🙂
  4. 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. 🎇
  5. 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.)
  6. 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.
  7. 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.
  8. As was talking generally about linking, not loading using E/A.
  9. ... 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.
  10. 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.
  11. 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.
  12. 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.
  13. Pardon my ignorance here, but can you invoke the xdt99 tools from the TI 99?
  14. 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.
  15. 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.)
×
×
  • Create New...