Re: IIgs peculiarities

[dempson@actrix.gen.nz (David Empson)]

vladitx <vladitx@nucleusys.com> wrote:

> On Feb 22, 10:28 am, demp...@actrix.gen.nz (David Empson) wrote:
> > vladitx <vlad...@nucleusys.com> wrote:
> >
> > > 1) IIgs ROM 03 has additional bit in the shadowing register (and the
> > > default 'enable') to include Text Page 2 ($800..$BFF), but the
> > > firmware keeps it disabled for some reason. And the "Alternate Display
> > > Mode" option is still available in the Control Panel.
> > > Where is the logic to this? Just leaving the register to shadow Text
> > > Page 2 is the way to go, and no "Alternate Display Mode" is needed at
> > > all.
> >
> > Probably because of a reason like some third party software was
> > expecting to be able to use text page 2 in bank $E0, and having it
> > permanently shadowing from bank 0 would have corrupted whatever was
> > there.
> 
> I suspected that. But then again, ROM 00/01 "Alternate Mode" will copy
> data in banks $E0/E1 so a software relying on these 2x1KB chunks is
> not very smart.

The point is that it was a decision by the user whether or not to enable
Alternate Display Mode, so some software could have made the (bad)
assumption that it was safe to use this area, because the author wasn't
aware of that feature, or didn't expect it to be enabled.

> Also Memory Manager doesn't handle this region, which should further
> stop developers from using it.

All the more reason for lazy developers to use it. A free 1 KB area
which doesn't require any mucking around with toolsets.

Games come to mind, especially if they are expecting to be booted
directly.

> > > 2) I tried manually setting "Slow" speed by changing the high-bit of
> > > the appropriate register (through Monitor), but nothing happens. And
> > > the content of the register doesn't change. Is there IRQ subroutine
> > > keeping overwriting it? Or is there a special way to access it?
> >
> > You can't do this directly, because the KEYIN routine saves and restores
> > the register containing the speed. You have to call a subroutine which
> > sets the bit.
> 
> There's something fishy here. While I change system speed through
> Control Panel (and make sure that it really changes), reading E0/C036
> through Monitor still doesn't show change in bit7 - it is always set.
> 
> Maybe Sheppy will reveal the truth. BTW, this is on a 03.

Same for a ROM 1 or ROM 3. If you enter the CDA menu while the monitor
is waiting for input, the speed register is temporarily changed, but the
monitor's KEYIN routine restores it to the prior setting as soon as you
press a key. (Or it might be the line input routine - I'm just aware of
never being able to have the speed setting "stick" when entering the CDA
menu while the standard line input routine is waiting for input.)

> > > 4) Memory expansion - according to what I've seen the connector
> > > provides for 2^10 rows/columns and 4 banks (CROW1/CROW0). This makes
> > > 4MB. How to go beyond this up-to 8MB? Is the signal "MSIZE"
> > > responsible and how?
> >
> > Memory cards which support more than four "rows" do so via a mechanism
> > which has compatibility issues. They watch for the bank register value
> > output by the CPU on the data bus in the first half of a cycle, and
> > latch at least one bit. Some of them latch the whole thing and ignore
> > the CROW1/0 bits, while others synthesize a third row select bit from
> > one bit of the bank select register.
> 
> This explanation fits well. Despite the marketing hype of "8.25MB",
> hardware reference cites expansion of additional 4MB.
> 
> I still wonder what "MSIZE" signal does. It is shorted to ground on a
> certain memory expansion board, so must be input to FPI.

(Without checking documention which is buried away...) It tells the FPI
whether the memory rows are 256 KB or 1 MB, and thus how to set up the
CROW memory mapping, and it may influence refresh cycles.

The earlier memory expansion cards for the IIgs had 256 KB to 1 MB of
memory using 256 KB rows.

