Whoever touches the code next, we have found an issue in the Day 1 example program, and we also discussed how it should be fixed to make it more clear:
Code:
<KermM> CurRow comes before CurCol
<KermM> Try making that currow, and take out the _homeup
<add> ok
<add> will try
<KermM> Thanks :)
<KermM> It's kind of bad form that the first program uses an optimization like that, though
<KermM> we should really make it ld a,0 \ ld (currow),a \ ld (curcol),a
<unknownln> yeah was thinking that
<KermM> Then later explain how to optimize that
<KermM> Premature optimization is a great way to be confusing.
In other words, the ld hl, 0 \ ld (pencol),a should be changed to the three lines I mentioned above. At the end of the lesson, or later in the tutorial, we should explain first the xor a optimization, and later the ld hl,0 \ ld (currow),hl optimization.

Edit: So people don't have to scroll through, here's the link:
https://bitbucket.org/tari/83pa28d
I made that change to the code, and added a note to at some point discuss the opportunities for optimization in that example.
I started reading over this on the chance there was anything more I could learn in them. While reading it I noticed a few things:

Day 5
Under the 1-D arrays section you give an array where element size is 1 byte, but in the code below it element_size gets defined as 3

Under 2-D arrays you say that b has row index, c has column index but you are multiplying c by row size and adding b. Unless I'm mistaken it should be b*row size + c in that case

Code:

    LD     A, C       ; Multiply by row size
    ADD    A, A
    ADD    A, A
    ADD    A, B       ; Add in row index


Day 9
When explaining how these can be used to pack you give an example of packing a date

Code:

PackYear:
    RLA                   ; Put bit 0 into carry
    RR     H              ; Transfer to H
    DJNZ   PackYear
; HL = %yyyyyyy? ????????
[...]

in each packing shouldn't RLA be RRA.

That's basically as far as I got reading in detail.
pyrotechnic wrote:
I started reading over this on the chance there was anything more I could learn in them. While reading it I noticed a few things:
Noticed the first one during the edit spree this weekend (below), but not the second. I've committed fixes for both.

Jonimus and I had a productive weekend converting all of the lessons into Markdown. Need to work on the stylesheet, and most of the supporting documents still need conversion- work on those will continue in the to-markdown branch.

Rationale for this is mostly that it's easier to edit Markdown than it is to edit raw HTML. As a bonus, Pandoc will allow us to build into other formats (such as PDF) with relative ease, though I am unsure how well that will work in the cases where Markdown is inadequate and we've had to fall back to HTML.

Notes:
  • I have ideas in mind for styling, but am open to suggestions.
  • Descriptions of ROM calls and such are a little bit funny in the new format. They were presented as tables which is not really semantically correct, but we haven't quite settled on a good way to present them. Currently the description list seems odd, but with the right stylesheet it may be just fine.
  • Need to add an appendix for the CSE. May also want something that discusses differences between the non-color models as well.
  • Our goal here was just converting markup; we didn't make much effort to fix factual errors.
If you want to explore it yourself, quick build (assuming Python 3, Mercurial and Pandoc are installed on your system):

Code:
$ hg clone https://bitbucket.org/tari/83pa28d/
$ cd 83pa28d
$ make
$ python3 -m http.server
The conversion to markdown looks pretty great. But is it intentional that paragraphs are wrapped at around 80 characters in the source? These appear as line breaks in the markdown editor I've tried to view the files with, which doesn't seem correct.
Runer112 wrote:
The conversion to markdown looks pretty great. But is it intentional that paragraphs are wrapped at around 80 characters in the source? These appear as line breaks in the markdown editor I've tried to view the files with, which doesn't seem correct.


That doesn't seem to affect pandoc's generated pages nor bitbucket's markdown preview so it may be specific to your editor. That said bitbucket has some issues with some of our definition list formatting and other layout choices so we may decide to redo how we did a few things.
Ah, I've got it. Apparently the editor was defaulting to using a slightly different flavor of markdown that cares about single newlines in the source, but I turned that off.

Also, would it be worthwhile to trying to get some degree of syntax highlighting in all the code blocks? Markdown extra allows for the language of code in code blocks to be specified. I don't know if we can get z80 assembly, but I know the widely-used highlight.js supports a somewhat close relative, x86 assembly.

EDIT: It's worth noting that, now that I look at it, I think that Markdown extra is actually the flavor that resulted in the single newlines in the source being retained in the output. So if this were to be used, the source line wrapping may need to be removed.
Yes syntax highlighting was a goal we had in mind, though basic themeing and CSS for the basic document would be good first, syntax highlighting would be lower on the list IMO.

