EUG #48 Feedback

By Robert Sprowson
Originally published in EUG #49

MORSE CODE SOUNDER

This was an interesting implementation of a morse code sounder and the author stated that (for interest) the sequence of dots and dashes for each letter is stored in one byte. The coding is as follows:

Take the letter C. It is stored as 26 which, if written in binary, is 00011010. The program uses an algorithm similar to the one below to 'scan' the binary of the number until it finds a 1. From then on, the program sounds a dash when it encounters a 1 and a dot when a 0 is encountered, until the end of the number.

Algorithm

Load byte to acumulator LDA table,X
Shift it to the left ASL A
Load accumulator with 0 LDA #0
Add with carry to 0 ADC #0
If accumulator contains 1 then dash else dot BEQ dot:.dash

But my question is - How do you know how many dots and dashes are required to make up a letter? For example 'O' is dash dash dash (ie. => 00000111) but the letter 'J' is dot dash dash dash (ie. also => 00000111 also). Surely there must be a second table saying how many itterations of the loop to perform, making it 2 bytes per entry perhaps?

MAKE YOUR MIND UP

The editor swiftly responded to my barrage of comments about teeny weeny things that have niggled about EUG. I think it's almost perfect now but to follow up anyway: 

>I have implemented a configuration menu and reinstated CODE8. 
>Of course it includes a Mode 6 text viewing option you crave so happy,
>happy, happy!
Excellent - no need to squint anymore! 
>   As noted, the User Group is operating a little differently as all 
>Back Issues are being amended in the light of members' criticisms. That
>the !BOOT files didn't take account of BASIC is very useful and I have
>immediately remedied this.
Yep - I spotted that. Trying to !BOOT an EUG disk with View running always caused confusion on View's behalf...

I also pointed out that there was no need to do two seperate 'builds' of the disk for DFS and ADFS since ADFS is backwards compatible with DFS: 

>   On your assessments of ADFS and DFS though, I am floored. A DFS disk
>has a limit of 31 files on each side of a disk. The MENU program has to
>be rewritten to take this into account. There are usually around fifty
>files on an EUG disk. Whereas ADFS can split them into directories, DFS
>needs commands specifying it to turn over the disk when appropriate. 
>Such commands give an error if ADFS encounters them!
I had forgotten about the ridiculously small DFS disk catalogue size, true, but this is easy to fix. Your list of filenames are usually held in 'DATA' statements in the menus, so having found which file you need try to open it: 
      F=OPENIN filename$:IF F<>0 THENCLOSE#F
Now work out which FS we're on: 
      A%=0:Y%=0:fsid=(USR &FFDA) AND&FF:REM Returns 4 for DFS
And finally: 
      IF (F=0) AND (fsid=4) THEN *DRIVE2
      CHAIN filename$
So under anything but ADFS the file is opened successfully and CHAINed. But under DFS, the file is on the other side of the disk, but still named exactly the same as under ADFS. Having not found the file, you wap sides.

Of course, any menus on 'side 2' just need *DRIVE 0 instead. People with multiple drives (running the disk in DRIVE 1) might have problems here but you can discover the drive number with OSGBPB A=6 under DFS. 

>   Regarding the BBC A, the disks cannot be tested on this machine so
>compatibility is dubious. I don't think we need a MENU program for it
Use of *FX254,64,0 on a Model B beeb turns it into a 16k Model A spec machine, so this could be used to check for memory problems. 
>or to have MENUs for each type of machine. It could result in disks
>cluttered with more of what are essentially the same programs.
If you include the source to the menu programme then it can pick and choose the appropriate code when you boot the disk. This way there's no duplication - just one very generic program. 
>   Your problems with EUG #47 are unique. The DFS EUG disks set PAGE to
>&E00 as many of the (longer) games include downloading code that takes
The machine had the Graphics Extension ROM fitted. I think it's used to generate timeclocks for TV programmes and I was just using it because I couldn't be bothered plugging my BBC in. I've not lost any sleep over it!

Glad to see things are on the up and up - and hope you enjoy my other submissions this time too.

Robert Sprowson
Email: info@sprow.co.uk
Web: http://www.sprow.co.uk/bbc