> > The compatibility issue is that DMA cycles don't output a bank in the
> > first half of the cycle, so a memory card which uses this technique is
> > not compatible with cards in I/O slots which use DMA.
> 
> According to what I understand from a quick glance at ROM 01
> schematics, I/O slots are bound only to MDBUS which is $E0. Which
> should mean that DMA for the seven Apple ][ slots is only possible in
> that bank.

There is a DMA bank select register in the FPI which allows DMA to any
bank, but the FPI only outputs the CROW signals during a DMA cycle. It
doesn't output the DMA register in the first half of the cycle.

> Memory expansion is through FPI bus, where as you stated bank number
> is output somewhere in the beginning of a cycle (sorry, still haven't
> looked at 65C816 details).

The bank number is output on the data bus by the 65816 in the first half
of a CPU cycle, from which it is latched by the FPI.

> > There is one exception: the RamFAST SCSI card uses some trick to allow
> > DMA to work properly with these cards. I never heard the official story
> > of how they did this, but my speculation at the time was that the driver
> > does a normal CPU access to the target bank, which is sufficient to
> > latch the correct details into the memory card, then DMA cycles are
> > performed within that bank. It probably has to do with the CPU
> > repeatedly accessing the same bank to avoid bogus data appearing on the
> > data bus.
> 
> Are you sure DMA can have I/O in a bank different than $E0?

100% certain. See above, and every IIgs-specific DMA card (including
Apple's own "High Speed" SCSI card) fully supports DMA up to the 4 row
limit in the memory expansion card (plus all of the built-in RAM).

> > > 5) The memory expansion board may contain ROM, banks $F0+. Does the
> > > FPI know the installed ROM on the motherboard and redirect the other
> > > memory range to the expansion? Is pin #57 of FPI configuring this or
> > > FPI chips on ROM 03 are newer?
> >
> > The area in banks $F0 through $F7 is reserved for a ROM disk, which is
> > supported by the built-in SmartPort firmware (in slot 5). Some memory
> > cards provided ROM or static RAM in this area (I had an OctoRAM ESP).
> 
> So FPI doesn't block write access to this region? Nice for creating
> runtime configurable ROM disks (devtools, for example).

Write access is possible: my OctoRAM ESP card had a jumper for whether
or not to allow writes. It used NiCad batteries to hold the RAM contents
while the computer was off.

> > The firmware just looks for signature bytes at the start of bank $F0 to
> > see if there is a valid ROMdisk present.
> >
> > Banks $F8 and higher (up to $FB on a ROM 3 IIgs, or $FD on ROM 00/01)
> > are reserved for expanding the firmware ROM. I believe they do map to
> > the ROM expansion area on the memory expansion card, but nothing is
> > allowed to use them. Some cards might have bent the rules and used this
> > area to enlarge the ROMDISK, and been bitten when the built-in ROM got
> > bigger with ROM 3.
> 
> The split $F0..$F7 / $F8+ seems like just a software compatibility
> guideline. FPI should output ROMSEL for the whole area.

It does.

> Now it's quite easier - there won't be ROM 04. :-) So the whole area
> $F0..$FB is there for ROMDISK, as no future firmware extensions would
> be made.
> 
> > To answer your specfic question: the FPI chips on the ROM 00/01 and ROM
> > 3 are different. They even have different names: the ROM 3 on is "CYA"
> > (apparently short for "Control Your Apple").
> 
> Ok, sounds quite right.
> 
> Speaking of which, does anyone have schematics of ROM 03?

They are in the 2nd edition of the IIgs Hardware Reference.

> > The ROM 3 version has different memory mapping rules to deal with the
> > larger built-in ROM, the greater number of fast RAM banks on the
> > motherboard, and the fact that they have one more multiplexed address
> > bit. The CROW0 and CROW1 signals are generated based on a higher start
> > address than for the ROM 00/01.
> 
> There is a signal on the 01 FPI named "1 Megabit". It could've been
> only provision to support 1Mbit DRAMs, or something more ...

No idea, sorry.

-- 
David Empson
dempson@actrix.gen.nz