Edit: We are using pandoc for the markdown parsing currently so I would look through what that says for this sort of thing rather than w/e flavor your editor is using.
Runer112 wrote:
Also, would it be worthwhile to trying to get some degree of syntax highlighting in all the code blocks? Markdown extra allows for the language of code in code blocks to be specified. I don't know if we can get z80 assembly, but I know the widely-used highlight.js supports a somewhat close relative, x86 assembly.
Yeah, this is something to investigate. I'd prefer to do it on the backend during the compile phase rather than with scripts (most compellingly, doing it at compile-time is easily portable to other output formats), but don't know how difficult that might be. A little research indicates a custom-built Pandoc might do the job, or perhaps it can be done with a fairly simple external filter.

Runer112 wrote:
EDIT: It's worth noting that, now that I look at it, I think that Markdown extra is actually the flavor that resulted in the single newlines in the source being retained in the output. So if this were to be used, the source line wrapping may need to be removed.
The Pandoc manual describes pretty effectively how its default Markdown dialect differs from others. Under markdown_strict and most other dialects, a hard line break is denoted with a trailing backslash on the previous line.
I'd just like to chime in that this is an awesome project, kudos.
I muddled my way through writing some Haskell to implement syntax highlighting as a Pandoc filter; didn't turn out too bad, I think.



You'll need ghc and alex installed to use the filter. The easiest way to get them is just by installing the Haskell Platform. I'd like to have the build system gracefully fall back to not highlighting syntax if the prereqs aren't available, so there's a bug open for that.
Is it possible to make the highlighting differentiate between (non-literal) values, macros, instructions, and register names? Also, doesn't Pandoc require Haskell Platform to be installed anyway?
elfprince13 wrote:
Is it possible to make the highlighting differentiate between (non-literal) values, macros, instructions, and register names?
Probably. If somebody is willing to contribute some regexes that might do that it's more likely to actually happen.
elfprince13 wrote:
Also, doesn't Pandoc require Haskell Platform to be installed anyway?
No. There are binary distributions for Windows and Mac, and it doesn't have any external runtime dependencies (modulo perhaps a LaTeX compiler for that output format).
Tari wrote:
elfprince13 wrote:
Is it possible to make the highlighting differentiate between (non-literal) values, macros, instructions, and register names?
Probably. If somebody is willing to contribute some regexes that might do that it's more likely to actually happen.


done. With essentially the least elegant possible regex. On the upside, registers/flags get two CSS classes labeling them both as registers and the size of the register, so we could for example make all registers one color, but make 16-bit registers bold, and flags italicized.

I didn't add in any changes to the style sheet though, but will play with that later.


Posting spree, made it prettier.


[edit]

Started fixing up the math too, using markdown+tex_math_dollars which renders everything we'll need to use into HTML without any fancy MathJax. Afaict, getting an aligned environment would need MathJax though, so I substituted tables and it looks just fine.

tex_math_dollars appears to do not-so-nice things to hex values:

That use of tables feels like a bit of a misuse to me, but I guess there isn't really a "correct" way to get that alignment without manually marking it up.
I'll see if I can use \mathrm to make those upright. And tables feel less abusive than <pre>, and are probably better form than requiring mathjax.
Tari wrote:
That use of tables feels like a bit of a misuse to me, but I guess there isn't really a "correct" way to get that alignment without manually marking it up.
Came looking for a complaint about misuse of tables for non-tabular data, left satisfied. Wink This is really a stylistic thing more than anything, but based on reading a lot of z80 ASM from a lot of different coders, I feel like the tutorial should promote lowercase opcodes and operands separated by spaces rather than caps and tabs, respectively. I believe I recall tabs in many of 83pa28d examples.
Something something stones, something something glass Cemetechs Wink


Also, fixed up day 3 a bit more. I put some of the math that didn't require alignment in a list instead of a <pre>, which I think will look good if we suppress the dots, and got rid of some typos. Also made the LaTeX'd hex look good using \mathrm.
Been mucking with the appearance of things more these past few days..

Major definitions (new instructions, bcalls, etc) now contrast with the running text to pop out more.

(Disregard improper apostrophe use. It was like that when I found it.)

Added some trendy Responsive Design to make the header not take up annoying amounts of horizontal space on narrow screens (also for print output).

The same screen rotated into landscape orientation:



elfprince13 wrote:
Just reflecting on this, it would be pretty slick if the left-side ("result") column were all one cell (colspan=4 or such). That's hard to do with pandoc (we'd have to fall back to handwritten HTML for the table), so I'm not sure it's worth doing.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 4 of 8
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement