Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4888 > unrolled thread

IIGS - Linear mapping?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  IIGS - Linear mapping? paul.s.macmillan@gmail.com - 2018-11-06 11:11 -0800
    Re: IIGS - Linear mapping? James Davis <JPD.Enterprises@outlook.com> - 2018-11-07 00:06 -0800
      Re: IIGS - Linear mapping? kegs@provalid.com (Kent Dickey) - 2018-11-07 08:23 -0600
        Re: IIGS - Linear mapping? John Brooks <jbrooks@blueshiftinc.com> - 2018-11-07 08:35 -0800
          Re: IIGS - Linear mapping? kegs@provalid.com (Kent Dickey) - 2018-11-07 23:29 -0600
            Re: IIGS - Linear mapping? John Brooks <jbrooks@blueshiftinc.com> - 2018-11-08 15:14 -0800
              Re: IIGS - Linear mapping? Dagen Brock <dagenbrock@gmail.com> - 2018-11-09 02:03 -0800
                Re: IIGS - Linear mapping? John Brooks <jbrooks@blueshiftinc.com> - 2018-11-09 14:53 -0800
              Re: IIGS - Linear mapping?  <leonb@novabbs.i2p> - 2020-01-24 22:07 +0000
              Re: IIGS - Linear mapping?  <leonb@novabbs.i2p> - 2020-01-24 22:29 +0000
                Re: IIGS - Linear mapping? Antoine Vignau <antoine.vignau@laposte.net> - 2020-01-24 20:15 -0800

#4888 — IIGS - Linear mapping?

I have seen several references to an option to make the Super Hi-Res memory linear. (Example p. 87 of Apple_Technical_Introduction_to_the_Apple_IIGS). But I am confused by this because its already linear... what does this option actually do? Bit 6 of the New Video register.  How can it be any more linear than it already is?

[toc] | [next] | [standalone]

#4889

On Tuesday, November 6, 2018 at 11:11:37 AM UTC-8, paul.s.m...@gmail.com wrote:
> I have seen several references to an option to make the Super Hi-Res memory linear. (Example p. 87 of Apple_Technical_Introduction_to_the_Apple_IIGS). But I am confused by this because its already linear... what does this option actually do? Bit 6 of the New Video register.  How can it be any more linear than it already is?

It is not linear if it is anything like the Apple II/II+/IIe display screens.  Look in the technical reference manual's index for how the IIgs display screen memory mapping works when in linear vs. non-linear modes.

[toc] | [prev] | [next] | [standalone]

#4890

In article <46c55e6e-5ecc-48b3-8762-116a88332b80@googlegroups.com>,
James Davis  <JPD.Enterprises@outlook.com> wrote:
>On Tuesday, November 6, 2018 at 11:11:37 AM UTC-8, paul.s.m...@gmail.com wrote:
>> I have seen several references to an option to make the Super Hi-Res
>memory linear. (Example p. 87 of
>Apple_Technical_Introduction_to_the_Apple_IIGS). But I am confused by
>this because its already linear... what does this option actually do?
>Bit 6 of the New Video register.  How can it be any more linear than it
>already is?
>
>It is not linear if it is anything like the Apple II/II+/IIe display
>screens.  Look in the technical reference manual's index for how the
>IIgs display screen memory mapping works when in linear vs. non-linear
>modes.

Which "technical reference manual"?  I don't know how this works either,
and I would like to know.  As far as I can see, the details (such as: what
hires/dhires would look like when linear mode is enabled, or what superhires
would look like with linear mode disabled) are not the the Apple IIgs
Hardware Reference Manual, 1st or 2nd edition.

Kent

[toc] | [prev] | [next] | [standalone]

#4891

