• Please review our updated Terms and Rules here

QX-10 Software archive

Altomare

Member
Joined
Feb 14, 2022
Messages
38
Location
France
In 2022, I obtained a few boxes of QX-10 disks from Emmanuel Roche's estate.
He was big QX-10 user and had a lot of software and hardware.

I dumped 70 disks and uploaded them here: Google Drive
I started uploading them to archive.org too but due to server issues I'll resume that later.
Edit: It's up on archive.org too

I don't have the time to look into each one, but there's a printed listing I scanned. I added some notes about faulty discs in the readme file.
Looks like there's mostly CP/M Plus (from MML) system and utilities, as well as sources for both QX-10 and QX-16. Saw some disassemblers in there as well.

If anyone is willing to check and sort through it, that would be greatly appreciated. I can help with file extraction and image manipulation if needed.
 
Last edited:
That's great. I have a real QX-10. How do I get .hfe back on real floppies with DOS or Windows machine ?
Is there a convert utility back to .img ?

Larry G
 
This is pretty cool, I've been dumping some of my collection of QX-10 disks as well, but this set seems to have a whole lot of source code on them which will be interesting to look through. I'll have to check them out when i have some time.
That's great. I have a real QX-10. How do I get .hfe back on real floppies with DOS or Windows machine ?
Is there a convert utility back to .img ?

Larry G
I actually use the greaseweazle utilities for converting between images formats its supports hfe images fine and convert to and from a variety of formats including a raw sector image or imd. I wrote a few diskdefs for it to support the QX-10 systems.

These are the ones i use and work for most disks i've seen and you can convert using gw convert --format=<name> <input file> <output file>
Code:
disk epson.qx10.399                                                                                                                                                                  
    cyls = 40
    heads = 2
    tracks 0.0 ibm.mfm
        secs = 16
        bps = 256
        rate = 250
    end
    tracks * ibm.mfm
        secs = 10
        bps = 512
        rate = 250
    end
end

disk epson.qx10.396
    cyls = 40
    heads = 2
    tracks 0-1 ibm.mfm
        secs = 16
        bps = 256
        rate = 250
    end
    tracks * ibm.mfm
        secs = 10
        bps = 512
        rate = 250
    end
end

disk epson.qx10.320
    cyls = 40
    heads = 2
    tracks * ibm.mfm
        secs = 16
        bps = 256
        rate = 250
    end
end
 
Most of the disks here use a format specifically made for CP/M Plus, so you'll need a new diskdef: 5 sectors per track, 1024 bytes per sector.

It's mentioned here: https://electrickery.hosting.philpem.me.uk/comp/qx10/detail.html

Edit here because I can't edit the first post. I messed up the archive.org link, here is the proper one:
https://archive.org/details/emmanuel_roche_qx10_archives
I've only done some looking at the first several images (which seem use the 16x256 sector layout), but disk 02 has incorrectly numbered tracks (20-39) on side 1. Those 19 tracks seem to be a duplicate of tracks 13-32. Not sure if that was an issue with dumping or if the disk itself is damaged in some way.
 
Oh boy now I have a bunch of research to do. I communicated privately with Mr Roche for years and I knew he had a QX-10 as I did decades ago.
We suddenly lost touch then I heard the sad news about his death. Thanks for all the dumps. I dumped what I had on Frank Kraan's site maybe 10 years ago.
My goal will be to get these back on floppies. I have complete floppy imaging setups for everything. I have a couple gotek's as well and had one running on my QX-10 until I got
the drives fixed. I'm not up to speed on modern techniques and probably won't be. Real hardware has always been my thing. Let's keep this thread going
as discoveries are made concerning his archive.

Larry G
 
Those 19 tracks seem to be a duplicate of tracks 13-32. Not sure if that was an issue with dumping or if the disk itself is damaged in some way.
I think I know the issue. I used a Shugart SA-450 and a Greaseweazle, and it was not configured properly for the slow step timing of the drive. So when I tried to re-read tracks 20 onward, it tried to do seeks from 0 to 20 but ended up at 13.

This issue should only affect disks in the first 11. I re-dumped #2, let me know if you need me to do other disks
 

Attachments

Altomare,
In comparing /02/over1.img to /redump/over1.img the over1.src file is not sane.
Photo attached.

Looks as if you need to redump the first 11 .hfe files so the .SRC files are valid.


CP/M Definitions
Code:
# EPS2  Epson QX-10 - DSDD 48 tpi 5.25" - 256 x 16
diskdef eps2
  seclen 256
  tracks 80
  sectrk 16
  blocksize 2048
  maxdir 64
  skew 1
  boottrk 8
  os 2.2
