Cursor Control with Commodore 64.

The ability to draw a character at any spot on the screen - within the constraint of rows and columns, perhaps, is key, when you're trying to create either a text editor, or a roguelike, or nearly anything with a text-based UI.

It's apparently also impossible on the Apple I, but fortunately I'm working with something a bit more advanced. I'm not doing THAT retro.

C64 Programmer's Reference Guide is fairly good. I'm not entirely sure I could have comprehended it, or would have had access to it when I was in grade school, but it's at least theoretically possible.

I definitely would have been able to get this book, whether via a library or by pestering my parents sufficiently. Not sure I had the character and audacity required for such a proactive behavior, though, but meh.

In any case, the various bits of secret sauce I've discovered thus far are:

poke 214, row
poke 211, column:sys (58732) 

This sets the cursor to a specific row and column, as far as printing is considered. The SYS is required to set the row and column.

The get loop is fairly common, being

get a$:if a$="" then goto

You can find that in many different sources. However, it does not display the cursor.  Poking at the right spot (204, 0 for enable, 1 for disable) does turn the cursor on and off, but for some reason, the cursor location is wrong.

You can also do direct manipulation of screen memory by poking at locations from 1024 onwards, but unfortunately the character ROM doesn't directly map to PETSCII.

As a downside of using GET input, you do not get to benefit from the, actually rather nifty on-screen editing that is default for C64.

I'm trying to create a status line, by jumping between cursor location and line 23, where I print current cursor location and... well, haven't really thought that far. Filename, I suppose. Currently I'm just putting the last key's code there.

I flip editor mode on F1, of course the only command currently supported is "save", and frankly, there is no scrolling, so max document length is 25 lines, but, baby steps.

print#, which is used to write to files, is also... finicky, I guess. it uses slightly different printing rules, and it differentiates between variables by CRs (char code 13), which makes it unsuited to printing numbers, unless you use some sort of string encoding. I did figure out I could save ASM files as hex strings, and loading those would be quite simple. I might use that as an intermediate step.

Anyway, the various SYS commands are fortunately documented in the Programmer's Reference Guide.

I am currently working with the idea that actual data is kept on known area in memory, which is then written to disk. I've already run into some issues with the memory area not being cleared, which ended up with this little bit of... fun.

a900a2009d00109dff109dff119dff12e8e0ffd0ef60

 To break it down:

a900     lda 0
a200     ldx 0
9d0010   sta 4096,x
9dff10   sta 4351,x
9dff11   sta 4606,x 
9dff12   sta 4861,x
e8       inx   
e0ff     cpx 255
d0ef     bne -16
60       rts

It's really moderately straight-forward, it should zero an area from 4096 to 5116, or so, by copying accumulator to various memory slots adjusted by x-index. it increments x-index by 1, then compares it to 255, and if it's not there yet, it jumps back 16 bytes in execution.
Biggest new thing I learned was that the comparison operator jumps backwards or forwards by a specific number of bytes. Makes sense.

Oh, I guess I should mention I tested this by using this little program here :

ready.
list

10 rem hex8todec
30 i=1:m=0
35 input "mem address start:";s
40 print str$(s);:input a$
50 gosub 150:i=i+1
60 d=b*16
70 gosub 150
80 b=d+b
90 print b,;
100 poke s+m, b:m=m+1
110 if i=len(a$) then goto 200
120 i=i+1
140 goto 50
150 b=asc(mid$(a$,i,1))
160 if b<64 then b=b-48
170 if b>64 then b=b-55
180 return
200 rem end
ready.

Running the program with an appropriate sys address call, of course.
There are a couple of different ways of doing byte to hex conversion and vice versa.
A lookup table works fine, and is pretty concise for byte-to-hex, since the and masking and division need to be done anyway. I don't worry much about the memory limitations at this point, although they are a concern with real-world applications. My editor program is starting to reach the point where putting the screen at 4096 may risk overwriting the actual code.

For hex-to-byte conversion, I guess you could create an array of integers of the PETSCII codes, and compare each letter to the array, recording the index of the match, but I'm not convinced it's faster than what I have here. Might use less memory, though.

A Simple Quiz Game in Commodore 64 Basic a Grade Schooler Could Write

10 print "quizgame"
20 open 1,8,8,"quizfile,r,s"
30 dim answer$(9)
35 i=0
36 p=0:rem points
37 qs$=""
40 input# 1,a$
50 rem print a$
60 if a$="!" goto 900
80 ca=0:rem correct answers
100 type$=left$(a$,1)
130 if type$="q" then qs$=qs$+mid$(a$,2,255)
150 if type$="a" then gosub 200
160 if type$="c" then gosub 250
190 goto 40
200 answer$(i)=mid$(a$,2,255)
210 i=i+1
220 return
250 rem gosub from 160
260 ca=val(mid$(a$,2,1))
270 gosub 300
280 return
300 print qs$
310 for j=0 to i-1:rem gameplay
320 print str$(j+1)+":"+answer$(j)
330 next j
340 i=0
350 get an$:if an$="" goto 350
360 an=val(an$)
370 if ca=an then p=p+1
380 print "your answer was:", an
390 print "correct answer was:",ca
400 print ,answer$(ca-1)
410 return
900 close 1
910 print "number of points:"+str$(p)

So...yeah.
Basically, that's all it took. It reads in a file "quizfile" and lines that start with a q, are part of the question, a lines contain an answer, and c lines are followed by a number indicating which answer was correct.

For an example:

qWhat is your favourite color
aBlue
aRed
aBlue, i mean red!
c1

