Microsoft Softcard and IIgs
vladitx
doesn't work. When trying to load CP/M the computer hangs and then
cold restart with CTRL+F1+RESET is slow and funny. I guess some fight
on the bus happening.
Softcard tried in slot5 and control panel set to "Your Card". Is the
slot number inappropriate?
Steven Hirsch
_Some_ Softcards will work in _some_ IIgs machines if, and only if, you set
the speed to normal in the control panel.
On a ROM 3, you might not have to set the control panel to "Your Card", but I
won't swear to it.
vladitx
> _Some_ Softcards will work in _some_ IIgs machines if, and only if, you set
> the speed to normal in the control panel.
This one seems not to work in my particular IIgs.
> On a ROM 3, you might not have to set the control panel to "Your Card", but I
> won't swear to it.
Tried both, same result. Same for fast/normal speed.
Steven Hirsch
If you want to run CP/M on the IIgs, consider picking up a Freed Z80 card (or
fabricating one yourself). The Applicard style of board runs just fine in a
IIgs and cooperates with accelerator cards.
vladitx
> If you want to run CP/M on the IIgs, consider picking up a Freed Z80 card (or
> fabricating one yourself). The Applicard style of board runs just fine in a
> IIgs and cooperates with accelerator cards.
I was more wondering why Softcard is failing in the IIgs. My CP/M
experience is zero, but Applicard could be interesting nonetheless.
I take it that Applicard is the best type? Where can I read summary
about existing Z80-based cards and existing CP/M versions for Apple
II, and compatibility between them, important features, etc?
In other words, is there good source of information about the
evolution of CP/M on the Apple II? Would make fine reading for me.
Michael J. Mahon
> On Mar 10, 1:11 pm, Steven Hirsch <snhir...@gmail.com> wrote:
>
>> If you want to run CP/M on the IIgs, consider picking up a Freed Z80 card (or
>> fabricating one yourself). The Applicard style of board runs just fine in a
>> IIgs and cooperates with accelerator cards.
>
> I was more wondering why Softcard is failing in the IIgs. My CP/M
> experience is zero, but Applicard could be interesting nonetheless.
The clocking of the Softcard is very clever, and a very unusual
"syncopated" clock. It interacts with the Apple II by stealing
DMA cycles, and therefore exercises areas of slot timing to their
limits.
The timing margin limits of some cards go beyond the timing margin
limits of some Apple II's--particularly post-][+ Apple II's.
-michael
******** Note new website URL ********
NadaNet and AppleCrate II for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
vladitx
> The clocking of the Softcard is very clever, and a very unusual
> "syncopated" clock. It interacts with the Apple II by stealing
> DMA cycles, and therefore exercises areas of slot timing to their
> limits.
>
> The timing margin limits of some cards go beyond the timing margin
> limits of some Apple II's--particularly post-][+ Apple II's.
My guess too, some timing violation must occur. Softcard must have
been designed around 1980-1981, so is based around the venerable II+.
Sather has investigated the change in slot timing between II and IIe,
including the changes 65C02 introduces. But this card works in an
enhanced IIe, so the changes in IIgs must be even bigger. Or DMA
handling in IIgs is stumbled by the card.
Any II / IIe cards using DMA known to be working ok in IIgs?
Alex Freed
> On Mar 12, 12:17 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>> The clocking of the Softcard is very clever, and a very unusual
>> "syncopated" clock. It interacts with the Apple II by stealing
>> DMA cycles, and therefore exercises areas of slot timing to their
>> limits.
>>
>> The timing margin limits of some cards go beyond the timing margin
>> limits of some Apple II's--particularly post-][+ Apple II's.
>
> My guess too, some timing violation must occur. Softcard must have
> been designed around 1980-1981, so is based around the venerable II+.
I'm not sure the issue is so subtle. What happens is that since the
SoftCard and clones use Apple's main memory, they can only do so
during the 500ns when the 6502 normally does it but not the "video"
500ns.
Applicard on the other hand has its own memory and only talks to
the 6502 via a pair of registers. The way the "busy" flags are
implemented it doesn't matter if z80 runs at 20 MHz and 6502 at 1 MHz as
is the case with my kind-of-replica card. By the same token the Apple
can also run at any accelerated speed.
I have a ROM1 GS and a SoftCard clone. If you want I can test it.
-Alex.
vladitx
> I'm not sure the issue is so subtle. What happens is that since the
> SoftCard and clones use Apple's main memory, they can only do so
> during the 500ns when the 6502 normally does it but not the "video"
> 500ns.
Yep, the phi0 portion.
IIgs goes way more complex with the MegaII/FPI bridging.
> Applicard on the other hand has its own memory and only talks to
> the 6502 via a pair of registers. The way the "busy" flags are
> implemented it doesn't matter if z80 runs at 20 MHz and 6502 at 1 MHz as
> is the case with my kind-of-replica card. By the same token the Apple
> can also run at any accelerated speed.
Definitely the PCPI design takes the least-resistance path and
decouples the Apple II and the Z80 system as much as possible, at the
cost of losing the direct access to Apple II memory.
I'd guess that screen scroll suffers from this. Another guess is that
probably GBASIC doesn't work on Applicard?
> I have a ROM1 GS and a SoftCard clone. If you want I can test it.
01 and 03 should be identical in the slot operations, but yes, if you
find the spare cycles and feel interested - please do.
I will dedicate a day (no plans, though) to plug the analyzer in IIe
and IIgs and see what's wrong. M$ SoftCard is the only DMA card I have
so far.
Alex Freed
>
> I'd guess that screen scroll suffers from this.
Maybe it does, but it doesn't have to. In fact I think it could be made
to work much faster than with the shared memory.
Suppose the whole "terminal emulator" is implemented on 6502 - maybe
just the ROM routines are used. Then the z80 will only issue a (single
byte?) command "scroll the screen" and continue whatever it was doing
while the 6502 does the scrolling at the same time. It will finish and
signal "ready" to z80 to process the next request.
>Another guess is that
> probably GBASIC doesn't work on Applicard?
I think I read that some trick allows MS basic to work but no graphics.
-Alex.
Steven Hirsch
> Definitely the PCPI design takes the least-resistance path and
> decouples the Apple II and the Z80 system as much as possible, at the
> cost of losing the direct access to Apple II memory.
And why is that a problem?
> I'd guess that screen scroll suffers from this. Another guess is that
> probably GBASIC doesn't work on Applicard?
Actually, with a good software implementation the screen scrolling is far
quicker with a decoupled coprocessor. The host processor has control all the
time and simply needs to read bytes from a port and write them to the screen.
With the softcard, regardless of who is writing to the screen (and I don't
recall offhand whether this is 6502 or Z80 code) they share bus cycles with
the other guy.
PCPI actually missed a few opportunities for improving performance in this
area, but out of the box it's quicker than a softcard. When I did the
CardZ180 BIOS, I was able to able to trim a lot of overhead from screen output
and it could easily keep up with a 19k2 baud modem. Stock Applicard would
drop characters in this mode and the Softcard was hopeless.
Add an accelerator to the host and sky's the limit. You cannot use an
accelerator with a DMA device. Applicard works with any accelerator on any
version of the A2.
>> I have a ROM1 GS and a SoftCard clone. If you want I can test it.
>
> 01 and 03 should be identical in the slot operations, but yes, if you
> find the spare cycles and feel interested - please do.
>
> I will dedicate a day (no plans, though) to plug the analyzer in IIe
> and IIgs and see what's wrong. M$ SoftCard is the only DMA card I have
> so far.
There were very few A2 cards that used DMA. The only others I can think of
are the Transwarp I (DMA with a vengeance - once it grabs on, it doesn't ever
let go) and the Vista 8" floppy controller.
Steve
vladitx
> Maybe it does, but it doesn't have to. In fact I think it could be made
> to work much faster than with the shared memory.
> Suppose the whole "terminal emulator" is implemented on 6502 - maybe
> just the ROM routines are used. Then the z80 will only issue a (single
> byte?) command "scroll the screen" and continue whatever it was doing
> while the 6502 does the scrolling at the same time. It will finish and
> signal "ready" to z80 to process the next request.
Definitely the proper way to do terminal emulation. To extend it
further, a single bit in "commands" may indicate whether they need
synchronisation at every transaction (e.g. allow buffering).
> >Another guess is that
> > probably GBASIC doesn't work on Applicard?
>
> I think I read that some trick allows MS basic to work but no graphics.
This could be the text-only MBASIC.
vladitx
> vladitx wrote:
> > Definitely the PCPI design takes the least-resistance path and
> > decouples the Apple II and the Z80 system as much as possible, at the
> > cost of losing the direct access to Apple II memory.
>
> And why is that a problem?
It's a "cost", not a problem per se. :-)
Z80 loses all (direct) Apple hardware, including video. On the other
hand if done with a proper driver API (and reasonable transfer speed)
it gains sort of portability.
> Actually, with a good software implementation the screen scrolling is far
> quicker with a decoupled coprocessor. The host processor has control all the
> time and simply needs to read bytes from a port and write them to the screen.
> With the softcard, regardless of who is writing to the screen (and I don't
> recall offhand whether this is 6502 or Z80 code) they share bus cycles with
> the other guy.
Agreed. AFAIR with SoftCard the 6502 is mostly idle, doing only disk I/
O (but I could be totally wrong here).
> PCPI actually missed a few opportunities for improving performance in this
> area, but out of the box it's quicker than a softcard. When I did the
> CardZ180 BIOS, I was able to able to trim a lot of overhead from screen output
> and it could easily keep up with a 19k2 baud modem. Stock Applicard would
> drop characters in this mode and the Softcard was hopeless.
Agreed again. I can understand why Applicard has it's own UART.
> Add an accelerator to the host and sky's the limit. You cannot use an
> accelerator with a DMA device. Applicard works with any accelerator on any
> version of the A2.
The IIgs case is an example of accelerator and DMA, but I guess it's
DMA is different than the original II.
> There were very few A2 cards that used DMA. The only others I can think of
> are the Transwarp I (DMA with a vengeance - once it grabs on, it doesn't ever
> let go) and the Vista 8" floppy controller.
Useful info, thanks.
Steven Hirsch
> Agreed again. I can understand why Applicard has it's own UART.
Actually, precious few Applicards ever had the UART piggyback. I own one of
perhaps a half-dozen in existence. The vast majority relied on the trusty
SuperSerial card on the host. So, you had data going from host to slave
processor, followed by screen output going back the other way. It was still
much faster than the Softcard.
The CardZ180 did have on-board UARTs, since the 64180/Z180 has two built-in.
Steve
Steven Hirsch
> vladitx wrote:
>>
>> I'd guess that screen scroll suffers from this.
>
> Maybe it does, but it doesn't have to. In fact I think it could be made
> to work much faster than with the shared memory.
> Suppose the whole "terminal emulator" is implemented on 6502 - maybe
> just the ROM routines are used. Then the z80 will only issue a (single
> byte?) command "scroll the screen" and continue whatever it was doing
> while the 6502 does the scrolling at the same time. It will finish and
> signal "ready" to z80 to process the next request.
Unfortunately, the stock Applicard OS is too dumb to do this asynchronously.
I implemented something like that to speed up the CardZ180, though.
>> Another guess is that
>> probably GBASIC doesn't work on Applicard?
I honestly don't know. I would sooner saw off my left arm than use BASIC for
anything, so I'm the wrong person to answer that.
> I think I read that some trick allows MS basic to work but no graphics.
I'm guessing that Microsoft used the same hack in all tools shipped with the
Softcard to prevent them from working in other environments. I have seen
patches for Microsoft Fortran and the ALDS cross-assembler to work around it
(the latter is absolutely vital to setting up a native build environment, IMHO).
Michael J. Mahon
> Alex Freed wrote:
>> vladitx wrote:
>>>
>>> I'd guess that screen scroll suffers from this.
>>
>> Maybe it does, but it doesn't have to. In fact I think it could be
>> made to work much faster than with the shared memory.
>> Suppose the whole "terminal emulator" is implemented on 6502 - maybe
>> just the ROM routines are used. Then the z80 will only issue a (single
>> byte?) command "scroll the screen" and continue whatever it was doing
>> while the 6502 does the scrolling at the same time. It will finish and
>> signal "ready" to z80 to process the next request.
>
> Unfortunately, the stock Applicard OS is too dumb to do this
> asynchronously. I implemented something like that to speed up the
> CardZ180, though.
Why does the Z80 card even need to know about it? The 6502 code
could always buffer output and appear "ready" unless the buffer is
full. Of course, that's one more copy to get it in the right place
in the screen buffer...
>>> Another guess is that
>>> probably GBASIC doesn't work on Applicard?
>
> I honestly don't know. I would sooner saw off my left arm than use
> BASIC for anything, so I'm the wrong person to answer that.
>
>> I think I read that some trick allows MS basic to work but no graphics.
>
> I'm guessing that Microsoft used the same hack in all tools shipped with
> the Softcard to prevent them from working in other environments. I have
> seen patches for Microsoft Fortran and the ALDS cross-assembler to work
> around it (the latter is absolutely vital to setting up a native build
> environment, IMHO).
In this case, it's simply a matter of the Z80 graphics routines not
having access to the Apple II screen buffer in RAM. A driver could
be written to have the 6502 "proxy" graphics updates, but that would
be relatively slow in comparison with DMA access.
Michael J. Mahon
> vladitx wrote:
>
>> Definitely the PCPI design takes the least-resistance path and
>> decouples the Apple II and the Z80 system as much as possible, at the
>> cost of losing the direct access to Apple II memory.
>
> And why is that a problem?
Speed, since it requires a 6502 "proxy" and a handshake to access
Apple II memory locations, for text, graphics, or memory-mapped I/O.
The Apple II architecture is designed to be controlled by accesses to
memory addresses, sometimes precisely timed. Interposing interprocessor
communication has serious speed effects when Apple II state must be
changed.
>> I'd guess that screen scroll suffers from this. Another guess is that
>> probably GBASIC doesn't work on Applicard?
>
> Actually, with a good software implementation the screen scrolling is
> far quicker with a decoupled coprocessor. The host processor has
> control all the time and simply needs to read bytes from a port and
> write them to the screen. With the softcard, regardless of who is
> writing to the screen (and I don't recall offhand whether this is 6502
> or Z80 code) they share bus cycles with the other guy.
I agree that using multiprocessing speedup for scrolling is a win,
compared to doing it all on one processor or the other. As you note,
there are severe interference effects with the Softcard, but it also
allows the 6502 to make progress while the Z80 is running, since the
Z80 doesn't make use of all of the memory access slots.
> PCPI actually missed a few opportunities for improving performance in
> this area, but out of the box it's quicker than a softcard. When I did
> the CardZ180 BIOS, I was able to able to trim a lot of overhead from
> screen output and it could easily keep up with a 19k2 baud modem. Stock
> Applicard would drop characters in this mode and the Softcard was hopeless.
And the fact that it runs the Z80 almost twice as fast as the Softcard
is certainly a factor!
> Add an accelerator to the host and sky's the limit. You cannot use an
> accelerator with a DMA device. Applicard works with any accelerator on
> any version of the A2.
For me, this is a huge advantage. It's too bad that most accelerators
were not implemented with DMA compatibility (though I know it would have
complicated them).
>>> I have a ROM1 GS and a SoftCard clone. If you want I can test it.
>>
>> 01 and 03 should be identical in the slot operations, but yes, if you
>> find the spare cycles and feel interested - please do.
>>
>> I will dedicate a day (no plans, though) to plug the analyzer in IIe
>> and IIgs and see what's wrong. M$ SoftCard is the only DMA card I have
>> so far.
>
> There were very few A2 cards that used DMA. The only others I can think
> of are the Transwarp I (DMA with a vengeance - once it grabs on, it
> doesn't ever let go) and the Vista 8" floppy controller.
Actually, any DMA device in the Apple II must "let go" frequently
to prevent the 6502 from losing its dynamic state. Woz did some
experiments and found that typical 6502s could tolerate much longer
"holds" than were specified, but the time was temperature- (leakage-)
dependent, so holding it longer than factory specs is iffy.
Alex Freed
>
> I agree that using multiprocessing speedup for scrolling is a win,
> compared to doing it all on one processor or the other. As you note,
> there are severe interference effects with the Softcard, but it also
> allows the 6502 to make progress while the Z80 is running, since the
> Z80 doesn't make use of all of the memory access slots.
>
AFAIK 6502 was always held off-line while z80 was running. The only
exception was a z80 "memory refresh" cycle when 6502 was given a chance
to fetch a byte to refresh its dynamic registers, byte this byte was
ignored anyway as "ready" was not asserted.
-Alex.
Alex Freed
>
> I agree that using multiprocessing speedup for scrolling is a win,
> compared to doing it all on one processor or the other. As you note,
> there are severe interference effects with the Softcard, but it also
> allows the 6502 to make progress while the Z80 is running, since the
> Z80 doesn't make use of all of the memory access slots.
>
AFAIK 6502 was always held off-line while z80 was running. The only
exception was a z80 "memory refresh" cycle when 6502 was given a chance
to fetch a byte to refresh its dynamic registers, but this byte was
Steven Hirsch
>> Unfortunately, the stock Applicard OS is too dumb to do this
>> asynchronously. I implemented something like that to speed up the
>> CardZ180, though.
>
> Why does the Z80 card even need to know about it? The 6502 code
> could always buffer output and appear "ready" unless the buffer is
> full. Of course, that's one more copy to get it in the right place
> in the screen buffer...
<shrug> I don't know why Wink didn't take more advantage of asynchronous I/O.
The only things buffered were keyboard input and printer output.
I took pains in the CardZ180 host BIOS to optimize throughput, but I honestly
cannot recall all the fine points. I'm still reacquainting myself with the
environment. Never honestly thought anyone would be interested in such things
after 20+ years!
Steve
Steven Hirsch
>> And why is that a problem?
>
> Speed, since it requires a 6502 "proxy" and a handshake to access
> Apple II memory locations, for text, graphics, or memory-mapped I/O.
>
> The Apple II architecture is designed to be controlled by accesses to
> memory addresses, sometimes precisely timed. Interposing interprocessor
> communication has serious speed effects when Apple II state must be
> changed.
All I can tell you is that I never found things slow with an Applicard. I was
doing a lot of software development on such a system and assemble + link
operations were at least 4x faster than on a Softcard.
mdj
> > Add an accelerator to the host and sky's the limit. You cannot use an
> > accelerator with a DMA device. Applicard works with any accelerator on
> > any version of the A2.
>
> For me, this is a huge advantage. It's too bad that most accelerators
> were not implemented with DMA compatibility (though I know it would have
> complicated them).
For Zip Chips, it always struck me as odd, since the cache writes
through via a buffer. The DMA setup time should have been adequate to
dump the write buffer. All it needed to do then was flag the cache as
dirty.
Of course, a better implementation could have used /INH to make the
cache 'visible' to a DMA peripheral but that requires a slot, or at
the very least, a tap to the relevant signal...
> >>> I have a ROM1 GS and a SoftCard clone. If you want I can test it.
>
> >> 01 and 03 should be identical in the slot operations, but yes, if you
> >> find the spare cycles and feel interested - please do.
>
> >> I will dedicate a day (no plans, though) to plug the analyzer in IIe
> >> and IIgs and see what's wrong. M$ SoftCard is the only DMA card I have
> >> so far.
>
> > There were very few A2 cards that used DMA. The only others I can think
> > of are the Transwarp I (DMA with a vengeance - once it grabs on, it
> > doesn't ever let go) and the Vista 8" floppy controller.
>
> Actually, any DMA device in the Apple II must "let go" frequently
> to prevent the 6502 from losing its dynamic state. Woz did some
> experiments and found that typical 6502s could tolerate much longer
> "holds" than were specified, but the time was temperature- (leakage-)
> dependent, so holding it longer than factory specs is iffy.
That only applies to the older NMOS 6502's though, right?
Matt
David Wilson
The Rockwell R65C02 data-sheet says:
phi2 cycle time Max: R65C02 and R65C102 minimum operating frequency is
limited by phi2 low pulse width. All processors can be stopped with
phi2 held high.
phi2 Low Pulse Width: Max 5000ns
mdj
> > That only applies to the older NMOS 6502's though, right?
>
> The Rockwell R65C02 data-sheet says:
>
> phi2 cycle time Max: R65C02 and R65C102 minimum operating frequency is
> limited by phi2 low pulse width. All processors can be stopped with
> phi2 held high.
>
> phi2 Low Pulse Width: Max 5000ns
So the question is, does phi2 get held high?
David Wilson
Unfortunately, no.
The DMA' signal must be asserted during phase 1 of the 65(c)02 cycle
(when phase 0 (and phase 2) are low).
On a IIe with X5 and X4 left in the default state, phi0 = not(DMA or
PHI1) which is low when DMA is true.
If X5 and X4 are cut and soldered respectively, phi0 is no longer
gated by DMA'. You then need to ensure READY is deasserted to prevent
the 65(c)02 from executing instructions while DMA is active. See page
G-3 of Jim Sather's Understanding the Apple IIe.
The IIgs Hardware Reference (chapter 8) shows DMA being asserted
during the 1st half of the Apple II cycle and remaining asserted until
the start of the next cycle. It does not mention the possibility of
holding DMA asserted for more than one cycle.
Michael J. Mahon
> On Mar 13, 4:55 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>>> Add an accelerator to the host and sky's the limit. You cannot use an
>>> accelerator with a DMA device. Applicard works with any accelerator on
>>> any version of the A2.
>> For me, this is a huge advantage. It's too bad that most accelerators
>> were not implemented with DMA compatibility (though I know it would have
>> complicated them).
>
> For Zip Chips, it always struck me as odd, since the cache writes
> through via a buffer. The DMA setup time should have been adequate to
> dump the write buffer. All it needed to do then was flag the cache as
> dirty.
I think the problem is that DMA is the only case of something besides
the processor writing to memory.
This means that if DMA can be ignored, the cache logic only has to
pay attention to addresses generated by the processor, not addresses
that appear on the bus. Since the processor is synchronous with the
cache logic, this side is easy. Snooping bus addresses would have
been a completely new address datapath running between the two clock
domains.
Since prior to the introduction of the High-Speed SCSI card, the
penetration of DMA into the Apple II world was extremely low, it
was an understandable decision to forego DMA compatibility to
achieve a significant simplification.
Then there's the problem that DMA is not directly signaled to the
pins of the 6502 socket... ;-)
mdj
Yeah... That's why I thought a 'dumb' method like detect DMA and flag
cache dirty might work, but it now occurs to me that syncronising the
cpu 'pause' (which I board might do by deasserting RDY before
asserting DMA) is nigh on impossible across two clock domains :-(
> Then there's the problem that DMA is not directly signaled to the
> pins of the 6502 socket... ;-)
Right. I had thought a timer that is reset by the PH0 clock could be
used to detect DMA, but it does seem like it's a lot more complicated
that I first thought.
The good news is, in ProDOS 8 it doesn't matter much. Since all I/O is
done a block at a time, there's enough handshaking slowing things down
between block requests that an accelerated II gets close to the same
performance without DMA active, at least for the modest I/O requests
that happen in Apple II programs.
Matt
Michael J. Mahon
That's been my experience as well--I haven't really missed DMA.