Tursi Posted June 29, 2020 Share Posted June 29, 2020 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. 3 Quote Link to comment Share on other sites More sharing options...
Airshack Posted June 29, 2020 Share Posted June 29, 2020 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. After the reset it seems blank? Here's the pattern table at >2000 after system reset... This part seems alright. Quote Link to comment Share on other sites More sharing options...
Airshack Posted June 29, 2020 Share Posted June 29, 2020 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: @Tursi, the program appears to be running yet I cannot see the playfield due to the (screen) name table being all blanks? Quote Link to comment Share on other sites More sharing options...
Airshack Posted June 29, 2020 Share Posted June 29, 2020 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: 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. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 29, 2020 Share Posted June 29, 2020 (edited) 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 June 30, 2020 by Lee Stewart further explanation... 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted June 29, 2020 Share Posted June 29, 2020 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!! 6 Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 30, 2020 Share Posted June 30, 2020 There you go! And yeah, that first cartridge is always fun. 4 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 30, 2020 Share Posted June 30, 2020 This game has been a dream of mine for a couple of years now, and I've been fortunate enough to see it progress as it's been developed. I'll tick another item off my Bucket List when I finally put the final version on my FG99. ENK! ? 2 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 19, 2020 Share Posted July 19, 2020 May I safely assume this is an error in the SN 76489 AN data sheet documentation? 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted July 19, 2020 Share Posted July 19, 2020 Sure. The format is [ 1 reg reg reg data data data data ] for the bits of the first byte, so the first digit is 8 for "Tone 1 frequency", 9 for "Tone 1 attenuation" etc. 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 19, 2020 Share Posted July 19, 2020 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?" 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: *** put another way: What is the specific meaning of "no other control registers on the chip being accessed." Quote Link to comment Share on other sites More sharing options...
PeteE Posted July 19, 2020 Share Posted July 19, 2020 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?" 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: *** 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. 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted July 19, 2020 Share Posted July 19, 2020 Mind that they call it "attenuation", not "volume". I also found that a bit confusing when I learnt about it first. 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 20, 2020 Share Posted July 20, 2020 15 hours ago, mizapf said: Mind that they call it "attenuation", not "volume". I also found that a bit confusing when I learnt about it first. Me too. M-Webster, ATTENUATION: a lessening in amount, force, magnitude, or value : WEAKENING.. Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 20, 2020 Share Posted July 20, 2020 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? Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted July 20, 2020 Share Posted July 20, 2020 (edited) A good way to learn about sounds! Using MINI MEMORY & EASY BUG... 1 Ringy-Dingy(snort)! 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. ... EDIT: I linked the above pic., to the underlying doc. Edited July 23, 2020 by HOME AUTOMATION 1 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 20, 2020 Share Posted July 20, 2020 43 minutes ago, HOME AUTOMATION said: A good way to learn about sounds! Using MINI MEMORY & EASY BUG. Great idea! Thank you! Do we have a utility for composing, testing, and generating sound lists? Something like Magellan for sound editing? Quote Link to comment Share on other sites More sharing options...
PeteE Posted July 20, 2020 Share Posted July 20, 2020 50 minutes ago, Airshack said: Great idea! Thank you! Do we have a utility for composing, testing, and generating sound lists? Something like Magellan for sound editing? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted July 20, 2020 Share Posted July 20, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted July 21, 2020 Author Share Posted July 21, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted July 21, 2020 Share Posted July 21, 2020 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted July 26, 2020 Share Posted July 26, 2020 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? 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? Quote Link to comment Share on other sites More sharing options...
+TheBF Posted July 26, 2020 Share Posted July 26, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted November 5, 2020 Share Posted November 5, 2020 On 7/25/2020 at 9:14 PM, InsaneMultitasker said: What is the date of your document? No date. I used this link: http://www.vgmpf.com/Wiki/images/7/78/SN76489AN_-_Manual.pdf I'd appreciate an update link! Quote Link to comment Share on other sites More sharing options...
Airshack Posted November 5, 2020 Share Posted November 5, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.