Morse Code program for Ext.Basic

[TEXAS_JOE]

MORSE.zip

 

This one took about two hours to write!

 

This is really just a little program to show you the Morse code for letter A to Z and numbers 0 to 9.

 

It not only shows you the code in print, next to the letter you typed, but it also "sounds it out" so you can hear

what the Morse sounds like (in a very slowed down manner which would equate to less than ten words per minute in morse terms)

 

Press Shift and 1 to clear the screen at any time.

 

(This is an amended version which was compiled with Harry Wilhelm's. Instead of a FOR NEXT waitstate, it uses a CALL SOUND with volume zero, this is due to difficulties I encountered with fast changes in sound tones.)

Edited April 6, 2012 by TEXAS_JOE

[sometimes99er]

Fine implementation. Wrote my name and the did the obligatory distress signal. Trying out S several times yielded many different results - at least with Classic99. One or two dots instead of three, and different pauses. Only yesterday I did a basic take on Visage's "Fade to Grey" with a good fat bassline, the timing looked okay in the programlines, but it was generally out of sync, compiled it with Wilhelm's, and to my surprise, it was still awful - recognisable but with bad timing. I didn't care to look into it any further, but my "Shooting Stars" did sound pretty spot on, depending on CALL SOUND for overall time control.

[TEXAS_JOE]

mmmm ... the sound in classic99 does have difficulties with fast changes , it can miss a beat or two, and I also found that even compiled it still does it. Apparently on the real TI this is not the case..... One thing that did make a tonne of difference was the CALL SOUND(300,110,30) statement instead for FOR DE=1 TO 500::NEXT DE.

The reason being, whilst compiled, the for-next made bugger-all difference and still made the program miss several beats, however the problem was reduced (but not resolved) by using the call sound with no volume.

 

Recognisable but with bad timing is very true of this. Maybe one day this will be fixed, who knows. Classic99 is after all an ongoing project. I would like to know what it's like in MESS, however I don't use MESS because I had trouble mounting the game images and so gave it up as a bad job!

 

I've just loaded Morse into Classic99 to try it myself, in this end, Pressing S several times just did the job, I got S followed by DI..DI..DI ... So I don't know whats happened there?

 

Although I do admit the Morse is generally VERY slow on this program, to get out of the bad sync timing mainly. It would'nt save your life in a bad situation thats for sure hehehe...

 

Thanks for trying my program

[sometimes99er]

Copied Morse and my own Fade from the DSK1 directory of Classic99 to a DSK image using TiDir. Both work fine in MESS.

[TEXAS_JOE]

Aaah good!

[Tursi]

Yeah, don't be too surprised if Classic99 doesn't like fast audio changes. When I rewrote the audio engine a couple of years ago I didn't have time to tie it in properly, so it only updates on the end of frame. Which means that short duration changes to the audio chip might not make it out (and DAC simulation no longer works either).

[TEXAS_JOE]

Yeah I knew about it already. (I'd read somewhere else, maybe on these forums, that Classic had slight sound issues) ....

It's no biggie. 'Specially not when you consider the amount the emulator * is * doing .... it's all good

 

I've actually not encountered any problems with my morse code program, I * did * encounter them ,but got around them in the end.

No idea why Sometimes99er's Morse program was giving him the wrong signals for S .... it does'nt do that on my end.

 

I'm currently sat with my laptop rapidly thinking of ideas for another game or even just a small program ... I did mention I would do something with the RXB cartridge that's included with Classic99. I want to, it needs fully exploiting ... there is potential there. I might start out with simple, smallish graphical demos and then work my way up to an actual game. I know one thing, sprite coincidence seems to be much improved.

 

Example; the old Extended Basic would have it so you can't have multiple parenthesis on Call Coinc, but with RXB you can. That will change a lot for me, it might actually persuade me to make something good (ish) to my limited programming ability.

 

I'm trying * not * to make another fruit machine game, although I am dying to make another 'themed' one, I've done Tombstone City and I can just see MunchMan one rolling it's reels .... I just hope I don't get 'typecast' .... oh look it's texas joe, the bandit game maker ... hehe

[Tursi]

I'm trying * not * to make another fruit machine game, although I am dying to make another 'themed' one, I've done Tombstone City and I can just see MunchMan one rolling it's reels .... I just hope I don't get 'typecast' .... oh look it's texas joe, the bandit game maker ... hehe

 

hehe.. nothing wrong with that! You could release a compilation in the end!

[sometimes99er]

Yeah, don't be too surprised if Classic99 doesn't like fast audio changes. When I rewrote the audio engine a couple of years ago I didn't have time to tie it in properly, so it only updates on the end of frame. Which means that short duration changes to the audio chip might not make it out (and DAC simulation no longer works either).

 

Your Cartridge Apps EPSGMOD Example sounds great, but I detect a few timing problems here and there too. Do you/How about ensuring a sound (change) to always be of approx. 1/60th of a sec. (queuing up and forcing all through at that rate) ? Also the D - Toggle Channel 3 does not work for me ?

Edited April 9, 2012 by sometimes99er

[Tursi]

It's not even that smart... it only even looks at the sound registers when end of frame is processed, and then the entire 1/60th of a second worth of sound is generated based on that instantaneous state, and end of frame processing can be repeated several times in a row if the host system is running slowly. That affects all audio, including the SID plugin (which has numerous effects that need to run faster than that). As I often repeat, I know how I want to fix it, I just have to get up to it as I want to tie it into the VDP rewrite, which is a big job. I know this doesn't help anyone.

 

As for toggling channel 3 not working, hmm! That's probably a program bug then, since I don't use any hardware feature to mute the channels. But it's been so long since I did that, and I don't plan to support that code moving forward, in part because the creator never released the newer version of the tracker and partly because I consider his license too restrictive.

 

[sometimes99er]

Thanks.

 

As I often repeat, I know how I want to fix it, I just have to get up to it as I want to tie it into the VDP rewrite, which is a big job.

 

Just a small input. VDP graphics works rather well now, after the - was it a move from top-of-frame to end-of frame. Maybe minor experiments/update with sound could make its way.

[Tursi]

That's a good way to describe what happened. It definately possible to do sound properly with the current architecture, it's just not the direction I wanted to take things. Most of the features I've been putting off are because I want to swtch the emulator timing from CPU cycle counting (today) to VDP scanline counting. The reason is that the CPU can be halted by waitstates and the speech synthesizer (among others), and this can not be emulated today in Classic99 because the rest of the system stops when the CPU does. (I've got some hacks in there, but they don't work well).

 

The only reason it's not done is it's just not high enough on the priority list -- the emulator works fairly well for most of what I need it to do, and happily others find it useful too. But it will happen someday.