java compiler on Hack.a. day

[Tursi]

http://hackaday.com/2015/04/12/java-byte-code-ahead-of-time-compilers-and-a-ti-99/

 

Is the creator of this one present? on my phone so have not gotten a good look at it yet. :-)

[Willsy]

Wow! How cool is that!!??

 

More info here: http://www.mikekohn.net/micro/retro_console_java.php

[JamesD]

Looks like it compiles java bytecodes into native machine code.

I think a virtual machine tuned specifically to small environments might me better than a Java VM but compiling the bytecodes to native code has some potential.

[Tursi]

Looks like it runs pretty well, and from cartridge only, to boot. (If we could get it extended to store variables in VDP RAM, it looks like it might very well be useful for larger things, if anyone uses Java. (Sadly, I'm out. ))

 

Another point of interest we had going in another thread - there's a nice high res picture there of an opened Parker Brothers cart, he built his test from a Popeye.

[+Ksarul]

Nice find. We should invite him to Chicago. . .

[+retroclouds]

That is impressive! Good work!

[+Ksarul]

I think I will have to send him one of the 512K boards (or even a 128K board) to allow him to do some seriously expanded Java-programming fun on his TI. . .

[sometimes99er]

Wow !

 

The 9900 implementation is surprisingly short. And to go so far as to have the stack in the CPU workspace registers. Ha.

 

The Java bytecode instruction set is again surprisingly short and simple. I never took a look before, I should have. It's so ... Forth ... !?!??

 

http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings

[matthew180]

From the project website:

 

There is a chunk of extra RAM attached to the video processor, but I decided to just use the 256 byte area for variables. I figured it's not like anyone is going to use this for anything serious anyway.

People are so quick to write off anything that is not made in the last year or so. It must be hard to live in a world where nothing you have or do today will be relevant in a year or two.

 

At the top right of the cartridge, there is a piece of PC board that broke off when I cracked it open with a hammer.

Seriously? A hammer to open a cartridge case? I wonder what the expected outcome was?

[Willsy]

Wow !

 

The 9900 implementation is surprisingly short. And to go so far as to have the stack in the CPU workspace registers. Ha.

 

The Java bytecode instruction set is again surprisingly short and simple. I never took a look before, I should have. It's so ... Forth ... !?!??

 

http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings

Yes, underneath the covers Java is a stack-based language in a similar vein to Forth. Cool huh?

[gregallenwarner]

As a Java developer by profession, this is a dream come true!

[Tursi]

Seriously? A hammer to open a cartridge case? I wonder what the expected outcome was?

 

Probably exactly what happened, he didn't seem overly concerned. (Probably didn't know Popeye was uncommon, either )

[+OLD CS1]

 

Probably exactly what happened, he didn't seem overly concerned. (Probably didn't know Popeye was uncommon, either )

 

And, he just made it a little more uncommon for us and collectors.

[Opry99er]

There's one on eBay right now.

[+OLD CS1]

What is most interesting to me about this approach is that for years Java engines for Amiga have languished, and here this guys comes with a few months worth of work.

[mikeakohn]

Seriously? A hammer to open a cartridge case? I wonder what the expected outcome was?

 

I was looking for coconut milk.

 

Actually, I was trying to be really careful just hitting the corner lightly to break whatever was keeping that cartridge from opening (glue or something?). The other 2 cartridges I opened just had a screw to take and out pulled apart with not too much effort. This one was sealed somehow.

[mikeakohn]

