Bigram 2630 & GVP HC Series II

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • I know this isn't an issue with the Bigram but just wondering if anyone has any advice. When I install the Bigram none of the Hard drives I have hooked up to my GVP HC-II SCSI controller show up.


    The board itself still shows up in the autoconfig information in SysInfo, but none of the devices attached to it are accessible.

    Screenshots:



    Bigram:




    I think I may have had the same problem without the bigram but trying to use a Microbotics 8Up! Memory board. Is there something I'm missing that might make the GVP HC-II get along with other ram? It doesn't mind the 2MB on the 2630 itself so I thought it wouldn't mind the bigram attached to the 2630 but it appears I am incorrect.


    Here is what GVP Info has to say about the 2 boards:




    The memory config for all 3 pools:




    Thanks for any help anyone can offer.

  • The GVP controller is a DMA controller, but there is no data path for DMA to reach the "big" fastmem, as that's outside the 24-bit address area that is reachable by DMA.


    There should be a switch in the GVP software to disable DMA and go back to PIO mode. That should do the trick.

  • Yes, the 2091 is also a DMA controller. However, it appears to have a detection for non-DMA targets and branches into an alternative routine when DMA won't work - and that's dead slow. The Guru ROM (which was available for both these controllers) will give it back most (if not all) of the performance you know.


    Just to emphasize it again: This is not a problem of BigRam2630, but a general problem of DMA cards in the A2000 that can't reach the accelerator's fast mem.

  • Thanks so much for your help Jens. I looked into information about the guru rom and from what I was able to discern was it required an adapter because it didn't fit into the space of the original roms. I've been unable to source any of these adapters. Do you have a resource you could point me towards to so I can try to accomplish this?

  • Unfortunately no, I don't have a source for such an adapter. I did contact the author for licensing the Guru ROM in the ACA2000, because I totally see this coming many more times if I sell lots of ACA2000 boards. In summer 2020, he mentioned that "another run is in the making", but to behonest, I never saw these adapters for sale anywhere. I'll pick up that conversation again :-)

  • FWIW - This is Robert Miranda of (formerly) GVP Tech Support 1989-1993. I know the Series II cards quite well as a result, and I also currently support the GuruROM v6 for Ralph Babel. I am actively part of the OS 3.1.4/3.2 beta test team. I worked heavily with the developers to help eliminate AutoConfig race conditions in the revamped OS 3.1.4/3.2 before each release.

    As I was writing some of this up, the user reported in recent 1:1 conversation that he found the A2630 board set for Unix mode, and it resulted in some very strange Config info seen in the ShowConfig tool. Changing the J304 jumper fixed it,. While that was happening, I also noticed that the GVPInfo board info screen he posted in April showed Product ID 9 for the DPRC I/O PIC. The GVP SCSI driver v4 will operate only against the Product ID 11. It probably ignored the board at boot as a result. I'm not sure what that J304 jumper does to the system's expansion bus logic view.

    As for the question of DMA and memory >16MB, it's time to dispel the myth propagated by shortsighted C= driver engineering of scsi.device on the A2091/A590, and the hack they and uninformed users online have propagated in the past 30 years.

    First: The gvpscsi.device v3/v4 (gvpscsi.device) and GuruROM v6 driver (omniscsi.device) are all related. During the initial testing Ralph Babel and I did, we tested/solved 99% of the quirks and bugs of the 33C93/33C93A -02 and later while being driven at an odd 7.xxx MHz or 14.xxx MHz clock (WD chip specs want something better like 8MHZ, or 10MHz, or higher) - This is something C= never could quite do without the -08 variant of the SCSI chip years later. The -02 chip under this driver is expected to be driven only at 7MHz, and the -04 and higher revisions are expected to be driven at 14MHz unless the card natively doesn't support it, or a jumper setting identifies a non-default clock has been set. Disconnect/Reconnect is not an issue with any of these drivers. Proper termination is still important on any SCSI configuration.

    Second: These drivers are built as a dual-level driver. The one layer drives the 33C93(a) SCSI chip bus logic. The second layer drives the I/O engine (data transfer inside the Amiga). The driver evolved in the following way:

    The v3 driver supports the early Impact (series I) buffered I/O CPU-driven cards and the Series II DMA units (Zorro II through Combo22/33 models). Support was dropped for Series I after v3.15 as code space was needed for future products (G-Force 030/040 variants). I won't cover the nuances here. When in doubt, use v3.15 on the older stuff, and with Async-only SCSI capable devices.

    The v4 driver is functional for all the GVP Series II DMA products and G-Force accelerator product line with a 33C93A SCSI chip. Aside from some corner-case enhancements, and expectation that the SCSI chip is running at 14MHz on all boards that support it, it functions just like the v3. I have documented the subtle differences elsewhere, but 4.13-4.15 are the latest.

    The GuruROM v6 is an enhancement of the v4. It is 1) larger code space than the 16K ROM space provided on both the GVP Series II products and the A2091 - hence the adapter. 2) With 14MHz 33C93A clock enabled, it is capable of Sync SCSI communications, potentially doubling the speeds over the SCSI cable (Amiga bus clock speeds are the next limiting factor the benchmarks run into). 3) it has some finer-grained configuration options the earlier v3/v4 driver could not implement due to the code space limit. 4) It added A2091/A590 DMAC-02 transfer support to the transfer-layer, and the use of 14MHz / Sync mode requires a hack and jumper setting to those C= boards.

    FastROM (gvpscsi.device) v3/v4, and the post-GVP GuruROM v6 (omniscsi.device) are both 24/32-bit DMA address-space aware for the supported GVP Series II & C= A2091 DMA cards in all Amiga machines. This means they natively handle memory targets located above the 24-bit (16MB) address line that would otherwise cause an address-wrap during the transfer by a 24-bit Z2 aware DMA controller.

    When either the older or newer driver identifies that the supported DMA SCSI interface' data's transfer source/target memory address is located above 16MB, the driver seeks out a 16K 24-bit DMA-capable buffer of type MEMF_24BIT in the system memory pool. That's normally the AutoConfig 16-bit FastRAM on the HC8, or other Z2 FastRAM card, or in this system's case, with the A2630, the local 2MB of 32-bit native RAM (which appears to AutoConfig first, and is DMA-capable). That 16K buffer is used to perform a CPU-copy down (or up) with the >16MB target address. For this reason, DMA Mask in a partition/filesystem definition is ALWAYS supposed to be 0xFFFFFFFE for either the v3/v4 or v6 driver. This buffering activity for high-address RAM will result in about 1/2 the potential I/O performance for the most optimal transfers. CPU speed contributes to the efficiency. If ChipRAM must be used for the buffer, the performance impact is slightly higher (Agnus has ownership during heavier graphics needs). Either way, it is still many times more efficient to buffer-copy at the driver level than falling back to PIO, which is simply horrid (think OldFileSysem floppy performance). The driver actually can still do PIO in a rare case, and it's automatic - no jumper setting applies to this.

    Note: All of this described behavior is automatic. The buffering design is much more efficient (and functionally robust) than the C= hack to stuff a reduced-address DMA Mask band-aid into a (higher-level) filesystem partition entry. The native driver on the A2091 of course isn't this smart. The DMA Mask hack is their only way to fix the deficiency on that Zorro II scsi.device driver. For the record: DMA_Mask doesn't fix SCSI_Direct initiated transfers - the application or filesystem using that transfer method would still have to detect the condition on the host and buffer it some way itself. Ugly. Very inefficient at that level of the OS.

    I hope this sheds some light on the topic, and dispels this almost 30-year myth about the GVP (and C=) cards and how 24-bit DMA is handled.

    Also: The status of GuruROM is posted by me on AmiBay under an identical nickname as I have used here.

  • That's normally the AutoConfig 16-bit FastRAM on the HC8, or other Z2 FastRAM card, or in this system's case, with the A2630, the local 2MB of 32-bit native RAM (which appears to AutoConfig first, and is DMA-capable).

    In this particular case, the BigRam2630 also maps 1MB of 32-bit fastmem to $00c0.0000, overlaying possible 512k ranger-mem of the A2000. Although this would be the better (faster!) choice at first sight, it will NOT be DMA-capable. Not sure if the driver is aware of that, or if we should patch the memory attributes in order to make sure that this mem won't be used for that 16k buffer.


    The 2630 memory in Z2 space is definitely DMA-capable, and a very good choice, as the CPU-copy loop will take advantage of it's speed compared to the 7MHz ram in the rest of the 24-bit address space.

  • Thanks for this info.


    I believe the buffer allocation will happen late enough. My recollection is that the buffer is allocated only at the time when the transfer target falls outside of the DMA 'mask' that the driver works from. If so, that will be late enough to grab the first A2630 memory for it's 16K buffer (yes, a good target) as I assume it's still highest priority with the 24-bit DMA flag set. It would still be prudent to remove the 24-bit DMA capable flag from the 1MB. I will still check with Ralph Babel on the topic of the 16K buffer allocation timing.


    The thing I am not sure of is whether there is any normal DMA transfer masking available for that $00C0.0000 memory when an application has allocated that memory for a standard transfer (to/from). My understanding from Ralph Babel and Jeff Boyer back in the day is that any memory in the 0<16MB address space should always be 24-bit DMA capable. A certain other accelerator developer in the past few years ran afoul of this 30+ year best practice (I was the messenger, I got shot). Soon after, they shifted their 32-bit memory to address ranges outside of the ZII space to avoid the DMA problem (the A590 and GVP A500-HD8 users ran into it, in addition to the A2000 DMA cards).


    Technically, the GuruROM driver has a DMA Mask feature (for testing) that works like a filesystem DMA Mask. The problem is that the way the bits land on the actual physical memory locations. It would prevent DMA to 8MB<16MB (causing buffering to occur), which leaves a few corner cases with the upper part of that ZII FastRAM space. However, this driver-level mask option/solution is not possible for the native drivers on native Zorro II GVP DMA products (v3/v4), the A2091, Microbotics Hardframe, or A2090(a) - the majority of units in the field.


    As I doubt this $00C00000 memory is easily removed at this point, I might suggest a small program/tool option that does an allocate absolute of that specific $00C0.0000 1MB space - let the user set it on if there is any 24-bit DMA controller in the system. It may be the last memory allocated in terms of priority, but is still best to avoid the run off the cliff at some point. I could think of possibly something that might come about from high memory fragmentation and a large allocation. It should also solve the other controllers' potential problem with the loss of 1MB. I was even thinking that 512K of Kickstart (FastROM) might nicely go here, along with optional relocating of the SSP and VBR. Maybe it could be suggested for Thor's 68030.library to handle it that way as a special case?

  • So as to not confuse the casual reader that may stumble on this post and my replies, my reference to "the DMA Mask that the driver runs from" is an internal mask value that gets automatically adjusted based on the product the driver detects it is controlling. For example, the Combo/G-Force cards have different amounts of 32-bit memory >16MB that the DPRC can directly access on the cards. It can't be adjusted on gvpscsi.device. It's possible to adjust it on omniscsi.device in the later versions. There is no relationship to any filesystem mask of any similar name.

  • As I doubt this $00C00000 memory is easily removed at this point,

    It is easily removed for this case. It's a user-setting with the flash tool for the BigRam2630, so it is persisted in the hardware. It's just that it makes the system so much faster :-)


    Maybe it could be suggested for Thor's 68030.library to handle it that way as a special case?

    If there's a 68030 in an A2000 system that's from iComp, then it's most likely an ACA123x card on an ACA2000, which is not yet available. However, only very few ACA123x cards have the $00c0.0000 memory chunk switchable, so it's definitely worth thinking about a way to inhibit DMA access to "ranger mem". I'd prefer a software solution, as I don't plan on supporting DMA at all with the ACA2000. Reason is that not a single A1200 accelerator supports DMA access to it's local memory, and the ACA1221lc (and predecessors with 68ec020 CPU) have all their mem in the 24-bit address area for obvious reasons.


    So it'll either have to be "switch off DMA in software", or a bus error on the hardware side if a DMA is requested. I won't bother implementing DMA, as there's just no data path into A1200 accelerator memory.


    I was even thinking that 512K of Kickstart (FastROM) might nicely go here, along with optional relocating of the SSP and VBR.

    BigRam2630 has a "fast Kickstart" option, and if I remember right, moving VBR into fastmem is also a user-flash option. Read all about it's capabilities in the register description.

  • Thanks for the insight. I agree on the faster memory's impact when being available at an early OS boot point. The Combo/G-Force 030 and 040 all had some form of all-high mapped memory option. Whenever that all large-memory mode >16MB was selected, getting as many of the system structures out of ChipRAM after power on had an impact (Some Z2 16-bit Fast was even a little better to have). Most of the time I suggested users pick the mixed mode (some banks Z2 Auto and some high mapped, if possible). If $00C0.0000 can switch in and out on the A2630/BigRAM+ combo when Z2 DMA is around, that's as good an option to point users to as there is. Software adjustable is always good.


    I recently picked up an ACA1221LC to get a feel for some of the A1200 ACA gear. I saw the planned ACA 2000-interface interface card, so will be curious to try it there when it's available.


    I have a GVP A1230+ JAWS-II 8MB (all high mapped) on the A1200 I have. It has a SCSI option that had a limited run before the mid-1994 divestiture of GVP to GVP-M and others. It's still using the DPRC Z2 DMA chip as a PIC for it's ROM to map memory, and interface to the A1291 SCSI board (I have the SCSI module, too). It supports DMA transfer to it's high-mapped RAM, and presumably ChipRAM. I consider it a rare case to encounter it, though., based on it's short production run period. It will be interesting to see if the upcoming ACA 2000 module works with this one. It appears to be a tangent of the v4 gvpscsi, but I know this card's v5 SCSI driver is not one of Ralph's. It has some slightly different tools, and the ROM is soldered on.


    There was also the A1200 product called FANG which was memory (32-bit AutoConfig), FPU, and DPRC DMA SCSI. It was not a CPU card. I would believe that and other passive-resource cards are not supported on the ACA 2000.


    I will probably pick up one of these BirGAM+ cards at some point. My A2630 for whatever reason wasn't booting the last time I tried (-07 ROMs worked on the A2620, so not them). When I get it going, I am now curious of the memory board.

    Thanks

  • I have a GVP A1200 68030 card here, but it does not work on ACA500 or ACA500plus, so it may be possible that it is not capable of dealing with a 16-bit wide host, or that it even requires the host CPU to run some software before it gives control to the 68030.


    Looking closer at the board, it says "Jaws II Rev.3", so it's likely that it's exactly what you're describing. If you have more details about it's hardware, I can try to make it work. Until now, I have only developed the A1200 accelerator interface against my own ACA12xx cards, and by coincidence, the Blizzard cards also worked. I never investigated why the GVP card didn't work.

  • As noted earlier, these A1200 cards were designed and shipped late in GVP's existence. That is what I call the ~15 months after my departure from GVP (round 1 layoffs) and before divestiture mid-1994.

    I was aware of the A1208 SCSI/FPU/8MB RAM card - it had just come out. I didn't have any A1200 hardware to test it on, so it went to someone else, then I was let go soon after. Having an A3KT with supped-up GF-040/40 and Bridgecard, and every slot and bay filled, left me no way to justify another Amiga or PC on my work desk.

    I was aware of the first generation A1230, or JAWS I, which was being worked on - it has no SCSI. It's memory is software-mapped >16MB with the DPRC's ROM like the G-Force units. I never saw it before my departure. I see a MACH120 and MACH210 on these boards for the custom logic.

    The Rev 3 is considered the A1230+, or JAWS II. They compressed the logic even further with the MACH130 to fit a clock interface (mine doesn't work) and a header under the corner for the FANG, or the A1291. That is a PCB with a 33C93A and some termination / clock control for that.


    I won't profess to be an engineer (only a tech), but I do have more deeper technical notes on the entire GVP A1200 card series. I can't post any detail in public view, though. I know most of the bus logic is buried in the MACH130 and the MACH210 chips as far as memory and A1200 interfacing. I would not expect Jeff to have done much different than what was done on the A2000 G-Force cards. I'd expect modifying the Amiga data bus to 32-bit, and maybe an adjustment to the Async logic state machine to best interface with 14MHz vs 7MHz. 32-bit memory model on the card is set for 50MHz performance against SIMM32 60ns memory, and that is regardless of the clock provided (some shipped with EC030/40's). I see the high density bus buffers along the card edge, so I assume he has control of bus/buffers through them and the MACH130 logic.

    I assume it's an A2000-like CPU takeover, with the _BOSS interface - that A1200 line is connected to the MACH130. After that, it's just a 14MHz clocked DPRC (not 7MHz as on the G-Force/Combo cards) doing typical HW AutoConfig as a 64K Zorro II (16-bit) I/O PIC through glue logic.

    I have updated the BBoAH hardware page with the jumper details I felt comfortable distilling from the information I have a few weeks ago. It may be additional information you didn't have.

  • I would not expect Jeff to have done much different than what was done on the A2000 G-Force cards.

    A1200 is even easier, as you don't need to care about E-Clock accesses. Gayle does that for you :-)


    an adjustment to the Async logic state machine to best interface with 14MHz vs 7MHz.

    ...and the differences between 68000 and 68(ec)020, which are big enough to call the new state machine "new from scratch", as things even happen on "the other" clock edge. Yes, experience helps, but in essence, adapting a 68030 to a 68020 bus is a walk in the park.


    I assume it's an A2000-like CPU takeover, with the _BOSS interface - that A1200 line is connected to the MACH130. After that, it's just a 14MHz clocked DPRC (not 7MHz as on the G-Force/Combo cards) doing typical HW AutoConfig as a 64K Zorro II (16-bit) I/O PIC through glue logic.

    If you assume that you only change bus ownership during a reset, you can completely skip on BR/BOSS, and just assert BR during reset. If you do that, the bus is yours, and you never give it back - no need to fiddle with BR/BG. Granted, you need to read the 68020 data book "between the lines", but it works with all CPUs of the 68k family. That's what the ACA500(plus) expects: The BR line is essentially a switch for the complete logic to either talk 68000 or 68020. The ACA500(plus) don't even connect the OVR line, which would be required if A1200-side glue logic would be used for the 68030 - that was a popular technique of the Apollo accelerators, and it's one out of a few reasons why these won't ever work on the ACA500(plus).


    I'm implementing Autoconfig completely local on my accelerators, so I don't need OVR on the A1200-side. I keep avoiding that, as Gayle ignores OVR in too many places. So if you now come back with "oh yes, OVR is connected to the logic as well", I'll have to say that there's no way we can make this work (other than adding logic/cost, but I would not want to do that for a small run of accelerators that uses outdated memory SIMMs).

  • I'm definitely seeing the edge connector OVR signal connected to pin 77 of the DPRC, which is identified as _Slave.


    Noted on the clean state machine - but I'm guessing Jeff could do it in his sleep back then.

    I'm recalling the BR trick for the A530 - hence the sidecar unit has a small relay circuit to hold off the A500 CPU start process until the sidecar gets to full power (from it's PS). I know there is then logic that steals the bus away, but the logic also has to let DPRC and the 68030 trade off bus ownership without releasing it back to the 68000 (A500) and I assume same here for the 68020. This card has a software register to fallback/reset into 68020 native, so add that in to the logic mix.

    I think we can rule this card out, and probably it's earlier non-SCSI relative, if OVR won't get handled in the ACA 2000 interpretation. No arguments on the value vs low production.