end

# libdsk
[eps2]
description = EPS2  Epson QX-10 - DSDD 48 tpi 5.25" - 256 x 16
sides = alt
cylinders = 80
heads = 2
secsize = 256
sectors = 16
secbase = 1
datarate = DD

#Flashfloppy/GOTEK
[esp2]
cyls = 80
heads = 2
secs = 16
interleave = 1
bps = 256
id = 1
#rpm = 360
rpm = 300
rate = 250
mode = mfm
iam = no



Code:
$ cpmls -f eps2 -D 02_qss_kernel.img
     Name    Bytes   Recs  Attr     update             create
------------ ------ ------ ---- -----------------  -----------------
GENREL  .COM    16K    123    
GRAFFOR .REL     2K      4    
GRAFPAS .REL     2K     15    
GRAFPLI .REL     2K      4    
IKRNPAS .SRC     8K     51    
IKRNPLI .PLI     4K     30    
KERNEXP .$$$     0K      0    
KERNEXP .FOR    14K    104    
KERNEXP .PLI    16K    116    
KERNEXP .SRC     8K     54    
KERNLIB .REL    78K    616    
KERNLIBE.REL    86K    678    
LIB     .COM     8K     56    
LINK    .COM    16K    123    
OVER1   .SRC     4K     29    
OVER2   .SRC     6K     38    
OVER3   .SRC     4K     31    
OVER4   .SRC     6K     36    
   18 Files occupying    280K,      38K Free.





Larry
 

Attachments

  • Compare_over1_src.png
    Compare_over1_src.png
    153.2 KB · Views: 10
Last edited:
Alright, I re-dumped part of the first box (1->11). This box was sitting on top and was very moldy so each floppy took a lot of cleaning.
The Shugart drive was a big help for it as it's the only one I have with a very rounded head, which reduces scraping risk.

Some were not fully salvageable:
  • 07: one unreadable sector (corrupted header?).
  • 09: is missing due to a lot of errors. I'll try again later
I'll add those files to the big archives tonight, unless you find issues with them
 

Attachments

Alright, I re-dumped part of the first box (1->11). This box was sitting on top and was very moldy so each floppy took a lot of cleaning.
The Shugart drive was a big help for it as it's the only one I have with a very rounded head, which reduces scraping risk.

Some were not fully salvageable:
  • 07: one unreadable sector (corrupted header?).
  • 09: is missing due to a lot of errors. I'll try again later
I'll add those files to the big archives tonight, unless you find issues with them
Disk 02 seems to work fine with this redump.

I did notice that the redump shows a bad sector on disk 11, where there were previously no bad sectors. The difference seems to be two bits a value of 0x6f in the original is now a value of 0x0f in the redump. You should probably just leave disk 11 as is since the original seems fine. The other disks seem to convert fine with no bad sectors other then disk 7 which you mentioned in your notes.
 
I use SAMDISK for the *.hfe to *.raw & *.imd conversions in Dbian Linux.

libdsk can also do the conversions, if cpmtools is built with libdsk.


Code:
wine samdisk 07_redump_missing_1_sector.hfe 07_redump_missing_1_sector.raw
wine samdisk 06_redump.hfe 06_redump.raw
wine samdisk 05_redump.hfe 05_redump.raw
wine samdisk 04_redump.hfe 04_redump.raw
wine samdisk 03_redump.hfe 03_redump.raw
wine samdisk 02_redump.hfe 02_redump.raw
wine samdisk 01_redump.hfe 01_redump.raw


Code:
wine samdisk 07_redump_missing_1_sector.hfe 07_redump_missing_1_sector.imd
wine samdisk 06_redump.hfe 06_redump.imd
wine samdisk 05_redump.hfe 05_redump.imd
wine samdisk 04_redump.hfe 04_redump.imd
wine samdisk 03_redump.hfe 03_redump.imd
wine samdisk 02_redump.hfe 02_redump.imd
wine samdisk 01_redump.hfe 01_redump.imd


cpmtools Definitions:
Code:
# EPS1  Epson QX-10 - DSDD 48 tpi 5.25" - 512 x 10
diskdef eps1
  seclen 512
  tracks 80
  sectrk 10
  blocksize 2048
  maxdir 128
  skew 1
  offset 16384
  boottrk 0
#  boottrk 4
  os 2.2
end

# libdsk
[eps1]
description = EPS1  Epson QX-10 - DSDD 48 tpi 5.25" - 512 x 10
sides = alt
cylinders = 80
heads = 2
secsize = 512
sectors = 10
secbase = 1
datarate = DD

