Jump to content

Photo

Assembly on the 99/4A


674 replies to this topic

#626 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,902 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Jan 11, 2018 3:49 AM

Set a breakpoint on writes to your R6 in Classic99 and it will stop and show you the instruction that is changing it. That should provide some insight.

So if you're at >70B8, then R6 is at >70C2, and the breakpoint syntax would be ">70C2" (in this case the '>' means 'write to').

I suppose that violates the pure original console concept though. ;)

#627 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,060 posts
  • Location:Uzbekistan (no, really!)

Posted Thu Jan 11, 2018 5:31 AM

Check the contents of the vector at 6020 in easy bug.

#628 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Thu Jan 11, 2018 6:12 AM

Set a breakpoint on writes to your R6 in Classic99 and it will stop and show you the instruction that is changing it. That should provide some insight.

So if you're at >70B8, then R6 is at >70C2, and the breakpoint syntax would be ">70C2" (in this case the '>' means 'write to').

I suppose that violates the pure original console concept though. ;)

 

Already had done that and it is totally the KSCAN call that is messing up R6. Here's the code snippet

PL LI,R7,1
 BL @DG
 BL @KI

DG MOV R11,R10
 LI R8,3
P1 MOVB @P(R6),R0
 SRL R0,8
 INC R6
 MOVB @P(R6),R1
 SRL R1,8
 INC R6
 BL @PP
 DEC R8
 JNE P1
 MOV R10,R11
 B *R11

KI MOV R11,R10
LP JMP LP
SA BLWP @>6020
<------  This is where R6 and R7 are getting trashed
 MOVB @>837C,R1
 LI R2,>2000
 COC R2,R1
 JNE SA
 MOV R10,R11
 B *R11

 

Up until the BLWP @>6020 (KSCAN), R6's contents are what they should be. Immediately after KSCAN, R6 is reset to zero for some reason and R7 to >FFFF. The DG routine changes R6, but these changes are not preserved after KSCAN....

 

As for violating the pure console concept, I have been violating that for a while now :) While everything is going through the LBLA, I am pretty much copying and pasting into Classic99 for routine testing purposes. That debugger has been a life saver. However, I am first putting all my code on paper with comments and notes. There is only so much pain I can endure  :grin:



#629 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,496 posts
  • Location:Silver Run, Maryland

Posted Thu Jan 11, 2018 10:13 AM

Have you moved the user WS to see if the same thing happens with R6 and R7?

 

Also, If you are getting past “LP  JMP LP”, I would guess interrupts are enabled before the program gets there?

 

...lee



#630 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,902 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Jan 11, 2018 2:25 PM

Odd, but we know it's not the BLWP itself that's changing R6 and R7, that doesn't write to those user registers. Is that really where Classic99 breakpointed?

I don't have a proper test here, but I ran a quick and dirty loop:

  def start
  
start
  lwpi >70b8
lp
  blwp @>6020
  jmp lp
  
  end
