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

Groups > comp.sys.apple2 > #5206 > unrolled thread

Apple IIGS bank latching

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

Contents

  Apple IIGS bank latching "Marc S. Ressl" <mressl@gmail.com> - 2012-03-05 01:00 -0800
    Re: Apple IIGS bank latching Antoine Vignau <antoine.vignau@laposte.net> - 2012-03-05 02:56 -0800
      Re: Apple IIGS bank latching "Marc S. Ressl" <mressl@gmail.com> - 2012-03-05 07:36 -0800
        Re: Apple IIGS bank latching Antoine Vignau <antoine.vignau@laposte.net> - 2012-03-05 14:15 -0800
          Re: Apple IIGS bank latching Antoine Vignau <antoine.vignau@laposte.net> - 2012-03-05 14:22 -0800
            Re: Apple IIGS bank latching "Marc S. Ressl" <mressl@gmail.com> - 2012-03-05 20:02 -0800
              Re: Apple IIGS bank latching "Marc S. Ressl" <mressl@gmail.com> - 2012-03-05 20:54 -0800
                Re: Apple IIGS bank latching Antoine Vignau <antoine.vignau@laposte.net> - 2012-03-05 22:47 -0800
              Re: Apple IIGS bank latching Antoine Vignau <antoine.vignau@laposte.net> - 2012-03-05 22:52 -0800
                Re: Apple IIGS bank latching mressl@macgui.com (Marc S Ressl) - 2012-03-06 16:07 +0000
                  Re: Apple IIGS bank latching Daniel Kruszyna <dan@krue.net> - 2012-03-06 23:29 +0000
                    Re: Apple IIGS bank latching mressl@macgui.com (Marc S Ressl) - 2012-03-07 02:28 +0000
                      Re: Apple IIGS bank latching Antoine Vignau <antoine.vignau@laposte.net> - 2012-03-06 21:50 -0800
                        Re: Apple IIGS bank latching mressl@macgui.com (Marc S Ressl) - 2012-03-07 06:43 +0000
                      Re: Apple IIGS bank latching Vladimir Ivanov <vladitx@XXXyahooXXX.com> - 2012-03-07 09:44 +0200
                      Re: Apple IIGS bank latching Daniel Kruszyna <dan@krue.net> - 2012-03-07 12:15 +0000
                        Re: Apple IIGS bank latching mressl@macgui.com (Marc S Ressl) - 2012-03-08 02:32 +0000
                Re: Apple IIGS bank latching mressl@macgui.com (Marc S Ressl) - 2012-03-06 16:16 +0000
                  Re: Apple IIGS bank latching Daniel Kruszyna <dan@krue.net> - 2012-03-06 18:46 +0000

#5206 — Apple IIGS bank latching

Hello,

I am once again intrigued by the behavior of the Apple IIGS, and I was
wondering if someone can help me out with this... here are the
questions:

* Does a real Apple IIGS do the Apple IIe main/aux mapping only on
bank $00, or does this behavior happen also on other banks? For
instance, try the following code on a real IIGS, what is the result?
Best if you try after a restart without OS...

CALL-151
E0/1000:E0
E1/1000:E1
00/0100:8D 03 C0 AF 00 10 E0 8D 20 01 8D 02 C0 60
00/0100G
00/0120

What do you see, E0 or E1? I would guess E0.

* Does a real Apple IIGS map the ROM in E0/D000.FFFF and E1/D000.FFFF?
I would say it doesn't, but for some reason Sweet16 does it. A test
(again, best if you try after restart without an OS):

CALL-151
00/0300:af 00 d0 e0 8d 10 03 60
00/0300G
00/0310

What do you see, 6F (from the ROM) or something else? I would expect
something else...

* When you enable shadowing on all banks, is I/O also mapped on all
banks? This test assumes that you have a memory expansion card, and
you just restarted :-):

00/0300:a9 90 8d 36 c0 af 00 d0 02 8d 10 03 60
00/0300G
00/0310

What do you see? 6F (from the ROM) or something else? I would expect
ROM, although most emulators don't do it.