On Wednesday, November 7, 2018 at 6:23:21 AM UTC-8, Kent Dickey wrote:
> In article <46c55e6e-5ecc-48b3-8762-116a88332b80@googlegroups.com>,
> James Davis  <JPD.Enterprises@outlook.com> wrote:
> >On Tuesday, November 6, 2018 at 11:11:37 AM UTC-8, paul.s.m...@gmail.com wrote:
> >> I have seen several references to an option to make the Super Hi-Res
> >memory linear. (Example p. 87 of
> >Apple_Technical_Introduction_to_the_Apple_IIGS). But I am confused by
> >this because its already linear... what does this option actually do?
> >Bit 6 of the New Video register.  How can it be any more linear than it
> >already is?
> >
> >It is not linear if it is anything like the Apple II/II+/IIe display
> >screens.  Look in the technical reference manual's index for how the
> >IIgs display screen memory mapping works when in linear vs. non-linear
> >modes.
> 
> Which "technical reference manual"?  I don't know how this works either,
> and I would like to know.  As far as I can see, the details (such as: what
> hires/dhires would look like when linear mode is enabled, or what superhires
> would look like with linear mode disabled) are not the the Apple IIgs
> Hardware Reference Manual, 1st or 2nd edition.
> 
> Kent

I haven't seen a good description of SHR linear vs interleaved memory by Apple, just GS TN #32, /INH anomoly:

http://www.1000bit.it/support/manuali/apple/technotes/iigs/tn.iigs.032.html

I reverse engineered the behavior when making the VidHD board so it could model the VGC's behavior.

The VGC has 32-bit access to slow memory (VRAM), which it uses to draw SHR scan-lines of 160 bytes in 40 cycles, and to load 32 palette bytes in 8 cycles during hblank. 

When aux mem is not interleaved (required for DHGR aux mem writes), the 65816 sees two byte-planes:

1) Even bytes are stored from $01/2000-$01/$5FFF, located in the 2nd 64K DRAM
2) Odd bytes are stored from $01/6000-$01/$9FFF, located in the 1st 64K DRAM

This means that all 16 SHR palettes are stored in a single page at the end of each byte-plane with palette low bytes at $01/5Fxx and high bytes at $01/9Fxx.

Note that interleaving is forced on whenever the SHR screen is displayed ($C029 bit 7=1 forces an implied bit 6=1 too).


I think non-interleaved SHR could allow for a useful SHR pseudo-mode of 40x200 with 240 colors in only 8.4K of memory using fill mode with all odd bytes = 0. Example:

AB CD: two bytes (4 pixels) of the 8000-byte source image
$01/2000: AA BB CC DD: Even bytes of non-interleaved SHR
$01/5000-$9FFF: all zeros (fill mode)

How the buffer appears with interleave enabled:
$01/2000: AA 00 BB 00 CC 00 DD 00

SHR display with fill mode enabled:
$01/2000: AA AA BB BB CC CC DD DD

You could also race-the-beam changing palette bytes to get 3000 colors per screen (200 lines * 15 colors).

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#4892

In article <9a2cfb53-c5ea-4b13-b0af-a44fa4a091e8@googlegroups.com>,
John Brooks  <jbrooks@blueshiftinc.com> wrote:
>I haven't seen a good description of SHR linear vs interleaved memory by
>Apple, just GS TN #32, /INH anomoly:
>
>http://www.1000bit.it/support/manuali/apple/technotes/iigs/tn.iigs.032.html
>
>I reverse engineered the behavior when making the VidHD board so it
>could model the VGC's behavior.
>
>The VGC has 32-bit access to slow memory (VRAM), which it uses to draw
>SHR scan-lines of 160 bytes in 40 cycles, and to load 32 palette bytes
>in 8 cycles during hblank. 
>
>When aux mem is not interleaved (required for DHGR aux mem writes), the
>65816 sees two byte-planes:
>
>1) Even bytes are stored from $01/2000-$01/$5FFF, located in the 2nd 64K DRAM
>2) Odd bytes are stored from $01/6000-$01/$9FFF, located in the 1st 64K DRAM
>
>This means that all 16 SHR palettes are stored in a single page at the
>end of each byte-plane with palette low bytes at $01/5Fxx and high bytes
>at $01/9Fxx.
>
>Note that interleaving is forced on whenever the SHR screen is displayed
>($C029 bit 7=1 forces an implied bit 6=1 too).
>
>
>I think non-interleaved SHR could allow for a useful SHR pseudo-mode of
>40x200 with 240 colors in only 8.4K of memory using fill mode with all
>odd bytes = 0. Example:
>
>AB CD: two bytes (4 pixels) of the 8000-byte source image
>$01/2000: AA BB CC DD: Even bytes of non-interleaved SHR
>$01/5000-$9FFF: all zeros (fill mode)
>
>How the buffer appears with interleave enabled:
>$01/2000: AA 00 BB 00 CC 00 DD 00
>
>SHR display with fill mode enabled:
>$01/2000: AA AA BB BB CC CC DD DD
>
>You could also race-the-beam changing palette bytes to get 3000 colors
>per screen (200 lines * 15 colors).
>
>-JB
>@JBrooksBSI

