Retroness of your development process

[+Random Terrain]

Programmers are people who poop and pee

 

Lies!

[CPUWIZ]

Sometimes, both at once!

[+Random Terrain]

Sometimes, both at once!

 

If it's at the urinal, I'm impressed.

[+nanochess]

I think "real programmers" should read "professional programmers" for my taste.

 

Seems like real programmers are good at math and physics.

Not always

Seems like real programmers are professional and have no problem with time management.

Myth

Seems like real programmers can break down a program into smaller parts and hold a basic outline of the whole program in their minds.

True

Seems like real programmers know how long each part of the program will take to finish, as if they can see into the future.

50%

Seems like real programmers can learn any programming language in the same amount of time it takes the average person to order a burger and fries at a fast food restaurant.

Myth

Seems like real programmers would never use BASIC unless they had a teaching job and The Man forced them to use it.

Myth

 

I don't know exactly who started the myth of real programmers as it's mostly a archetypical joke like the Nutty Professor of Jerry Lewis or Big Bang Theory that shows scientifics as laughable stupid jerks.

 

Myself being a professional programmer, I passed from novice to amateur and then professional over twenty years.

 

Over time you develop your own skills and toolsets.

 

I know of professional programmers that use IDE and BASIC, others only program in SQL, and also of programmers that are heavily against certain languages just because them doesn't fit their taste.

 

You're a good programmer if you can program what you want when you want. Programming language doesn't matter.

 

Novice, amateur and professional are only subcategories of speed/complexity, and with enough practice anyone can go professional.

 

Just my 2 cents.

Edited January 4, 2014 by nanochess

[Kylearan]

"Real" or "professional" programmers, the most important thing is that the code they produce is maintainable and good for others to read, understand, extend and modify - regardless of what language is used or how quickly the code is produced. That's something many people who consider themselves "good" programmers miss, and it's a PITA when they switch jobs, the project grows, or they stop working on the project and others want/have to take over. And yes, needless use of polymorphism just for the sake of it, excessive testing beyond what's really necessary, or "clever hacks" are annoying in that regard, too. There's a lot of ideology flying around in that area (language, tools, methods like SCRUM... *rolleyes*)...

 

 

[Mr SQL]

 

Well, I would have been a broom pusher in those days, since I've written everything from assembly to BASIC to COBOL to Lisp to Perl to Javascript for money but could only sporadically beat my electronic chess game even on its easiest level as a teenager, to say nothing of the chess club kids. But then, working at Cold-War-era IBM wouldn't exactly have been a good fit for me, anyway. Dated one of their coders in the early '90s and it had certainly changed, but...

 

