Another assembler

[Alfred]

I retired this year, and after nearly 40 years of writing applications and system code in S/370 assembler, I've decided to give asm a rest for a while. First on my list is a native 65816 assembler, that I'm going to model after Six Forks and clone most of the features from the WDC assembler. We have all these nifty little programming languages and yet almost nobody uses them. So I'm going to write my little assembler in Basic XE, and the linker too.

 

As for why, when there is MADS and what not ? Why not ? With Rapidus and some of these other mods, no reason we can't have nice things on the 8-bit.

[Rybags]

I used to do a fair bit of S/370 programming myself. Was almost the logical progression from 6502, 68000 though took a little while to get used to the base register concept and it's restrictions.

[dmsc]

Hi!

 

I retired this year, and after nearly 40 years of writing applications and system code in S/370 assembler, I've decided to give asm a rest for a while. First on my list is a native 65816 assembler, that I'm going to model after Six Forks and clone most of the features from the WDC assembler. We have all these nifty little programming languages and yet almost nobody uses them. So I'm going to write my little assembler in Basic XE, and the linker too.

 

As for why, when there is MADS and what not ? Why not ? With Rapidus and some of these other mods, no reason we can't have nice things on the 8-bit.

Shameless plug, you can use my FastBasic IDE, it's free, faster and IMHO, nicer than BASIC XE. See at http://atariage.com/forums/topic/267929-fastbasic-beta-version-available/?p=3870695

[Alfred]

Thanks, but I'll be sticking with Basic XE. Your Basic looks interesting, but it's not something I'd use.

[VladR]

Is it because you only want to use the tools that were available in the 70's ? I'm just trying to understand the reasoning here, as you're going to the dev on the real thing, why would you not use something that's an order of magnitude better than the default SW from ~half a century ago ?

[Alfred]

Eh? What are you talking about ? FastBasic is not an order of magnitude better than Basic XE.

[baktra]

I used to do a fair bit of S/370 programming myself. Was almost the logical progression from 6502, 68000 though took a little while to get used to the base register concept and it's restrictions.

Now, elimination of instructions that use base register is very popular for successors of S/370. E.g. BC is being replaced with BRC etc.

[Alfred]

I would have liked to have been on the committee that came up with Load Multiple Disjoint. Disjoint, lol.

[+JAC!]

>Why not ?

Yes, the definitive answer in case you are asked "Why <anything> Atari-8bit <anything>"?

[Alfred]

Is it because you only want to use the tools that were available in the 70's ? I'm just trying to understand the reasoning here, as you're going to the dev on the real thing, why would you not use something that's an order of magnitude better than the default SW from ~half a century ago ?

 

I'm assuming you're talking about MADS etc. If I was going to use a cross-assembler or cross-compiler, then why bother using the Atari ? Just compile on the PC/Mac using whatever language and use that machine. Seems pointless to use a big desktop machine to write code for the little one. Might as well just use the big machine for everything and leave the XL in the box.

[Alfred]

Now, elimination of instructions that use base register is very popular for successors of S/370. E.g. BC is being replaced with BRC etc.

 

Yeah, I never really got into that habit. I still mostly code with a base reg, still use BNE rather than JNE. I doubt I've used any of those 20 bit displacement instructions, or even most of the Grande ones.

[VladR]

Seems pointless to use a big desktop machine to write code for the little one. Might as well just use the big machine for everything and leave the XL in the box.

I disagree. The difference in productivity is enormous. I've recently started writing a 3D flatshading engine for A800. Took me about 10 hrs of work to create a cycle-exact 6502 VM in C++ (via macros), so now can use Visual Studio's amazing debugger (especially Edit&Continue) while typing 6502 Assembler, and freely insert debugging C++ statements between the ASM instructions.

Debugging such thing via monitor/hexDump on Atari (I did something similar, 25 yrs ago, so thanks but no thanks ) would take ages, and realistically would end long before it would get any results.

 

Now, if your goal is the experience of coding on the real thing, I totally understand. No judgment here, just mere curiosity, that's all.

 

