Classic99 Updates

[Tursi]

No such thing as a 6K GROM, only 6K chips that TI used. All GROM/GRAM is 8K it was just limited to 6K by hardware.

 

I know what TI did. That doesn't change my requirements though.

 

What project are you doing? Do you need a EA Cart? I had planed to use the AMS routines built into RXB and the Super EA with AMS to just access them but I may have opened up enough space to do that now. And yea I am pushing the limit of 8K for the EA Cart.

 

Okay, no worries. I just spent the last two days writing a GPL relocator anyway, and so I have what I needed done (porting my E/A Complete cartridge to a different base). I figured since you had the source code, it might save some time, but your GROM won't fit in my code. No worries there .

 

As for what it is, I'll be able to show it soon.

 

And the Ryte Data GPL Assembler is the best GPL Assembler, but is very sparse on tools that RAG or German or Swedish GPL Assemblers have.

 

I just don't want to hand-assemble the GPL I need to write next like I've done with all the little functions I've already done.

 

I kind of wish there was a cross-assembler.. maybe I should do that. Trying not to spend too much time on tools though.

[RXB]

No such thing as a 6K GROM, only 6K chips that TI used. All GROM/GRAM is 8K it was just limited to 6K by hardware.

 

I know what TI did. That doesn't change my requirements though.

 

What project are you doing? Do you need a EA Cart? I had planed to use the AMS routines built into RXB and the Super EA with AMS to just access them but I may have opened up enough space to do that now. And yea I am pushing the limit of 8K for the EA Cart.

 

Okay, no worries. I just spent the last two days writing a GPL relocator anyway, and so I have what I needed done (porting my E/A Complete cartridge to a different base). I figured since you had the source code, it might save some time, but your GROM won't fit in my code. No worries there .

 

As for what it is, I'll be able to show it soon.

 

And the Ryte Data GPL Assembler is the best GPL Assembler, but is very sparse on tools that RAG or German or Swedish GPL Assemblers have.

 

I just don't want to hand-assemble the GPL I need to write next like I've done with all the little functions I've already done.

 

I kind of wish there was a cross-assembler.. maybe I should do that. Trying not to spend too much time on tools though.

 

I do not understand why you would be restricted to 6K for GROM? No one anywhere even makes them at all? Is this to duplicate orginal TI equipment as I can not think of any other reason.

 

I disassembled the EA cart myself so that is where the code I have came from. I am attaching the latest version I finished a few minutes ago. AMS is not in this one yet only a rough draft on paper not in computer yet.

TEMP.zip

[sometimes99er]

I do not understand why you would be restricted to 6K for GROM?

I believe that any retro programming is about restricting yourself *). I myself even tries to steer clear of the 32K Memory Expansion, and staying with the bare, stripped down, unexpanded TI-99/4A console. All I like to add is my own homebrew (8K ROM only) cartridge.

 

I have a hard time justifying myself, not only to family and friends, both even to myself. Why am I foolishly wasting my time with this old TI-99/4A ? I say, one, because it's fun, two, because I'm sentimental attached to the beast somehow, three, because I might learn something useful (to use somewhere else) ...

 

 

*) If you upgrade every part of the TI-99/4A, you end up with a modern PC !?

[Tursi]

I do not understand why you would be restricted to 6K for GROM?

 

Because even modern microcontrollers have limits.

 

No one anywhere even makes them at all?

 

http://harmlesslion.com/software/grom

 

Is this to duplicate orginal TI equipment as I can not think of any other reason.

 

No, it's just all the memory I have allocated to that file. I'm already using 20k for just that one module (as my version includes the EDIT1, ASSM1 and ASSM2 files). I haven't quite announced the project yet.. if I can get the config tool written tonight I will post a YouTube video, otherwise later this week.

 

I disassembled the EA cart myself so that is where the code I have came from. I am attaching the latest version I finished a few minutes ago. AMS is not in this one yet only a rough draft on paper not in computer yet.

 

Thanks, but it was just for the AMS stuff that I was interested. I have my own modified Editor/Assembler cartridge already that I used for my project:

 

