Java-based language for Atari?

[DarkCart]

I had an idea. Would anyone be interested in a Atari programming language for Java? I'd imagine the code looking like this

public class Game {

    public static void main(String[] args) {
        AtariGame a = AtariGame.createGame("My Game");
        Playfield p = a.getDefaultPlayfield();
        p.setPlayfield("playfield data here");
        Screen s = a.getScreen();
        s.add(p);
    }

}

The code would be interpreted to assembly, which would then be compiled using dasm.

 

Have I gone crazy?

[ZackAttack]

Have I gone crazy?

You will once you try to build the interpreter. Maybe if you required everything to be static it could be done, but even then I think you'd be looking at a very sizeable task.

[ZylonBane]

Since Java is an "enterprise" language, and thus utterly horrible, I'm thinking eww, ick, oh god no.

[Thomas Jentzsch]

I think handling objects would be too much, even when compiled to assembler. There is quite some overhead in every object (memory and CPU), and especially for the 2600 hiding that overhead seems not like a good idea.

 

If you leave out objects and memory allocation, making everything static, then the results would be mostly similar to bB.

[Mr SQL]

I had an idea. Would anyone be interested in a Atari programming language for Java? I'd imagine the code looking like this

public class Game {

    public static void main(String[] args) {
        AtariGame a = AtariGame.createGame("My Game");
        Playfield p = a.getDefaultPlayfield();
        p.setPlayfield("playfield data here");
        Screen s = a.getScreen();
        s.add(p);
    }

}

The code would be interpreted to assembly, which would then be compiled using dasm.

 

Have I gone crazy?

Cool project DarkCart! You're welcome to use the Virtual World BASIC runtime or parts of it if you like, it's got objects and memory allocation which could fit well with Java.

 

I think handling objects would be too much, even when compiled to assembler. There is quite some overhead in every object (memory and CPU), and especially for the 2600 hiding that overhead seems not like a good idea.

 

If you leave out objects and memory allocation, making everything static, then the results would be mostly similar to bB.

 

Tom, I think a high level programming language must surface objects to the developer - bB and vwB both surface phantom hardware for a screen buffer and vwB surfaces a camera object and a large virtual world as well; these are objects the developer can marshall visually (drawing in the code) and programmatically.

 

Same deal with the sprite libraries, these objects are also visually defined and surfaced with the properties and methods of their respective runtimes; bB supports multiple color attributes and vwB supports vertical flipping and a tile mapping method to connect more objects.

[+Gemintronic]

In order to garner users it'd have to provide something that both existing BASICs do not. More multi-colored sprites without extra hardware. Higher resolution multi-color playfields in RAM. That's my take

[neglectoru]

I think the biggest challenge for a Java-like language would be memory management. Dynamic memory allocation and garbage collection is at the heart of Java. On the 8-bits, being able to optimize to static and absolute memory reads is highly desirable.

 

 

Some of the things I like about Java are strong static typing (to catch errors at compile time), enumerations (rather than integer constants that can be confused), and organizing with procedures / classes. For these reasons, I think Pascal (or Oberon) is actually a good choice for the 8-bit, and if you are cross compiling from a modern machine, you could probably do a lot of ahead-of-time analysis to make decent code.

 

I'd love to see a high level yet high performance API that abstracts the screen, sound, and so on. Good luck!

[Thomas Jentzsch]

Tom, I think a high level programming language must surface objects to the developer - bB and vwB both surface phantom hardware for a screen buffer and vwB surfaces a camera object and a large virtual world as well; these are objects the developer can marshall visually (drawing in the code) and programmatically.

Agreed. But the more abstract you become, the more overhead (on average) you create and/or the more you limit the potential. There is a reason why abstraction became popular when the CPUs became faster. I cannot see many of the benefits of Java (e.g. simplified memory management) are usable on a 2600. C++, Pascal or Modula all seem better suited.

[Mr SQL]

Agreed. But the more abstract you become, the more overhead (on average) you create and/or the more you limit the potential. There is a reason why abstraction became popular when the CPUs became faster. I cannot see many of the benefits of Java (e.g. simplified memory management) are usable on a 2600. C++, Pascal or Modula all seem better suited.

 

