Jump to content
IGNORED

Assembly on the 99/4A


matthew180

Recommended Posts

Lots of good advice above. More generically:

 

- you now know that the bug is caused by something that is initialized by loading via editor assembler that is NOT initialized from your program directly

- you have verified that the VDP registers do not appear to be that something

 

The most likely other cause remains the EA Utilities not existing in low RAM, but we can see that your program counter (PC) is still up in high memory. Look at the running disassembly - does it look like your program is running or is it off in hyperspace? ;) Breakpoint (F1) and make sure that the code you see looks familiar.

 

If your program is running, then you can assume the screen corruption is not caused by a software crash - that leaves only video memory not being initialized as expected. So as noted above - check that your VDP tables contain the expected data.

 

Don't overlook Home Automation's comment about the first instruction of your program. When you use EA#3, you start at a label which can be anywhere in the program. When you use EA#5, the first byte loaded is the first executed statement (SFIRST and SLOAD are the same), so if you have any BSS or DATA at the beginning, just insert a "B @start" (or whatever label) before them.

 

  • Like 3
Link to comment
Share on other sites

6 hours ago, Asmusr said:

You need to check if the name table at >0000 and the pattern table at >2000 contain the expected data.

The name table is fine on EA5 without a system reset.

 

EA5_Running_Before_Reset.png

 

 

After the reset it seems blank?

 

 

EA5_Running_After_Reset.png

 

 

 

Here's the pattern table at >2000 after system reset...

 

EA5_VDP2000_After_Reset.png

 

This part seems alright.

Link to comment
Share on other sites

2 hours ago, Tursi said:

does it look like your program is running or is it off in hyperspace? ;) Breakpoint (F1) and make sure that the code you see looks familiar.

 

If your program is running, then you can assume the screen corruption is not caused by a software crash - that leaves only video memory not being initialized as expected. So as noted above - check that your VDP tables contain the expected data.

 

 

After using (F1) I took this snapshot of the code running which appears to be familiar as this code involves moving one my enemy vehicles:

1370473752_EA5_Code_Running_After_Reset.thumb.png.9756f5192fe473eac04b9f61d7cbaabb.png

 

@Tursi, the program appears to be running yet I cannot see the playfield due to the (screen) name table being all blanks?

Link to comment
Share on other sites

3 hours ago, Tursi said:

Don't overlook Home Automation's comment about the first instruction of your program. When you use EA#3, you start at a label which can be anywhere in the program. When you use EA#5, the first byte loaded is the first executed statement (SFIRST and SLOAD are the same), so if you have any BSS or DATA at the beginning, just insert a "B @start" (or whatever label) before them.

@HOME AUTOMATION has been very helpful so no, I will not overlook his comments. Welcoming any and all comments at this point! 

 

As you say, I do indeed have code starting at the (newly renamed) label SFIRST. As mentioned earlier this label name works with the EA SAVE routine, E/A manual, 24.5, p.420.

 

Before SFIRST I have multiple EQU, DATA, and BYTE's in order to set things up. I'll try inserting "B @SFIRST" as the very first line like so:

 

 

 

EA5_Homeauto_Tip.thumb.png.064d45707ce2b7cd155ea72b85102c28.png

 

EDIT: Adding this first line of code did not change the situation with the (screen) name table at >0000 reading all blank character >20s, after a system reset and EA5 option selected.

  • Like 1
Link to comment
Share on other sites

EQUates and other directives can occur in your source code before SLOAD and SFIRST. It is the first assembled word that must be labeled SLOAD (and usually also, SFIRST). In your scenario, whatever word has the address >A000 after assembly should be labelled SLOAD and SFIRST—oh—and, of course, be executable:

       AORG >A000
       DEF SFIRST,SLOAD,SLAST
       VDPRD EQU >8800
*      ...
SFIRST
SLOAD  B    @START
       DATA ...
       BSS  ...
*      ...
START  LIMI 0
*      ...
SLAST  END
       

 

...lee

Edited by Lee Stewart
further explanation...
  • Like 1
Link to comment
Share on other sites

1 hour ago, Lee Stewart said:

