"AI" on C64... help port?

[aiia...@gmail.com]

http://www.mos6502.com/friday-commodore/artificial-intelligence-on-a-c64/

can someone look at http://www.mos6502.com/files/nn64_listing.txt and let me know what the pokes and disk commands do, so I can port this to another BASIC?


Rich

[rusure]

you may want to go here and download one of the C64 items .

http://project64.c64.org/hw/c64.html

I recommend the Commodore 64 PROGRAMMER'S REFERENCE GUIDE

[rusure]

On May 15, 7:08 am, aiiad...@gmail.com wrote:
> http://www.mos6502.com/friday-commodore/artificial-intelligence-on-a-...
>
> can someone look athttp://www.mos6502.com/files/nn64_listing.txtand let me know what the pokes and disk commands do, so I can port this to another BASIC?
>
> Rich

You may want to download some of the C= 64 items from here :

http://project64.c64.org/hw/c64.html

I recommend the Commodore 64 Programmer's Reference Guided

[wf]

The POKEs place characters on the screen. The screen buffer starts at
1024 and is a 40x25 grid. So POKE1024+X+40*Y,<val> puts a character at
X,Y on the screen.

The disk commands write & read individual numeric values sequentially to
a file, with PRINT#5,<val> and INPUT#5,<val> respectively. The contents
of the F1%, F2% and M% arrays are saved & restored, one value at a time.

[Anton Treuenfels]

<aiia...@gmail.com> wrote in message
news:2078785.21.1337087316506.JavaMail.geo-discussion-forums@yneo7...

Lines 370-390 look like interrupts are being turned off and the character
ROM switched into visible memory for the purpose of copying a character
pattern into the free memory block, then the character ROM is switched back
out and interrupts re-engaged. No idea why, though.

All the PRINT ""; statements are bit puzzling since they don't appear to do
anything. I'll guess that the special (ie., non-ASCII) characters originally
there aren't showing up in the listing. They would most likely have been
"screen clear" and/or "cursor home", ie., the KERNEL character output
routine would have treated them specially.

As has been mentioned, all the POKES based on an address starting at 1024
are directly modifying screen memory, ie., the memory the video chip scans
looking for the character codes of what it should display. They're not
directly concerned with the logic of the neural net but only with how things
look on the screen.

The lines 1840 and 2030 form a command to access a sequential file on drive
0 for writing and reading, respectively. The OPEN statements one line 1850
and 2060 actually open the files as #5 (an arbitrary number) on device 8
(usually a 1541 floppy drive, which actually had only one physical drive,
but not all Commodore drives were so limited). The file #5 is used to refer
to those files in subsequent writes and reads.

Line 50 OPENs file #15 on device 8 with a secondary value of 15. That
secondary value is a special value that accesses the "command channel" of a
drive (as opposed to a "data channel"). It's common and convenient to use
the same number for the file number (but not required). This file is used in
lines 2230+ to ask the drive whether or not an error has occurred during a
write or read (the variables are essentially "error number", "error message
(ie., text)", "error track", "error sector").

- Anton Treuenfels

[Anssi Saari]

"Anton Treuenfels" <teamt...@yahoo.com> writes:

> All the PRINT ""; statements are bit puzzling since they don't appear
> to do anything. I'll guess that the special (ie., non-ASCII)
> characters originally there aren't showing up in the listing.

Yes. The webpage links to a prg file too, but it doesn't have the
control codes either so the program doesnt work too well. One might ask
the author of the post on mos6502.com if he happens to have a working
version somewhere. He might since he posted a screenshot...

[aiia...@gmail.com]

lines 360 to 410 are the only thing I haven't been able to figure out

[aiia...@gmail.com]

310 K=ASC(A$)
PRINT "FETCH ";A$

350 L%=0:rem init l%, the function of this routine is to
fill F1%(L%),
for L% = 0 to 41 (height * width, 7*6)
360 K=(K-64)*8+53248: set k to point to address relative to
the key pressed
370 POKE56333,127:POKE 1,PEEK(1)AND251


380 FORI=0TO6:
POKE49408+I,PEEK(K+I) moves 7 bytes from ?ROM? to RAM
:NEXT


390 POKE 1,PEEK(1) OR 4:POKE 56333,129


400 FOR I = 0 TO 6: rem height
410 J% = PEEK(49408+I)/2:rem get from RAM or ROM relative to I
420 FOR K=1 TO 6:rem width
430 L%=L%+1:rem initialized to zero from outside of i loop, it is
an index into f1%:
440 F1%(L%) = -1 + (2 * (J% AND 1)): rem fills 6 bytes of F1%,
value depends on j%, which
is ?ROM? address?
450 J%=J%/2: rem get next ?bit? from the value retrieved from ?ROM?
460 NEXT K
470 NEXT I

[aiia...@gmail.com]

On Wednesday, May 16, 2012 4:17:53 PM UTC-7, aiia...@gmail.com wrote:
> On Wednesday, May 16, 2012 3:16:59 PM UTC-7, aiia...@gmail.com wrote:
> > On Tuesday, May 15, 2012 6:08:36 AM UTC-7, aiia...@gmail.com wrote:
> > > http://www.mos6502.com/friday-commodore/artificial-intelligence-on-a-c64/
> > >
> > > can someone look at http://www.mos6502.com/files/nn64_listing.txt and let me know what the pokes and disk commands do, so I can port this to another BASIC?
> > >
> > >
> > > Rich
> >
> > lines 360 to 410 are the only thing I haven't been able to figure out
>
> 310 K=ASC(A$)
> PRINT "FETCH ";A$
>
> 350 L%=0:rem init l%, the function of this routine is to
> fill F1%(L%),
> for L% = 0 to 41 (height * width, 7*6)
> 360 K=(K-64)*8+53248: set k to point to address relative to
> the key pressed
> 370 POKE56333,127:POKE 1,PEEK(1)AND251
>
>
> 380 FORI=0TO6:
> POKE49408+I,PEEK(K+I) moves 7 bytes from ?ROM? to RAM
> :NEXT
>
>

I see what its doing now. moves character from ROM to RAM (7 bytes)

my target computer doesn't have access to character ROM so I'll have to load a character set into RAM.

r

[aiia...@gmail.com]

On Tuesday, May 15, 2012 6:08:36 AM UTC-7, aiia...@gmail.com wrote:

80 DIM V%,J,I


why is V% dimmed without initializing J and I?

[Anton Treuenfels]

<aiia...@gmail.com> wrote in message
news:82706e1c-3731-466b...@googlegroups.com...

None of these are array variables; they're all scalar. The DIM statement as
used here simply creates them and initializes them to zero. A faster and
more compact way of saying

80 V%=0:J=0:I=0

although V%, an integer variable, actually takes the same amount of space as
a scalar that a floating point variable does (seven bytes - it's only in
arrays that integer variables save space vs. floating point, two bytes vs.
five per element). If there's any practical reason for doing that, I can
only imagine that it must have something to do with limiting the range of
values V% is allowed to have and making the BASIC interpreter responsible
for guaranteeing it.

Offhand I doubt it, though.

- Anton Treuenfels