Jump to content
IGNORED

Question about 6502 Assembly source code and Merlin (Apple II)


Recommended Posts

Over the weekend I finally took a dive into assembly language programming. Things are going smoothly so far (managed to get a square to move around the screen on command and play different tones with different keys, etc).

 

Fun, fun.

 

But here's where I'm scratching my head:

 

When I was programming in BASIC, I would often write the source code in notepad and then load it to a disk image with Ciderpress (an Apple II file management program for Windows). Then I'd test it through emulation. This proved to be very efficient for me and I was able to churn out pretty elaborate games in very little time.

 

Now with assembly, I'm using Merlin which works just fine, but it's very tedius and I'd much prefer to write the code in something like notepad (or even something better?) and then load it to a disk image via Ciderpress just like I did with my BASIC code. (Or at the very least, allow me to modify the source code in Ciderpress itself since it lets me read the contents there). The important part is that I still want to me able to access my loaded file with Merlin. However, neither approach appears to work so what's the most efficient way to accomplish what I need? Am I really stuck programming on an actual Apple II computer or emulator? (If so I guess I get to experience programming as it was in the 80s!)

Edited by Tanrunomad

Now with assembly, I'm using Merlin which works just fine, but it's very tedius and I'd much prefer to write the code in something like notepad (or even something better?) and then load it to a disk image via Ciderpress just like I did with my BASIC code.

i'm using Crimson Editor to edit source code and assembling with ACME. i have no idea if that combination'll still work with Merlin but i'm basically building a file and using Ciderpress to insert it into a disk image for testing.

I use Notepad++ and I used ca65 as an assembler for some Apple II stuff I wrote. I also used Ciderpress but if I can get a2tools rebuilt for 64 bit I'll dump ciderpress and just put the disk transfer in the build script. I had to create my own custom definitions for 6502/Z80/6809/6803 cpus for syntax highlighting.
I originally started with TASM because I use it on other CPUs but I think I switched to accommodate other people. It certainly works but no 6502 people seemed to use it.
I haven't used ACME but I believe that's what was used for the IIgs ROM source code that's downloadable.
I haven't used Merlin either.

Can you transfer some source code from Merlin back to the PC so you can analyze its format? Perhaps it is more than a plain ASCII file, which means that in order to load the source code developed on the PC, you might have to make modifications to the format. I've never programmed for an Apple ][ but if I did, I would probably stick with cross assembling using either one of the available assemblers (I prefer DASM, but most of them work the same way with similar strengths) and dry run it in emulation. Once I got most of the functionality and bugs sorted out, I'd transfer the executable to real floppy disk to fine tune testing. Then again, the more includes, macros, conditionals etc you use in the cross assembler, the tougher it might be to get a native format that Merlin can read and assemble.

  • 1 month later...

I love working with Merlin. For 2600 / NES development I have used Notepad++ with DASM as well. Personally, I think that cross-assembling is good if you want to work quickly. Using Merlin is preferable because I don't care how long it takes to get my projects done. To me, its all about the experience. If you want to write 6502 assembly the way the pros did it back in the day, Merlin is a good choice.

 

Also, I used to feel that Merlin was tedious until I learned all the commands. The only drawback is scrolling. That's why I developed a "legend" to find sections of code faster.

If you want to write 6502 assembly the way the pros did it back in the day, Merlin is a good choice.

Nah, the pros cross assembled from a second instance of the same machine, a different 8-bit entirely, Amigas and STs, DOS boxes (with or without PDS hardware), 68000-based minicomputers, the odd mainframe...

@TMR

Sure. Pretty much every 6502 based system has a cross compiler solution. I'm not discouraging the OP from using one either. I just think that it's super cool to write assembly within a 6502 based environment.

 

What do you mean by "second instance of the same machine, a different 8-bit entirely"? As far as I remember, the Motorola 68000 (both used for the Amiga and Atari ST) is a 16 bit CPU. And DOS can run in 16-bit Real Mode as well as 32 bit protected mode.

 

Not trolling here I promise :) I'm just trying to figure out what you mean exactly.

I ended up using Merlin 100% for programming my first game, Lamb Chops. I'm now co-developing a 2nd game with a friend and it's going to be awesome. This time we're programming in C with Visual Studio for most of the game.

I believe TMR means that in the old days, development was often done through cross assembly using one of the following methods:

 

* Two identical 8-bit computers linked together, one being the host with the assembler, the other being the client to which the executable code was transferred and run

* Two different 8-bit computers, similar connection between the two with the most powerful being the host

* An Amiga, ST, DOS, mini computer, mainframe etc acting as the host, linked with the 8-bit client

 

That is to say, rarely the code was developed, saved, assembled and ran on the same computer. For smaller projects, it is doable if the assembler has a reentry location and the target program doesn't overwrite the assembler, otherwise you need to reload a lot all over when you go back to editing.

@TMR

Sure. Pretty much every 6502 based system has a cross compiler solution. I'm not discouraging the OP from using one either. I just think that it's super cool to write assembly within a 6502 based environment.

 

What do you mean by "second instance of the same machine, a different 8-bit entirely"? As far as I remember, the Motorola 68000 (both used for the Amiga and Atari ST) is a 16 bit CPU. And DOS can run in 16-bit Real Mode as well as 32 bit protected mode.