http://www.harmlesslion.com/software/complete

 

I wrote a tool that is able to parse GPL byte code and relocate a GROM to another base. It isn't perfect of course, but it does follow all branches and calls (as long as they are in the GROM) and does a pretty good 95% job. The Editor/Assembler required knowledge of just 3 subroutines that required DATA, and a small handful of patches (less than a half dozen, I'd say), which was made possible through Thierry Nouspikel's disassembly of the GROM! It was a fun a project. I was thinking of releasing the tool, but I'm not sure if anyone would be able to use it! You need a good understanding of both GPL and C to be able to use it, since it will likely need tweaks specific to the cartridge you are working with.

 

On the other hand, it's only a few steps away from a PC-based GPL disassembler. Since it follows all execution paths it gets pretty good at determining code from data... I dunno, people can speak up if they want to see it.

 

Last night I mocked up the configuration dialog for my project, so I will just need to port to GPL and it will be ready to announce. (Not ready to ship though). I just want to show it working because otherwise it's rather hard to explain what it does.

[Tursi]

I did run into one case where my parser had trouble.

 

A code block like the following:

 

CALL G@>6123
BR G@>6222
TEXT 'HELLO WORLD'

 

This sequence (not this text) happens in E/A, but there was no perfect way to deal with it. Many CALLs end with RTN, which clears the condition flag, so the BR is pretty much absolute, but a CALL /can/ use RTNC, which preserves the condition flag, in which case the BR is a /test/, and BS may be used as well.

 

My parser can handle a sequence like this:

 

CALL G@>6123
BS G@>6230
BR G@>6222
TEXT 'HELLO WORLD'

 

In this case it knows the condition flag was tested both ways and that the BR must be taken. But in the first case, if the CALL used RTNC, then the BR may NOT be taken. Since my parser does only a single pass over the code, it can not easily match up CALL statements to how they returned, so can not make this determination. In order to prevent parsing data in that case, I treat CALL as always clearing the condition bit so that a BR will always branch. This works in E/A (and most other GPL code I looked at), but in theory it's possible that the BR is meant conditionally and that there may be a piece of code that executes after it, instead of the text. My parser would miss the code in that case, unless something else jumped to it.

 

Not sure if there is a better way to handle that. I guess doing a dual pass, and tracing out all the CALL functions first (and remembering how they returned) would be the most absolute way. Any ideas?

[Tursi]

I have a hard time justifying myself, not only to family and friends, both even to myself. Why am I foolishly wasting my time with this old TI-99/4A ? I say, one, because it's fun, two, because I'm sentimental attached to the beast somehow, three, because I might learn something useful (to use somewhere else) ...

 

I'm with you on that. I believe that working with a restricted system keeps skills sharp that many people in this era of infinite disk, RAM, and performance have let wane. I am on board with expanding the machine a bit, but my expansions need to work with existing software, and that's where I push my limits. I like to work with the raw console, but I do allow the 32k RAM at least, and I'm agreeable to the AMS expansion, since it's a simple and clever design that doesn't break the original system.

 

Of course, the recruiters look at me funny when I tell them that. Only other engineers tend to understand. What's so different? My last job was programming an ARM CPU with 32k RAM and 64k flash.

 

