home Asteroids | Donkey Kong | Duck Hunt | Frogger | Moon Patrol | Pacman | Pong | Simon | Space Invaders | StarCastle | Tertis

1986
                   
1987
1988
1989
2000
2001
2002
2003
2004
2006
   

Home

Asteroids | Donkey Kong | Duck Hunt | Frogger | Moon Patrol | Pacman | Pong | Simon | Space Invaders | StarCastle | Tertis

Date: 2003-05 atari800xl.org comp.sys.atari.8bit
KoalaPad Touch Tablet for 8-bit?  
 
1.  Thomas Havemeister  
 More options May 1 2003, 1:07 am
Newsgroups: comp.sys.atari.8bit
From: Thomas Havemeister <t@gmx.de> -
Date: Wed, 30 Apr 2003 18:08:09 +0200
Local: Thurs, May 1 2003 1:08 am
Subject: Re: KoalaPad Touch Tablet for 8-bit?
| | | | | |
Thomas Richter schrieb:

> Well, AFAIK they did this unfortunately. The EOA "Music Construction Set"
> is able to use touch tablets as input devices, but offers two different
> settings for it: Atari Artist and Koala Pad, meaning that they were
> different. IIRC, something trivial as an axis swap.

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


 
 
2.  Thomas Richter  
 More options May 1 2003, 1:08 am
Newsgroups: comp.sys.atari.8bit
From: Thomas Richter <t@cleopatra.math.tu-berlin.de> -
Date: 30 Apr 2003 16:08:53 GMT
Local: Thurs, May 1 2003 1:08 am
Subject: Re: KoalaPad Touch Tablet for 8-bit?
| | | | | |
Hi,

>> Well, AFAIK they did this unfortunately. The EOA "Music Construction Set"
>> is able to use touch tablets as input devices, but offers two different
>> settings for it: Atari Artist and Koala Pad, meaning that they were
>> different. IIRC, something trivial as an axis swap.
> and do you think, that there is a hardware difference between the "c64
> koala pad" and the "atari koala pad" ?

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


 
 
3.  Thomas Havemeister  
 More options May 1 2003, 1:12 am
Newsgroups: comp.sys.atari.8bit
From: Thomas Havemeister <t@gmx.de> -
Date: Wed, 30 Apr 2003 18:13:47 +0200
Local: Thurs, May 1 2003 1:13 am
Subject: Re: KoalaPad Touch Tablet for 8-bit?
| | | | | |
Thomas Richter schrieb:

> 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).

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


 
 
4.  Anders Carlsson  
 More options May 1 2003, 8:54 am
Newsgroups: comp.sys.atari.8bit
From: Anders Carlsson <anders.carls@mds.mdh.se> -
Date: 01 May 2003 01:53:47 +0200
Local: Thurs, May 1 2003 8:53 am
Subject: Re: KoalaPad Touch Tablet for 8-bit?
| | | | | |

Thomas Havemeister <t@gmx.de> writes:
> and do you think, that there is a hardware difference between
> the "c64 koala pad" and the "atari koala pad" ?

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


 
 
5.  Andreas Magenheimer  
 More options May 3 2003, 2:54 am
Newsgroups: comp.sys.atari.8bit
From: Andreas Magenheimer <magea@students.uni-mainz.de> -
Date: Fri, 02 May 2003 19:54:25 +0200
Local: Sat, May 3 2003 2:54 am
Subject: Re: KoalaPad Touch Tablet for 8-bit?
| | | | | |
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:


 
 
6.  Andreas Magenheimer  
 More options May 3 2003, 2:48 am
Newsgroups: comp.sys.atari.8bit
From: Andreas Magenheimer <magea@students.uni-mainz.de> -
Date: Fri, 02 May 2003 19:48:45 +0200
Local: Sat, May 3 2003 2:48 am
Subject: Re: KoalaPad Touch Tablet for 8-bit?
| | | | | |
Well,
the KoalaPad can be used - but you have to search for the Atari software
then...
-andreas.

Thomas Havemeister schrieb:


 
 
7.  William Kendrick  
 More options May 3 2003, 1:10 pm
Newsgroups: comp.sys.atari.8bit
From: b@newbreedsoftware.com (William Kendrick) -
Date: Sat, 03 May 2003 04:06:33 GMT
Local: Sat, May 3 2003 1:06 pm
Subject: Re: KoalaPad Touch Tablet for 8-bit?
| | | | | |

Andreas Magenheimer <magea@students.uni-mainz.de> wrote:
> Well,
> the KoalaPad can be used - but you have to search for the Atari software
> then...

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!
   


 
Custom DL problem  
 
1.  Russ Gilbert  
 More options May 1 2003, 2:17 am
Newsgroups: comp.sys.atari.8bit
From: "Russ Gilbert" <r@en.com> -
Date: Wed, 30 Apr 2003 13:18:07 -0400
Local: Thurs, May 1 2003 2:18 am
Subject: Re: Custom DL problem
| | | | | |
(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


 
 
2.  Thomas Richter  
 More options May 2 2003, 5:15 pm
Newsgroups: comp.sys.atari.8bit
From: Thomas Richter <t@cleopatra.math.tu-berlin.de> -
Date: 2 May 2003 08:15:51 GMT
Local: Fri, May 2 2003 5:15 pm
Subject: Re: Custom DL problem
| | | | | |
Hi Russ,

> (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.

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?

> 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)

ANTIC D, LMS. Ok.

> 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

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.

> for n=1 to 9:poke dl+69+n,13:next n

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

> 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

Ok.

> for n=1 to 7:poke dl+81+n,13:next n

See below.

> (if I only put n=1 to 6, I get the four lines of GR0)

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.

> 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?

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


 
 
3.  Russ Gilbert  
 More options May 3 2003, 4:59 am
Newsgroups: comp.sys.atari.8bit
From: "Russ Gilbert" <r@en.com> -
Date: Fri, 2 May 2003 16:00:20 -0400
Local: Sat, May 3 2003 5:00 am
Subject: Re: Custom DL problem
| | | | | |
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.


 

- - - -
End