Any of you Coding on Amiga?

[Siggy999]

Yes, I got back into it 3 years ago, I've been spending that time re-learning assembly and trying to get back into writing games. I've hit several stumbling blocks, and my free time isn't what it once was, but I like to think I'm making some progress.

I do most things in UAE and send it to the real 2000 to test. Recently my PC blew it's processor, so I've actually been doing all my stuff on the real thing (1084 montior, NTSC amiga - original mouse and keyboard - and currently no accelerator) and once I got used to it again, I haven't found it all that bad.

[weiju]

Originally Posted by jman

we are spoiled by years of big screens and machine responsiveness, you'll end up needing a dedicated LCD screen (which is cheap) but in addition you'll want a scandoubler/flickerfixer card to use it (and that is where the trouble starts), but you can't code in 640x256, right? So you'll need a new graphic card to allow higher resolutions.

I think 640x256 is fine if all you have in front of you is a good text editor. I have been "spoiled" by years of "responsiveness" of Java IDEs and now mostly use text editors and CLIs for that reason. Since it's a hobby, finding time for Amiga programming can be hard and I just don't want to spend it changing disks and waiting for the compiler.

Expensive is one thing, but waiting for some stuff popping up on Ebay or Craigslist is the other. On the A1000, everything but the base machine is hard to find, so I gave up trying to turn it into a dev machine and got the 1200 instead (too bad, I really like the 1000's design).

[AlfaRomeo]

Yes, some times, in BlitzBasic.
Last project was a program that shows the state of Cia Registers and their bits.
I´m trying to learn Assembler too but now it´s in stand-by because progress is too hard and I´ve lack of time

[Photon]

Originally Posted by jman

but you can't code in 640x256, right? So you'll need a new graphic card to allow higher resolutions.

This was the sort of thing I was kinda pre-empting weiju. You seem to have a clear concept of where you want to go, so sorry about that. But maybe there ARE prejudices on what you need to code Amiga, that make coders hesitant about getting started/restarted? Your last post is spot on.

The only real answer is that it depends on how big projects you code on, and which platform it's for:

'Amiga' PPC: get a PPC board and something to plug it into.
AmigaDOS > 3.1: Something that runs that OS well.
Classic AGA: Stock A1200 with some harddisk/CF is just fine. Turbo+fastmem is not necessary, but will of course shorten compile times.
Classic OCS: Any OCS/ECS Amiga with 512K chipmem or more, an extra floppy and some fastmem is really usable. If you use a lot of includes you WILL want a harddisk/CF, and if your compiler takes its time you will want a smidgeon of non fake fastmem or a turbo.

You can start with a basic configuration like this and expand it later. Don't hold inspiration ransom until you can afford shopping for something that you may want because it's obviously desirable and will speed up your work!

If you use a resource-hungry compiler, you should get a computer with minimum specs to run it, of course.

On a 256K A1000 you may be restricted to only Assembler and some old, lean ones at that, like Seka. But on a 512K only machine you can definitely get started with Asm, C etc, perhaps enough to find out if you're getting hooked The above specs, though, will allow you do pretty much anything you want for the platforms.

I always recommend some kind of fastmem (as in, non-chipmem) in any dev Amiga. The reason is to leave "the stock machine amount of chipmem" (or as close as you can manage) available at runtime, when you have the editor and assembler/compiler loaded.

If you code games or demos, you can get tricked by the overcontrast and oversaturation of flatscreens. You can "calibrate" them somewhat, but you'll never have correct calibration AND correct dark colors and pastels. It will be hard to spot slight moving-graphics errors when it runs full framerate, and the same is true for scrolling. LCD TVs are better in these respects, but you're at the mercy of the panel type and signal standards chip used.

If your CRT or CRT TV doesn't support RGB, there are CD32-type S-Video enhancers for 10 EUR (if you don't mind soldering a small chip inside) or 35 (?) EUR and up for an external big box. I do think CRTs are lovely to work with, and think C1081/C1084 are excellent for standard lowres/hires graphics and text.

Whichever you choose, if you use RF/composite to start with I think you will soon make an effort to get better video output since text on these is tiring for the eyes.


