My goal has been to find a way to record into the Paula chip for making .MODs while also being able to send MIDI out to my gear. It's extremely difficult to get MIDI timing right, so I understand why projects like UAE haven't put as much time into that aspect of the Amiga. And that's why I've landed on MiSTer FPGA, since it's the only way I've found to control external gear without timing problems.
But that's still left me with no way to sample audio since the MiSTer doesn't model the parallel port :banghead
Last year gave me hope when Echolevel began producing Open Amiga Sampler units and released his schematics on Github:
https://github.com/echolevel/open-amiga-sampler
Going through the documentation it looks like recording 8-bit audio is a fairly straightforward process:
I also found this blog post by someone working on full duplex networking through the parallel port that outlines a TON of insights into the communication path between the MC680xx CPU, CIAs and the actual DB25 port: https://lallafa.de/blog/2015/09/amiga-p ... nt-page-1/Our Amiga (ASM, C, etc) code performs a read of the parallel port's data byte at the relevant hardware address
The Amiga's CIA chip automatically fires a STROBE signal on Pin 1 every time a data byte is read
That's it! But that's no good - we've only got one sample byte, and it's either empty or gibberish because the sampler hadn't been instructed to perform an analogue-to-digital conversion. That's what the STROBE signal instructs it to do. It performed the conversion AFTER we read the byte. So:
We set up a loop in our code, using an interrupt to set the speed of this loop - and the speed of the loop should be our desired sample rate
We come to terms with the fact that the first data byte we read will always be useless - perhaps we don't mind, or perhaps we chop it off later, it doesn't matter
That first data byte read will trigger the first STROBE, and then the loop of "read byte from parallel pins -> send STROBE -> trigger new conversion on AD chip -> AD chip sends byte to parallel pins" continues until we break it (often with a mouse click, or automatically if we run out of memory to store all these bytes)
Usually we'll send every incoming byte to Paula, the Amiga's audio chip, to be played back from the Amiga's audio output. This means we can monitor the incoming signal even if we're not storing the data anywhere - useful to decide if we need to tweak the input level, wait for just the right moment to start recording, or whatever.
So what has been standing in the way of proper parallel port emulation / FPGA development? Is it just a matter of priority or is there some technical hurdle that hasn't been resolved yet?The external device needs to setup data right before the CPU access. While the .L sub cycle before the read might suffice for stable read it is more safe to already setup data in .H before
If you use a parallel port control line to “clock” the data you can set the line before the first CPU read and start reading with the first byte.
If you want to use the strobes to sync your reads then you have a problem: The strobe signal arrives _after_ the read! To get in sync with this signal you must use a trick: first perform a dummy CPU read just to generate a strobe and then use this strobe to sync your device’s writes:
In the above time sheet we dummy read at 0.H
The device already sets up data 0x22
The CPU performs the next read at 3.H and gets 0x22
The device waits for the raising edge of strobe (4.H – 4.L) and sets the next data
Reading in 2E and event 1E gets more difficult as in the worst case no “clock” signal is available and you have to use a sampling pattern with fixed E size to setup the data in time from the device. It is still open if it possible to write a stable 1E transport this way.
In most reader code the interrupts have to be disabled on Amiga side otherwise the clocked setting up of data before a read might arrive too late and thus a CPU read gets wrong.
