Out of curiosity

[sage]

10€ pieces, but half an hour work putting together (if you do several). It did this one for O(20) of them and, actually, i am not keen to do it again. Its such a waste of time.

[+karri]

10€ pieces, but half an hour work putting together (if you do several). It did this one for O(20) of them and, actually, i am not keen to do it again. Its such a waste of time.

 

Sage, now I lost the track. Do you refer to flashing an ARM CPU, using molded plastics or transferring the data to a cart over ComLynx?

[sage]

Sage, now I lost the track. Do you refer to flashing an ARM CPU, using molded plastics or transferring the data to a cart over ComLynx?

 

well the page flipped, i was replying to lxs quote of usb serial comlynx.

[AVoltoro]

All I can say is that that I have work cut out for me during Easter, both in terms of getting a Lynx and learning the programming language for it. I think I will make a basic game for it first before driving the insane train of hype that this has become. Maybe a 2d platformer or spaceship shooter just to get me warmed up. Com-lynx support possible. Nothing as advanced as this.

 

Despite this, however, I thought I could share what I want to do with this game idea from a gameplay perspective. I am thinking of a Legend of Zelda/ Final Fantasy type thing where the weather effects enemies, side-quests, etc. Different enemies have different elemental weaknesses and only appear in different weathers, and the same thing goes for side-quests. I am also toying with the idea of it affecting dungeons, but I want the game to be playable in all weathers, and not have parts of it blocked off because it isn't raining, snowing, etc.

 

Also I went to a game expo a few weeks back, and someone did something with the same concept (of having outside weather affect in game actions) only that game was for smart phones and used both an internet connection to a weather website and the phones internal GPS for the same results. Could this be easier or not?

[+karri]

Imho the point in having environment sensitive games is to map your local environment to match the game. If I turn off the lights and play in the dark it will be night in the game also. So I would go for a simple photocell and skip the real weather outside.

[+karri]

I just received an ARM prototyping board.

 

 

There was a few things that hit me.

 

There is a built-in temperature measuring device in the chip. So we can easily check the temperature of the cart.

 

As this is not a memory chip there is no restrictions in what the lines should do. This means that we could transfer programs and give commands by banging bytes to the address latch instead of trying to emulate real memory. Also the configuration can be programmed on the fly (type of eeprom, sram, dual banks).

 

The custom commands could also be used for reading the attached sensors. The question is what kind of sensors to include?

 

The easiest sensors would be sensors that fit on the cart without a need to see through plastic. Sound, position, acceleration, location, orientation, pressure, RF, magnetics.

[AVoltoro]

The thing is though this is measureing the tempreture of the cartridge, not the tempreture outside. This means that outside influence, such as the cartridge overheating, could affect it. Also, while I like the idea of a photocell in the crtridge, I feel it may become a bit to slimier to Boktai

[+karri]

I may try my hands on the 15€ cart. As it requires lower interface voltages I need some resistor packs and buffers. The program would be streamed through the ComLynx as a lnx-file.

 

The question is that how does the Lynx differentiate the boot when it is in programming mode or the normal gaming mode?

 

One cool solution would be to stick the cart in the fridge for a minute. If the temperature is below 0 it starts into programming mode and pushes a ComLynx reader software to the Lynx. Otherwise it gives the programmed game to it.

 

Obviously Lynx lovers in Lapland and Greenland won't like this cart.

Edited March 8, 2013 by karri

[Wookie]

Another possibility would be to aim for a 512k cart with no external components (except 3.6V power regulation, resistor pack for address lines and buffers for the data bus).

--

Karri

 

I have a design for lynx carts up to 128MB using just parallel flash memory and an i2c 8-bit shift register. IIRC, the Lynx natively has an 8 bit "segment" address and an 11-bit "offset" address giving it a 19-bit address space (512KB). So the 8-bit shift register acts as an additional upper 8 address lines giving the cart a 27-bit address space (128MB). I'll have to dig up my design, but I'm pretty sure I used the AUDIN line as the write/chip select for the 8-bit shift register. Then I used software to bit-bang i2c. The second to least significant address line of the 11-bit address counter can be used as the strobe line for the shift register and the least significant bit of the data bus as the data line for i2c. You then just toggle the LSB of what you're writing and write it twice causing the address counter to do one full transition from low to high and back to low.

 