I'm not sure I'm following what you're saying.

TN-IIGS-032 says on the IIgs, the main and auxiliary mem as the CPU sees it
actually maps to two banks of 64KB of memory, which I'll call A and B.
The TN-IIGS-032 gives the mapping from A and B to memory, but I'll do the
reverse here and show which bank is accessed when the CPU accesses a given
address:

Main Memory                     Auxiliary Memory
$0000 - $5fff: A                $0000 - $5fff: B
$6000 - $9fff: B                $6000 - $9fff: A
$a000 - $ffff: A                $a000 - $ffff: B

This is transparent to software (which cannot tell what physical DRAM addresses
are being accessed).  And it basically makes no difference to normal video
modes, since main memory video displays all map to bank A, and Aux video
displays all map to bank B.

SHR (Super-Hires) has a problem--it maps only to Auxiliary memory in bank $01,
but it needs to read 4 bytes in one 1MHz clock cycle.  Clearly, they want to
access bank A and bank B in parallel, but the SHR buffer all maps to auxiliary
memory.

So, based on what you're saying, I assume that when New Video ($C029) has
bit 6=1, Auxiliary memory is "linearized", but I think that really
means interleaved.  Here's what I think you're saying: When $c029[6]=1, the
CPU's view of aux memory is:

$01/2000 is B.$2000 which is Non-Linearized $01/2000
$01/2001 is A.$6000 which is Non-Linearized $01/6000
$01/2002 is B.$2001 which is Non-Linearized $01/2001
$01/2003 is A.$6001 which is Non-Linearized $01/6001
etc.

OK, this explain SHR.  Now, to figure out what DHGR looks like.

I would assume this is all CPU-address based swizzling--the video hardware
always references the direct bank A or B as required (so Double-Hires Aux
memory is always bank B offset $2000-$3fff for page 1).  And so if
$c029[6]=1 and Double-Hires is being shown, what happens is that the CPU
view of the DHR buffer (including aux/main split) becomes:

Aux  $01/2000 is pixels 0-6     (same as usual)
Main $01/2000 is pixels 7-13    (all main memory accesses are same as usual)
Aux  $01/2002 is pixels 14-20   (this is different--we skip the odd bytes)
Main $01/2001 is pixels 21-27
Aux  $01/2004 is pixels 28-34   (this is different)
Main $01/2002 is pixels 35-41
Aux  $01/2006 is pixels 42-48   (this is different)
etc.

Basically, from the CPU's perspective, the Aux memory EVEN bytes from
$01/2000-$5fff are what is displayed for DHGR page 1 when "linearized".

So then, from the CPU's perspective, the Aux mememory EVEN bytes from
$01/$6000-$9fff are what is displayed for DHGR page 2 when "linearized".

When $c029[6] is set back to 0, the data from the CPU's perspective appears
to move back into the proper DHGR buffers, with page 1's aux data at
$01/2000-$3fff (all bytes), and page 2 at $01/$4000-$5fff.

So for KEGS to get basic support for linear mode on and off, it should move
this Bank 1 memory around as $c029 bit 6 is changed.  I'll look into this.
I don't think it's worth the effort to support drawing the proper graphics
with DHGR when $c029[6]=1, since I'm not aware of any code using this, so
testing and debugging this would be a whole lot of extra work.

This brings up a related question I do not know the answer to:

For normal Apple II video modes, the basic timing is simple: every 1MHz
clock has two phases: in one phase, video memory is accessed; and in the
other phase, the CPU can access the memory.  The video memory also acts as
refresh, so special refresh cycles are not needed.  For double-hires (or
dbl-lores), both Main and Aux memory are read in parallel in the same
phase, so it gets two bytes of data for video in the one phase of video
access.  But SHR needs to get 4 bytes of data in each 1MHz clock.
So you've explained the two banks A and B, and they are clearly read in
parallel.  This only gets us half the bandwidth we need.  So does the VGC/
Mega2 read data from the video DRAMs twice as fast in SHR mode?  How does it
do this?

