Compatibility problem with TurboSound FM (register expansion of TurboSound Next interferes)

This section is for discussing everything about Next hardware and latest updates.
Alcoholics Anonymous
Posts: 501
Joined: Mon May 29, 2017 7:00 pm

Re: Compatibility problem with TurboSound FM (register expansion of TurboSound Next interferes)

Post by Alcoholics Anonymous » Tue Apr 09, 2019 4:28 am

Black_Cat wrote:
Sat Apr 06, 2019 12:42 pm
Dear Alcoholics Anonymous, no one in their right mind will create FM music tracks for the external expansion Board using 7MHz mode, or 14Mhz.
This is incorrect. The next is not a pentagon which can only operate at 3.5 MHz. The next can operate at several speeds - 3.5, 7, 14 and the choice is going to be up to the user and software. The user can dynamically change the speed while the program runs using a function key. Programs written for the next are very likely going to run at top speed - 14 MHz. For original spectrum sw, the user may choose to run sw at a faster speed to make games more enjoyable. 3d games, vector graphics games can benefit from this.

If we allow the bus to operate at speeds other than 3.5 MHz, and this is a possibility perhaps configurable via nextreg, it would be a shame if a peripheral designed for the next was unable to fully operate with next hardware. However, this wouldn't be a total disaster because programs using such a device could purposely slow down when communicating with it, with the next hardware ensuring the expansion bus is only enabled at, say, 3.5 MHz.

Music is normally driven at fixed rates, for exampe on a 50Hz interrupt. These are rates independent of cpu speed so in most cases it doesn't matter to the music sw that the computer itself is running faster. If the interface cannot operate at higher than 3.5 MHz then the sw will have to slow down when using the interface.

Just to make it clear: there will be no conflict with any device attached to the expansion bus. The next will not propagate io cycles to the bus if an internal device responds on a port. Software will be able to disable internal devices to allow external peripherals to respond on conflicting ports. In the case of this audio device, you would disable ports FFFD, BFFD and then this device and only this device would get io cycles for these ports.

This is how the expansion bus is intended to work and is yet to be implemented. The FPGA is becoming full and what gets in depends on a combination of available space and highest priority features.
Black_Cat wrote:
Thu Apr 04, 2019 7:12 pm
Alcoholics Anonymous, please do not enter PiyoTaro misleading. The ALS series has both TTL input and output, the HCT and ACT series have TTL input, and the CMOS output, HC and AC series have CMOS input and output.
There is no misleading. The salient point is these families are internally cmos and because of that drive outputs rail to rail. Actively driving output to +5 is the problem. TTL families made from bipolar transistors cannot drive up to +5 and realistically drive at most +4v and normally less which is compatible with the bus.
in Russian: the developers of ZX Spectrum Next have misled users, and have not fulfilled the promise to make the edge connector compatible with the original ZXBus interface. Therefore, the interface ZXNextBus, it will be impossible to connect most of the existing peripheral equipment. This is because the ZX Next expansion interface is only compatible with 3.3 V TTL devices, and is not compatible with 5V TTL.
I realize English is not your first language so I will quote the above yet again:
There is also a bug in the zx next pcb design - there are no level shifters on the expansion bus; only series resistors. The fpga is not 5V tolerant on input and the series resistors are not really adequate for interfacing with 5V devices. I say that with the knowledge that people have been doing it this way anyway for years without consequence (so far) as far as I know.

TTL logic from the spectrum's period, eg the LS family, is not able to drive outputs high above 4V anyway and the fpga is specced to handle 4V. But the logic family you're talking about is actually cmos and will drive all the way up to 5V.

I think what will eventually happen is that a 3rd party add on will come out that acts as level shifter on the expansion bus
Part of real life in product design is discovering issues and doing your best to work around them. In this case the favoured solution, as mentioned, is likely going to be a level shifter peripheral for the expansion bus.

The expansion bus is using a common method for interfacing 3.3v to TTL using series resistors. This works if the 3.3v inputs at the fpga are 5v tolerant. Xilinx discontinued 5v tolerant input in the spartan 6 family, although it was documented as tolerant early in the spartan 6's life. They now recommend level shifters for 5v inputs. The next design migrated from an altera part to a xilinx part because a good deal was had for a larger capacity fpga in the xilinx family. I suspect (but don't know) that the altera part was 5v tolerant.

The fpga will tolerate up to 4v on inputs and this will cover standard ttl families made with bipolar transistors. This is what most legacy hardware uses. It's only more recent hardware that is likely using cmos-ttl families.

Having said all that, people continue to use this method for interfacing 5v inputs to 3.3v devices, even for spartan 6 devices that are not 5v tolerant. There are projects that have done this and haven't seen detrimental effects yet. However, this is not something that should be done for the longevity of the device and is why another solution has been proposed.

Post Reply