forum.defence-force.org

dizzy33 wrote: ↑Sun Jun 07, 2020 2:31 pmGreat ! Will you build some to sell them ?

I'll order the standar quantity (10 PCBs), one of them for me, and I’ll sell the rest.

Dbug wrote: ↑Mon Jun 08, 2020 6:33 am... does the omnibus also powers the Oric itself so basically we just need to power the omnibus and everything else is properly powered? If yes, how would that work with the RetroComputerShack SCART cable that's supposed to be powered for the SCART selection?

Yes, Omnibus will power the Oric itself, so we'll just need one external PSU. No problem with RetroComputerShack SCART cable, Omnibus has a female barrel jack connector to plug the PSU.

Great news Silicebit !
But I talked with Kenneth about the fact of connecting both the Erebus and my Protek together, he says that there will be a problem :
the Erebus and the Protek both use the "I/O control", and there will be a conflict due to the fact that there is no "opened collector".
I don't know what "opened collector" means, but according to Kenneth there may be a risk of burning a component ...
What's your point of view about this ?

The PAL16L8 in Protek interface has tri-state outputs, no problem here, but we must check if the I/O CONTROL output is put in high impedance mode when the Protek interface is not addressed. I still don’t know how the Protek interface works.

The I/O CONTROL line is driven by the output of a 74LS30 in Erebus, this IC has a standard totem-pole output, and when two or more totem-pole outputs are connected in parallel, the problems begin.

Here you can see why. And Q1 or Q2 or both, are destroyed. I think that Erebus would need to be redesigned to correct the I/O CONTROL output.

This is what you are aiming for



The I/O Control output could possibly be made into "open collector" at a pinch by adding a diode in series with the Erebus TTL drive output (cathode toward Erebus, anode toward Oric and other interfering devices), so that Erebus can only pull the line down to ground, but when the chip drives high, the diode blocks this. A pullup resistor may be needed on the I/O control line (anode side of diode) so that it floats back up.

A better way would be to use an actual Open Collector drive chip, but that's more work/redesign.

The diode is a good solution, even if the PAL16L8 tolerates a 0v output with a high state (short circuit to ground), according to the datasheet, it would be necessary to add a diode on the joystick interface too, assuming that the address # 3F3 is not decoded by this interface, with the omnibus and its regulator, one could imagine Erebus and Protek working together ...

The diode is a good solution if Erebus is the only totem-pole output in the I/O control line, or if it's in parallel with tri-state or open collector outputs. If there is another totem-pole output on the same line, the short circuit will appear again. Of course, we can add another diode in series with the other drive output, but as mikeb says, a better way would be to use an actual Open Collector drive chip for both outputs.

Thanks to all of you for these answers, as I am not good in electronic, I don't understand all you say, but if all I need is to add a diode to Erebus and to the Protek, I will be able to it as long as someone tells me where to solder it exactly.
But if I understand well, the diode may not remove all potential problems ...

Silicebit. wrote: ↑Sun Jun 14, 2020 5:25 pm The diode is a good solution if Erebus is the only totem-pole output in the I/O control line, or if it's in parallel with tri-state or open collector outputs. If there is another totem-pole output on the same line, the short circuit will appear again.

Correct, I did assume that the Erebus was the only "brute force" driver for the line, and that the other device was behaving well -- I haven't looked at the circuit for either

I'm not sure when Oric was designed that they envisaged people stacking up many many devices into the expansion port, so conflicts like this (and the "I want to be the boot ROM" vs "No, *I* need to get in first") were maybe not high on the list of thoughts ... problem left for expansion hardware people to solve.

Stupid question: would it not be feasible to merge the ROM's?

ibisum wrote: ↑Sun Jun 14, 2020 8:38 pm Stupid question: would it not be feasible to merge the ROM's?

Not a stupid question at all!

It would be possible to put the contents of more than one ROM into a larger EPROM -- that's been done for things like mods where people have put an Oric 1.0 ROM, an Atmos 1.1 ROM, diagnostic software, and something else, into one 27C512 (which is 4 x the size needed for Oric's #C000-#FFFF)

But -- to access any one of 4 quarters needs some hardware support (either manually switching two address lines between 00, 01, 10 and 11) or other electronic means, none of which is built into Oric, or the disk systems etc. So you'd have to design and add that yourself.