I intend my Linux expansion (which I dearly hope I do since I was foolish enough to announce it) to include 1MB AMS. It needs some kind of memory expansion since I want to detach it from the PEB. I'm still having a little trouble sourcing a cheap enough Linux board. The one I prototyped on is nice (beautiful, even!), and has good support, but it is more expensive than I'd like for a production run. (http://www.designarm.com/products/snapper-single-board-computers.html)

[RXB]

When I bought my TI, I was not in love with the console alone. I could see other systems sold had 10 time the abilities that the TI console had, with out the P-Box the TI99/4A was in sad shape in comparison to others. I had to decide between a Hard Drive controller or a GRAMULATOR.

I picked the GRAMULATOR as it allowed me an area where there was little compilation. Also getting into the guts of the TI back then was more fun then just having a huge hard drive. And it still is more fun to be in the guts then have a hard drive. The hard drive just makes it much more easy to use the TI.

I want to see how far I can push the TI to perform better, so personally going backwards would just suck the fun out of it. Maybe if I was a Hardware guy I would feel differently. I will release the AMS support for EA as soon as it is finished. (Source code in GPL and Assembly)

By the way the Unix core is 64K has anyone attempted to put Unix onto the TI using the AMS?

Edited April 4, 2011 by RXB

[GratedTopping]

I'm using the most-recent version of Classic99.

 

It seems that RPT$ is not working correctly. In a program line, I tried a CALL CHAR(143,RPT$("80",) <note -- that's supposed to be an 8 but it shows up like a smiley plus there are two "))" on the end> and the error is a string-number mismatch. However, just typing that in, the character is redefined properly.

 

Is this something that was mentioned in the documentation? Did RPT$ work properly before?

Edited April 4, 2011 by GratedTopping

[RXB]

I'm using the most-recent version of Classic99.

 

It seems that RPT$ is not working correctly. In a program line, I tried a CALL CHAR(143,RPT$("80",) <note -- that's supposed to be an 8 but it shows up like a smiley plus there are two "))" on the end> and the error is a string-number mismatch. However, just typing that in, the character is redefined properly.

 

Is this something that was mentioned in the documentation? Did RPT$ work properly before?

 

 

Yea I went back to FW editor for files had to give up on drag and drop files for GPL as everything is mostly for Assembly or XB programmers. Understandable as I am the only GPL programmer left I think. I am sure now that you pointed it out it will get fixed.

[sometimes99er]

I'm using the most-recent version of Classic99.

 

It seems that RPT$ is not working correctly. In a program line, I tried a CALL CHAR(143,RPT$("80",) <note -- that's supposed to be an 8 but it shows up like a smiley plus there are two "))" on the end> and the error is a string-number mismatch. However, just typing that in, the character is redefined properly.

 

Is this something that was mentioned in the documentation? Did RPT$ work properly before?

Works fine here (both QI345 and QI349). One way I could get a *STRING-NUMBER MISMATCH was by spelling RPT wrong as RTP ...

Edited April 5, 2011 by sometimes99er

[RXB]

I do not understand why you would be restricted to 6K for GROM?

 

Because even modern microcontrollers have limits.

 

No one anywhere even makes them at all?

 

http://harmlesslion.com/software/grom

 

Is this to duplicate orginal TI equipment as I can not think of any other reason.

 

No, it's just all the memory I have allocated to that file. I'm already using 20k for just that one module (as my version includes the EDIT1, ASSM1 and ASSM2 files). I haven't quite announced the project yet.. if I can get the config tool written tonight I will post a YouTube video, otherwise later this week.

 

I disassembled the EA cart myself so that is where the code I have came from. I am attaching the latest version I finished a few minutes ago. AMS is not in this one yet only a rough draft on paper not in computer yet.

 

Thanks, but it was just for the AMS stuff that I was interested. I have my own modified Editor/Assembler cartridge already that I used for my project:

 

http://www.harmlessl...ftware/complete

 

I wrote a tool that is able to parse GPL byte code and relocate a GROM to another base. It isn't perfect of course, but it does follow all branches and calls (as long as they are in the GROM) and does a pretty good 95% job. The Editor/Assembler required knowledge of just 3 subroutines that required DATA, and a small handful of patches (less than a half dozen, I'd say), which was made possible through Thierry Nouspikel's disassembly of the GROM! It was a fun a project. I was thinking of releasing the tool, but I'm not sure if anyone would be able to use it! You need a good understanding of both GPL and C to be able to use it, since it will likely need tweaks specific to the cartridge you are working with.

 

On the other hand, it's only a few steps away from a PC-based GPL disassembler. Since it follows all execution paths it gets pretty good at determining code from data... I dunno, people can speak up if they want to see it.

 

Last night I mocked up the configuration dialog for my project, so I will just need to port to GPL and it will be ready to announce. (Not ready to ship though). I just want to show it working because otherwise it's rather hard to explain what it does.

 

This is the original TI GPL code for the Editor Assembler cart. And with out a 32K memory it does not work, that was the reason for the Mini Memory Module.

* Check for Expansion Memory

EXPMEM ST @>2000,@>8300 * Get a byte at lower 8K

ST >FF,@>2000 * Put a >FF at lower 8K

CEQ >FF,@>2000 * Is there a >FF there?

BR GE91D * No

CLR @>2000 * Clear at lower 8K

CZ @>2000 * Is it zero?

BR GE91D * No

ST @>8300,@>2000 * Put the byte back

RTN * Return

And this is the original EA INIT.

*

* CALL INIT

*

BINIT2 DCEQ >A55A,@>2000 * Lower 8K there?

BS GEBBD * Yes, return

BINIT3 CALL EXPMEM * Check again

ST >03,@FAC

DST GF000,@FAC2

GEBA0 MOVE 4,G@G0000(@FAC2),@FAC4 *

DADD >0004,@FAC2

MOVE @FAC4,G@G0000(@FAC2),@0(@FAC6) * Load support

DADD @FAC4,@FAC2

DEC @FAC

BR GEBA0

BR CLRXOP

GEBBD RTN

I added the CLRXOP but that was just a 4 line subroutine they kept putting in over and over. So you are making a EA CART that runs with out Expansion memory? Where is the program going to load?

[Tursi]

I added the CLRXOP but that was just a 4 line subroutine they kept putting in over and over. So you are making a EA CART that runs with out Expansion memory? Where is the program going to load?

 

No, I'm not, I made an EA Cart that lets you Edit and Assemble without the Editor/Assembler floppy disk.

 

It's interesting to see the original E/A source. Thierry Nouspikel disassembled the entire cart himself, and posted his results here: http://nouspikel.group.shef.ac.uk//ti99/download.htm#disass (scroll down to the E/A section). Nice to have two difference views.

 

I wanted to be able to show my project by now, but I ran into an unexpected snag that took me two days to code through. But it's getting close. I guess I'll go start a new thread for it, because it's not Classic99 related (except that I am developing on it.)

[RXB]

I added the CLRXOP but that was just a 4 line subroutine they kept putting in over and over. So you are making a EA CART that runs with out Expansion memory? Where is the program going to load?

 

No, I'm not, I made an EA Cart that lets you Edit and Assemble without the Editor/Assembler floppy disk.

 

It's interesting to see the original E/A source. Thierry Nouspikel disassembled the entire cart himself, and posted his results here: http://nouspikel.gro...load.htm#disass (scroll down to the E/A section). Nice to have two difference views.

 

I wanted to be able to show my project by now, but I ran into an unexpected snag that took me two days to code through. But it's getting close. I guess I'll go start a new thread for it, because it's not Classic99 related (except that I am developing on it.)

 

Well I will pump out a EA Cart for TI BASIC and AMS support next as my RXB EA cart has no Basic support in it. I am still amazed anyone would want to use Basic over XB. Basic is so slow and cumbersome.

 

The Basic Support module will be rolled into that package as a Cartidge so make 40 of GRAM I can fill. Should be able to do amost anything. Editor, Assembler for Assembly and GPL built in.

 

Some other goodies I thought up also. Good luck on your project.

[RXB]

I do not understand why you would be restricted to 6K for GROM?

I believe that any retro programming is about restricting yourself *). I myself even tries to steer clear of the 32K Memory Expansion, and staying with the bare, stripped down, unexpanded TI-99/4A console. All I like to add is my own homebrew (8K ROM only) cartridge.

 

I have a hard time justifying myself, not only to family and friends, both even to myself. Why am I foolishly wasting my time with this old TI-99/4A ? I say, one, because it's fun, two, because I'm sentimental attached to the beast somehow, three, because I might learn something useful (to use somewhere else) ...

 

 

*) If you upgrade every part of the TI-99/4A, you end up with a modern PC !?

 

 

Honestly even in the wildest of fantasies you could never make a TI a modern PC in any way. It has vastly way to many restrictions for that.

The fact that I am even working with the TI in the first place( even in a Emulator) is Retro Programming.

The computer is from a design in 1979 (TI994A) so anything at all is retro. I guess restricted Retro would be a further step back.

I would perfer to work at the highest level the TI ever got to and push that. Even that is majorly Retro.

Everyone has what they like to do I guess. Good luck with your projects.

[Tursi]

Just posted v350:

 

-Fix STATUS opcode for better EOF detection (this fixes DM2 copies)

-STATUS opcode should work on non-open files now (not fully tested)

-Default FIAD record length is now 80 instead of 128

-Bugfix in GROM cartridge creation for loading lowercase character set on 99/4A

-Cartridge creation window stays open after saving

-Enabled TI BASIC cartridge creation

-Added support for MPD project (new ROM type of 'M' - files not available yet)

-Allow options on disk controllers. An option goes at the beginning of the filename, starts with a question mark, and ends with a period. For example: "DSK1.?W.FILENAME". Currently only FIAD has options, and there are three possibilities:

- ?W. - File should be handled as Windows text (override defaults - good way to save as Text or open text without extensions!)

- ?T. - File should be treated as TIFILES (detection for this works well, so this is not too useful unless you use the V9T9 default save option)

- ?V. - File should be treated as V9T9 (mostly useful for saving V9T9 format in a TIFILES configured folder)

 

Note that when reading, the file detection is still attempted first, so forcing a filetype on a read will only work if for some reason the autodetection fails. All options have value when saving, though.

 

-Allow FIAD folders to support long filenames in directories. This is experimental, it seems to work with some apps (like BASIC catalogs), but I expect it will break others. The idea is that the program opens the directory as IF0, and must accept filenames up to 127 characters long afterwards (it will get a record length of 254 instead of 38). I may change this in the future to an explicitly different open (variable instead of fixed records) if it breaks too much software. This option is off by default. This does not affect emulated sector access.

 

-Also an option to allow FIAD directories to return more than 127 files. This is off by default and does not affect emulated sector access.

 

http://harmlesslion.com/software/classic99

[sometimes99er]

You're truely King !

 

Haven't touched much on files, and maybe I'll steer clear of it, with my limited TI resources (spare time) concentrated on stuff surrounding the (Atarisoft) 8K game cartridge format (that's where my love is - apparently). Anyway, Tursi, great work you're doing for the community. Keeping it alive, exploring and pushing. You don't have to answer this, but I simply haven't the capacity to understand how on earth you can pull off all of the things you do, I mean without some sort of time distortion device (allowing 25 hours in a day).

 

Here's a public promise. I have to play around with your MOD to VGM tool(s) in a not to distant future (now, I didn't promise too much there, did I ?).

 

Also, I don't know if this is possible already, how about a debugger feature which let's you record, stop, and store the data going the sound chip ?

 

[Tursi]

Haven't touched much on files, and maybe I'll steer clear of it, with my limited TI resources (spare time) concentrated on stuff surrounding the (Atarisoft) 8K game cartridge format (that's where my love is - apparently). Anyway, Tursi, great work you're doing for the community. Keeping it alive, exploring and pushing. You don't have to answer this, but I simply haven't the capacity to understand how on earth you can pull off all of the things you do, I mean without some sort of time distortion device (allowing 25 hours in a day).

 

I really wish I did. I've spent the last year trying to catch up on my task list, and I think I may still have to drop some promised projects. On the plus side, I have it down to about a dozen "critical" items now.

 

My passion is pushing the console, there's no question I get a thrill out of seeing it do things it shouldn't do. I wish I had a tenth of the knowledge I have now back in 1984-1991 when I was using the TI exclusively and more importantly, had the time to do it, but even so, it's a blast. It's also important to note that I'm building on top of massive foundations - plenty of which I had nothing to do with. While Classic99 makes a lot of what I play with a joy to develop (and thank you to everyone who ever pushed me to keep working on Classic99), "I stand on the shoulders of giants", and wouldn't be doing very much of this without the amazingly hard work of folks like Thierry Nouspikel and Fred Kaal, whose tools and documentation are continuously open beside Classic99 while I work (not to mention TI Intern!). The support of legends from back in the day like Ben Yates and Barry Boone keeps me going - I always wanted to be a part of their group, and while I got there a bit late, it's still something. And then we have the heavy hitters in these forums, Mark, Matthew, Marc, Owen, Walid, and definately you, Sometimes99er, who produce things that exceeed my expectations of what the machine is, and further encourage me to work harder. (And the problem with lists is you always forget someone - please include yourself if I missed you!)

 

In short, thank you, but I'd be nothing without the rest of you. You motivate me!

 

Here's a public promise. I have to play around with your MOD to VGM tool(s) in a not to distant future (now, I didn't promise too much there, did I ?).

 

Would love to see what you can do! I do have ideas for a compressed playback format which will make using it more reasonable in the end. The PSGMod format was awesome but the license on it has always bothered me a bit, as did the fact that the author didn't release the 1.05 version of the tracker (which had an even more efficient output format).

 

Also, I don't know if this is possible already, how about a debugger feature which let's you record, stop, and store the data going the sound chip ?

 

I'm not entirely sure if it fits the bill, but I do intend to add support for saving to the VGM format. The TI sound chip is already supported, and there are many players for it (although not much for editors. The PSGMod tracker can import it though, I don't recall if it can export it.) VGM is a pretty simple format, at least for our chip, documentation is here: http://www.smspower.org/Music/VGMFileFormat

 

