Imo hardware/software is a blurred line these days, it doesn't matter so much. It's all just code running on a thing. The results are what matters.

The ideas about expanding scope sound nice in theory but personally I would rather not see Scope Creep take over the project (e.g. "Be Every Soundcard Ever!"). A modular design where extra stuff can be snapped on later, absolutely would be nice. But I like the idea of keeping the project primarily focused upon it's main goal (i.e. to achieve GUS functionality), above all else.

Re: FPGA, I'd also say: I'd rather not see this. Or more accurately: I'd rather that was done as a different project, and that this project here stays As Is. There is an unmatched openness of design, cost, availability, options, that comes with using common everyday components like Pi's*. And openness and availability are so so important when it comes to these projects. It's the difference between many thousands of people being able to access it at will (example: mt32-pi), or mere hundreds, beholden to unique chip acquisition, legacy components, special manufacturing processes and multiple middlemen (example: most bespoke soundcards made here).

*current terrible stock levels aside!

One could argue that an FPGA blurs the line between hardware and software, but hardware itself is distinctly not "code running on a thing."

If the Pi has enough horsepower then it doesn't matter. But OP may run into limits doing everything in software, especially regarding latency and jitter.

Plasma wrote on 2022-06-14, 23:17:

One could argue that an FPGA blurs the line between hardware and software, but hardware itself is distinctly not "code running on a thing."

It's a semantic argument. Change "code" to "logic" and it's a perfectly apt description. The only difference is levels of abstraction - which is irrelevant when results match.

My ideal is for GUS's core functionality to be as free and open for as many people as possible, in as many ways as possible.

Plasma wrote on 2022-06-14, 23:17:

If the Pi has enough horsepower then it doesn't matter. But OP may run into limits doing everything in software, especially regarding latency and jitter.

He may, or may not. That's for this project to discover, and I'm very glad it's being done.

Yeah, this is an experiment that I'm doing out in the open and I'm in it for the fun of learning about the ISA bus, the GUS itself, and how far a Pi can take things. Failure is an option, and I'm fine with that. I've had a lot of fun so far.

A couple projects that use a Pi that interface directly with timing-sensitive hardware give me a lot of hope: PiStorm (Amiga 68K accelerator + RTG graphics + WiFi interface + HDD, with a CPLD for glue logic) and RaSCSI (SCSI device that emulates disk drives, optical drives, ethernet devices, and graphics cards).

Shreddoc wrote on 2022-06-15, 00:08:

Plasma wrote on 2022-06-14, 23:17:

One could argue that an FPGA blurs the line between hardware and software, but hardware itself is distinctly not "code running on a thing."

It's a semantic argument. Change "code" to "logic" and it's a perfectly apt description. The only difference is levels of abstraction - which is irrelevant when results match.

I guess it's semantics if you disregard the English language. Hardware is not software.

Shreddoc wrote on 2022-06-15, 00:08:

Plasma wrote on 2022-06-14, 23:17:

If the Pi has enough horsepower then it doesn't matter. But OP may run into limits doing everything in software, especially regarding latency and jitter.

He may, or may not. That's for this project to discover, and I'm very glad it's being done.

I hope it's successful as well.

Shreddoc wrote on 2022-06-15, 00:08:

It's a semantic argument. Change "code" to "logic" and it's a perfectly apt description. The only difference is levels of abstraction - which is irrelevant when results match.

It goes a bit deeper than that, you can actually make a thing that will work in place of the original chip as it can match all of the timing etc. and not because you are carefully fudging things until they match but it coming out inherently from replicating the logic of the original hardware (i.e using silicon shots and tracing out the original logic). The transistors controlling the current flow are not same , but in the end the electrons move the same paths and produce same work.
Of course one can achieve same functional result by completely different way to original logic too, which often happens with all the single chip solutions such as MiSTer where there isn't enough memory or pins to have all the different buses that some hardware might have (i.e many arcade devices) and then actual deviations from original design become necessary and then you have stuff that you can confidently not call "original".

Tiido wrote on 2022-06-15, 00:47:

Shreddoc wrote on 2022-06-15, 00:08:

It's a semantic argument. Change "code" to "logic" and it's a perfectly apt description. The only difference is levels of abstraction - which is irrelevant when results match.