To keep it retro, I have fond memories of getting Geoworks Ensemble to run on an IBM PC-XT with an amber monitor, serial mouse, and a keyboard that could be used as a lethal weapon. (It was neat, cooler than my Amiga in some ways, but it didn't have emacs, or even a proper shell.)

 

raindog,

some of those 4k Chess programs are no joke! Fidelity's 1979 Chess Challenger 7 felt like it played at around 1400 though it's rated at 1200 (play is not consistent to the end game). Ditto for Atari's psychedelic Video Chess; I like to play that one on level 4, enjoy the five minutes of colourful screen transitions between moves where the board vanishes

 

In contrast I remember the 4k Chess cart for the Tandy Colour computer played surprisingly bad; I imagine it's engine comprises a much smaller percentage of the 4k than it's contemporaries - the dedicated chess computers had an edge early on because they didn't have to waste space on display routines.

[+Gemintronic]

"Real" or "professional" programmers, the most important thing is that the code they produce is maintainable and good for others to read, understand, extend and modify - regardless of what language is used or how quickly the code is produced. That's something many people who consider themselves "good" programmers miss, and it's a PITA when they switch jobs, the project grows, or they stop working on the project and others want/have to take over. And yes, needless use of polymorphism just for the sake of it, excessive testing beyond what's really necessary, or "clever hacks" are annoying in that regard, too. There's a lot of ideology flying around in that area (language, tools, methods like SCRUM... *rolleyes*)...

 

 

 

Despite a good track record of finding show stopper bugs my former company spent my time and their money over-formalizing and automating the testing process. Towards the end I spent more time fiddling with visual basic and automated tools than catching bugs. As a software tester I was admonished for shipping date slips instead of being praised for finding and properly documenting issues before release. I'd blame wrong minded attitudes towards QA more than excessive testing any day

[raindog]

 

raindog,

some of those 4k Chess programs are no joke! Fidelity's 1979 Chess Challenger 7 felt like it played at around 1400 though it's rated at 1200 (play is not consistent to the end game). Ditto for Atari's psychedelic Video Chess; I like to play that one on level 4, enjoy the five minutes of colourful screen transitions between moves where the board vanishes

 

Mine was actually this one (or looked just like it): www.bygone-binds.ecrater.com/p/9111729/tandy-electronic-computerized-chess-game Knowing Radio Shack, I assume they just rebadged someone else's. I did about as well (or not) with the chess games I later tried on the C64, though, and even Battle Chess on the Amiga. And, for that matter, every non-real-time strategy game or RPG I've ever played since then.

 

If the objective is "make this machine produce output Y from input X, in such a way that you don't have to rip it out and start over when it's time to add more features", I have no problem strategizing, even if "this machine" is made up of half a dozen different APIs connecting to 10 different data sources over which I have little to no control. If it's "there's this guy who's out to get you and you need to whack him first, and you need to politely take turns doing it, so figure out all his possible moves 5 turns in advance" (or the modern RPG variation of "you need to politely take turns doing it (but while you're picking an action he can sneak up on you while you're thinking"), I'm toast.

[tep392]

editor: windows notepad

assembler: MADS command line

disassembler: dis6502

hex editor: xvi32

bitmap editor: paint.NET, tilelmolester

 

I have a goal to develop a game entirely on my 800XL using floppy drives. Only exception is I will backup files onto a PC.

[ClausB]

Editor: NotePad (with Atari 8-bit font, of course).

 

Assembler: Cross-8, a cool 80's era table-based assembler for PC-DOS with tables for many 8- and 16-bit micros. You can edit the tables to add instructions and simple macros. The 6502 table had some bugs to fix, IIRC, or was that the Z80? Long ago I ported a project from 8048 to 8051 and did it by creating a table to assemble 8048 mnemonics into 8051 machine code. This assembler outputs hex files, so I also had to find a hex to bin converter, called hex2bin.

 

Tester, debugger, player: Stella. I don't even own a 2600 (sorry).

[ClausB]

Oh, and for max retroness, you have to type mnemonics in all caps.

[raindog]

Eh, I was in the habit of hitting Shift-Commodore to switch to lowercase on boot within a month of getting my C64 in 1983. For actual "max retroness" you need to be 'writing code' using switches and/or patch cables without the benefit of an assembly language, as they did on ENIAC. Never went back that far myself, but I did use paper tape to boot the PDP-8 I had in my basement 25 years ago courtesy of my EE housemates.

[SmileyDude]

For my 2600 hacking, it's vim, dasm, make and Stella. Not because I want it to be retro, necessarily - it's just that those happen to be a combination of tools that work well for me.

 

Sometimes I'll use TextMate as my editor instead, but that means having to switch apps rather than remaining in Terminal for everything.

 

I'll usually keep my iPad handy as well for reference material, but my web browser is usually open to something as well.

 

If I really wanted to be retro in my tools, I would probably try using an Apple II or some other 8-bit machine as my development machine and a real 2600 as my test machine. But I'm rather fond of having a debugger and a short build-deploy-run cycle

[SmileyDude]

Oh, and for max retroness, you have to type mnemonics in all caps.

I know it's more authentic to how the machines of the day presented them, but yuck - I rather not have uppercase mnemonics these days

[maiki]

I guess for some people over here it would be a true journey back in time to develop a 2600 game using only some authentic eg. Imagic development setup. Some vintage Atari 800 and custom development cartridge and all that. Without any PC. I can imagine the value of such game might rise a bit. Stating on the cover "developed using Atari 800 home computer and Atari 2600 video game system only"...

 

http://atariage.com/forums/topic/198712-atlantis-development-setup/

[Thomas Jentzsch]

There might be a very(!) few people who would honor this, but I don't think this would make a big difference. Else e.g. Basic games would generally have a lower value, even if they have an adequate or even better quality.

[enthusi]

Ah, nice thread.

To me it probably boils down to: I have to enjoy what I do and how I do it as this is my hobby.

Also: for me coding for such a limited platform means that assembler is mandatory, just due to efficiency. Lack of efficient code (for good reasons like time, money, maintainability etc...) is what bothers me with all modern codes/drivers etc. So when I code for 8 bit machines, I want to max them (and/or my skills out.

I don't use IDEs but Im not religious about it. If other people do: go ahead.

My assembler of choice is XA (floodgap). It comes with a handy disassembler and I used to reverse code alot (mostly not for the 2600 though).

I use either Kate as editor or actually terminal-mode-editors such as nano, nice edit or mcedit. Not vi/vim

Oh, and I develop only on linux as I own no other machine anyway. Much of Assembloids2600 was actually even coded and partially tested on a raspberry pi.

Even the c64 version

Here is an enormously oversized (sorry) picture of the C64 setup. RaspberryPi at the bottom left. Running vice and even faster: transferring code to the real c64 next to it.

http://enthusi.de/return/desk02.png

A similar approach applies for 2600 coding. Stella is awesome with its debugger etc. However I had a little bug/glitch that only z26 showed properly (like my junior).

Every now and then I transfer the binary to SD for harmony card or if it's set up I use the Supercharger for quick and easy transfer (its just a 4k anyway).

That gives me the most joy out of it actually

There are even weirder ways to develop. I will come back to this

My code is always rather straight forward. I dont even use macros as they tend to confuse me

So I always want to know why the binary looks like it does and i.e. I want to be fully able to remove a redundant CLC or such in the code at any time.

Sometimes I check/fix code in the resulting binary rather than stella (not very often though

But only when I deem it more practical, not to add that extra pain.

I dont like the usage of given tools at all (except for the editor/assembler

So when I do gfx I write own converters and use GIMP and/or plain PNG from my graphician.

I love coding tons of tools to optimize data. Like the possible overlap of score digits or the overlap of audio data with PF0 data or nice sinus-tables etc etc.

For that I write small python scripts. So that part aint exactly old school at all.

I wouldnt exactly want to debug code after writing it to eproms again and again like some had to in the old days.

But I feel awe for people that went through it and came up with those masterpieces.

What impresses me the LEAST:

using modern hardware and converters to play/stream movies to retro-plattforms.

What impresses me the most:

getting things done with even smaller, faster, smarter coder than anyone every did before.

Which is why I enjoy the tight 2600 demo scene alot as well.

To value a game for the 2600 I judge how much I like it (I dont play games THAT much though) and immediately I consider how it might have been done.

The less obvious that is, the more I am excited.

A beautyful game in 1K might mean more to me than a 32 KB game ever could.

Not just because I know how hard fighting for bytes can be but also because 32 KB is ALOT and to use it efficiently is very hard already.

So hard in fact, I am not sure I can grasp it all That coming from someone out of C64 scene normally

Unfortunately I suck at music. I thought no one would mind bleeps and blorps on the 2600 but then I noticed that people really master the TIA Audio as well - damn

I dont mind people using basic etc. But I prefer a strict indication. I prefer 'wow, look what the 2600 can do in just 4k' over 'look what the 2600 can do in this game. Yeah it uses 27 external CPUs and 4 MB of RAM. Cool!'.

And of all the 8 bit machines I know and coded for, the 2600 sure does not have to hide at all for what a bare metal device can achieve

Extra and non-well-defined hardware killed many scenes for other systems IMHO.

Like amiga (how many not-really-compatibles are there?) or spectrum (on which speccy does this game/demo run again?) or atari (xl, xe, 400? 800? 130?).

The c64 demo (and game) scene became so big as it always stuck VERY strictly to vanilla c64 + drive, nothing else.

Most other scenes (vc20 i.e. as far as I know) rely heavily on hardware add-ons etc.

I always like and love the 2600 for what it was and is and what can be made with it, not what it possibly could be turned into

so, that's my POV if I forgot nothing important

[johnnystarr]

On my blog, I wrote an article about using Merlin on the Apple //. It's extremely frustrating, but you can't help but feel "retro" when you use it.

 

I'm a complete perfectionist, so I'm always finding ways to improve my code formatting. For awhile, I thought it would be best to use a more classic approach.

 

I dropped the uppercase mnemonics and have also picked up some good habits from viewing modern code. I usually prefer a Unix environment for development (Vim). However, I work in IT as a Windows admin. On my lunches, I use a combination of Notepad++, batch scripts and Stella (win64). I find this is all I really need. My projects are stored in my Dropbox folder so I can get to work on my Linux box when I get home.

 

Although I would love to use a PDP-10/11 and a logical analyzer so I can say I'm "ultra retro", it just isn't feasible. I don't view it as cheating to have access to modern toolkits or emulators. It's just simply what we have available. At the end of the day, my goal is to master 2600 development. The sooner I can get there, the more demos / games I can make

Edited April 1, 2014 by johnnystarr

[kamakazi]

What do I use? In this day and time I use a Windows environment for trying to learn Assembly Language for 2600 and 5200 development. I was going to try for the 7800 but I wanted to get my feet wet with a little older console first. I have, however, developed a few unpublished works in DarkBASIC Professional during college. As a matter of fact, one class centered around creating documents for clients to review. A project I had in the back of my mind since 2005 became the center. I was suppose to use mock-up images of the work but instead had the game up and running in 3 weeks. I used real screenshots from the game for the assignment. I even did the document to look more like the game's instructions (which in reality it really was) and, while impressive, didn't really get the grade I was hoping for. The instructor found it hard to believe that I created a game in 3 weeks. I didn't get a failing grade though.

 

For the tools I am using for 2600 development, I am using Emerald Editor (previously Crimson Editor), I plan to use Stella for testing purposes, and DASM for compiling my code. Since someone else on here mentioned having a setup for Lubuntu (and I'm a HUGE fan of Ubuntu) I am going to see if I can find what they used for Ubuntu (Linux). I'd rather use that than Windows. I never have liked the Windows operating system since it was first introduced.

[Mr SQL]

On my blog, I wrote an article about using Merlin on the Apple //. It's extremely frustrating, but you can't help but feel "retro" when you use it.

 

I'm a complete perfectionist, so I'm always finding ways to improve my code formatting. For awhile, I thought it would be best to use a more classic approach.

 

I dropped the uppercase mnemonics and have also picked up some good habits from viewing modern code. I usually prefer a Unix environment for development (Vim). However, I work in IT as a Windows admin. On my lunches, I use a combination of Notepad++, batch scripts and Stella (win64). I find this is all I really need. My projects are stored in my Dropbox folder so I can get to work on my Linux box when I get home.

 

Although I would love to use a PDP-10/11 and a logical analyzer so I can say I'm "ultra retro", it just isn't feasible. I don't view it as cheating to have access to modern toolkits or emulators. It's just simply what we have available. At the end of the day, my goal is to master 2600 development. The sooner I can get there, the more demos / games I can make

johnnystar,

I just read your blog entry about writing Assembly on paper and writing it outdoors in nature environments:

http://www.thestarrlab.com/search/label/Assembly%20Language

 

That's really cool! You articulate it and illustrate those concepts really well - those are some of my favourite creative development processes for exactly the reasons you described!

 

Another favourite of mine I'll combine with that or do seperately is carrying my Assembly source files around on Rockbox, which is an open source OS for iPods and mp3 players; it's got a text browser that remembers your spot in the file and I'll use it to review different parts of the code I'm working on