Is producing a high quality 16 bit Atari Sampler practical?

[mrbombermillzy]

One of the things I have found a real pity over the years, is that no one has thought to produce a high quality (semi/professional) 16 bit sampler cart for the ST/TT/F030/etc... range.

Ive owned the Microdeal Replay 16 cart for years, but havent done much other than tinker because the actual audio quality lacks for several reasons:

1. Audio DAC quality; Playback colouration
2. Possibly resistor tolerances
3. Poor earthing - hum causing sub-optimal s-n ratio
4. Software playback routines designed for the base 8Mhz 68000 Atari ST causing aliasing/frequency reduction problems on >1ch playback.

To try to remedy this, I have found schematics for the cart online:

ATARI_REPLAY_16_Schematic.pdf

(64.6 KiB) Downloaded 3 times

so perhaps some modifications can be made (see points 1 to 3) to vastly improve the audio output quality, at least from the HW side.

The other option is to find the (mythical?) AVR Replay 16 Pro cart, which allegedly existed (I read about it in a review in ST Format magazine; apparently it included its own PSU), although I have never ever, ever, seen one advertised or for sale anywhere...ever.

Anyway, if the said unit could be found and reverse engineered, thats another option (although Im sceptical on how 'professional' the unit is.

I understand that Steinberg and others produced similar designs, but the AVR/Microdeal samplers had the whole integrated SW suite which appealed more and was easier to just start using quickly. (Quickly being a very relative term in this age of AI generated music! )


Once the above can be solved, Im sure SW on the faster TFxxx cards (and the TT, etc) can improve sample playback rate for higher channel counts on the faster machines. Its just theres no motivation to create the SW for the low quality 16 bit cart.

Would love to know your thoughts on this guys...

[exxos]

Once the above can be solved, Im sure SW on the faster TFxxx cards (and the TT, etc) can improve sample playback rate for higher channel counts on the faster machines. Its just theres no motivation to create the SW for the low quality 16 bit cart.

For a stock ST, IIRC, the cartridge port is timed by the GLUE, so regardless of CPU speed, you can't improve on anything. But care would be needed as the CPU switches between 8/50mhz on the 536 boosters , or variations on CPU on MSTE/TT etc, it may upset the sampling rates in software. No idea.

While hardware could be improved with more modern tech, you still have the software issue, but you would need a whole new interface somewhere to increase the bandwidth and then you need RAM to keep up.

You need a new interface which runs at a constant speed. Double speed *could* be done on the Nexus on a H4/H5 on the cartridge port.. but you would still have to design a more modern ADC interface and software to work with it.

No idea if there was any better Falcon samplers either ? If there was, that would be a better place to start.

[mrbombermillzy]

For a stock ST, IIRC, the cartridge port is timed by the GLUE, so regardless of CPU speed, you can't improve on anything.

I was under the impression, that some of the (very few) sample replay apps could do higher frequencies for the TT. I guess with the 16Mhz bus thats what facilitated that .

I was also under the impression that the write timings for sample playback are timer/interrupt based, so the systems non RW to the cart port activities are longer with the faster CPU, so hence more room for tighter interrupts/timers (and hence higher RW or sample playback rates).

So your saying the cart port R/W bandwidth limit is ~40-50Kb/s..ish on a 8Mhz system bus?

No idea if there was any better Falcon samplers either ? If there was, that would be a better place to start.

Yes there was - sort of - Clarity 16. I had that with my F030 BITD, although as the Falcon had an audio out DAC already, I think it was just the AVR SW and a clock cart to be able to sample in the more standard 44.1/22Khz, etc rates.

And to be frank, the F030 has its fair share of 16-bit sample playback apps/HW anyway.

[exxos]

Let me try and reframe the technicals here

It's one of those things where the ST architecture by design just isn't great at this sort of thing, which is why looking at the Falcon or any machines with a 16mhz bus, like the H5 Nexus will have would stand the best chance of working better etc.. But I don't think that is going to make a good starting point anyway..

If anything, you would probably be better looking into things like a Ravan , when you can plug in sound blaster cards (I assume) and you basically have everything you need on the card already.. You have a superfast system for everything else.. But of course you need to plumb the whole thing in..

It's certainly a lot easier than trying to build hardware better and integrate it into a ST where it would probably be almost impossible to build and get working good,, So that is where I would really start looking at building up a sampler system if that's what you want to do..

Ultimately once knowledge and experiences gained and how the whole system works hardware and software, then you can look at the terms of "cost" in terms of required CPU to run everything, even the MEGA ST might be able to convert the MEGA BUS into a ISA bridge to talk to a sound card.. I honestly don't know but Sound Blaster cards are cheap for basic ones, I don't know how much memory they have on board, but it would certainly solve a lot of problems out of the gate..

I honestly think the Raven would be the right sort of environment to build up this sort of thing up on.. The ST has enough samplers already

[mrbombermillzy]

It's one of those things where the ST architecture by design just isn't great at this sort of thing...

Ok, well that - in a nutshell - probably answers why it hasnt been tried since 1992 or whatever.

I honestly think the Raven would be the right sort of environment to build up this sort of thing up on.. The ST has enough samplers already

I have a PC which is a pretty great environment. However, I was looking to use an ST. Dont think I can afford a Raven anyway. (Not sure I can even afford the 060 CPU!)

[sporniket]

For that kind of project, I would have attempted to create an ACSI device instead, hoping that the data throughput and enough buffer memory on the device would be enough for being able to record sound for a few seconds.

Of course, i guess that it would mean to write a driver for that too ?

[mrbombermillzy]

For that kind of project, I would have attempted to create an ACSI device instead, hoping that the data throughput and enough buffer memory on the device would be enough for being able to record sound for a few seconds.

Of course, i guess that it would mean to write a driver for that too ?

I guess - traditionally at least - the ACSI/DMA port has the fastest throughput on an ST, so good call.

However, if I was going to go to all the effort of starting from a clean slate, I would instead probably opt to still use the cart port and get a device (FPGA?) to snoop the bus to get an estimated 1.5-2Mb/s transfer rate.

This is a fairly new discovery: https://www.ultradevtools.de/diary.html (look for entry dated 04.03.2025)

or

https://atari-forum.com/viewtopic.php?t=44833 (if you are allowed on!)

[ijor]

For a stock ST, IIRC, the cartridge port is timed by the GLUE, so regardless of CPU speed, you can't improve on anything.

So your saying the cart port R/W bandwidth limit is ~40-50Kb/s..ish on a 8Mhz system bus?

Technically, the cartridge port is not clocked at all. The clock doesn't even reach the cart port. A standard system will, of course, access the port at standard speed. But this doesn't mean you can't have a custom hardware and/or software interface.

For example, if some kind of accelerator allows accessing TOS at 16 MHz, then, in theory, this could be used to access the cart port as well.

I guess - traditionally at least - the ACSI/DMA port has the fastest throughput on an ST, so good call.

In a standard system, yes. In practice, it might be easier to "overclock" the cartridge port. Also the ACSI interface is way much more complicated.

However, if I was going to go to all the effort of starting from a clean slate, I would instead probably opt to still use the cart port and get a device (FPGA?) to snoop the bus to get an estimated 1.5-2Mb/s transfer rate.

This is a fairly new discovery: https://www.ultradevtools.de/diary.html (look for entry dated 04.03.2025)
https://atari-forum.com/viewtopic.php?t=44833 (if you are allowed on!)

Yes, one of the main problems of using the cartridge port, is that it's designed as read only. I understand this is "fixed" in the H4/H5? But there are several techniques to "write" to the cartridge even in standard boards. You could indeed check into the SideCart project, which I believe is open source? It shows, among other things, that you can snoop the bus even using a modern MCU (and not an FPGA).

Btw, respect where respect is due, Pera (AFAIK) was the first to snoop at the cart port using Blitter to write to his IDE interface.

[mrbombermillzy]

Technically, the cartridge port is not clocked at all. The clock doesn't even reach the cart port. A standard system will, of course, access the port at standard speed. But this doesn't mean you can't have a custom hardware and/or software interface.

For example, if some kind of accelerator allows accessing TOS at 16 MHz, then, in theory, this could be used to access the cart port as well.

I understand that ST ROMs avoid the system bus contentions of regular ram. I guess this can also applied to ROM (or otherwise) on the cart port. So does that mean something like a TF536 could access the cart port at its CPU clocked speed (with the data in the address register technique)?

Yes, one of the main problems of using the cartridge port, is that it's designed as read only. I understand this is "fixed" in the H4/H5? But there are several techniques to "write" to the cartridge even in standard boards. You could indeed check into the SideCart project, which I believe is open source? It shows, among other things, that you can snoop the bus even using a modern MCU (and not an FPGA).

If the previous point is true, that would be an easier solution.

Btw, respect where respect is due, Pera (AFAIK) was the first to snoop at the cart port using Blitter to write to his IDE interface.

Im a bit rusty on what he has done, so I will have to look into how he did that.

I was aware of his work on ~80 colour per scanline video playback SW (in collaboration with DML IIRC?) but if IIRC that needed a small HW mod.

P.S. Also, I may well have been a bit pessimistic on the 'regular' ST cart port throughput. Maybe its more like 100-150kb/s with good tuned SW - perhaps more if some system bus cycles can be prevented from being hemorrhaged by the use of a quicker CPU (e.g. fully maximising the instructions into the minimum no. of bus cycles).

I might add this to my (long) list of tests to see what can be achieved.