almightytodd

I don't know if we're still looking for logo suggestions, but here's mine:

May the year 2020 quickly be forgotten; and may Curt always be remembered.

Such a tragic loss. His legacy will live on in his writings and his engineering projects. I will think of him each time I use my Legacy Engineering joystick and my Flashback 2; and when I read "Atari - Business is Fun" that he co-wrote with Marty. Condolences to his family.

Hi George! I recently discovered the trs80gp emulator and wanted to come here to AtariAge and share with everyone that after years of searching for a usable TRS-80 emulator, I've finally found one! So of course, I did a search first to see if anyone else had mentioned it, and imagine my surprise to find the author active in these forums! WOW!!! The TRS-80 Model I holds a special place in my heart, because although there was no way as a 17 year old that I could talk my family into buying one (...at over $2,000 of today's dollars), I went down to my local Radio Shack, bought a beginning TRS-80 BASIC book (I think it was Level 1... ...not sure), and then spent a few Saturdays at Radio Shack trying to type in programs on their demo machine. The first computer I actually OWNED was a Timex/Sinclair 1000, which also made use of the Z80 CPU. I enjoyed that for several years, and I now continue to explore BASIC programming using the EightyOne emulator, which features display scan lines and other video effects that really bring nostalgia in to the emulation experience. If only I could find a decent TRS-80 emulator with similar features... ...and now I have! Here's a screenshot of my desktop while running your fine emulator with appropriate wallpaper... I'm a software engineer at Walt Disney World now, and those early experiences with machines like the TRS-80 and the Sinclair had a definite influence on the direction of my career. The second computer that I owned was a TRS-80 Color Computer 2, by the way, but it just didn't seem to have the same kind of charm as these earlier models. Thanks again for your efforts in creating, well, it's just the BEST TRS-80 emulator I've ever seen! My discovery of this has been a real bright-spot during COVID-19 lock-down and spending my days working from home. Thank you! Thank you!

Planet Patrol This game adds to the challenge with the sun going down so you only see your enemies when you fire. I also like that it solves the "portrait orientation" problem that many arcade ports suffer by rotating the orientation 90 degrees and limiting the side-to-side (...or up-and-down) area of the screen. This seems more "fair" than a game like "Breakout", where the arcade game is squashed down to landscape orientation, and the ball flies at crazy angles that are just about impossible to handle once the ball is traveling at the higher speeds.

This is good: I think we need a separate category for vector-graphics games... So many great B & W raster arcade games... ...it's too hard to choose just one.

Yes, that would be great...

Interesting...

Fascinating! Do you have some sample code you could post to demonstrate this technique?

I am amused... ...just for fun I modified my Fibonacci sequence program above to also print the PEEK of the ERR_SP as discussed above with each iteration. I then ran it on the "stock" ZX81 with 1Kb of RAM... and it ran out of memory just before printing the stack-pointer value on the 40th ITERATION!! What are the odds? (Error code 4 at line 1060)

