evacpod type in from apple ii

[bradhig1]

I was talking about the original problem with 2740 last night when I counted the comma's I came up short one and retyped it several times before I got it right and today I found another problem with it a 52 instead of a 62 and fixed that.  I believe I got most if not all the bugs out.  Don't hold or repeatedly hit the increase thrust keys or you will fly off the top of the screen and I lost.   I have always had problems with spelling ever since grade school.

type ins.DSK

Edited April 2, 2023 by bradhig1

[bradhig1]

1 hour ago, bradhig1 said:

I was talking about the original problem with 2740 last night when I counted the comma's I came up short one and retyped it several times before I got it right and today I found another problem with it a 52 instead of a 62 and fixed that.  I believe I got most if not all the bugs out.  Don't hold or repeatedly hit the increase thrust keys or you will fly off the top of the screen and I lost.   I have always had problems with spelling ever since grade school.

type ins.DSK 140 kB · 0 downloads

Eeek!!  I didn't close the dsk image in the emulator before uploading it. This one should work.  Load EVACUPOD

type ins.DSK

[bradhig1]

Here is another one called cellmates.  I can't get past out of data in 1540 because I can't get lines fixed 1870-1880 due to not being able to cursor up to the point in the line where the error is instead of being forced to retype the whole line which results in another error.  Lazy programmer should have used call sound commands instead of data statements.  I hate data statements to death.

type ins.DSK

[+OLD CS1]

37 minutes ago, bradhig1 said:

Lazy programmer should have used call sound commands instead of data statements.  I hate data statements to death.

DATA statements are often used to reduce redundancy in a program.  Among other benefits, they also provide an easy method to make changes to tables of data used within the program.  An example in the TI world: a song or sound effect can take up multiple lines of CALL SOUND statements, which take up a massive amount of memory compared to their utility, versus a FOR/NEXT loop which READs the note values and uses only a single CALL SOUND statement.

 

If you have a rather lengthy song, instead of having to space out line numbers and insert new statements to change, add, or remove a note, you just make a change to a DATA statement until you get it right.  &c.

 

Once you feel the power of their utility, there is no going back.

[bradhig1]

I typed in bugout on page 74 of issue 5.6.  I typed in capture and run it with cellmate and when I run bugout it says the file is not on the disk.   It is supposed to read the file and display letters codes to match to ones in the magazine.  I don't know if this is an emulation issue or not.   I am sick of this.  The file I made with the capture program is called celltrace.

type ins.DSK

type ins.DSK

Edited April 3, 2023 by bradhig1

[nick3092]

Against my better judgement, I went line by line and found what should be all the issues in the bugout program you typed in.  Specifically lines 290, 340, 500, and 520.  But I'm leaving it to you to fix them.

 

I know I eluded to this before as one way of checking your work.  But now I will spell it out step by step.  I highly suggest trying this method in the future.

