This is such an amazing project. Simple. Clean board. Easy to build if you got the solder skills. I would hope for better screen resolution but you aren’t doing this for that.
I have a comment on HN about that. Fact is the Propeller chip can do quite a bit better than the 160 pixels included with the CODY.
On a TV, 720x440 NTSC is not hard. 640x400, 420 whatever here, is a better fit, as that rides in the safe area for NTSC.
There is a lot of video code, some written by me, for the P1 that can run on that configuration. The project author is using the reference Parallax video circuit.
This means you can get S-video, or composite. And you can get about 60 colors without special tricks, including 5 grey shades.
There is not enough RAM on the P1 to do full on one byte per pixel, or even 16 color 4 bits per pixel at those resolutions.
A 640x200 screen is basically 64k at 4 bits per pixel. 320x200 is 32K, etc...
So, one has to use tiles and sprites to make those resolutions and color depths useful. Drivers exist that do just that.
That said, 320x200 with 8x8 tiles, 256 of those defined in a table, plus sprites can be very robust under 16Kbytes of RAM.
Offering C-64 style color text, which could include the text mode shown on the CODY, given the C64 multi-color mode, is only... 1k for the text memory, 2k for the 256 possible 8 byte character definitions, and another 1K for a color / attribute map.
Then one has to choose! Do it C64 style, where the color map begins at a different address from the screen memory where the text is, or do it IBM style, where both start at the same address, and the screen memory is combined with the color map.
On the Propeller, IBM style is easier! Grab 16 bits per character, and 8 of those index into the character map, and the other 8 are used as color / attribute data directly. But, that means each character is basically 16 bits too.
Done the C64 way, the Propeller has to do two fetches per character instead of one, which limits some things like ultimate high resolution and number of sprites to be drawn, etc... but it makes for easy implementation of "Print commands" in that text can be dumped to the screen memory in sequential bytes, just as it's seen.
I'm in the weeds now!!
As I back out, yes!! The board is really clean, and there just are not a lot of components. It's NICE WORK and I sort of want to build one.
(I would modify the video to be 320x200 though, and keep the 40x25 screen, but just have nicer characters.)
On a TV, 720x440 NTSC is not hard. 640x400, 420 whatever here, is a better fit, as that rides in the safe area for NTSC.
There is a lot of video code, some written by me, for the P1 that can run on that configuration. The project author is using the reference Parallax video circuit.
This means you can get S-video, or composite. And you can get about 60 colors without special tricks, including 5 grey shades.
There is not enough RAM on the P1 to do full on one byte per pixel, or even 16 color 4 bits per pixel at those resolutions.
A 640x200 screen is basically 64k at 4 bits per pixel. 320x200 is 32K, etc...
So, one has to use tiles and sprites to make those resolutions and color depths useful. Drivers exist that do just that.
That said, 320x200 with 8x8 tiles, 256 of those defined in a table, plus sprites can be very robust under 16Kbytes of RAM.
Offering C-64 style color text, which could include the text mode shown on the CODY, given the C64 multi-color mode, is only... 1k for the text memory, 2k for the 256 possible 8 byte character definitions, and another 1K for a color / attribute map.
Then one has to choose! Do it C64 style, where the color map begins at a different address from the screen memory where the text is, or do it IBM style, where both start at the same address, and the screen memory is combined with the color map.
On the Propeller, IBM style is easier! Grab 16 bits per character, and 8 of those index into the character map, and the other 8 are used as color / attribute data directly. But, that means each character is basically 16 bits too.
Done the C64 way, the Propeller has to do two fetches per character instead of one, which limits some things like ultimate high resolution and number of sprites to be drawn, etc... but it makes for easy implementation of "Print commands" in that text can be dumped to the screen memory in sequential bytes, just as it's seen.
I'm in the weeds now!!
As I back out, yes!! The board is really clean, and there just are not a lot of components. It's NICE WORK and I sort of want to build one.
(I would modify the video to be 320x200 though, and keep the 40x25 screen, but just have nicer characters.)