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.....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)
Asymmetric multiprocessing...
Re: Asymmetric multiprocessing...
4E75 7000
Re: Asymmetric multiprocessing...
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.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.
Application notes here, for your enjoyment:
https://www.nxp.com/docs/en/application-note/AN405.pdf
- XorA
- Site Admin
- Posts: 1359
- Joined: Thu Jun 02, 2011 11:31 am
- Location: Shotts, North Lanarkshire, Scotland, UK
Re: Asymmetric multiprocessing...
Thats what the manual says, but its not actually truePr0f 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.
Re: Asymmetric multiprocessing...
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 allXorA wrote:Thats what the manual says, but its not actually truePr0f 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.
- 1024MAK
- Super Gold Card
- Posts: 592
- Joined: Sun Dec 11, 2011 1:16 am
- Location: Looking forward to summer in Somerset, UK...
Re: Asymmetric multiprocessing...
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
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
Standby alert
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
Re: Asymmetric multiprocessing...
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...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
-
- Font of All Knowledge
- Posts: 3932
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Asymmetric multiprocessing...
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.
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.
Regards,
Derek
Derek
-
- Font of All Knowledge
- Posts: 3932
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Asymmetric multiprocessing...
Dave wrote:Issue 8 is definitely retaining the ROM port. .Derek_Stewart wrote:But looking at the Issue 8 discussion, Rom Port is being removed.
This what I meant, can you clarify.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.
If this incorrect, can you implement an Aurora style Rom Port so the Second Processor boards can be interfaced.
Regards,
Derek
Derek
Re: Asymmetric multiprocessing...
Ok.Derek_Stewart wrote:This what I meant, can you clarify.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.
If this incorrect, can you implement an Aurora style Rom Port so the Second Processor boards can be interfaced.
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.
Re: Asymmetric multiprocessing...
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.