• Please review our updated Terms and Rules here

What is your primary programming Language at present?

What is your primary programming Language at present?

  • Java/J2EE

    Votes: 2 11.1%
  • .Net/ASP

    Votes: 2 11.1%
  • Mainframe

    Votes: 1 5.6%
  • Embadded

    Votes: 0 0.0%
  • C

    Votes: 2 11.1%
  • c++

    Votes: 1 5.6%
  • Others(Please mention it in your Reply)

    Votes: 10 55.6%

  • Total voters
    18
At this rate, I should be able to program an Atari 2600 game by the end of the year! (NES not likely, as the architecture of the GPU is a bit more complicated, & plus I'd have to learn how to make use of those 22 memory-mapped registers)

Now you can *really* program the Atari 2600 with BASIC!

Cheers,

80sFreak
 
I know some RPG, as well. I'm not great with it, but I know enough to be dangerous. Would that be considered "Mainframe" for the purposes of this poll?
That seems plausable. I went to a job interview last year, and the boss asked me, half joking if I knew anything about RPG. They had a potential client who had some really old system written in RPG that needed a rehaul. This consultant firm in question already had more clients than they could handle, so they simply turned down this customer due to their lack of skills and it would not be worth learning it or hire in an expert.
 
LOL, It'd probably use up the whole kilobit of memory in the RIOT before it even draws some simple text!

Errrgh... Did you actually *GOTO* the website I linked to? This is not the old Atari BASIC on a cartridge. You do the programming on a PC where it is compiled and then you can run that binary on an emulator or the real thing. According to the site, its routines have been highly optimized.

Cheers,

80sFreak
 
I went to a job interview last year, and the boss asked me, half joking if I knew anything about RPG. They had a potential client who had some really old system written in RPG that needed a rehaul.

That doesn't surprise me, actually. Since RPG has always been the defacto standard for IBM's AS/400 and its children, there is an awful lot of RPG code out there. Our accounting system is written in native environment RPG with visual extensions available. Rock solid system, will probably run for 20 or 30 more years...

In fact, there are so many RPG accounting packages available that it took me almost 2 years of reviewing to find the right price/performance mix...
 
Long live BBC Basic :smile:
Hooray!

I'll be honest with you all, I can't program for toffee. I can make BBC Basic do what I want so long as it is text based (I made a text based game once, holey as a colander).

I will however have to learn pascal or delphi (I can't remember which syllabus for which college I applied to) come september as part of my A level computing course.

Oh, I am still looking into PIC assembley too. Not got much to show for it yet though.
 
Last edited:
Atari: With Batari Basic, you get an executable that you can burn to a EPROM (or mount cartridge image in the emulator) or perhaps load with help of a CuttleCart or whatever they are called. The little amount of RAM you have available is used as workspace, not storing the actual program.
 
*sigh* I KNOW! I'm just saying, that w/ 128 bytes of memory, AND code that isn't as efficient as hand-coded ASM (Although if you program the interpreter REALLY well, I wouldn't believe it'd be impossible to get close), running at just 1.19MHz, it's still not going to run very well! Just like programming something on BASIC on anything else, except probably faster in this case as it's reading from a ROM instantly rather than reading from a disk, storing to RAM, & THEN running it, & also because this would be compiled & not interpreted instantly.
 
Last time I checked, Batari does not bundle an interpreter with the program. Instead it compiles the code into human readable assembly code that is up to you to further hand optimize before you assemble it into a binary. Indeed on these systems a compiler will never generate as tight code as you could manage by hand, but I believe you get a good head start with a driver. I don't know how many bytes of RAM the supplied driver uses though.
 
Ah, it generates the ASM source? NOW I give it slightly more credit, although I still say that it'd just be too much of an enabler if it already requires you to know 6502 ASM, & the STELLA & RIOT architecture.
 
Well, I'm sure it would be excellent for someone like me, who already speaks 6502 quite well and has experience in programming other systems where you don't have to watch where you put your tongue all the time. I don't know how much of the Stella and RIOT you need to study to use it, but probably it helps if you are aware of what the hardware can and can't do. I haven't followed AtariAge forums for a while, but I remember most newbies posting their great game concepts failed on the point where they didn't recognize what was feasible and approximate difficulty level if it was theoretically doable at all.

If you're seriously considering programming for the 2600, I don't see what is wasted by spending a Saturday afternoon with this Basic package to check what it can do and how it does it. As I wrote, a few games in the MiniGame compo last year were developed with help from Batari Basic, perhaps extensively hand optimized. It seems to have filled its purpose, giving aspiring Atari 2600 programmers an easier way into the scene. From there one can study the technical details and one day use Basic only to draw up half functional prototypes.
 
OK, I'll byte...what is the storage limit for the 6502? If memory serves me, that's an 8 bit processor with a 16 bit address bus? So is 64K the max, or is there some bank select mechanism in place?

I've got a couple of cash registers based on the 6502, but I've never really delved into them to see what makes them tick.

I am, however, working on a 8085 based unit now, and I assure you, a great deal can be accomplished in 64K...
 
OK, I just answered my own question...found a data sheet on the 6502...

56 Instructions? I'll need to take a look at that and see how it compares to the intel set.
 
Natively the 6502 can only address 64K. By adding external bank switching circuitry, it can be "overcome" which has been proven by various memory expansions and also computers natively having more memory than the CPU can address.

I never counted the number of official instructions. Does that include all the addressing modes, or just the number of unique instructions? In many 6502 implementations, it is also possible to use undocumented ("illegal") instructions. Some of them are supposedly very useful, while others are instable and may lead to the program crashing. Personally I have never studied these undocumented instructions much. Since we were speaking about Atari 2600, which has a 6507 (somewhat stripped down 6502 IIRC), it is worth mentioning that undocumented instructions are highly valued on that system, because they save space and more importantly clock cycles in some cases. I also know sometimes one has to pad out an algorithm with slower or dummy instructions to synchronize it correctly, which is one reason why it probably is the most difficult 6502 based platform to learn machine code programming on.

Gee. Now this thread is slowly getting back on topic again. :-D
 
Back
Top