#Flashfloppy/GOTEK
[esp1]
cyls = 80
heads = 2
secs = 10
interleave = 1
bps = 512
id = 1
#rpm = 360
rpm = 300
rate = 250
mode = mfm
iam = no


# EPS2  Epson QX-10 - DSDD 48 tpi 5.25" - 256 x 16
diskdef eps2
  seclen 256
  tracks 80
  sectrk 16
  blocksize 2048
  maxdir 64
  skew 1
  offset 32768
  boottrk 0
#  boottrk 8
  os 2.2
end

# libdsk
[eps2]
description = EPS2  Epson QX-10 - DSDD 48 tpi 5.25" - 256 x 16
sides = alt
cylinders = 80
heads = 2
secsize = 256
sectors = 16
secbase = 1
datarate = DD

#Flashfloppy/GOTEK
[esp2]
cyls = 80
heads = 2
secs = 16
interleave = 1
bps = 256
id = 1
#rpm = 360
rpm = 300
rate = 250
mode = mfm
iam = no


# EPS3  Epson PX-10/8 - DSDD 3.5" - 512 x 8
diskdef eps3
  seclen 512
  tracks 80
  sectrk 8
  blocksize 2048
  maxdir 64
  skew 1
  offset 32768
  boottrk 0
#  boottrk 8
  os 2.2
end

# libdsk
[eps3]
description = EPS3  Epson PX-10/8 - DSDD 3.5" - 512 x 8
sides = alt
cylinders = 80
heads = 2
secsize = 512
sectors = 8
secbase = 1
datarate = DD

#Flashfloppy/GOTEK
[esp3]
cyls = 80
heads = 2
secs = 8
interleave = 1
bps = 512
id = 1
#rpm = 360
rpm = 300
rate = 250
mode = mfm
iam = no


Larry
 
Well damn that was too easy. I use samdisk all the time. I had no clue it supported .hfe . We should give Simon Owen some kind of award.


hfe.JPG
 
Last edited:
Making progress. I had to use samdisk to convert .raw to .imd then imagedsk to write to floppy then can read on my qx-10. Here is some cpm+ cbios source code from disk 03

roche.JPG
 
Thank you for these disk images!

Monsieur Roche was a well-known CP/M expert and sometimes a hard opponent in discussions.
Some years ago, when I was playing with the GXS system, I was very interested in the GSS-Plot and GSS-Kernel disks, but he could not make a disk image.

Now, with your images, I enthusiastically started with the first dump of the two disks (01 and 02) and had big difficulties decoding them.
I spent a whole day examining the image files and trying to make sens of them. I found some systematically intermixed extents so that I finally changed the directory entries.
This allowed me to scrape most of the text files from the disks. but the binaries were not correct and a part of one text files was nowhere to be found.

Close to giving up, I revisited this thread and found the re-dumped new images.
And these were perfectly usable without tinkering!

Now I was able to have a closer look at the files and I tried to rebuild one of the demonstration programs written in PL/I.
Lacking a PL/I manual, I experimented with compilers and linkers and finally found a combination which worked.
Initially, I used PL/I Version 1.0 and LINK 1.0 which were able to translate and link the files, but the resulting .COM file crashed.

A second experiment with PL/I 1.4 and LINK 1.3A gave more satisfying results.

Obviously PL/I 1.4 and the associated LINK 1.3A are useable for producing working programs.

Linking gives some warnings about three multiple defined references, but these seem to be harmless:

MULTIPLE DEFINITION: X$EB4
MULTIPLE DEFINITION: X$NB
MULTIPLE DEFINITION: X$NU

Additionally, three unsatisfied externals are listed, but they seem to be unused so that the executable works.

UNDEFINED SYMBOLS:

KCSTOT KCSTIN KCHRIN

I guess, that these names may be related to I/O
KCSTOT STandared OuTput
KCSTIN STandard INput
KCHRIN CHaracter INput

In order to resolve these externals, I created three dummy PL/I modules D1, D2 and, D3.
(I do not know how to implement three public functions in a single PL/I module, so I created three).

File D1.PLI:
KCSTOT:
procedure returns (fixed);
return (0);
end KCSTOT;

File D2.PLI:
KCSTIN:
procedure returns (fixed);
return (0);
end KCSTIN;

File D3.PLI:
KCHRIN:
procedure returns (fixed);
return (0);
end KCHRIN;

Additional files required:
GENGRAF.COM
GSX.SYS
ASSIGN.SYS
+ at least one DD...REL driver, also entered into ASSIGN.SYS

