Legacy versus ARM-based 2600 Game Development

[Legacy versus ARM-based 2600 Game Development]

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

 

[The Knight Rider 2600 project]

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

[Curt Vendel has passed away. :(]

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.

[Preferred Model III emulator?]

On 4/14/2018 at 3:36 AM, George Phillips said:

trs80gp will load a BASIC program in either ASCII or tokenized form from the command line. Usually "trs80gp program.txt" is all you need.

 

You can edit inside the emulator and use LLIST to save a copy (which gets appended to trs80-printer.txt).

 

Or you can CSAVE and it'll let you save it as a ".cas" file. But then it isn't as easy to convert that back to ASCII.

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!

 

[What are the best 2600 games most people have never played?]

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.

[Favorite black-and-white arcade games]

On 7/23/2015 at 7:19 AM, Keatah said:

RASTER:

Night Driver

Sprint 2

Starship

Sky Raider

 

VECTOR:

Lunar Lander

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.

[Exploring Recursion in BASIC]

Yes, that would be great...

 

[Exploring Recursion in BASIC]

Interesting...

 

[Exploring Recursion in BASIC]

On 5/30/2020 at 5:58 PM, JamesD said:

Even though BASIC doesn't have local variables, you can simulate them in arrays.  <hint, hint>

 

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

[Exploring Recursion in BASIC]

On 5/29/2020 at 7:32 AM, carlsson said:

You can recurse up to 40 levels on an (expanded) ZX-81? That's cool, compared to only 23 levels on e.g. the VIC-20, due to the stack space is used up. I suppose it is true also for newer computers that eventually you'll run out of stack space or other form of nesting when you recurse like that, which is why algorithms preferably are rewritten to avoid recursion.

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)

[Exploring Recursion in BASIC]

On 5/31/2020 at 1:04 AM, phoenixdownita said:

Any recursive program admits an iterative version in which you hold the state needed, which for true recursion can grow at each call, that is to say you can build your own stack and introduce whatever other limits you see fit if the machine/language stack is too limiting ... it may run slower but ...

 

If the problem lend itself to tail recursion then it's not even recursion anymore and the iterative solution uses constant space ... like the Fibonacci series you are using, it should be possible to replace the recursive gosub with goto (not sure about the BASIC you are using but try to replace the gosub in line 1080 with a simple goto, no recursion)  no recursion really needed as the problem only necessitates to keep state for the "last 2" to generate the next .... all of it being moot nowadays due to Fibonacci sequence admitting a closed form (as you reported already) but there are other fixed state problems that can be solved the same way (aka replace recursion with iteration and a fixed amount of state).

 

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.

[Exploring Recursion in BASIC]

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

[Exploring Recursion in BASIC]

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.

 

 

[Why doesn't this assembly program work?]

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'

[My Atari XEGS Project]

On 5/25/2020 at 8:29 PM, universal2600 said:

Interesting makes me curious what if one used a Motorola 68008 cpu 🤔🙃

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

[Why doesn't this assembly program work?]

...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!

 

 

[Why doesn't this assembly program work?]

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...

[LOGO anyone?]

36 minutes ago, almightytodd said:

 

Oh! Even better! ...leave line 1050 as-is and replace line 1060 with another RETURN! It works!

 

[LOGO anyone?]

6 minutes ago, senior_falcon said:

From the TML demo program:

100 !BINARY SNOWFLAKE FOR TML
110 FOR I=1 TO 3 :: X=1.6 :: L=37 :: A=30 :: B=(L+.01)/X^6 :: GOSUB 130 :: CALL LINK("TURN",120):: NEXT I
120 GOTO 120
130 IF L<B THEN L=L*X :: RETURN
140 CALL LINK("TURN",-A):: CALL LINK("FWD",L):: L=L/X :: GOSUB 130 :: CALL LINK("FWD",-L,A*2):: CALL LINK("FWD",L):: L=L/X :: GOSUB 130
150 CALL LINK("FWD",-L,-A):: L=L*X :: RETURN

That is MONDO COOL!!!

 

 

[LOGO anyone?]

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 !!!

[LOGO anyone?]

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.

[LOGO anyone?]

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?

[Intellivisionaries episode 38 is up!]

The interview with Jason Enos is awesome! I really loved hearing about his start with Sega.

 

[History of Commodore from the 8-bit Guy on YouTube]

I enjoy all of the 8-bit Guy's videos, but this is his project that I am most interested in:

 

 

There's already an emulator for it so you can experiment with it before it even exists...

https://github.com/commanderx16/x16-emulator

 

[Timex-Sinclair 1000/ZX-81 vs. 3M Post-It Note]

37 minutes ago, JamesD said:

The CoCo came with the chicklet keyboard until the intro of the white version.  That's when they introduced the "melted" keyboard.  1983?
That keyboard is pretty good.  The chicklet keyboard was okay, but you had to clean it to keep keys from sticking after a while.
The VIC has more colorful graphics than the CoCo, but the CoCo has bitmapped graphics.  Resolution, and number of characters per line favor the CoCo.
By 1982, 64K CoCo upgrades were becoming common by 1982, and I think Tandy was selling 64K units in 1983.  That's also when the CoCo 2 came out.
The CoCo had a large number of peripherals, though a lot were 3rd party.  Disk drives, digitizers, expansion boxes, sound & speech upgrades, printers, modems, plotters, ...

One category you left out is BASIC. 
EXTENDED COLOR BASIC was the best out there at the time. 
Speed wise, the CoCo was pretty fast once you used the high speed POKE.
Too bad they didn't take advantage of the 6809's hardware multiply in the floating point math library.

Productivity software favors the CoCo.  The bitmapped graphics were commonly used to display upper and lower case text.

 

Gould was a disaster for the company, and the Amiga.

I'm amused that you're discussing the CoCo as a competitor to the other home/hobby computers of the day featuring color capabilities. A CoCo 2 with a "melted" keyboard was my second computer; after first owning a TS1000. I've only recently come to appreciate the capabilities and potential of the Motorola 6809 CPU. Strictly speaking of the eight-bit era, it was one of the best if not THE best of the eight-bit CPUs.

 

Ironically, I kinda feel like the main competitor to the 6809 was Motorola's own 68000 32-bit CPU. As I understand it, the assembly language coding is somewhat similar between the two. It was a far more sophisticated (and expensive) chip than any of the eight (or even 16 bit) chips of that era, but as evidenced by Apple, Atari, and Amiga/Commodore's embrace of it; it was clearly the direction of the future for the non-Intel CPU route.

 

The thing I grapple with for home color-enabled 8-bit systems, was that to really leverage the power of color for science, education, or business, you really needed an honest to goodness color monitor. But back in the early 80's, those things were like 800 bucks! -- much more expensive than most of the computers you might be hooking them up to. The Commodore 128 screen output looked great in 80-column mode on a high resolution color monitor, as did the CoCo 3. But when the average Joe hobbyist/home computer nerd was putting together a full system; with disk drives and maybe some kind of printer, a color monitor would push the whole package into the $2,000+ range, and all of a sudden, a Macintosh or IBM compatible began to make a lot more sense; even if that meant abandoning color in favor of higher resolution monochrome.

 

Anyway, I really appreciate all of the discussion here and the fond memories of my early years of computing. I find this all the more exciting with the recent (limited) releases of the C-64 full-sized computer and the new ZX Spectrum NEXT. Exciting times for retro-computing...