2 years later...back at it again! Making great progress, having a few questions.
My github is here:
Several tapes have been completely decoded, so now I'm working on MAME's implementation of the tape drive.
I figured out that the standard cassette_image_device wasn't going to cut it. Too many differences between that and the intvkbd drive.
The cassette_image code, however, seems fine to use. This makes sense as the media should be almost identical to standard cassette media.
I'm implementing my own drive in machine/intvkbd_tapedrive.* using my own cassette_image_device-like class.
I've got the tape images loading, and the drive motor control working.
My question is about "plumbing" - aka how to setup the update() calls so that everything happens more or less like the real thing.
When reading a tape, the drive can provide interrupts at the bit rate of nominally 3000bps.
When playing audio, (which it can do simultaneously from a different track,) it will provide audio data as needed. My current tape format has 48000Hz audio just to make things easy for now.
When I implemented this in my personal version of MESS back in 2002, I set up a timer at exactly 3000Hz, and had a tape format with the bits already decoded. So, I stepped through bit by bit and everything worked great. However, this seems a bit like cheating, because the data on the tape is Biphase-Mark encoded, and not necessarily at exactly 3000bps. I feel like I need to be processing the raw tape image and still supporting audio playback as needed. At any rate, lets call this option A)
So, I have 2 alternative ideas.
If you look at the TRS-80 driver, it gets called every 11Khz even though the max bit rate is 1500baud. It processes a bit of the tape each time, looking for a "end of bit" and then processes that bit. This causes a little bit of random latency per bit, but as long as it's not too much, things should work fine. So, in my case I would use something like 24000Hz and do the same processing on my 3000bps data stream. Call this alternative B)
I just came up with C). Use a timer on the fly to trigger a callback whenever you know there is the next "event" coming from the tape. That way everything happens at exactly the right time. This seems a little complex to set up, but I feel like the accuracy would be great. I only wish there was another driver with this kind of example to follow - I haven't been able to find one. This makes me think I am missing something fundamental.
At any rate, I will probably try to get option B) going, and see how it goes. I can at least see how that would work all the way.
If any other MAME developers have a recommendation, I'd love to hear it.