The first thing I noticed was that the loader stored some data at >70D8, about 32 bytes worth (but oddly it was loaded into memory expansion at >a000... I didn't realize the Mini Memory knew about that ;) ).

When I ran it, something did alter >70B8 (R0, with the start address) and >70CE (R11, with >609C), but I don't see R6 and R7 of that workspace touched at all.

I reset and tried again with LBLA. I couldn't remember how to EXIT it, so I just used warm reset and ran the code from Easy Bug. Again, though, nothing was touching that workspace after it started - I set breakpoints over the whole space.

I think you might be chasing a red herring on looking at KSCAN...

#631 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Thu Jan 11, 2018 2:52 PM

 


I think you might be chasing a red herring on looking at KSCAN...

 

 

I'm not sure how that would be given that R6 is fine up until that call... I'm including my entire code below. Copy and paste it into the LBLA and please double check me. You can run it from Easy Bug using E7D3C. To check for the R6 corruption, first remove the MOV R6,@TM at label RS and the MOV @TM,R6 a couple of instructions down. This will break the code because of the zeroing out of R6 after KSCAN. Maybe I'm missing something...

 

Spoiler

 

All the program does so far is rotate a few dots around a center point using the S and D keys in bitmap mode. It's just a test for now. 



#632 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,763 posts
  • Location:Germany

Posted Thu Jan 11, 2018 3:33 PM

While I tried to debug your code, I found an evil bug in the debugger hooks in the TI MAME emulation ... The problem is that the debugger cleared the state of the cartridge ROMG line before the CPU has read the second byte.

 

This in fact led to lost bytes and illegal instruction states during debugging. It's working now, so I can continue to explore your fascinating issue. :)



#633 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Thu Jan 11, 2018 3:38 PM

While I tried to debug your code, I found an evil bug in the debugger hooks in the TI MAME emulation ... The problem is that the debugger cleared the state of the cartridge ROMG line before the CPU has read the second byte.

 

This in fact led to lost bytes and illegal instruction states during debugging. It's working now, so I can continue to explore your fascinating issue. :)

 

Ah a silver lining! Glad to be of service!  :grin:



#634 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,763 posts
  • Location:Germany

Posted Thu Jan 11, 2018 4:31 PM


I reset and tried again with LBLA. I couldn't remember how to EXIT it, so I just used warm reset and ran the code from Easy Bug. Again, though, nothing was touching that workspace after it started - I set breakpoints over the whole space.
 
Same for me at first ... it's easy: Typing END ends the LBLA.


#635 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,763 posts
  • Location:Germany

Posted Fri Jan 12, 2018 1:31 PM

Two important points I found:

 

First: Entering programs into the LBLA is a nightmare! :mad: I mistyped countless lines, and it seems there is just FCTN-3 to edit. Also, I skipped some lines while entering. At the end I got unresolved references, twice. This is the first time that I wished to have a way to paste text into MAME. Since that is not reliably possible, LBLA operation in MAME really means: type line by line - as with the real thing.

 

Then I finally remembered that I could also paste the program to a file on a disk image in TIMT, use the Assembler from E/A to assemble it, and then LOAD AND RUN it in MiniMem. Argh! Should have thought about that right away!

 

Second: Your workspace on entering the program is GPLWS, as the MAME debugger shows me. This will bring you into trouble for sure. Try to set it with LWPI.



#636 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,496 posts
  • Location:Silver Run, Maryland

Posted Fri Jan 12, 2018 2:10 PM

If, as mizapf said, the default startup workspace is GPLWS (>83E0), you are definitely in trouble.  The first thing that MM does after executing the “BLWP  @>6020” is to change the WS from >7092 to GPLWS and, as I said in my last post, R6 and R7 are used quite a bit in KSCAN.  Among other functions, R6 is cleared and is also used to return a status byte.  Anyway—GPLWS is a bad idea as a user workspace.

 

...lee



#637 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Fri Jan 12, 2018 3:19 PM

Thanks for the tip guys! I had assumed that MM automatically sets the user workspace to USRWSP (>70B8)... The MM manual states that USRWSP "is reserved for your program's set of workspace registers" but did not specifically state that I needed to set that up manually. Once I added LWPI >70B8, everything worked just fine without corruption of the registers.

 

 

The Morley book (Fundamentals of TI-99/4A Assembly Language - I taught myself assembly using that book) actually explains that it is true that >70B8 is indeed set as the USRWSP when the LBLA is loaded, however when we return to Easy Bug to run the program, the latter sets the workspace to >83E0 !

 

You'd think something that important would be mentioned in the MM manual, but oh no... We need to thin the hair of the hapless programmers a bit more...



#638 matthew180 OFFLINE  

matthew180

    River Patroller

  • Topic Starter
  • 2,441 posts
  • Location:Castaic, California

Posted Fri Jan 12, 2018 4:41 PM

Any reason to not use a user workspace somewhere in the scratch pad RAM?  You are going to take a hefty speed penalty for using 8-bit RAM for your workspace.



#639 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Fri Jan 12, 2018 6:16 PM

Not really. It's where MM told me the user workspace was . Speed is not issue as things stand, but it's definitely an option if the need arises. At my assembly proficiency level, such considerations rarely bubble to my consciousness unless I hit a brick wall, in which case you guys on this forum have never failed to help me find a workable solution such as what happened above. So thank you!!!



#640 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Sat Jan 13, 2018 6:22 AM

Two important points I found:

 

First: Entering programs into the LBLA is a nightmare! :mad: I mistyped countless lines, and it seems there is just FCTN-3 to edit. Also, I skipped some lines while entering. At the end I got unresolved references, twice. This is the first time that I wished to have a way to paste text into MAME. Since that is not reliably possible, LBLA operation in MAME really means: type line by line - as with the real thing.

 

 

Ah yes, good old fashioned suffering  :grin: The LBLA is brutally unforgiving of typing mistakes, and downright Caligula-ish (ok I just invented that word for effect...) when it comes to correcting missed code lines. That pasting feature is one of the star features of Classic99 in my view. Have you considered incorporating that in MAME by any chance?



#641 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,763 posts
  • Location:Germany

Posted Sat Jan 13, 2018 6:58 AM

The LBLA is brutally unforgiving of typing mistakes, and downright Caligula-ish (ok I just invented that word for effect...) when it comes to correcting missed code lines. That pasting feature is one of the star features of Classic99 in my view. Have you considered incorporating that in MAME by any chance?

 

This is not easy to achieve in MAME, carefully speaking. People using other emulations have already complained about that point as well. There is a paste feature, but it is not reliable. The problem is that such a paste feature must be handled by the MAME framework which controls the user interface. The MAME framework, however, is totally agnostic about the emulation it runs - consider that the framework (or the core, specifically) must be so generic to be able to handle thousands of widely different emulations from calculators to PlayStations.

 

If you think about TI BASIC, you remember that the more lines are in memory, the longer it takes to add more lines. There is no way for me in the TI emulation to signal to the framework that we're not ready to take more characters right now. And the framework cannot find out - it can't even find out when you're typing to fast. This is mainly a consequence of the fact that we are using original memory dumps for the console ROMs, and the console did not have a way to buffer keystrokes either or to detect an overrun. You could consider to patch the original ROMs to create something like an overrun indication, let's say, by setting a CRU bit, but still I don't know how to propagate that information to the framework. The longer one thinks about that, the uglier that concept becomes.

 

It is just for that reason that I added the paste feature to TIImageTool: The reason why you want to paste is - in most cases - to get a program into memory to save it afterwards. Instead, with TIMT, you save it to an image first, then run it in MAME. The effect is basically the same - I was able to paste any program that showed up in this forum into the image in TIMT, then use it in MAME. In contrast, pasting into the image is much safer, you can review the program code. Also, I added the BASIC cruncher to TIMT to be able to paste BASIC text into the image which ends up as a BASIC program. Works like a charm, if I may say so.

 

However, and this was the case here: The LBLA is a running program, and the keystrokes it receives are translated to object code in memory and do not end on disk. I could now either add this feature to TIMT again, which amounts to creating an assembler, or - as I said - remember that it's just source code that can be assembled by E/A.



#642 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Sat Jan 13, 2018 5:13 PM

Well I've got another one for you...

It appears that the LBLA does not like doing operations between 2 addresses symbolically. For example, the instruction C @X1,@X2 where X1 and X2 are labels to single words does not work. Neither does A @X1,@X2. Replacing one of the labels with the direct address or a register solves the problem. 

Is this normal? I don't recall coming across that issue before with the EA...



#643 Stuart OFFLINE  

Stuart

    Dragonstomper

  • 730 posts
  • Location:Southampton, UK

Posted Sat Jan 13, 2018 6:08 PM

Well I've got another one for you...

It appears that the LBLA does not like doing operations between 2 addresses symbolically. For example, the instruction C @X1,@X2 where X1 and X2 are labels to single words does not work. Neither does A @X1,@X2. Replacing one of the labels with the direct address or a register solves the problem. 

Is this normal? I don't recall coming across that issue before with the EA...

 

That's a bug in LBLA. See [http://www.stuartcon...inimem_lbla_bug].



#644 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,496 posts
  • Location:Silver Run, Maryland

Posted Sat Jan 13, 2018 6:11 PM

Well I've got another one for you...

It appears that the LBLA does not like doing operations between 2 addresses symbolically. For example, the instruction C @X1,@X2 where X1 and X2 are labels to single words does not work. Neither does A @X1,@X2. Replacing one of the labels with the direct address or a register solves the problem. 

Is this normal? I don't recall coming across that issue before with the EA...

 

No, it is not normal.  It works perfectly fine with E/A.  [See Stuart’s post before mine.]

 

...lee



#645 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Sat Jan 13, 2018 7:21 PM

 

That's a bug in LBLA. See [http://www.stuartcon...inimem_lbla_bug].

 

Thanks for the clarification. Interesting! Unfortunately I don't know if the LBLA can be patched in Classic99 though. I will definitely patch my tape though for the real thing. That said, I should be able to avoid the issue by simply defining my labels earlier in the program. I'll test it out later tonight.

 

Man I spent probably 2-3 hrs trying to figure out why these instructions were not working. Should have asked for help sooner...

 

UPDATE: Defining the data labels prior to the code section where they are used solved the problem and circumvented that bug. 



#646 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,902 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Jan 13, 2018 10:33 PM

Awesome collaboration, glad you got it solved1

 

Mizapf, regarding "there is no way to know" when it's safe to paste another byte, there is a way There is actually a string paste function in the PS/2 adapter I created -- which is a separate piece of hardware that needs to interface to a real TI. 

 

All you need to do is count how many times the column changes. When it has changed as many times as there are possible columns (I believe I used 8), you can be reasonably sure that at least one scan has completed. True that this is not 100% and software could be written that it's not compatible with -- but this software is very unlikely to be able to receive a generic pasted string. My code uses this sequence to establish a 'frame'. It holds the character being pasted for one frame, then it leaves the keys off for one frame. This means it pastes at the rate that the calling software is scanning the keyboard (possibly slightly slower).

 

Classic99 of course knows which ROM is loaded, and for its paste function it actually watches for KSCAN and injects the code directly. This is not so much in line with the MAME approach... but as you do have fixed CRCs for every ROM, you arguably DO know what's loaded. ;)

 

Both mechansims actually work in Classic99, because Classic99 runs the microcontroller code from my PS/2 interface. If the backend did have a way to specify that you are ready for a pasted key, you can certainly implement such a mechanism.

 

(To see the PS/2 paste string, enter the Konami code on the keyboard while in any editor or TI BASIC. Works in Classic99 or on the hardware adapter: up, up, down, down, left, right, left, right, B, A, Enter.) ;)