Kent

[toc] | [prev] | [next] | [standalone]

#4893

On Wednesday, November 7, 2018 at 9:29:08 PM UTC-8, Kent Dickey wrote:
> In article <9a2cfb53-c5ea-4b13-b0af-a44fa4a091e8@googlegroups.com>,
> John Brooks  wrote:
> >I haven't seen a good description of SHR linear vs interleaved memory by
> >Apple, just GS TN #32, /INH anomoly:
> >
> >http://www.1000bit.it/support/manuali/apple/technotes/iigs/tn.iigs.032.html
> >
> >I reverse engineered the behavior when making the VidHD board so it
> >could model the VGC's behavior.
> >
> >The VGC has 32-bit access to slow memory (VRAM), which it uses to draw
> >SHR scan-lines of 160 bytes in 40 cycles, and to load 32 palette bytes
> >in 8 cycles during hblank. 
> >
> >When aux mem is not interleaved (required for DHGR aux mem writes), the
> >65816 sees two byte-planes:
> >
> >1) Even bytes are stored from $01/2000-$01/$5FFF, located in the 2nd 64K DRAM
> >2) Odd bytes are stored from $01/6000-$01/$9FFF, located in the 1st 64K DRAM
> >
> >This means that all 16 SHR palettes are stored in a single page at the
> >end of each byte-plane with palette low bytes at $01/5Fxx and high bytes
> >at $01/9Fxx.
> >
> >Note that interleaving is forced on whenever the SHR screen is displayed
> >($C029 bit 7=1 forces an implied bit 6=1 too).
> >
> >
> >I think non-interleaved SHR could allow for a useful SHR pseudo-mode of
> >40x200 with 240 colors in only 8.4K of memory using fill mode with all
> >odd bytes = 0. Example:
> >
> >AB CD: two bytes (4 pixels) of the 8000-byte source image
> >$01/2000: AA BB CC DD: Even bytes of non-interleaved SHR
> >$01/5000-$9FFF: all zeros (fill mode)
> >
> >How the buffer appears with interleave enabled:
> >$01/2000: AA 00 BB 00 CC 00 DD 00
> >
> >SHR display with fill mode enabled:
> >$01/2000: AA AA BB BB CC CC DD DD
> >
> >You could also race-the-beam changing palette bytes to get 3000 colors
> >per screen (200 lines * 15 colors).
> >
> >-JB
> >@JBrooksBSI
> 
> I'm not sure I'm following what you're saying.
> 
> TN-IIGS-032 says on the IIgs, the main and auxiliary mem as the CPU sees it
> actually maps to two banks of 64KB of memory, which I'll call A and B.
> The TN-IIGS-032 gives the mapping from A and B to memory, but I'll do the
> reverse here and show which bank is accessed when the CPU accesses a given
> address:
> 
> Main Memory                     Auxiliary Memory
> $0000 - $5fff: A                $0000 - $5fff: B
> $6000 - $9fff: B                $6000 - $9fff: A
> $a000 - $ffff: A                $a000 - $ffff: B
> 
> This is transparent to software (which cannot tell what physical DRAM addresses
> are being accessed).  And it basically makes no difference to normal video
> modes, since main memory video displays all map to bank A, and Aux video
> displays all map to bank B.
> 
> SHR (Super-Hires) has a problem--it maps only to Auxiliary memory in bank $01,
> but it needs to read 4 bytes in one 1MHz clock cycle.  Clearly, they want to
> access bank A and bank B in parallel, but the SHR buffer all maps to auxiliary
> memory.
> 
> So, based on what you're saying, I assume that when New Video ($C029) has
> bit 6=1, Auxiliary memory is "linearized", but I think that really
> means interleaved.  Here's what I think you're saying: When $c029[6]=1, the
> CPU's view of aux memory is:
> 
> $01/2000 is B.$2000 which is Non-Linearized $01/2000
> $01/2001 is A.$6000 which is Non-Linearized $01/6000
> $01/2002 is B.$2001 which is Non-Linearized $01/2001
> $01/2003 is A.$6001 which is Non-Linearized $01/6001
> etc.
> 
> OK, this explain SHR.  Now, to figure out what DHGR looks like.
> 
> I would assume this is all CPU-address based swizzling--the video hardware
> always references the direct bank A or B as required (so Double-Hires Aux
> memory is always bank B offset $2000-$3fff for page 1).  And so if
> $c029[6]=1 and Double-Hires is being shown, what happens is that the CPU
> view of the DHR buffer (including aux/main split) becomes:
> 
> Aux  $01/2000 is pixels 0-6     (same as usual)
> Main $01/2000 is pixels 7-13    (all main memory accesses are same as usual)
> Aux  $01/2002 is pixels 14-20   (this is different--we skip the odd bytes)
> Main $01/2001 is pixels 21-27
> Aux  $01/2004 is pixels 28-34   (this is different)
> Main $01/2002 is pixels 35-41
> Aux  $01/2006 is pixels 42-48   (this is different)
> etc.
> 
> Basically, from the CPU's perspective, the Aux memory EVEN bytes from
> $01/2000-$5fff are what is displayed for DHGR page 1 when "linearized".
> 
> So then, from the CPU's perspective, the Aux mememory EVEN bytes from
> $01/$6000-$9fff are what is displayed for DHGR page 2 when "linearized".
> 
> When $c029[6] is set back to 0, the data from the CPU's perspective appears
> to move back into the proper DHGR buffers, with page 1's aux data at
> $01/2000-$3fff (all bytes), and page 2 at $01/$4000-$5fff.
> 
> So for KEGS to get basic support for linear mode on and off, it should move
> this Bank 1 memory around as $c029 bit 6 is changed.  I'll look into this.
> I don't think it's worth the effort to support drawing the proper graphics
> with DHGR when $c029[6]=1, since I'm not aware of any code using this, so
> testing and debugging this would be a whole lot of extra work.
> 
> This brings up a related question I do not know the answer to:
> 
> For normal Apple II video modes, the basic timing is simple: every 1MHz
> clock has two phases: in one phase, video memory is accessed; and in the
> other phase, the CPU can access the memory.  The video memory also acts as
> refresh, so special refresh cycles are not needed.  For double-hires (or
> dbl-lores), both Main and Aux memory are read in parallel in the same
> phase, so it gets two bytes of data for video in the one phase of video
> access.  But SHR needs to get 4 bytes of data in each 1MHz clock.
> So you've explained the two banks A and B, and they are clearly read in
> parallel.  This only gets us half the bandwidth we need.  So does the VGC/
> Mega2 read data from the video DRAMs twice as fast in SHR mode?  How does it
> do this?
> 
> Kent

