Jump to content
Starsickle

RETROTrek - Early Development Thread

Recommended Posts

]Introduction - Welcome to RETROTrek

Hello, everyone! Having gotten the itch to program something AND do some community contributing, I've decided to try my hand at a small game. One of my memories from elementary school was playing games on the C64 and the PET. One of them was a Trek-Clone. There were many, many Star Trek games on old computers, and that trend went way into the DOS-era systems. So, I thought it would be interesting to try my hand at one, myself. Welcome to "RETROTrek". Inspired by years and years of Trek-clone games, some as far back as 1967 and 1972 - RETROTrek follows in the vain of old trek games for the C64 and PET, but with the aim to evolve and improve on the design and experience.

You can check out progress at my GitHub - RETROTrek Github Project Tracker

THE BIG THREE THINGS OF RETROTrek

    1. A tribute to early EGA and VGA trek-clone games - for the Commander X16 first, and hopefully compatible with the Commodore 64
    2. Simple design - Text and Grid based for the platform CharSet. Has to be a FINISHABLE game project.
    3. Easy to play - everything displayed on same screen.

You are a freshly minted Starship captain of an alliance of peace-loving explorers that has been tasked with exploring an unexplored and contested region of space. Your ship and crew are ready for your commands. The game takes place on a 20x10 grid representing this uncharted region of space, with each grid location being a sector that is a 10x10 grid. In this area, you must Explore, Survive, and fight the evil KLORG - the alliance's foremost enemy.

Knowing that this might be something I may not absolutely ever finish, I've decided to develop the game's features in distinct phases.

PHASE 1 - ONE OF EVERYTHING AND REPEATED SECTORS
    
This phase will be completing a game that has only the absolute minimum loop. WARP will simply move you to a new area to explore before you continue on. Perform tasks to gain points. Do this 10 times, and you win. Very simple.

Phase 1 will be about getting all the the core systems and programming structure in place, and setting the state for expansion. Because I am not familiar or particularly experienced with this version of BASIC, It'll be a struggle, but I am no stranger to new things, and I am mostly working on engine parts. Aim Low, Deliver High.

PHASE 2 - SPACE, THE FINAL FRONTIER

This phase will introduce a navigable 20x10 map of space. The WARP command will now take you to a destination of your choosing. As well, what appears on the two maps will be Masked and requiring scanning to reveal. I expect to add most of the more fun bits that will create the game part of the game in this phase. For Phase 2, there's tons of things I'd like, but given the idiosyncrasies of BASIC, I might be limited.

PHASE 3 - SPACE WITHIN SPACE

This phase will extend the components created in Phase 2 by extending them to the sector map. Here, we will introduce a space within space in the 10x10 Sector map; drawing us closer to the old EGA trek-clones. As well, the movement commands should work as originally intended, and the player will be able to freely navigate the stars, orbit planets, and perhaps other space functions like hailing, bartering, and of course - being stranded and needing aid.

By the end of this, I will have a game that will have three game modes:

  1. Explore - Your primary mission is to explore/make contact with a sufficient amount of objectives in the region. Be careful, though!
  2. Secure - Your primary mission is to survive the spacial region long enough to eliminate the objective number of Klorg ships.
  3. Contact - Your primary mission is to make contact with an objective number of populated alien planets.

PLANNED FEATURES (Not a complete or final list)

  • Turn Mechanics (Passive and Active uses of resources and crew each turn)
  • Combat mechanics (Phase Cannons, Torpedos, and Particle Streams)
  • Game Over Conditions (Crew Dead/Mutiny, Ship dead in space, Turn Limit)
  • Self-Destruct (Simple, Animated, Fancy)
  • Randomly Generated Maps
  • Regional Discovery Mask (Fog of War)
  • Region and Sector Simulation per X turns (The REALLY hard part.)
  • Random Generated Alien Species and Planetary Systems (Tough, but doable!)

THIS THREAD AND EARLY DEVELOPMENT

I am sure I will need lots of help, but I'm confident that I can at least get phase 1 complete if I try. This is a project I don't expect to finish or devote much of my time to, so I hope I can make big inroads to progress to something interesting and fun. If anyone has any thoughts or advice/tips about this, please post up! I'd be interested in hearing what you think is possible or desirable for this game. I created the thread for the purpose of early development discussion, as I don't think I'm quite ready to put a non-game on the site for download.