This is not quite enough, as the ability to create the file is required. A simple solution - and the one I used to write the file was this:

5 dim o$(100)
6 i=1
10 input o$(i)
20 if o$(i)="!" then 100
40 i=i+1
50 goto 10
100 print "end"
105 print i;"lines of text"
107 open 1,8,8,"@0:quizfile,w,s"
110 for j=0 to i
120 print o$(j)
140 print#1,o$(j)
150 next
160 close 1

It's not good enough, though, since you do need the ability to add new questions.
It's also not the simplest possible way, since you could do the whole thing with a goto after the open in a input-print# loop until end symbol, but I often putter around, trying different things, and sometimes the solution can be messy.

simple would be something like this:

10 open 1,8,8,"@0:quizfile,w,s"
20 input a$
30 if a$="!" then 100
40 print# 1,a$
50 goto 20
100 close 1

Well, I'm going to be compassionate towards my younger self. After all, it took me a while to figure out how to write and load from files, and an arcane syntax like "@0:" is more than a bit odd, although I think it means "start writing to the file from this location. Because, otherwise, the file doesn't save, and then, sadness. 

Adventures in Commodore 64 Basic

Let me try to get this formatted nicely in HTML:

10  rem decimal to hex byte converter
20  rem need some data, use basicmem
30  begin=4096
40  finish=4128
50  for i=begin to finish
60  v=peek(i)
65  rem numbers start at 48=0
70  hi=int(v/16):lo=v and 15
75  rem numbers start at 48=0
80  lo$=chr$(48+lo)
90  hi$=chr$(48+hi)
100 rem chars start at 65=a
110 if lo>9 then lo$=chr$(55+lo)
120 if hi>9 then hi$=chr$(55+hi)
130 print hi$lo$+" ";
140 cols=cols+1
150 if cols=8 then gosub 200
160 next
170 goto 230
200 print ";"
210 cols=0
220 return
230 rem end

---

Here's the stylings:

div.commodore {
  border: 60px solid #0088ff;
  color: #0088ff;
  background-color: #0000aa;
  text-transform: uppercase;
  font-family: "Courier", "Courier New";
}

To tell the truth, I've already written a bunch of tiny practice programs.

1. One that takes in input lines and writes them to file, 
2. Read lines from file
3. change the cursor, border and background color - in machine language, put into memory. That was the image in the last post. 
4. one that tests the hires mode. Things get interesting there

and a few others. However, today I wrote something potentially useful - a bit of code that dumps an area from memory to the screen in hex. Doing that is probably going to be useful, once I get into more machine language stuff, especially as I cannot pretend to own a TASM cartridge or something.

Well.

What I wrote is a START, as, since it being a basic program, it's slow, AND unless I combine it with an interface to edit memory, it doesn't do that much - I can do poke-run loops, but that seems remarkably tedious.

An alternate way would be to translate  this to ASM, then load it to an area in memory, and then activate it via SYS calls.

Still, the output looks cool.

The program dumped is, naturally, the screen-color altering one from my previous post.
A9 is a single-byte LDA, 8D is STA followed by a 2-byte little endian address, 60 is RTS.

I suppose a sys calls is basically just a JSR, then.

Fixing My Childhood Trauma With Commodore 64

Holy Belldandy's Eyebrows, Batman!

Yes, I possessed one of these wonderful machines, wayback. I was even interested in programming with them. Unfortunately, very little materials were available, outside a fairly good computer magazine, and my understanding was really quite poor.

At some point in grade school - between age 9 and 12,  I was quite into it - even if I had tried to trade my C64 for an MSX, because it had direct commands for graphics and sound. However, typing in program listings rarely worked and I really couldn't debug the programs - didn't even know how.  I did try to write a trivial pursuit type question-answers game in the fifth grade, but it was just this awful mess of IF-THENs. I think I tried using DATA statements, but I couldn't quite get it to work, so I gave up on that, and the fact I even remember that, should tell you something.

At that age, I didn't have any money. I couldn't buy ANYTHING, although I did get my parents to buy, and later on had a subscription to the C=magazine. I also think I had ONE book (ISBN 951-832-005-5), but it seems to have vanished at some point. :/

So, as a project, I'm doing some C64 programming, with the following constraints:
- All code is written inside the emulator
- No pre-existing applications are allowed. I don't know if I had any
- I will allow for the internet, which is a bit of a cheat, admittedly, but there are chances I could have gleaned the information from a magazine.

My goals are, roughly:
 - A text editor,
 - A hex editor, capable of writing to disk, for some rough machine code working
 - MAYBE a macroassembler.
 - Various audio/video tests
 - The !"#%¤%& game, it's engine and enough demo questions for a proof of concept.

Since I'm bringing in a generation's worth of computer science knowhow, I can say that the quiz program needs to load the questions from a file on a floppy disk (or perhaps a datassette, too) instead of being hardcoded, and the questions need to be editable with (a, the) text editor.

I do hope to document this, since a "How do I Basic to Macroassembler" does not seem to exist in the 'net at this point.

Game character stuff.

Something something cast fist?

A lot of what becomes a game is art assets. On a recent interview, a modern game can have 10 Gb of art and maybe 200M of code.

This is a kernel, or a seed of sorts. Also, my camera is not a scanner. Clearly.

I ended up doodling in Piskel a bit. Fun, and usable, but not exactly what I intend to go for.
Just the keyframes, but at this resolution I'm not sure if any more is needed.

Still, I seem to be entering a pixel art kick .