Jump to content

mizapf

Members
  • Content Count

    4,038
  • Joined

  • Last visited

  • Days Won

    3

mizapf last won the day on August 31 2016

mizapf had the most liked content!

Community Reputation

2,983 Excellent

1 Follower

About mizapf

  • Rank
    River Patroller
  • Birthday 09/24/1969

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    MAME, TIImageTool, Ninerpedia
    Linux advocate (openSUSE/KDE)

Recent Profile Visitors

16,838 profile views
  1. Here is a test. The original source code is RORG >0020 DATA 1,2,3 AORG >A024 DATA 4,5,6 RORG DATA 7 END This is the tagged object code as produced by the E/A assembler: 01 0028 " " A 0020 B 0001 B 0002 B 0003 9 A024 B 0004 B 0005 B 0006 A 0026 B 0007 F See the result in the memory view of the MAME debugger.
  2. Unfeasible, unless the Raspi 4 has become 20 times faster than the Raspi 3. My tests with the Raspi 3 utterly failed, see the bottom of my page: https://www.mizapf.de/en/ti99/mame I'll probably give it a try when I can get hold of a Raspi 4.
  3. In assembly code, RORG typically appears when you used an AORG before. If you have a second RORG, then you may have had such an absolute block in between, but you would not expect that the loader treats this RORG block as if it were a completely independent file. As for your AORG/RORG overwrite concerns, it certainly sounds interesting that your linker intelligently avoids a clash of absolute code and relocatable code, but you should at least allow for a "compatibility" option with the same behaviour as our existing linkers. Otherwise, you may write some program that links correctly with your linker, but fails with the E/A or LDR linker.
  4. Same for me, your question triggered some interest in discovering unknown commands. MAME does support the MID (try the Guru program), but of course no undocumented functions, unless I am starting to develop a split personality. (Going to discuss that with myself later.) I also thought about another way to find out whether there are undocumented instructions in the 9995. One could run a loop through the unspecified values and execute them (using X), and if they are invalid, let it branch along the MID vector. To gain control, the location in the TI ROM must be patched (like the Guru program). Then one could store that value in a list. The only problem with this idea is that one must be sure that the tested instruction does not cause a jump outside of the loop.
  5. Here is the code. You just have to load it (E/A 3 or CALL LOAD); there is nothing to be executed. Then you can continue as usual, e.g. load another program with a test instruction. When an invalid instruction is found, you should get the "Guru meditation". guru.dsk Edit: Of course, this will only detect the invalid instructions of the 9995, and this processor already defines four instructions not included in the 9900 (LST, LWP, DIVS, MPYS).
  6. Sure. COPY means source code inclusion. This also means your symbols are available in the file with all inclusions. You can create a file with some constants and COPY it into your code for direct use. Using COPY means you get a single object code. Linking via the linking loader requires you to declare symbols with DEF, and you have to explicitly REF them in another file that is to be linked with the first one. All other symbols are only valid in the respective object file. AORG or RORG are only interesting for the assembler, not the linker. The linker does not see any of them; it only sees the 9 or A tags (9 for absolute position, A for relocatable position), and it does not know how they were created (e.g. by BSS, BES, or RORG).
  7. I'm currently away from my Geneve. I once showed you my Guru Meditation that could be used here: Load this code in GPL mode, then another program with this command, and run it. You should then get the "Guru meditation" if the command is invalid (using the Macro Instruction Detect (MID) of the 9995).
  8. Also on WHTech: http://ftp.whtech.com/Cartridges/MAME/zip/demonatb.zip (demonatb = Demon Attack Beta)
  9. MAME loads the disk image when you insert it via the menu or on startup (when specified as a parameter). It creates a magnetic cell image in memory (so the disk image is not cached directly but in another form), and it writes back the image again when swapping disks via menu, or when shutting down the emulation. In between those events, the disk image is not changed.
  10. We had this a while ago: Also, see Speech in Alpiner: https://www.ninerpedia.org/index.php?title=Alpiner
  11. I did not mean to replace the current competition; there we can enjoy new fights all over the time. Until all games will have been played. My proposal is to introduce a second event with recurring challenges. I believe many of us have their favorite games which they would like to play again. Often, during the current competition, you finally gained some skills, and then the month is over. I'd like to play Munch Man, Parsec, and TI Invaders again, but we had all of them years ago. I'd find it interesting to have such a fixed collection of games, and maybe one could have another championship with another set of games ("TI Classics", "Atarisoft challenge", "Modern games"). You may have to play two or more games per month to keep your rank in all of these ... which may get a bit stressful, I see. 🙂 We may have to stretch the periods if we don't have 12 games in a category, i.e. just every two months, or every six weeks. Repetition is just the crucial point here, it is not a limitation.
  12. The important point is that the games reappear each year, so you have to defend your last score. Or replace your failure last time with a glorious fight.
  13. Just a (obvious?) tip: If you hold your smartphone in landscape orientation, you could get more of the line on the photo. 🙂
  14. Ah, I finally understood the point. The first program is this RORG >0010 DATA 1 DATA 2 DATA 3 END and the loader loads the data at addresses A010, A012, A014. When I now load RORG >0020 DATA 4 DATA 5 DATA 6 RORG >0030 DATA 7 DATA 8 END the data are put at A036, A038, A03A, A046, A048; just saw it in the MAME debugger. That is the way it should be. The relocatable location counter points to the first free word in the relocatable space, and this is RORG 0. Anything else would not make sense. If you concatenate the sources for a single file, then of course, the location counter is a single one for the concatenated file. If I inserted the second file before the end of the first one, the locations of 4, 5, 6, 7, 8 would be A020 etc.
  15. Can it be read out? It would be interesting for the SGCPU emulation which currently pretends to have a normal TI keyboard.
×
×
  • Create New...