appiah4 wrote on 2023-01-19, 10:36:OK, you had me until the ULTRASND variable.. Time to google SET ULTRASND.. […]
Show full quote
OK, you had me until the ULTRASND variable.. Time to google SET ULTRASND..
EDIT: Oh, ok, I need to add SET ULTRASND=240,7,7,3,3 to my AUTOEXEC.
EDIT2: This card is NOT PnP at all, is it? ie. No support for/from UNISOUND right?
EDIT3: Which reminds me, why is the Address selection a part of the flashed ROM and not a jumper on the card?
It should be SET ULTRASND=240,3,3,7,7 – it's port,dma,dma,irq,irq.
Yeah, no PnP at all. It does feel strange having the exact opposite type of configuration as the GUS (jumpers for IRQ/DMA vs. jumpers for address) but address decoding is done entirely in firmware on the PicoGUS. The way things are is the result of a number of tradeoffs: number of GPIOs, flexibility of emulation, and BOM cost & availability of components.
Choosing the address with a jumper and using traditional hardware address decoding would have meant being locked down to only supporting a few addresses. A card like the GUS that supports a variety of addresses (GUS, AdLib, MPU-401) has to have pretty complex address decoding – it was implemented in like 4 GALs on the early versions and in a custom ASIC (the GF1D1) on later ones. Matching that would have meant using more discrete logic, GALs, or a CPLD which would have increased the BOM cost and ultimately not save any GPIOs – with address decoding in firmware and addresses being muxed with data, it's only 2 more GPIOs to support the full 10-bit IO address space. And then you can emulate any card you want instead of having the address ranges that you can decode baked into hardware! Firmware is temporary, hardware is forever...
The limited GPIOs also meant I had to use jumpers to choose the IRQ (IRQx) and DMA (DRQx, DACKx) signals to route to the Pico. Having this configurable via software would have meant more hardware on the card and even more GPIOs that I didn't have.
MJay99 wrote on 2023-01-19, 12:13:
As for the address, I think this might solve itself a little better with the card becoming flashable from the DOS... then you could just upload a proper firmware for the desired address from there (even though it's more invasive than just setting an address). Otherwise, address decoding might be doable in hardware and with a spearate jumper block (e.g. schlae's snark barker would have a usable schematic) - I just don't know if there are other dependencies making it unfeasable for the Picogus.
I am wrapping up the next version of the firmware which will support firmware flashing and setting the GUS port in DOS using pgusinit.exe. Here is a preview video where the card is in GUS mode, I then upload the AdLib firmware onto the card, and then run a program that uses AdLib: https://www.youtube.com/watch?v=5HkKBqUo1q0