Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » HW issues found in AppleII machines & cards
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
HW issues found in AppleII machines & cards [message #377737] Sun, 09 December 2018 00:02 Go to next message
Anonymous
Karma:
Originally posted by: jbrooks

While making VidHD, the dev team ran across several hardware problems in various Apple II machines and interface cards. The issues are listed below to help others who develop hardware for the Apple II platform.


1) Apple II, II+ DRAM read timing

The DRAMs read timing is just barely fast enough to make the 6502's timing requirements. It appears that for slot cards, the data bus has additional delay compared to PH0, so cards that latch the data bus at PH0 falling edge will often read incorrect values.

VidHD works around this problem by latching the data bus slightly after PH0 falling edge. Note that on the IIe & GS VidHD latches immediately at PH0 falling edge. On the IIGS delayed reads of the data bus can fail since the bank address is multiplexed onto the data bus shortly after PH0 falling edge..

BTW: The video pipeline for mode/page changes is 1 cycle shorter on the II,II+ than the IIe, GS.


2) Apple II, II+ 7M signal unstable at power up

It can take the 7M signal a long time to become stable at power up on early machines. VidHD works around this by using an internal clock until the 6502 comes out of reset, then switching over from the internal clock to using 7M w/PLL.


3) IIe accelerator DMA

Both FASTchip //e and AE Transwarp IIe use the bus 100% of the time, locking out any other card from doing DMA. I've tried using the DMAIN signal to tell the accelerator that a higher-priority card needs to do DMA, but these accelerators do not appear to follow Apple's DMAIN/DMAOUT priority spec. They hold the bus even when slowed to 1MHz and during RESET.

VidHD partially works around DMA lock-out by disabling DMA-based features ($Cs00 firmware, machine-detect, VRAM/video mode detect, and ctrl-panel key-read DMA).


4) RamFast SCSI DMA

The RamFast card supports DMAIN/DMAOUT, but is missing a pull-up on DMAIN. This means that if the DMAIN line is floating due to no card in the next lower slot, the FamFast's DMAOUT will incorrectly be low (active) all the time, locking out DMA for the card(s) in higher slots.


5) GS ROM3 DMA after reset

On the ROM3 GS, a bus fight occurs when a memory expansion card w/ROM disk and a slot card DMA is started within a few cycles of coming out of reset. I believe it's a bug in the CYA chip (and possibly FPI) where early DMA causes the CYA/FPI to incorrectly enable the memory card's ROM access, resulting in both the slot card DMA and ROM disk driving the bus = bus fight.

VidHD works around this by waiting until the speaker beep before starting a DMA. This allows the GS firmware to properly configure the CYA/FPI before a DMA occurs.


6) ZipGS RDY line bug

When a slot card pulls RDY low, there is about a 1/1000 chance that the ZipGS will ignore/miss it, causing corruption of the internal ZipGS cache.


