Jump to content
Wally1

Assembly Language

Recommended Posts

Well

 

after some serious soul searching

 

I have decided to return to 6502

and not pursue 68000 assembly anymore.

 

To me, 6502 is much more elegant and more bang per byte.

 

All 56 instructions are 3 character symmetrical

and I can really wrap my noodle around its structure and stuff...

 

I was really barking up the wrong tree with 68K! {i couldnt' stand 'TRAP' or the arbitrary 3,4,5 character mnemonics and i really hated ADDQ instead of INX !}

 

And to share a side note with whoever is reading this

i was half asleep and my higher self (you can call that the subconscious or

the fact that the soul ascends to Heaven when we sleep, i.e. G-D)

 

was the determining factor that pretty much said to me:

 

'return to 6502'.

 

So there you have it.

 

I would love some feedback guys.

 

Edited by Wally1

Share this post


Link to post
Share on other sites

well AtariGeezer,

 

i actually read some people said that 68K codes it self (!)

 

and that it is orthogonal (right-angled) and it was one of the more

favored ASM Languages, it was preferred.

 

but all i know what my instincts tell me

 

and if Star Raiders can be developed in 8 measly kilobytes

than i wanna be on that gravy train!

 

yeah Abacus makes good books

 

 

Edited by Wally1
  • Like 1

Share this post


Link to post
Share on other sites

My first experience with an assembler was on the XL and its 6502c. Few years later I switched to the ST and 68k.

Both assemblers have their own pros and cons. Like 65xx - simple instructions or fast interrupts, and 68k - instruction flexibility and functionality (like dbra loop, trap), 32bit math and a lot of registers.

 

I like them both.

 

now thanks to @necrocia I'm back with 6502

Edited by Cyprian_K
additional informations
  • Like 1

Share this post


Link to post
Share on other sites

I don't think that forcing 3 character long mnemonics for CPU with much more instructions than some old (even for 1982) CPU like 6502 would be good idea.

Motorola's mnemonics where little strange for me after Z80 ones. Like why move instead ld - not just longer, by actually not correct by my knowledge. Move means moving from one place to other, so that it is moved from origin. But that happens not with move instructions, they are copy in fact. Load (ld) is more proper.

But mnemonics are just what their name says - for easier remembering and working with.

I like 68000 ASM, and use it over 30 years. There is lot of operations, and that's good for code efficiency, but needs some time to get in, and be able to make good code. Good assembler helps a lot. Devpac was most popular, I would say with good reason.

 

I coded before it on Z80. And not only me. I saw traces of old, Z80 coding habit in many SW.

They used: 

  move  address,d0
  tst  d0

  Or even worse:
  move address,d0
  cmp #0,address

  

 But no need for any further test after move. Move to data register with 68000 sets flags too, according to value transferred.

In this example I did not add size (b, w or l) because it depends not from size, of course.

Share this post


Link to post
Share on other sites

I never learned 68000 asm but I loved working with 6502 asm.  It had a wonderful way of being created by various basic compilers and decompiled easily from compiled exe's.  You would probably enjoy the disassembled then reassembled fully documented Star Raiders.  Better than the original code because the disassembly caused an in-depth analysis of the source code to extrapolate which routines were doing what and document it with comments.  I wrote an assembler in TurboBasic that compiled into basic ascii strings for call by way of USR calls.  By combining multiple machine codes into small nugget routines I could just add a command to call a 6502 routine nugget.  Stuff like that was how new languages were created.  I remember them coming out with languages like "ACTION!" - those were always easy to hatch a new language because all they did was make the underlying elegant 6502 be available via some new asm "routine nuggets"

The reason I never got into 68000 was probably because the ST was taken over by the Commodore people.  The Atari people went to the Amiga camp and sort of reversed and "flipped sides" causing me to get an ST and only played mainly Dungeon Master on it until I unplugged it and got an Amiga and then quickly just went to PC after that because not much good came out for the Amiga over time the Amiga stood in the shadow of the mighty PC where everything came out for the PC always and the 68000 just went away.

Star Raiders asm source code.  The game that made people buy the 800 computers.  Like Dungeon Master made people buy an ST (I'm not done yet I've got three Worm rounds left and I'm taking Stamn's bones back to the resurection shrine!).  Fruit Ninja made them buy an Xbox360 with Kinect sensor controller.

https://atariwiki.org/wiki/Wiki.jsp?page=Star+Raiders+source+code+by+Lorenz+Wiest&fbclid=IwAR1Z3vhzhj1KwyYF3qz7TflEFMVrIUtfIgpAciJQRm0GbFSroMd5vtSBoro

Edited by Ray Gillman
  • Like 1

Share this post


Link to post
Share on other sites

Thank you Ray.

 

Star Raiders is pretty amazing for only 8k.

 

I will check out the source code.

 

Share this post


Link to post
Share on other sites

I taught myself 68000 on the Amiga but once I stepped up to the A1200 and A4000 I found that 68000 could not cut the mustard.
Don't get me wrong because it made great demos and some really nice games came from the 68k but to do the advanced stuff you needed more juice.

then things got really weird when I picked up the PPC/060 for the A4000 and that's when I just called it quits and went back to C++ on the PC side.


I wanted to make some games using C++ on the Amiga but am not about to pay full or any price for that 20 something year old Storm C++ package.

Then I looked into the Atari ST and just wasn't impressed.
No HD unless it was in 2 colors and after I was used to Amiga I didn't want to go down the ST road.

Edited by Mike Harris

Share this post


Link to post
Share on other sites
On 9/22/2019 at 2:41 PM, Ray Gillman said:

I never learned 68000 asm but I loved working with 6502 asm.  It had a wonderful way of being created by various basic compilers and decompiled easily from compiled exe's.  You would probably enjoy the disassembled then reassembled fully documented Star Raiders.  Better than the original code because the disassembly caused an in-depth analysis of the source code to extrapolate which routines were doing what and document it with comments.  I wrote an assembler in TurboBasic that compiled into basic ascii strings for call by way of USR calls.  By combining multiple machine codes into small nugget routines I could just add a command to call a 6502 routine nugget.  Stuff like that was how new languages were created.  I remember them coming out with languages like "ACTION!" - those were always easy to hatch a new language because all they did was make the underlying elegant 6502 be available via some new asm "routine nuggets"

The reason I never got into 68000 was probably because the ST was taken over by the Commodore people.  The Atari people went to the Amiga camp and sort of reversed and "flipped sides" causing me to get an ST and only played mainly Dungeon Master on it until I unplugged it and got an Amiga and then quickly just went to PC after that because not much good came out for the Amiga over time the Amiga stood in the shadow of the mighty PC where everything came out for the PC always and the 68000 just went away.

Star Raiders asm source code.  The game that made people buy the 800 computers.  Like Dungeon Master made people buy an ST (I'm not done yet I've got three Worm rounds left and I'm taking Stamn's bones back to the resurection shrine!).  Fruit Ninja made them buy an Xbox360 with Kinect sensor controller.

https://atariwiki.org/wiki/Wiki.jsp?page=Star+Raiders+source+code+by+Lorenz+Wiest&fbclid=IwAR1Z3vhzhj1KwyYF3qz7TflEFMVrIUtfIgpAciJQRm0GbFSroMd5vtSBoro

 

 

 

Can I ask that why is it every time I go to look at these source code listings it has to add tons of crap to it instead of just displaying the damn thing.

I have tried in two separate browsers FF and Chrome yet it adds garbage such as

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
  <link rel="dns-prefetch" href="https://assets-cdn.github.com">
  <link rel="dns-prefetch" href="https://avatars0.githubusercontent.com">
  <link rel="dns-prefetch" href="https://avatars1.githubusercontent.com">
  <link rel="dns-prefetch" href="https://avatars2.githubusercontent.com">
  <link rel="dns-prefetch" href="https://avatars3.githubusercontent.com">
  <link rel="dns-prefetch" href="https://github-cloud.s3.amazonaws.com">
  <link rel="dns-prefetch" href="https://user-images.githubusercontent.com/">

 

 

Am I supposed to open this in some editor then compile?

This really makes it difficult to use 3rd party applications and boxes you into a set style or system.

Share this post


Link to post
Share on other sites

That's certainly not the way how to put some source code online. It should be plain text, without html .

Ahhh... as I see it is fixed now.

And I think that there is source for Atari ST version available too . Need to look for ...

Share this post


Link to post
Share on other sites

While working on my first Assembly game on the TI-99/4A (TMS9900) I figured I'd try something on the ST next. What's a modern workflow look like using a PC? I travel for a living so I'm looking for some tools I can load up onto a cheap Windows10 machine. Any ideas? Trying to avoid online tools. Need to do much of my work in a no wi-fi area. I can do it all on a Mac if there's tools for Mac. I've always been interested in the 68000. Feeling spoiled with my sixteen 16-bit relocatable registers on the TI. ;)

 

Current workflow includes: 

 

All Windows10 stuff...

 

Magellan Graphics Editor for Maps, Sprites, and Character drawing

 

Coding in IntelliJ IDEA with some TMS9900 specific plug-ins to help catch typos, etc.

 

A TI-99/4A specific Assembler (ASM994A)

 

Emulation via Classic99

 

Assuming I'll need similar tools for the ST? Where to begin?

 

-James

Share this post


Link to post
Share on other sites
On 9/9/2019 at 3:01 AM, AtariGeezer said:

After learning 6502,  I found it rather easy to code in 68k.  The Abacus books helped too :)