.

> $01/2000 is B.$2000 which is Non-Linearized $01/2000
> $01/2001 is A.$6000 which is Non-Linearized $01/6000
> $01/2002 is B.$2001 which is Non-Linearized $01/2001
> $01/2003 is A.$6001 which is Non-Linearized $01/6001
> etc.

Correct

> Basically, from the CPU's perspective, the Aux memory EVEN bytes from
> $01/2000-$5fff are what is displayed for DHGR page 1 when "linearized".

Correct. DHGR is only using SHR 'even' bytes from the first byte-plane ($01/2000) and does not use the SHR 'odd' bytes from the 2nd byte-plane ($01/6000).

>  But SHR needs to get 4 bytes of data in each 1MHz clock.
> So you've explained the two banks A and B, and they are clearly read in
> parallel.  This only gets us half the bandwidth we need.  So does the VGC/
> Mega2 read data from the video DRAMs twice as fast in SHR mode?  How does it
> do this?

Every GS motherboard has 4x 2MHz DRAM chips for this reason.
 - 7 MHz video modes read one DRAM each cycle (data is visible on floating bus)
 - 14 MHz video modes read 2 DRAMs each cycle (80col, dbl-lores, dbl-hires)
 - 8 & 16 MHz video modes read all 4 DRAMs each cycle (320x4bit SHR & 640x2bit SHR)

There are effectively 4 memory banks A,B,C,D, though for emulators it can be thought of as 2x 64KB banks A & B as you described.

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#4895

> I think non-interleaved SHR could allow for a useful SHR pseudo-mode of 40x200 