#647 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,902 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Jan 13, 2018 10:34 PM

 

Thanks for the clarification. Interesting! Unfortunately I don't know if the LBLA can be patched in Classic99 though. I will definitely patch my tape though for the real thing. That said, I should be able to avoid the issue by simply defining my labels earlier in the program. I'll test it out later tonight.

 

Man I spent probably 2-3 hrs trying to figure out why these instructions were not working. Should have asked for help sooner...

 

The disk file MM_LBLA.OBJ is a windows-formatted text file in the TI uncompressed object file format. You could probably find the correct byte to patch there. Likewise, if you apply the patch in easy bug, again, it will be saved with the rest of the NVRAM until you wipe it. ;)



#648 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,915 posts
  • Location:Eagan, MN, USA

Posted Sun Jan 14, 2018 6:56 AM

 

The disk file MM_LBLA.OBJ is a windows-formatted text file in the TI uncompressed object file format. You could probably find the correct byte to patch there. Likewise, if you apply the patch in easy bug, again, it will be saved with the rest of the NVRAM until you wipe it. ;)

 

I took a quick look at the object file, but it does not quite match the memory contents of the MM after LBLA is loaded and I can't seem to find the right string to change in it. I do know however that the file represents the entire 4K of the MM from >7000 to >7FFF, so it will likely be just a matter of counting bytes as long as I understand how the file is formatted. I see that each line is terminated by 80000F. Is that correct?