Back in '91 I actually did it the other way around. I'd been struggling to understand 6502 but then I got a copy of 68000 Assembly Language Programming by Glentop and within a week I was proficient at 68000. The following week I took what I'd learned and became proficient at 6502. Today, I can't remember anything about 68000 but can still read 6502 okay. And yeah, the Abacus books helped. I had Atari ST Internals. That was a godsend.

Personally, I liked the architecture of both Atari systems. And I even dabbled with inserting my own Trap calls. My favourite project was one which "inserted" extra OS calls via Trap calls which could be called from either assembly language or STOS. These were just a collection of about 20 different screen fades and transitions, some of which were donated by friends.

If I had the time, I'd relearn 68000.

Share this post


Link to post
Share on other sites

Well, I must say that there is something more important than what tools to use for programming in ASM - knowledge about it.

So, literature first. Lot of it is available online now. So, some MC68000 programming literature, with all registers, operations explained. And that will be long part - because 68000 is much more complex than some 8-bit CPU. Of course, you can go in same fashion as some older CPU, but that will be not so efficient.

2-nd most important thing is practice.  Don't see that you have some Atari ST. But now there is better way than testing, debugging on real HW :

Emulator with Debugger. Steem Debugger. Called Steem Boiler too. It is available only for Windows, and is really useful for programmers. You have complete overview of program flow, computer HW registers, RAM, with history .... That is best help for early tests, finding bugs. Surely, serious programming need test on real HW too, but that can be last step - Steem is very accurate emulator, so it will work on real HW without problems 99% .