* I am quite unable to understand what the "bank latch" bit in the new
video register $C029 does. If I'm not mistaken, the FPI keeps track of
the main/aux memory mapping in bank $00, and if something has to be
written, it tells the Mega II through the bank latch if data has to be
written to main or aux memory. Can somebody do a test to confirm this?
Again, restart and no OS...

E0/1000:E0
E1/1000:E1
00/0300:a9 00 8d 29 c0 af 00 10 e1 8d 10 03 60
00/0300G
00/0310

What do you see, E0 or E1? I would guess E0, but who knows :)

Thanks for all your help,
and with the best wishes,

Marc.-

[toc] | [next] | [standalone]

#5207

Tested on a real ROM 3

* E1
* 6F
* 6F
* crashes the //gs (5.25" motor turned on then stopped, GR screen
displayed) - no result visible!

av

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

#5209

On 5 mar, 07:56, Antoine Vignau <antoine.vig...@laposte.net> wrote:
> Tested on a real ROM 3
>
> * E1
> * 6F
> * 6F
> * crashes the //gs (5.25" motor turned on then stopped, GR screen
> displayed) - no result visible!
>
> av

Hello Antoine:

thank you so much for your results... now that is really interesting!

Regarding the 4th experiment, can you try this one:

E0/1000:E0
E1/1000:E1
00/0300:AD 29 C0 48 25 7F 8d 29 c0 af 00 10 e1 8d 80 03 68 8d 29 c0 60
00/0300G
00/0380

Thanks again!,
and with the best wishes,

Marc.-

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

#5211

Tested on a real ROM 3

Ah, better ;-)

* E1

antoine

ps. FF/D000: 6F

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

#5212

On 5 mar, 23:15, Antoine Vignau <antoine.vig...@laposte.net> wrote:
> Tested on a real ROM 3
>
> Ah, better ;-)
>
> * E1
>
> antoine
>
> ps. FF/D000: 6F

Same results on a ROM 01:
* E1
* 6F
* 6F
* crash
* E1

BTW, replaced 25 (AND dp) with 29 (AND imm) ;-)

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

#5214

On 5 mar, 19:22, Antoine Vignau <antoine.vig...@laposte.net> wrote:
> On 5 mar, 23:15, Antoine Vignau <antoine.vig...@laposte.net> wrote:
>
> > Tested on a real ROM 3
>
> > Ah, better ;-)
>
> > * E1
>
> > antoine
>
> > ps. FF/D000: 6F
>
> Same results on a ROM 01:
> * E1
> * 6F
> * 6F
> * crash
> * E1
>
> BTW, replaced 25 (AND dp) with 29 (AND imm) ;-)

Whoops, my bad :-).

Thanks a lot for all the results. I am still surprised by that last
one!

Some more tests (pretty please with sugar on top):

(5) Is aux/main memory switching enabled for all even banks or just
bank 0?
CALL-151
02/1000:02
03/1000:03
00/0100:8D 03 C0 AF 00 10 02 8D 20 01 8D 02 C0 60
00/0100G
00/0120
What do you see, 02 or 03?

(6) In case the last experiment returned 03, is aux/main memory
switching enabled for all even banks, if the shadowing is enabled for
all banks?

CALL-151
02/1000:02
03/1000:03
00/0100:A9 90 8D 36 C0 8D 03 C0 AF 00 10 02 8D 20 01 8D 02 C0 60
00/0100G
00/0120
What do you see, 02 or 03?

(7) This is a test of linearized video memory.

E0/0:0
1<0.BFFFM
1900:19
2000:12 34
2080:56 78
9D00:9D
9E00:9E
9F00:9F
A000:A0
C029:41
1900
2000.2007
2080.2087
20a0.20a7
9d00
9e00
9f00
a000

What do you see?

Again, thanks a lot!

With the best wishes,

Marc.-

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

#5215