It goes a bit deeper than that, you can actually make a thing that will work in place of the original chip as it can match all of the timing etc. and not because you are carefully fudging things until they match but it coming out inherently from replicating the logic of the original hardware (i.e using silicon shots and tracing out the original logic). The transistors controlling the current flow are not same , but in the end the electrons move the same paths and produce same work.
Of course one can achieve same functional result by completely different way to original logic too, which often happens with all the single chip solutions such as MiSTer where there isn't enough memory or pins to have all the different buses that some hardware might have (i.e many arcade devices) and then actual deviations from original design become necessary and then you have stuff that you can confidently not call "original".

It all goes a lot deeper, technically. No doubts there. I have a MiSTer, alongside my own built arcade emulation cabinets, and even as "just a user", have already spent untold hours reading and conversing about the technology, including many long conversations about the merits/drawbacks of different implementation types.

But for the average end-user, from a results-based perspective, What's Inside The Black Box is irrelevant. Far more important: does it achieve the desired result? reasonably? - can everyone who wants one, easily get one?

Plasma wrote on 2022-06-15, 00:43:

Shreddoc wrote on 2022-06-15, 00:08:

Plasma wrote on 2022-06-14, 23:17:

One could argue that an FPGA blurs the line between hardware and software, but hardware itself is distinctly not "code running on a thing."

It's a semantic argument. Change "code" to "logic" and it's a perfectly apt description. The only difference is levels of abstraction - which is irrelevant when results match.

I guess it's semantics if you disregard the English language. Hardware is not software.

They share many commonalities, hence my original point which you partially agreed with - that, with many modern implementations, the lines are blurred. Especially from an end-user, results-based perspective.

The comments from Tiido further highlight how, with the MiSTer FPGA project, that line-blurring is in great effect. In that "FPGA based" project, we have cycle-accurate logic-accurate implementations. We also have partial logic implementations fleshed out by workarounds or shortcuts. There's also bare software-level stuff going on. It's all mixed together. The end-user can't tell which is which.

polpo wrote on 2022-06-14, 20:50:

I'd love to use an FPGA, and such a solution would be far better suited to emulating a GUS, but I don't know any Verilog beyond "make the LED blink." Simple as that!

There is arguably not THAT much difference in the end running a close-to-metal program on a CPU or running a verilog design on an FPGA. Yeah, the FPGA is more "hip" in the emulation scene, but a close-to-metal software emulator with not operating system in the way which could destroy latencies etc. will sound indistinguishable from an FPGA. There also won't be THAT much of a power difference, depending on which FPGA you are using. I think going with what you are familiar with, and what is currently available on the market, is the best decision (not that a Pi is more easily available than an FPGA at the current situation...).

Hi,

I already contacted you in Vogons and recommended you to use my Player, Mod Master...
it use only the I/O Port and no IRQ/DMA.
As it also support Interwave, you can try this as well.

You can't use @decoding and still have DMA Working.

Also, add Tandy, CMS, OPL2/OPL3, Covox is simple as none of them use IRQ/DMA. (Even general Midi/MT32)

As I told you in twitter, this is something I wanted to do as well. Currently I am working in the ISA USB Software (More simple to do to start)

I think that multiplexing the 8 Data bits with the Address is possible and will bring the needed aditionnal signals.

the3dfxdude wrote on 2022-06-11, 22:57:

Dr Scott M. Baker has done a more complete ISA-to-PI card for emulating a floppy drive, here: https://www.smbaker.com/raspberry-pi-virtual- … -xtat-computers

It includes some useful things like power and reset signaling. I definitely would like to see a complete ISA-to-PI reference design utilizing as much as we can on the ISA bus for quick emulation prototyping.

This one is "Too complexe" as no dual port memory is needed for a sound card.
At the end ISA Pi is only wire most of the ISA signals on the Pi bus.

Then, 99% of the job is software.

Can a ISA-to-PI be used as a video card? It would be awesome, imagine adding acceleration capabilities

Sure, it's indeed possible. It's been done on other platforms, already:

https://thebrewingacademy.com/products/rgb2hd … video-cart-slot

- Alex

Plasma wrote on 2022-06-14, 20:43:

I agree this is a cool project but why not use an FPGA?

FPGA design is not simple, and here, any part of DOSBOX or other software emulator can be used.

FreddyV wrote on 2022-06-16, 19:23:

Plasma wrote on 2022-06-14, 20:43:

I agree this is a cool project but why not use an FPGA?