I recommend Devpac assembler, v 3 . That was most popular in period when lot of SW for ST was done, and it produces good code, with possible optimizations. Surely not so fast as some ASM on PC, but you can speed up it in Steem (about 20x).

 

And I can not resist:  " Feeling spoiled with my sixteen 16-bit relocatable registers on the TI. ". Well, MC68000 has 16 32 bit registers, and is 32-bit CPU in big part. And I'm sure that has much more operations and their variations than TMS9900. Which was somehow design failure in my (and many other people) opinion, not to mention 'opinion' of the market. Actually, that design was exactly opposite to later winner - RISC. Putting registers in RAM made it just very slow.

Nice thing to can have registers overall in RAM, but speed penalty is too high. And 16 registers of 68000 are pretty much. If not enough, there are fast ways to save content in RAM and reuse .

Share this post


Link to post
Share on other sites
On 9/8/2019 at 8:50 PM, Wally1 said:

Well

 

after some serious soul searching

 

I have decided to return to 6502

and not pursue 68000 assembly anymore.

 

To me, 6502 is much more elegant and more bang per byte.

 

 

 

I find that programming the 6502 to manipulate 16-bit and larger quantities to be tedious.

 

On 9/8/2019 at 8:50 PM, Wally1 said:

 

I was really barking up the wrong tree with 68K! {i couldnt' stand 'TRAP' or the arbitrary 3,4,5 character mnemonics and i really hated ADDQ instead of INX !}

 

 

 

ADDQ instead of INX bothers me because as an addition operation, it affects the carry (and X) flag whereas an increment or decrement on most processors do not.

Share this post


Link to post
Share on other sites
On 10/22/2019 at 11:39 PM, Airshack said:

While working on my first Assembly game on the TI-99/4A (TMS9900) I figured I'd try something on the ST next. What's a modern workflow look like using a PC? I travel for a living so I'm looking for some tools I can load up onto a cheap Windows10 machine. Any ideas? Trying to avoid online tools. Need to do much of my work in a no wi-fi area. I can do it all on a Mac if there's tools for Mac. I've always been interested in the 68000. Feeling spoiled with my sixteen 16-bit relocatable registers on the TI. ;)

<snip>

On 10/22/2019 at 11:39 PM, Airshack said:

 

Assuming I'll need similar tools for the ST? Where to begin?

 

-James

 

I do not own real hardware and use Steem and Devpac to do testing.  I use my own cross assembler and emulator to do most of the development; everything so far treats the ST display and keyboard as a TTY.

Share this post


Link to post
Share on other sites
On 9/8/2019 at 10:01 PM, AtariGeezer said:

After learning 6502,  I found it rather easy to code in 68k.  The Abacus books helped too :)