Then we're still back to the priorities problem -- a bare Oric has one ROM, it boots, and is in control. Simple.

An Oric with a single disk controller -- the external electronics in the controller force the internal Oric ROM out of the way at boot time (Asserting ROMDIS), and it demands to take over. Once it has done what it needs to (loading the boot sector, running it, loading the rest of DOS into memory and relocating it up into shadow memory, setting up vectors for ! commands etc) it can allow the external ROM to go quiet, allow the internal ROM to come back into action, and the now-running Oric can jump to start of basic, or Cold Reset, or whatever. Complex as that sounds, it's easy to see who's in control, and when. There is only one level of override provided by Oric, internal ROM or "other peripheral".

Add a second disk controller and you have a fight -- what mechanism can the disk controllers use to argue amongst themselves who gets to boot Oric, and how to transfer control from disk controller 1 to 2, before letting Oric boot. There is no mechanism for that, and I suspect no-one has ever tried to put two disk controllers on one Oric.

I think that external peripherals mostly are designed to believe they are the ONE extra device attached to Oric, beyond that, all bets are off (Oh, sorry, those items aren't compatible, shame ...)

Some other computers (like e.g. The Enterprise 64/128) had a better attempt at this sort of thing, by having the onboard OS ROM go through the memory map looking for "ROM signatures" which would allow it to find and enumerate any ROM extension, give it the opportunity to do things at startup, maybe take over the boot process etc, before finally falling back on the built in word-processor as the default code. BASIC was a plug in cartridge ROM. The disc system had its own ROM to get EXDOS booted. Control was passed around until everything had initialised, then someone took up running things!

Some other computers (like e.g. The Enterprise 64/128) had a better attempt at this sort of thing, by having the onboard OS ROM go through the memory map looking for "ROM signatures" which would allow it to find and enumerate any ROM extension, give it the opportunity to do things at startup, maybe take over the boot process etc, before finally falling back on the built in word-processor as the default code. BASIC was a plug in cartridge ROM. The disc system had its own ROM to get EXDOS booted. Control was passed around until everything had initialised, then someone took up running things!

I guess technically, something like the Omnibus could be extended to provide this type of functionality:
- Have the board itself have its own (upgradable) ROM
- Have all the connector slots use additional electronic trickery to enable/disable them (like a 8 bit mask that enable each of the 'n' connectors)
- On startup, control is given to the main board ROM which copies itself to RAM to perform a check of all the connected peripherals, checking if there is a ROM, and if yes, which size, checksum it has, and based on data entered in the board ROM code knows what is compatible with what

Probably a nightmare to do with discrete electronics, but conceptually I guess that's doable: You could have a Microdisc, Jasmin, Erebus, Joystick Interface, Speech Synthesizer, RS232 card, ... all connected at the same time!

I guess Dbug can be speaking about a thing like the Tandy color computer multi-pak interface. In my mind too.

http://www.trailingedge.com/trs80/Coco-Multi-Pakom.pdf

Hello,

see attached Sinclair programmable joystick interface

john davis uk

hello,

john davis uk

anybody have the 2 gal chips data files ?

or have a protek joystick interface to borrow or buy so I can read the gal bit maps

regards

john

<big voice>
Are you telling me when I'm not around people design electronics without caring about open collector lines ?
</big voice>

Joking, you can't know everything, these kind of things are usually taught during several years at engineering school…

Putting diodes should work, as long as the internal VIA's CS accepts the diode's threshold voltage as a logical 0. Another option would be to use NPN transistors instead, but diodes are definitely simpler.
/me opens his Memotech…A TTL 0 is defined as <= 0.8V on input, but most diodes have a higher threshold.

Now maybe the VIA has more tolerance on CS as it's an open collector input… Oh dear:
> Input low voltage (normal operation) VlL max +0.4 Vdc

So even with a low voltage shottky diode it's quite unlikely to work. It might work on your ORIC but not on another one.


It's also the kind of things where having some scratch area on the PCB with a few unused pads could come in handy to fix things, just saying.

Still, I suppose that means if I want to put expansion connectors in my design I better make sure I AND all the incoming IO_CONTROLs