Please click on the underneath link to get to the page about this topic:
Check out this new page: https://www.bytedelight.com/?page_id=5787
Here are the offers: https://www.bytedelight.com/?product_cat=refurbishrepair
Took some time but here it is!
This is part 1, more to follow this week.
“Can I use a Spectranet and DivMMC together?”
“Can I use the PlusDlite and the ZX Spectrum +3 disk drive at the same time?”
I get questions like these a lot!
And yes, they are totally valid questions.
So let’s finally put the anwser in this post, will try to keep it in a nutshell!
ZX Spectrum architecture
The ZX Spectrum was developed to be an affordable machine back in the days.
One way of making that possible was by leaving out many components that other much more expensive systems had.
If you add external hardware to the ZX Spectrum, it’s usually accessed by I/O (input/output) ports.
The proper way of designing external hardware would be by ‘decoding its address bus’ using ALL 16 address lines from the ZX Spectrum.
However Sinclair themselves (the development team of the ZX Spectrum itself) already made an exception of this by claiming one address line for ULA (that big chip) purposes.
So it wasn’t already possible anymore to do proper address decoding.
And the way Sinclair did it, became kind of a standard with many hardware add-ons.
Many producers used just one or two address lines to decode for their hardware.
Doing it that way resulted in many devices becoming incompatible, especially more complex devices like Floppy Disk interfaces and these days the SD storage interfaces and now the Spectranet ethernet interface.
As a comparison: at the time when the ZX Spectrum was sold, many other machines had several expansion slots, but interfaces developed for those had more complete ‘address decoders’ to avoid conflicts.
Hence though those machines and add-ons were a lot more expensive.
So what about interfaces on the ZX Spectrum then?
The basic rule is: every two interfaces with ROMs and NMI circuits will collide by default.
All storage interfaces have at least their own ROM, and many have an NMI circuit.
Now some interfaces like Disciple have an inhibit switch that adds some kind of compatibility, but not much.
And there is no magic / standard way of working around this.
One ‘very difficult’ solution (it IS possible) is disabling the ROM and NMI on one interface but leaving it’s hardware available, so it can be accessed by commands from the other interface.
For example someone could write %-commands on Spectranet to add support to the +3 disk drive or DivMMC SD card and so on.
But there is another catch: with complex interfaces like Spectranet, DivMMC and others, there are often I/O conflicts as well.
That means that when the software tries to access the hardware on one interface, it accidentally may activate hardware on the other device.
To solve that, one of the interfaces needs to be changed on a hardware level.
Hence I keep saying: there is almost no way of doing this.
So you have to pick the setup you like the most.
Or two setups, or three… Mancave anyone??
A new version of ESXDOS, version 0.8.7, has been released.
Amongst the changes is a bugfix for the ‘.MKDIR’ command that created nested folders that didn’t work.
Here’s the announcement and place where you can download this new ESXDOS release: http://board.esxdos.org/viewtopic.php?pid=1240#p1240
And here’s an upgrade instructions page: https://www.bytedelight.com/?p=140.