In your scenario, whatever word has the address >A000 after assembly should be labelled SLOAD and SFIRST:


       AORG >A000
       DEF SFIRST,SLOAD,SLAST
       VDPRD EQU >8800
*      ...
SFIRST
SLOAD  B    @START
       DATA ...
       BSS  ...
*      ...
START  LIMI 0
*      ...
SLAST  END

That worked! After a system reset that file works under EA5! Onward to see if I can get Fred Kaal's  utility Module Creator 2.0 to make me a .bin for the FlashGROM99.

 

Edit:  YES! The resulting EA3-to-EA5 conversion resulted in three files (ENKA,ENKB,ENKC) which fed into Fred Kaal's Module Creator 2.0 properly!

 

I have a working cartridge binary!!! Yes!

 

Who knew seeing your own title appear as option #2 on the TI Boot/Menu screen would be so exciting?  

 

Grateful for: @HOME AUTOMATION, @Lee Stewart, @Tursi, @apersson850, @senior_falcon, @PeteE, @Asmusr, @mizapf, @GDMike. Great team effort guys! THANK YOU!!

  • Like 6
Link to comment
Share on other sites

  • 3 weeks later...

Q1: Will re-setting the Attenuation Bits (A0-A3) to >0000 [assuming = 0 dB] produce the same results as setting them to >FFFF which is "OFF?"

 

 

Screen Shot 2020-07-19 at 2.56.10 PM.png

 

Q2: If I wish to update the frequency bits (second data byte, F0-F5) with a single-byte write to the sound processor, must I first set ALL other attention control registers to >1111 first, to turn them off?  Asking because the remark below about single-byte updates so long as no other register is being accessed:

Screen Shot 2020-07-19 at 3.07.29 PM.png

 

 *** put another way: What is the specific meaning of "no other control registers on the chip being accessed."

 

Link to comment
Share on other sites

47 minutes ago, Airshack said:

Q1: Will re-setting the Attenuation Bits (A0-A3) to >0000 [assuming = 0 dB] produce the same results as setting them to >FFFF which is "OFF?"

 

 

Screen Shot 2020-07-19 at 2.56.10 PM.png

 

Q2: If I wish to update the frequency bits (second data byte, F0-F5) with a single-byte write to the sound processor, must I first set ALL other attention control registers to >1111 first, to turn them off?  Asking because the remark below about single-byte updates so long as no other register is being accessed:

Screen Shot 2020-07-19 at 3.07.29 PM.png

 

 *** put another way: What is the specific meaning of "no other control registers on the chip being accessed."

 

Q1: >0000 is 0dB, correct.  But this is not the same as OFF (silent), 0dB is actually loudest and 28dB is quietest.

Q2: Normally changing the frequency requires two bytes, but the remark about single-byte update refers to changing upper 6 bits the same channel frequency again.  If you write to any other register, then the next frequency change will require two bytes again.  I feel like that feature was never really that useful, and my code always does the two-byte frequency writes.

  • Like 2
Link to comment
Share on other sites

15 hours ago, PeteE said:

0dB is actually loudest and 28dB is quietest.

Just so I have this one straight...

 

0dB is loudest because by setting the attenuation control bits to: 0 0 0 0, there’s going to be Zero attenuation, or zero lessening of the sound magnitude.

 

28db attenuation is commanded by setting the attenuation control bits: 1 1 1 0.

 

So 28dB attenuation is near-maximum attenuation for the device.
 

Maximum lessening in the magnitude of volume comes from setting the attenuation control bits to: 1 1 1 1, which is why that’s OFF.

 

<insert clicking sound you hear when you pull on an overhead lightbulb string> 

 

This is why they’re called ATTENUATION bits and not VOLUME bits.

 

Si?

Link to comment
Share on other sites

A good way to learn about sounds! 

Using MINI MEMORY & EASY BUG...

 

 

Easy Bug tms9919.jpg

 

1 Ringy-Dingy(snort)!:-D

 

 

 

90 First channel ON.

 

8E First channel freq. first nyble.

 

0F First channel freq. second two nybles.

 

