lkesteloot / alice Goto Github PK

Launch only demos or system utilities (like shutdown)

Modify libgl/hardware_rasterizer.c to fill memory but then not synchronize with the FPGA.
Determine frame rates with the different demos.
Calculate approximate lit triangles per second from bounce and logo
Calculate approximate unlit triangles per second from jello and insect

Copy hps2fpga_test1/lcd_backlight.cpp, remove the loop, set the brightness from a command-line parameter. Depends on #33

In double-buffered command mode, PRINT_FRAME_RATE should split out and print the time spent in memcpy().

In single-buffered command mode it should print the time spent between H2F_DATA_READY and ~F2H_BUSY.

• Edit hardware_rasterizer to save off a command stream
• Save logo command stream (may change timing)
• Remove ENDs from stream (except last one)
• Add commands to U-Boot "bootcmd" to play back stream on boot.
  • Load stream into memory
  • set GPO to kick off GPU

Depends on #19 .

The image occasionally glitches, especially when the CPU is using a lot of memory bandwidth. Perhaps the scanout memory controller port can be given a higher priority than the other ports.

If Home works, then we can design/implement the entire UI flow.

• Get the right size drill bit
• Drill button hole
• Solder jumper wires to button
• Install button
• Install jumper wires - FPGA GPIO?
• FPGA reassign button to GPIOs

Port arena networking code - see if Brad has relevant changes in his Ubuntu VM

The big unknown here is how to do the reciprocal. Find Verilog reciprocal algorithms. Failing that, do it on the CPU and pass it in.

It's most apparent in buttonfly's stroked fonts. fpgasim and reference rasterizers both show issues, so I think it's how lines are converted to polygons in libgl.

In particular, look at the o's in logo and jello.

To get this right, there may be a special mode for rdr2i that connects adjacent lines, or perhaps libgl just isn't handling wide lines correctly. The OpenGL Specification may be our only real reference here because the IrisGL Programming Guides don't get into the details of rasterization.

This is the reference rasterizer with fractional vertex coordinates:

This is the reference rasterizer with rounded-nearest vertex coordinates:

This is fpgasim:

The new read/write FIFO pipeline takes four clocks per two pixels. We should be able to pipeline it down to one clock for two pixels.

M_PI seems to be defined in math.h, which is included by hardware_events.c, but it still gives this error:

../libgl/hardware_events.c:108:38: error: ‘M_PI’ undeclared (first use in this function)
      value = theta_x_smoothed / (2 * M_PI) * 3600;

Note that hardware_events.c is included in logo and compiles fine there. Removing the flag -std=c99 from the Arena Makefile results in successful compilation. I didn't check that change in because I didn't know why it was there.

This is huge, because naively I'd do a Z-buffer pixel read each time I needed it, but the latency there is huge. Maybe initially do it that way. But then I either need to pre-fetch each row of the bounding box, which is wasteful since at least half of those (on average) won't be necessary, or do something even more complex. And remember that we also have to write the updated Z values back. Perhaps add another port to the memory controller so that we can do that simultaneously with writing color.

When I display the color_borders.png file, I sometimes (?) see a blue pixel in the top-left corner, with everything shifted over one. Check the semantics of the FIFO to discover where that blue pixel comes from, and perhaps do an extra read from the FIFO after flushing it.

Depends on #33

Need to recompile uboot so that fpga2sdram_handoff=0x00000333 or put that by hand in the bootcmd variable