What languages are you and Andrew considering with your BoulderDash development kit?

 

Modula or Pascal would be cool but I think C/Java style syntax parsing might be more popular. Forth could be interesting too.

[joe_7]

Hi, new here.. I contribute to a java bytecode compiler project (called java_grinder) which aims to support the 2600 enough to make simple games:

https://www.mikekohn.net/micro/atari2600_java.php

Each platform has an API written in assembly which allows access to the video, sound, input, etc. Only a subset of java is implemented so there are limitations. The 2600 is particularly challenging and there are many problems, but I'm optimistic that things will get better as we learn more about the platform.

This is our demo game so far:

[ZylonBane]

I assume this is one of those things that gets filed under "Because I Can" rather than "Actually Useful".

[joe_7]

Wow.

[Thomas Jentzsch]

Put him on ignore. That helps.

[+SpiceWare]

https://www.mikekohn.net/micro/atari2600_java.php

Your site has this - "So the programmer has to figure out when the horizontal blank is starting and change the bitmap and color registers before the TV starts drawing again. That horizontal blank time is only 68 CPU clock cycles in length. Not a lot of time."

 

There's 76 CPU cycles per scanline. Horizontal Blank occurs during the first 22.6 cycles of the scanline. For reference, see the Asymmetric Playfield TIA Timing diagram here.

 

Put him on ignore. That helps.

 

Seconded.

[mikeakohn]

Your site has this - "So the programmer has to figure out when the horizontal blank is starting and change the bitmap and color registers before the TV starts drawing again. That horizontal blank time is only 68 CPU clock cycles in length. Not a lot of time."

 

There's 76 CPU cycles per scanline. Horizontal Blank occurs during the first 22.6 cycles of the scanline. For reference, see the Asymmetric Playfield TIA Timing diagram here.

 

 

I grabbed that number from another webpage. Thanks for letting me know.

[joe_7]

Latest game test binary:

srtest1.bin

It's basically finished besides scoring. But there are only 6 bytes left in the ROM, mainly because my 6502 compiler generates 16-bit code. May have to make an 8-bit compiler which would save a ton of room.

The Java game source is here, but will change over time:

https://github.com/mikeakohn/java_grinder/blob/master/samples/atari_2600/Atari2600JavaDemo.java

[Thomas Jentzsch]

But there are only 6 bytes left in the ROM, mainly because my 6502 compiler generates 16-bit code. May have to make an 8-bit compiler which would save a ton of room.

IMO that's not an option, that's a MUST!

[Kylearan]

How does 16-bit code look like for a 8-bit processor? A NOP following each instruction?

Edited December 30, 2015 by Kylearan

[joe_7]

; 8-bit addition

clc

lda value1

adc value2

sta result

 

; 16-bit addition

clc

lda value1 + 0

adc value2 + 0

sta result + 0

lda value1 + 1

adc value2 + 1

sta result + 1

The 6502 has low cycles so speed isn't a problem for game logic, but it's almost twice the size. Going 8-bit now.

[Kylearan]

Ah, you meant code for 16-bit arithmetics, not 16-bit code per se. That makes more sense. :-)

 

Yeah, forced 16-bit arithmetics on the VCS is very wasteful.

[joe_7]

Implemented the 8-bit compiler and updated the kernel to have better resolution/stability, and a scoreboard. There is still some 16-bit stuff in there (because the addresses are 16-bit) but doing the math/loops/etc in 8-bit saved a ton of room. There are still 300+ bytes left for a title screen and perhaps some music.

Since Java only has signed numbers, the horizontal positions are scaled from 0-127 to 0-158. This makes programming a lot easier even if it's not perfect. Only going for 1970's quality anyway

Edit: forgot the binary: srtest2.bin

Edit: With 33 bytes to spare it's a mostly-complete game: srtest3.bin

(Must use the reset button to start now, first one to 10 wins. Enemy AI still needs work.)

Edited January 1, 2016 by joe_7

[joe_7]

Finished the game up today, added game variations, scoring, etc:

 

And the binary of course: sr_final.bin