Also, the timing of your effort is identical to the latest release of FastBasic, which to me seems absolutely amazing (but then again, I don't know Basic XE's features from the top of my head - but presume [most probably incorrectly] it's the default Basic from 30 yrs ago, just on 130XE ?).

 

Out of curiosity, can you tell me which killer features of BasicXE make it better than the FastBasic ?

[Alfred]

Nothing killer, except it has full string support and natively supports the banked ram in an XE. I suppose the fast string searching might be useful, it's just a good language. FastBasic has some good stuff, but it seems incomplete. Where is the 4 byte integer type, strings longer than 255 chars, etc. It's a good start, but I wouldn't use it myself, probly go with Action! or PL65 maybe next time.

[Alfred]

DDT is the only debugger that I've used, never needed more. Don't usually need it either, c'mon 6502 code is like Pilot. C++ debug statements, I can't believe you're serious.

[VladR]

c'mon 6502 code is like Pilot. C++ debug statements, I can't believe you're serious.

The question really is : "Why would I want to waste more of the precious free time browsing hexadecimal data [in a monitor] compared to single-line C++ debugging statement (that prints the whole array) ?"

 

What exactly do I gain by wasting more time and being less productive (and thus potentially postponing the deliverable to next year and/or never) ? I swear, I don't get it, but then again, I'm ~29 years from retirement (so there's still much to learn)...

 

Recent example: I made a stupid copy/paste bug - I got a phone call in the middle of doing copy/paste, so once I dropped the phone, the code looked complete (and I couldn't fully test it, as I ran out of time, due to the phone call) - of course it wasn't.

How would you recommend quickly finding one wrong value somewhere in the middle of the 3D pipeline while using 17 arrays and 73 variables across 16 KB? Because it took me, like, 2 minutes from within Visual Studio's C++.

 

If you know of a faster way, directly from assembler or monitor - I would appreciate if you shared it

[baktra]

I disagree. The difference in productivity is enormous. I've recently started writing a 3D flatshading engine for A800. Took me about 10 hrs of work to create a cycle-exact 6502 VM in C++ (via macros), so now can use Visual Studio's amazing debugger (especially Edit&Continue) while typing 6502 Assembler, and freely insert debugging C++ statements between the ASM instructions.

Debugging such thing via monitor/hexDump on Atari (I did something similar, 25 yrs ago, so thanks but no thanks ) would take ages, and realistically would end long before it would get any results.

 

Now, if your goal is the experience of coding on the real thing, I totally understand. No judgment here, just mere curiosity, that's all.

 

As far as I know, even Atari used cross-assemblers for development of their 8-bit software. The micros are neat, but development on them is not a very comfortable experience. That's why I also salute developers who created amazing software with just MAC/65, ATMAS, Quick Assembler and other native development tools.

[tschak909]

Back in the day, I either cross-assembled, or I used the Atari Macro Assembler (AMAC), it's not the fastest assembler, but it can handle _LARGE_ projects, and assembles a better target binary than MAC/65 ever did (doesn't need to be de-segmented), and its cross reference functionality puts it ahead of the whole pack (a big plus if you're assembling a very large project). One thing, I do wish that I had the Amoeba debugger back then, as it is a superb debugging suite.

 

-Thom

[Heaven/TQA]

just for nostalgia reason I would use again Thorsten Karworth's Makro Assembler XE which can handle large source code files in memory... or Mac/65 as cart but since nearly 20 years i am using XASM/MADS... never ever would I go back writing assembler on native machine.

 

Altirra + MADS is the way to go.

[drac030]

First on my list is a native 65816 assembler, that I'm going to model after Six Forks and clone most of the features from the WDC assembler.

 

Just a remark, native 65C816 assemblers already exist, One is Alfasm, another is MAE. I have never used Alfasm, but MAE (unlike MADS) uses the WDC syntax.

 

This of course does not mean that another one should not be written.

 

And considering the hobby in terms of productivity... I am simply speechless.

[VladR]

As far as I know, even Atari used cross-assemblers for development of their 8-bit software. The micros are neat, but development on them is not a very comfortable experience.

tschak909 had recently had a thread here, where he showed YT vid of compiling ASM using Corvus Drive (I never even knew [behind the iron curtain] that stuff was possible on A800). That blew me away, since I only experienced assembling large ASM projects from the tape in ATMAS II (quickly resorting to learning hexa opcodes and just writing the code in monitor, as I ran out of RAM for source code veeery quickly), so I would argue that it's actually a very comfortable experience with a set-up like that, even on the little micro (comparatively speaking, that is). But today we have other options...

 

 

And considering the hobby in terms of productivity... I am simply speechless.

Well, there's only so much of a free time. Why is it so wrong of me to try to accomplish / finish something in a year, instead of dragging it through a decade ?

[Alfred]

Alfasm is a pretty basic assembler I wrote quickly just to have something. Chuck came out with his cross-assembler later. I learned 6502 Sam using only EASMD. Like Vlad, it was easier then to just memorize the op code table and type the data into memory and Bsave the code. I didn't start using Mac/65 til much later. Still, the line editors kind of of suit my style.

 

I sit and think about a project in my head for days or weeks til I have it all worked out and then I just sit down and type all the code in, however long that takes. One or two passes through an assembler to fix all the typos and any missed declares, then a couple of runs to make sure it works correctly and that's it.

 

I do miss 80 col editing. Back then I ported SPF to my 800 with the 1 meg Axlon. Now I would port it to use VBXE and 65816 instructions to get the speed up there. First things first though.

[Alfred]

I've never used AMAC but reading the manual revealed it has some nice features that I would clone. The reason I like Six Forks is because with the linker speed of assembly is kind of a non-issue because you only assemble a few pages of code at most. I can remember assembling BobTerm when I was helping Bob and with the screen off it took almost six minutes to assemble with MAC/65.

 

Everybody has their own way, whatever works is what you do.

[luckybuck]

Hi Alfred,

 

You mentioned EASMD, do you have the source code for EASMD? Else, do you know, who wrote it?

 

All the best to you. Please stay healthy. Please.

[dmsc]

Hi Alfred!

 

Nothing killer, except it has full string support and natively supports the banked ram in an XE. I suppose the fast string searching might be useful, it's just a good language. FastBasic has some good stuff, but it seems incomplete. Where is the 4 byte integer type, strings longer than 255 chars, etc. It's a good start, but I wouldn't use it myself, probly go with Action! or PL65 maybe next time.

As you said, FastBasic currently does not support many string functions and long strings, but you can use byte arrays as longer strings and work directly with them, for example the integrated editor loads the complete file into a byte array and then prints segments using "BPUT", and manipulate parts using MOVE.

 

I'm want FastBasic to grow to a useful language for many types of programs, and extend it to address common needs (always keeping it as fast as possible). Perhaps some additions could be made:

 

- Possibility to treat byte arrays directly as (null-terminated) strings, with a syntax like:

 dim big(2000) byte    : ' A big "string" array
 big() = "Hello World" : ' Compiled as:  tmp$="Hello World": move adr(tmp$), adr(big), len(tmp$) : poke adr(big)+len(tmp$), 0
 big(6,) = "Alfred"    : ' Compiled as:  tmp$="Alfred": move adr(tmp$), adr(big)+6, len(tmp$) : poke adr(big)+6+len(tmp$), 0
 ? big()               : ' Compiled as:  i=0: while big(i) : put big(i) : inc i : wend

- Adding functions to search memory/strings, something like " index = memsearch( ADR(haystack$), LEN(haystack$), ADR(needle$), LEN(needle$) ) "

 

What do you think, would that be useful? Main problem with null-terminated strings is that you can't store $0, and in Atari this is the common "hearth" character.

 

Thanks,

 

Daniel.

[Alfred]

Hi Alfred,

 

You mentioned EASMD, do you have the source code for EASMD? Else, do you know, who wrote it?

 

All the best to you. Please stay healthy. Please.

 

No, I don't have the source for Easmd. As best I recall, it was written by Kathleen O'Brien, wife of Atari DOS 2 author Paul Laughton.