B0 Second channel ON.

 

AE Second channel freq. first nyble.

 

0E Second channel freq. second two nybles.

 

...:music:

 

   EDIT:

I linked the above pic., to the underlying doc.

Edited by HOME AUTOMATION
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, PeteE said:

 

It's not much of an editor, but if you insist on using sound lists then I guess it will help. However, for producing sound and music playable from assembly, working with VGM and a tracker on the PC combined with the tools developed by @Tursi is far better solution. 

  • Like 1
Link to comment
Share on other sites

On 7/19/2020 at 8:29 AM, Airshack said:

May I safely assume this is an error in the SN 76489 AN data sheet documentation?

Yes, that is an error in the datasheet, one of many.  Just above that table, one the same page, you will see the same error in the Noise Shift Rate table.  Also missing are setup-and-hold times for the CE_n, WR_n, and READY lines, no indication about the output voltage range, etc.  It seems like the SN76489 datasheet was a rough draft, or was never actually finished, proof read, or edited.

 

Yes, the "volume" is confusing since it is specified as an amount of attenuation.  Basically think of the chip as being "full on", and you have to shut it up. "0000" is no attenuation, "1111" is max attenuation, but in reality it is probably transistor cut-off, which is why you see the term "OFF" in the datasheet.

 

Also note that 2dB increments are not what people expect for audio levels.  Levels that change by double or half, i.e. -/+3dB, are more typical and more what you expect to happen.  2dB steps is just odd for audio.

  • Like 1
Link to comment
Share on other sites

3 hours ago, matthew180 said:

  2dB steps is just odd for audio.

If I remember correctly 1dB is defined as the amount of level change that can be perceived 50% of the time by humans, so 2dB might be a reasonable choice to overcome that hurdle.

It does provide the ability to create relatively smooth attack and decay envelopes to our sounds. I think a 3dB step would produce an audible step but I have never tried it to know for sure.

I think if I wanted anything more it would be 1 more bit of attenuation range.

Link to comment
Share on other sites

On 7/19/2020 at 10:29 AM, Airshack said:

May I safely assume this is an error in the SN 76489 AN data sheet documentation?

9919 Ctl Reg Address.png

I have a SN76489 document dated November 1981 that has the proper value in the table.  The document is fairly simple in its formatting.  Upper left corner header reads "ADVANCED CIRCUITS" with a "TEXAS INSTRUMENTS Incorporated" footer.  What is the date of your document?

Link to comment
Share on other sites

I know this is Forth but it might help you out nevertheless.

I took the approach of creating literal values for each sound source in the chip.

Then I OR the sound value with the appropriate literal value to select which sound source on the chip.

 

Here are the constants. You could use EQUates or DATA values in Assembly language.

 

After ORing the frequency values to the OSCillator constant you write the two bytes of the register to the chip starting with the lsb. ( example AABB , write AA 1st, then BB)

 

For attenuation values and noise values,  it is just a one byte write.

Edit: Home Automation pointed out to me that Oscillators require 3 nibbles. I was thinking in terms of writes to the sound chip. :) 

\ frequency code must be ORed with these numbers to create a sound
HEX
  8000 CONSTANT OSC1      A000 CONSTANT OSC2   ( oscillators take 2 nibbles)
  C000 CONSTANT OSC3        E0 CONSTANT OSC4   ( noise takes 1 nibble)
 
\ Attenuation values are ORed with these values to change volume
( 0= max, 15 = off)
    90 CONSTANT ATT1         B0 CONSTANT ATT2
    D0 CONSTANT ATT3         F0 CONSTANT ATT4  ( OSC4 volume adjust)
 

Might make it easier for you like it did for me.

  • Like 1
Link to comment
Share on other sites

  • 3 months later...
On 7/20/2020 at 11:35 AM, Asmusr said:

if you insist on using sound lists then I guess it will help. However, for producing sound and music playable from assembly, working with VGM and a tracker on the PC combined with the tools developed by @Tursi is far better solution. 

Hmm... I'm willing to learn these tools. I did roll my own crude sound-list player but I'm certain there's better ways.  Thanks!

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...