more IO, graphical input

[tomhea]

The original idea (source):

Another cool project could be to add a "graphical interface" to it (perhaps a 320x240 memory address that gets converted to a monochromatic image). This could be used to support coding a Pong - and thinking long-term, maybe a real hardware (FPGA) that implements a flip-jump processor and can execute Pong on a TV :P - but that's.. a long project

I thought about supporting a screen output for some time, so your idea sounds awesome.
I think we can place the board blob as hex.vec 320*240 right after the initial op and IO (so staring at 4*w).
hex.vec is a consecutive list of hex - a variable the standard library supports, that holds 4 bits of information in it. we can use it for now as only 1/0, or support 4-bit colors.

To support that, we need to:

• add support for a SCREEN flag (and height-width fields) in the .fjm format (in a new version).
• find a nice python library that displays the screen
• write some stl functions to help us code there

To write the pong we need:

• add some option to wait ("sleep") for some amount of time
• add an option to get a random number (the ball should spawn in a different cell/direction each time)
• decide a way to input each keypress instead of waiting for a line of input (maybe add support for a running-flag, which will decide if the input should be given char by char, of line by line.
• have some time programming and ponging :)

I'll be happy to hear any ideas or notes that you have

[lestrozi]

I haven't thought this through, but I think I'd try do it something more similar to DOS screen modes ( https://cs.lmu.edu/~ray/notes/pcvideomodes/ ). This could even allow screen-mode changes in runtime (not for the first version, of course :) ) which could be set using ~4 bits starting at 4*w; then a region after them (or perhaps in the last addresses of the program) becomes the bitmap.

[tomhea]

OK thats cool!

Mode 12 seems to me as a good choice.
mode D us good if we want smaller resolution (performance-wise), and modes 4/5 or 11 for less color options.

I think that the runtime change is cool, yet unnecessary. I would support adding another flag in the .fjm file, that will specify the screen-version, or the resolution+color size. That way the interpreter wouldn't need to handle switching screens at runtime. Tell me if I missed something.

And I agree, we should standerize the screen bitmap starting address.

[lestrozi]

One thing we need to decide is if we should map a memory region to the screen.. Or provide a "interrupt/syscall". I began favoring the former, but now I think the latter would make it easier for FJ developers as well as for the compiler.

I thought about providing 2 interrupt/syscalls:
FillRect(x, y, w, h, color) -> None and GetPixel(x, y) -> color

Basically, you set the 5 values in 5 specific positions (eg starting at 5dw, and when you flip 4dw+0 it executes it); same for GetPixel, but then you flip 4dw+1 and get the result in 7dw or something like that

Thoughts?

[tomhea]

I really liked the simplicity of:

FillRect(x, y, w, h, color) -> None and GetPixel(x, y) -> color

I'm gonna address it in #154.