Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

mizapf

Members
 View Profile  See their activity

  • Content Count

    5,366

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by mizapf

  3. Posted

    I don't remember all details; it's many years ago that I wrote the emulation.

     

    (Just had a short look in the specs...)

     

    In general, there are status bits that indicate the completion of a command and the kind of completion (success, failure). You can also set an interrupt for the completion of a command. I'd have to look into the HFDC DSR to check which way it is working.

    • Like 2

  9. Posted

    7 hours ago, Airshack said:

    Where may I read more about this? I have it working as I wish yet it’s still mysterious.

     

    You could study TI Intern; we have a link in the Development subforum in the pinned thread.

     

    I actually never thought about the effect of the 83C4 hook on [email protected] ... obviously because it is rarely used. Regarding the 83C4 alone, a LIMI 0 won't help because the next LIMI 2 occurs only 11 instructions after the BLWP @0, and it will not be cleared until then. So you must clear it before BLWP @0.

    • Like 1

  10. Posted

    1 hour ago, tmop69 said:

    Is there a way to check the CRU from XB? The test with the sprite would be ok for a brand new program (e.g. during the game title), but not feasible if you want to compile an existent one.

    For a minimal impact, one could do that with a sprite color that blends with the background.

      

    10 CALL SPRITE(#1,42,8,96,1,0,10)
20 A=0
30 CALL POSITION(#1,X,Y)
40 A=A+1
50 IF Y<20 THEN 30
60 IF A>15 THEN PRINT "PAL/50 Hz" ELSE PRINT "NTSC/60 Hz"

     

    Accessing CRU is only possible via machine language programs.

    • Like 2
    • Thanks 1

  12. Posted · Edited by mizapf

    @BeeryMiller I remember this was indeed an issue ... but long ago, maybe 10 years or more.

     

    I tried it with this code. The code is meaningless, also the CLR instructions. 

           TEXT 'Example'
LABEL1
       CLR  R0
       LI   R1,LABEL1

       TEXT 'Another'
LABEL2 CLR  R0
       LI   R1,LABEL2

       TEXT 'LastOne'
LABEL3 TEXT 'here'
       CLR  R0
       LI   R1,LABEL3
       MOV  *R1+,R2
       MOV  *R1+,R3
       
       END

     

    This is the memory dump after loading:

      

    a000  4578 616d 706c 6500 04c0 0201 a007 416e   Example.......An
a010  6f74 6865 7200 04c0 0201 a016 4c61 7374   other.......Last
a020  4f6e 6568 6572 6500 04c0 0201 a023 c0b1   Onehere......#..
a030  c0f1 0000 0000 0000 0000 0000 0000 0000   ................

     

    So we can see that LABEL1 is indeed on an odd address (a007), where LABEL2 is on an even address (where it matters when the label is in the same line as the instruction and when it is not!). In the third example, I falsely assume that LABEL3 is on an even address, because I use MOV (not MOVB) which will deliver an unexpected result: R2 will contain 'eh' (from (LastOn)eh(ere)) and R3 will contain 'er' (not 'he' and 're').

     

    • Thanks 1

  13. Posted · Edited by mizapf
    I just don't get it without space lines.

    It aligns for DATA and instructions.

     

    With EVEN, you could e.g. ensure that a line with BYTE or TEXT starts at a word address when the previous line was BYTE or TEXT or BSS.

     

    Also, the E/A manual mentions that a label is assigned the current location counter, so for instance, in

      

       DATA 0
   TEXT 'Example'
LABEL
   LI R0,1
   ...

     

    the LABEL does not point to the operation LI in the following line but to the byte after the text.

    • Like 1

  14. Posted

    10 minutes ago, BeeryMiller said:

    I've seen the GenProg file move around, disappear, reappear, disappear, etc. a number of times on Whtech.  It always makes me nervous when things are moving around as I wonder if at some point it will just disappear and I will be the only resource.

    For that reason, I set up the new directory Geneve.new and only copy things inside, not move. 🙂

     

    • Like 6

  16. Posted

    As I see that people are using the Horizon emulation, a heads-up: The emulation will be fixed for the next release; I am doing some more tests to find last glitches. However, you should definitely do a backup of your Horizon ramdisks to disks before upgrading! I cannot guarantee that the old NVRAM save file will be loaded by the new emulation. It is possible that it does, but only if you set the exact same capacity.

     

    If the old file fails to load, it will be replaced by an empty one when you close the emulation. (You're doing regular backups anyway, I know.)

     

    I gues this could probably be useful to know.

    • Like 1
    • Thanks 1

  19. Posted

    45 minutes ago, FarmerPotato said:

    I would like to understand the format of the DREM image.  Does it interchange with the MESS drive image?

    The format in MAME is a special metadata-enriched container format. But if you have a sector dump, you can easily create a MAME HD image and vice versa (using chdman or TIImageTool).

    • Like 2

  20. Posted

    12 hours ago, OLD CS1 said:

    Does MDOS/GeneveOS provide the interface to the hardware clock for software (asking as I know nothing about the Geneve OS?)  I would expect an operating system to abstract access to any underlying hardware.  For instance, the "CLOCK" DSR has a standard interface for software to query and set, and the DSR itself manages access to whatever chip is being used.

     

    It would seem that if you wanted to use a superior or more readily available chip that changes could be made to GeneveOS to accommodate without sacrificing software compatibility provide the software is well-behaved and only uses the supplied interface.  Why should user software access the clock directly?

     

    Preventing direct access to hardware is one of the reasons why the privileged mode was invented for processors. This could be done on the TMS99105 since it has such a mode. You cannot restrict the address access, but you could use a CRU bit to guard the clock hardware, and the TMS99105 allows access to CRU addresses 1C00 and higher only in privileged mode.

  21. Posted

    I shall give you some more technical reasons for this, to avoid sounding like "I just don't like it."

     

    I suppose many people believe that an emulation uses some kind of delay loops here and there to achieve the real execution speed. As for MAME, this is not the case; other simulators and emulators may do it the same way or have other ways.

     

    In fact, the MAME core contains a scheduler that gives every clocked component a kind of "permit" to run for a specific amount of its cycles. The components are invoked at special points in time, deadlines. Those deadlines may be e.g. 16.67 ms apart when set up by the video interrupt (60 Hz), but they are closer together and with different time spans with several interleaved timers. So if we only had the video interrupt, we can assume the scheduler is invoked every 16.67 ms.

     

    Then the core calculates the number of cycles that happen in the real machine during that time. If we take 333 ns as the TMS9900 cycle time, this means 50000 cycles. Hence, the scheduler calls the TMS9900 component in MAME to execute exactly 50000 cycles. This is done as fast as your PC can do it; there are no delay loops inside. Of course, there is an emulation of wait states and of the READY line control; the wait states are realized by letting the appropriate cycles pass without action. But this is part of the emulation, not of the emulator. (Which means: The emulator cannot take away this feature, as I wrote the emulation that way; it is a required behavior.)

     

    When the TMS9900 component has finished to run its 50000 cycles, it returns control to the scheduler which will call it after the next deadline. This means that if your PC is pretty fast, the component has a lot of free time now. But if your PC is not so fast, it may actually fail to meet the deadline. In that case, the emulation runs slower than the real system. You can see that when you stop the emulator: In the command line window, you get an output about the speed. If it says 100%, then all deadlines were met. The more it is below 100%, the more it failed to keep the deadlines.

     

    I put a performance comparison table on https://www.mizapf.de/en/ti99/mame/mamereq

     

    The benchmark feature of MAME removes all deadlines and lets it execute everything one after another without free time. Also, the screen output is turned off because this is a heavy performance load. So if you look at the numbers for the "Thinkpad T60 Core2 Duo" when it runs the Geneve emulation, you see that it achieves 91% of the real speed. This means that this is actually the fastest way to run the Geneve emulation. All spare times are 0, and quite some deadlines were missed. This computer cannot run MAME any faster even when you removed the deadlines.

     

    On my Core i7 PC, the raw Geneve performance is 483% without graphic output; this would take away another 100%. This means that when I removed those deadlines, it would run at most 4 times as fast as the real Geneve. And I did not even take floppy and hard disk operations into account, which would be important for you as you were talking about doing compile and assemble work. Those are also heavy impacts, and I'd expect that you won't make it run more than at double speed. When I do heavy floppy and hard disk work in the emulation, it may even drop below 100% on my machine.

     

    There is in fact a setting "speed" in mame.ini. You may try to increase it, but as I said, you will not reach a much faster emulation, especially when your speed is already close to 100%. Maybe try it and compare the run speed of a simple TI BASIC loop 1 to 1000; you'll notice that the sound is broken, much too high pitched, but the BASIC program seems to run at the same slow pace.

    • Like 4

  23. Posted

    7 hours ago, dhe said:

    Is there a way to crank up the speed of MAME, I know for things like most arcade games, close to original timing is optimal, when it comes to things, like compiling MDOS - a 2Ghz TMS9995 would be nice!

    No, actually not. A lot of work has been invested over (literally) decades to model execution times as close as possible to the real machine. If you need such things as fast compiling or assembling, maybe some external tools running on the PC are a better way.

     

     

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...