Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
"Learn TI-83 Plus Assembly in 28 Days" is a great tutorial. In fact, many including myself feel that it remains the best z80 assembly tutorial currently available. Unfortunately, though, it's nearly a decade old, and it has a variety of omissions and errors, not to mention missing information on the most recent calculator models. Several community members have talked about updating it over the years, but sadly, none has gotten the free time to follow through. I brought up the topic once again with DrDnar on #cemetech yesterday evening, and we came up with the following options:

:: Tari and I have discussed working independently or together to improve and fix up the tutorial using a DCVS repository. Other people could potentially contribute, and the completed tutorial could be uploaded to ticalc.org and the Cemetech Archives.
:: Alternatively, I and others could work to add the days and reference material in ASM in 28 Days to WikiTI, and then everyone would be able to edit it. I offered an additional idea that when it reached something of a static state, one of us could take the initiative to extract the pages once more and upload it to ticalc.org et alia.

Thoughts on these two options? Other than DrDnar, Tari, and myself, does anyone have interest in helping? Prerequisites are excellent spelling, grammar, and clarity, experience with technical teaching or writing, and of course proficiency with z80 assembly.


Editor's note: Tari helpfully hosts a precompiled version of the updated guide if you just want to read it.
I would be interested in fixing it up a bit. A repository would certainly make controlling the changes of multiple people easier, but I worry slightly that it could hinder people who don't have much experience with using repositories and associated software (e.g. me) from contributing.
It's very straightforward to use version control, whether we used mercurial or git. Plus, that's a great skill to have if you ever plan to write software professionally, or even if you just want to keep your calculator source code sanely organized. The ability to see exactly the code added for each new feature in a program, for example, is very valuable.
I'd also be interested in helping with whatever i can. I've been wanting to work on a set of tutorials specifically related to game programming, concepts like tilemapping, hit detection, bullets, objects, path-finding, etc. Perhaps this could be a subset of the new tutorials?
I think that's reasonable. I think that one of ASM28D's biggest flaws is that it doesn't have nearly enough example code and complete example programs, so perhaps fleshing out some sections with how the skills could be applied to writing a game would be nice. Even taking a game through from the rudiments to something complete and fun, as I did in "Programming the TI-83 Plus/TI-84 Plus" in chapter 6, perhaps? There's Hot Dog's tutorial for game-centric ASM, but I've always found his approach (including teaching hex and bit math near the end) to be very suboptimal.
I also like the idea of walking people through building a game. I think two good projects to walk through would be, first, a Phoenix-style shoot-em-up (introduces objects/bullets, enemy patterns, etc. but you don't have to worry about the speed-hit of a tilemap) followed by a Mario-style platformer (introduces things like tilemaps and simple physics).
This is an exciting prospect. Unfortunately I an unable to contribute but will be one of the target audience instead. The ASM in 28 Days seems to have gained almost iconic status, but as mentioned is let down by some errors. I know that some errors have been trapped on the forums but a noob could otherwise, be stopped in their tracks. Programming in ASM is a great skill and should be a voyage of self discovery as well as a foundation stone for an exciting hobby or career.
I especially like the Wiki idea; having the entire community able to add to the remake seems like a good way to pull in everyone's unique specialties with ASM, creating a very well rounded tutorial.

I'd love to help out with this, but i rarely have access to a computer during the summer :'(
I like the idea of updating it, especially via some repository like Git (since I've finally gotten decent at it thanks to another project). I would be interested in helping to create a few example programs, or at the very least, going through and adding some extra details to make the snippets behave correctly (the CD record thing comes to mind).

I think I'll read through it today, since it's been quite a while since I've looked at it.
It sounds like the current majority prefers the repository idea, so let's work with Tari's repository for now and see where that goes.
Until I can figure out how to upload to the repository, here's what I've been working on: a list of things I think should be fixed with day number, location on page, what to fix, and why I think it should be fixed/changed. (If you saw it yesterday, it's the same one):

| Day | Location on page                | What to fix                      | Why                                    |
|   1 | Top, Requirements for Learning  | It should use newer tools that   | When I was first learning from this,   |
|     |                                 | will make it easier for people   | almost the first thing I did was find  |
|     |                                 | to start/learn.  Also, we should | a different assembler because I        |
|     |                                 | use BrandonW's ti83plus.inc and  | couldn't get TASM to work, plus Brass+ |
|     |                                 | link them to that.               | BinPac8x is a lot easier to setup.     |
|     |                                 |                                  |                                        |
|   1 | Top, Requirements for Learning  | The guide says that it's almost  | My reasoning for this is that a lot of |
|     |                                 | necessary to know a high level   | the people who are reading this have   |
|     |                                 | language, like C.  We might want | just come from TI Basic (or Axe) and   |
|     |                                 | to make sure that, even if       | requiring another language might scare |
|     |                                 | someone doesn't know C or some   | some of them away.                     |
|     |                                 | other language that they can     |                                        |
|     |                                 | still understand the tutorials.  |                                        |
|     |                                 |                                  |                                        |
|   1 | Development of a Z80 Program    | Switch away from Notepad         | Notepad is hard to work with and using |
|     |                                 | completely.  This might also     | a programming editor (Notepad++ or     |
|     |                                 | remove the concern about setting | really anything else) will make their  |
|     |                                 | up the Z80 filetype.             | lives a lot easier.                    |
|     |                                 |                                  |                                        |
|   1 | Development of a Z80 Program,   | Remove the reference to          | I think most of the readers would have |
|     | near the bottom                 | Borland's Turbo Assembler.       | no idea what this is (I was kind of    |
|     |                                 |                                  | familiar but still had to google to    |
|     |                                 |                                  | make sure).                            |
|     |                                 |                                  |                                        |
|   1 | Assembling, near the top        | Again, remove TASM stuff, plus   | This part isn't really bad, but it     |
|     |                                 | if we include Brass and such     | would be better to make things go      |
|     |                                 | then they won't have to manually | faster for whoever's reading it.       |
|     |                                 | save the .bat file.              |                                        |
|     |                                 |                                  |                                        |
|   1 | Sample Z80 Program, in the code | Change ProgStart to the value    | I seem to remember some value like     |
|     |                                 | in ti83plus.inc.  We'd also want | ProgStart already in there, I might    |
|     |                                 | to check that the bcall syntax   | be wrong, though.  Also, bcalls gave   |
|     |                                 | works with the newer include     | me the most trouble when I was         |
|     |                                 | file.                            | learning because my assembler would    |
|     |                                 |                                  | never accept the syntax I was using.   |
|     |                                 |                                  |                                        |
|   1 | Navigating Within DOS           | Maybe remove the info about DOS  | If everything is set up so you just    |
|     |                                 |                                  | have to drag and drop the ASM file     |
|     |                                 |                                  | onto the assembler (or have a .bat     |
|     |                                 |                                  | which calls everything for you), then  |
|     |                                 |                                  | navigating DOS isn't necessary. I do   |
|     |                                 |                                  | think it's useful to know, but could   |
|     |                                 |                                  | confuse people for no reason.          |
|     |                                 |                                  |                                        |
|   1 | Sending to the Calculator       | Change this over to use          | Most people don't use GraphLink now    |
|     |                                 | TI-Connect or TILP rather than   | (I'd say no one, but I'm sure there's  |
|     |                                 | GraphLink                        | one person somewhere with it).         |
|     |                                 |                                  |                                        |
|   2 | Top                             | Again, ProgStart and bcall. Also | I always wondered where the reasoning  |
|     |                                 | we should remove the shouting    | for using all-caps instructions came   |
|     |                                 | opcodes                          | from, but I think that it would be     |
|     |                                 |                                  | best to teach them as lowercase at     |
|     |                                 |                                  | least from a style viewpoint.          |
|     |                                 |                                  |                                        |
|   2 | Directives                      | Discuss .db a bit more, and then | .db is usually something that people   |
|     |                                 | remove the details about .end    | don't understand that well.  It's      |
|     |                                 | and the second .end              | probably explained more further into   |
|     |                                 |                                  | the tutorial, but a little more info   |
|     |                                 |                                  | here would be better.  For .end, I     |
|     |                                 |                                  | don't remember if Brass requires .end  |
|     |                                 |                                  | so it might be worth leaving that part |
|     |                                 |                                  | out.                                   |
|     |                                 |                                  |                                        |
|   2 | ROM Calls                       | If the syntax for them is        | Personally, I like having them look    |
|     |                                 | changed, this will need to be    | like instructions, e.g. bcall PutS.    |
|     |                                 | changed, too.                    | I also don't really like the _PutS     |
|     |                                 |                                  | syntax, but that's probably just me.   |
|     |                                 |                                  |                                        |
|   2 | Program Template                | We'll want to make sure this     | Most people are just going to be       |
|     |                                 | template follows good            | copying this into all of their         |
|     |                                 | conventions.  Also, later on in  | programs, so the header should be      |
|     |                                 | the tutorial, we should just     | correct.  And including the full       |
|     |                                 | include the full header          | header will help people who want to    |
|     |                                 |                                  | try out the programs from each chapter |
|     |                                 |                                  |                                        |
|     |                                 |                                  |                                        |
What format will the guide be edited in? Something that can be converted to mediawiki syntax, html, pdf?
I rather like that idea. Pandoc?
I like it! I wonder how well it will work for the pages in the guide. (Especially looking at the reference sections)
Coincidentally, I emailed Sean back in early May asking him if he would mind if I made some updates to the tutorial (although the updates I had in mind were mainly compiler based, as I'd been emailed by someone asking how to get TASM working).

I'm happy to add my 2 cents wherever it might be useful Smile
AHelper wrote:
What format will the guide be edited in? Something that can be converted to mediawiki syntax, html, pdf?
I was assuming that we'd be sticking with HTML for flexibility; I think we all know at least decent HTML/CSS?

James: That's great, I actually did the same a few years back. Did he ever get back to you?
Do it right, use LaTex Razz
elfprince13 wrote:
Do it right, use LaTex Razz
As much as I love LaTeX, I don't know if that's the right solution here, especially as we don't have a lot of fancy math to mark up.
But everyone appreciates high quality type-setting! And it can be used to generate both PDF and HTML output! And I'm sure the algorithmic package could be put to good use for pseudocode.
And LaTeX is a lot more contemporaneous to the Z80 than HTML.
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
Page 1 of 7
» All times are GMT - 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