avatar_JonB

Anyone interested in a PCW MIDI interface?

Started by JonB, 21:17, 09 October 19

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

JonB

Hello chums

I was chatting with GeoffB17 recently via email and he proposed a MIDI interface for the PCW, based on a design published in the old Maplin magazine. Geoff's interested in getting hold of one, but the question is.. is anyone else interested? I've reviewed the design and I think I can build it with programmable I/O on a Z80 (so, another card to add to your Z80 bus, if you have one), but the cost to develop it is too much for one unit. I'm hoping Geoff will write some software for it..

What say you all?

JonB

GeoffB17

Well, it would be nice.   My initial interest would be to play existing midi files, from the PCW to one of my midi modules (maybe my Korg NS5r, as it's sat here doing nothing else).

No problem doing whatever is needed with the data in the midi file, I've done the same regarding PCs and progs are working fine.   The problem that may be a real problem is with the timing.

Each midi event in a midi file has timing data, relative to the start of the file.   This data is in 'ticks', which are related to but not the same as, any real time.  So, when tempo changes during playback, this can be coped with.   If you choose to alter the tempo, this can be coped with.

In my PC, the timer IRQ is replaced with my own handler which maintains a 'tick' count which can be referred to while the file is playing so that each event is not actioned until it is due time-wise.

As I understand it, there is a 'timer' IRQ on the PCW, but i'm not sure if the handler can be replaced in the same is possible on a PC.

I understand that there was a midi system for the PCW (and for CPCs ?) from EMR.   I think the PCW system was called 'PCW Pro Performer'.  Has anyone here seen that system, anyone any clues how that handled the timing?   Or how well the system worked.

If the timing cannot be done properly (??) then it's possible that it could be done solely in software, i.e. as each next event is spotted the gap between the next event and the previous one is translated into a delay loop, the exact time of which is adjusted re tempo, time base, etc, as required.   A lot of experimentation would be needed to get the timing close enough to be effective.

Note, the midi interface referred to here is not any sort of sound card, it is purely to send OUT the midi data, to be received by a midi unit to be converted into actual sound there.

Geoff

JohnElliott

The problem is that on the PCW, only one process can really 'own' the timer interrupt, because reading the count of ticks clears it. And other things than the timer can interrupt on the same IRQ, so you have to read the count of ticks to know if it's a timer interrupt or not.
Once the timer interrupt's been received, it's handled by a CPC-like kernel with routines like KL_NEW_FRAME_FLY (add a new 50Hz handler) or KL_NEW_FAST_TICKER (add new 300Hz handler). The problem is that this kernel is strictly for the use of PCW CP/M, and its functionality isn't exported to programs that run under CP/M. Also, kernel memory is limited so there might not be any space to add new handlers to the ones it already uses to drive the matrix printer, the floppy drive, etc...


JonB

Hi John

Could you patch the RST7 handler vector and increment your own counter, then jump to the original handler?

GeoffB17

Hmm, sounds like there's going to be a problem.

So, I'll have to try the software timing.   May be somewhat clumsy. I'll just have to see.

I'll find a suitable simple midi file, and write a little prog to play it, just using the 'beep' for the sound.   At this stage, I'm not interested in the notes, just the timing of the notes, i.e. does the beat of the notes sound right for the tune.   And, as I'll know that the specific midi file should take xx seconds to play through, does this prog play the file through in the same xx seconds?  Or thereabout?

If I can get that OK, then add further complexity step by step.   Of course, further complexity of prog will affect the timing, so I'll be able to slightly reduce the software delay.

I'll see!

Geoff

LambdaMikel

#5
An interesting idea, but the problem really is software.

I can tell that the interest in a CPC MIDI interface is very very low, from my own experience of building one. And the CPC has the advantage that it can be turned into a MIDI IN sound module quite easily, whereas the PCW lacks any serious sound capability (DKtronics sound box add on?)

Playback of MIDI files and a Sequencer Program would need to be written first, and that's going to be a fair amount of work. In general, MIDI IN will be more difficult to realize than MIDI OUT, because of the realtime processing requirements and relatively high baud rate of MIDI. MIDI OUT is easy to realize, even with BASIC...

Does the PCW not already have a serial interface? Then, all you really need to do is to configure it for 312500 BAUD (if that's possible) and connect a MIDI breakout header board (maybe level shifter).

This one works great with a standard UART / Microcontroller TTL levels:

https://www.amazon.com/ubld-it-MIDI-Breakout-Board/dp/B00YDLVLVO/ref=sr_1_fkmr0_1?keywords=ubilt+it+midi+breakout+board&qid=1570980153&sr=8-1-fkmr0

Michael


JohnElliott

Quote from: JonB on 10:14, 13 October 19
Hi John

Could you patch the RST7 handler vector and increment your own counter, then jump to the original handler?
Depends if your code will be thrown off by RST7 interrupts that don't come from the timer. Also you'll need to work out how the existing system handles memory banking, because the interrupt can come while any of the memory banks is paged in.

JonB

#7
Hmm, I see your point, John.

@GeoffB17 if you can overcome this issue and implement it with interrupts (delay loops are too variable IMHO) then I might revisit the hardware side of the project. However.. no one else has expressed any interest, so I doubt I'd get the initial outlay back.

@LambdaMikel : the CPS8256 can only go up to 19200 baud (at least, according to the manual entry for SETSIO.COM) so it won't be quick enough to use that MIDI breakout board. Nice idea, though.

GeoffB17

I'm sure that I remember reading somewhere that the CPS unit was really reliable ONLY up to 9600.   I'm not sure if this was something to do with the PCW generally, or just the CPS box.   19200 was possible, depending on the driving software, but was risky (in terms of reliable data transfer).  So although this 'breakout' unit sounds interesting, it may not be practical.

As for the delays, yes, I'd be worried that the software method would not be reliable enough (re timing), but I'll still mess with software and see what it's like.  Just for the fun of it?   I'd understood that the Z80 might not be able to do the same things regarding the IRQ code, but I'd not thought as far as the possible complications regarding the bank swapping.

Geoff

LambdaMikel

Quote from: GeoffB17 on 21:17, 13 October 19
I'm sure that I remember reading somewhere that the CPS unit was really reliable ONLY up to 9600.   I'm not sure if this was something to do with the PCW generally, or just the CPS box.   19200 was possible, depending on the driving software, but was risky (in terms of reliable data transfer).  So although this 'breakout' unit sounds interesting, it may not be practical.
I see. Well, unfortunately 312500 is not negotiable in MIDI AFAIK. And bit banging it out is probably not an option either... at that rate. 

Powered by SMFPacks Menu Editor Mod