-JB
Twitter: @JBrooksBSI
HW issues found in AppleII machines & cards [message #377808 is a reply to message #377737] Sun, 09 December 2018 14:34 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: dmrogers99

John, the implications of DMA lockout on accelerated //e machines are unclear to me. What will I observe as a user? I have 2 machines I use, one with a TW the other with a FastChip.

Thanks,
Dave Rogers
Re: HW issues found in AppleII machines & cards [message #377814 is a reply to message #377737] Sun, 09 December 2018 17:26 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
<jbrooks@blueshiftinc.com> wrote:
> While making VidHD, the dev team ran across several hardware problems in
> various Apple II machines and interface cards. The issues are listed
> below to help others who develop hardware for the Apple II platform.
>
>
> 1) Apple II, II+ DRAM read timing
>
> The DRAMs read timing is just barely fast enough to make the 6502's
> timing requirements. It appears that for slot cards, the data bus has
> additional delay compared to PH0, so cards that latch the data bus at PH0
> falling edge will often read incorrect values.
>
> VidHD works around this problem by latching the data bus slightly after
> PH0 falling edge. Note that on the IIe & GS VidHD latches immediately at
> PH0 falling edge. On the IIGS delayed reads of the data bus can fail
> since the bank address is multiplexed onto the data bus shortly after PH0 falling edge.
>
> BTW: The video pipeline for mode/page changes is 1 cycle shorter on the
> II,II+ than the IIe, GS.
>
>
> 2) Apple II, II+ 7M signal unstable at power up
>
> It can take the 7M signal a long time to become stable at power up on
> early machines. VidHD works around this by using an internal clock until
> the 6502 comes out of reset, then switching over from the internal clock to using 7M w/PLL.
>
>
> 3) IIe accelerator DMA
>
> Both FASTchip //e and AE Transwarp IIe use the bus 100% of the time,
> locking out any other card from doing DMA. I've tried using the DMAIN
> signal to tell the accelerator that a higher-priority card needs to do
> DMA, but these accelerators do not appear to follow Apple's DMAIN/DMAOUT
> priority spec. They hold the bus even when slowed to 1MHz and during RESET.
>
> VidHD partially works around DMA lock-out by disabling DMA-based features
> ($Cs00 firmware, machine-detect, VRAM/video mode detect, and ctrl-panel key-read DMA).
>
>
> 4) RamFast SCSI DMA
>
> The RamFast card supports DMAIN/DMAOUT, but is missing a pull-up on
> DMAIN. This means that if the DMAIN line is floating due to no card in
> the next lower slot, the FamFast's DMAOUT will incorrectly be low
> (active) all the time, locking out DMA for the card(s) in higher slots.
>
>
> 5) GS ROM3 DMA after reset
>
> On the ROM3 GS, a bus fight occurs when a memory expansion card w/ROM
> disk and a slot card DMA is started within a few cycles of coming out of
> reset. I believe it's a bug in the CYA chip (and possibly FPI) where
> early DMA causes the CYA/FPI to incorrectly enable the memory card's ROM
> access, resulting in both the slot card DMA and ROM disk driving the bus = bus fight.
>
> VidHD works around this by waiting until the speaker beep before starting
> a DMA. This allows the GS firmware to properly configure the CYA/FPI before a DMA occurs.
>
>
> 6) ZipGS RDY line bug
>
> When a slot card pulls RDY low, there is about a 1/1000 chance that the
> ZipGS will ignore/miss it, causing corruption of the internal ZipGS cache.
>
>
> -JB
> Twitter: @JBrooksBSI
>

