Consider NTSC output on I2S

[cnlohr]

Do you guys have room for a textbuffer? If so, I may be inclined to write something that can output that textbuffer to an NTSC connection on the I2S pin.

[mengstr]

A 80x25 textbuffer would most likely fit in the dram in the nosdk variant. Can the charmap be put in iram you think?

[cnlohr]

Using IRAM: You betcha!

Hmm... there's two ways you can go.

(1) graphic charmap (store line-of-text-at-a-time-by-buffer) and use compressed line text. (uses about 1kB for the text (includes extended charset))

(2) store only the text buffer, and no graphic buffer. Looking at the code a little more, looks like it'd be best to use 6px wide x 8px high chars. Which I just realize only uses 1kB!

A few questions:

(1) Would you want to use the extended charset?
(2) How much extra IRAM do you have?
(3) Do you want me to code it as a VT100 interface?
(4) Do you want to do NTSC broadcast? or NTSC composite cable?
(5) Is your I2S engine totally free? Keep in mind it operates on the RX pin :(

[mengstr]

1. Nah, I recon that the 96 characters from regular 7-bit ascii would be enough for a cp/m machine
2. will check a bit later, it's 2 am here now ;-)
3. that'd be nice if you already got the engine for vt100/102 decoding available. As far as I remember VT102 implements insert/delete character on a line which is really convenient to have.
4. I guess composite cable got much better image quality?
5. I'm not using the I2S at all. But if it's using the RX pin then it might be a showstopper unless I can go over to a softuart. Is the video-engine using any interrupts that would fsck up a softuart implementation?

[cnlohr]

It would use interrupts that would make a softuart untenable. I wonder if there is any other options for alternate mapping. Just looked, even if you use a PS/2 keyboard you can't bitbang it. May be able to use the SPI bus, or UART1 I'll look into it.