When Phase 1 is functionally ready to be played, I will post the initial version and this thread will change or be moved/locked.

 

 

 

RetroTrek-01.png

RetroTrek-02.png

RetroTrek-03s.png

Edited by Starsickle
Overhauled OP for Progress and Information
  • Like 1

Share this post


Link to post
Share on other sites

Heh, we could probably do a whole thread on just the Star Trek clones people are (re) writing. I've been working on my own version that's more like the original Mayfield version, but with 100% new logic and without some of the awkward things he did to optimize the game (like joining two subroutines halfway through to save code space.) I actually went through and documented all of Mayfield's variables and code blocks, so I could reproduce the program with 100% new code.

In my case, I wanted to make the same program work on several different computers: The Altair 8080, Tandy Model 102, IBM PC with Advanced BASIC, the Commodore 64, Commodore 128, and Commander X16. So while it won't take advantage of the CX16's special features, my program will work as close to the same as possible on a wide array of computers. Obviously, the Tandy 102 with its 40x8 screen will look different than the Commander X16, with its 80x60 display... so I'm making all of the routines modular and re-porting from the Altair version as my baseline. 

Anyway - the text-based Star Trek game is one of my favorites, so I'm glad to see someone else coming at it from a different angle. It looks good - keep it up.

Edited by TomXP411
  • Like 1

Share this post


Link to post
Share on other sites

I wasn't aware! I should probably be learning from the others. I'm sure what I have in mind isn't what others have in mind, and others probably have much higher proficiency in this language and platform than I do.

You're in for quite a task for such wide cross compatibility for a single game. There was a good reason, I think, that so many clones of this game were so different from one to the next. Heck, I remember one game that I still can't find that was 1-4 ships (you could play as Feddy, Klingon, Romulan) on a blank playing field, and you would pause the game to change heading and speed, fire weapons, or even beam over crew to attempt to board other ships. 2-players on that one was a painful experience!

Anyways, some progress since I've posted. I've started separating out code to test individual screens and methods, and it's coming along well. Pic attached.

I also added a 5th color scheme - OLD 286. I'll show all of them off, eventually.

Some work needs to be done on layout and spacing of text, but it's coming along. I'm having trouble with WAIT - as it seems it's incompatible. I don't know what I'd use to do a "PRESS ANY KEY TO CONTINUE" without perhaps STOP, but I could use some examples. I haven't taken time to play many of the other games, yet.

Another problem is the right and bottom edges of the screen - which are giving me trouble to properly fill with colored space characters. I always end up a bit off - you can see how in my previous screens.

As for game mechanics - I'm still very focused on program structure and establishing conventions and codebase for myself.

Finally, I think I may wish to include some simple sounds, but these seem to be written in assembly - I don't know if I could do the same in BASIC and then make some subroutines out of them?

RetroTrek-WIP6.png

Edited by Starsickle

Share this post


Link to post
Share on other sites

You can wait for input with just the INPUT command. Unless I'm misunderstanding the question?

Quote

INPUT "PRESS ANY KEY TO CONTINUE"; IN$

You can definitely make some simple sound effects with the PSG register in BASIC (you could do any sound in BASIC, really, but using the YM2151 is more complicated). You mentioned though that you'd like it to be compatible with the C64, and any sound-related stuff wouldn't be.

Share this post


Link to post
Share on other sites
3 hours ago, Ender said:

You can wait for input with just the INPUT command. Unless I'm misunderstanding the question?

More like

	POKE 198,0: WAIT 198,1
	

The system waits until any keyboard key is pressed. This would be handy for a number of things, including what will be the message queue.

Which does not work, but is given in documentation. the X16 docs tell that WAIT is incompatible, and that seems to jive well enough with my own tests with that statement.

Share this post


Link to post
Share on other sites

Here's a small image of the color schemes, which you can currently set in game.

Once I figure out what problems necessitate a graphics mode change, I'll work on that code and add it to the options. For now, the default configuration is 80x60 characters.

Currently working on making a Queue for the reports area - something I haven't done since Data Structures 215...

RetroTrek-WIP8.png

Share this post


Link to post
Share on other sites
5 hours ago, Starsickle said:

More like

 


	POKE 198,0: WAIT 198,1
	

 

The system waits until any keyboard key is pressed. This would be handy for a number of things, including what will be the message queue.