Same,  68K seemed a lot more elegant to me at the time.   Also  had to learn x86 assembly for school at the same time I was teaching myself 68K.   I hated x86 assembly,  this was before the 386 flat memory/protected mode,  and coding for the segmented memory was a pain in the ass as I recall. 

Share this post


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

Same,  68K seemed a lot more elegant to me at the time.   Also  had to learn x86 assembly for school at the same time I was teaching myself 68K.   I hated x86 assembly,  this was before the 386 flat memory/protected mode,  and coding for the segmented memory was a pain in the ass as I recall. 

Segmentation on the x86 is something that the programmer had to get used to managing.  I have done so much of it that it is second nature.

 

The ironic thing is that IBM chose the 8088 for their small computer.

 

The IBM mainframe architecture is notorious for how difficult it was to program.  Addressing required using a base register.  A section of code started with a BALR (BrAnch and Link Register) instruction to get something related to the current program counter into a register.  All other branches must be offsets to that base address.  IIRC, a section of code is limited to 4K bytes, so any sizeable program had to be broken up into small pieces.

Share this post


Link to post
Share on other sites
6 hours ago, BillG said:

Segmentation on the x86 is something that the programmer had to get used to managing.  I have done so much of it that it is second nature.

...

 

OMG ! Do we have Bill Gates himself here ? 😄

 

Why IBM chose 8088 for PC was discussed zillion times on billion places. I think that main reason was that MC68000 was still buggy in that time, and probably price too. Don't know was then 68008 available ?

 

Surely, 68000 ASM is dream compared to 8086/8 . Even without segmentation. But things changed - as always, and Motorola could not keep development pace with Intel. For instance, memory block copy works better in later 80xxx CPUs - no unnecessary instruction reread for every new copy cycle. What forced 68000 programmers to use movem with many registers for max speed.

 

On the other side, I think that DRI could do many things better. For instance using 32-bitness of 68000 better. Probably C compiler for was not much good - as their Basic, RCS were not too. Independent SW firms made it better, as we know.

Share this post


Link to post
Share on other sites
13 hours ago, BillG said:

Segmentation on the x86 is something that the programmer had to get used to managing.  I have done so much of it that it is second nature.

No doubt, anything becomes second nature when you do it enough

 

6 hours ago, ParanoidLittleMan said:

Why IBM chose 8088 for PC was discussed zillion times on billion places. I think that main reason was that MC68000 was still buggy in that time, and probably price too. Don't know was then 68008 available ?

I heard the 68000 wasn't available in enough quantity.  Price was likely a factor too.  

 

 

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.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...