Are you teaching with the Picocomputer?

[rumbledethumps]

PJF on Discord is "teaching eight college students microprocessor application development using the RP6502."
Nichetronix on YouTube says, "I think I will teach this in one of the introductory Computer Engineering courses I teach."

I'd like to hear more about this. I designed the device for autodidacts, but knowing more about how folks use this in a classroom could help steer future documentation.

[patrick-flynn]

I taught the course last fall (August to December). It was the first offering, and a pilot - an elective "project course" for seniors (fourth-year students) in computer science and computer engineering. Students worked with me to develop two project ideas - the first was a text-mode game, and the second was a graphical game. My lectures covered some history of the microprocessor era, some elements of gae design principles (very practical) with examples, and some quick exposure to the Pico platform and the several APIs, with los of example code showing how to do various things. After those general lectures were done (about mid-semester), instruction was individualized - mandatory weekly meetings and office hours as needed to help students climb the learning curve, check on progress, and so on - but no group lectures.

I'm teaching the course again (to a slightly larger group) this coming fall, using a different platform which has an emulator available. The class design will change a lot - I'll have lectures for the entire semester so i can cover topics in more depth and enlarge the scope a bit. There will be several programming assignments intended to build familiarity with the 65C02 and the platform (along with the quirks of small-machine C and the C/assembly interface), and just one large project due at the end of the semester.

With regards to specific things that can be done with documentation to serve a student audience - my general feeling is that the documentation as it existed a year ago was just at the Nyquist rate for me. I could make sense of all of it after a very careful read, but the students were quite bewildered - they don't have enough of the terminology, and sometimes it's stacked intimidatingly ("what's a sprite? what's an affine transform? what does 'fix8.8' mean to specify the transform? why do I have to play tricks with the affine transform to rotate a sprite about its center rather than its corner?"). It's not necessarily @rumbledethumps 's job to make the documentation more accessible to students, it's the instructor's job to appreciate it and help the students understand, ideally via example. This involves some work - for example, the sprite API implementation made a ton more sense to me after I spent some time (a LOT of time) digging through Luke Wren's repo. I was VERY fortunate that I started developing samples and demos months in advance - because coding these things up cemented things in place conceptually for me so I could convey them to students. A huge thank-you to @rumbledethumps and Tony @vruumllc for the code they made available in the early days. I'm also glad I only soldered together my original five Picos before I decided to wise up and have the PCBWay populate the others so all I needed to do was snap in the ICs and Picos.

If I were to use the Pico again this fall, I would probably remove some of the flexibility, and require all projects to use a specific graphics mode and resolution. XRAM management and budgeting was probably one of the bigger technical challenges for students, and the availability of different settings was a source of confusion. XRAM budgeting was much more of a challenge than 6502 RAM budgeting!

More thoughts as they come up.

[patrick-flynn]

I spent a lot of time developing utilities for graphics conversion and sent them to the students, on the assumption that converting graphics formats was both (a) fun for me (I'm an image processing guy) and (b) out of scope for the students.

With that said, the students were fairly conservative with graphics - a lot of low-color schemes, standard colors using the provided macros, etc.

One of the eight students did serious work on sprite design, but used my utilities and the packtiles Python script to convert them to the in-memory sprite format.

At the other end of the complexity spectrum, I wrote a very specific Python script to take a PNG image taking the complete tile sheet from Bosconian (one of my favorite videogames from the 80s), chop it into tiles, resample the tiles to square power-of-2 pixels in x and y, convert the results to the tile memory format, and bundle that together with the XRAM VGA config structures also produced by the script. The whole kit and kaboodle of binary files was converted to assets at build time, so you got "instant graphics" as soon as you set the mode at run time. Cute.

XRAM budgeting gets more and more finicky as the number of assets increases, of course. One of the things I tried was motivated by some attempts to get a start at Marble Madness. It's a vertical scroller with a fairly tall playfield (taller than the screen). My vertical scrolling was implemented by a tight assembly loop to shift the rows that remained visible, followed by a direct read-to-xram from the image file for the new row to be displayed

Interestingly, the vertical scrolling work led me to a dead end. I asked myself "how about adding an xxmemcpy() function to the API?" - a direct copy of a block from one XRAM address to another. You can use that for vertical scrolling! If I remember correctly, there is already a memcpy in the Pico API. So I added the routine to the RIA firmware, and tested it, and verified that it worked (the XRAM was updated correctly), but saw no visual change when I used it to perform vertical scrolling - because I had forgotten the PIX signaling needed to update the VGA! At that point, I had no time to figure out how those were triggered.

[rumbledethumps]

Here's how you scroll: https://github.com/picocomputer/examples/blob/main/src/mode2.c#L34

For marble madness, you can keep the playfield entirely in xram and scroll around it. For example, render 320x240 of a 320x500 playfield. Put the scoreboard on another layer so it doesn't move. This eliminates the need for moving memory around. All you do is change y_pos. A 16x16 mode2 playfield can be quite large even in 64k.

In other words, the size of what's in xram doesn't have to match the canvas size. It goes the other way too. In an RPG you can have a small character portrait of 16 bit color that's much less than the resolution of the screen canvas.

The most complex apps so far only use a small fraction of the VGA capabilities.

[patrick-flynn]

Alas, my playfield was 83kb (290x577x4bpp). I didn't want to compromise the original art so I was stuck with the size on the sprite sheet I found.

[rumbledethumps]

The arcade version was Atari System 1 which could smooth scroll around a 64x64 playfield of 4bpp 8x8 tiles. So it's doable in mode 2, but you need the ROM data instead of a screenshot.

[netzerohero]

Reading this thread with interest... a couple of comments....

An emulator would be awesome.

Though it does not have the graphics of the pico-6502, the SYMON 6502 emulator may be of interest - for general 6502 work. Features include memory viewing, trace logs, breakpoints and single step, as well as emulation of the historic 6545 CRTC. The emulator includes the ability to boot rom images, including EhBasic also implemented on pico6502. Here is a link to a quick-start write-up: gotBASIC.com.

With regards to ... documentation ... - my general feeling is that the documentation as it existed a year ago was just at the Nyquist rate for me. [An experience person/instructor] could make sense of all of it after a very careful read, but the students were quite bewildered...
It's not necessarily @rumbledethumps 's job to make the documentation more accessible...

Agree with the comment on documentation - such technical documentation requires careful attention and takes time.

I have observed how the introduction-of- and encouragement-to-use- wikis have changed the way technical documentation is approached (i.e., developed and used) from (say) thirty years ago. In my day-job (in a related embedded HW / SW field) the use of wikis have enabled developers and user-community an avenue to contribute-to and continually-improve that needed documentation - evolving over many years resulting in a shared-knowledge repo providing technical details & tips.

Wikis haven't been "the silver bullet". They do take time; they aren't fully self-organizing - HW/SW-Leads work to encourage wiki-use by the developers - in order to take their great ideas, examples and use-cases, write-them-down and "put-them-to-paper" on the wiki...