1. I opened the disk image in Ciderpress, double clicked bugout.
2. A window opens with the basic listing.  Press Ctrl-A to highlight the whole program, and Ctrl-C to copy it.
3. I opened Notepad++ (it's free and I prefer it over basic Notepad in windows, it has some nice features like highlighting the line you are looking at, you can highlight a word/variable, and it will highlight that same thing else where in the lising, etc.  But whatever text editor you prefer will work fine), and pasted the listing in to there.
4. I put Notepad++ on half my screen, and the PDF of the listing on the other half.  Now you can even zoom in the text on Notepad++ to make it easier to read, along with zooming in the PDF to a comfortable level.
5. A few things jumped out at me right away just skimming your program listing.  Like hitting the same character twice where it would only make sense to use it once.  Or a character that is clearly out of place based on the statement being executed.
6. After fixing those and realizing the program still wasn't working quite right, I went through line by line comparing the entire program until I found any issues and fixed them. All in all, it took 5-10 minutes to find and fix the issues. 

Alternatively, you can print the listing out from Notepad++ (or whatever) and then you can print out just the page(s) of the PDF you need, and you can compare them physically side by side just like we did in the old days.

 

The other thing is above you mentioned having trouble editing the lines directly on the Apple, and it sounds like you are emulating (most likely AppleWin).  You can use the same method above to fix your lines easily using a text editor and pasting the line in AppleWin.  Once you fix the line in your text editor, highlight and copy the line.  Then go over to AppleWin and at the basic prompt, press Shift+Insert.  It will paste the fixed line into AppleBasic for you.  Then just hit Enter and it will put the new line into memory.

 

The other issue you maybe running into is the way the IIe goes into edit mode.  By default it doesn't change the cursor, so you can get confused about what mode you are in (its always a checkerboard).  A little trick to get around that is to type in PR#3 and hit enter to put the IIe in 80 column mode.  Then press Escape+4 to go back to 40 column mode.  What you will notice now is the checkerboard cursor is solid.  That means you are in typing mode.  If you press Escape to go into edit mode, the cursor will now have a plus sign in the middle.  When you hit Escape again to go back to typing mode, it goes back to solid.  That can help you keep track of what mode you are in if you are having trouble with that.

 

Good luck.

Edited April 3, 2023 by nick3092

[bradhig1]

13 minutes ago, nick3092 said:

Against my better judgement, I went line by line and found what should be all the issues in the bugout program you typed in.  Specifically lines 290, 340, 500, and 520.  But I'm leaving it to you to fix them.

 

I know I eluded to this before as one way of checking your work.  But now I will spell it out step by step.  I highly suggest trying this method in the future.

1. I opened the disk image in Ciderpress, double clicked bugout.
2. A window opens with the basic listing.  Press Ctrl-A to highlight the whole program, and Ctrl-C to copy it.
3. I opened Notepad++ (it's free and I prefer it over basic Notepad in windows, it has some nice features like highlighting the line you are looking at, you can highlight a word/variable, and it will highlight that same thing else where in the lising, etc.  But whatever text editor you prefer will work fine), and pasted the listing in to there.
4. I put Notepad++ on half my screen, and the PDF of the listing on the other half.  Now you can even zoom in the text on Notepad++ to make it easier to read, along with zooming in the PDF to a comfortable level.
5. A few things jumped out at me right away just skimming your program listing.  Like hitting the same character twice where it would only make sense to use it once.  Or a character that is clearly out of place based on the statement being executed.
6. After fixing those and realizing the program still wasn't working quite right, I went through line by line comparing the entire program until I found any issues and fixed them. All in all, it took 5-10 minutes to find and fix the issues. 

Alternatively, you can print the listing out from Notepad++ (or whatever) and then you can print out just the page(s) of the PDF you need, and you can compare them physically side by side just like we did in the old days.

 

The other thing is above you mentioned having trouble editing the lines directly on the Apple, and it sounds like you are emulating (most likely AppleWin).  You can use the same method above to fix your lines easily using a text editor and pasting the line in AppleWin.  Once you fix the line in your text editor, highlight and copy the line.  Then go over to AppleWin and at the basic prompt, press Shift+Insert.  It will paste the fixed line into AppleBasic for you.  Then just hit Enter and it will put the new line into memory.

 

The other issue you maybe running into is the way the IIe goes into edit mode.  By default it doesn't change the cursor, so you can get confused about what mode you are in (its always a checkerboard).  A little trick to get around that is to type in PR#3 and hit enter to put the IIe in 80 column mode.  Then press Escape+4 to go back to 40 column mode.  What you will notice now is the checkerboard cursor is solid.  That means you are in typing mode.  If you press Escape to go into edit mode, the cursor will now have a plus sign in the middle.  When you hit Escape again to go back to typing mode, it goes back to solid.  That can help you keep track of what mode you are in if you are having trouble with that.

 

Good luck.

520 was the one I missed.  I found the others.   In 1984 we typed in several programs.  Horse Racing and Acrobat from computer and a program called happy birthday that displays a birthday card on screen with an animated figure holding up a sign.  We used a TV with a fuzzy picture at times and all three wouldn't work because of errors in data statements. Horse Racing we didn't use the automatic proofreader in Compute and retype it a couple of times when it would go to the restore screen as it draw the racetrack.  Acrobat crashed at the menu when we selected difficulty.  Happy Birthday kept saying error in 45 which read the data in.  All three were fixed after printing out the listings and finding errors in data statements.  Happy Birthday's data error wasn't found until 5 to 6 years later when I found a missing comma.  Sometimes I just need another set of eyes to find what I missed.

[bradhig1]

GOkay it works however the gauge from import pro. is messed up and the bugout codes don't show any more errors to fix at least what I see.   The graphics are great due to it running on my laptop's LED panel and not a CRT as it was designed for.   Still can't cursor up no matter what mode I am in.

 

Got it fixed. error in 1330. 

type ins.DSK

[Iamgroot]

You are obviously typing in programs quite fast.  It is better to slow down your typing speed and proof read each line as you enter them.  It is far easier to check a line just after it is typed in, rather than entering the entire program, then checking line by line.  You will find you will get far fewer typing mistakes and you won't get as frustrated as well.

[Duhast]

You should really check out Program Writer from Beagle Bros.  It would allow you to fix all the errors/proofread natively on the //(Applewin whatever).

 

https://archive.org/details/a2_Program_Writer_v2.1

 

Documentation is found on the archive or other places on the web.  DO NOT use older versions.

 

[bradhig1]

12 hours ago, Iamgroot said:

You are obviously typing in programs quite fast.  It is better to slow down your typing speed and proof read each line as you enter them.  It is far easier to check a line just after it is typed in, rather than entering the entire program, then checking line by line.  You will find you will get far fewer typing mistakes and you won't get as frustrated as well.

I catch a lot of bugs while typing yet some get through.  There is a version of cell mates for the atari 8 bits anyone else want to take that one.  I have carpal tunnel in my wrists now.