#649 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,763 posts
  • Location:Germany

Posted Sun Jan 14, 2018 8:01 AM

Hi Tursi,

 

thank you for your tips indeed; these are some interesting thoughts, and I already copied them into a file before it gets lost in the stream of postings ...   ;)

 

I'm still not overly optimistic, but as I said, there is a general wish of MAME users that such a feature be available at some time. I could imagine that eventually, there will be some core feature for throttling input, and this will them be available to the emulated system in some way.

 

In the current state, my concerns are that such a concept must also work e.g. for the Geneve, and you have so many different configurations ... It's not so great to see that the pasting is working correctly on the 99/4A, but then not for the 99/8 or the Geneve. Here, you're always in a more comfortable situation with Classic 99, since it is a TI-99/4A-only emulator, and you can assume safe ways to retrieve meta-information (what is the system doing) and to monitor activity.

 

For now, the paste feature in TIMT is doing almost everything I need. It is certainly not an optimal solution; I suppose most people don't remember TIMT as a practical way in that situation and just wonder why MAME is not offering such a feature.


Edited by mizapf, Sun Jan 14, 2018 8:03 AM.


#650 Stuart OFFLINE  

Stuart

    Dragonstomper

  • 730 posts
  • Location:Southampton, UK

Posted Sun Jan 14, 2018 9:13 AM

 

I took a quick look at the object file, but it does not quite match the memory contents of the MM after LBLA is loaded and I can't seem to find the right string to change in it. I do know however that the file represents the entire 4K of the MM from >7000 to >7FFF, so it will likely be just a matter of counting bytes as long as I understand how the file is formatted. I see that each line is terminated by 80000F. Is that correct?

 

I've attached a corrected version.

Attached Files






2 user(s) are browsing this forum

2 members, 0 guests, 0 anonymous users