Thomas Richter schrieb:

and do you think, that there is a hardware difference between the "c64
koala pad" and the "atari koala pad" ?

--
\thomsen
Sturz des Zaren & Take those Atarian care!
Thomas Havemeister, Student of Commercial Information Technology
Technical University of Ilmenau

Hi,

Hard to say as I've never owned a C64, leave alone its Koala Pad. Thus,
I'm up to guessing. However, it would be astonished if there would be a
difference (would have been higher production costs without any benefits).

Greetings,
        Thomas

Thomas Richter schrieb:

yep, this is true. So I will check this hardware and write a report :-)

grtx 2 berlin...

--
\thomsen
Sturz des Zaren & Take those Atarian care!
Thomas Havemeister, Student of Commercial Information Technology
Technical University of Ilmenau

It's quite easy to find out what a C64 uses the game port pins for
and compare to what is possible on the Atari. Would this Koala Pad
plug into the first or second game port to begin with?

             Pin#  C64-1             C64-2    
_____________   1  JOY A0            JOY B0
\ 1 2 3 4 5 /   2  JOY A1            JOY B1
 \_6_7_8_9_/    3  JOY A2            JOY B2
                4  JOY A3            JOY B3
                5  POT AY            POT BY
                6  BUT A/LIGHT PEN   BUT B
                7  +5V (max 50 mA)   +5V (max 50 mA)
                8  GND               GND
                9  POT AX            POT BX

Then there are issues like interconnection between game ports and the
CIA controlling the keyboard etc, but I doubt something like a touch
pad does rely on bus conflicts to operate properly.

--
Anders Carlsson

Nope,
the hardware is (afaik) the same. only the software differs... Once upon
a long ago, AMC-verlag sold some port-switchers, they turned an ST-mouse
into an Amiga mouse (or vice-versa), a koala-pad into a touch-tablet (or
vice versa), etc. etc. There were 8 different port-switchers available.
Alas, no more...  -Andreas.

Thomas Havemeister schrieb:

Well,
the KoalaPad can be used - but you have to search for the Atari software
then...
-andreas.

Thomas Havemeister schrieb:

Odd.  I specifically remember having problems trying to use my brother's
C=64 Koala pad with the example program I found.  But an Atari 8-bit one
worked.

This WAS years ago, though, so I could be totally confused or dumb.  *shrug*

-bill!

--
b@newbreedsoftware.com                                            Hire me!
   

(BASIC moves $s and 1k and 4k boundaries can
cause bad problems with a DL.)  My memory isn't
so good to remember exactly what you said.
Posting the DL is possible, but here's the code that
sets the DL up.  It is a 10 line $ that I insert into the
screen by changing the first LMS to point to one of
the two 10 line strings I use, the a second LMS to
point back to regular screen memory.
j=peek(559)
poke 559,0
poke dl+67,77  (put a lms at mode line 62)
x=scrn+40*62 (scrn and dl are 88,89 and 560,561)
hi=int(x/256):lo=x-(hi*256)
poke dl+68,lo:poke dl+69,hi
for n=1 to 9:poke dl+69+n,13:next n
poke dl+79,77 (now point back to scrn memory)
x=scrn+40*72
hi=int(x/256):lo=x-(hi*256)
poke dl+80,lo:poke dl+81,hi
for n=1 to 7:poke dl+81+n,13:next n
(if I only put n=1 to 6, I get the four lines of GR0)
x=scrn+96*40:hi=int(x/256):lo=x-(256*hi)
poke dl+89,66:poke dl+90,lo:poke dl+91,hi
for n=1 to 3:poke dl+91+n,2:next n
hi=int(dl/256):lo=dl-(256*hi)
poke dl+95,65:poke dl+96,lo:poke dl+97,hi
poke 559,j
return
lemme see that would give a dl, from the top of my head
112*3,77,scrnlo,scrnhi,then 13s down to offset 67 where
thers a 77, then $lo,$hi,9 13s,a second lms 77 at offset
79,scrn+40*72 lo, same hi,7 more 13s,a lms gr0 66,
lo scrn+96*40, same hi, 3 2s, 65, dl lo, dl hi.

My game is working, and I've compiled it.  You wanna
take a look?
Russg

Hi Russ,

Well, what I'm saying is that you need to be careful
with 4K and 1K boundaries when setting up a DList.
However, it seems that you take an Os generated list
and modify it as required. How do you create this DList?
By means of a "GRAPHICS 7+16" I suppose?

ANTIC D, LMS. Ok.

Ok, you'd therefore overwrite the DL'instructions
at offsets 68,69 for the target address. GR.7 has
96 rows and only a single LMS at the beginning,
so you should be relatively save here.

Wouldn't be needed as I guess since that's setup to
ANTIC D anyhow by the Os.

Ok.

See below.

Ok. I suppose that you opened the screen with "GRAPHICS 7" to
get a text window. Then, the screen layout would be as follows:

3  x 0x70       24 blank lines total
     0x4d LO HI LMS start
79 x 0x0d       79 lines ANTIC D
     0x42 LO HI LMS start text window
3  x 0x02       ANTIC 2 text window
     0x41 LO HI jump back to the ANTIC start

The 0x42 LMS text window start is therefore at offset 3+3+79 = 85, hence
in the middle of the addresses you're poking to. The reason why you get one
text line less is because you overwrite it with the above loop.

The problem you're facing here is than an LMS takes two additional bytes
in the display list, though there isn't room for additional bytes there
without overwriting already setup display lines.

I guess I'd already know what's going on here. (-;

I think you're best off with setting up a new DL completely since
yours requires more memory anyhow.

So long,
        Thomas

Tom Says:
"The 0x42 LMS text window start is therefore at offset 3+3+79 = 85, hence
in the middle of the addresses you're poking to. The reason why you get one
text line less is because you overwrite it with the above loop.

The problem you're facing here is than an LMS takes two additional bytes
in the display list, though there isn't room for additional bytes there
without overwriting already setup display lines.
"
I appreciate the help.  Don't quite understand.
Right, my two extra LMS require 4 more bytes
in the DL.  I am using a GR. 7 to create the screen,
so it has a text area, with a stock DL starting
at $8FA2, extending to $9000.  Screen memory
starts at $9060 for the GR7 and $9F60 for the
GR 0.  There is room for my DL which is 4 bytes
longer than the OS generated one.  The stock DL
is 94 bytes long, mine is 98 bytes long.
The stock DL goes 94 bytes $8FA2 to $9000.
Mine goes $8FA2 to $9004.  The area from $9004
to $9060 isn't used.  There's also an unused area
from the GR7 screen bottom ($9060+d80*d40)=
$9CE0, to the begining of the GR0 area at $9060
+d96*d40=$9F60.  From $9CE1 to $9F5F isn't used.
From $9005 to $905F isn't used.

There's room for my 4 bytes longer DL between
the end of my DL ($9004) and the start of screen
memory ($9060).

My DL has the same number of GR7 lines (d80) and
the same number of GR0 lines (4).  The OS won't
display the 4th GR0 line however, or Antic won't.
XLIT does display the 4 GR0 lines, as I expected.
Only when I ran it on a real Atari and then also with
atari800win do I miss the 4th GR0 line.