Which does not work, but is given in documentation. the X16 docs tell that WAIT is incompatible, and that seems to jive well enough with my own tests with that statement.

You don't need WAIT or POKE to just wait for a keypress. You use GET. 

100 GET A$:IF A$="" GOTO 100

This is the correct way to do it in BASIC. 

Edited by TomXP411

Share this post


Link to post
Share on other sites
8 hours ago, Starsickle said:

I'm having trouble with WAIT - as it seems it's incompatible. I don't know what I'd use to do a "PRESS ANY KEY TO CONTINUE" without perhaps STOP, but I could use some examples.

WAIT is not meant for keyboard input. That waits for a memory location or port address to be set to a particular value. 

GET is the command to read a key from the keyboard. 

GET is non-blocking, continuing execution if the keyboard buffer is empty. In that case, it returns a null string (""). Otherwise it returns the first key waiting in the keyboard buffer.

This will wait for a keypress:

100 GET A$: IF A$="" THEN 100

Or you can just fall through if you want to keep action going: 

100 GET A$
110 IF A$="T" THEN GOSUB torpedo_subroutine
120 IF A$="P" THEN GOSUB phaser_subroutine
200 animate lights and sounds....

etc.

 

  • Like 1

Share this post


Link to post
Share on other sites

And in case you don't know about the Commodore's random number generator, the time to seed it is after that key has been pressed.  And you'll want to do it like this:

	R = RND(-TI)  :REM SEED PRNG
	

 

I'm one of the guys doing a space retro clone game thingy.  My target is Traveller, rather than Trek, and I've got a couple of early programs in the repo, but with r38 I can start on the Magnum Opus.

Edited by rje

Share this post


Link to post
Share on other sites
1 hour ago, TomXP411 said:

GET is non-blocking, continuing execution if the keyboard buffer is empty. In that case, it returns a null string (""). Otherwise it returns the first key waiting in the keyboard buffer.

This will wait for a keypress:

100 GET A$: IF A$="" THEN 100

Or you can just fall through if you want to keep action going: 

100 GET A$
110 IF A$="T" THEN GOSUB torpedo_subroutine
120 IF A$="P" THEN GOSUB phaser_subroutine
200 REM //STUFF

 

 

Ah, thank you. That solves that. That will enable some greater control over things.

Hmm...As a quick aside - would you say this is a good reference?
https://www.c64-wiki.com/wiki/C64-Commands

It seems that I've run into a few hiccups and mistakes having followed it in the last few days. If there is a better reference out there, feel free to throw some my way.

1 hour ago, rje said:

And in case you don't know about the Commodore's random number generator, the time to seed it is after that key has been pressed.  And you'll want to do it like this:


	R = RND(-TI)  :REM SEED PRNG
	

I'm one of the guys doing a space retro clone game thingy.  My target is Traveller, rather than Trek, and I've got a couple of early programs in the repo, but with r38 I can start on the Magnum Opus.

Can you expand on that? I've seen RND(), but you're saying there's some seeding based detail surrounding this one? I was just planning on calling it each time I needed a new number.

Traveller, eh? I might have to look that one up. I might have heard of it in passing. Always up for good ideas.

Share this post


Link to post
Share on other sites
2 hours ago, Starsickle said:

Ah, thank you. That solves that. That will enable some greater control over things.

Hmm...As a quick aside - would you say this is a good reference?
https://www.c64-wiki.com/wiki/C64-Commands

It seems that I've run into a few hiccups and mistakes having followed it in the last few days. If there is a better reference out there, feel free to throw some my way.

Can you expand on that? I've seen RND(), but you're saying there's some seeding based detail surrounding this one? I was just planning on calling it each time I needed a new number.

Traveller, eh? I might have to look that one up. I might have heard of it in passing. Always up for good ideas.

Yes, that's a good reference. Use that in conjunction with the Programmer's Reference Guide that comes with the emulator, since some new commands have been introduced into the language.

are you new to BASIC, or just to the Commodore flavor?

 

Share this post


Link to post
Share on other sites

RND() is something I learned only in the last several years.  And... it's well documented in the C64 wiki you quoted (yeah, I think that's a good reference!).

A negative number seeds the PRNG.  A positive number returns the next random number.  And a zero... just doesn't work well.