FPGA design is not simple, and here, any part of DOSBOX or other software emulator can be used.

On the other hand, a big enough FPGA, could support several sound cards as once. Synth chips like the OPL3, dual OPL2's could be done in FPGA, its logic replicated to 100% would be impossible to distinguish from the real thing. I know there's someone on VCFED working on it but i'm sure it's not easy. In any case, i believe that a single card that does it all on a big enough FPGA is the future and the way to go.

carlostex wrote on 2022-06-17, 13:40:

On the other hand, a big enough FPGA, could support several sound cards as once. Synth chips like the OPL3, dual OPL2's could be done in FPGA, its logic replicated to 100% would be impossible to distinguish from the real thing. I know there's someone on VCFED working on it but i'm sure it's not easy. In any case, i believe that a single card that does it all on a big enough FPGA is the future and the way to go.

You're thinking of the BitchinFastAudio 3000. It's been over a year without a progress report. I hope it's not dead.

https://www.youtube.com/watch?v=0aCy3ccLZzo

SScorpio wrote on 2022-06-17, 14:46:

You're thinking of the BitchinFastAudio 3000. It's been over a year without a progress report. I hope it's not dead.

https://www.youtube.com/watch?v=0aCy3ccLZzo

I remember I saw this one.
There are so many more persone able to read and correct C than FPGA.
If you take the Vampire example (Amiga FPGA) there is only one person in the world able to understand the core... the one who wrote it.

carlostex wrote on 2022-06-17, 13:40:

On the other hand, a big enough FPGA, could support several sound cards as once. Synth chips like the OPL3, dual OPL2's could be done in FPGA, its logic replicated to 100% would be impossible to distinguish from the real thing. I know there's someone on VCFED working on it but i'm sure it's not easy. In any case, i believe that a single card that does it all on a big enough FPGA is the future and the way to go.

Do a 100% accurate FPGA is way more complicated to do than software emulation, and much more complex to maintain.
A big enaugh FPGA is more expensive than a Pi Zero that can surely do the job.
The Board design and soldering itself is a nightmare compared to a simple connector for a Pi.

We are talking about a board for Old PC, 100% accuracy is not really needed, and the number of person wanting a board like this is not worth the effort to go to a FPGA design.

FreddyV wrote on 2022-06-17, 15:07:

We are talking about a board for Old PC, 100% accuracy is not really needed, and the number of person wanting a board like this is not worth the effort to go to a FPGA design.

The thing about FPGAs is that the code is portable between vendors with less work than some other porting projects. So only a chip is recreated in FPGA and shared on GitHub or one of the FPGA focused site, it's done. There are full PC and console projects using some of these sound chips. So putting in the work isn't limited to only a single low run sound card for legacy systems.

FreddyV wrote on 2022-06-16, 13:21:

Hi, […]
Show full quote

Hi,

I already contacted you in Vogons and recommended you to use my Player, Mod Master...
it use only the I/O Port and no IRQ/DMA.
As it also support Interwave, you can try this as well.

You can't use @decoding and still have DMA Working.

Also, add Tandy, CMS, OPL2/OPL3, Covox is simple as none of them use IRQ/DMA. (Even general Midi/MT32)

As I told you in twitter, this is something I wanted to do as well. Currently I am working in the ISA USB Software (More simple to do to start)

I think that multiplexing the 8 Data bits with the Address is possible and will bring the needed aditionnal signals.

Hi Freddy, thanks for the recommendation for Mod Master. I'll add it to my list of players to test with, especially on 286. Sorry I missed your messages before.

About address decoding meaning DMA won't work: maybe I am totally not understanding how 8 bit ISA DMA works, and I am new to this level of hardware interfacing on the PC, so please correct me if I am wrong. But here is how I understand it: the DMA controller is programmed and puts the address to be written to or read from on the address lines, but the ISA card should not care. It just has to write or read the byte on the data lines.

In any case that is a very good idea to multiplex the data and address lines – it would keep the flexibility of software address decoding but would still allow more signals to be brought to the Pi. I will keep this in mind for the next hardware revision!

Small update: I have IRQ somewhat working but it is not 100% reliable yet. For example, timers are funny. Crystal Dream II runs at about 33% speed as it's reliant on the GUS timer to time the whole demo. I will be doing some captures with my logic analyzer of my actual GUS card to see how it drives the IRQ line so I can achieve parity.