Thank you so much for that! I am constantly in awe of the brilliance that I find in the forums here. I re-configured my EightyOne emulator to a stock ZX81 with one Kb of RAM. The BASIC and operating system are stored in an 8Kb ROM. It seems to me that the Model 1 TRS-80 had a 4Kb ROM? Can anyone confirm? Anyway, here's a simple program to PEEK at the RAM addresses of the system variables, which start at the end of ROM. I modified my code from the example on page 136 of the Timex Sinclair 1000 manual. Using a "GOTO" the program runs happily for at least 4,000 iterations. Switching to a GOSUB in line 1040, the situation changes dramatically... The program stops with error code 4 (out of memory). I then execute a "PRINT N" command which returns 270, suggesting that the GOSUB stack has consumed all of the memory in 270 iterations (...unless the value of "N" has been corrupted). I looked up the ASM source code for the ZX81 ROM here: https://www.tablix.org/~avian/spectrum/rom/zx81.htm#L0EB5 If I'm reading this right, the GOSUB routine uses the "error stack pointer - ERR_SP" to store the return address for each GOSUB call at Hex address 4002: ;; GOSUB L0EB5: LD HL,($4007) ; sv PPC_lo INC HL ; EX (SP),HL ; PUSH HL ; LD ($4002),SP ; set the error stack pointer - ERR_SP CALL L0E81 ; routine GOTO LD BC,$0006 ; I experimented with PEEKing memory location 16,386 during each iteration, which I believe corresponds with Hex value 4002. Please point out any glaring errors in my thinking. THIS IS WHY I'M POSTING HERE! During my various experiments, I found that the starting address of this stack pointer varied with the length of my program, and then decremented two-bytes with each iteration. I found one case where it wrapped around zero (...this was before I had reduced my RAM from 16k to 1k in the emulator) and it started over at 255. Another interesting phenomenon I observed, is that once I had blown out memory space during a test run, the program wouldn't list fully anymore, and if I tried running it repeatedly, it would run out of memory in fewer iterations each time (...13, and then 3). The only remedy for this condition was a reboot, and then I'd have to type my program back in again. I could also save state in the emulator, and then reload it with an additional constraint that a snapshot will only load to an emulation model with the same memory model. From my computer science days in college, I believe heap-space grows upwards while stack-space grows down? This stuff is all very interesting to me. I'm tempted to try some additional experimenting with the Altirra emulator or the BeebEm for the BBC Micro, since those computers used the 6502 CPU instead of the Z80 in the Sinclair.

I'm inspired to do some testing to see just how deep the recursion can potentially go... Updates to follow.

My apologies for hijacking the topic on LOGO programming on the TI 99/4A computer. I think it's best to continue the conversation in this new thread. I was browsing the Rosetta Code website when I stumbled upon this Recursive example of the Fibonacci sequence on the Sinclair Z81. 10 INPUT N 20 LET A=0 30 LET B=1 40 GOSUB 70 50 PRINT B 60 STOP 70 IF N=1 THEN RETURN 80 LET C=B 90 LET B=A+B 100 LET A=C 110 LET N=N-1 120 GOSUB 70 130 RETURN I was quite surprised to see how similar it was to my second attempt at demonstrating recursion in BASIC using a subroutine. ...a quick style note: I prefer to start BASIC Programs with line 100 - allowing for a zeroth line number for a remark naming the program. This also allows for 99 lines of code without any changes in indentation of the line numbers - retaining ten lines between each for the insertion of other lines. I prefer to number all subroutines in the thousands; creating a visual "break" between the "Main" routine and the subroutines. In the Fibonacci example above, the sequence is not created; rather the nth Fibonacci value is returned based on input "N". I find it much more interesting to present the sequence, so I have modified the Rosetta Code example to display the sequence from 1 to 40 (an arbitrary value). Here's what I came up with: Another Sinclair ZX81 example from Rosetta Code is very interesting: 10 INPUT N 20 PRINT INT (0.5+(((SQR 5+1)/2)**N)/SQR 5) This one also displays only the nth number, so here it is reworked to display the sequence up to the 40th iteration: The output of this example is identical to the Recursive solution. I have to say, playing around with this stuff using the EightyOne emulator is such a joy. The BASIC language commands are all laid out for me on the keyboard with a single button-press for each keyword; which means no typos. The syntax is checked as each line is entered and a new line of code isn't added to the listing until it is syntactically correct. Each line of a listing can be selected for editing, including the line numbers, which is extra helpful for moving things around and repeating code lines that differ only by one or just a few characters.

Isn't it a better practice to have labels on a line by themselves? It looks odd to me to have a label followed by commands and operands... ...just sayin'

I'm always amused when a necrobump happens to a topic thread that's been dormant for over a year with no explanation whatsoever...