If you have a way of getting files onto the Amiga (and don't make disk-loaded programs), there's no real need for a working floppy drive in your dev Amiga.


-~-

Typing too much again, and some obvious stuff too, but just so it's clear that you can do a lot without "aquiring the perfect setup first". A600+CF is one of the cheapest ways to get started - 90 EUR and you're up and running! And it's cute on a desk

-~-

jman: you need a gfx card if you dev for such gfx modes, or use a framework that is written for one (SDL, some GUI builder or whatever.)

[weiju]

@Photon: great recommendations, maybe this could be part of the Wiki/FAQ ?

After re-reading my initial post, I realized that the discussion was caused by my failure to provide sufficient context (struggling with the A1000/256K configuration), I apologize for that.

Anyways, I had defined my personal minimum as 68000, OCS, 1 MB and a harddisk, mostly because I want to use C and I am lazy but I agree you can work pretty reasonable with a smaller configuration.

[Thorham]

Originally Posted by jman

but you can't code in 640x256, right?

What do you think most people were using back in the day? That's right, 640x256. The same holds true for when the Amiga 1000 was first released. In both cases, interlace probably isn't a good alternative.

But it goes farther than that. Think Commodore 64. This one only does 320x200, and that works fine as well. Of course it has to, because there's nothing else (or a C128).

People still use 640x256 today, and I'm one of the people who's used this until 2005 when my 1084 broke down and I just bought a video scaler/tv box (now I use 672x562 in 94 hrtz interlace through the Commodore VGA adapter, which is fab).

[Photon]

Originally Posted by weiju

@Photon: great recommendations, maybe this could be part of the Wiki/FAQ ?

After re-reading my initial post, I realized that the discussion was caused by my failure to provide sufficient context (struggling with the A1000/256K configuration), I apologize for that.

Anyways, I had defined my personal minimum as 68000, OCS, 1 MB and a harddisk, mostly because I want to use C and I am lazy but I agree you can work pretty reasonable with a smaller configuration.

Nah, that's pretty optimal to get started with most things actually! For C or Asm with a lot of includes, a harddisk[1] will definitely save your nerves fringing at the ends

I don't know how many Amiga coders are targeting demanding languages (say, C++ & SDL) or later platforms (PPC+gfx card), but I'm sure they can give better specs than my tepid (lame!!) ones I know a little about both but not enough for a shopping list. All I know is that it really doesn't take a big shopping list to get started.

Thorham, yup. It's mostly about 'columns', and around 80 pretty much handles any language you throw at it, in fact I myself use way less in modern languages. (Like most coders, I guess.) While you can go 'many lines' even in many ancient editors, it's really not a dealbreaker, it's quite all right with 30 lines. With many lines on OCS/ECS/AGA it's difficult to get many lines and not cram the lines together like hell[2], I like at least a little bit of line spacing. If you dev for gfx cards it's a no-brainer of course - you already have the means for getting a nice 1024x768+ display with a really nice font

I could mention at this point that I made 3 fonts to cater to my sense of taste back in the day... Being happy with editor and editing IS important, I won't brush that under the carpet. [3]



[1] The great thing about a 'transfer unit', whether it's a 2.5" harddisk that you can plug in a USB adapter, CF card in IDE in A600, SD card in dirt cheap PCMCIA card reader, or a softly whirring zip drive, is that you get peace of mind. While workdisks are easy to make and Asm-One etc allow EXTERN to eliminate INCBIN loading, you just feel there's harmony in the universe if you can pop it in a PC or such in a jif and backup easily.

Format FFS, not FAT95 and stay away from really old MFM/IDE interfaces and pretty much anything will have you humming.

[2] On ECS+, some editors support a whopping 160+ column by 64 line superhireslace experience.

[3] Swedish expression is "I won't stick that under the stool!"... I did my best.

[jman]

Originally Posted by Photon

jman: you need a gfx card if you dev for such gfx modes, or use a framework that is written for one (SDL, some GUI builder or whatever.)

Originally Posted by Thorham

People still use 640x256 today, and I'm one of the people who's used this until 2005

I did some thinking about what you two are saying. Photon was really insightful so first of all a big thanks to him, really.

I'm no professional Amiga coder, I'm just a lost soul fiddling with ASM.
I tried both "production" mode on a A4000 and 800x600 on WinUAE and there is a difference indeed. Yes, as you pointed out it's the "600" to make the difference rather than the "800" (that's why I prefer 4:3 screens at work rather the ubiquitous 16:9) but you both know the warm feeling when you have more code under your eyes.
This is why I wouldn't want to go back to half the screen I'm used to have. Of course I can do it too and I'm sure I won't suffer any psychological breakdown :-) After all I'm doing it just for fun. At work I simply would not accept it.

[Leffmann]

I program a bit in assembly and C for fun, no huge projects or anything.

Originally Posted by weiju

Yes, I just started to pick it up again, after finally getting a hold of a system that has enough memory and a hard disk (A 1200). I used to program it in assembly and C/C++ in the 80's and 90's and plan on doing that again and maybe sprinkle in a little Lisp/Scheme if possible.
I plan to code little a couple of small utilities to re-familiarize myself and then see. I would love to do development on my Mac and test/deploy on the Amiga.

I usually program on my Mac and test run in WinUAE through Virtual Box or VMWare Fusion. Works excellent and runs smooth.

For programming C and assembly directly on the Amiga I would recommend ASM-One for just mucking about and getting a feel for it. For a more complete set of tools I would use phxass, phxlnk and the Dice C compiler for earlier machines with little RAM, and for machines with Kickstart 2 and a bit more RAM I would use the Barfly assembler and debugger, probably the fastest and most advanced ones you can run directly on the Amiga, and the SAS/C compiler.

[Photon]

weiju, seems Leffman's method of assembling/compiling outside the Amiga and run it in emu could be perfect for you then?

If I know Leffman he's made a performance chart of all Assemblers, if he says so, it is so. I think he's tried them all!