As carlsson said, i was referring to several different solutions; before the 16-bit machines were viable/affordable as cross assemblers it was commonplace to use 8-bits, either getting two of the same machine or using a different machine with a bit more welly or perhaps a better storage solution for source code; the Oliver twins used an Amstrad CPC to assemble Dizzy for the Spectrum, there were Commodore 128s assembling games for the C64, John Harris had two Atari 8-bits linked together and so on...

@TMR & carlsson

 

Very cool guys! I wasn't around in those days. My first language was QBASIC in 1996. I think it's really cool that Tanrunomad and others

are picking up 6502 assembly. After years of C and C++ I find it relaxing. I can see why they used two machines for "rapid" development,

but I'm in no rush. This might be a dumb opinion, but I think that machine language is sort of "zen like" in nature. So many people these days

are in such a hurry that they don't like to take the time to really learn something well.

  • Like 1

I can see why they used two machines for "rapid" development, but I'm in no rush. This might be a dumb opinion, but I think that machine language is sort of "zen like" in nature.

If you're assembling to memory and testing on the spot you've either got to get into the habit of saving very regularly or risk having a bug in your code running wild and spannering the source or even the assembler in the process. It's hard to be zen-like under those circumstances! =-)

 

So many people these days are in such a hurry that they don't like to take the time to really learn something well.

i don't see cross assembly as being in a hurry though, more being cautious and making sure the program you're putting time and effort into is safe; i've lost source files to dodgy floppies over the years[1] to know how crap that feels - it isn't something i'd wish on anyone else, especially someone learning 6502 now.

 

[1] And those losses were with a ridiculously involved backup process (numbered source files spread over seven disks) and running my homebrewed C128-based cross assembly rig. Now i use a Windows box, keep copies of major milestones and have all my source backed up via Dropbox because old habits die hard...

Besides backup solutions and assembly speed, I can save A LOT of wear on my 8-bit keyboards by using my mostly disposable PC keyboard for all the dull typing, and save the old keyboard for moments of glory, running the software/games. On the other hand, most 8-bits consume far less power than a PC of today, so in terms of total resources spent, native development might be more "green", in particular if you can plug in a nice, disposable USB keyboard made entirely of recycled material... :-)

Besides backup solutions and assembly speed, I can save A LOT of wear on my 8-bit keyboards by using my mostly disposable PC keyboard for all the dull typing, and save the old keyboard for moments of glory, running the software/games. On the other hand, most 8-bits consume far less power than a PC of today, so in terms of total resources spent, native development might be more "green", in particular if you can plug in a nice, disposable USB keyboard made entirely of recycled material... :-)

 

I own about 20 of these Clicky Keyboards.. At a rated life of 25 Million keystrokes, per key, they don't need to be replaced very often...

  • Like 1
  • 7 months later...

I recommend SuperMon for just messing around: it's very direct.

 

I'm also working on a Merlin-compatible assembler in go: it currently works for assembling the Merlin intbasic source I found, but the code is messy (although getting better), and the error handling rough around the edges. Happy to share with any brave souls who are interested.

I ended up using Merlin 100% for programming my first game, Lamb Chops. I'm now co-developing a 2nd game with a friend and it's going to be awesome. This time we're programming in C with Visual Studio for most of the game.

 

When i was younger, i started with Merlin then i used procode.

Now, i'm looking about c cross-programming for apple2 e/c. I've some difficulties to understand how cc65 is running

 

Can you describe your adaptation of visual studio for Apple2 ?

I've never used Merlin, but I have been using dasm to cross-assemble to the Apple II. I'm already familiar with the syntax of dasm since I've been using it for Atari 2600 development, so it was really easy to keep using it for the Apple II as well. Also I'm too used to modern keyboard layouts that the Apple II keyboard still throws me off a bit. It's not as bad as some machines (ZX-80/TS-1000 comes to mind as being particularly bad), but I'd much rather have some modern conveniences while writing code so I can save some more brain activity to put towards the code itself rather than trying to deal with old text editors.

 

As for deploying it to real hardware, I've been making cassette images for now. I'll probably need to switch to some other method at some point if my Apple II projects get more complicated, but for now this is working pretty good.

I think I used a IIgs keyboard on one of my Macs at one point. Not as good as some of the other Mac keyboards, but definitely better than that squishy Mac keyboard was shipping with their Performas in the 90s. Ugh.

 

As for the IIe keyboard, it is pretty close. I find it pretty nice to use, except for it being a few inches higher than the Mac keyboard. Perhaps if I lowered my desk a bit, I could deal with it better. But for now, I'll stick to my cross compiling setup :)

 

It would be kinda cool to rig up an something (perhaps Arduino or similar based) to allow a USB keyboard to plug into a II. I might take a stab at that sometime just for the heck of it :)

 

The //e layout is pretty close to that of a modern keyboard, and of course the IIgs keyboards were also Mac keyboards, if that makes things any easier...

This has actually been done already. Take a look https://www.tindie.com/products/option8/retroconnector-keyboard-interface-for-apple-iie/

There are also adapters for Joysticks by the same guy.

 

I figured there was something already done in this area, but was more thinking of doing it just to figure out how to do it myself. But this is still pretty cool -- interesting that they used a slot just to hold the card and not for any actual electronic connections. I guess this would be a good use of slot 3 on the IIe, since it's pretty much useless otherwise once you have the 80 column card installed.

  • 5 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

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.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...