So you want to seed it with TI, the system timestamp.  So, negative TI.  But, you want a human element to effectively randomize WHEN that seeding happens... hence "press any key to continue".  I note that this also works really well:

...
INPUT "YOUR NAME"; NA$
R=RND(-TI)
...
	

...that way, you've also gathered info by which to record his score for the leaderboard...

 

Edited by rje
  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, TomXP411 said:

Yes, that's a good reference. Use that in conjunction with the Programmer's Reference Guide that comes with the emulator, since some new commands have been introduced into the language.

are you new to BASIC, or just to the Commodore flavor?

 

Just to Commodore - I can't say opening up the manual when I was about 9 was legitimate programming experience. =P It's been about 28 years since I've touched the keywords POKE and PEEK. I've been tinkering with SMILEBasic4 after it came out (it's fun!) and I have some experience with VB/VBA, but VB is high level compared to C64. I deal mostly in High level languages. You won't see me doing assembly. I C'd my way through that course.

Slowly but surely I'll get it all figured out. This morning I just finished the message queue, but with a funny quirk - because the dimensioned array is filled with lines of nothing, a nothing gets shifted at the boundary the first time anything is added to it, resulting in a single gap. The queue otherwise works fine, though, and is ready to be integrated into the game's Report-spam window. I can fix that later.

Quote

 

RND() is something I learned only in the last several years.  And... it's well documented in the C64 wiki you quoted (yeah, I think that's a good reference!).

A negative number seeds the PRNG.  A positive number returns the next random number.  And a zero... just doesn't work well.

So you want to seed it with TI, the system timestamp.  So, negative TI.  But, you want a human element to effectively randomize WHEN that seeding happens... hence "press any key to continue".  I note that this also works really well:

 

Oohhh, I see what you're talking about. You have to seed system before pulling from RND and that requires the -TI, which is the system's current time. Not sure why I was confused, now. Lack of sleep and coffee.

Edited by Starsickle

Share this post


Link to post
Share on other sites
Quote

You won't see me doing assembly. I C'd my way through that course.

I got a C in 8086 assembly (it was a four credit course!  ouch!), a million years ago, but that doesn't stop me from writing assembly when I think I can get away with it.  6502 is easier anyway.  For me though it's a matter of necessity: I won't write it unless I have significant runtime delays I need to seriously reduce.  Or if I can do something useful in 256 bytes or less.

And I do work high level in my real job.  As in, React, and Java.  And I write Perl for fun.  Actually, I wrote Perl utilities to get around the limitations of BASIC 2.0... including a filter that lets me code with labels, no line numbers, and combines multiple source files (all of which is EXTREMELY helpful), and even a thing that simulates simple data structures (I don't use the latter -- it's really hacky).

 

Edited by rje
  • Like 1

Share this post


Link to post
Share on other sites
22 hours ago, rje said:

And I do work high level in my real job.  As in, React, and Java.  And I write Perl for fun.  Actually, I wrote Perl utilities to get around the limitations of BASIC 2.0... including a filter that lets me code with labels, no line numbers, and combines multiple source files (all of which is EXTREMELY helpful), and even a thing that simulates simple data structures (I don't use the latter -- it's really hacky).

I would find that ability very useful, as I like to create parts and pieces and then assemble them. With organizing and convention, you can make larger and larger things more quickly.

Share this post


Link to post
Share on other sites
On 9/6/2020 at 5:39 PM, Starsickle said:

I would find that ability very useful, as I like to create parts and pieces and then assemble them. With organizing and convention, you can make larger and larger things more quickly.

And the two-letter variable limitation really causes a problem for long BASIC programs, when I start to lose track of my variables, because I don't have a separate document with a dictionary of variables I'm using and where they're used, etc.

  • Like 2

Share this post


Link to post
Share on other sites

Been taking it easy last day or so. Discovered a strange problem with the message queue, where the last line will force the top screen lines to be drawn at the bottom and render the game unresponsive. Definitely a baddie, but likely caused by a logical problem when PRINT and LOCATE are used before the next loop at the last queue line. The queue functioned fine before, so it must be something elsewhere. Will track it down and smash it.

There is another bug with game start repeating Self-Destruct Entry Code, ut this is related to the program segments in lines being disorganized. It's time for some code cleanup.