On 6 mar, 01:02, "Marc S. Ressl" <mre...@gmail.com> wrote:
> On 5 mar, 19:22, Antoine Vignau <antoine.vig...@laposte.net> wrote:
>
>
>
>
>
>
>
>
>
> > On 5 mar, 23:15, Antoine Vignau <antoine.vig...@laposte.net> wrote:
>
> > > Tested on a real ROM 3
>
> > > Ah, better ;-)
>
> > > * E1
>
> > > antoine
>
> > > ps. FF/D000: 6F
>
> > Same results on a ROM 01:
> > * E1
> > * 6F
> > * 6F
> > * crash
> > * E1
>
> > BTW, replaced 25 (AND dp) with 29 (AND imm) ;-)
>
> Whoops, my bad :-).
>
> Thanks a lot for all the results. I am still surprised by that last
> one!
>
> Some more tests (pretty please with sugar on top):
>
> (5) Is aux/main memory switching enabled for all even banks or just
> bank 0?
> CALL-151
> 02/1000:02
> 03/1000:03
> 00/0100:8D 03 C0 AF 00 10 02 8D 20 01 8D 02 C0 60
> 00/0100G
> 00/0120
> What do you see, 02 or 03?
>
> (6) In case the last experiment returned 03, is aux/main memory
> switching enabled for all even banks, if the shadowing is enabled for
> all banks?
>
> CALL-151
> 02/1000:02
> 03/1000:03
> 00/0100:A9 90 8D 36 C0 8D 03 C0 AF 00 10 02 8D 20 01 8D 02 C0 60
> 00/0100G
> 00/0120
> What do you see, 02 or 03?
>
> (7) This is a test of linearized video memory.
>
> E0/0:0
> 1<0.BFFFM
> 1900:19
> 2000:12 34
> 2080:56 78
> 9D00:9D
> 9E00:9E
> 9F00:9F
> A000:A0
> C029:41
> 1900
> 2000.2007
> 2080.2087
> 20a0.20a7
> 9d00
> 9e00
> 9f00
> a000
>
> What do you see?
>
> Again, thanks a lot!
>
> With the best wishes,
>
> Marc.-

I just realized the 4th experiment has a big flaw, it is not resetting
bit 0 but bit 7. Here goes the corrected version:

E0/1000:E0
E1/1000:E1
00/0300:AD 29 C0 48 29 FE 8d 29 c0 af 00 10 e1 8d 80 03 68 8d 29 c0 60
00/0300G
00/0380

This time I hope it correctly returns E0 :-).

With the best wishes,

Marc.-

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

#5217

On 6 mar, 05:54, "Marc S. Ressl" <mre...@gmail.com> wrote:
> I just realized the 4th experiment has a big flaw, it is not resetting
> bit 0 but bit 7. Here goes the corrected version:
>
> E0/1000:E0
> E1/1000:E1
> 00/0300:AD 29 C0 48 29 FE 8d 29 c0 af 00 10 e1 8d 80 03 68 8d 29 c0 60
> 00/0300G
> 00/0380
>
> This time I hope it correctly returns E0 :-).
>
> With the best wishes,
>
> Marc.-

* E0

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

#5216

(5) returns 02
(6) returns 03
(7) returns
* 1900: 19
* 2000.2007: 12 34 00 00 00 00 00 00
* 2080.2087: 56 78 00 00 00 00 00 00
* 20A0.20A7: 00 00 00 00 00 00 00 00
* 9D00: 9D
* 9E00: 9E
* 9F00: 9F
* A000: A0

Antoine

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

#5218

Antoine Vignau wrote:
> (5) returns 02
> (6) returns 03
> (7) returns
> * 1900: 19
> * 2000.2007: 12 34 00 00 00 00 00 00
> * 2080.2087: 56 78 00 00 00 00 00 00
> * 20A0.20A7: 00 00 00 00 00 00 00 00
> * 9D00: 9D
> * 9E00: 9E
> * 9F00: 9F
> * A000: A0
> 
> Antoine
>

Hello Antoine. Now this is most interesting! :-).

Here are the findings:

* The Apple IIe memory switches are always active for bank $E0.
* If the language card and I/O is enabled, Apple IIe memory switches are
active for bank $00.
* If shadowing is enabled for all banks, memory switches are active for all
even banks ($00, $02, etc).
* ROM is always available when the language card is enabled (Sweet16 1, KEGS
0 :-) )
* The New Video "memory linearization" appears to not scramble the contents
of video memory (I'm still having a hard time understanding this, as I
believed it would).

I hope this information is useful to authors of Apple IIGS emulators :-).

With the best wishes,

Mar.c-

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

