[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The next step after writing my own Apple ][ wedge for the ///is...
mdj wrote:
On Oct 9, 3:05 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
The softswitch architecture of the /// is quite complex and almost
undocumented. That's a shame, since without complete documentation,
this rather clever (maybe too clever) machine design is headed for the
bit bucket of history...
I particularly liked the extended (ZP), Y addressing :-)
This very clever device, implemented with fairly simple logic outside
the processor, solves one of the most vexing problems of bank switching:
turning every banked memory reference into at least two (and usually
more) instructions. It's a shame it didn't become more widespread as
a way of extending a 16-bit address space.
It really is quite an architectural jump over the Apple II, and as you
say, it's a shame appalling design (or lack thereof) in other areas
put it to a premature death.
Agreed.
BTW, back on the subject of reloading the character generator SRAM, it
appears that this was done in a typically "Woz" fashion, by extending
the function of the video refresh circuits.
Since the SRAM is single-ported, it can only be updated when it is not
being used to paint characters, so the Apple /// designers provided a
mode (controlled by the $C0DA/$C0DB softswitch) in which, during VBL,
the video scanner accesses certain screen holes to obtain a character
code, which is then used to generate an address in the $C00..$FFF range
containing character image data. Since each character image has 8 rows,
a character whose image is to be replaced must be stored in 8 screen
holes. A total of 64 screen holes are reserved for this operation, so
up to 8 character images can be replaced by the hardware during each
VBL period.
In SOS, this operation is controlled and synchronized by VBL interrupts,
which sequence through all the requested replacements in multiple video
frames.
So, to cause the character image data at $C00..$FFF to replace the
content of the character generator SRAM, one must:
1. Store the character values ($00..$7F), 8 at a time, 8 times each into
8 different "download" screen holes:
Download cell: 0 1 2 3 4 5 6 7
==== ==== ==== ==== ==== ==== ==== ====
0878 0879 087A 087B 0A78 0A79 0A7A 0A7B
087C 087D 087E 087F 0A7C 0A7D 0A7E 0A7F
08F8 08F9 08FA 08FB 0AF8 0AF9 0AFA 0AFB
08FC 08FD 08FE 08FF 0AFC 0AFD 0AFE 0AFF
0978 0979 097A 097B 0B78 0B79 0B7A 0B7B
097C 097D 097E 097F 0B7C 0B7D 0B7E 0B7F
09F8 09F9 09FA 09FB 0BF8 0BF9 0BFA 0BFB
09FC 09FD 09FE 09FF 0BFC 0BFD 0BFE 0BFF
2. Wait until out of VBL.
3. Enable character image downloading ($C0DB) and VBL interrupts (by
storing $90 into $FFEE).
3. Wait until after next VBL and repeat from 1. for the next 8
characters until all have been downloaded.
SOS uses a VBL interrupt routine to perform these tasks, but they
could be done by polling VBL for shorter code.
After downloading is complete, character image downloading should
be disabled ($C0DA).
The scheme seems complex (like Apple II screen buffer addressing),
but there is an elegance and economy in the hardware required to
support it.
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."