Incidentally, regarding my note on files, I've already determined that just enabling long file names doesn't work. It actually works brilliantly in BASIC (with the standard catalog program everyone has as LOAD), but it crashes just about everything else I've loaded. I did some investigation, and nobody else has really addressed this, so the next release will use my alternate proposal, which is really very simple:

 

1) Today, a directory is read by opening the drive (or folder on hard drive) as I/F38, and reading up to 127 records.

2) My proposal for long file names is to open as I/V0 instead. The Variable is the flag to indicate long filenames are supported, and the application must expect any record length up to 254 bytes. The format for each record is exactly the same as before, just the name string may be longer (with a maximum length of 237 chars if I did my math right, but Classic99 will implement a maximum of 127 chars).

3) By the same token, opening as variable instead of fixed means that you will accept more than 127 records.

4) For the old standard, Classic99 will implement a long-to-short filename mapping, which will be used on filenames longer than 10 characters when the old Fixed style directory is opened. I can't use the Windows short filenames because they are still too long (up to 12 characters) and that trick would need to be reimplemented for Linux filesystems anyway.

 

None of the above affects reading emulated sectors for directory, you will always get the old style there. It's not safe to extend that, I've already tried.

 

Thus my recommended system for applications that want to get directories supporting long file names:

1) first try to open the directory as I/V0. If it succeeds, pay attention to the returned record length and ensure you have enough buffer space. The filename can be up to this length minus 17 bytes (two eight byte numbers and a string length byte). You must be prepared to receive any number of records, including more than 127.

