Michael Kohn - java grinder (https://www.mikekohn.net/micro/java_grinder.php)
Anyone add support for CPC? :)
I am actually impressed with what little java code that C64 demo runs... 8)
Would be nice to have a CPC API as well there as it an interesting project.
It is more or less a bit similar to CPCtelera project as far as I understand, isn't it?
After taking a closer look at the C64 demo (which is impressive) it seems like this depends on very machine specific libraries.
The "JAVA" part "just" seems to be pure normal control flow (if, then, a++, b++) - so I guess it is not worth
the effort while we have C and powerful libraries available for crossdevelopment.
I'm not very deep in CPCtelera, maybe it can be "recycled" as CPC Implementation for this use case. Maybe give the java grinder author a "hint" :) ...
For CPC development, CPCtelera is awesome for me.
What would have been nice with Java was for it to convert JavaME, which was almost the idea I had with sMIDP2lib.
I.e. you code for JavaME (using a certain approach of course), thus targeting older cellphones (and Android too if you had the sMIDP2lib for Android).
And then sMIDP2lib for the CPC would create a CPC version.
The thought was that it would make more people look into CPC game-development, because they wouldn't only be targeting the CPC.
I did actually start the sMIDP2lib project on the CPC. Demoniak helped out a lot creating functions for SDCC.
The idea was to create a J2ME game - then simply copy 99% of the source directly into a CPC project.
I managed to do this for J2ME -> Android and for J2ME -> Flash and even for J2ME -> HTML5 (had to run through a converter first though).
But the project died. And then came CPCtelera which I'm finding much more interesting.
I'd might check it out, if it was like this site (http://www.quitebasic.com), but that site only produces the results on the Canvas and Output provided, guess writing it for an Amstrad falls into the too hard basket. Just seems to be an interesting idea of making a language on a Website and having example programs, as well as documentation to get you through the language, to me has appeal.
Yep, this is merely a way to code for old computers using a different language - Java (but probably Clojure, Scala, Jython, JRuby, etc too) - but without the standard Java frameworks or compatibility.
As such, porting CPCTelera or similar to the framework would be a great idea, as I find a lot of the Java development ecosystem to be quite powerful (it's what I work with all the time).
The interesting aspect is that it really uses the Java bytecode as an intermediary object code for the final compilation step to native assembly.
The fact that you can write in Java for the Atari 2600 and get worthwhile results on a system with 128 bytes of RAM is pretty amazing. But then again, no JVM, no frameworks, and a static hardware-specific API...
There is already Z80 support in Java Grinder itself... it wouldn't be so hard to create an API for hardware and fill in the assembly language code that goes along with the function calls.
Hi there, I tried it a little bit with @mikeakohn (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1707) helpo but now I am stuck.
So if you are C/Java experienced, maybe you can help me get it fly ...
**********************************************************
First, you need a gcc development environment. I have cygwin64 installed as described in this manual: CPCtelera Reference Manual - . . (http://lronaldo.github.io/cpctelera/files/readme-txt.html#Software_Requirements)
after that (which takes a loong time if you are new to it :) ) you need to install a JAVA SDK (like this: Java SDK (64 Bit) - Download - CHIP (http://www.chip.de/downloads/Java-SDK-64-Bit_47299013.html))
Now you have to tell your Cygwin where to find JAVA ->
I did edit the file ".bashrc" which is in the your users home directory of the cygwin installation (..\home\username\)
and entered the path to my JDK (which is located at Windows Drive "D" in Path "JavaSDK").
!! Use an editor that saves this in UNIX format ! (Like Notepad++ Notepad++ Portable - Download - heise online (http://www.heise.de/download/notepad-portable.html)) !!
# -- Tell it where to find java, for example
# "/cygdrive/c/Program Files/Java/jdk1.8.0_05/bin"
export JAVA_HOME=/cygdrive/d/JavaSDK/bin
export PATH=$PATH:"/cygdrive/d/JavaSDK/bin"
In terminal, change where you want to have java-grinder (I chose my user home), and type in "git clone https://github.com/mikeakohn/java_grinder.git (https://github.com/mikeakohn/java_grinder)
". This will downlaod the latest release.
After that, type "make". Look if everything builds ...
Now - install latest CPC try from attached ZIP into followin locations:
\api\cpc_.cxx
\api\cpc_.h
\generator\CPC.cxx
\generator\API_CPC.h
\generator\CPC.h
\java\net\mikekohn\java_grinder\CPC.java
\include\cpc.inc
\samples\cpc\CPCHello.java
\samples\cpc\CPCHello2.java
\samples\cpc\CPCGraph.javaGo to javagrinder home directory, "make clean", "make", "make java"
Now if you go to samples\cpc\
you can javac an example:
javac -classpath ../../build/JavaGrinder.jar CPCGraph.javaand javagrind it:
../../java_grinder CPCGraph.class cpc_graph.asm cpcNow - I am stucked. I get
Quote
--> Function not implemented 'screen_I' ../api/invoke_static.cxx:171
** Error compiling class.
@mikeakohn (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1707) looked at it
"it should be:
int CPC:cpc_screen_I(
classes are all uppercase... functions are all lowercase except for the signature... it was done that way because the signature in JNI is always uppercase..."
Now it IS ... I must have some very noob mistake in there (brackets ? ; , ?) which does not disturb make, javac ... but javagrinder does not know my functions WITH parameter. CPC.cls() i.e. works ...
Tada !
Ok, it is just a small demo, but with text and coloured graphics ;D
import net.mikekohn.java_grinder.CPC;
public class GrafCPC
{
public static void main(String args[])
{
int i;
char c;
CPC.screen(1);
CPC.plot(1,1,2);
CPC.draw(640,200,1);
CPC.draw(0,200,2);
CPC.draw(640,0,3);
String txt = "Very simple Grafix for CPC in JAVA";
for (i = 0; i < txt.length(); i++)
{
c = txt.charAt(i);
CPC.putChar(c);
}
c=CPC.readChar();
}
}
Thx for your software and patience , @mikeakohn (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1707) !
Waiting for your first JAVA-games, ppl :)
Congrats!
Support for 'new' is still missing?
Now all we need to do is to port the CPC class to other Java-supporting platforms, and then we can create games for multiple platforms in (almost) one go. :D
This would be very easy now - not a lot implemented yet :D
TBH, I wanted to get it work. "Finishing" the firmware class - I dunno.
[size=78%]Maybe I'll try to implement on sprite routine or something like that from CPCTelera as PoC.[/size]
The generated code is very push/pop heavy and looks not very speedy. So for real projects / games I'd still recommend C or ASM.
Yea... would probably be a better project to port CPCtelera to other platforms. :)
Java Grinder seems to be good idea. However I would prefer something CPC specific. The .dox format invented by @Prodatron (http://www.cpcwiki.eu/forum/index.php?action=profile;u=13) seems to do this for SymbOS and HTML. So what's about a Java-like language for the CPC, but using specifically the powers of the CPC? I didn't look too close at Java Grinder, so it's hard to tell how close it could be to the CPC design. The problem of all the all-computer, all-OS solutions is a loss of speed. Windows is the perfect example for that. With a CPC I still can beat Windows in some tasks. Just my thoughts... :)
Quote from: SRS on 11:25, 08 April 16
The generated code is very push/pop heavy and looks not very speedy. So for real projects / games I'd still recommend C or ASM.
Guess it would depend on what Games one would want to write.
Quote from: SRS on 11:25, 08 April 16
The generated code is very push/pop heavy and looks not very speedy. So for real projects / games I'd still recommend C or ASM.
The push/pop can be changed to ld (I+D) instructions similar to what I did with 6809. I did it this way because it was the easiest way to do it at the time. Actually, I'm not sure if that would help or hurt it.
Quote from: mikeakohn on 12:33, 09 April 16
The push/pop can be changed to ld (I+D) instructions similar to what I did with 6809. I did it this way because it was the easiest way to do it at the time. Actually, I'm not sure if that would help or hurt it.
Ah, do you have a link? (Found Z80 on the page, but can't click it). :)
@TFM (http://www.cpcwiki.eu/forum/index.php?action=profile;u=179): have a look at my latest addition - after it was checked and gets released.
Just a short "snip" ->
You have to implement
virtual int cpc_setTxtPen_I() { return -1; }
virtual int cpc_setTxtPen_I(int c) { return -1; }
The one with (int c) is the new one (for calling with CONST)
int CPC::cpc_setTxtPen_I(int c)
{
if (c < 0 || c > 15)
{
printf("Error: Color index out of range\n");
return -1;
}
fprintf(out, " ld a, 0x%02x\n", c);
fprintf(out, " call TXT_SET_PEN\n");
return 0;
}
int CPC::cpc_setTxtPen_I()
{
fprintf(out, " pop hl\n");
fprintf(out, " ld a,l\n");
fprintf(out, " call TXT_SET_PEN\n");
return 0;
}
and add-on to CHECK_FUNC(setTxtPen,_I) also CHECK_FUNC_CONST(setTxtPen,_I)
and virtual int cpc_setTxtPen_I(); and virtual int cpc_setTxtPen_I(int c);
*********************************************************
The new one compiles to i.e.
CPC.setTxtPen(3);
ld a, 0x03
call TXT_SET_PEN
the part with variable like
CPC.putChar(char c);
gets
ld e, (iy+8)
ld d, (iy+9)
push de
; putChar_C()
pop hl
ld a,l
call TXT_OUTPUT
Cool! You're the man! :) :) :)
Now with 16bit (unsigned) arithmetics and Memory-API support for Z80 Platform.
My test programs came to a point where the missing "new" (which is clearly stated at homepage) is a reason they can't be made (by me).
So, I'll for sure add some this and that for now and then but I won't be able to push it much further - but all of you feel free to evolve it beyond (maybe some crack can implement the "new" capacity?).
Looking out for first games / demos written in Java now :)
Quote from: mikeakohn on 12:33, 09 April 16
The push/pop can be changed to ld (I+D) instructions similar to what I did with 6809. I did it this way because it was the easiest way to do it at the time. Actually, I'm not sure if that would help or hurt it.
It would be more a peephole optimization for the generated ASM that could help a bit for more serious projects.
Example : "screencpc" there are at least 3 "pairs" of push and direct pop the same register. removing them manually from ASM saves 6 Bytes of code / 63 cycles.
SDCC has a real nice peephole optimizer, but it's not like an extra *.exe that could be included in the Makefile for samples/cpc, sadly.
This, of course, is "
complaining on a high comfort level" :)
Quote from: mikeakohn on 12:33, 09 April 16
The push/pop can be changed to ld (I+D) instructions similar to what I did with 6809. I did it this way because it was the easiest way to do it at the time. Actually, I'm not sure if that would help or hurt it.
Do you mean storing the stack parameters in a static block of memory instead? Then you could only have one level of function calls.
Quote from: SRS on 16:07, 28 April 16
It would be more a peephole optimization for the generated ASM that could help a bit for more serious projects.
SDCC has a real nice peephole optimizer, but it's not like an extra *.exe that could be included in the Makefile for samples/cpc, sadly.
It is pretty good (but several bugs reduce its usefulness, most of which are fixed in z88dk's version btw) but even if it were separated into a separate exe it would not be portable to anything else.
The least problematic issue is that it can only operate on asz80 syntax asm with correct whitespace. Indexed register instructions have to use the weird ix syntax, constants must use the # operator and so on.
The real problem is that it is using information delivered to it by the compiler so it can't really be separated from the compiler.
However, having said that, there is another peephole optimizer that does operate separately from any compiler called copt. This one is a regular expression engine that can look for patterns and make text substitutions. For things like removing redundant pushes and pops, copt can do this very well. If Java Grinder is a simple compiler that generates code locally rather than trying to do register assignment, as it seems to be, copt can be effectively used to optimizing common code patterns in its output.
Quote
My test programs came to a point where the missing "new" (which is clearly stated at homepage) is a reason they can't be made (by me).
So, I'll for sure add some this and that for now and then but I won't be able to push it much further - but all of you feel free to evolve it beyond (maybe some crack can implement the "new" capacity?).
There are several characteristics that make Java unsuitable for embedded systems and new is one of them. Objects are created and thrown away with impunity which is a problem for execution speed in small memory systems because of the frequent garbage collection and large amount of memory that must be set aside for a heap. But it would still be interesting to see if someone does it.