The Sinclair QL Forum

dilwyn wrote:The Tracker software itself, plus the MIDInet software IIRC, is in http://www.dilwyn.me.uk/misc/midi_tracker.zip

Afraid I can't remember if it contains source code - at least I don't *think* it does (from memory)

You are right, it does not. Would also be good, to get the sources of Phil Bormans Midi extensions (part of the ZIP), but I fear.....

Silvester wrote:But that can be better done with fast SERial 68681 (one of the reasons why I'm doing it); 31250 MIDI option with opto-isolators along with full SER.

Take a look at the NXP SCC2691. It has an auto-repeater feature which make the in/thru/out implementation not require any extra repeater hardware.

Application notes here, for your enjoyment:

https://www.nxp.com/docs/en/application-note/AN405.pdf

Pr0f wrote:It could be that the QL is an I/O peripheral of the z80 - during I/O fetches, only bottom 8 bits of address bus are used.

Thats what the manual says, but its not actually true

XorA wrote:

Pr0f wrote:It could be that the QL is an I/O peripheral of the z80 - during I/O fetches, only bottom 8 bits of address bus are used.

Thats what the manual says, but its not actually true

Yes - the upper 8 bits get loaded too, provided you use the correct instructions. The Z180/HD64180 had separated out the I/O instructions so that it could be made true again, but the stock Z80 didn't have those instructions. For the purpose of this interface, it is only using the lower half of the address bus it seems to me. You only need to push enough code in there to get it bootstrapped, after all

The NMOS and CMOS Z80 microprocessors always put a sixteen bit address out on the address bus. Including during I/O and DRAM refresh operations.

The Zilog documentation always specifies the lower 8 bits (A0 to A7). For some operations, the Zilog documentation also specifies the higher 8 bits. How useful the top eight address bits/lines are during an I/O operation very much depends on the I/O instruction used and what it is you are trying to do.

The Sinclair Z80 based home computers and the Amstrad CPC range both made use of the sixteen bit I/O address instructions.

Mark

1024MAK wrote:The NMOS and CMOS Z80 microprocessors always put a sixteen bit address out on the address bus. Including during I/O and DRAM refresh operations.

The Zilog documentation always specifies the lower 8 bits (A0 to A7). For some operations, the Zilog documentation also specifies the higher 8 bits. How useful the top eight address bits/lines are during an I/O operation very much depends on the I/O instruction used and what it is you are trying to do.

The Sinclair Z80 based home computers and the Amstrad CPC range both made use of the sixteen bit I/O address instructions.

Mark

I haven't touched the z80 for a while, but I thought that some of the I/O instructions just put a copy of your lower 8 bits or the contents of the A register on the upper half of the address bus, and it was only those that involved the paired registers that usefully placed the other half of the register pair on the top 8 bits. It was the refresh register with the Interrupt Vector register if I remember it...

Hi,

Is it possible to programme the Miracle Midi Z80 CPU to perform Z80 assembley language programmes other than MIDI interfacing.

Maybe this a way to add a co-processor to the QL.

I have a working Midi interface to try this out.

I will have to look at Phil Borman's extensions which was to connect the QL Midi to an Atari ST QL emulator via MidiNet.

Dave wrote:

Derek_Stewart wrote:But looking at the Issue 8 discussion, Rom Port is being removed.

Issue 8 is definitely retaining the ROM port. .

Issue 8 Discussions wrote:I plan to discontinue the ROM port after Issue 8 as the image can be saved in flash and relocated. I found the connectors to be very difficult to source, and quite expensive at £5/00 a piece. Therefore, I will be offering it as a built time option - if you don't want it, your Issue 8 board will be £5 cheaper.

This what I meant, can you clarify.

If this incorrect, can you implement an Aurora style Rom Port so the Second Processor boards can be interfaced.

Derek_Stewart wrote:

Dave wrote:I plan to discontinue the ROM port after Issue 8 as the image can be saved in flash and relocated. I found the connectors to be very difficult to source, and quite expensive at £5/00 a piece. Therefore, I will be offering it as a built time option - if you don't want it, your Issue 8 board will be £5 cheaper.

This what I meant, can you clarify.

If this incorrect, can you implement an Aurora style Rom Port so the Second Processor boards can be interfaced.

Ok.

Issue 8 PCB is split in two. This line is at a point between the ROM port and Joystick 2. The ROM port is on an add-on card that has a through connector for expansions. If you do not use the ROM port, you can put the extender in a drawer, and plug your expansions quite a bit further inside the QL case.

There's two versions of the space card - one is just a ROM port and J1 thru con. The other is 16MB DRAM and the ROM port.

People can choose to not fit the ROM port socket but get the spacer card and save £5. Or they can just skip the spacer card and have a shorter QL board and save £10.

The Aurora style ROM port, I 100% defer to Nasta.

After Issue 8, nothing I make will have a ROM port. I have considered a pre-decoded Q68-compatible mini-extension-bus for smaller/simpler expansions (like Acorn "podules") but there's too many choices and too little feedback/demand to pick any one approach over another.

How much work would be involved in doing a 'Tube' like the BBC ? There is even an option to have a raspberry pi zero as tube add on, all be it with bespoke code running.