Anyway, the extra 8 address lines makes a huge difference. You have 256 "banks" of 512KB. I even started coding a dragon warrior style RPG for the Lynx that was going to use as much of that space I could. Of course life intervened but I hope that some day I can pick it up again.

[Wookie]

Another possibility would be to use the PIP (parallel interface port) of PIC microcontrollers to directly memory map the PIC. Use the AUDIN as the chip select for the PIC and then you'll have a fully programmable controller for doing whatever you want. I sketched out on a napkin a schematic for a lynx cart that had a microSD slot, a memory mapped PIC and two 256KB flash chips. The idea was that I could send commands to the PIC via the memory mapping and have the PIC load 256KB blocks of data from the microSD card and storing it in one of the flash chips. This would offload all of the hard work to the PIC and basically give you infinite space on a lynx cart.

 

Then there's the absolutely insane idea of connecting the PIC to TI's CC3000 wifi chip

http://www.edn.com/electronics-products/other/4404215/Self-contained-Wi-Fi-module-simplifies-Internet-connectivity

 

The wifi chip is fully self contained and has an SPI interface. There are PIC's with both PIP's and SPI master ports. Digital distribution of lynx games anyone? The only problem is power. The lynx eats batteries. The CC3000 will exacerbate that considerably. So as long as you don't mind being plugged into the wall, it would work great.

[Wookie]

Correction, I've been calling it a PIP, but it is PSP (parallel slave port) that PIC microcontrollers have. It is an 8-bit, asynchronous, bi-directional port between the PIC and an external device such as the Atari Lynx.

 

The memory mapped PIC is a really good idea for a dev cart too. Using a serial connection from the PIC to a PC, you could build a fully integrated dev chain. Write a small server on the PC that responds to commands from the PIC. Program the PIC to respond to commands from the Lynx through the PSP. This would allow you to write your game to send live debug messages to the PC through the PIC. You could also write a small debug monitor that could halt your game and let you inspect registers and data from the PC. Probably the coolest feature to implement would be live editing of game data on the PC and sending a command to the PIC which causes the PIC to reload the asset from the PC and stores it in the cart flash. It drastically reduces turnaround time when tweaking game assets (including code).

 

If you used a dispatch table when calling functions in debug mode, you can actually rewrite functions on the fly. You change the code on the PC, compile it into binary, send the new code to the PIC with instructions on which function it replaces. The PIC stores the binary in the flash memory, and when the Lynx asks the PIC for events, the PIC tells the Lynx that function foo has been updated and it is at location X in the flash memory. The Lynx loads the function into RAM and then replaces the dispatch pointer for function foo in the dispatch table. So then the next time function foo is called, the address of function foo is loaded from the dispatch table which causes execution to jump to the new function.

 

Anyway, I'm rambling. There's a ton of cool stuff you can do with PIC microcontrollers with parallel slave ports.

[GadgetUK]

Wow, a tonne of interesting stuff in this thread now! I love wookies idea of 128Mb carts... Think what you could do with that lol!! FMV cutscenes, tonnes of samples etc.

 

Regards the arm proto, I would add a gyro (orientation) sensor, photo resistor, and a pin header that allows something else later (thinking rumble device lol).

[AVoltoro]

Just to let you know I am reading all of this. Not a hardware buff, but willing to back up any kickstarter project or other initiative to get to see the light of this. Also willing to invest in a prototype cart if that is helpful. And love to get programming on this.

What I also find very interesting to get to see is a ComLynx to PC cable. I am sure that for people in the know this is a no-brained, but I would love to program the connectivity of a Lynx game to PC, thereby opening up options for internet connectivity and other things. There was a lot of talk on uploading games to the Lynx through ComLunx, but I would really.like to get my hands on the required cable (USB preferred over Serial).

Thank you for you support, but I am still going through college, and sending it though Kickstarter, getting a team together (which will need to happen), adding and implementing stretch goals while trying to get at distinction to go to Uni will be far too difficult.

[AVoltoro]

well the page flipped, i was replying to lxs quote of usb serial comlynx.

Do you have any tutorials for the tools?

[sage]

Do you have any tutorials for the tools?

 

Which tools?