Copy Link
Add to Bookmark
Report
GEnieLamp A2Pro - Vol.5, Issue 32
|||||| |||||| || || |||||| ||||||
|| || ||| || || ||
|| ||| |||| |||||| || |||| Your
|| || || || ||| || ||
|||||| |||||| || || |||||| |||||| GEnieLamp Computing
|| |||||| || || |||||| RoundTable
|| || || ||| ||| || ||
|| |||||| |||||||| |||||| RESOURCE!
|| || || || || || ||
||||| || || || || ||
~ WELCOME TO GENIELAMP A2Pro! ~
"""""""""""""""""""""""""""
~ TIPS AND TECHNIQUES: Compressing Hi-Res Graphics ~
~ Scrolling Text ~ Linear Regression ~ Bezier Curves ~
~ 65C816 in an Atari? ~ Switching Processes in the GNO Shell ~
~ HOT NEWS, HOT FILES, HOT MESSAGES ~
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
GEnieLamp A2Pro ~ A T/TalkNET Publication ~ Vol.5, Issue 32
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Publisher.................................................John F. Peters
Editor....................................................Tim Buchheim
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
~ GEnieLamp IBM ~ GEnieLamp Atari ~ GEnieLamp PowerPC ~
~ GEnieLamp A2Pro ~ GEnieLamp Macintosh ~ GEnieLamp TX2 ~
~ GEnieLamp Windows ~ GEnieLamp A2 ~ LiveWire (ASCII) ~
~ Member Of The Digital Publishing Association ~
GE Mail: GENIELAMP Internet: genielamp@genie.com
////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>>> WHAT'S HAPPENING IN THE A2Pro ROUNDTABLE? <<<
"""""""""""""""""""""""""""""""""""""""""""""""""
~ November 1, 1995 ~
FROM MY DESKTOP ......... [FRM] A2PRO ROUNDTABLE STAFF .. [DIR]
Notes From The Editor. Directory of A2Pro Staff.
TIPS AND TECHNIQUES ..... [TIP] HEY MISTER POSTMAN ...... [HEY]
Compressing Hi-Res Graphics Is That A Letter For Me?
DEVELOPERS CORNER ....... [DEV] LIBRARY BIT BONANZA ..... [LIB]
News From Online Developers. HOT Files You Can Download.
LOG OFF ................. [LOG]
GEnieLamp information.
[IDX]"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
READING GEnieLamp GEnieLamp has incorporated a unique indexing
""""""""""""""""" system to help make reading the magazine easier.
To utilize this system, load GEnieLamp into any ASCII word processor
or text editor. In the index you will find the following example:
A2PRO ROUNDTABLE STAFF .. [DIR]
Directory of A2Pro Staff.
To read this article, set your find or search command to [DIR]. If
you want to scan all of the articles, search for [EOA]. [EOF] will take
you to the last page, whereas [IDX] will bring you back to the index.
MESSAGE INFO To make it easy for you to respond to messages re-printed
"""""""""""" here in GEnieLamp, you will find all the information you
need immediately following the message. For example:
(SMITH, CAT6, TOP1, MSG:58/M530)
_____________| _____|__ _|___ |____ |_____________
|Name of sender CATegory TOPic Msg. Page number|
In this example, to respond to Smith's message, log on to page
530 enter the bulletin board and set CAT 6. Enter your REPly in TOPic 1.
A message number that is surrounded by brackets indicates that this
message is a "target" message and is referring to a "chain" of two
or more messages that are following the same topic. For example: {58}.
ABOUT GEnie GEnie's monthly fee is $8.95 which gives you up to four hours
""""""""""" of non-prime time access to most GEnie services, such as
software downloads, bulletin boards, GE Mail, an Internet gateway, award-
winning multi-player games and friendly chat lines. GEnie's non-prime time
connect rate is only $3.00 per hour. Prime Time (8:00 am to 6:00 pm local
time on weekdays) is only $5.00 per hour. To sign up for GEnie, just
follow these simple steps:
1. Set your communications software to half duplex (local echo) 8 bits, no
parity and 1 stop bit, at 300, 1200, 2400 or 9600 baud.
2. Call (with modem) 1-800-638-8369 (US) or 1-800-387-8330 (Canada).
3. Wait for the U#= prompt. Type: JOINGENIE and hit RETURN. When you
get the prompt asking for the signup/offer code, type: DSD524 and hit
RETURN.
4. Have a major credit card ready, as the system will prompt you for your
information. If you need more information, call GEnie's Customer Service
department at 1-800-638-9636.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
[EOA]
[FRM]//////////////////////////////
FROM MY DESKTOP /
/////////////////////////////////
Notes From My Desktop
"""""""""""""""""""""
by Tim Buchheim
[A2PRO.GELAMP]
o TOP OF THE PAGE
>>> TOP OF THE PAGE <<<
"""""""""""""""""""""""""
~ A Letter From the Editor ~
GENIE OUTAGES Last month I talked about GEnie's first ten years and how
""""""""""""" much it has changed. Well, it is still in the process of
change; GEnie is in the middle of both hardware and software upgrades. In
the past few weeks, these upgrades have caused some problems with GEnie.
I've received a report on these problems and thought I should pass it on
so you know what's happening.
Here's the report I got:
"As many of you have no-doubt experienced, GEnie has recently had some
recent unplanned system outages. These outages have been both hardware and
software related. The hardware problems have been fixed, and a solution
for the software problem is undergoing rigorous testing and is slated to be
deployed around mid-November. We apologize for any inconvenience these
outages have caused."
Here's a chronology of what happened. [GEIS is GEnie's parent company]
10/17 (Tuesday) around 21:10: All members were knocked off line. By 21:45
''''''''''''''''''''''''''''' GEnie was back on line. The problem was
diagnosed as a software problem for which GEIS had a formulated fix. The
fix has been undergoing rigorous testing and is slated to be deployed
around mid to late November.
10/23 (Monday) and 11/24 (Tuesday) around ~21:00-22:00: On both days,
''''''''''''''''''''''''''''''''''''''''''''''''''''''' GEnie members
again were knocked off line. The problem was diagnosed as a hardware
problem on GEIS equipment that GEnie requires for operation. On Wednesday,
the hardware vendor addressed the incidents by replacing boards that were
identified as bad.
10/27 (Friday) around 19:00 - 23:00: Initially, only some clients were
'''''''''''''''''''''''''''''''''''' knocked off line, but eventually,
all were knocked off. This incident was attributed to a hardware failure
on yet another piece of GEIS equipment. This time a power supply blew out.
The power supply was replaced that evening, and GEnie service was restored.
Each of the incidents displayed the same symptoms, but were caused by
different problems.
EMAIL WEIRDNESS There have also been some strange things happening with
""""""""""""""" Email the past few weeks. GEIS upgraded the internet mail
gateway, fixing several bugs but causing a minor problem. As most of you
know, you can receive email sent to "yourname@genie.com" as well as
"yourname@genie.geis.com" but all outgoing mail is sent with
"yourname@genie.geis.com".
Or at least it's supposed to be that way. When the INET03# mail
connector was upgraded to the new software a few months ago, no one had any
problems because it was configured right. The main connectors,
INTERNET#, INET#, INET00#, and INET01# were upgraded this week but
weren't configured properly, so they send mail as "genie.com" instead of
the correct "genie.geis.com".This has caused problems for people on mailing
lists, because the mailing lists don't recognize this other address.
A temporary solution is to send all mail through INET03# rather than the
other connectors, if you need to have it sent with the "genie.geis.com"
address. The other connectors may be reconfigured, or they may leave
them as "genie.com" since they were scheduled to be set to "genie.com" in a
month or so anyway.
Once they officially announce that internet mail will be through
"genie.com", you should unsubscribe to mailing lists through INET03# and
resubscribe through one of the main connectors, so they recognize your
"genie.com" address instead of "genie.geis.com".
-- Timothy Carl Buchheim
Editor, GEnieLamp A2Pro
P.S. You might have noticed that this issue is much bigger than usual.
Well, I tried to keep it reasonable by not having the "RTC Watch"
and "Spotlight On:" columns this month. Look for those next month,
unless I decide to skip them again in the interest of keeping
download time to a minimum :)
P.P.S. Sorry this issue was a few days late, but I had no time to work on
before the 1st. :/
[*][*][*]
Do you have something to say about GEnieLamp A2Pro? Please
post any questions or comments you may have in Category 1,
Topic 15 in A2Pro's BB (m530;1). Or, feel free to talk to me
(A2PRO.GELAMP) anytime you see me in a Real Time Conference.
Readers out there on the Internet: feel free to email me at
a2pro.gelamp@genie.com When writing, please tell me where
you got your copy of GEnieLamp, if it wasn't on GEnie. I'm
always interested to see how many places GEnieLamp ends up :)
By the way, the current issue and most back issues are
available online in many places. GEnie users should check
Library #2 in the DigiPub libraries (DIGIPUB, page 1395;3)
Those of you not on GEnie should use gopher software to
connect to gopher.genie.com for issues; all recent issues and
most older ones are there.
[*][*][*]
[EOA]
[DIR]//////////////////////////////
A2PRO ROUNDTABLE STAFF /
/////////////////////////////////
By Tim Buchheim
[A2PRO.GELAMP]
o A2Pro STAFF LIST
>>> A2Pro STAFF LIST <<<
""""""""""""""""""""""""
______________________________________________
APPLE II PROGRAMMERS & DEVELOPERS ROUNDTABLE
_____ ______ ______________________________________________
/_____|/______\
/__/|__| ___|__| Head Sysop: Hangtime (HANGTIME)
/__/_|__| /_____/ Your Sysops: Greg Da Costa (A2PRO.GREG)
/________|/__/ __ __ __ Todd P. Whitesel (A2PRO.TODDPW)
/__/ |__|__/______ /_//_// / Nathaniel Sloan (A2PRO.HELP)
/__/ |__|________// / \/_/ Tim Buchheim (A2PRO.GELAMP)
[EOA]
[FEA]//////////////////////////
TIPS AND TECHNIQUES /
/////////////////////////////
Compressing Hi-Res Graphics
"""""""""""""""""""""""""""
By Russell Nielson
[R.NIELSON1]
o COMPRESSING GRAPHICS
o THE PROGRAMS IN THE PIC.COMP10.BXY ARCHIVE
Editor's note: This is the first of what I hope will be a
"""""""""""""" series of articles written by readers. But
it will only work if you send in articles! If your article
is published, then you will be paid with GEnie usage credits.
Any article related to programming Apple II computers will be
considered. Those articles which include sample source code
are especially good, because the whole point of the series is
to provide programmers with ideas and samples, in order to
encourage them to write new software for the Apple II!
This month's article is about compressing graphics files, and
is based on a file in the A2Pro library called PIC.COMP10.BXY
which was uploaded by the author of this article.
>>> COMPRESSING GRAPHICS <<<
"""""""""""""""""""""""""""""""
INTRODUCTION As we all know, any type of graphics take up a lot of disk
"""""""""""" space, and when you have a lot of graphics in one place,
disk space can be eaten up very quickly. I'd like to discuss one form of
graphics on the Apple II called hi-res graphics, which stands for high
resolution graphics. All programmers that have ever programmed on the
Apple II in hi-res know that a single picture takes up a whopping 8187
bytes of memory or 17 blocks on a ProDOS disk! When you have many pictures
stored on disk they can take up a lot of space. Please be aware that
"picture" and "screen" both refer to a single hi-res graphics screen.
When developing software that uses graphic screens and pictures, you need
to store these picture files on disk, load them into memory, and display
them on the hi-res screen. This isn't a problem until you start having
multiple pictures, like a title screen, a menu screen, an options screen, a
high scores screen, etc.. you are talking a lot of graphic data here! The
main problem usually shows up when you only have a certain amount of disk
space available for your entire project. For instance, if you are
writing a cool game and plan on distributing it on one side of a 5.25"
floppy disk, your entire game (were talking all your graphics, code,
data, etc) has to fit in 140k! Not only that, but if you want your disk to
boot into the game automatically then you need to leave enough space for
ProDOS (and BASIC.SYSTEM if part of your program is in Applesoft) to be
copied there. As you can see you will run out of disk space rather
quickly.
During the development of one of my arcade games I had so many graphic
screens saved to disk that it really got me sick to see all the disk
space going to waste! Not only that but loading an entire 8187 bytes of
data just to display one screen takes some time, so I sat back and
thought for a moment. I have this rather simple screen, which is
practically a black screen with a colored border and a small graphic at the
top, which is taking as much disk space as any other screen. I
determined that regardless of how complex or how simple the picture may be,
it's always the same size. If you cleared the hi-res screen to black (a
blank screen) and saved it, it would still be a whopping 17 blocks. The
reason behind this is because the graphics screen on Apple computers is
simply a chunck of memory that reflects what is seen on the monitor. If
you save hi-res screen 1 you would be writing the area of memory from $2000
to $3FFF. This block of memory is always the same size and doesn't
change even if the graphic image is very simple. I needed to come up
with something here to save space.
One solution to saving disk space is to somehow represent the picture on
the screen in a different manner that does not take up the full 8187 bytes.
Welcome to the world of compression. There are many compression methods
around and they are used all the time. For instance, Shrink-It and GS
Shrink-It use compression methods when placing files into archives.
These programs take each file and compress them down as small as the
compression algorithm allows and then stored them into the archive. Take
GEnie's Software Libraries for example, most everything is stored in a
compressed format (.SHK) because compressed files take up less disk space
and cut down on file transfer times.
Although the Shrink-It compression routines are quite complex, this does
not mean that every compression method is complicated. When writing my
routine for compressing the hi-res screen, it had to ensure that no
information was lost during the compression so that the original picture
would be recreated and displayed on the screen EXACTLY how is was before
being compressed.
MY COMPRESSION METHOD After loading numerous pictures and examining the
""""""""""""""""""""" hex dump of the screens, I began to see repetitious
bytes and repeating patterns. I figured that if I could store these
repeating sequences of bytes as a single number, or two, then I would be
saving space. I used a very simple algorithm that would allow me to
represent groups of bytes on the screen in just a couple bytes.
Here's what I came up with:
All black colors on the screen are either $00 or $80, depending on the
color bit. $00 is black #1 and $80 is black #2. Remember that there are
two black colors and two white colors available in hi-res. In contrast,
all white colors on the screen are either $7F or $FF, again depending on
the high bit.
So a black line on the hi-res screen would look something like this:
00 00 00 00 00 00 00 00 00 00
Note: All numbers are represented in hexadecimal.
""""
This segment would be a black line ten bytes wide on the hi-res screen.
The same goes for black #2 ($80), white #1 ($7F) and white #2 ($FF). I
looked at this and said to myself, "Hmmm.. there's gotta be a better way
than to just keep repeating zeroes over and over again wasting space."
So I came up with a method. For every $00, $80, $7F, or $FF I find, I will
count the number that are in a row, store the color, and then store the
number of times this color is repeated. So in the example above, I'd store
all those zeroes like this:
00 0A
Only two bytes are needed to represent that entire group of zeroes! The
above "00 0A" means that color 00 is repeated 10 times! ($0A = 10
decimal). When it comes time to decompress it again, I simply check for a
$00, $80, $7F, or $FF and then repeat that color the number of times the
repeating byte says! The repeating byte always follows directly after
the color byte.
For another example, here's how the following segment would compress:
Raw: 00 00 00 00 00 FF FF FF FF 7F 7F 7F 7F 7F 7F 7F 80 80 80 80 00 00
Compress: 00 05 FF 04 7F 07 80 04 00 02
See how it works? The more repeating bytes in a row, the more space will
be saved! So if you have a picture with lots of black and white areas,
then the compression will be excellent. In the above sample, that's over
50% compression!
WHAT ABOUT COLORS? After I wrote this routine and tested the compression
"""""""""""""""""" on various pictures, I still was not satisfied with
the results. Why? Well, when I had a picture will lots of black and white
areas, this compression scheme worked great, but when I had a picture
with lots of colors and hardly any black and white areas, the compression
was horrible. The reason was because if there were hardly any repeating
black and white bytes, then there was not a whole lot to compress.
I started thinking of a better way to compress the screens and for new
ideas for better compression. After looking at a few more screen dumps, I
noticed that Green, Purple, Red, and Blue colors followed a pattern. Maybe
I could use a compression method to represent repeating color? Sure I
could! Here's what I came up with:
After the examination of the screen dumps, this fact surfaced:
Green lines are repeating patterns of $2A and $55
Purple lines are repeating patterns of $55 and $2A
Red lines are repeating patterns of $D5 and $AA
Blue lines are repeating patterns of $AA and $D5
So a green line on the screen would look like this:
2A 55 2A 55 2A 55 2A 55 2A 55 2A 55
Wow! I see a pattern. I used the same algorithm as the black and white
method, but had to add in a little twist for pattern repetition. Since the
black and white colors were represented as one byte (00, 80, 7F, FF) they
were easy to compress, I just had to store count the number of bytes in a
row and store that count (or repeat number) after the color byte. But
now things are a little different because two bytes represent a color
instead of just one.
To handle colors (now meaning that black and white aren't colors), I will
use a method for pattern recognition by issuing a comparision of two
bytes instead of just one. For example, if I was compressing a screen
and I came across a $2A, I'd immediately check the byte following it and
see if it was a $55. If it was, then I would have found a pattern! I'd go
on an count how many of these patterns were in a row and store that
repeat value as the repeating byte. So in the above example, that green
line would be stored like this:
2A 55 06
In this case, the "2A 55" is the pattern for a green line and the "06"
means that there are six of these patterns in a row. When I'm
decompressing this screen and I came across the $2A byte, and after I
made sure that the next one after it was $55, then I would go ahead an
repeat this pattern 6 times!
The same thing goes for Purple, Red and Blue. Except that I would
compare different numbers because the patterns would be made up of
different byte combinations.
That is basically the extent of my compression algorithm. There are only
two cases in my routine, checking for a non-color byte, and checking for
a color byte. In the case of checking for a non-color sequence, I'd act
on 00, 80, 7F, and FF. In the case of checking for a color pattern, I'd
act on $2A/$55, $55/$2A, $D5/$AA, and $AA/$D5 which represent color
sequences. Any other values would be stored as normal, non-compressed.
DECOMPRESSION Once the screen has been compressed and is stored in this
""""""""""""" new format, it needs to be decompressed and end up in its
original form. This process works just like the compression method but
it is much easier. I start scanning the compressed data and I look for the
key values which are 00, 80, 7F, and FF. Whenever I encounter such a
value, I take the next byte, which is the repeating value, and store that
number of the color value in a row to the screen. So if I came across
"00 1D" I'd store twenty-nine 00's in a row. I'd also scan for key color
sequences which are $2A/$55, $55/$2A, $D5/$AA, and $AA/$D5. Whenever I
find one of these sequences I'd take the next byte, which (again) is the
repeating value, and store this pattern that many times. So ifI came across
"AA D5 03" I'd store three "AA D5"'s in a row on the screen.
DISADVANTAGES Aren't there any disadvantages? Yes, unfortunately there
""""""""""""" are a few. The good thing is that all the advantages
always outweigh the disadvantages. The only bad part about my
compression algorithm is when there is only one $00, $80, $7F, or $FF in
a row, it takes one extra byte to store it compressed than it would to
leave it decompressed. For instance a single $00 would compress to look
like this: 00 01. This is a disadvantage because we started with one
byte and ended up with two. The other bad part is when you only have one
color pattern in a row like $D5 $AA, it would compress to D5 AA 01. We
went from having only two bytes to needing three. The overall advantage is
that the compression method always comes out ahead of the game because
there are usually lots more repeating bytes in a row than there are
single bytes laying around, and because of what I am going to describe
below.
THERE'S GOTTA BE SOMETHING ELSE With that done I went ahead and did some
""""""""""""""""""""""""""""""" more compressions and studied the
results. Everything was working great except for one instance. If I had
a majorly complex screen (one with hardly any repeating bytes) then the
compression would result in hardly any savings, and sometimes would end
up just a little bigger than the original! This was not good. I broke
open a few of my Apple books in search of a secret or two about the
hi-res screen that I may have overlooked, or simply failed to think about.
And soon enough, I found something.
I found out that the hi-res screen was full of "screen holes". What I
mean when I say screen holes, is that the screen has many areas which are
not visible to the viewer. These areas can be safely zeroed out, and these
zeroed out areas will compress. So even if there is not one single
repeating byte on the entire screen, after the compression it will still be
smaller, not by a whole lot, but definetly smaller. Sometimes even just
a few bytes help.
HOW IS IT ALL ACCOMPLISHED? Let me first explain that I have uploaded the
""""""""""""""""""""""""""" entire source code to the A2Pro Software
Libraries. Along with this source is a complete set of utilities to
load, compress, save, and decompress screens. Download file PIC.COMP10.BXY
(file number 3596) if you want to have the entire source and utilities.
I'll explain some of the source code here:
There are two constants I use here. SCREEN is hires screen one, and BUFFER
is hires screen two, which I am using to hold the compressed picture data.
SCREEN equ $2000 ; screen address
BUFFER equ $4000 ; crunch data buffer
Here are some zero page storage variables. Picture and Data are pointers.
Picture equ 0 ; picture to pack
Data equ 2 ; crunch data
PtrnByte1 equ $FE ; 1st pattern byte to store
PtrnByte2 equ $FF ; 2nd pattern byte to store
Here are the non-color and color pattern constants.
Black1 = $00 ; recognition values
Black2 = $80
White1 = $7F
White2 = $FF
Green = $2A ; color recognition values
Purple = $55
Red = $AA
Blue = $D5
Now here is the crunch (or compression) routine.
Crunch
jsr Filter ; filter screen "holes"
lda #>SCREEN ; point to hires screen 1
ldx #<SCREEN
sta Picture+1
stx Picture
lda #>BUFFER ; point to data buffer
ldx #<BUFFER
sta Data+1
stx Data
ldy #0
:NewByte
lda (Picture),y ; load the screen byte
beq :blkwht ; $00, $80, $7F, $FF
cmp #Black2 ; bytes will repeat
beq :blkwht
cmp #White1
beq :blkwht
cmp #White2
beq :blkwht
cmp #Green ; possible Green pattern
beq :green
cmp #Purple ; possible Purple pattern
beq :purple
cmp #Red ; possible Red pattern
beq :red
cmp #Blue ; possible Blue pattern
beq :blue
bne :store ; always
:green jmp :Dgreen
:purple jmp :Dpurple
:red jmp :Dred
:blue jmp :Dblue
:store sta (Data),y ; store screen byte
jsr NextData
jsr NextPic
bcs :finished ; carry set = finished
jmp :NewByte
:blkwht sta (Data),y ; store repeat byte
sta :compbyte
jsr NextData
ldx #0
:repeat
inx
jsr NextPic ; get next picture byte
bcs :storerep ; end of screen, store rep
lda (Picture),y
cmp :compbyte ; match?
beq :same
:limit
txa
sta (Data),y ; store repeat counter
jsr NextData
jmp :NewByte
:same
cpx #0 ; up the repeat counter
beq :limit ; max of 255 repeat bytes
jmp :repeat
:storerep
txa
sta (Data),y ; store repeat counter
jsr NextData
:finished rts
:Dgreen tax
iny ; is this a green pattern?
sta PtrnByte1
lda (Picture),y
cmp #Purple
bne :pstore
sta PtrnByte2
jsr StorePtrn ; store green pattern
bcs :finished
jmp :NewByte
:Dpurple tax
iny ; is this a purple pattern?
sta PtrnByte1
lda (Picture),y
cmp #Green
bne :pstore
sta PtrnByte2
jsr StorePtrn ; store purple pattern
bcs :finished
jmp :NewByte
:Dred tax
iny ; is this a red pattern?
sta PtrnByte1
lda (Picture),y
cmp #Blue
bne :pstore
sta PtrnByte2
jsr StorePtrn ; store red pattern
bcs :finished
jmp :NewByte
:Dblue tax
iny ; is this a blue pattern?
sta PtrnByte1
lda (Picture),y
cmp #Red
bne :pstore
sta PtrnByte2
jsr StorePtrn ; store blue pattern
bcs :finished
jmp :NewByte
:pstore dey
txa
jmp :store
:compbyte ds 1 ; stores comparison byte
*-------------------------------------------------
StorePtrn
ldx #0
ldy #0
lda PtrnByte1 ; store pattern data
sta (Data),y
iny
lda PtrnByte2
sta (Data),y
dey
jsr NextData
jsr NextData
:Ptrnloop
lda (Picture),y
cmp PtrnByte1
bne :endptrn
iny
lda (Picture),y
cmp PtrnByte2
beq :match
dey
:endptrn
txa
sta (Data),y ; store pattern repeat count
jsr NextData
clc
rts
:match
dey
jsr NextPic
jsr NextPic
bcs :done
inx
bne :Ptrnloop
:done dey
txa
sta (Data),y ; store pattern repeat count
sec ; indicate finished
rts
*-------------------------------------------------
* Screen "holes" are 8 bytes in a row at a constant
* increment of $80 (or 128 decimal) through-out
* the hi-res screen. So 504 bytes make up the
* total bytes in screen holes per screen. After
* compression it would only use 126 bytes, so that's
* a savings of 378 bytes in compressed format in
* just the screen holes!
*-------------------------------------------------
Filter lda #>SCREEN ; zero out the screen holes
sta Picture+1
lda #<SCREEN
clc
adc #$78 ; start at 1st screen hole
sta Picture
:Hole lda #0
ldy #8 ; store all zeroes there
:loop dey
sta (Picture),y
bne :loop
lda Picture
clc
adc #$80 ; advance to next hole
sta Picture
bcc :ok
inc Picture+1
:ok
lda Picture+1 ; finished last hole?
cmp #>SCREEN+$2000
bne :Hole ; nope, loop for more
rts ; yep, finshed
*-------------------------------
* Adjust screen pointer
*-------------------------------
* Exit, carry set if done
NextPic pha
inc Picture ; next picture address
bne :noinc
inc Picture+1 ; see if at bottom of screen
:noinc lda Picture
bne :nottop
lda Picture+1
cmp #>SCREEN+$2000
bcc :nottop
pla
sec ; carry set = done
rts
:nottop pla
clc ; carry clear, more
rts
*-------------------------------
* Adjust data pointer
*-------------------------------
NextData inc Data ; next data buffer address
bne :noinc
inc Data+1
:noinc rts
You'll notice that the first thing I do it call the Filter routine which
simply fills all the screen holes with zeroes so the compression routine
works effectively in all cases, regardless of the complexity of the screen.
Next I set up the Picture pointer to point to hires screen one and set up
the buffer to store the compressed data to hires screen two. I am only
using hires screen two because it is a convienent place in memory to
store the data. It could be anywhere.
Then the compression loop begins at :NewByte. The next byte is loaded from
the hires screen and it is checked to see if it is a $00, $80, $7F, or $FF.
If the screen byte is any of these values then the program goes to the
:blkwht routine which stores the color value, counts the number of color
values in a row, and then stores the value as the repeating byte; then
loops for more.
If the screen byte is a $2A, $55, $AA, or $D5 then there is a possible
pattern so the program branches to the appropriate color routine which
checks the next byte to try and match a color pattern, then if a color
pattern is found it counts the number of patterns in a row and stores the
value as the repeating byte; then loops for more.
That's it for the compression routine. Now for the decompression routine.
Unpack
lda #>SCREEN ; point to hires screen 1
ldx #<SCREEN
sta Picture+1
stx Picture
lda #>BUFFER ; point to data buffer
ldx #<BUFFER
sta Data+1
stx Data
ldy #0
:NewByte
lda (Data),y ; load the data byte
bmi :high
beq :blkwht ; $00, $80, $7F, $FF repeat
cmp #Green ; possible Green Pattern
beq :green
cmp #Purple ; possible Purple Pattern
beq :purple
cmp #White1
beq :blkwht
bpl :store
:high
cmp #Black2
beq :blkwht
cmp #Blue ; possible Blue pattern
beq :blue
cmp #Red ; possible Red pattern
beq :red
cmp #White2
beq :blkwht
:store sta (Picture),y ; store screen byte
jsr NextData
jsr NextPic
bcs :finished ; carry set = finished
bcc :NewByte ; always
:green tax
iny ; is this a green pattern?
sta PtrnByte1
lda (Data),y
cmp #Purple
bne :pstore
sta PtrnByte2
jsr ScreenPtrn ; store green pattern
bcs :finished
bcc :NewByte ; always
:purple tax
iny ; is this a purple pattern?
sta PtrnByte1
lda (Data),y
cmp #Green
bne :pstore
sta PtrnByte2
jsr ScreenPtrn ; store purple pattern
bcs :finished
bcc :NewByte ; always
:red tax
iny ; is this a red pattern?
sta PtrnByte1
lda (Data),y
cmp #Blue
bne :pstore
sta PtrnByte2
jsr ScreenPtrn ; store red pattern
bcs :finished
bcc :NewByte ; always
:blue tax
iny ; is this a blue pattern?
sta PtrnByte1
lda (Data),y
cmp #Red
bne :pstore
sta PtrnByte2
jsr ScreenPtrn ; store blue pattern
bcs :finished
bcc :NewByte ; always
:finished rts
:blkwht pha
jsr NextData ; get repeat byte
lda (Data),y
jsr NextData
tax ; and use as counter
pla
:repeat sta (Picture),y ; store to screen
jsr NextPic
bcs :finished
dex
bne :repeat ; loop
jmp :NewByte
:pstore dey
txa
jmp :store
*-------------------------------------------------
ScreenPtrn
jsr NextData ; grap repeat counter
jsr NextData
ldy #0
lda (Data),y
tax
jsr NextData
:Ptrnloop
ldy #0 ; store pattern to screen
lda PtrnByte1
sta (Picture),y
iny
lda PtrnByte2
sta (Picture),y
dey
jsr NextPic
jsr NextPic
bcs :out
dex ; pattern loop
bne :Ptrnloop
clc
:out rts
The unpack (or decompress) routine starts just as the compression
routines did. It sets up the Picture and Data pointers. This time it
reads the Data byte and compares it to see if it is a $00, $80, $7F, or
$FF. If it is one of these bytes then it grabs the repeating byte and
stores that many of the color value to the screen (or unpack address, which
happens to be hires screen one). Then loops for more.
Just like the compression routine, again, when a color pattern is found, it
is stored to the screen as many times as the repeat value.
That's it! My compression routines are not very complex but they work very
fast and very well for hires graphics.
>>> THE PROGRAMS IN THE PIC.COMP10.BXY ARCHIVE <<<
""""""""""""""""""""""""""""""""""""""""""""""""""""
All the programs and utilities are freeware, including the "dirty" graphics
that I "quickly" drew to demonstrate my routines.
PIC.COMPRESSOR - This is the main compression program. It allows you to
'''''''''''''' choose and load a hi-res graphic, compress it, and then
give you the option to save it and watch it decompress.
Use this program to compress all your pictures.
UNPACK.TEST - This program will search the CRUNCHED subdirectory and
''''''''''' load and unpack all the compressed picture files to the
screen. It works like a slide show.
SCREEN.HOLES - Little program I used while trying to find all those
'''''''''''' screen holes.
CRUNCH - This is the machine language compression and unpack
'''''' routines. It does all the compressing and decompressing
because of its speed.
UNPACK - This is ONLY the unpack routine. If you write a program
'''''' that needs to load and unpack compressed pictures, then
this is all you need. You don't need the compressor
because you won't be compressing pictures, you'll just
unpack them.
DIRECTORY STRUCTURE The way the programs are set up now, they will look
""""""""""""""""""" for picture files in the subdirectory called PICS.
When the compression program saves the crunched picture it will save it
in the subdirectory called CRUNCHED with the extension .PCC. So every
picture that you would like to crunch must be copied into the PICS
subdirectory.
TECHNICAL BABBLE The way the routines are set up now, the compressed
"""""""""""""""" picture must be loaded onto hi-res screen 2 ($4000) and
it gets unpacked to hi-res screen 1 ($2000). The compressing/unpacking
routines are at $7000 and $7003. After loading CRUNCH, a CALL to 28672
will compress the picture on screen 1 to screen 2 and a CALL to 28675
will unpack the compressed picture on screen 2 to screen 1.
After loading UNPACK, it will reside at $7000 also, except that only one
CALL is used. A CALL to 28672 will unpack the compressed picture
residing on screen 2 to screen 1.
SOURCE CODE The source code to the routines was written with the MERLIN """"""""""" assembler. The CRUNCH.S source and UNPACK.S source may be
modified to suit your needs. You can change the compile address (ORG) to
something else if you'd like the (un)compression routines to reside
somewhere else in memory. You can also change the values of "Picture"
and "Data" to tell the routines where to look for the compressed picture
and where to uncompress the picture to. You may want to set up a "load"
buffer where the compressed picture will be loaded and then unpack it to
either of the hi-res screens. It's up to you.
The source code is fully commented therefor I think that you will find it
very interesting to browse through and read all the other technical junk as
well.
[*][*][*]
We want your articles! If you want to write an article for
GEnieLamp A2Pro, then contact the editor, A2PRO.GELAMP for
more information. We pay for articles with usage credits.
[*][*][*]
[EOA]
[HEY]//////////////////////////////
HEY MISTER POSTMAN /
/////////////////////////////////
Is That A Letter For Me?
""""""""""""""""""""""""
By Tim Buchheim
[A2PRO.GELAMP]
o BULLETIN BOARD HOT SPOTS
o WHAT'S NEW
o PROGRAMMERS' TIPS
o MESSAGE SPOTLIGHT
>>> BULLETIN BOARD HOT SPOTS <<<
""""""""""""""""""""""""""""""""""
~ Where All the Action Is! ~
[*] CAT 2, TOP 5, MSG {59}.....Using the Merlin 8 assembler
[*] CAT 2, TOP 8, MSG {43}.....Assembly language and AppleSoft BASIC
[*] CAT 3, TOP 4, MSG {113}....The Merlin 16+ Assembler
[*] CAT 3, TOP 19, MSG {138}....General Assembly Questions
[*] CAT 11, TOP 8, MSG {111}....Programming Algorithms and Structures
>>> WHAT'S NEW <<<
""""""""""""""""""""
~ Announcements ~
A HALLOWEEN VISITOR BOO!
"""""""""""""""""""
I am sure programmers just love computer goblins <g>
(SKELETON, CAT1, TOP2, MSG:211/M530)
>>> PROGRAMMERS' TIPS <<<
"""""""""""""""""""""""""""
~ Helpful Advice from the Experts ~
STARTING SOURCEROR Help! My Merlin-8 manual is packed away and I cannot
"""""""""""""""""" remember...
How do I start Sourceror? I remember the BRUN SOURCER/OBJ, but then what?
(PAUL.RSM, CAT2, TOP5, MSG:59/M530)
>>>>> Paul,
"""""
1. Load the program to be disassembled.
2. BRUN SOURCEROR
3. Accept the $2500 (default) address for the source file.
4. Hit <return> if the loaded program is at its "running location"
Is that enough?
...John at Wood-n-Shavings
_____
/ \
(=====)
\___+_/
!... Hans
(H.HAUMANN, CAT2, TOP5, MSG:61/M530)
<<<<< I found a friend's Merlin manual. After BRUN SOURCER/OBJ, enter
""""" the editor. Kill the 80 column screen with Esc Ctrl-Q. Type USER.
(PAUL.RSM, CAT2, TOP5, MSG:62/M530)
SCROLLING TEXT I need to be able to scroll the IIe 40-column text screen
"""""""""""""" upwards. Does anyone have or know of a routine that can
do that for me?
This looks comparatively trivial to do, and I sat down to write the code,
only to discover that I have nearly completely forgotten how to code 6502
assembly. Use it or lose it. <sigh>
I can relearn assembly, but I would rather get this project on the road
=now=. <g>
TomZ
(A2.TOMZ, CAT2, TOP8, MSG:43/M530)
<<<<< >I need to be able to scroll the IIe 40-column text screen upwards.
"""""
Oops. I =meant= to say DOWNwards. It's not hard to get it to scroll
upwards. <g>
TomZ
(A2.TOMZ, CAT2, TOP8, MSG:44/M530)
>>>>> First, I've never done this so I'm speculating, but...
"""""
If you want to scroll downward and back upward, as in a word processor
file, then maybe you need a buffer with the text properly broken into
line-length sections. Then it's a small matter to re-draw the screen by
shifting pointers. I'm sure that there is a better way to do this. ;)
Will you control the text content, or will it be input by the user?
Charlie
(A2.CHARLIE, CAT2, TOP8, MSG:45/M530)
<<<<< The program would be doing all writing to the screen. This is
""""" intended to be an arcade effect for an Eamon game in development.
All I need is a routine that will write each line to the line below it.
This was once =well= within my capabilities as an assembly user, but I
haven't written a line of assembly in several years and find that I have
totally lost everything I once knew on the subject. (I find this
discovery to be extremely depressing, BTW)
If nobody has such a routine handy, we can work around it OK. We're not
even sure we want to do it that way.
TomZ
(A2.TOMZ, CAT2, TOP8, MSG:46/M530)
>>>>> Maybe this will help...
"""""
First push the registers to the stack to store them so that you can restore
them after you are finished.
PHA
TYA
PHA
TXA
PHA
You can also store any other flags, etc. that way.
Next, you'll need a routine for locating the cursor. Load the x register
with the horizontal cursor location, and the y register with the vertical
location. Then JSR GOTOXY
GOTOXY DEX ;go back one for range
STX CH ;store horiz. location CH = $24
DEY ;go back one for range
TYA
PHA ;calculate base address
LSR ; based on BASCALC ($FBC1)
AND #3
ORA #4
STA BASH ;BASH = $29
PLA
AND #$18
BCC :1
ADC #$7F
:1 STA BASL ;BASL = $28
ASL
ASL
ORA BASL
STA BASL
RTS
Next set up a counter to use to loop through the lines from 23 to 2.
BEGIN LDX #1
STX HOR :HOR = $06
LDX #23
STX VER ;VER = $07
:1 LDX HOR
LDY VER
JSR GOTOXY
LDY CH ;horiz. pos
:2 LDX HOR
LDA (BASL),Y ;get character on screen
STA BUFFER,X ;BUFFER = $200
INC HOR
INC CH
LDY CH
CPY #40 ;finished with line?
BNE :2
LDX #1
STX HOR
LDX VER
INX
STX VER
JSR GOTOXY
LDY CH
:3 LDX HOR
LDA BUFFER,X
STA (BASL),Y
INC HOR
INC CH
LDY CH
CPY #40
BNE :3
LDX #1
STX HOR
LDX VER
DEX
DEX
STX VER
CPX #1
BEQ :4
JMP :1
:4 RTS
After this you will have to place the new line 1 message on line 1. Be sure
to restore your registers when you are done.
Hope this helps.
Charlie
(A2.CHARLIE, CAT2, TOP8, MSG:47/M530)
>>>>> That'll get you up and running, but if you decide to go with it
""""" then you'll probably want to speed it up. BTW you didn't mention if
it should respect the text window or not; Charlie's routine uses the
numbers for the whole screen.
Todd Whitesel
(A2PRO.TODDPW, CAT2, TOP8, MSG:48/M530)
>>>>> Hey Tom!!
"""""
I wrote a blazingly fast downscroll routine for use in a project for
Softdisk 8-bit, but they ceased publication and I haven't finished the
program yet. The project was the ProDOS version of Electric Duet and it
uses the 40-column text mode exclusively, written in 6502 opcodes so it's
compatible on all Apple II's!! This is so fast because I use text screen
row tables instead of computing the address.
All you need to do here is make sure Top, Bottom, Left, and Right are set
to the values to define the text window, normally they are setup for full
screen, but this routine allows you to scroll ANY portion of the text
screen! The neat thing about this routine is that after the text window is
scrolled, the top line is filled with spaces.
Charlies' routine looks as if it will work, but if you want speed (usually
arcade style games need the fastest code possible) then try my routine! :)
Have fun!
- Russ
P.S. If you'd rather not type this in, I'll be happy to shoot the source
code file to you via attached file in email.
*-------------------------------------------------
* Zero page constants
*-------------------------------------------------
ptr equ $06 ; general usage pointer (trashable)
Left equ $20 ; left margin of text window
Right equ $21 ; right margin of text window
Top equ $22 ; top of text window
Bottom equ $23 ; bottom of text window
zp equ $eb ; general zero page (trashable)
*-------------------------------------------------
* Downscroll
*-------------------------------------------------
* Entry: Top, Bottom, Left, Right set to text window
Downscroll
lda Bottom ; start at bottom of text window
sta zp
dec zp
:Next_Row
ldy zp ; get current row
lda LOTAB,y ; set up "from" copy address
sta :downmod+1
lda HITAB,y
sta :downmod+2
dec zp ; get previous row address
ldy zp ; set up "to" copy address
lda LOTAB,y
sta ptr
lda HITAB,y
sta ptr+1
ldy Left ; start at left of text window
dey
:Do_Row
lda (ptr),y ; get screen byte
:downmod sta $FFFF,y ; store one line down (self modified!)
cpy Right ; finished row?
bne :Do_Row ; nope, keep going
lda Top ; at top of text window?
cmp zp
bne :Next_Row ; nope, do next screen row
Blankline
lda #" " ; fill with spaces character
ldy Left ; start at left of text window
:Blank
sta (ptr),y ; put space there
iny
cpy Right ; finished row?
bne :Blank ; nope, keep going
rts ; ok, finished
*-------------------------------------------------
* Text screen line lookup table
*-------------------------------------------------
LOTAB hex 0080008000800080
hex 28a828a828a828a8
hex 50d050d050d050d0
HITAB hex 0404050506060707
hex 0404050506060707
hex 0404050506060707
(R.NIELSON1, CAT2, TOP8, MSG49/M530)
>>>>> Use Russ' routine. :) Mine was just a quick hack to get you
""""" heading in the right direction; his is good. :)
Charlie
(A2.CHARLIE, CAT2, TOP8, MSG:51/M530)
>>>>> Here's a slightly tweaked up version of Russell's screen downscroll
""""" routine that's a tad smaller, a tad faster, and missing an infinite
loop bug :)
Note that this uses an additional pair of zero page locations ($FE,$FF)
which I've found are typically safe to grab... Also the Blankline routine
is no longer externally callable.
*
*-------------------------------------------------
*
* 40 column text screen downscroller
* by: Russell Nielson
* Tweaks by Harold Hislop
*
* Downscrolls the current text _window_
* 6502 clean
*
*-------------------------------------------------
*
case se ;enable case sensitivity
tr on
tr adr
xc off ;kill 65C02/802/816 ops
org $900 ;or wherever...
*
*-------------------------------------------------
*
* Zero Page stuff(ings)
*
*-------------------------------------------------
*
ptr equ $06 ;general usage pointer (trashable)
zp equ $EB ;general zero page (trashable)
XtraZP equ $FE ;Russ didn't use this originally.
*
Left equ $20 ;left margin of text window
Right equ $21 ;right margin of text window
Top equ $22 ;top of text window
Bottom equ $23 ;bottom of text window
*
*-------------------------------------------------
*
* Here there be code...
*
* Entry: Top, Bottom, Left, Right set to text window
*
*-------------------------------------------------
*
Downscroll
ldx Bottom ;get bottom of current window
dex ;refer to prev line
*
]LnLp lda LOTAB,x ;set up the "Get" pointer
sta ptr
lda HITAB,x
sta ptr+1
*
dex ;get previous line number
stx zp ;prep for 'nother pass
*
lda LOTAB,x ;and the "Put" ptr...
sta XtraZP
lda HITAB,x
sta XtraZP+1
*
ldy Left ;start at left of text window
]MvLp dey
lda (ptr),y ;get screen byte
sta (XtraZP),y ;store one line down (self modified!)
cpy Right ;finished line?
bne ]MvLp ;nope, so loop
*
ldx zp ;assume another loop needed...
cpx Top ;at top of window yet?
bne ]LnLp ;nope, do next screen row
*
lda #" " ;fill with spaces character
]Clr sta (ptr),y ;put space there
dey
cpy Left ;finished row?
bne ]Clr ;nope, keep going
rts ;ok, finished
*
*-------------------------------------------------
*
* Text screen line lookup table
*
*-------------------------------------------------
*
LOTAB hex 0080008000800080
hex 28A828A828A828A8
hex 50D050D050D050D0
*
HITAB hex 0404050506060707
hex 0404050506060707
hex 0404050506060707
*
*-------------------------------------------------
-Harold
(hope the formatting comes out Ok...)
(HAROLD.H, CAT2, TOP8, MSG:51/M530)
>>>>> Charlie, your quick hack was a good one! The reason I've never
""""" used the BASCalc monitor routines is because I have a habit of
doing everything on my own, and in my own way... just so I can customize
any routine I write to do EXACTLY what I need it to do. :)
(R.NIELSON1, CAT2, TOP8, MSG:53/M530)
>>>>> > and missing an infinite loop bug :)
"""""
I KNEW IT!! Ratz! I posted that routine directly from my project code
but there was a little editing that I had to do to the code here in the
post. In my original downscroll routine I had certain columns of the
screen that didn't get scrolled (they were data dividers) so I had the
routine skip these specified columns. I edited out the column checking
code from the routine and I must've done it hastily and left an infinite
loop in there... thanks for spotting it and reposted a better version
Harold.
The reason the Blankline routine was external was because it was used by
the Downscroll _and_ Upscroll routines, which saved valuable bytes in the
object code, because I was running low on space.
Anyway,
Cool!
(R.NIELSON1, CAT2, TOP8, MSG:54/M530)
>>>>> Harold,
"""""
Sorry, but your version doesn't work. I loaded it into Merlin, assembled
it, tested it, and it just fills the screen with random characters, and I
can see why. :)
I can see a couple of problems right away:
ldy Left ;start at left of text window
]MvLp
dey <====== DEY???
lda (ptr),y ;get screen byte <===== from ptr???
sta (XtraZP),y ;store one line down (self modified!)
cpy Right ;finished line?
bne ]MvLp ;nope, so loop
You are starting at the Left margin, why would you DEY? And, you have the
to pointers switched, you want to grab data from XtraZP and place at ptr.
This should be:
ldy Left ;start at left of text window
dey
]MvLp
iny
lda (XtraZP),y ;get screen byte
sta (ptr),y ;store one line down (self modified!)
cpy Right ;finished line?
bne ]MvLp ;nope, so loop
Tony, here's my routine again without the infinite loop.
*-------------------------------------------------
* Downscroll
*-------------------------------------------------
* Entry: Top, Bottom, Left, Right set to text window
Downscroll
lda Bottom ; start at bottom of text window
sta zp
:Next_Row
dec zp
ldy zp ; get current row
lda LOTAB,y ; set up "from" copy address
sta :downmod+1
lda HITAB,y
sta :downmod+2
dec zp ; get previous row address
ldy zp ; set up "to" copy address
lda LOTAB,y
sta ptr
lda HITAB,y
sta ptr+1
ldy Left ; start at left of text window
dey
:Do_Row
iny ; <==== this was the missing INY :)
lda (ptr),y ; get screen byte
:downmod sta $FFFF,y ; store one line down (self modified!)
cpy Right ; finished row?
bne :Do_Row ; nope, keep going
lda Top ; at top of text window?
cmp zp
bne :Next_Row ; nope, do next screen row
Blankline
lda #" " ; fill with spaces character
ldy Left ; start at left of text window
:Blank
sta (ptr),y ; put space there
iny
cpy Right ; finished row?
bne :Blank ; nope, keep going
rts ; ok, finished
(R.NIELSON1, CAT2, TOP8, MSG:56/M530)
>>>>> Russell,
"""""
>> and missing an infinite loop bug :)
<< I KNEW IT!! Ratz!
Hehehe, I've been there too (as you proceed to point out :)
Infact it seems that I'm there again... sigh.
>> The reason the Blankline routine was external was because it was used
>> by the Downscroll _and_ Upscroll routines, which saved valuable bytes in
>> the object code, because I was running low on space.
I suspected that might have been the case originally.
>> You are starting at the Left margin, why would you DEY?
uhm... Dyslexic Register Command Syndrome? ;-)
>> And, you have the to pointers switched, you want to grab data from
>> XtraZP and place at ptr.
Drat! I hate making stupid errors like that... (came about when I changed
your code from self modifying to zpage ptr)
Speaking of "saving valuable bytes"... Using a pair of Zpage locs that are
known to be expendable (instead of self modifying object) comes out several
bytes smaller (and faster by a few cycles too :) The locs that are used by
the monitor's RdKey routine (for the pseudo random number generator) are
free for the taking if you're not making use of them anyway. [a point I
often forget about, so I figure others might miss this too]
Take another look at my entry code... at least I got that part right, it's
tight enough to make a duck float ;-) {s quack}
-Harold
(HAROLD.H, CAT2, TOP8, MSG:57/M530)
>>>>> Harold, using Zpage instead of self-modifying absolute only makes
""""" the code faster if the loop executes just once. On most text
windows, you're executing the loop upwards of 10 times, so saving cycles
in the loop at the expense of the setup code is good from a speed standpoint.
If you really want to crank for speed, I'd recommend two things:
1. use self-modifying absolute for both pointers
This saves you 2
cycles per loop over using Zpage for both, but costs 4 in
setup (1 from each ZP store changed to an absolute store). It breaks even
when the window is 2 wide and wins for anything wider.
2. add "Left" to the pointers and loop from "Right-Left" down to 0
This eliminates a CPY from the loop, saving you 3 cycles times the width of
the window, but costs 15 cycles in setup. It breaks even when the window is 5
wide and wins for anything wider.
These changes would give you a core section that looked something like:
ldx line
clc
lda lotab,x
adc Left
sta labld+1
lda hitab,x
sta labld+2
lda lotab+1,x
adc Left ;carry already clear, from previous ADC
sta labst+1
lda hitab+1,x
sta labst+2
sec
lda Right
sbc Left
tay
lp:
labld: lda $FFFF,y
labst: sta $FFFF,y
dey
bpl lp
Todd Whitesel
(A2PRO.TODDPW, CAT2, TOP8, MSG:58/M530)
>>>>> Todd,
"""""
Nice explanation of execution cycle time and setup/overhead time. Cool
example too. :)
(R.NIELSON1, CAT2, TOP8, MSG:59/M530)
>>>>> I may be off base here, but assuming you have an enhanced //e can't
""""" you turn on the enhanced video firmware (PR#3), issue a CNTL-Q for
40 column screen and use the CNTL-V to scroll down and CNTL-W to scroll
up??
It's been a long time since I played with this but the information is in
the looseleaf "About Your Enhanced Apple IIe: Programmer's Guide" manual
that came with the //e Enhancement kit.
Bob, AF6C
(R.ECKWEILER, CAT2, TOP8, MSG:61/M530)
RESIZING YOUR STACK Hi Assembly Gurus:
"""""""""""""""""""
I have written a couple of CDAs (in Merlin 16+); then I wrote a memory
query utility for GNO/ME THEN I obtained a pre-written GNO/ME mem util
(written in C).
Using these I found that I am using 65%+ of stack under GNO/ME and my
CDAs are using 4K each.
Now the question ... under assembly programs like Merlin 16+, how do I
control the allocated stack size. Ok, how do I do it under ORCA/M as
well!!!
The pragma stacksize give me control under ORCA/C.
The Assembly manuals (Merlin and ORCA/M) mention the defaults BUT not how
to change them.
Thanks in advance!
Doug M.
(D.MITTON, CAT3, TOP4, MSG:113/M530)
>>>>> You override the GS/OS default stack size of 4k by linking a stack
""""" segment into your program. I don't know how to create a stack
segment, though.
for more information about stack/direct-page segments, see pages 38-39 and
476-477 in the _GS/OS Reference_.
(A2PRO.GELAMP, CAT3, TOP4, MSG:114/M530)
>>>>> Doug,
"""""
Here is a piece of code that explains what I've been able to do.
**************************************************
* *
* Linker command file *
* *
**************************************************
typ TOL
lkv 2
asm stuff.s
asm dp.s
lnk stuff.l
sav stuff
knd $12 ;"direct-page/stack" object segment as mentioned
;in Apple IIGS GS/OS Reference manual. Page 37.
lnk dp.l
sav dp
Next file
**************************************************
* *
* Direct page space *
* *
**************************************************
typ TOL
rel
ds $200 ;Makes 2 pages of direct page space
sav dp.L
**************************************************
Next file
**************************************************
* *
* Stuff program *
* *
**************************************************
type TOL
rel
;stuff's stuff
sav stuff.L
**************************************************
Clay
Warning! Opinions will change due to new facts.
Clayburn W. Juniel, III - Effective Software Solutions
clay1@primenet.com
(C.JUNIEL, CAT3, TOP4, MSG:115/M530)
>>>>> And, since you asked, it's pretty much the same under ORCA/M. The
""""" details are in the manual; see the KIND directive on page 328 and
the various kind fields on page 490. You can also do a lot more than just
create a stack segment, and I suspect Merlin can, too.
And now, back to our regularly featured assembler...
Mike Westerfield
(BYTEWORKS, CAT3, TOP4, MSG:116/M530)
>>>>> Thanks for the information on creating a DP segment in Merlin 16+
""""" (and ORCA/M), it was exactly what I was looking for.
One additional point to any other interested parties, make sure you are using
Linker.XL (lkv 2) for the previous examples to work. My installation
defaulted to Linker.GS which was perfect for my CDAs and ProDOS8 stuff but
not for this.
ORCA/M was a little more straight forward to implement once I figured out
what was going on BUT I still don't think I would have gotten either out of
the manual(s). (I know, they are for reference, not tutorial!!!! :-))
Thanks Again!!!
Doug M.
(D.MITTON, CAT3, TOP4, MSG:117/M530)
LINEAR REGRESSION Mike W,
"""""""""""""""""
I'd like to duplicate the curve fit function used by Quick Click Calc in a
small project. On p. 51 of the QCC manual, you give the equation for the
first, second, and third order fits. The third order fit is given as:
2 3
y = A + Bx + Cx + Dx
This looks a lot like a cubic polynomial expression for a spline function
(although the examples I've seen reverse the order of the terms). If this
is a spline function, then what basis matrix are you using? If not, what
are the A B C and D coefficients?
But the manual mentions that this is a "linear regression"--a term I
haven't heard of before. Worse, I can't find it in any of my books,
including a fairly recent college Algebra & Trig textbook. Is it safe to
assume that the coefficients are the dataset's y-values i, i+1, i+2, and
i+3?
Can you help me out?
Michael
(ANIMASIA, CAT11, TOP8, MSG:111/M530)
>>>>> Hi Michael,
"""""
Linear regression is a pretty standard method for finding coefficients
yielding the smallest error between a curve fit and a set of data points. I
could cite a gob of sources, but most of the books I learned from (and
still use) are 20 years old, so you might have trouble finding them. Try
looking through any halfway decent college probability & statistics text,
vurtually any data analysis book for the physical sciences, or a linear
algebra text that is engineering oriented, rather than oriented towards
theoretical mathematics.
I'll try to give you a quick version here, but do try to find the books--
among other things, they will tell you how to figure the error in the fit!
You basically create two matrices. One is a cube; it has the sum of the
independent variable (x in most notations) raised to various powers. The
power starts at 0 in the top left position, and you add one across the
top row and left column. The power for the interior values is the sum of
the power to the top and left. So, showing only the powers in the
correct spot, the cubic array looks like this (ASCII is a pain for matrices
with powers; write it on a sheet of paper :)
0 1 2 3 4 ...
1 2 3 4 5
2 3 4 5 6
3 4 5 6 7
4 5 6 7 8
You can keep going as long as you like. The matrix I've shown is for a 4th
order polynomial fit. To actually calculate the terms, you sum the
values raised to the power I've shown. Since I can't use mathematical
notation, I'll use Pascal. :) In this case, all of the values are
stored in two arrays, x[size] and y[size]. So to compute the value for 4
in the array, you would sum all of the x values raised to the 4th power,
like this:
s4 := 0.0;
for i := 1 to size do
s4 := s4 + sqr(sqr(x[i]));
The second array is a column (or a vector). It's the sum of the
dependent variable times a power of the independent variable. The powers
for the independent variable are the same as for the left column of the
square matrix. Calculating the third term down would go something like
this:
sy2 := 0.0;
for i := 1 to size do
sy2 := sy2 + y[i]*sqr(x[i]);
There is a third matrix; it contains the coefficients for the polinomial.
From the manual, that's A, B, C, etc. It's a column, too, just like the
second one. The last step is to combine these equations into a matrix
equality. Calling the square one S, the coefficients c, and the second
matrix with the x and y powers n, the equation is
Sc = n
You solve this set of simultaneous equations for the coefficients. For
higher or lower order polinomials, simply adjust the size of the matrices.
CAUTION: The equations are not well behaved. You can get numerical
'''''''' errors, like divide by zero, with many off the shelf equation
solvers. Guard for that!
Finally, if this didn't make much sense, rest assured that it's a lot
easier with a blackboard or book, where you can use matrix notation,
powers, and summation signs. :) If this confused you, find a discussion
in a book.
Mike Westerfield
(BYTEWORKS, CAT11, TOP8, MSG:112/M530)
<<<<< Mike--
"""""
Excellent overview! I actually understood your ASCII power notation matrice
and your Pascal sources, which is not surprising because I remember your
Call -APPLE articles being so well written. I feel I have a much better
idea of what I have to work towards than before. However, I still don't see
how the three matrices relate to eachother to produce the results that they
do. So it looks like I'm going to stop at the university library tomorrow
to investiage your sources; "data analysis for physcial sciences" sounds
like a good bet. I'll let you know how it works out. Thank you!
Michael
(ANIMASIA, CAT11, TOP8, MSG:113/M530)
>>>>> Hi Michael,
"""""
If you got everything but how to solve the matrix equation, concentrate
on linear algebra books. In fact, you might even want to find one of those
encyclopedia sized books on engineering mathematics that I assume are still
used to cover 4-6 math courses in an engineering curriculum. Concetrate on
simultaneous solutions to multiple equations, which is what you are
actually doing.
Once you get to the point where you're actually doing it, switch to a
good introductory text on numerical analysis, or check out something like
Sedgewick's Algorithms book. All will have better methods for actually
solving the matrix equations than the math books are likely to show,
since the methods that work well on a computer are a little different
from the ones that work well by hand.
Mike Westerfield
(BYTEWORKS, CAT11, TOP8, MSG:114/M530)
<<<<< Mike,
"""""
I spent the better part of the day at the library looking through the types
of books you suggested. You were right; there are tons of books which cover
linear regression in many different fields. Some good. Some bad. I
backtracked and began investigating how to find the closest fit to a first
order function and even that slowed me down. Not surprisingly, I found
myself having to relearn much of the matrix operations for solving
simultaneous solutions. So it looks like I'll have to go back and start
from the beginning. I'll check into "Sedgewick's Algorithms" too. Still,
I'm enjoying this because it's no longer abstract theory.
Michael
(ANIMASIA, CAT11, TOP8, MSG:115/M530)
>>>>> Cool. FWIW, linear regression was the first thing I ever did with
""""" a matrix (back in high school) and it remains one of the most-used,
and IMHO, most usefull things I've ever done with a matrix. :) And in
physics and math, I've seen quite a few matricies.
Mike Westerfield
(BYTEWORKS, CAT11, TOP8, MSG:116/M530)
>>>>> One book that covers this subject fairly well is _Advanced
""""" Engineering Mathematics_ by Erwin Kreyszig. It's an older college
text book (1964 - fourth edition) but should be able to be found in used
book stores. What I like about this book is that it contains a lot of
practical examples instead of just dry theory.
Another book that may be of interest is "BASIC Computer Programs in Science
and Engineering" by Jules Gilder 1980 (A Hayden PaperBack). It is full of
BASIC programs. Chapter 4 is "Matrix Mathematics" and Chapter 5 is "Data
Analysis" including linear a least-squares fit and various logarithmic
least-squares fit programs
In the seventies and early eighties I wrote many programs on a Tektronix
4054 desktop computer. It had built-in matrix functions and you could
solve multiple equations with multiple unknowns with one BASIC call.
Bob, AF6C
(R.ECKWEILER, CAT11, TOP8, MSG:117/M530)
BEZIER CURVES Speaking of least-squares fit algorithms, I once had an
""""""""""""" interest in how Bezier curves were drawn. You know, a
spline curve where the points can be unordered in both the X and Y axes.
I wanted to, given a completely random set of points, draw a smooth curve
through the points.
Best I ever came up with was limited. The method would only work if the X
(or Y) coordinates were listed in order (increasing or decreasing).
Does anyone know how these are computed? I know it can be done, because I've
seen it in some paint/draw programs.
...Chris
(K.FLYNN, CAT11, TOP8, MSG:120/M530)
>>>>> Chris,
"""""
Bezier curves are pretty easy to draw once you know how it's done. The
simplest Bezier curve has four points: two endpoints and two handle points
which define the shape of the curve. Image that the following four points
will create a smooth Bezier curve. ep is endpoint and hp is handle point.
hp1
ep1
ep2
hp2
When a Bezier curve is drawn, the drawing algorithm starts drawing from the
first endpoint, ep1, toward the first handle point, hp1, but never actually
touches hp1 because as it goes along, it begins to head toward the next
handle point, hp2. Again, the curve doesn't touch hp2 because it heads
toward the last endpoint, ep2. The curve therefore touches the endpoints
but only heads toward the handle points. The handle points are called
handles because if you drag these handles around, you'll change the shape
of the curve. These are the curves that Postscript uses for its foundation;
same for most any illustration program.
There are two ways you can draw a Bezier curve. The first is to say that a
variable t will be increased from 0 to 1 over series of steps and a basis
matrice function will be solved for x and y with t. You simply connect the
x and y's as you increment t. This is slow and entirely too precise for
drawing on the screen.
The second way is much faster because it recursively splits the Bezier
curve into two smaller Bezier curves until the curves become straight
enough to be approximated by lines. This only uses shifts and adds and
you'll find the source code to this below.
Still, you wanted to know how to connect a whole series of points. That's
easy too. To lengthen a Bezier curve, add three more points: two handles
and an endpoint. Because the last endpoint of the first Bezier is the first
endpoint of the second Bezier, that endpoint is reused. So you need to have
"(curves * 3) + 1" points. Another thing to keep in mind is that to have
the overall Bezier curve look smooth between adjacent sub-curves requires
you to position the two handles on either side of an endpoint to line up in
a straight line across the endpoint. Otherwise, you'll have a sharp bend in
your curve, (which may be what you want too).
However, this won't _completely_ solve your problem because you
specificially wanted to have this curve pass through _all_ of your points.
Well, a Bezier curve, like I mentioned, only passes through the endpoints
but not the handles. There are different types of curves, and the one you
would want to use to pass through all points is a Catmull-Rom curve, which
are harder to draw than Bezier curves because you can't as easily subdivide
them.
But don't let that discourage you because Bezier curves are great and if
you can get them to work (no problem) you're on your way to creating an
illustration program for the GS :)
Michael
(This C source code is old and doesn't use the bit shift operator to divide
by two. This is because I assumed there was a problem with the way Orca/C
generated code if it tried to bit shift a negative number. I wanted to use
negatives because I wanted to have a Cartesian coordinate plane, but this
could easily be solved if you use only the positve quadrant of the plane,
such as screen coordinates. Also, it refers to endpoints as control
points.)
#include <types.h>
#include <quickdraw.h>
#define BezDepth 4 /* greater the depth, the smoother the curve */
#define NumBezPts 17 /* must be >= 2^BezDepth + 1 */
/* It's important to note that increasing BezDepth
makes smoother curves--up to a point. We reach
diminishing returns in increasing BezDepth too
much, since the accumulated error of repeated
averaging eventually throws the calculations off
by one or more pixels. This could be soved by
using fixed point math. */
typedef struct {int top, left, bottom, right;} rect2, *rect2ptr;
typedef struct
{int x, y;} intVector2, intPoint2, *intVector2ptr, *intPoint2ptr;
intPoint2 bezPts [NumBezPts];
intPoint2ptr bezPtsPtr;
int xCenter, yCenter;
void SubdivideBezier (intPoint2 p0, intPoint2 p1, intPoint2 p2, intPoint2
p3, int depth);
void DrawBezier (intPoint2 ctrl1, intPoint2 hand1, intPoint2 hand2,
intPoint2 ctrl2);
void main (void)
{
rect2 viewPort;
intPoint2 ctrl1, hand1, hand2, ctrl2;
/* Define Bezier curve's points: */
ctrl1.x = -100; ctrl1.y = 0; /* Cartesian coordinates */
hand1.x = -30; hand1.y = 60;
hand2.x = 10; hand2.y = -80;
ctrl2.x = 100; ctrl2.y = 0;
GetPortRect ((RectPtr) &viewPort);
xCenter = (viewPort.left + viewPort.right) / 2;
yCenter = (viewPort.top + viewPort.bottom) / 2;
SetPenSize (2, 1);
SetPenMode (modeCopy);
SetSolidPenPat (0);
DrawBezier (ctrl1, hand1, hand2, ctrl2);
/* Draw handles as dots: */
MoveTo (hand1.x + xCenter, yCenter - hand1.y);
LineTo (hand1.x + xCenter, yCenter - hand1.y);
MoveTo (hand2.x + xCenter, yCenter - hand2.y);
LineTo (hand2.x + xCenter, yCenter - hand2.y);
}
void DrawBezier (intPoint2 ctrl1, intPoint2 hand1, intPoint2 hand2,
intPoint2 ctrl2)
{
int i;
bezPtsPtr = bezPts;
*bezPtsPtr++ = ctrl1;
SubdivideBezier (ctrl1, hand1, hand2, ctrl2, BezDepth);
MoveTo (bezPts [0].x + xCenter, yCenter - bezPts [0].y);
for (i = 1; i < NumBezPts; i++)
LineTo (bezPts [i].x + xCenter, yCenter - bezPts [i].y);
}
void SubdivideBezier (intPoint2 p0, intPoint2 p1, intPoint2 p2, intPoint2
p3, int depth)
{
intPoint2 q0, q1, q2, r0, r1, s0;
int x, y;
if (!depth)
{
*bezPtsPtr++ = p3;
return;
}
q0.x = (p0.x + p1.x) / 2; q0.y = (p0.y + p1.y) / 2;
x = q0.x; y = q0.y;
q1.x = (p1.x + p2.x) / 2; q1.y = (p1.y + p2.y) / 2;
x = q1.x; y = q1.y;
q2.x = (p2.x + p3.x) / 2; q2.y = (p2.y + p3.y) / 2;
x = q2.x; y = q2.y;
r0.x = (q0.x + q1.x) / 2; r0.y = (q0.y + q1.y) / 2;
x = r0.x; y = r0.y;
r1.x = (q1.x + q2.x) / 2; r1.y = (q1.y + q2.y) / 2;
x = r1.x; y = r1.y;
s0.x = (r0.x + r1.x) / 2; s0.y = (r0.y + r1.y) / 2;
x = s0.x; y = s0.y;
SubdivideBezier (p0, q0, r0, s0, --depth); /* subdivide into left half */
SubdivideBezier (s0, r1, q2, p3, depth); /* subdivide into right half */
}
(ANIMASIA, CAT11, TOP8, MSG:121/M530)
>>>>> Oh yeah. I forgot to mention that to compile and use the code you
""""" can use Prizm's Graphics Output window. Just open that window and
choose Compile to Memory. It's best to make the Graphics Output window as
big as it can be (Mike- the zoom box on that window doesn't do anything.)
Also, the curve won't look stunningly smooth because of the accumulated
division error inherent in integer math. You'll need to use fixed-point
math to get perfectly smooth curves.
Michael
(ANIMASIA, CAT11, TOP8, MSG:122/M530)
>>> MESSAGE SPOTLIGHT <<<
"""""""""""""""""""""""""""
~ Important or Interesting Messages ~
65816 IN AN ATARI? Greetings! I've got a 65816 transplanted into my
"""""""""""""""""" 8-bit Atari (please no flames) and was searching here
for some 65816 assembler examples. This seems to be the biggest collection
of '816 programmers on GEnie; what can you point to? I've programmed for
over 10 years on the 6502, and was looking for fast signed multiply
routines, etc. Also, since everything here is ".BXY", can anyone suggest a
path to some other archive format like ARC or LZH? Thanks in advance...
(JDPOTTER, CAT3, TOP19, MSG:138/M530)
>>>>> JDPOTTER,
"""""
>> I've got a 65816 transplanted into my 8-bit Atari (please no flames) and
>> was searching here for some 65816 assembler examples.
Hey, no flames from me! How did you get the 816 in the Atari anyway? (by
leaving pin 1 out of the socket?? That's what I did on my IIc, works great!
:))
Most likely most of the source you'll find here for 816's will be for the
Apple IIgs, which won't do you tooo much good... (the IIgs has a "toolbox"
(part rom, part in the OS) that covers a =lot= of ground... math routines
included.)
>> Also, since everything here is ".BXY", can anyone suggest a path to some
>> other archive format like ARC or LZH? Thanks in advance...
Chances are if some file or other (or more than one :) sounds like a likely
candidate for what you're looking for it could be unpacked by one of the
folks around here and either emailed to you that way, or maybe packed up
using another method... (I think there's a utility around somewheres for
producing ARC files on an Apple II)
-Harold
(HAROLD.H, CAT3, TOP19, MSG:139/M530)
>>>>> There's also a MS-DOS utility to unpack .BXY and .SHK archives
""""" (both ShrinkIt archives), if that's of any help to you.
Doug
"As Canadian as possible under the circumstances."--Heather Scott
(EDITOR.A2, CAT3, TOP19, MSG:140/M530)
>>>>> There are some fast math routines for signed and insigned 2, 4 and
""""" 8 byte integer math in the ORCA/M package. The source code is
available separately as GS-13 ORCA/Sublib Source $25, available from Byte
Works. The files are ASCII files with the SRC file type stamp. The biggest
problem you would face is getting the files from the Apple IIGS 3.5" disk
they ship on to your computer. A friend with an Apple ][ or Mac can help.
If you're interested, let me know. I can send you a catalog; you can at
least get an idea what we have. I'll need your mailing address if you want
the catalog.
Mike Westerfield
(BYTEWORKS, CAT3, TOP19, MSG:141/M530)
<<<<< Harold.H, I got the 65816 from the guy who bought the rights to all
""""" ICD Atari 8-bit products. It's the 65C816 and a PAL mounted in a
socket, plugs directly into my 6502 socket. I saw some interesting code
tips in the "Optomeisters" topic. I'm really looking for a 16 x 16 -> 32
bit signed multiply; I was able to adapt some of their fast routines, but
would like to see more. Thanks.
Jeff
(JDPOTTER, CAT3, TOP19, MSG:142/M530)
>>>>> Jeff,
"""""
> I'm really looking for a 16 x 16 -> 32 bit signed multiply
You might want to check out the "Apple Assembly Lines" archives in the
libraries. They have some _excellent_ articles w/source on all sorts of
algorithms such as various sized multiples. (They even have a 8 x 8 -> 16
bit multiply that executes in 65 cycles!) Search on "AAL" for all the
issues, or "multiply" or "multiplication" for the ones you need.
Michael
(ANIMASIA, CAT3, TOP19, MSG:143/M530)
[*][*][*]
While on GEnie, do you spend most of your time downloading
files? If so, you may be missing out some excellent
information in the Bulletin Board area. The messages listed
above only scratch the surface of what's available and
waiting for you in the bulletin board area.
If you are serious about your Apple II, the GEnieLamp staff
strongly urges you to give the bulletin board area a try.
There are literally thousands of messages posted from people
like you from around the world.
[*][*][*]
[EOA]
[DEV]//////////////////////////////
DEVELOPER'S CORNER /
/////////////////////////////////
News From The A2Pro Online Developers
"""""""""""""""""""""""""""""""""""""
By Tim Buchheim
[A2PRO.GELAMP]
o ONLINE SUPPORT IN A2Pro
o EDIT-16 SUPPORT
o USING THE GNO SHELL
o THE SPLAT! SOURCE LEVEL DEBUGGER
>>> ONLINE SUPPORT IN A2Pro <<<
"""""""""""""""""""""""""""""""
CAT TOP COMPANY
=== === =======
29 INDEPENDENT DEVELOPERS ONLINE
2 DYA/DigiSoft Innovations Online
8 Simplexity Software Online
14 Quality Computers Q-LABS Online
20 DreamWorld Software Online
26 METAL/FV Software Online
32 Kitchen Sink Software Online
38 EdIt-16 (Bill Tudor)
30 PROCYON, INC.
31 SOFTDISK PUBLISHING
33 GS+ MAGAZINE
34 JEM SOFTWARE
35 PRODEV, INC.
36 THE BYTE WORKS
Each month this column feature highlights and news from various
developers who provide support via A2Pro.
>>> EDIT-16 SUPPORT <<<
"""""""""""""""""""""""""
EDIT-16 REQUEST Bill,
"""""""""""""""
Is there anything new to report about Edit-16 or are no more updates planned?
My only real desire is to have it handle files larger than 64k. Other than
that, I can't think of a thing. And if no further improvements are planned, I
can understand that.
Bob
(R.FISCHER7, CAT29, TOP38, MSG:108/M530)
>>> USING THE GNO SHELL <<<
"""""""""""""""""""""""""""""
SWITCHING PROCESSES How do you switch processes in GNO? I've found the
""""""""""""""""""" GNO shell to be very confusing. Is Edit-16
compatible? I haven't been able to get it to work with the shell yet. Any
help would be appreciated!
Brian Gillespie, Jaunt! Software
(B.GILLESPIE3, CAT30, TOP2, MSG:193/M530)
<<<<< I've learned some more about switching processes, but how do you
""""" switch out of the ORCA editor? It eats the Control-Z keypress.
Thanks!
Brian Gillespie, Jaunt! Software
(B.GILLESPIE3, CAT30, TOP2, MSG:194/M530)
>>>>> You need to set the auxtype of the ORCA editor to something (I
""""" think $DC00 but it should be in the GNO docs somewhere, so don't
trust me, trust them) to tell GNO it needs to handle the input stuff
differently. Maybe someone else here can tell us just what it does
differently?
Todd Whitesel
(A2PRO.TODDPW, CAT30, TOP2, MSG:196/M530)
>>>>> From the GNO Shell User's Manual (Appendix E, Non-Compliant
""""" applications, page 50): "Setting the auxtype of an application to
$DC00 disables the interrupt driven keyboard buffering and turns off the
GNO/ME cursor. Desktop programs use the GNO/ME keyboard I/O via the Event
Manager, and thus should NOT have their auxtype changed."
However, I always thought EXE (and S16) files were supposed to follow the
FTN that details the $DBxx auxtype. The ORCA editor has an auxtype of $DB01
(at least mine does.)
- Tony
(A2.TONY, CAT30, TOP2, MSG:197/M530)
>>>>> >However, I always thought that EXE (and S16) files were supposed
""""" >to follow the FTN that details the $DBxx auxtype.
They are. :) But when you use a S16 or EXE program in GNO, it is being
loaded and executed by GNO itself with direct calls to the System Loader
toolset..
Only _QuitGS looks for that $DBxx in the auxtype.. since GNO isn't loading
the program through _QuitGS, it can require the auxtype to be whatever it
needs. (I assume that it properly handles the defined bits in a $DBxx
auxtype, though.)
Note that GNO doesn't require any weird auxtypes for desktop programs.. so
leave them set to whatever is appropriate for the specific app.
(A2PRO.GELAMP, CAT30, TOP2, MSG:198/M530)
>>>>> > Only _QuitGS looks for that $DBxx in the auxtype..
"""""
Okay, so there's no harm in changing EXE auxtypes for files that run on a
shell from $DB01 to $DC00 (ie. the ORCA editor.) However, I wouldn't want
to change a S16 auxtype like that unless I only plan on running the program
from the shell, right?
- Tony
(A2.TONY, CAT30, TOP2, MSG:199/M530)
>>>>> right, although I would assume that most S16 programs you use
""""" aren't text programs, and therefore wouldn't need any auxtype
changes. (Programs that use the Event Manager, such as desktop programs,
work fine in GNO, from what I understand.. but I don't have GNO, so I can't
be sure. :)
(A2PRO.GELAMP, CAT30, TOP2, MSG:200/M530)
>>>>> You can't change the auxtype of a S16 file to $DC00 if the file is
""""" on an HFS volume, due to the way the HFS FST maps between ProDOS
and HFS types. (At least, not the standard GS/OS way. Don't know if you
can get around it by mucking with the optionList.)
(S.REEVES2, CAT30, TOP2, MSG:202/M530)
>>>>> huh? why can't you change the auxtype of a S16 file on an HFS
""""" volume? A S16 file with an auxtype of $DC00 would have a creator
type of "pdos" and a file type of "p" $B3 $DC $00
(A2PRO.GELAMP, CAT30, TOP2, MSG:203/M530)
>>>>> The HFS FST won't preserve a non-zero auxtype of a S16 file unless
""""" it starts with $DB (this is described on page 334 of the
Programmer's Reference for System 6.0). It seems you can set it to $DC00
by directly changing the Mac filetype to "p" $B3 $DC $00 (via the
optionList), but you must do this manually. GNO's standard chtyp command
won't do it for you.
(S.REEVES2, CA30, TOP2, MSG:204/M530)
>>>>> yuck. that's stupid. :(
"""""
(A2PRO.GELAMP, CAT30, TOP2, MSG:205/M530)
>>> THE SPLAT! SOURCE LEVEL DEBUGGER <<<
""""""""""""""""""""""""""""""""""""""""""
USING SPLAT! Hi, I have two questions related to Splat!
""""""""""""
1.) I have searched the manual cover to cover trying to figure out how to
display strings in hex in the variables window/dialog a la the 'mem'
command does in the ORCA debugger. I am manipulating text, control
characters and NULL's in char arrays and would like to see the changes
in hex while stepping through the program. Can I do this with Splat!?
Currently I am using Splat! for debugging program control but switch
over to ORCA debugger to watch the changes in the arrays because I can
only get the ascii text in double quotes using Splat!.
Which brings me to question 2.
2.) Are there any known problems having Splat! and ORCA debugger in the
ORCA shell at the same time. So far I haven't noticed any problems but
I would like to know ahead of time what to watch out for.
My setup has the 'shell' version of Splat! installed in ORCA/shell 2.x, and
the ORCA/Debugger init and debugger utilities installed. I use a script to
run ORCA/D. I 'cmpl +d {program}.cc keep={program}' once, and type 'splat
{program}' to use Splat! or 'debug {program}' to use the ORCA/D.
This, so far, works ok (my programs are ANSI C, text display only, no
toolbox) but I prefer Splat!'s interface to ORCA/D's and want to save the
hassle of jumping from one to the other.
Thanx.
Eric Heim
(of course, by using both there is no spent money wasted :)
(E.HEIM3, CAT30, TOP9, MSG:31/M530)
>>>>> Eric,
"""""
I'm not familiar with Orca/Debugger's mem command, but I'm afraid you can't
do what you're asking for (showing characters as hex) in Splat! at this
time. I believe unprintable characters show up either as octal or hex
(it's been a while since I've used it much) but I know that's not what
you're after.
I don't know imagine there would be any problems with the setup you are
running (Orca INIT and Splat! shell version), but it's not something that
I've ever tested and certainly don't guarantee. If it works, then it
works. And until there's a major upgrade to Splat! (don't ask), I guess
you'll have to continue to use both to get what you want. Sorry.
Mike Hackett
(M.HACKETT, CAT30, TOP9, MSG:32/M530)
<<<<< Hi Mike H.,
"""""
Don't be sorry, Splat! is great. ORCA/Debugger is great. I'm glad I
have both. I was just hoping that Splat! had EVERYTHING to save a little
time while trying to fix my latest 'index past the end of array' ;-)
Eric Heim
(E.HEIM3, CAT30, TOP9, MSG:33/M530)
>>>>> Eric,
"""""
> display strings in hex in the variables
Well it *is* possible, but it doesn't look pretty...
Here is a way to see 4 characters in hex from a string. The text characters
are stored in a pointer that doesn't really point to anything. Pointers are
displayed in their hex values. The hex values can also be displayed in
the output window.
Look at BadAddress to see the 4 chars displayed in hex, not what it
points to. It doesn't really point anywhere.:)
#pragma keep "Program"
#pragma debug -1
#include <stdio.h>
#include <string.h>
struct StringPlus
{
char SPlus[10];
};
void main (void)
{
struct StringPlus ASP;
unsigned int x;
/* Declare address and set to unique numbers */
unsigned char *BadAddress;
asm {
lda #0xFFFF
sta BadAddress+2
lda #0xFFFF
sta BadAddress
}
strcpy(ASP.SPlus, "5678\n");
ASP.SPlus[6] = 0;
for(x=0;x<10;x++) {
/* Notice ordering to keep string characters lined up */
/* Copy string characters to the hex address for hex display */
asm {
lda ASP
sep #0x20
sta BadAddress+3
rep #0x20
}
asm {
ldx #1
lda ASP,x
sep #0x20
sta BadAddress+2
rep #0x20
}
asm {
ldx #2
lda ASP,x
sep #0x20
sta BadAddress+1
rep #0x20
}
asm {
ldx #3
lda ASP,x
sep #0x20
sta BadAddress
rep #0x20
}
/* Increment string chars for viewing change */
ASP.SPlus[0]++;
ASP.SPlus[1]++;
ASP.SPlus[2]++;
ASP.SPlus[3]++;
/* Display some of string in hex in output window */
printf(" Hex=%X, %X\n", ASP.SPlus[0], ASP.SPlus[2]);
}
exit(0);
}
More chars can be copied into more hex addresses for display,
but this can be used to view some important ones.
- James - [IMAGE]
(J.GRAY38, CAT30, TOP9, MSG:34/M530)
<<<<< James,
"""""
Thanx for your reply.
Actually, my interest in looking at the hex in the string was purely for
debugging purposes. This particular function is a filter for raw data
and somehow (thanks to Splat! and ORCA/Debugger I found the problem) it
was indexing past the end of an array under certain conditions. The array
is part of a structure and the next element was a pointer that would get
blasted when the indexing went too far. Easy to fix once I saw what was
happening :)
Eric Heim
(E.HEIM3, CAT30, TOP9, MSG:35/M530)
[EOA]
[LIB]//////////////////////////////
LIBRARY BIT BONANZA /
/////////////////////////////////
HOT Files You Can Download
""""""""""""""""""""""""""
By Tim Buchheim
[A2PRO.GELAMP]
o GREAT NEW FILES!
>>> GREAT NEW FILES! <<<
""""""""""""""""""""""""""
File #4871 MTL.PUB.SRC.BXY (ALL)
Uploaded on 10/28/95 by JUST.DAVE
About 124K (d/l time approx. 9 minutes @ 2400 baud)
This file is part of the release of METAL v1.09.07.
It contains the source code that was released with METAL v1.09.07.
Read MTL7.README.TXT (file #25957) in the A2 library for details.
File #4870 FOREACH.BXY (GS)
Uploaded on 10/19/95 by S.REEVES2
About 13K (d/l time approx. 1 minute @ 2400 baud)
This is a version of the UNIX shells' built-in "foreach" construction, for
iterating a series of commands over different values of a variable. It was
written by Sean McAfee (mcafee@umich.edu). Requires an Apple IIgs and
GNO 2.0 or higher (works with ORCA/Shell 2.0 too, but ORCA already has an
equivalent command).
File #4868 REZTHINGY.BXY V1.0B2 (GS)
Uploaded on 10/15/95 by B.WELLS5
About 5K (d/l time under 1 minute @ 2400 baud)
This Spectrum script will allow you to name resources in your REZ source
code and then run the script to generate all the rName resources for each
'named' resource. Cool, eh? :) This is just a very quick hack, so the
only documentation is what appears when you run the script. An example
REZ file is also included.
File #4867 HTMLEDIT.BXY (GS)
Uploaded on 10/14/95 by C.STILES3
About 81K (d/l time approx. 5 minutes @ 2400 baud)
Obtained from the Internet - source is Nova Scotia user group. See the
description on A2 for more info, or just donload it and extract the info.
Promotes the use of HTML. No doc file, but help button is available.
File #4864 PRSET1.0B1.BXY (GS)
Uploaded on 10/1/95 by R.ECKWEILER
About 19K (d/l time approx. 1 minute @ 2400 baud)
PRSet is an ORCA utility that allows configuring the .PRINTER driver
directly from the ORCA command line or from an exec file. By putting a
PRSET command in the LOGIN file for ORCA the printer may be configured
automatically each time ORCA is run. The program allows you to set all the
parameters normally set by the CDA or CDEV programs and has extensive
printer initialization string inputting capabilities.
[EOA]
[LOG]///////////////////////////////
LOG OFF //
//////////////////////////////////
GEnieLamp Information
"""""""""""""""""""""
o COMMENTS: Contacting GEnieLamp
o GEnieLamp STAFF: Who Are We?
GEnieLamp Information GEnieLamp is published on the 1st of every month
""""""""""""""""""""" on GEnie page 515. You can also find GEnieLamp on
the main menus in the following computing RoundTables.
RoundTable Keyword GEnie Page RoundTable Keyword GEnie Page
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
DigiPub DIGIPUB 1395 Atari ST ST 475
Macintosh MAC 605 IBM PC IBMPC 615
Apple II A2 645 Apple II Dev. A2PRO 530
Macintosh Dev. MACPRO 480 Geoworks GEOWORKS 1050
BBS BBS 610 CE Software CESOFTWARE 1005
Mini/Mainframe MAINFRAME 1145 Programming PROGRAMMING 1445
Data Comm. DATACOMM 1450 IBM PC Prog IBMPCPRO 617
PowerPC PPC 1435 PowerPCProg PPCPRO 1440
GEnieLamp is also distributed on CrossNet and many public and
commercial BBS systems worldwide.
o To reach GEnieLamp on Internet send mail to genielamp@genie.com
o Back issues of GEnieLamp are available in the DigiPub RoundTable
Library #2 on page 1395 (M1395;3). Internet users should use
the GEnie gopher (gopher.genie.com) which has most back issues
(but might be missing a few of them). After you connect to
gopher.genie.com, choose the "Magazines and newsletters" item
and then choose the menu item for the Apple II.
o GEnieLamp pays for articles submitted and published with online
GEnie credit time. Upload submissions in ASCII format to library
#31 in the DigiPub RoundTable on page 1395 (M1395;3) or Email it to
GENIELAMP. On Internet send it to: genielamp@genie.com
o We welcome and respond to all E-Mail. To leave comments,
suggestions or just to say hi, you can contact us in the DigiPub
RoundTable (M1395) or send GE Mail to John Peters at [GENIELAMP] on
page 200.
o If you would like to meet the GEnieLamp staff "live" we meet every
Wednesday night in the Digi*Pub Real-Time Conference at 9:00 EDT
(M1395;2).
o The Digital Publishing RoundTable is for people who are interested
in pursuing publication of their work electronically on GEnie or via
disk-based media. For those looking for online publications, the
DigiPub Software Libraries offer online magazines, newsletters,
short-stories, poetry and other various text oriented articles for
downloading to your computer. Also available are writers' tools and
'Hyper-utilties' for text presentation on most computer systems. In
the DigiPub Bulletin Board you can converse with people in the
digital publishing industry, meet editors from some of the top
electronic publications and get hints and tips on how to go about
publishing your own digital book. The DigiPub RoundTable is the
official online service for the Digital Publishing Association. To
get there type DIGIPUB or M1395 at any GEnie prompt.
>>> GEnieLamp STAFF <<<
"""""""""""""""""""""""
GEnieLamp o John Peters [GENIELAMP] Publisher
""""""""" o Mike White [MWHITE] Managing Editor
APPLE II o Doug Cuff [EDITOR.A2] EDITOR
"""""""" o Ray Pasold [R.PASOLD] A2 Staff Writer
o Charlie Hartley [A2.CHARLIE] A2 Staff Writer
A2Pro o Tim Buchheim [A2PRO.GELAMP] EDITOR
"""""
ATARI o Sheldon H. Winick [GELAMP.ST] ATARI EDITOR
""""" o Bruce Smith [B.SMITH123] EDITOR/TX2
o Mel Motogawa [M.MOTOGAWA] Atari Staff Writer
o Richard Brown [R.BROWN30] Atari Staff Writer
o Al Fasoldt [A.FASOLDT] Atari Staff Writer
o Timothy V. Steed [T.STEED1] Atari Staff Writer
o Lloyd E. Pulley [LEPULLEY] Atari Staff Writer
IBM o Sharon La Gue [SHARON.LAMP] IBM EDITOR
""" o Tika Carr [LAMP.MM] MULTIMEDIA EDITOR
o Susan M. English [S.ENGLISH1] Multimedia Graphics Artist
o Wayne & Chris Ketner[C.KETNER] IBM Staff Writers
MACINTOSH o Richard Vega [GELAMP.MAC] MACINTOSH EDITOR
""""""""" o Tom Trinko [T.TRINKO] Mac Staff Writer
o Bret Fledderjohn [FLEDDERJOHN] Mac Staff Writer
o Ricky J. Vega [GELAMP.MAC] Mac Staff Writer
POWER PC o Ben Soulon [BEN.GELAMP] POWER PC EDITOR
"""""""" o Eric Shepherd [SHEPPY] Power PC Staff Writer
WINDOWS o Bruce Maples [GELAMP.WIN] EDITOR
""""""" o Tika Carr [LAMP.MM] Windows Staff Writer
ETC. o Jim Lubin [J.LUBIN] Add Aladdin Scripts
"""" o Scott Garrigus [S.GARRIGUS] Search-ME!
o Mike White [MWHITE] (oo) / DigiPub SysOp
o John Peters [GENIELAMP] DigiPub SysOp
o Phil Shapiro [P.SHAPIRO1] Contributing Columnist
o Sanford E. Wolf [S.WOLF4] Contributing Columnist
o Douglas Parks [DELUXE] Contributing Columnist
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////////
Opinions expressed herein are those of the individual authors, and do
not necessarily represent opinions of GEnie Information Services,
GEnieLamp Online Magazines, or T/TalkNet Online Publishing. Bulletin
board messages are reprinted verbatim, and are included in this publi-
cation with permission from GEnie Information Services and the source
RoundTable. GEnie Information Services, GEnieLamp Online Magazines,
and T/TalkNet Publishing do not guarantee the accuracy or suitability
of any information included herein. We reserve the right to edit all
letters and copy.
Material published in this edition may be reprinted under the fol-
lowing terms only. Reprint permission granted, unless otherwise noted,
to registered computer user groups and not for profit publications.
All articles must remain unedited and include the issue number and
author at the top of each article reprinted. Please include the fol-
lowing at the end of all reprints:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////
The preceeding article is reprinted courtesy of GEnieLamp Online
Magazine. (c) Copyright 1995 T/TalkNET Publishing and GEnie Infor-
mation Services. Join GEnie now and receive $50.00 worth of online
credit. To join GEnie, set your modem to 9600 baud (or less) and half
duplex (local echo). Have the modem dial 1-800-638-8369 in the United
States or 1-800-387-8330 in Canada. When you see the U#= prompt,
type: JOINGENIE and hit the RETURN key. When you get the prompt
asking for the signup code, type DSD524 and hit RETURN. GEnie will
then ask you for your signup information. For more information call
(voice) 1-800-638-9636.
////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
[EOF]
ÿÿ
.