#5227

Marc S Ressl <mressl@macgui.com> wrote:
> * The New Video "memory linearization" appears to not scramble the contents
> of video memory (I'm still having a hard time understanding this, as I
> believed it would).

When linearization is enabled, e1/2000..9fff is remapped.

x = linear_address - $2000
y = x[15]:x[0]:x[14..1]
physical_address = y + $2000

in other words:

linear $2000 maps to physical $2000
linear $2001 maps to physical $6000

$2002 -> $2001
$2003 -> $6001

the pattern continues...

It just so happens that the mapping between main/aux bank and physical
chips on the board is swapped for addresses $6000..$9fff. These two
hacks together let the VGC access two contiguous bytes of SHR data
simultaneously.

-- Daniel

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

#5228

Daniel Kruszyna wrote:
> Marc S Ressl <mressl@macgui.com> wrote:
>> * The New Video "memory linearization" appears to not scramble the
>> contents
>> of video memory (I'm still having a hard time understanding this, as I
>> believed it would).
> 
> When linearization is enabled, e1/2000..9fff is remapped.
> 
> x = linear_address - $2000
> y = x[15]:x[0]:x[14..1]
> physical_address = y + $2000
> 
> in other words:
> 
> linear $2000 maps to physical $2000
> linear $2001 maps to physical $6000
> 
> $2002 -> $2001
> $2003 -> $6001
> 
> the pattern continues...
> 
> It just so happens that the mapping between main/aux bank and physical
> chips on the board is swapped for addresses $6000..$9fff. These two
> hacks together let the VGC access two contiguous bytes of SHR data
> simultaneously.
>

Daniel,

thanks a lot for your clearing that up :-). I have been looking for this on
the net, and it seems you are the first who covers this.

Now, the problem is experiment #7 I posted earlier (omg, I sound like a
craZy scientist!!)... here is a snippet:

C029:01
2000:12 34
C029:41
2000.2001

This returns "12 34", but I would have expected something different (as the
memory map is changed). Is it possible that the monitor is messing with
C029? What do you guys think is going on?

Btw, I have two more experiments :-) #8 and #9...

* #8 Is aux/main memory switching disabled if the language card is disabled?

00/1000:00
01/1000:01
00/0100:AD 35 C0 48 A9 00 8D 35 C0 8D 03 C0 AF 00 10 00 8D 20 01 8D 02 C0 68
8D 35 C0 60
00/0100G
00/0120

* #9 Is it true that the video character generator data is available at
$C028?

00/0300:A2 00 DA AD 28 C0 20 DA FD FA E8 D0 F5 60

In case you see something interesting, I have this big petition: could you
run this program a couple of times, and make pictures of the screen (til you
notice it cycles back to the beginning)? I would expect 256 (characters) * 8
(scan lines) * 8 (languages) interesting bytes… this would make 64
screens. Am I pushing it too much? :-)

Thanks a lot to all of you for all the help,
and with the best wishes!

Marc.-

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

#5231

Tested on a real ROM 3

* #7: 12 34
* #8: 01
* #9: will do that tonight, Paris time. Pattern is different each
time...

antoine

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

#5232

Antoine Vignau wrote:
> Tested on a real ROM 3
> 
> * #7: 12 34
> * #8: 01
> * #9: will do that tonight, Paris time. Pattern is different each
> time...
> 
> antoine
>

Antoine:

thanks for going into all this trouble. I discovered a bug in experiment #9,
it should be as follows:

00/0300:A2 00 DA AD 2C C0 20 DA FD FA E8 D0 F5 60 

With the best wishes,

Marc.-

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

#5233

On Wed, 7 Mar 2012, Marc S Ressl wrote:

> C029:01
> 2000:12 34
> C029:41
> 2000.2001
>
> This returns "12 34", but I would have expected something different (as the
> memory map is changed). Is it possible that the monitor is messing with
> C029? What do you guys think is going on?

Once I tried messing with (probably) the speed register from Monitor and 
it didn't went well. Always do your experiments from short program, 
perhaps with interrupts disabled, just in case.

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

#5234