...And while I'm on the topic of this YouTube video (...or perhaps I've hijacked the topic here... ...sorry), I think I've spotted some errors. I'm very new to Assembly Language (on any CPU) so I'm looking for some confirmation. He explains that spaces matter in the Assembly cartridge, and shows the columns and what should go there: ...then he makes a point of "accidentally" forgetting to add an extra space when he types in the Load Accumulator command (LDA #0) so he can show how the assembler flags it as an error. BUT, he completely ignores the fact that he's left the Clear Carry Flag (CLC) command in the "Label" column (...and he refers to it as the "comments" field several times...). I'm guessing that clearing the carry flag isn't particularly important in this case (...maybe because he starts counting up at zero?) so it doesn't matter... The other thing that seems wrong; he indicates how important it is to end the ASM routine with an "END" statement, which he again puts in the LABEL column, so the word "END" is treated as a label. Is "END" even the right command in this case? I run it through the debugger as a trace as entered, and I see that the final command executed is "BRK'. So just for fun, I tried different values in the label field of the final command. It turns out, the program ends exactly the same way with whatever label I stick in there: It also ends without error with a "BRK" command, either as a label or as an opcode: Am I getting all of this right? I really don't want to trash this guy because he has several videos and I have found them very helpful. And it's pretty cool that he's demonstrating everything using an actual 130XE and the actual Assembler/Editor cartridge. I would just like some confirmation as I learn about new things that I'm understanding these things correctly. Thanks!

It's funny, because just the other day I made the same mistake while following along with the video here: He uses a starting address of $1000 (4096, I believe...) ...I kept wondering why my code assembled to starting address x03E8. I found that I could run it using G03E8 or T03E8, but I couldn't figure out why...

In some dialects of BASIC, doesn't a GOSUB with no corresponding RETURN result in a syntax error? Or is that only "FOR" without "NEXT"? ...wait a second; I think I've figured it out: ...Line 1050 could just as easily be a "GOTO", but the whole idea is that the subroutine "calls itself", which is more clear with the use of the "GOSUB". However, if a "GOTO" is used instead, line 1060 is no longer needed because the subroutine returns to the line after 180 where it was called. I just want to send thanks to everyone participating in this thread. I really enjoy thought provoking discussions like this that I find frequently here at AtariAge. Shout-out to @Albert !!!

I fired up the Sinclair "EightyOne" emulator to play with this. Using "GOSUB" doesn't seem to work very well unless it's wrapped in a conditional "GOTO" loop or "FOR" loop. I decided to just use a "FOR" loop with the number of iterations based on the input. The input prompt warns against numbers greater than 15, but it still works with an answer in scientific notation and some loss of precision for larger numbers. I don't check for non-numeric input but the ZX81 halts the program with error codes if that's the case. I'm probably using more variables than I need to (...and of course, in BASIC they're all global), and I don't know that this example really captures the "spirit" of what recursion is (...since a "FOR" loop doesn't really "unwrap" the return values the way a recursive function call does). In any case, I never thought of recursion as being the major selling point of LOGO anyway. To me, the appeal is more the nature of quick visual feedback of experimentation of concepts, and the building of complexity through iterations of simple sub-units. I've always found BASIC to do fine with these ideas too. I'm encouraged to hear that there are some school districts teaching the "Scratch" language. I'm familiar with it, although I haven't taken the time to play with it at all (...truth be told, I haven't played with LOGO either). Going back to my earlier post though, I don't think the point of teaching a programming language to children is to prepare them for careers in computer science, any more than teaching basic mathematics is to prepare them to become accountants. I think it is more to the idea of teaching approaches to problem solving and learning with concepts such as analogies, abstraction, and algorithms.

I am curious (...and somewhat concerned) about why computer programming using LOGO and/or BASIC is no longer part of elementary and middle school curriculum. These disciplines augment mathematics for teaching concepts such as analogies, methodologies and algorithms. Is learning how to learn and learning how to think no longer important?