Sounds like a confirmation of the observation that whatever is not widely
used/tested probably doesn’t work properly. ;-(

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: HW issues found in AppleII machines & cards [message #377826 is a reply to message #377808] Sun, 09 December 2018 18:43 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: jbrooks

On Sunday, December 9, 2018 at 11:34:23 AM UTC-8, dmrog...@yahoo.com wrote:
> John, the implications of DMA lockout on accelerated //e machines are unclear to me. What will I observe as a user? I have 2 machines I use, one with a TW the other with a FastChip.
>
> Thanks,
> Dave Rogers

CPU accelerators which plug into the CPU socket seem to be DMA compatible, while those which are slot-only seem to lock out all other DMA unless they are 'turned off'.

Without DMA access, VidHD cannot check find the Apple II model or beam position.

Currently when DMA is locked out at power up, VidHD brings up it's control panel screen and reports 'DMA locked out'. Normally VidHD uses DMA to pause the CPU during the control panel screen and read the keyboard, but when DMA is locked out, keystrokes typed while in VidHD's control panel are also used by the currently running program (BASIC, etc).

Pressing Esc, Return or Reset exits the ctrl-panel and displays the Apple II video at 1080p.

Even with DMA locked out, VidHD can still do it's primary job of observing the CPU accelerator's writes to VRAM/softswitches and generating 1080p video like normal, but the VidHD beam position will not match the motherboard/CRT beam position since that is read at startup via DMA. Beam position mismatch is not usually noticeable except in race-the-beam tech demos like French Touch, or 60 FPS games which sync to vblank, which can have more visible tearing during scrolling.

VidHD's 80-column firmware (largely intended for the II and II+) will be disabled since it relies on DMA. This also disables firmware access to the high-res text modes (80x45, 120x67, 240x135). When DMA is locked out, VidHD generates 40-col & 80-col text by observing the IIe $C300 firmware writes to main/aux $400-$7FF like normal.

GS super-hires graphics modes are still available when DMA is locked out.

Below is a video from July 2018 of VidHD running Wavy Navy at 16 MHz on a FastChip IIe with DMA locked out. The vertical line at the left edge has since been fixed.

https://www.youtube.com/watch?v=GZ0OzjJcJeA

-JB
@JBrooksBSI
HW issues found in AppleII machines & cards [message #377868 is a reply to message #377737] Mon, 10 December 2018 04:29 Go to previous messageGo to next message
cybernesto is currently offline  cybernesto
Messages: 78
Registered: June 2013
Karma: 0
Member
It is amazing how much effort you have put into this project John. Thank you so much for this awesome card.
Re: HW issues found in AppleII machines & cards [message #377870 is a reply to message #377868] Mon, 10 December 2018 04:56 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: jbrooks

On Monday, December 10, 2018 at 1:29:52 AM UTC-8, cybernesto wrote:
> It is amazing how much effort you have put into this project John. Thank you so much for this awesome card.

Thanks! The Apple II and community are worth it.

Good thing I didn't know how complex this was going to be when I started though...

-JB
@JBrooksBSI
Re: HW issues found in AppleII machines & cards [message #377889 is a reply to message #377870] Mon, 10 December 2018 11:18 Go to previous messageGo to next message
David Schmenk is currently offline  David Schmenk
Messages: 374
Registered: December 2012
Karma: 0
Senior Member
On Monday, 10 December 2018 01:56:40 UTC-8, jbr...@blueshiftinc.com wrote:
> On Monday, December 10, 2018 at 1:29:52 AM UTC-8, cybernesto wrote:
>> It is amazing how much effort you have put into this project John. Thank you so much for this awesome card.
>
> Thanks! The Apple II and community are worth it.
>
> Good thing I didn't know how complex this was going to be when I started though...
>
> -JB
> @JBrooksBSI

You're going to have to write a book with all your findings. "Brooks: *Really* Understanding the Apple II"
Re: HW issues found in AppleII machines & cards [message #377958 is a reply to message #377826] Mon, 10 December 2018 22:35 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
<jbrooks@blueshiftinc.com> wrote:
> On Sunday, December 9, 2018 at 11:34:23 AM UTC-8, dmrog...@yahoo.com wrote:
>> John, the implications of DMA lockout on accelerated //e machines are
>> unclear to me. What will I observe as a user? I have 2 machines I use,
>> one with a TW the other with a FastChip.
>>
>> Thanks,
>> Dave Rogers
>
> CPU accelerators which plug into the CPU socket seem to be DMA
> compatible, while those which are slot-only seem to lock out all other
> DMA unless they are 'turned off'.
>
<snip>

I expect that’s true only as long as no DMA writes are attempted, since
that would cause the memory content to be inconsistent with the
accelerator’s cache.

Unless the accelerator has access to the bus, it can’t see DMA accesses.

>
> -JB
> @JBrooksBSI
>



--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: HW issues found in AppleII machines & cards [message #378041 is a reply to message #377958] Tue, 11 December 2018 17:40 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: jbrooks

On Monday, December 10, 2018 at 7:35:56 PM UTC-8, Michael J. Mahon wrote:
> <jbrooks> wrote:
>> On Sunday, December 9, 2018 at 11:34:23 AM UTC-8, dmrog...@yahoo.com wrote:
>>> John, the implications of DMA lockout on accelerated //e machines are
>>> unclear to me. What will I observe as a user? I have 2 machines I use,
>>> one with a TW the other with a FastChip.
>>>
>>> Thanks,
>>> Dave Rogers
>>
>> CPU accelerators which plug into the CPU socket seem to be DMA
>> compatible, while those which are slot-only seem to lock out all other
>> DMA unless they are 'turned off'.
>>
> <snip>
>
> I expect that’s true only as long as no DMA writes are attempted, since
> that would cause the memory content to be inconsistent with the
> accelerator’s cache.
>
> Unless the accelerator has access to the bus, it can’t see DMA accesses.
>
>>
>> -JB
>> @JBrooksBSI
>>
>
>
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

True, but a cpu-socket-only accelerator could use BE (bus enable) to detect a DMA and flush it's caches, assuming it was using a write-through cache policy.

Ideally, accelerators would use both the card slot + cpu socket to watch DMA transfers and update their internal cache instead of just invalidating the entire cache.

-JB
Re: HW issues found in AppleII machines & cards [message #378077 is a reply to message #378041] Wed, 12 December 2018 01:56 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
<jbrooks@blueshiftinc.com> wrote:
> On Monday, December 10, 2018 at 7:35:56 PM UTC-8, Michael J. Mahon wrote:
>> <jbrooks> wrote:
>>> On Sunday, December 9, 2018 at 11:34:23 AM UTC-8, dmrog...@yahoo.com wrote:
>>>> John, the implications of DMA lockout on accelerated //e machines are
>>>> unclear to me. What will I observe as a user? I have 2 machines I use,
>>>> one with a TW the other with a FastChip.
>>>>
>>>> Thanks,
>>>> Dave Rogers
>>>
>>> CPU accelerators which plug into the CPU socket seem to be DMA
>>> compatible, while those which are slot-only seem to lock out all other
>>> DMA unless they are 'turned off'.
>>>
>> <snip>
>>
>> I expect that’s true only as long as no DMA writes are attempted, since
>> that would cause the memory content to be inconsistent with the
>> accelerator’s cache.
>>
>> Unless the accelerator has access to the bus, it can’t see DMA accesses.
>>
>>>
>>> -JB
>>> @JBrooksBSI
>>>
>>
>>
>>
>> --
>> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
>
> True, but a cpu-socket-only accelerator could use BE (bus enable) to
> detect a DMA and flush it's caches, assuming it was using a write-through cache policy.

I presume that’s a 65816 pin... 65x02’s have no such capability.

> Ideally, accelerators would use both the card slot + cpu socket to watch
> DMA transfers and update their internal cache instead of just
> invalidating the entire cache.

As far as I know, there are no such accelerators—certainly not for 8-bit
Apples. In fact, are there any that do the cache invalidation for DMA
writes?

General use of DMA is likely to expose numerous implementation errors in
peripheral cards, as you have observed.

Another systemic issue with processor-slot accelerators is their inability
to deal properly with /RDY stalls, which were commonly used to synchronize
FP coprocessors.

>
> -JB
>

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: HW issues found in AppleII machines & cards [message #378083 is a reply to message #378077] Wed, 12 December 2018 03:17 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: jbrooks

On Tuesday, December 11, 2018 at 10:57:01 PM UTC-8, Michael J. Mahon wrote:
> <jbrooks> wrote:
>> On Monday, December 10, 2018 at 7:35:56 PM UTC-8, Michael J. Mahon wrote:
>>> <jbrooks> wrote:
>>>> On Sunday, December 9, 2018 at 11:34:23 AM UTC-8, dmrog...@yahoo.com wrote:
>>>> > John, the implications of DMA lockout on accelerated //e machines are
>>>> > unclear to me. What will I observe as a user? I have 2 machines I use,
>>>> > one with a TW the other with a FastChip.
>>>> >
>>>> > Thanks,
>>>> > Dave Rogers
>>>>
>>>> CPU accelerators which plug into the CPU socket seem to be DMA
>>>> compatible, while those which are slot-only seem to lock out all other
>>>> DMA unless they are 'turned off'.
>>>>
>>> <snip>
>>>
>>> I expect that’s true only as long as no DMA writes are attempted, since
>>> that would cause the memory content to be inconsistent with the
>>> accelerator’s cache.
>>>
>>> Unless the accelerator has access to the bus, it can’t see DMA accesses.
>>>
>>>>
>>>> -JB
>>>> @JBrooksBSI
>>>>
>>>
>>>
>>>
>>> --
>>> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
>>
>> True, but a cpu-socket-only accelerator could use BE (bus enable) to
>> detect a DMA and flush it's caches, assuming it was using a write-through cache policy.
>
> I presume that’s a 65816 pin... 65x02’s have no such capability.
>
>> Ideally, accelerators would use both the card slot + cpu socket to watch
>> DMA transfers and update their internal cache instead of just
>> invalidating the entire cache.
>
> As far as I know, there are no such accelerators—certainly not for 8-bit
> Apples. In fact, are there any that do the cache invalidation for DMA
> writes?
>
> General use of DMA is likely to expose numerous implementation errors in
> peripheral cards, as you have observed.
>
> Another systemic issue with processor-slot accelerators is their inability
> to deal properly with /RDY stalls, which were commonly used to synchronize
> FP coprocessors.
>
>>
>> -JB
>>
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Yes, BE tristates the CPU address & data bus on a 65816. I don't know of any 6502,65c02 accelerators which detect DMA and invalidate their cache.

I know of the Zip Chip for II+ and IIe, and there were several DMA SCSI cards made for the II+, IIe, but I don't know how well they coexisted. My VidHD testing has been with a RamFast rev D, ZipGS, and FastChip IIe.

In theory, a 6502,65c02 accelerator could detect that ph0 was being held low >980ns due to DMA, and then flush it's internal write-through cache.

A simpler option for modern 6502 accelerators would be to support the DMAIN,DMAOUT priority system and yield the bus to neighboring DMA cards. It would also be nice to yield the bus on CPU internal/idle cycles, but likely more complex to implement.

Sather tells a funny story of how Woz's initial Apple II design used DMA to read out 40 video bytes each scanline, but after awhile Woz's 6502s would stop working. So he kept a supply of 'new' 6502 chips on hand to swap in as his used 6502's started losing their register state due to ph0 being stopped too long during DMA. This problem prompted Woz to switch to the 2MHz interleaved cpu/video shared memory approach.

BTW, when VidHD is put in slot 3 and DMA is available, the VidHD firmware uses DMA to greatly speed up calls to $C311 AUX_MOVE and $C314 AUX_XFER.

When DMA is not locked out, the VidHD control panel screen pauses the CPU via /RDY stalls and reads the keyboard via DMA, resuming the CPU at exit.

-JB
@JBrooksBSI
Re: HW issues found in AppleII machines & cards [message #378097 is a reply to message #378083] Wed, 12 December 2018 13:56 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
<jbrooks@blueshiftinc.com> wrote:
> On Tuesday, December 11, 2018 at 10:57:01 PM UTC-8, Michael J. Mahon wrote:
>> <jbrooks> wrote:
>>> On Monday, December 10, 2018 at 7:35:56 PM UTC-8, Michael J. Mahon wrote:
>>>> <jbrooks> wrote:
>>>> > On Sunday, December 9, 2018 at 11:34:23 AM UTC-8, dmrog...@yahoo.com wrote:
>>>> >> John, the implications of DMA lockout on accelerated //e machines are
>>>> >> unclear to me. What will I observe as a user? I have 2 machines I use,
>>>> >> one with a TW the other with a FastChip.
>>>> >>
>>>> >> Thanks,
>>>> >> Dave Rogers
>>>> >
>>>> > CPU accelerators which plug into the CPU socket seem to be DMA
>>>> > compatible, while those which are slot-only seem to lock out all other
>>>> > DMA unless they are 'turned off'.
>>>> >
>>>> <snip>
>>>>
>>>> I expect that’s true only as long as no DMA writes are attempted, since
>>>> that would cause the memory content to be inconsistent with the
>>>> accelerator’s cache.
>>>>
>>>> Unless the accelerator has access to the bus, it can’t see DMA accesses.
>>>>
>>>> >
>>>> > -JB
>>>> > @JBrooksBSI
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
>>>
>>> True, but a cpu-socket-only accelerator could use BE (bus enable) to
>>> detect a DMA and flush it's caches, assuming it was using a write-through cache policy.
>>
>> I presume that’s a 65816 pin... 65x02’s have no such capability.
>>
>>> Ideally, accelerators would use both the card slot + cpu socket to watch
>>> DMA transfers and update their internal cache instead of just
>>> invalidating the entire cache.
>>
>> As far as I know, there are no such accelerators—certainly not for 8-bit
>> Apples. In fact, are there any that do the cache invalidation for DMA
>> writes?
>>
>> General use of DMA is likely to expose numerous implementation errors in
>> peripheral cards, as you have observed.
>>
>> Another systemic issue with processor-slot accelerators is their inability
>> to deal properly with /RDY stalls, which were commonly used to synchronize
>> FP coprocessors.
>>
>>>
>>> -JB
>>>
>>
>> --
>> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
>
> Yes, BE tristates the CPU address & data bus on a 65816. I don't know of
> any 6502,65c02 accelerators which detect DMA and invalidate their cache.
>
> I know of the Zip Chip for II+ and IIe, and there were several DMA SCSI
> cards made for the II+, IIe, but I don't know how well they coexisted. My
> VidHD testing has been with a RamFast rev D, ZipGS, and FastChip IIe.

As far as I know, they didn’t. As a Zip Chip user (on a //e), I couldn’t
use DMA or /RDY-dependent cards.

> In theory, a 6502,65c02 accelerator could detect that ph0 was being held
> low >980ns due to DMA, and then flush it's internal write-through cache.

Yes, it could, but none do. No flush would be needed for a write-through
cache, but invalidation would be—a fairly performance-expensive approach.

> A simpler option for modern 6502 accelerators would be to support the
> DMAIN,DMAOUT priority system and yield the bus to neighboring DMA cards.
> It would also be nice to yield the bus on CPU internal/idle cycles, but
> likely more complex to implement.

....and requiring a slot. ;-)

> Sather tells a funny story of how Woz's initial Apple II design used DMA
> to read out 40 video bytes each scanline, but after awhile Woz's 6502s
> would stop working. So he kept a supply of 'new' 6502 chips on hand to
> swap in as his used 6502's started losing their register state due to ph0
> being stopped too long during DMA. This problem prompted Woz to switch to
> the 2MHz interleaved cpu/video shared memory approach.

I remember reading this story and being delighted that it forced the more
elegant (and better performing) approach. ;-)

> BTW, when VidHD is put in slot 3 and DMA is available, the VidHD firmware
> uses DMA to greatly speed up calls to $C311 AUX_MOVE and $C314 AUX_XFER.

A nice bonus!

> When DMA is not locked out, the VidHD control panel screen pauses the CPU
> via /RDY stalls and reads the keyboard via DMA, resuming the CPU at exit.

So how will this work with the Zip Chip (no DMA, no /RDY?

> -JB
> @JBrooksBSI
>



--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: HW issues found in AppleII machines & cards [message #378098 is a reply to message #378097] Wed, 12 December 2018 14:34 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: jbrooks

On Wednesday, December 12, 2018 at 10:56:07 AM UTC-8, Michael J. Mahon wrote:
> <jbrooks> wrote:
>> On Tuesday, December 11, 2018 at 10:57:01 PM UTC-8, Michael J. Mahon wrote:
>>> <jbrooks> wrote:
>>>> On Monday, December 10, 2018 at 7:35:56 PM UTC-8, Michael J. Mahon wrote:
>>>> > <jbrooks> wrote:
>>>> >> On Sunday, December 9, 2018 at 11:34:23 AM UTC-8, dmrog...@yahoo.com wrote:
>>>> >>> John, the implications of DMA lockout on accelerated //e machines are
>>>> >>> unclear to me. What will I observe as a user? I have 2 machines I use,
>>>> >>> one with a TW the other with a FastChip.
>>>> >>>
>>>> >>> Thanks,
>>>> >>> Dave Rogers
>>>> >>
>>>> >> CPU accelerators which plug into the CPU socket seem to be DMA
>>>> >> compatible, while those which are slot-only seem to lock out all other
>>>> >> DMA unless they are 'turned off'.
>>>> >>
>>>> > <snip>
>>>> >
>>>> > I expect that’s true only as long as no DMA writes are attempted, since
>>>> > that would cause the memory content to be inconsistent with the
>>>> > accelerator’s cache.
>>>> >
>>>> > Unless the accelerator has access to the bus, it can’t see DMA accesses.
>>>> >
>>>> >>
>>>> >> -JB
>>>> >> @JBrooksBSI
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
>>>>
>>>> True, but a cpu-socket-only accelerator could use BE (bus enable) to
>>>> detect a DMA and flush it's caches, assuming it was using a write-through cache policy.
>>>
>>> I presume that’s a 65816 pin... 65x02’s have no such capability.
>>>
>>>> Ideally, accelerators would use both the card slot + cpu socket to watch
>>>> DMA transfers and update their internal cache instead of just
>>>> invalidating the entire cache.
>>>
>>> As far as I know, there are no such accelerators—certainly not for 8-bit
>>> Apples. In fact, are there any that do the cache invalidation for DMA
>>> writes?
>>>
>>> General use of DMA is likely to expose numerous implementation errors in
>>> peripheral cards, as you have observed.
>>>
>>> Another systemic issue with processor-slot accelerators is their inability
>>> to deal properly with /RDY stalls, which were commonly used to synchronize
>>> FP coprocessors.
>>>
>>>>
>>>> -JB
>>>>
>>>
>>> --
>>> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
>>
>> Yes, BE tristates the CPU address & data bus on a 65816. I don't know of
>> any 6502,65c02 accelerators which detect DMA and invalidate their cache..
>>
>> I know of the Zip Chip for II+ and IIe, and there were several DMA SCSI
>> cards made for the II+, IIe, but I don't know how well they coexisted. My
>> VidHD testing has been with a RamFast rev D, ZipGS, and FastChip IIe.
>
> As far as I know, they didn’t. As a Zip Chip user (on a //e), I couldn’t
> use DMA or /RDY-dependent cards.
>
>> In theory, a 6502,65c02 accelerator could detect that ph0 was being held
>> low >980ns due to DMA, and then flush it's internal write-through cache..
>
> Yes, it could, but none do. No flush would be needed for a write-through
> cache, but invalidation would be—a fairly performance-expensive approach.
>

A flush is still needed since the internal cache state could be invalid after DMA writes to mem location that is contained in-cache, right?

DMA is typically done infrequently, so in practice I doubt that flushing the cache would have much impact on performance.

But this whole approach is not likely since the Zip Chip has not been recreated and modern accelerators use the slot approach.

>> A simpler option for modern 6502 accelerators would be to support the
>> DMAIN,DMAOUT priority system and yield the bus to neighboring DMA cards..
>> It would also be nice to yield the bus on CPU internal/idle cycles, but
>> likely more complex to implement.
>
> ...and requiring a slot. ;-)
>

Yes, and using DMA from a slot is probably the easiest approach. That's why I think the easiest 'fix' is to have DMA-based slot cards support the DMAIN/DMAOUT protocol so that more than a single DMA card can be installed in one machine.

>> Sather tells a funny story of how Woz's initial Apple II design used DMA
>> to read out 40 video bytes each scanline, but after awhile Woz's 6502s
>> would stop working. So he kept a supply of 'new' 6502 chips on hand to
>> swap in as his used 6502's started losing their register state due to ph0
>> being stopped too long during DMA. This problem prompted Woz to switch to
>> the 2MHz interleaved cpu/video shared memory approach.
>
> I remember reading this story and being delighted that it forced the more
> elegant (and better performing) approach. ;-)
>
>> BTW, when VidHD is put in slot 3 and DMA is available, the VidHD firmware
>> uses DMA to greatly speed up calls to $C311 AUX_MOVE and $C314 AUX_XFER..
>
> A nice bonus!
>
>> When DMA is not locked out, the VidHD control panel screen pauses the CPU
>> via /RDY stalls and reads the keyboard via DMA, resuming the CPU at exit.
>
> So how will this work with the Zip Chip (no DMA, no /RDY?
>

Good question. I'm not sure. When not using VidHD's slot 3, 80-col text driver, VidHD's DMAs are passive reads at startup which should not affect the Zip Chip cache.

Even VidHD's Control-Panel /RDY & DMA reads might work okay since the DMA is a passive read of the keyboard, and using /RDY to pause the CPU is more of a nicety than a crucial feature.

Worst-case, either disable the Zip Chip (go for FastChip w/cool speed knob), or ground the DMAIN line to VidHD so DMA isn't used.

Almost all of VidHD's functionality is coded on the ARM64, ARM32, or FPGA and can be tweaked with a software upgrade if needed.

>> -JB
>> @JBrooksBSI
>>
>
>
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: HW issues found in AppleII machines & cards [message #378152 is a reply to message #378083] Thu, 13 December 2018 12:45 Go to previous message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
In article <4018938a-5934-44b9-80d5-df13bc11b838@googlegroups.com>,
<jbrooks@blueshiftinc.com> wrote:
> I know of the Zip Chip for II+ and IIe, and there were several DMA SCSI
> cards made for the II+, IIe, but I don't know how well they coexisted.
> My VidHD testing has been with a RamFast rev D, ZipGS, and FastChip IIe.

At one time, probably 25 years or so ago now, I had a 10-MHz RocketChip
(like the ZipChip, but faster) and a rev. C RamFAST installed in a IIe. I
had to turn off DMA on the RamFAST to get it to work.

(I still have the RamFAST, but my IIGS currently has an Apple High-Speed
SCSI Card installed because I couldn't get a CD-ROM drive working with the
RamFAST. The RocketChip got sold off shortly after I upgraded the IIe to a
IIGS.)

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Basic program question
Next Topic: New GBBS Pro game
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 04:11:35 EDT 2024

Total time taken to generate the page: 1.38774 seconds