Marc S Ressl <mressl@macgui.com> wrote:
> Now, the problem is experiment #7 I posted earlier (omg, I sound like a
> craZy scientist!!)... here is a snippet:
> 
> C029:01
> 2000:12 34
> C029:41
> 2000.2001
> 
> This returns "12 34", but I would have expected something different (as the
> memory map is changed). Is it possible that the monitor is messing with
> C029? What do you guys think is going on?

It's very likely that the monitor is changing this register. When I did my
experiments, I used a program that first clears all of $2000..$9fff. It then
sets one byte with linearization disabled, and searches the entire range with
linearization enabled for that byte (or bytes). Repeat for all bytes.

Here it is:
http://krue.net/junque/linear.po

(To Antoine, who will probably disassemble this -- I know that the code is
terrible, but it does get the job done. :)

-- Daniel

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

#5241

Daniel Kruszyna wrote:
> Marc S Ressl <mressl@macgui.com> wrote:
>> Now, the problem is experiment #7 I posted earlier (omg, I sound like a
>> craZy scientist!!)... here is a snippet:
>> 
>> C029:01
>> 2000:12 34
>> C029:41
>> 2000.2001
>> 
>> This returns "12 34", but I would have expected something different (as
>> the
>> memory map is changed). Is it possible that the monitor is messing with
>> C029? What do you guys think is going on?
> 
> It's very likely that the monitor is changing this register. When I did my
> experiments, I used a program that first clears all of $2000..$9fff. It
> then
> sets one byte with linearization disabled, and searches the entire range
> with
> linearization enabled for that byte (or bytes). Repeat for all bytes.
> 
> Here it is:
> http://krue.net/junque/linear.po
> 
> (To Antoine, who will probably disassemble this -- I know that the code is
> terrible, but it does get the job done. :)
>

It's probably the monitor.

Anyway, I have taken the liberty to grab your experiment, and re-post it
here in all hex-glory!

2000:4C 78 20 00 00 DA C2 20 8A EB 38 FB 20 41 F9 A9
2010:A0 20 ED FD 18 FB C2 10 FA 60 DA 38 FB 20 8E FD
2020:18 FB C2 10 FA 60 A2 00 20 A9 00 9F 00 00 E1 E8
2030:E0 00 A0 D0 F6 60 A9 40 1C 29 C0 AE 03 20 A9 FF
2040:9F 00 00 E1 20 1A 20 20 05 20 A9 40 0C 29 C0 A2
2050:00 20 BF 00 00 E1 F0 09 A9 00 9F 00 00 E1 20 05
2060:20 E8 E0 00 A0 D0 EB 60 20 36 20 AE 03 20 E8 8E
2070:03 20 E0 00 A0 D0 F1 60 18 FB E2 20 C2 10 A2 00
2080:20 8E 03 20 A9 40 1C 29 C0 20 26 20 20 68 20 4C
2090:8F 20

I do think that's was very clever thing to do :-). So that answers
experiment #7!

Thanks a lot,
and with the best wishes,

Marc.-

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

#5220

Antoine Vignau wrote:
> (5) returns 02
> (6) returns 03
> (7) returns
> * 1900: 19
> * 2000.2007: 12 34 00 00 00 00 00 00
> * 2080.2087: 56 78 00 00 00 00 00 00
> * 20A0.20A7: 00 00 00 00 00 00 00 00
> * 9D00: 9D
> * 9E00: 9E
> * 9F00: 9F
> * A000: A0
> 
> Antoine
>

Oh and I forgot one item:

* When the bank latch is enabled, A17 is passed to the Mega II, so you can
access E1/xxxx directly. If the bank latch is disabled, all accesses to
E1/xxxx go to E0/xxxx (where you can still access auxiliary memory through
Apple IIe soft switches,

-- 
With the best wishes,

Marc.-

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

#5224

Marc S Ressl <mressl@macgui.com> wrote:
> * When the bank latch is enabled, A17 is passed to the Mega II, so you can
> access E1/xxxx directly. If the bank latch is disabled, all accesses to
> E1/xxxx go to E0/xxxx (where you can still access auxiliary memory through
> Apple IIe soft switches,

For this reason, the memory softswitches exist in both the MegaII and FPI.

-- Daniel

[toc] | [prev] | [standalone]

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

csiph-web