A few years ago, [Mike]’s friend gave him an old Sega Genesis with the very cool and somewhat rare SegaCD drive attached. The SegaCD gave him an idea – while it’s not easy to burn a cartridge and play homebrew games on a real Genesis console, everyone has a CD burner somewhere. [Mike] began writing his demo and then realized adding Java would be easy on the 68000. The result is Java on three billion devices and a Sega Genesis.
This project is built around Java Grinder a Java byte code compiler that will compile classes, factories, and all the horrible Java design.design.pattern.pattern.patterns() into assembly language. Already, there are a lot of platforms supported by Java Grinder, including the Commodore 64, the TI99, and thanks to some work from [Joe Davisson], the Apple IIgs
With a byte code compiler, an assembler, and an API for the Sega-specific hardware, [Mike] set about building his demo. Since this was a Sega, it needed the ‘SEGA’ sound at the start. [Mike] ended up recording his voice saying ‘JAVA!’ This plays through the Z80 on the Genesis.
The complete demo – viewable in its emulated format below – has everything you would expect from a proper demo. Starfields, dancing sprites, and even a Mandelbrot pattern make it into the three-minute long demo.
Wow, so you can make a 68000 emulate a 4004, with the power of java, no delay loops necessary.
http://e4004.szyc.org/ … OK That’s Java—-script… emulating a 4004, so all we need now is for the 4004 to run Java, so run the whole lot on the Sega, and sometime shortly before the heat death of the universe, it will be have booted up the emulator needed to emulate itself running itself. }:¬)
Do you want the Singularity?
Because that’s how you get the Singularity.
Died.
Now I just need a C to Java converter, so I don’t have to use that ugly language.
Simple, to convert C to java, just insert the following code between every statement:
for (int i=0;i<100000;i++) {
ptr = malloc(i);
free (ptr);
}
if your code still runs too fast, just increase the value of i, until you have the speed you need, or run out of memory.
How about the Squawk Java VM? Java in Java.
https://en.wikipedia.org/wiki/Squawk_virtual_machine
I would say that the time might be right for someone to do an ARM CMSIS port of the Squawk VM … but Java is nearly dead anyway.
…except for that pesky Android, which is mostly written in Java.
Yet has no JRE so one can run actual JAVA on Android. Can’t use my phone to monitor my networked printers which use JAVA in their internal print servers.
Ever heard of Dalvik? Or ART?
Sure, they are perfect examples of things that aren’t the JRE. Dalvik is a custom runtime that uses it’s own opcodes instead of java byte code and incompatible with it and ART is compatible with Dalvik byte code bubt AOT compiled.
Is Java really nearly dead? In terms of Java/swing apps on the desktop those never really took off so yes that has quietly fallen into obscurity. But what source of information did you base your statement on? On the TIOBE index Java is still at the top and up 6% from last year. Objective-C, on the other hand, is even less popular than assembly language and Ruby.
I’m going to ignore your bogus statement and say that it’s not quite dead yet and it’s getting better.
Great project.
This is an interesting project.
I wonder… there’s a lot of games in Java, particularly the J2ME (IIRC) that older, pre-Android, mobile phones ran. Think this could perhaps run one of them? You’d need to take into account the Megadrive’s lower colour palette, and I don’t think the Megadrive has a bitmapped display mode. But how groovy would that be?
Is it pretty powerful then? Essentially a re-compiler? It’s strange, cos most of the modern console emulators run on recompilers themselves, to emulate a less-powerful machine on a modern PC. This is the other way round!
I’d like someone to write a JRE for Android.
Excellent idea!
for maximum speed, it should be written in Java, running on a JRE written in java, running on a JRE written in Java.
More recursion == more speed!.
Next challenge: JAVA on Atari 2600.
-no dedicated video memory means as much as 80% of CPU power is wasted on maintaining screen
-CPU is 6507, easy to code for but not much option
-128 bytes of RAM unless one adds extra RAM
-4KB ROM size max without bankswitching. This includes any added RAM.
If you put enough RAM in a cart, the 2600 is a Turing machine like any other. The display isn’t bitmapped, as you mention, it’s… strange but efficient for the very primitive 1970s games it was designed for.
Actually every 2600 game since about 1979 is a massive hack. The later ones, as far as the latter half of the 1980s, I think 1989, very much so. Part hack, part torture, part mental gymnastics. Just getting anything more complex than Combat to display is an achievement.
I must be missing something. I know what SegaCD is. How did he managed to get his program to run on a Genesis with Sega CD. There must be some sort of protection, no?
Back then the protection was that CD burners cost thousands of pounds, or just weren’t available.
The Dreamcast had zero copy protection as well…. buy one, download the library and play any and all games you want. dreamcast was WAY ahead of it’s time.
DC has copy protection. GD-ROM couldn’t be copied directly but they left a very easy way of bypassing that. Mil-CD was a feature that was never used officially but hacker got hold of the detail and figured those out and when they ripped GD-ROM, shrank the file to under 700MB if needed, then applied Mil-CD the resulting ISO could be played without need for modchip or any other stuff.
SEGA goofed on the design.