Looks like it runs pretty well, and from cartridge only, to boot. (If we could get it extended to store variables in VDP RAM, it looks like it might very well be useful for larger things, if anyone uses Java. (Sadly, I'm out. ))

 

 

I could probably change the code to work out of VDP RAM also. I picked the static RAM because the module that generates the TMS9900 code was TMS9900.cxx. I started that module without knowing anything about the TI99 really. To me this module really should be generic to TMS9900 incase there is another system out there that uses this CPU and had more than 256 bytes of memory.

 

After finding out about the 256 byte limit, I figured for just a short demo, as long as there wasn't a lot of global / local variables and a lot of function calls, 256 bytes of RAM should be plenty.

 

That said, I could add a function to TMS9900.cxx to abract out all memory hits so it keeps the memory usage as it is now and then override it in TI99.cxx so that it can be configured to use VDP memory or fall back to the TMS9900.cxx's memory function.

 

Not sure if that makes sense.

[Tursi]

 

Not sure if that makes sense.

 

It does, and welcome! Believe it or not, we still enjoy writing serious applications for the old TI, and I know we have a few Java fans. This is pretty cool to see even in the little demo you did.

[Opry99er]

Welcome! Your work is quite impressive... But please dont destroy any more rare carts. LOL. I would be happy to donate a spare cart or two for your next project.

Edited April 14, 2015 by Opry99er

[Willsy]

Yes, welcome. You've done an incredible job.

 

It might also be nice if a library could be developed to allow execution of code (and read/writing of variables etc) in CPU memory. In the TI-99/4A (and it's specific to the TI-99/4A, not to the TMS9900) the 32K CPU memory expansion is mapped into CPU memory as follows:

• 8K from 0x2000 to 0x3FFF
• 24K from 0xA000 to 0xFFFF

This is "regular" CPU memory, for hosting code and data. Other areas of the memory map are used for other purposes (device service routines (individual BIOS for I/O devices such as disk drives etc), speech, VDP, sound etc).

 

Fantastic job. I'm no Java expert, but when I do use it I quite like it, though I don't go too far into object design - it's very easy to over-complicate java code with overridden methods and generics and blah blah blah... there be demons. I like it simple and slick

 

Good job, and welcome to the group.

[+OLD CS1]

Welcome! Your work is quite impressive... But please dont destroy any more rare carts. LOL. I would be happy to donate a spare cart or two for your next project.

 

A spare 64k Guidry board or two would be worth it. Or even one of the new 2MB baddies.

[matthew180]

I could probably change the code to work out of VDP RAM also. I picked the static RAM because the module that generates the TMS9900 code was TMS9900.cxx. I started that module without knowing anything about the TI99 really. To me this module really should be generic to TMS9900 incase there is another system out there that uses this CPU and had more than 256 bytes of memory.

Welcome to the forum, mikeakohn.

 

Keeping it generic is probably good, but how do you specify which parts of a memory map are suitable RAM/ROM for code and data? The tool can't blindly assume that all memory is a chunk of RAM, so at that point it seems you have to introduce machine-specific attributes, no?

 

After finding out about the 256 byte limit, I figured for just a short demo, as long as there wasn't a lot of global / local variables and a lot of function calls, 256 bytes of RAM should be plenty.

The 256 bytes of 16-bit scratchpad RAM (the only 16-bit RAM in the system) are all yours as long as you turn off interrupts with a "LIMI 0" instruction. Otherwise the system's ISR is going to run every VSYNC and it uses specific locations in the scratchpad.

 

That said, I could add a function to TMS9900.cxx to abract out all memory hits so it keeps the memory usage as it is now and then override it in TI99.cxx so that it can be configured to use VDP memory or fall back to the TMS9900.cxx's memory function.

Could it please be configured (or defaulted would be nice) to expect and use the 32K RAM expansion instead of VDP RAM (VRAM)? We already have languages (BASIC and Extended BASIC) that live and run in the VRAM and it prevents serious software development since it locks down what you can do with the VDP. If you store and run code and data in the VRAM, you can't arbitrarily use all 16K or there will be no usable video output from the machine. Since the VRAM was the only RAM in the machine besides the 256 bytes of scratchpad, the VRAM is used and abused by many other parts of the system as well, i.e. disk buffers, I/O buffers, etc.

 

The 32K RAM expansion (which is supported in all the emulators and most people have on their real systems) is free and clear.

 

For the 99/4A, my opinions would be:

 

1. Turn off interrupts so you can use the 256 bytes of 16-bit scratchpad RAM as necessary.

2. Put the CPU's workspace in the 16-bit scratchpad RAM (at 0x8300, and you really don't want the workspace in 8-bit RAM)

3. Put any stack space after the workspace in scratchpad RAM

4. Use the 32K RAM for volatile code and data storage

5. Use the 8K cartridge space for non-volatile code and data

[mikeakohn]

Welcome to the forum, mikeakohn.

 

Keeping it generic is probably good, but how do you specify which parts of a memory map are suitable RAM/ROM for code and data? The tool can't blindly assume that all memory is a chunk of RAM, so at that point it seems you have to introduce machine-specific attributes, no?

 

 

The 256 bytes of 16-bit scratchpad RAM (the only 16-bit RAM in the system) are all yours as long as you turn off interrupts with a "LIMI 0" instruction. Otherwise the system's ISR is going to run every VSYNC and it uses specific locations in the scratchpad.

 

 

Could it please be configured (or defaulted would be nice) to expect and use the 32K RAM expansion instead of VDP RAM (VRAM)? We already have languages (BASIC and Extended BASIC) that live and run in the VRAM and it prevents serious software development since it locks down what you can do with the VDP. If you store and run code and data in the VRAM, you can't arbitrarily use all 16K or there will be no usable video output from the machine. Since the VRAM was the only RAM in the machine besides the 256 bytes of scratchpad, the VRAM is used and abused by many other parts of the system as well, i.e. disk buffers, I/O buffers, etc.

 

The 32K RAM expansion (which is supported in all the emulators and most people have on their real systems) is free and clear.

 

For the 99/4A, my opinions would be:

 

1. Turn off interrupts so you can use the 256 bytes of 16-bit scratchpad RAM as necessary.

2. Put the CPU's workspace in the 16-bit scratchpad RAM (at 0x8300, and you really don't want the workspace in 8-bit RAM)

3. Put any stack space after the workspace in scratchpad RAM

4. Use the 32K RAM for volatile code and data storage

5. Use the 8K cartridge space for non-volatile code and data

 

This is interesting. I never disabled the interrupts so probably there would probably eventually be glitches. Speaking of interrupts, the Java Grinder API has support for a Timer listener module. I was tempted to look into how to do that on the TI99 so the music and such could be played at proper intervals, but never got around to it. That might be useful.

 

The function that sets up where memory is.. actually, it's a little bit wrong the way it's written, but the first function is in TI99::open() (one of the first functions that gets called when generated code). It outputs the following lines:

 

fprintf(out, ".include \"ti99.inc\"\n\n");

fprintf(out, "ram_start equ RAM\n");

fprintf(out, "heap_ptr equ ram_start\n");

 

And then later in TMS9900::init_heap()

 

fprintf(out, " ;; Set up heap and static initializers\n");

fprintf(out, " li r10, ram_start+%d\n", (field_count * 2) + 2);

fprintf(out, " li r0, ram_start+%d\n", 256 - (16 * 2));

fprintf(out, " mov r0, @heap_ptr\n");

 

So basically ram_start would have to be changed to point to that 32k chunk of memory and heap_ptr would just need to put to the address of the 32k chunk of memory + 32k.

 

It should just work.

[matthew180]

The console ISR is very inefficient, but it can be left enabled to use the console's sound list player routine. You will have to tread very carefully in the scratchpad RAM though. There is also a user hook in the console ISR that you could use to get a call-back each time the ISR runs, i.e. once per VDP frame (60Hz/50Hz depending on VDP.)

 

Note that the 32K RAM expansion is not consecutive, as Willsy pointed out previously:

 

8K from 0x2000 to 0x3FFF

24K from 0xA000 to 0xFFFF

 

Supporting a CPU is different than supporting a system. It seems to me that to make this really useful to people (which may not be your goal), you need to have a system configuration file of some sort that defines the usable RAM/ROM areas, special addresses, etc. Something like MAME comes to mind.

[+acadiel]

Very impressed!

 

+1 on Ksarul's comment to give him the cart board we designed... imagine what could be done to interface to the stuff we put in the AVR on the Ubergrom board as well.

 

Mike - we have a few cart boards the community (kinda started with me doing 16K, 64K, and 128K versions).

 

We've made several different ones, but here's the low-down:

http://atariage.com/forums/topic/233535-quick-tutorial-on-cartridge-pcbs-needed/?p=3148071

 

The Red boards will give you 512K of bank switched ROM goodness. The Yellow ones, 2048M (but need a programmer that only a few of us have because of the pin count on the EEPROM.)

 

The Blue UberGROM boards have an Atmega 1284P which has a lot of awesome functionality as well as a 512K ROM.

http://atariage.com/forums/topic/235719-configuring-the-ubergrom/

 

I'm sure the manual Ksarul, myself, and Tursi were working on for the UberGROM is around here somewhere... did we ever release that, guys?