Compilers aside, if you don't code it all in asm, go with a commandline assembler+compiler combo, as Leffman suggests. I like Asm-One for its excellent, simple editor and debugger, it's all-in-oneness. I code everything in asm anyway, and an average-sized asm project, say 50-100k source or so, assembles in a jiffy even on an A500. I just love it, just write code and press a key (well, two) and it runs

[weiju]

@Photon: yes, this is similar to what I was thinking about, only that I am currently running E-UAE, my Mac is 4 years old and VMWare Fusion with XP is dog-slow (too many abstraction layers I guess )

The nice thing about this is that I write in a directory which UAE sees as a Harddisk. Also, I can probably use the version control system from the Mac (how developers on the Amiga do version control these days, I remember using RCS in the early 90's but that was pretty tedious).

@Leffman: I assume that you build in UAE, or do you use cross-compilation ? I ordered DICE directly from Matt back when I had my first Amiga, it used to be my primary C compiler (GNU C was slow). Devpac, DICE and OMA was all I could afford as a high school student - they worked pretty well, were fast and good investments.

I'll probably go with SAS/C for now to get a feel for it, I never worked with it before, but it looks pretty nice so far.

Thanks

[Leffmann]

Originally Posted by weiju

@Leffman: I assume that you build in UAE, or do you use cross-compilation ? I ordered DICE directly from Matt back when I had my first Amiga, it used to be my primary C compiler (GNU C was slow). Devpac, DICE and OMA was all I could afford as a high school student - they worked pretty well, were fast and good investments.

I build everything in OS X using vbcc, vasm and vlink. These are portable command line tools, but with a couple of scripts and a decent editor you can build a simple IDE. The way I've set it up lets me go from source to program running on the screen in two key presses so it's pretty alright.

Originally Posted by Photon

If I know Leffman he's made a performance chart of all Assemblers, if he says so, it is so. I think he's tried them all!

I did I can't remember the exact numbers, but Barfly and phxass are in the top in a league of their own, about 50-100 times faster than ASM-One and Devpac for large source files, but for small to medium files they're all pretty much the same speed.

[Thorham]

Originally Posted by Leffmann

I can't remember the exact numbers, but Barfly and phxass are in the top in a league of their own, about 50-100 times faster than ASM-One and Devpac for large source files, but for small to medium files they're all pretty much the same speed.

Not over here I can't get Barfly to cache the system includes I'm using and Phxass doesn't seem to have a cache at all. In this case, Asmone, which caches all includes, is much faster. Phxass is pretty slow in such a case.

But really? Phxass faster than Asmone? I have to see that to believe it.

[Leffmann]

Originally Posted by Thorham

Not over here I can't get Barfly to cache the system includes I'm using and Phxass doesn't seem to have a cache at all. In this case, Asmone, which caches all includes, is much faster. Phxass is pretty slow in such a case.

Phxass will be much slower if you're keeping all your include files on floppy I guess. It has no way of caching files since it's a single and stand-alone command line tool, and Barfly employs its file cache through a separate library which keeps the files in memory, there are instructions in the manual on how to enable it.

[weiju]

Originally Posted by Leffmann

I build everything in OS X using vbcc, vasm and vlink. These are portable command line tools, but with a couple of scripts and a decent editor you can build a simple IDE. The way I've set it up lets me go from source to program running on the screen in two key presses so it's pretty alright.

Fantastic, this is exactly what I was looking for (hasenbraten.de ? I get hungry ) - and was quite easy to install, too, thanks a lot !

[Thorham]

Originally Posted by Leffmann

Phxass will be much slower if you're keeping all your include files on floppy I guess. It has no way of caching files since it's a single and stand-alone command line tool, and Barfly employs its file cache through a separate library which keeps the files in memory, there are instructions in the manual on how to enable it.

I'm not keeping things on floppy, but on HD. The Barfly manual says that it can't cache SET and relative things, and these are used by the system includes. Asmone handles all this with ease.

[Leffmann]

This is turning into a real argument so this will be my last reply on this.

Originally Posted by Thorham

I'm not keeping things on floppy, but on HD. The Barfly manual says that it can't cache SET and relative things, and these are used by the system includes. Asmone handles all this with ease.

No actually Barfly is the better here, because while both of them will handle include files the same way by just keeping them in memory and assembling them every time, Barfly can also preassemble files that meet certain requirements to further reduce assembly times, but ASM-One can't.

ASM-One is also not aware of changes to its file cache. If a file changes, f.ex if you add something to your library of macros, then you have to manually tell ASM-One to empty the cache and reload all files again, even if you've only changed one of them.

Yes, I'm currently trying to get as much knowledge of BASIC as I can and then begin on z80 Assembler.

[Thorham]

Originally Posted by Leffmann

This is turning into a real argument so this will be my last reply on this.

No, it's not, I'm just speaking from my own experience, and it's perfectly possible that I simply missed something or did something wrong. Don't worry about it

Originally Posted by Amiga Forever

IF yes and what you coding on?

Yea on both a real Amiga as well as WinUAE; both on my registered copy of CubicIDE (so C/C++)