2) If the first try fails, open the directory as I/F38 or I/F0 for the old-style directory. You will only get short filenames (10 characters) and you will only get the first 127 in the event that there are more.

 

I think this is a good compromise that is easy to adapt existing code to, and maintains compatibility with the old systems. Of course I would have no problem with applications implementing more reasonable restrictions internally (I shudder to think what a 238 character filename would look like on the TI BASIC 28 column screen, and that's just the filename, not the whole path!), but I don't want to artificially restrict the internal protocol. Users can always use the short form filename!

 

Unfortunately I need to get this working to my satisfaction now... I've put it off for a long time, but I intend my GROM0 to use it so that it will work when I do the Linux module later - the Linux project will need it. (Speaking of having too many projects, sigh... )

Edited April 11, 2011 by Tursi

[RXB]

Ok does anyone else have this problem?

 

I use GPLHOW2D demo to load EA cart Basic Support into TI Basic on Classic99 and when I do CALL INIT or CALL LINK or CALL LOAD it starts this low sound like a low pitched sound like a Bad Tone Honk that never ends.

 

Unless I purposely do a error to get it to stop or do a call sound the low sound keeps on going.

 

I have checked the code I am loading so that is not the problem. I even edited the file to make sure that any goofy errors are not getting back to the TI Basic area.

 

The CALL INIT is exactly the same as the Editor Assembler version only relocated to the >3800 and the routine that moves it to lower 8K is at >5800 so that should not be a problem.

 

I have no sound routines in the code at all, and any error would stop TI Basic dead in it's tracks or lock up. What is making the sound?

[Tursi]

Set a breakpoint on writes to the Sound chip, and Classic99 will halt execution on the exact instruction that begins the tone. You can trace backwards from that point.

 

If you're messing around in scratchpad at all, it's possible you accidentally wrote to the sound list address and it started playing, but with the breakpoint you will be able to tell for certain.

[RXB]

Set a breakpoint on writes to the Sound chip, and Classic99 will halt execution on the exact instruction that begins the tone. You can trace backwards from that point.

 

If you're messing around in scratchpad at all, it's possible you accidentally wrote to the sound list address and it started playing, but with the breakpoint you will be able to tell for certain.

 

LOL messing around with Scratch pad? All of GPL runs out of it and nothing else.

 

How do you set a breakpoint on the Sound chip, I see GROM, VDP RAM in the docs but nothing about the sound chip. You may be right about one thing, it only does it when it for acccess ERAM routines.

INIT, LOAD and LINK all check for ERAM and that seems to turn it on. PEEK, PEEKV and CHARPAT do not.

[+retroclouds]

Set a breakpoint on writes to the Sound chip, and Classic99 will halt execution on the exact instruction that begins the tone. You can trace backwards from that point.

 

If you're messing around in scratchpad at all, it's possible you accidentally wrote to the sound list address and it started playing, but with the breakpoint you will be able to tell for certain.

 

LOL messing around with Scratch pad? All of GPL runs out of it and nothing else.

 

How do you set a breakpoint on the Sound chip, I see GROM, VDP RAM in the docs but nothing about the sound chip. You may be right about one thing, it only does it when it for acccess ERAM routines.

INIT, LOAD and LINK all check for ERAM and that seems to turn it on. PEEK, PEEKV and CHARPAT do not.

 

Just set a breakpoint on write to CPU memory address >8400.

[RXB]

Thanks will try that.

 

Ok results are it never breakpoints at 8400.

If I type in fjslflsj trash and hit enter it breakpoints fine. (And removes the broken sound)

 

But no matter if I type in CALL INIT or CALL LOAD("DSK1.BSCSUP") or CALL LINK("TOMB") they all make that low sound.

(If you slow the TI down it is more obvious)

 

I am going over the code and taking out any branchs that could possible cause it, also checking all values to see if that might be it.

Like I said it is a straight copy of code from the EA module, the only change is the address it runs from.

Edited April 19, 2011 by RXB

[Tursi]

The sound chip responds from >8400 to >87FF, it's possible there's a stray write somewhere else in that range. You can breakpoint on a write to a range with ">(8400-87FF)"

 

That's assuming it was definately silent before you load the file.

 

Another thing that may help you narrow it down, near the bottom of the register list on the Classic99 debugger are the sound chip outputs. Take a note or a screenshot of what they are before you hear then sound, then look again after - see whether a tone or volume register changed - or multiple changes. This will help you determine whether it's a single stray write or numerous.

[Willsy]

Like I said it is a straight copy of code from the EA module, the only change is the address it runs from.

 

That implies to me that the code probably calls routine(s) with hard-coded addresses in them somewhere, but you have moved the code somewhere else....

[RXB]

Well LOL oddly when I changed the original code to my own it stopped doing it?

 

I used FAC instead of the address that the source code originally had, and now it does not do it anymore.

 

By the way I also am almost done with the BASIC AMS support also so the whole thing will be ready soon.