also useful:
PIP.COM
STAT.COM
+ a text editor, e.g. TURBO.COM


The whole process is then:

1) ===== compiling =====
A>PLI PLOTEXP
--------------------------------------------------
PL/I-80 Compiler Version 1.4
Serial No. 3032-0000-001130 All Rights Reserved
Copyright (c) 1980-1982 Digital Research, Inc.
--------------------------------------------------
COMPILATION OF: PLOTEXP
%include 'IPLTPLI.PLI';
NO ERROR(S) IN PASS 1
NO ERROR(S) IN PASS 2
CODE SIZE = 00A0
DATA AREA = 0392
FREE SYMS = 2C55
END COMPILATION

Notes:
PLI produces a file PLOTEXP.REL of 2KB.
The three dummy modules D1 to D3 are also compiled into .REL files.

2) ===== linking =====
A>LINK PLOTEXP,GRAFPLI,PLOTLIB,D1,D2,D3[A]
LINK 1.3A
MULTIPLE DEFINITION: X$EB4
MULTIPLE DEFINITION: X$NB
MULTIPLE DEFINITION: X$NU

PLILIB RQST EXAMPL 0100 GPINI 0209 XRANGE 02AB
... long list of references ...
X$$TTIN C52B X$$TTOT C52E X$TTIN A268 X$TTOT A288
X$AD C537 X$J6 C57E X$SK C592

ABSOLUTE 0000
CODE SIZE A938 (0100-AA37)
DATA SIZE 1951 (AD53-C6A3)
COMMON SIZE 031B (AA38-AD52)
USE FACTOR 54

Notes:
GRAFPLI.REL is a thin, language dependent interface layer, similar mobject modules exist for Fortran and Pascal.
The option [A] is required to avoid memory overflow.)
LINK produces a file PLOTEXP.COM of 50 KB.

3) ===== combining with the GSX system file =====
A>GENGRAF PLOTEXP
---------------------------------------------------
GENGRAF 1.0 15 Nov 82 Serial No 5000-0000-000292
Copyright (C) 1982
Digital Research, Inc. All Rights Reserved
---------------------------------------------------

Notes:
GENGRAF requires the file GSX.SYS.
It produces a new file PLOTEXP.COM of 52 KB.


4) ===== executing the final .COM file =====
A>PLOTEXP
---------------------------------------------------
GSX-80 1.0 15 Nov 82 Serial No 5000-0000-000292
Copyright (C) 1982
Digital Research, Inc. All Rights Reserved
---------------------------------------------------
HP 2648A Driver Version 1.0
Copyright (C) 2020 by Martin Hepperle
---------------------------------------------------

... output of graphics terminal escape sequences ...

A>

Notes:
In my ASSIGN.SYS file I have an 8KB driver for a HP 2648A terminal.
The final .COM file is quite large. For a 64 kB CP/M 2.2 the demonstration porgram is already close to the limit.
Applying the same procedure to the GSS-Kernel example program produces a .COM file which is too large to be executed on my CP/M 2.2 simulator.
So I guess that the GKS system was an interesting technology demonstration, but the application of GSS-Plot and GSS-Kernel was rather limited due to these problems.


I still have two questions:
What is the purpose of GENREL.COM which is included with GSS-Plot and GSS-Kernel?
What happens if the GSS suite is compiled and run on a CP/M 3 system? Is memory still as tight as on 2.2?

Martin
 
O.K., with the help of the PL/I manual I found out how to export all 3 dummy procedure entries from a single PL/I module, thus replacing D1.PLI, D2.PLI, D3.PLI by a single DUMMY.PLI. The keyword "external" was the key.

File DUMMY.PLI:
Code:
DUMMY:
procedure;

  KCSTOT:
    procedure external returns (fixed);
    return (0);
  end KCSTOT;

  KCSTIN:
    procedure external returns (fixed);
    return (0);
  end KCSTIN;

  KCHRIN:
    procedure external returns (fixed);
    return (0);
  end KCHRIN;
 
end DUMMY;
 
Another update: the dummy files are not required - I did not use the correct LINK options.

The correct command line should be

Code:
A>LINK PLOTEXP[A],GRAFPLI,PLOTLIB[S]

[ A ] is required to minimize memory usage during linking,
[ S ] is essential to tell LINK that plotlib.rel is not an object module to be copied but a library so that only the referenced modules are extracted and linked. This reduces executable size and resolves the three previously unsatisfied references.

This should also bring GSS-Kernel application programs into a practical size.

Martin[/S]
 
Back
Top