Java mobile games to Atari lynx games (Theory)

[42bs]

6 hours ago, enthusi said:

Not saying c is bad. I use it at work alot. Neither is cc65 in some ways but one should know what is happening. Here is a small c code, followed by plain cc65 output and a small manual routine. For the given task the C version is certainly fast enough still but you see at once what the costs of generic code are.

https://pastebin.com/UN6UQaVY

As I said, 16bit oriented. Try using count as char not int.
Also, post increment/decrement often produces bad code.

And to be fair, one would use memset() for this job.
 

But as I said, you have to write compiler friendly code for optimal performance.

[42bs]

34 minutes ago, karri said:

I must agree that to date the best approach for single routines is structural asm. Like BLL.

 

The problem is that there is a lot of asm primitives that you need to learn.

 

My favourite coding language would be something like Occam. Just 14 mnemonics, indents to define the blocks, IRQ's are part of the control syntax, parallell execution if the CPU supports it. And very compact code.

ALT
    msg?VBL
         PAR
             SwapBuffers
             IncrementClock
             AdvanceMusic
    msg?Timer6
        SEQ
             StreamPCM

 

But how would you code the SwapBuffers function?
 

One draw-back of the structural macros in BLL is that I have not yet found a proper way of variable handling.

 

[enthusi]

57 minutes ago, 42bs said:

But as I said, you have to write compiler friendly code for optimal performance.

Yes, I agree 100% there. That's is basically all I had to say You 'should' have some idea of what you are doing and what cc65 will do with it (which is not the actual idea of C, at least not for modern plattforms).

 

[+karri]

1 hour ago, 42bs said:

But how would you code the SwapBuffers function?
 

One draw-back of the structural macros in BLL is that I have not yet found a proper way of variable handling.

 

I actually did a 3D helicopter simulator using a farm of transputers. Basically you split the screen to a number of areas (eg. 100 by 100 pixel squares) that you pipe to the drawing processes. When the pipeline has created the graphics you insert the areas to the screen buffer. The whole idea of Occam was about creating lots of independent server processes and pass the data around the processes using DMA instead of using mutex locks and trying to coordinate several threads access to a single resource.

 

The Transputer had the scheduler/dispatcher in silicon and it changed tasks every 64 us. So everything run in parallell all the time. It was a stack machine with virtually no registers.

 

But you really cannot use ordinary "programmers" for coding the stuff. The best guy is someone studying physics. Because they can think in real world events. Programmers are so limited to think in a program counter. Example: a car radio. You can tune the radio and change volume using two hands. So we have two parallell processes that run independently from each other. The sound will start from the tuner CPU and pass through the volume CPU.

 

The beauty was that when you needed more power you just added more transputers. Every chip contained the RAM, the CPU and 4 or 6 high speed pipes. So the topology the memory and the processing power expanded in a linear way. Usually we used fault tolerant meshes. I was really sad when the technology failed due to good marketing by Intel and Windows. Computing science took a huge step backwards when Occam died imho. The current Google Go seems to use the same concept. It is the closest thing to Occam today.

 

So perhaps we need to implement Go for the Lynx

 

[42bs]

I had an ATW once, but never got it to run and finally sold it.
Today Xmos looks much like a Transputer of the old days.

And maybe Erlang could be a successor of Occam, at least from what I read so far.

As for multi-core: Many developers learned (and will learn) it the hard way, that all of a sudden, parallel thread  _really_ run in parallel ?

 

[+karri]

It appears that Xmos is founded by David May - the same guy who invented the Transputer. The Transputer was actually defined in Occam. It is a silicon implementation of the Occam algorithm describing a Transputer.

 

David May is the only genius I have met in person in my lifetime. And I am very happy that I had a chance to talk with him.

 

[42bs]

*lol* May's Law: "Software efficiency halves every 18 months, compensating Moore's Law. "

[Europatari]

i am going to ignore this topic, because i am sick of all these non thematically fitting replies.

Make your thing, i will never go back to this place again

Goodbye!

[Turbo Laser Lynx]

On 9/26/2019 at 9:24 PM, enthusi said:

To truly keep a system alive and going you (also) need a certain amount of people that are willing to dig deep and code bare metal in the long run, in my experience.

That is very true! At least I'm very thankful for all the fun I've had creating for the Lynx that would never have been possible without groundbreaking work from many others and help from everyone on this forum.

 

@Europatari There must be some misunderstanding here, I don't think anyone meant any harm here. Personally I thought all of the out of the box brainstorming was really a lot of fun to read and would've hoped that it would've continued.

 

 

[+karri]

It is also not obvious what kind of customisation is practical as the Lynx lacks a keyboard.

 

My personal view is that some kind of Game designer running on a PC could cross-compile the result for the Lynx. "Always winter, never Christmas" was designed on Google Blockly. Blockly created xml to describe the logic of the game. From xml I created C-code that could then be compiled to a lnx file.

 

A second customisation is something that does not exist yet. It would be a PC on which you create an andventure. Like this editor written by Gerwin Broers.

 

Once the adventure is written you could then share it over ComLynx to the players. The players would have isometric views and take turns.

 

It is possible to create a Lynx cart with 64k eeprom for a decent price. You could create a library with games for typical Hero Quest characters (Barbarian, Dwarf, Elf, Wizard). The eeprom could hold the quest and the bg music. Plus any extra graphics you may need like villains or treasure.

The game master could participate as one of the characters from the PC. Or the PC could just show the entire game field for the audience while the players only see their limited views.

[+bhall408]

5 hours ago, karri said:

Once the adventure is written you could then share it over ComLynx to the players. The players would have isometric views and take turns.

 

This somewhat reminds me of the Atari 8-bit game Dandy. The original version (the author's college thesis paper at MIT) had a mini-computer as the "server" / dungeon master, and it would serve up game maps to Atari 800 computers.

 

The author also had done Deep Blue C, which compiled Tiny-C down to p-code, which would then be executed/interpreted by a runtime on the 6502. That could be a decent way to get larger games onto the Lynx.