Otherwise - with the Mission start and game over screens complete, I though I'd implement the "PRESS ANY KEY" as advised, but I've found that...it doesn't work. It just goes right through.

I've tinkered with pic below and a few guides on GET just to see if I'm not using it correctly, but code below seems to be on mark with what I was told would work.

10 PRINT "TESTING ANY KEY TO CONTINUE!"
11 A$ = "A"
20 GET A$: PRINT "YOU TYPED: "A$
21 IF A$="" THEN 40
30 PRINT "NO NO NO STOP" : STOP
40 PRINT "CONTINUING" : END

As a note: I've tried this by initializing A$ to "", "1", ""0", and "A". I've looked around the site for comparable code to see what I might be doing wrong, but have not yet found a piece to draw from. I don't want to post problems like this in programming help, as it's not clear if it's something with the emulator, something with the way I'm using it, or something else. I just wanna let everyone know I am looking things up and tinkering before posting here with a programming-related issue. I figure I'll find an answer by asking faster than staring at things that are 40 years old.

GET PROBLEMS.png

Edited by Starsickle

Share this post


Link to post
Share on other sites
3 minutes ago, rje said:

And the two-letter variable limitation really causes a problem for long BASIC programs, when I start to lose track of my variables, because I don't have a separate document with a dictionary of variables I'm using and where they're used, etc.

Absolutely - it's one of the most annoying and infuriating parts of designing a C64 program to me so far. If this could be overcome, being able to use meaningful names would be a godsend. Sadly, I'm not sure how absolutely committed the interpreter for BASIC 2.0 on this new platform has to be to the hardware that AB$ is the same as ABC$

Edited by Starsickle

Share this post


Link to post
Share on other sites
25 minutes ago, Starsickle said:

Absolutely - it's one of the most annoying and infuriating parts of designing a C64 program to me so far. If this could be overcome, being able to use meaningful names would be a godsend. Sadly, I'm not sure how absolutely committed the interpreter for BASIC 2.0 on this new platform has to be to the hardware that AB$ is the same as ABC$

It's committed to Commodore BASIC, forked and modified from version 2.0.  

It can have many improvements, such as better garbage collection (stolen from BASIC 4.0).  Michael's already added drawing commands, a feature-rich set of "DOS" commands, and prefixes for hexadecimal($dc) and binary numbers(%11011100).   It can have a MOD infix (needed!).  It could conceivably have improvements from Simon's BASIC, or from Compute! magazine's SuperBASIC, or any number of alterations of Commodore BASIC.  Heck, maybe it could even have native integer operations. But unless someone is going to dive into the interpreter and modify it for long variables, I doubt it's going to have that. Same goes for some modern control flow syntax.

 

A tool could potentially help here too.  I've thought about this one: my raw listing could have long variable names mapped to valid, short ones.  The easiest way to do that would to have actual data dictionary entries that looked like this in the raw source:

var mylongvarname$ ml$

Every time the translator would find one of these, it would check its hashtable to make sure the long variable and short variable aren't already declared -- and would die if they were.  Otherwise, it would create new entries, and replace the long variable name with the short one in the transpiled BASIC.

This would force me, ahead of time, to declare the variable mapping, and force me to change the mapping when there's a collision.

Hmmm.  The more I think about it, the more I like it.

Edited by rje

Share this post


Link to post
Share on other sites
7 minutes ago, rje said:

It's committed to Commodore BASIC, forked and modified from version 2.0.  

It can have many improvements, such as better garbage collection (stolen from BASIC 4.0), and drawing commands, and a feature-rich set of "DOS" commands.   It could conceivably have improvements from Simon's BASIC, or from Compute! magazine's SuperBASIC, or any number of alterations of Commodore BASIC.  But unless someone is going to dive into the interpreter and modify it for long variables, I doubt it's going to have that.

A tool could potentially help here too.  I've thought about this one: my raw listing could have long variable names mapped to valid, short ones.  The easiest way to do that would to have actual data dictionary entries that looked like this in the raw source:


var mylongvarname$ ml$

Every time the translator would find one of these, it would check its hashtable to make sure the long variable and short variable aren't already declared -- and would die if they were.  Otherwise, it would create new entries, and replace the long variable name with the short one in the transpiled BASIC.

This would force me, ahead of time, to declare the variable mapping, and force me to change the mapping when there's a collision.

Hmmm.  The more I think about it, the more I like it.

