X128 W.I.P. Page
15/01/2025
DISCLAIMER: I give no guarantees that I will ever implement/complete/release anything on this page.
Latest version: x128 V0.95d Open Alpha (DOS & Windows) (24/09/2024)
Online documentation: x128 instructions (02/10/2024)
Offline: x128 V0.95d instructions zip
Current experiments:
15/01/2025
Some things are beyond rational explanation.
Consider the coffee bun. It is clearly not a bun, yet it does not match any biscuit, cookie, or shortbread in its texture or in the nature of its crumbling.
Skulking, diffidently, on an obscure shelf in a seldom-perused corner of the bakery aisle. That little six-pack beckons you.
Does it not yield to the might of your mandible, in a most pleasing manner?
Indeed.
03/11/2024
I've done some optimising of the audio pipeline (as well as implementing a very basic "sleep until activated" flag for the soundchips) and it's now quite playable at ~30,000 cycles/ms, in a friendly video mode. Although some beeper tunes really slow things down.
The HiLow DataDrive emulation and all the video mode junk seems to have pushed it well above 8 MBs of RAM again.
I may be reaching some hard limits, based on some of the design decisions I made 30-odd years ago. Optimising is getting more difficult now and I need a bit more speed to (properly) say it will run on a reasonable 486. Maybe adding support for something like the CMSLPT would make sense as a way of offloading some of the processing on a slower machine.
31/10/2024
Firstly, I have been collaborating with Cesar (ZEsarUX author) to get HiLow DataDrive support working. It has been going well, progress is quite good. Currently, the file format is basically a huge stereo WAV file, so some more work needs to be done to make things more manageable.
Secondly, I ended up experimenting and added some support in x128 for just about every video mode in DOSBox... The code in x128 is capable of outputting to just about anything, although the added abstraction layer does slow things down a bit. (Lots of optimising required).
I added EGA (200 and 350-line monitors, and 64K/256K configurations), CGA (RGBI), and Amstrad. After that I had a look at what's new.
I've been running a 10 year-old version of DOSBox-SVN-Daum for testing, so I got DosBox-X. It had a ton of VESA modes that I didn't support yet, so I added those. Old VESA 1.0 modes, packed 4-bit modes, and other modes with unhelpful "bytes per scanline" values. I think the 24-bit modes are broken, though, they don't display correctly in their default configuration until you resize the scanline width. "High definition" modes refuse to respond to the "Get/Set Logical Scanline Width" functions altogether. One mode (0x303) reports itself wrongly (maybe because it's in the list twice and reports the same details for both).
Once I'd done that, I added MCGA (in a limited fashion, DosBox-X is missing the registers required to redefine the font) and then I ended up adding Hercules and Hercules InColor support (90 bytes per scanline and four interleaved banks (shakes fist at cloud)). Finally, I decided to add Plantronics ColorPlus (even though I can't test it, although I could try setting up another emulator for that).
All stupendously useless, of course. I don't think it's possible to get an MCGA machine that could run x128. Even more so for the Amstrad mode, as that's only available in a single 8086 PC (the PC1512). Hercules and Hercules InColor could be installed on a PC that might be able to run x128 (and maybe even run it through a second monitor?) Even Plantronics mode might be available on a clone card.
H - e - r - c - u - l - e - s I - n - C - o - l - o - r
I wonder if any of it will run on real hardware at all... none of it has been tested. Will a 320x175 EGA text mode actually work?
320x175 EGA text mode, it's ok for games (and a nice palette) but not so good for reading text
I tried my old Windows 98 machine (it smells a little... mouldy), but it doesn't even reach the BIOS, so that rules out any testing there... Another broken machine.
According to DosBox-X, I can run x128 in its fastest configuration without sound in about 25,000 cycles/ms (roughly a 486DX2-66). But 22 Khz, 16-bit sound adds another 40,000 cycles/ms (a P75 just for the sound routines... somehow?)
13/10/2024
Fully back online again...
The act of making the online documentation has revealed so many bugs and omissions to me... There is a lot to fix.
I have tested the Windows version on some other machines, and looked deep into the code (some of which I can barely remember writing). The joystick code was (and still is) very incomplete and remains undocumented. It can still access a whole range of axes, buttons, pov hats, d-pads, etc. and map them to certain controls, though. Some unusual possibilities are available. Mapping the System Mouse control to Kempston joystick is... strangely playable.
I would revise the Windows system requirements to a minimum of Windows Vista (32-bit) and DirectX 8 (because it seems to be compiled to require DirectInput 8, and I can't get it to ask for an earlier DirectInput interface). The good news is there seems to be some XInput code in there, so some controllers may work that otherwise wouldn't. I suspect that Windows XP (and earlier) will not work because of the compiler.
My 486 DOS machine is still giving me a full-on "1780 - Disk 0 Failure" though, so no luck in testing there.
05/10/2024
Ah, life without the internet, a taste of the future... I was left with little choice but to spend some money to get (temporarily) back online.
Anyway, the first draft of the online instructions are (finally) up.
I've found some bugs in the last build that I should probably patch up and make a small release for. I really don't want to do anything major and reopen an entire test cycle again.
02/10/2024 (offline)
Guess who ran out of mobile data and had to spend a few days offline? It would've been 10p per megabyte if I'd gone over. I could've ran up quite a bill just with background processes and software updates... Except the billing date on the "data warning" app was wrong, so now I've gone over the limit! (I used up about 80 MBs in a few hours, despite watching zero videos and downloading nothing) and there's another 6 days to go. Bah.
26/09/2024
Did you know that the average 360p, 30 fps video still uses 3 megabytes per minute? I've used up 80% of my mobile data package in about 12 days, despite being very careful.
Anyway, I include some blank disk images to cover for the missing ones so far: More Blank Disk Images
These disk images should not be taken as Verbatim (or any other brand of disk). I haven't tested them by writing them back to real disks, so the geometry may be a little suspect. They are, however, enough to play around with. The emulator is "open alpha", so consider the disk images "open alpha".
The RDD format (for the Macronics FIZ) is a (possibly) temporary format. The FIZ has a strange, custom format that manages to fit 11 * 256 byte sectors onto a single-density track. The hardware uses no FDC and just reads/writes bytes via a series of logic circuits. It always reads or writes a track at a time. So, for now, I've made this custom image format, which includes the gap bytes too.
The QDD format (for the Clive Drive) is "yet another Quick Disk format", which I might deprecate, as using someone else's format might make transferring them a lot easier. The hardware does not use a QDC (and Quick Disk Controllers did exist) and also reads/writes bytes via a series of logic circuits. So, like the FIZ, this is a raw dump of sectors and gap bytes.
Unfortunately, I haven't managed to make a suitable disk for the MB-02. I've found that the emulation currently does not work properly with "newer" system disks (which mention IDE interfaces), but it does with older disks.
Another history lesson... Back when Hungary was still part of the Eastern Bloc and the 8" floppy disk was the standard, they managed to invent a much smaller, sturdier 3" disk. However, they did not gain a lot of traction in the West, and the drives and media are now very, very rare indeed. Good luck finding one.
The geometry of the MCD-1 is a little odd. 45 tracks (compared to the 35-40 tracks common at the time), single-sided only, with a smaller track capacity due to a faster rotation speed (7 rps, instead of 5 rps).
But, clearly a stock of these ended up in the UK in the early '80s, because a number of articles about ZX81 and ZX Spectrum disk interfaces mention compatibility with the MCD-1 drive. A lot of these articles refer to the drives as "Hungarian 3 inch drives", to differentiate it from the other 3" drives (usually referred to as "Japanese" or "Hitachi drives").
The "Analogue Information Systems FDC" (ZX81, and released as the FDC-100 by COMPUSA for the Timex TS1000 in the US) clearly states support for it.
The Technology Research FDC-1 and Beta SD interfaces (ZX Spectrum) are stated in articles as supporting it.
The Thurnall MCD-1 (ZX Spectrum) supports it. It even has the drive in its name (and the interface PCB was held *inside* the same case as the drive), which is a little awkward as they stopped using them after a while and started using "Hitachi" drives. (This is an unemulated interface, due to a missing ROM file. In fact, there may be two different ROMs to cover the different geometries).
The SpeccyDOS interface (ZX Spectrum) manual lists a 45 track, single-sided disk format that seems to match the MCD-1, which makes sense as the SpeccyDOS interface was also developed in Hungary.
The FDC-1 does support the MCD-1, but the format routine is held on a utilities disk. The only routine found so far (on a standard floppy disk) can only format "standard" disks. So, the MCD-1 format routine must be on an MCD-1 disk somewhere. The chances of finding it are remote, if not impossible...
But, a little bit of reverse engineering of the Sandy FDD2 "SM-DOS 1.5" ROM (a clone, which has provided the only known ROM dump of the FDC-1 - there is no known dump of the original ROM), showed support for a 45 track, 7 sector, single-sided, single-density disk. It seemed to match the description of the single-density format mentioned in the MCD-1 manual.
So, I built a DSK file with a best-guess geometry, changed some of the information in the first sector, then ran the INIT command (which initialises the directory) and:
A long, long time ago, in Hungary...
From an emulation perspective all you get to see is a smaller disk with 308 blocks free (77K) vs 390 blocks free (97.5K) for a standard 40 track, single-sided disk. But it is a nice little recovery.
25/09/2024
X128 is provided as a DOS 32-bit EXE (you probably need at least 8 MBs of RAM and a high-end 486/low-end Pentium), a Windows 32-bit EXE, and a Windows 64-bit EXE. A 64-bit build doesn't really make a lot of sense for something this small, but things are being deprecated all the time. Mind you, if someone made a 128-bit CPU, I could make an x128 build of x128... Hmm...
I tried to test the DOS version's memory footprint with one of the DOSBox forks, but I found that it used up a minimum of 32K for each malloc, even if the amount requested was much smaller than that. So, I concatenated some mallocs and suddenly I needed 1.5 MBs less than before. The absolute bare minimum I found it could run on was 7.25 MBs (with 6.6 MBs free). I'm not sure how accurate that is compared to the real thing.
Exactly which versions of Windows this will run under is not certain. It has only been tested on Windows 7 & 8 recently. The previous version was happy all the way down to Windows 95, as long as it had DirectX 5 installed. I'm using a newer compiler than before (VS2015), which (usually) tends to limit support of older OSes.
Unfortunately, I'm finding that most of my hardware is failing (and that most of my hardware is failing...) My Win XP machine has a hard drive failure. My Win 98 machine was freezing, the last time I tried it. My DOS 486 has a hard drive on its last legs, with data corruption on it. I've had to boot it with a floppy disk recently. In fact, even my broadband router has broken down and I'm having to (carefully) upload this with a mobile connection with a rather-limited data package.
Anyway, this release of x128 is "mostly about the disk drives".
It now has reasonable support (using image files) of the following storage interfaces:
Beta 128, Beta 48, Beta Single-Density, FDC-1, DISCiPLE, +D, Didaktik D40/D80, Interface 1 (Microdrives), Opus Discovery, Opus Spectra, SpeccyDOS, Rocky Gush, Swift Disc 1, Swift Disc 2, Watford SPDOS, Kempston Disk, Kempston Disk 128 (a modern modification), Clive Drive, Macronics FIZ (and the subsequent names of it), Turbodrajv, Timex FDD, Convoy CDOS, Videobit Sistema S80, Pera Putnik floppy interface, Spectrum +3 disks, Cassettes (of course), and (partial) support for the Wafadrive and MB02.
My FDC emulation can't change the geometry of a disk image (yet), so I will have to supply blank images for all of these! Fortunately, someone has made some images for some (but not all) systems already: Blank Disk Images
It also supports the following interfaces, but without any storage hooked up to them:
SDI (1541), Logitek Proceed (1541), HiLow DataDrive, Challenge Sprint.
For audio, it supports the following:
Beeper, Two AY chips (Turbosound), SAA1099, Fuller AY chip, Currah Microspeech, Cheetah Sweet Talker, Fuller Orator, DK'Tronics Speech Synthesiser, Datel Vox Box, SpecDrum, Covox, Stereo Covox, Soundrive (4 channel DAC), SID chip at port $CF, SID chip at MB03 ports, MIDI through the Spectrum 128 AY chip, MIDI through the Zombie Zombie custom cable, and (very) limited RAM Music Machine (MIDI/DAC) support.
25/09/2024
A little history...
x128 was first released in 1996. Initially, it was an X11/Unix university project, running on Sun Sparcstations with some version of SunOS on them. I couldn't honestly tell you the specifications of the machine or the exact model.
I didn't have constant access to the computer labs, so I made a DOS version that I could work on at home, and it was initially called S128. It was a 16-bit executable compiled with Borland C 3.1. (I recently found a very old, very limited version that still had EGAVGA.BGI in the directory). I eventually just called that X128 too, but with a capital letter, since it was on an 8.3 file system (you may have noticed that there are still some htm files on this website).
In time, I left university and had no access to the labs. My PC could run an old version of Linux, but it wasn't a powerful enough setup. I gave up developing the X11 version and concentrated on the DOS version.
Then, I got my hands on Watcom C, which was able to build a 32-bit executable with a flat memory model. The result was a nice speed improvement. For a while, I kept the codebase able to compile on both, but there seemed little point maintaining the old Borland C version, since you needed quite a good 486 to run X128 well anyway. So I gave that up and stuck with Watcom. I skipped Windows 3.1 support, mainly due to lack of knowledge.
Then Windows 95/98 came along, but X128 would run fine under them. Not under Windows NT, but that wasn't a common home setup.
Some time later, Windows XP turned up and X128 for DOS was no longer viable, except when running under VDMSound (which was less than ideal).
From a (probably) 32-bit X11/Unix version, to 16-bit DOS, 32-bit DOS, 32-bit Windows, and (now) a 64-bit Windows version. It has been a long-running project.
Consequently... x128 (I'm not sure whether to use a capital X or not) is still, basically, a DOS application with a Windows wrapper around it. It still has its old DOS interface, but with some very, very rudimentary Windows parts added on. It is not written to comply with modern programming or emulation standards, nor does it behave it like it.
It's not even cycle accurate, but it does emulate a lot of interfaces.
It should be viewed as a leaky old boat and (like me) it is something of an anachronism.
24/09/2024
Finally, after 10 years and 7 months, I present an update to x128. It has a significant number of additions and bugfixes, but I have not documented them yet.
I will (slowly) update the text file and incrementally add online documentation to this page, rather than wait... forever... for me to complete the whole thing.
08/09/2024
I'm still a bit stuck... There are so many interfaces that testing has proved difficult and two of them have to be emulated every half scanline and two have to be emulated once every scanline (because my Z80 scheduler is quite, quite terrible). At the moment I have to make separate builds for the two...
I also found some audio hardware that I forgot I'd emulated...
01/09/2024
I read of the death of Bruce Gordon recently, although it took place in June. I know little about the rest of his life, but he was most known for being half of MGT (Miles Gordon Technology), who managed to put together a number of Spectrum-related devices in the '80s and '90s. The SAM Coupe, the DISCiPLE, and the Plus D disk interface being the most notable.
When someone dies who has had some impact upon you, it makes you think about your own life, the nature of things, and the time that has passed. It got me thinking about a part of my younger days that I had filed away.
At that time, disk drives were expensive and it was less common to have one for your home computer, particularly for a low-cost system like the ZX Spectrum. The price of a disk drive and interface could be greater than the amount spent on buying the computer itself.
The Spectrum did not have an official disk drive (at that time), but even for systems that did it was more difficult to find software on disk. Retailers and publishers knew that cassettes would sell more quickly, so they stocked and produced fewer disks, and they were notably more expensive when you did find them. So, in this country, software tended to come on cassette tape.
Third-party disk interfaces arrived and they (eventually) included a snapshot button, which would save the whole of memory to disk, thus allowing you to use your software on disk regardless of the loading system, and without requiring any specialised knowledge.
Even then, only a minority owned one. The price was immense compared to the price of a game (which could be as low as £1.99). If it was just games you wanted, then you might as well tolerate the not-too-bad 5 minutes to load a 48K game and get a lot more games instead.
But if you had an interest in programming, then you really did need to buy one. You could learn BASIC (awkwardly) with just a cassette deck, as errors would rarely crash the machine. But with machine code, the machine could crash every single time you tested your code. A disk drive (or a similar storage device) was essential.
So, in late 1986/early 1987, I saw this advert...
This was at a time when "disk" was still spelled "disc" in the UK, and it allowed for some fine wordplay in product names. DISCiPLE, Opus Discovery, etc. Boy, you Americans really missed out(!)
This jazzy image may have been designed to disguise the fact that they didn't have a case (or even all of the buttons) at the time the photograph was taken, or that they'd paid for a colour advert but the product had very little colour to show. But that did not matter, the specifications did, and the combination of the package sparked my interest.
I was barely a teenager and this was something that was far beyond the usual toys I would ask for at birthdays and Christmas. But, that unique mixture of disk, snapshot button, and joysticks convinced me that this was something I would find use of for an extended period of time. (I didn't have much use for a printer (paper costs money and runs out, and I couldn't submit any schoolwork on printer paper) and, like most people, I have never used a Spectrum network, although it seems there were some customised versions of the DISCiPLE sold into the education market and used in schools).
(Incidentally, a very similar interface is described in an advert by Saga Systems around the same time, although their interface was never released as they folded fairly soon afterwards. The chances of a second interface with the same combination of features being developed at the same time seems quite unlikely, and I have wondered whether they initially had a deal with Saga which fell through).
I knew that I couldn't ask for something as expensive as the DISCiPLE interface and a disk drive at the same time, so I asked for the interface alone, knowing that I could use those two joystick ports for two-player games until such time that I could get a disk drive. So I got it in early 1987, as a birthday present, and then waited until Christmas before I could get the disk drive to go along with it!
The DISCiPLE can take a larger ROM than it comes installed with and the pass-through edge connector has more pins than the Spectrum does, hinting at future expansions which never occurred...
Along with that came INDUG, the Independent DISCiPLE User Group (as it was called at the time), as well as their A5-sized magazine FORMAT. The magazine was more technical and not like the mainstream Spectrum computer publications, which were moving away from the type-ins and technical articles style, and into a more commercial phase which was largely games-oriented.
So, I would read the monthly magazine and understand a little of it but wasn't able to use any of the routines, and I used the DISCiPLE as a glorified joystick interface until December. I would occasionally load up the System cassette and play with a few options, but without really knowing what I was doing. During this time, the ROM was upgraded to System 3 to support the 128K machines. So, I sent my old chip away and got the new one. I had a System 2 interface for nearly a year and I managed to miss using it completely (at least until the modern era of emulation).
So, December comes and I finally get a disk drive. There was a glitch and the interface had to be repaired, which was handled by a small store called The Micro Shop in Partick. Places like that actually existed in those days, and it might explain the "DEE" sticker on one of the chips. But, finally, it worked. So I load a game, press the snapshot button, and then load it back in. FIVE SECONDS! I was stunned and I realised what I had been missing out on for that year! For a 128K game, over 10 minutes of loading would become 10 seconds. Incredible! And I was able to experiment and grow my knowledge of computers and programming. What more could I want?
The interface, of course, had its bugs and idiosyncrasies. But, once you had figured those out, your data was quite safe.
The System 3 ROM allowed the interface to save 128K snapshots, but the interface had not been designed with the 128K Spectrum in mind. It had no way of knowing which page of memory was in place. So, the string "BRUCE" was written to the current page and then the interface would check all the pages to see which one had the string in it. Bruce's signature was being written every time I used that snapshot button on a 128K game!
But there were limitations. You could fit sixteen 48K snapshots on a disk, which was excellent, but you could only fit six 128K snapshots because there was no attempt to identify unused areas of memory. Some 128K games could not be snapped because of a bug in the Spectrum's ULA chip and the I register, which meant that when the DISCiPLE was swapping pages - memory was being corrupted. A couple of 128K games even checked for a change in the AY sound chip registers. The DISCiPLE didn't save those, so the game would detect this and reset the machine. On the ZX Spectrum, games would often be 48K but have a small extra file loaded in for 128K music. If you wanted both versions on disk, it would take two snapshots - a total of 176K. Those disks were expensive when you only had pocket money.
Finally, there was a growing trend for games to be multiload - loading extra sections after the main game had loaded. There was no way to automate the disparate methods of file handling.
Naturally, where there is a need, knowledge flows in to fill that gap. The interface, the user group, the magazine, the shop, the games, various snapshot devices, and pieces of file transfer software that were published to solve parts of the problem, all combined to form an environment where I could learn how to bypass all of those issues. In time, I outgrew that snapshot button and now I know all that stuff inside-out.
Bruce made it possible (along with the giants he stood on the shoulders of).
(At this point it is customary to add some section where the writer states that it resulted in their successful career. Sadly, I cannot quite manage that. It did lead to me doing a degree in computer science, I even made a Spectrum emulator as part of my year-long project and the knowledge from that has served me well in subsequent projects. But when I left university in the '90s, it was at a point of recession and significant decline in the computer and electronics industry around where I lived. Many places closed down and it was hard to even find a place seeking applicants. I managed to get a series of short-lived jobs and they were at a reasonable level, but I cannot say I was successful in the way that society usually measures it, whether it be commercially, critically, by being prolific, or by finding my place in the world).
This is also a good point to mention that not all of Bruce Gordon's designs have been preserved and emulated. Prior to the DISCiPLE was a device known as the Gordon Microframe, an ambitious amalgamation of disk interface, motherboard, expansion slots, and I/O channels. Knowing Gordon's other work, it would include a System disk or cassette, which is also missing. The only software I could find that claimed to support this interface was The Last Word, published by Saga Systems, which made me wonder whether there was a link, as I mentioned earlier.
The advert (from Sinclair User, Issue 035, February 1985) looks like it might be a collage, such was the technology of the time. The voucher (from Your Spectrum, Issue 19, October 1985) makes quite a good offer, but it sadly expired some years ago. (Some pictures courtesy of archive.org).
This, along with other (unrelated) interfaces such as the Triton Quick Disc, Thurnall MCD-1/Disk System, LMT SPD1, and many others are missing. Efforts should be made to preserve their ROMs and media to avoid them being lost altogether.
30/08/2024
Much time has passed and my responsibilities have lessened, but never quite go away.
I can't seem to get what I need from life. I reach the cusp of old age and I find it all rather pointless. To say "things are going well" would be a significant exaggeration and I am tired of the needless obstacles put in my way. Anyway, before I go, I still have time for a few pointless acts.
I've done very, very little in the last five years, particularly, but this year has seen a little bit of activity from my brain.
It's been over 10 years since the last V0.95C (2) "Open Alpha" version was released (February 2014) and a new one is long overdue. But you will still have to wait a little bit longer while I patch it up a bit.
If you like disk drives, then this will be of interest to you. There are a LOT of them and I'm somewhat dreading the amount of documentation I will have to write...
14/05/2017.
My life is very complicated at the moment. The need to care for multiple family members (and tangle with bureaucracy) makes me wonder if I will ever finish a project again. It seems I have reached the phase of my life where dreams must be put aside and I must perform my duties until I am the one who needs to be cared for.
I had promised to help get TZX files working in an MSX emulator. I had planned to add some old Multi code into X128, so I could emulate a simple MSX-1 system and play TZX files. Unfortunately, the Multi code is very old and partially incompatible with the new X128 codebase, so it needs quite a lot of modifications. Still, it would be nice to see it working.
I will concentrate on that for now, when time permits.
11/12/2016.
A little bit of Macronics FIZ archaeology!
When you look through the old magazines (especially those before 1986), you do find an awful lot of hardware. A fair amount of it has been lost in the mists of time, including a surprising number of third-party disk interfaces.
I have been looking through WoS and various magazine databases and come up with a hypothesis - that the Macronics FIZ has a number of incarnations.
I have come up with a list, based upon various descriptions, such as: using 8K of RAM, the number of files per disk side (39), that it only supports 1 file per track, that it stores 2,816 bytes per track (despite being single-density), UDGs are saved along with BASIC programs, the very unusual BASIC commands and the fact that there is a maximum file size (so they provide a special bit of software that can save the full Spectrum memory, excluding the screen).
| Company | Product Name | Magazine References | ROM Available? | Filename Length | Comment |
| Macronics | FIZ | ??.82-12.83 | Y | 6 | Manual (Over 100K storage, 8K RAM used, 2,816 bytes per track, 1 file per track, 39 files, uses f$ in BASIC). |
| Interactive Instruments | Viscount Disk Drive System | 02.84-06.84 | N | 6 | 8K RAM used, Macronics copyright message, 107K per side and 2,816 bytes per track, 1 file per track, uses f$ in BASIC |
| Primordial Peripherals? | ? | 08.84? | N | 6 | "P2L or Primordial Peripherals Ltd. showed me a complicated but impressive system aimed at the small business owner. Priced at £249.95 with a drive unit (£79.95 for the interface) it was fast and efficient, although it needed a bit of study to get to grips with the operating system. It used 2K of RAM for the DOS and a further 6K workspace." |
| Statacom | Datafax Disk System and Datafax Spectrum Disk Interface | 09.84-12.84 | N | 5 | "Regular readers of Sinclair User will remember one of the first disc systems for the Spectrum, that from Interactive Instruments - later taken over by Primordial Peripherals. Those that do will immediately feel at home with the Statacom interface." (8K RAM used, 39 files, 1 file per track, 2,816 bytes per track, 107.25K storage, uses f$ in BASIC) and 100K per side. " A special loading procedure allows you to pack in the largest of programs, although you lose the screen display in the process". |
| Servicon Dynamics | Crescent 401 | 02.85-03.85 | N | ? | Uses 8K RAM, 100K per side, 39 files per side. "The manual contains a machine code program which allows 48K programs to be loaded and saved". |
| Omnitronix | Pacer Disk Interface | 06.85-01.86 | N | ? | " It is instantly recognisable by users of the Primordial Peripherals and Statacom systems." Early versions are the usual "107.25K, 39 files, 2,816 bytes per track, uses f$ in BASIC", but later models claim up to 400K and support DS and 80 tracks. |
This is a list of disk interfaces that, I believe, may be of one single design. Each device is advertised or reviewed with comments that suggest that they are very similar. It is possible that they may sound similar, by coincidence. In the absence of further information, it is impossible to say whether they all are. There is certainly a clear chain from the Macronics FIZ to the Omnitronix Pacer, based upon the various magazine references and the dates of the magazines as well - they seem to form an order where they never overlap. The Primordial period has no advertising dates (although there is a mention of it in 08.84). The Servicon Dynamics device is only linked by the claims made in the (very few) adverts they placed.
28/11/2016.
I've been asked to release an updated version of X128 Open Alpha by a few people. Unfortunately, I have limited time to work on it and my brain is useless just now.
There are some big bugs in the code. The Betadisk 48 code has stopped working (again). The FDC code is now merged. Previously, the DISCiPLE/+D and SAM Coupe disk code was handled by a very, very old version of SimCoupe's FDC code. Now it's handled by the normal FDC code (which runs almost everything else, apart from the +3 disk emulation). It works pretty well and allows much more flexibility with disk formats, but is a little less compatible in a small number of cases. It's trying to emulate the whole FDC range from WD1770 to WD2797, so I guess it's bound to happen. I've also come to the conclusion that I'll need to emulate some sort of timing in the FDC, if all of the disk interfaces are ever to work properly. For example, the Swift Disc seems to require the timing gap between sectors, otherwise the NMI routine will keep reading bytes until the end of the track (overflowing its sector buffer and writing into the hardware registers).
I've also been asked to emulate the Logitek Proceed 1 disk interface and the SDI (Spectrum Disk Interface). A reasonable request, as I can't think of anyone else on the planet who is trying to emulate old Spectrum disk interfaces.
Both are interesting devices that let you connect a Commodore 1541 drive to a Spectrum 48K. However, the drive is nearly a computer in itself - a 6502 with ROM, RAM and a serial port. It can be emulated in a much simpler way, though without full compatibility. There are a number of drive types. The 1541, 1571, 1581, FD-2000, FD-4000 and many more older ones to consider...
Finally, I noticed that the Macronics FIZ interface has had its ROM dumped: speccy4ever (not to be confused with the Facebook group of the same name). There's also a circuit diagram and it's remarkable - it has no FDC! It has some circuitry to handle byte reading and writing and everything else is a direct connection to the disk drive!
22/10/2016.
I have the NMI buttons working (via a hack, each ROM has a slightly different entry point). This enables access to the various DOS versions, which allow you to do everything you want with your disks, as well as load and save snapshots. It looks very powerful, but the FDC isn't being emulated well enough for anything to work.
I can just imagine using this system to put all your games on disk, then playing them all without even having to reset the machine. It must've been pretty luxurious!
Various Swift Disc DOSes
09/10/2016.
The Sixword Swift Disc is an interesting interface. It looks rather powerful and existed in the same time period as the DISCiPLE, but it seems to be rather rare (I have never seen a screenshot of it running, for example). It has a snapshot button, which is very common, but that button takes you to a DOS system, which isn't common. The first model has 16K ROM and 8K RAM, which is better than the usual "squash everything into the first 16K" technique used by most other interfaces of the time.
There are two versions of it, both have the most unusual ROM banking systems I have ever seen. Additionally, the way the FDC code has been written requires very, very good FDC emulation (which I don't have!). It's a complicated system and there are so many unknowns, that I'm not sure if I'll be able to emulate it properly. I don't even have any disk images for it. In the meantime, this screenshot of a catalogue of "no disk" is as far as I can get.
As much as you can get from the Swift Disc 1!
10/06/2016.
Denienced part 2? A scandal erupts over ULAplus and modes 3, 5, 7 and 9!
06/06/2016.
I promised Cesar Hernandez (author of ZEsarUX) that I would include modes 5, 7 and 9. These are like Radastan mode, but with the resolutions 256x96, 128x192 and 256x192. They are implemented in ZEsarUX and a new Spectrum clone - The ZX Prism. I also promised that I'd release a version of X128 including it, but I will have to tidy it up first.
Here is a screenshot!
The highest-resolution Neula
31/12/2015.
I haven't been able to update much. My mum has mixed dementia and significant mobility problems, which takes a lot of my time and energy.
In the meantime, I noticed "Radastan" mode had been invented as an extension to ULA+ on the new ZX-Uno Spectrum clone. I couldn't resist a quick emulation of it (two hours), although there is probably more to emulate - I don't have the full details. It's a 128x96x16 colour mode, which reminds me of a rather more colourful CoCo/Dragon display. Happy new year!
Images in "Radastan" mode
05/04/2014.
Thanks to Phill Harvey-Smith for the Kempston Disc 2.0 ROM and a couple of disk images! I now have a partial emulation of the Kempston Disc interface! It can page in the ROM and you can enter commands, however the disks are not detected.
Eugenio Ciceri provided the MF1-KDOS ROM (see the Multiface page for information and pictures for that). He also provided some interesting information... There was a version of the Kempston Disc interface exported to Italy and rebranded as the "Sandy DiscoVers3". It used KDOS 2.1 and had a localised version of the ROM too. I will post more about this later.
KDOS Capers!
14/03/2014.
Using DOSBOX, I have determined that the DOS version of X128 currently requires 8 MBs of RAM. That's too high for something that's supposed to run on a 486. 4 MBs would be more realistic.
27/02/2014.
I have added a link to the latest work-in-progress version at the top of the page.
Open Alpha V0.95c includes SPECTRA support. Even the DOS version (it's been a while since I wrote some Intel IA-32 code), but the DOS version is buggy in some other matters (Opus and some other drives don't work, etc).
There's also a bug where you have to reset twice before the SAM Coupe emulation works.
25/02/2014.
I can now load some of the TZX V1.20 files (no CSW support yet).
Also... behold the latest pics of SPECTRA Blitz by LCD.
SPECTRA Blitz
04/02/2014.
Some emulation of the SPECTRA interface video modes. Amongst other things, it allows a choice of higher-resolution attributes and a selection of 64 colours. Some of the video modes are a bit odd, due to the limitations of the hardware itself.
Snake Menu
Snake 4x4 Extra Colours
Snake 2x2 Basic Colours
SPECTRA Palette
SPECTRA Highest Resolution Basic Colours
SPECTRA Highest Resolution Extra Colours
SPECTRA Image Viewer 4x1 Double Attribute Extra Colours
Vision TR-DOS and DDR CP/M.
Vision TR-DOS (using the Betadisk 48 interface) and CP/M emulation, as used in the former East Germany. The CP/M requires the LEC 80K RAM modification (not quite the same as the larger LEC RAM system I'd emulated earlier) which was popular in some places. All the details were thanks to Porthos, who also did some fabulous testing for me. We exchanged broken EXEs for days on end until I discovered the DirectX bug I had in the code all this time (it thought that any bitmap mode with alpha bits was actually a palettised mode).
Vision TR-DOS
DDR CP/M
Rocky Gush.
Did you know that there was a disk interface in South Africa called Rocky Gush? It was named after its maker. I implemented a partial emulation of it a while back, but I'm having terrible timing troubles with it. It also implements a number of BASIC extensions in it as well (including a 64-column mode), it's a curious interface.
Rocky Gush bootup
04/10/2012.
OK, clearly I spoke too soon. Further information was found, it is possible to get to BASIC without a bootdisk and I was able to emulate it further than before. Here is a picture of a SpeccyDOS 4.1 directory listing! The boot disk would still be very useful though, as the snapshot button software is installed into RAM from it, so there is no NMI fun yet.
SpeccyDOS LIST*
02/10/2012.
I've been so busy, I haven't had a chance to update this page.
First of all, Watford SPDOS... This buggy picture is the first ever of SPDOS and possibly the last, if a boot disk is never found! SPDOS/KDOS need a boot disk, otherwise they just get stuck and you can't get into BASIC. The normal behaviour is to stick at the dull white screen looking for a drive and disk.
First and last?
Secondly, support for the Opus Discovery and Betadisk 48:
TR-DOS 4.11 is just 8K, while TR-DOS 3.0 is a measly 4K! Note that TR-DOS 3.0 is asking for a password, a feature that was phased out in later versions. Thanks to Velesoft for finding the older Betadisk 48 ROMs.
02/07/2012.
I have decided to move the Multiface stuff onto a separate page. Hopefully it'll be possible to find some of those missing ROM versions and build up the full list.
Multiface ROM Collection Project
After a little bit of work, it is easy enough to support the "old" Betadisk interface and to support the Opus Discovery by allowing a more complicated byte read routine in my Z80 engine (as much as I want to avoid it though).
The Kempston Disc interface (which was formerly sold as the Watford SPDOS interface) is a much harder job. The system is loaded from the drive when the computer is switched on or reset - it will not go to BASIC if it can't find it. As a result, you can do nothing at all if you don't have a drive and disks! One (uncorrupted) ROM of SpeccyDOS 4.1 is available, but it would also need a disk image (at the minimum) to try and emulate it. (NOTE: It later turned out that SpeccyDOS was unrelated to SPDOS!)
01/06/2012.
TZX files loaded as TAPs for the first time... will be better when it can do a bit of edge loading mixed in too. The new conversion of Majikazo uses the unofficial instruction "RES 0,(IY+004),A", which I hadn't bothered emulating... there's always one isn't there, so I added that one instruction in place of a proper fix for all those DDCB/FDCB special instructions.
I remembered that I briefly had a Multiface 128 that could save to "hypertape" and Opus Discovery. I got it, but it wouldn't work with my DISCiPLE interface so it had to be sent back. A replacement arrived with a newer ROM which supported the DISCiPLE/+D but lost the hypertape support. So I found the various versions and instructions and looked at the drives they supported...
Multiface ROM Collection Project
An interesting chronological record of support for various devices... There was a huge range of third party storage devices available in the early days and the ones listed here seem to be the most popular of them.
I don't support the Opus Discovery, Wafadrive or Kempston Disk or the older Betadisk it seems to use (the $3C00 entry point version). So, I thought I'd have a quick go at this, although it's far from perfect:
Wafa
There is a grand total of... one wafadrive cartridge that has been dumped. There's the directory of it up there! I don't think it's a perfect dump, the original would've been on a "16K" wafer, which would've loaded a bit quicker.
12/12/2010.
I have reintroduced the old beep interpolation, as certain games (using Wham Music Box-style routines) have high-pitched beeps in them. I've also rejigged all the tape loading/saving code so that I can add extra functionality to it (most of which hasn't been done yet). ZX80 "O" file loading/saving, ZX81 "P/81/T81" loading and ZX81 "P/T81" saving implemented, which is a bit pointless as the screen still rolls around like crazy. You can now also read a tape from 16-bit VOCs, 16-bit WAVs, (some) 24-bit WAVs and 32-bit WAVs. Although this is really pointless, just a side-effect of tidying up some routines.
05/07/2010.
OK, having a lack of time, I've decided to go for an "open alpha", so that anyone can try it out. Please note that this version is far from complete and is probably not much use for the inexperienced Spectrum emulatist. The ZIP contains both DOS and Windows versions, so you can have "fun" trying them out. The text file is probably the best way to find out what's new, but it does waffle on a bit.
X128 V0.95B Open Alpha (DOS & Windows)
18/03/2010.
The DOS version now supports PS/2 wheel mice for the emulation of the wheeled Kempston mouse! The CuteMouse driver is the only DOS driver capable of supporting the hardware required.
15/03/2010.
Did you know that sound output under Windows can go up to 192 Khz, 32 bit, stereo (or more if you have a surround sound setup)? Well, so can x128. All those soundchip emulation imperfections can now be heard in far too much detail, in a manner that would require a platinum ear to be able to hear the difference. WAV files can be output in those formats too, some of which can't be played on Windows Media Player and require something like GoldWave instead. The DOS version has been updated to support SB16 16-bit output and 16-bit VOC file output - you love it!
11/03/2010.
Finally managed to get my Win'98 machine working. X128 Windows runs from double clicking, but not from the command line (windowed or otherwise). It ran normal Spectrum stuff at just about the right side of 100% on the AMD K6-2 400, which is not terrible but could be a lot better.
28/02/2010.
A slight reduction in available features, as Quazar-produced hardware is off the agenda.
Denied
25/02/2010.
I dug out my old PCs to try the latest version on. The 486 had a flat BIOS battery but was able to run it at about 30%. The AMD K6-2 400 wouldn't boot up at all. I hope the reduction in speed is purely down to emulating too many soundchips at the same time. I'm not an expert with Windows message handlers, but I've finally made one that doesn't use up all the CPU time in a single core, with the benefit that my laptop fan no longer zooms up to top speed.
20/02/2010.
SAM TAP loading added (takes ages), probably not at the right speed, but the ROM tape loading routines are robust enough to handle it. Also, SID card emulation added to the SAM, no filters and slightly suspect white noise though. I've done a bit of ATM Turbo 2+, but it's not quite ready yet.
Finally, I've fixed up the SAM FDC enough so that Prince of Persia works now!
SAM tape loading
SAM Sidplayer
SAM Prince of Persia Title
SAM Prince of Persia
09/02/2010.
Peeep... ATM Turbo and LEC 528K. The ATM Turbo has a 640x200 mode with 8x1 attributes and a 320x200 mode with one colour per pixel using 16 colours from a palette of 64.
ATM Turbo Menu
ATM Turbo Prince of Persia Title
ATM Turbo Prince of Persia
ATM Turbo Personal Nightmare Demo
ATM Turbo Personal Nightmare Demo
ATM Turbo Personal Nightmare Demo
ATM Turbo Personal Nightmare Demo
LEC CP/M Loading
LEC CP/M
02/02/2010.
Peeep... A bit of SAM. The sound and disk controller still need improving.
SAM Manic Miner
25/01/2010.
ZX81 emulation is a nightmare! I've totally rewritten it, but it still rolls and wobbles all over the place. I've added the "correct" volumes for the AY chip (I think) as well as the YM version. As a bonus, Turbosound AY is now working. The YM2203 FM status register is faked so that demos that use it can be played without freezing (but without the lovely FM sound).
14/01/2010.
Microdrive support finally added (for IF1 ROM v1 only, though). AMX and AY mouse fixed. Kempston Slave and Atari mouse added. The Windows version does not have proper mouse support yet (not capturing the mouse input) but the buttons and mousewheel do register. Currah Microspeech, Cheetah Sweet Talker, Fuller Orator and DK'Tronics Speech Synthesiser support! My sample set will need to be tidied up a bit though. The hardware menu (F3) now goes to three pages. More flexible number of tracks allowed in TRD files, so Robocop 1024 works.
03/01/2010.
Peeep... A tiny snippet of the Pentagon 1024SL supported - a 256x192 mode with one colour per pixel using the fixed 16 (15 unique) colour palette.
Pang 16C
Pang 16C
Borntro 2008 16C
Ball Quest 16C
Ball Quest 16C
24/12/2009.
Peeep. ULA+ site.
Sgt Helmet ULA+
Sgt Helmet ULA+
C64 converted piccy ULA+
26/07/2007.
A little bit of news! X128 V0.5 has been ported to the Atari Falcon by Peter Persson! It was shown for the first time at the Nordic Atari Show. It's a bit slow and needs a fast machine, but future versions should have much faster screen rendering.
("Follow the link" to get to the NAS2007 downloads).
Generally, I have been too busy with work to do anything on my projects for several months now. :(
But I have upgraded my 486 to 66 Mhz and 28 MBs! I've also bought a network card for it, so that I can compile on a faster machine and copy it across easily - eBay is good for something. ;)
Some people have been wondering if a new version of X128 will be released. I do want to make a brand new version, I feel that an up-to-date DOS emulator would be very useful for old laptops, etc. Additionally, I do want to make the code more portable, so I want to finish off a Windows version and maybe a console version (still trying to get an N64 version of gcc up and running).
03/05/2004.
Not a great deal (time constraints). The DOS and Windows projects have been reorganised so that they share as much source as possible. This allows me to write something in one version and be able to compile it straight into the other one.
The Windows version now runs at full frame rate on a P400, although the DOS version has got a bit slower, due to adding support for Covox, Stereo Covox, Soundrive and Specdrum audio (and the more generic mixer code, that has to handle a variable number of channels and convert them down into whatever the output format is).
The DOS version is partially through an attempt to get it to output 16-bit sound (handy when you're mixing 11 channels), but it never quite works... I can get it to sound OK at half-speed or playing half-correct/half-random noise at full speed. Due to the way the new sound code works, I suppose I could actually try and use the proper volumes for the AY chip... maybe.
15/11/2003.
I just thought I'd say a few words about x128w. It now works (the ZX80 and ZX81 aren't running very well, but they're not running very well in the DOS version either) and with sound! It needs to be a bit faster, as it needs frame 1/2 on a P400. "In-game" the keys are all working fine, but the front end key handling needs more work done to it. I also need to add some fiddly little FE screens that handle some control and video options in a way that I think Windows applications should handle them. (Although I tend to download DOS versions of software, so maybe other emulators have these things implemented already!)
Tests show that it runs under Win'98, but not XP! I don't know why.
30/06/2003.
I guess I couldn't put it off any longer... The tidying up of the code finally reached a stage where I could start work on the Windows version. It's at the early stages, less than two weeks old.
Not very exciting, but what did you expect?
It looks mostly like the DOS version, but can (optionally) run in a Window. All bit-depths are handled, except for 8-bit palletised on the desktop (which I'll try to fix).
Keyboard input works (needs a bit of debounce to stop the menus from affecting the game), but not joystick or mouse.
Parameters passed in don't work yet. Sound isn't being played, but is still being generated.
28/01/2003.
It's been a long time since I updated this page...
Anyway, I've added ye-olde VGA text mode (nicked from Z80), which should hopefully allow older machines to get a better frame rate. I tried it on my old 486SX-25 and it did indeed allow me to run at a higher, more playable, frame rate.
The other thing I've done is added support for banked VESA 1.1 modes (yes, I really am going backwards through time). I'd implemented it so that VESA 1.2 drivers would be supported, only to find that my old 486SX-25 only had a VESA 1.1 driver... A bit of modification and (really) slow compiling later, and it was astounding to see that old machine run 640x400, 640x480, 800x600 and 1024x768 resolutions, providing all the usual options that anyone who likes to have fun with shift-F11 will know about. Not very quickly (obviously), but not too bad. Just imagine what it'd be like if I stuck a 486DX2-66 Overdrive chip in it!
One snag is that X128 clearly uses up too much memory. It used to be happy in 640K (many versions ago) but now it looks like it needs roughly 4 or 5 free megabytes of RAM. I must try and reduce it, preferably to run on a 4MB machine (with or without a clean boot).
Oh, one other thing I'm doing is adding ZX81 tape support via VOC files. I've never actually owned a ZX81 (or a decent technical document), so it's not as easy as I thought it would be. There are some beneficial side effects....
Nice, but attempting to load VOCs in ZX81 mode, just shows up the weaknesses of my ZX81 emulation, for the moment.
29/08/2001.
02/03/2000.
21/02/2000.
I didn't think I'd do it, but I did! I changed it to deal with all disk images (internally) as if they were FDIs. This lets FDI, FDD and funny sized TRD files (80T SS, 40T SS, 40T DS) be used as well as the old TRD (80T DS). Although 40 track disks only work if you type "40" into the TR-DOS prompt. TR-DOS thinks that a 40 track disk is in an 80 track drive and automatically compensates by accessing TRACK*2 (which is not what I want in this case)...
I then went a step further, so now SCL and $? (Hobeta) files can be loaded by the automatic creation of a temporary TRD file in the background! So, 5 formats in all, I had to change my file selector to accept more extensions (there is now no limit, I pass it the same double zero terminated string that the Windows load/save dialogue box uses). Until I hear otherwise, that's every "Russian" format catered for.
The WD1793 code can now be used in either x128 or Multi with only 2 lines being changed (one of these is because of x128's old Z80 core and the other is because of a minor incompatibility issue with the Didaktik). When opening a disk, the addresses of get_track and get_data routines are passed to the function, this is what allows most of the portability and the ability to handle any uncompressed format thrown at it (including the MSX's DSK). The drive select/side select/motor/etc bits are made more generic by a cheapo method which really will have to be improved.
General emulation quality of the WD1793 has also been improved slightly, but not enough to get the Refresh demo working or to get round the protection system which is called "ARS PROTECTION" (ahem) in AnyTank (also used, in one form or another, in other demos/mags). Whether the FDI support is really working to it's full capacity is unknown. I don't do anything with the CRC bits and the only two FDI files that I managed to find were quite happy to work after they'd been converted to TRD files. I haven't managed to find any IS-DOS disks yet. "ADS 2.0p" now thinks that disks have 81 tracks instead of an infinite number, so: better, but not perfect.
And I probably shouldn't be calling it the WD1793. WD2793 might be a better name for it.
I have a limited amount of information on this, I know the ports that it uses and I know that it uses the same FDC as the Betadisk interface. I also know it's memory layout and I think I've finally figured out where I should be putting my patches so that it pages in. Unfortunately, all I get is "X Bad Device" error when I try to load a sector. The sector does load, it's just that some flags somewhere make it generate an error in BASIC. I do get the correct "Retry" and "Write Protect" messages when I leave the disk (image) out or write protect it when I attempt to write to it. Mind you, I don't have a D40/D80 disk to insert, so I just use a TR-DOS formatted disk... I have some documents on the disk format and the commands, so I could (...) generate a disk.
It takes ages to load one sector because the interface has the DRQ line attached to the NMI line and my Z80 core only allows NMIs every so often! A good excuse to rewrite the Z80 core... (Hmm, that "rewrite" word again...)
I've found some games in .000 format, but I don't know much about that either. It looks just like the output you'd get by saving to tape, but with an extra byte at the start.
Unfortunately this screenshot doesn't do anything to make this webpage look any less black and white.
31/01/2000.
Partial emulation - working well in slow mode, dodgy in hi-res games and rolling wildly in fast mode. The grey border is left behind from the file selector (which is still using the Spectrum screen). Some games lock up the emulator...
Good!
Ah....
Oh dear...
This is not very useful, it allows you to play Arcadia (which only supports Fuller joystick (and keys)) and you can play Matchday or International Matchday with any joystick! I'll add a "redefine keys" joystick later, except that I'll allow more than one fire button (Gryzor here we come). I'm also wondering whether "DK Australian" is a tongue-in-cheek name....
All this won't fit into an old-style .Z80 snapshot, so..... a new snap format may be required.
Considering (in a really hypothetical way...):
Requested Items:
(C) Jane McKay, 2024
