Review of C64 by Jeremy

* [[Assembly vs BASIC]] (Ian)
* [[Hidden Code]] (John)
* [[RUN]] (Casey)



== OVERVIEW AND RECOMMENDATIONS ==

The sections of the C64 chapter are all relevant, work as a group, and actually fit together quite logically with natural transitions -- they do not need to be broken down into complex pieces to form a progression. I recommend that the current chapter draft be organized in the following sequence (note -- opposite of the current listing on the wiki):

# RUN (Casey)
# Hidden Code (John)
# Assembly vs. BASIC (Ian)

RUN is a perfect introduction -- it presents a new encounter with the machine as a compelling scenario. Hidden Code follows by expanding on what all of the behaviors of execution tell us about the environment. This section should be a bit more fastidious about delineating (where possible) what aspects of those hidden codes are most general to BASIC, and which are unusually specific to the C64 -- this might also be a good place to mention what other BASIC environments were common peers of the C64. Assembly vs. BASIC does not transition cleanly from the previous section, but it follows logically --

* we introduced the c64 running a BASIC program
* then we discussed everything we get for free in the higher level BASIC language
* so next we move to assembly, which helps illustrate what it would mean to *not* get those things for free.

For this reason it might make sense to overlap the end of Hidden Code with the Beginning of Assembly vs. BASIC, introducing the distinction between high and low programming at some point in the middle of Hidden Code -- for example, with Truncation. However, the current order works.

If I were to chance working headings changed to something a bit more descriptive (at least for now), perhaps:

# RUN: BASIC on the C64 (Casey)
# Hidden Code: the C64 BASIC environment (John)
# From BASIC to C64 Assembly (Ian)

...notice that, although each section contains C64 machine-specific details (Ian's especially), the big through-line here is BASIC. There is currently another draft BASIC chapter (BASIC in Print and in Memory (Nick) and Typography and BASIC (Mark S)). I think the open question is whether to combine all these  into one "BASIC on the C64" superchapter or attempt to separate a focus on c64-specific details as such from BASIC environments across (similar) platforms. Our current chapter order on the wiki lists BASIC before C64. If this is the case, part or most of RUN might end up getting moved to the front of BASIC.


== INDIVIDUAL DRAFTS ==

=== RUN (Casey) ===

This section is a great hook for the whole chapter. I suggest that the first few sentences be split off as the introduction, and that a fourth section (or subsection) be inserted. After the line: "Imagine [...] The screen erupts into motion as lines flow onto the screen." I'd suggest inserting a brief section on the C64 as other than a BASIC / assemply platform: as a completely described spectacle, as an assemblage of certain physical components, as a consumer product available for certain prices in certain markets to certain types of consumers, etc. This section might be a paragraph or it might balloon into something quite large, but no matter how large it gets, it can end back at the imagined situation "...when you type RUN. As each row fills with symbols" etc.

In general, I'd say that if this is going to be a chapter primarily about the C64, the biggest missing piece is socio/economic/historical context: what is / was the C64? I'm not saying it is Casey's job to write this -- just that this is where it might go, right at the beginning and right after Casey's evocation of the form factor and screen.

=== Hidden Code (John) ===

John explicitly suggests that a discussion of character-set / graphics should be prefixed to this section -- I agree, my own section on this should probably be removed from the Maze chapter and moved before this, and mentioned in reference during the Maze chapter. However, given that I wrote that section, I'd like other authors to confirm that they think it is the right fit.

The idea of hidden code here is extremely compelling, but should be framed carefully, so as not to imply that the BASIC interpreter is actually inserting lines of BASIC code invisibly as a pre-step to interpreting. That should be clear of course from the fact that the "hidden code" is written as pseudocode -- but this might also be a good place to introduce the concept of pseudocode itself, and spell out what the pseudocode represents (...they reference aspects of the BASIC envorinment are all machine code with no intermediate representation, right?). The distinction may seem a bit nitpicky, because the passage reads clearly without it, but it may set things up for Ians section.

In my opinion this section will be a highly useful reference point for many of the variations when they are elaborated later in the book -- for example, my own draft text on a LOGO variation includes a less exhaustive discussion of these hidden elements of the BASIC environment that need to be re-implemented, and I think that will be common for many implementations (Ian's assembly being one). I'd think through the logical order of the sections carefully, and provide a short list at the top before going into them. 

*   Truncation
*   Colors
*   Screen Grid
*   Cursor
*   Scrolling

Tempting to subtitle this section something cute like "The basics of BASIC"....

=== Assembly vs Basic (Ian) ===

The transition between this section and the last needs to be made explicit, but this section starts with great context. Whether the low/high discussion is moved up or left here, I think it might be important to make clear that "low/high level" languages are relative -- i.e. BASIC is quite high compared to assembly and machine code, but it is still quite 'low' in comparison to many languages (in fact, today some consider C low).

The progression into assembly code is helpful, clear and reads well. Given that it is a logical progression to a lower language (from BASIC to assembly) it might make more sense to title the section "From BASIC to Assembly" rather than Assembly vs Basic.

I got a bit hung-up on "no canonical assembly program exists." Given that assembly is still an intermediate representation, is this idea distinct from "no canonical machine code exists"? Does it imply that an assembly implementation can be canonical for abstracted BASIC, but BASIC cannot itself be canonical? The general implication of abstraction and canonicity (that various BASIC interpreters / compilers / environments could render the same BASIC as different machine code sequences) seems to be the important point to be expanded here before moving from writing BASIC to hand-writing assembly -- and I'm curious, because I don't know the details. I wonder whether the difference between a compiler and an interpreter is also important to discuss here.

"The assembly programmer would have to implement such a scrolling behavior by hand" -- this meshes perfectly with the earlier Hidden Code section, and we can see how these given affordances (like assumptions about screen geometry and cursor behavior) are part of what we lose when we go to a lower level of abstraction. HOWEVER, I'd note that we *also* lose these assumptions, not just when we go "down" to assembly, but also when we go to sideways or up to ACSLogo or Processing etc. etc. There the assumptions don't simply disappear, they are replaced by different assumptions. The point I'm trying to make might be appropriate for this section as a way of complicating the low-high situation, or it might instead be appropriate to discussion during later variant discussions which point back to the assembly passage.

Misc relevant pop cultural reference: "Apple yanks Commodore 64 emulator for BASIC interpreter easter egg"
http://www.downloadsquad.com/2009/09/08/apple-yanks-commodore-64-emulator-for-basic-interpreter-easter-e/