Wouldn't it be 80x200? 

I'll try to make a test program today.  

[toc] | [prev] | [next] | [standalone]

#4897

On Friday, November 9, 2018 at 2:03:57 AM UTC-8, Dagen Brock wrote:
> > I think non-interleaved SHR could allow for a useful SHR pseudo-mode of 40x200 
> 
> Wouldn't it be 80x200? 
> 
> I'll try to make a test program today.

Right. 320 (fill mode res) / 4 (SHR pixels per image nibble).

-JB

[toc] | [prev] | [next] | [standalone]

#5384

Thanks for your explanation of the linearized superhires mode.

The following two things are now clear to me:

1) the 6000-9fff segments of banks E0 and E1 are swapped. They do not reside in physical memory banks A and B, but in B and A  (as explained in TN32)

2) the linearization bit interleaves the bytes of the segments E1/2000-5fff and E1/6000-9fff

This means that when the linearization bit is on, the video hardware can access 16 successive bits of the linearized video buffer in a single read cycle.
For instance, the two bytes E1/2000-2001  are located in B/2000 and A/6000. Although they do not appear at the same address, the VGC produces two signals,
FLIP6 and FLIP7, that can swap the high bits of the A bank addresses. These can handle all the address discrepancies.

If we assume that the video hardware only makes one memory access during the first half of the 1Mhz clock cycle, then we have a problem because
we need 32 bits of video data per microsecond to produce the superhires video. Your explanation using the four memory chips is not good
enough because each of them (TMS4464, 150ns) only generate 4 bits. Together the four chips can only produce 16 bits per read cycle.

At this point I conjecture that the VGC in fact makes two memory accesses during that time, using the 4464 fast page mode
where one sets the row address only once, but get data for multiple column addresses.  To get the data, one needs to wait
at least 150ns after asserting RAS and 120ns after asserting CAS. So the following could barely work:


14M cycle
---------
 0   load video address column on the 4464 multiplexed bus RA0-RA7
 1   assert RAS
 2   load first video address row on RA0-RA7
 3   assert CAS
 4   maintain CAS
 5   read 16 bits of video data, deassert CAS, deassert RAS
 6   load second video address row on RA0-RA7
 7   assert CAS
 8   maintain CAS
 9   read 16 nore bits of video data, deassert CAS, deassert RAS
10   load cpu address column on RA0-RA7. 
11   assert CAS 
12   maintain CAS
13   read 8 bits of cpu data, deassert CAS, deassert RAS


What I do not like in this hypothesis is the fact that according to the schematics, the RAS and CAS signals are generated by the MEGA2, not the VGC.  This would mean that the MEGA2 contains a GS-specific circuitry. This is not completely implausible because it probably also contains the circuitry that swaps the banks 6000-9fff and the one that interleaves E1/2000-5fff and E1/6000-9fff. I just do not see where else this could be realized.

Anyway, this is remarkably complex.
 

[toc] | [prev] | [next] | [standalone]

#5385

Actually there is a bug in my timing table (one also needs RAS for the cpu).
This means that one has to use both the rising and falling edges of the 14M clock to load the address bus.
Maybe something like:


14M clock
---------
0 cycle 0      load video row address
1              assert RAS
0 cycle 1      load first video column address
1              assert CAS
0 cycle 2      -
1              -
0 cycle 3      -
1              latch first 16 bits of video data
0 cycle 4      deassert CAS
1              -
0 cycle 5      load second video column address
1              assert CAS
0 cycle 6      -
1              -
0 cycle 7      -
1              latch second 16 bits of video data
0 cycle 8      deassert CAS & RAS 
0 cycle 8      -
1              -
0 cycle 9      load row address for cpu access
1              assert RAS
0 cycle 10     load column address for cpu access
1              assert CAS
0 cycle 11     -
1              -
0 cycle 12     -
1              latch 8 bits of cpu data 
0 cycle 13     deassert CAS & RAS
1              - 

[toc] | [prev] | [next] | [standalone]

#5386

If this can help: http://www.brutaldeluxe.fr/documentation/cortland/v5/Cortland%20Custom%20ICs%20-%20Wayne%20Lowry%20-%20Preliminary%20notes%20-%2019860214.pdf

av

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web