That's encouraging to hear! Perhaps put this in Issues or feature requests? The good news is not everything in software is monolithic and set in stone.

Edited by Starsickle

Share this post


Link to post
Share on other sites
Just now, Starsickle said:

That's encouraging to hear! Perhaps put this in Issues or feature requests? The good news is not everything in software is monolithic and set in stone.

Yes, add in a request in the ROM project on Github.  

Share this post


Link to post
Share on other sites
2 hours ago, Starsickle said:

Otherwise - with the Mission start and game over screens complete, I though I'd implement the "PRESS ANY KEY" as advised, but I've found that...it doesn't work. It just goes right through.

I've tinkered with pic below and a few guides on GET just to see if I'm not using it correctly, but code below seems to be on mark with what I was told would work.


10 PRINT "TESTING ANY KEY TO CONTINUE!"
11 A$ = "A"
20 GET A$: PRINT "YOU TYPED: "A$
21 IF A$="" THEN 40
30 PRINT "NO NO NO STOP" : STOP
40 PRINT "CONTINUING" : END

As a note: I've tried this by initializing A$ to "", "1", ""0", and "A". I've looked around the site for comparable code to see what I might be doing wrong, but have not yet found a piece to draw from. I don't want to post problems like this in programming help, as it's not clear if it's something with the emulator, something with the way I'm using it, or something else. I just wanna let everyone know I am looking things up and tinkering before posting here with a programming-related issue. I figure I'll find an answer by asking faster than staring at things that are 40 years old.

 

I think what you're looking for is something like this. You want it to keep waiting until A$ isn't "".

Quote

10 PRINT "TESTING ANY KEY TO CONTINUE!"

20 GET A$: IF A$ = "" THEN 20

30 PRINT "YOU TYPED: "A$

40 PRINT "CONTINUING": END

 

  • Like 1

Share this post


Link to post
Share on other sites
23 hours ago, rje said:

when I start to lose track of my variables, because I don't have a separate document with a dictionary of variables I'm using and where they're used, etc.

There's an obvious solution to that.  😉

That is exactly what I've started doing. I keep a companion document with variable names and the line numbers of subroutines, so I can refer back to them as needed. While 2-character names still bite, I find that they're a lot easier to deal with when I have a data dictionary right there on the screen.

When the eventual BASIC editor for CX16 comes to fruition, I hope it comes with a tool to keep notes in a separate file that we can switch back and forth to at any time...

  • Like 1

Share this post


Link to post
Share on other sites
14 hours ago, TomXP411 said:

There's an obvious solution to that.  😉

That is exactly what I've started doing. I keep a companion document with variable names and the line numbers of subroutines, so I can refer back to them as needed. While 2-character names still bite, I find that they're a lot easier to deal with when I have a data dictionary right there on the screen.

When the eventual BASIC editor for CX16 comes to fruition, I hope it comes with a tool to keep notes in a separate file that we can switch back and forth to at any time...

Or we can go full IDE and it just knows all the variables, subroutines, tasks, TODOs, FIXMEs, and parameters in the project. A lot of work, but worth it if you're serious about a platform.

If we have a mouse, CTRL-C, CTRL-F, and CTRL-V, we can program in THIS century. XD

Update for today: I've dusted off the old Github (https://github.com/Starsickle) and I'm back up and running. No projects yet, as I'm basically in the "notepad and copypaste it into EMU" phase of things. I would love an IDE, so if ATOM or IDEA or ECLIPSE have something for C64 basic or X16 Platform BASICv2, please let me know.  I have, however, submitted two issues to the rom project and looking for things I may be able to contribute to, including documentation and tutorials.

On the RETROTrek side of things, I'm currently working on understanding how to read and write complex data into and out of arrays, but I may have bitten off more than I can chew - this is the subject that's halted my SMILEBasic project, as I am used to high level data structures and OOP doing all the heavy lifting instead of the highly segmented memory management and sequential R/W situation in BASIC.

Otherwise, I am also currently doing some code cleanup. It's been rough recently, so I'm going to slow down a bit and focus on filling out the things I can find that are easy to calculate and build and test.

Edited by Starsickle
Today's stuff.

Share this post


Link to post
Share on other sites

Atom does have BASIC support, but it also has a really nice package for 6502 assembly, supporting all the major assemblers including ca65.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use