• Doublebuffer the protocol stream
• Increase GPU clocks
• Increase width of GPU memory writes
• Skip more pixels when outside triangle
• Batch together multiple triangles into one DRAW
• -ffast-math
• Profile - where are hotspots? Will C++ optimization help any further?
• Lighting optimizations
• Matrix optimizations
• Break up long thin diagonal triangles
• Reduce per-triangle rasterization overhead (issue #49)

Figure out which buffer is back and put the image there. Then enqueue and start a SWAP and END.
Depends on #33

All pixels for odd values of X on the screen have the color of the pixel at X - 1. This is because I do 64-bit writes to memory and only compute "inside triangle" for the even pixel. Do two simultaneous "inside triangle" computation and use the write mask to set the two pixels independently.

I think right now PUTSYS is actually not storing all of the CBIOS because it's only storing the first 53 sectors, and I don't think that saves all memory from 0xE400 to 0xFFFF. This worked in my Alice 2 emulator effort because I loaded the CBIOS directly into memory with debugger commands. But only the CCP is overlaid when loading an executable at 0x100 and thus needs to be reloaded during WBOOT, so loading the CCP from disk worked fine.

PUTSYS should store all of CP/M in track 0, sectors 2-N, and track1, sectors 1-N. If CCP starts at 0xE400, then that's 56 sectors, so probably all of CCP+BDOS+CBIOS can be stored in track 0. If desired, we can do that and then change the disk scheme to reserve only the first track. (Right now track 0 and 1 are reserved.)

Also need to change WBOOTE entry point (WBOOT subroutine) to load all those sectors back in.

Split shutdown into two parts

• "Shutting Down" spinner launched from Buttonfly
• "Bye! (Okay to turn off)" screen launched at end of shutdown sequence
• "okay to turn off" should occur after most things, right now occurs after root remount ro

The division hardware generates some warnings. We currently have a 4-stage pipeline. Try increasing that to 5 or 6. (The hardware itself seems to work fine.)

I might have been misunderstanding the latency of FIFO.empty. Check it throughout.

Currently we wait for each read to return before initiating the next read. Pipeline the three reads.

After adding -O2, a number of warnings have popped up. Go either fix them or squelch them with -Wno.

• Turn accelerometer data to tilt angles
• Establish squelch implementation
• Port demos to tilt
  • insect: insect walks in direction of tilt
  • logo: tilt of logo (optional)
  • bounce: tilt of scene
  • jello: scene continuously rotates in direction of tilt
  • buttonfly: tilt of buttons (optional)
  • arena: direction and speed of robot

Result of each demo to be assessed - if tilt is unreliable or unstable for too many demos, try gyro board, and then fall back to joystick if neither can be made stable.

Esp fpga2sdram_handoff=0x00000333.
Instructions should go in Alice4 document
Brad needs to know how to generate a new loader sequence so he can try routing I2C through GPIO

The fpgasim code computes a bias for each edge, in order to guarantee that pixels aren't ever drawn twice. We don't do that in the FPGA code. See whether we need to, then add it. (It's pretty simple I think.)

The protocol program draws a single large RGB triangle, and I sometimes see strange visual artifacts, like a dark red line near the red vertex. It's most visible when the line is near-vertical.

This should bring us comfortably under the PowerBoost 1000C charge limit and allow us to run on battery if desired.

Is this a scanout problem related to or the same as #35? Or is this a new issue with rendering pixels past the end of the triangle so that values are extrapolated and wrap around?

When a demo program quits and returns to buttonfly, buttonfly immediately fills the command buffer with triangles. The FPGA might still be rasterizing. Pause at the top of the loop if the FPGA is busy.

• Establish reliable WiFi adapter part
• Configure wpa_supplicant to start on boot
• Configure DHCP to start on boot

The FPGA can clear both the color and Z buffer at the same time, so add a CZCLEAR command that takes both a clear color and Z value. We may have to port the demos to use czclear() if they don't already.

We can then keepCLEAR and ZCLEAR, or remove them and add two bits to CZCLEAR to specify which to do, or port all demos to czclear() and not support clear() and zclear().

• Implement pattern in rasterizer
• Couple protocol to hardware (protocol may be changed) - protocol.cpp test?
• Integrate command into software
  • hardware_rasterizer.cpp
  • parse_gpu_protocol

hardware_events.c is probably spending a significant time each frame reading touch events. Investigate speeding up readback of events (I2C clock?) or reducing the sampling rate in the controller.

Some GPIO outputs are combinatorial. Latch them all.

Right now there's the potential for drift between the gpu code in hardware_rasterizer.c and the other files.

All code interacting with the GPU should probably be in one C file.

Or whatever the Alice 3 clock speed is. Maybe make it configurable with a command-line option.

When brightness is low, the LCD in it's current orientation looks better when tilted "forward" (when the ribbon cable is at the "bottom") as if the LCD was a laptop screen which is closer to parallel to the user's body. It may be a good idea to rotate the LCD 180 degrees.

See #32.

The software work for this is probably pretty simple:

• Rotate output in libgl for rasterization, or rotate in FPGA rasterization, or rotate in FPGA scanout.
• Rotate tilt/accelerometer
• Rotate touchscreen

This has bunches of implications for the board design, but it may be possible to configure the LCD, DE0, and DABO so that the mounting points in the enclosure are just rotated 180 degrees and otherwise the enclosure is the same.

In anticipation of short-press on Home button issuing ESC.
Alternatively have a new device called HOME_BUTTON or something.
Make sure that ESC/HOME_BUTTON does not quit buttonfly

The fpgasim code re-orients triangles to be counter-clockwise. This lets it do only one set of computations for in/out triangle. I'm not sure if this is necessary.

The 470 and 240 Ohm resistors for the red 2-bit DAC are reversed in the KiCAD schematic for the SMD board.

After enqueing SWAP and triggering the GPU, wait on a change in F2H_RASTERIZER_FRONTBUFFER; this is the time spent rasterizing the previous frame.

Put a multimeter in current mode inline with power on DC side. Record power use in logo in the Alice 4 doc.

Set Z clear to 0xFFFFFFFF

Remove machine specific code as a bonus