karri

Has anyone measured how the ComLynx parity goes?

As I understand it the Lynx can send SPACE and MARK correctly.

Sending EVEN or ODD parity includes the parity bit itself in the calculation.

If the data byte is 0x00 then the ODD parity should be a 0. Including the ODD zero to the calculation makes no difference and the result is correct.

If the data byte is 0x01 then the ODD parity should be a 1. Because of the Lynx error the parity becomes 0 again.

My theory is that the Lynx will always produce a parity of SPACE when you chose ODD and a MARK when you choose EVEN.

If this is the case then emulating Lynx parity with ordinary equipment is trivial. Am I correct?

--
Karri

I found my old copy of HeroQuest for the Amiga yesterday and played it on my Ubuntu laptop for a while.

The original game looks very nice.

 HeroQuest.png   243.61K   17 downloads

I wonder if it could look great on a Lynx also? A clever graphics artist might be able to draw just a triangle sprite that could be flipped to make squares. Like this:

 drawing.png   48.48K   24 downloads  tiles.png   63.14K   19 downloads

What do you think? Would this work or is it too little variation to create good eye candy?

The important thing is to make the characters and monsters stand out to make this playable. And of course you have to be able to see the squares clearly in order to plan your moves.

The size of the triangle would be 16 pixels wide and 18 pixels high (in the orientation shown here).
--
Karri

Hi,

The Linux community is currently going crazy about Raspberry Pi - credit card size cheap stand-alone computer.

I am trying to get my hands on one as well. It might be possible to program one GPIO pin to emulate ComLynx exactly. This would allow Raspberry Pi to ComLynx with real Lynx hardware.

The price of the computer is $35 (USD) and it has Ethernet, USB's, HDMI output. And it runs from a SD-card.

It would be quite simple to create a small add-on card with a cart socket and a ComLynx plug to produce a large screen non-portable Lynx.

--
Karri

When I was glancing through Ninjabbas code I again got reminded that the cc65 toolchain lacks sprpck.

Perhaps now it the time to do something about it.

sprpck itself has more options than I need.

I usually do all my graphics on a single bmp image. To cut out a sprite I use
-oxxxyyy : offset in data (e.g. -o010200 )
-s160102 : sprite width and height (input-size is default)

Sometimes I need tiles

-rxxxyyy : split picture into yyy * xxx tiles

For sprites the action point is important. The action point is the point in a sprite that stays in place when you scale the sprite.

-axxxyyy : action point (e.g. -a200020)

The rest like palette to use and how many bits to have is something that can be better done with the image creating tools.

The input would only be png bitmaps. In that format we can define binary images with transparency like here:

 binary.png   688bytes   20 downloads

You can also define 4, 8 or 16 colors in an indexed png file. Here is 4 colors:

 fourcolors.png   507bytes   24 downloads

So what do you think? would this be a good replacement for sprpck in the cc65 toolchain?

Usage would be:

sp65 -t lynx [options] filename.png

This would produce an asm source file

filename.s:
.export _filename or _filename000000 in case of tiled conversion
.export _filename_pal in a format that can be imported directly to Susie
.export _filename_nrcolors 2, 4, 8 or 16


Comments?
--
Karri