• Please review our updated Terms and Rules here

How to mount a GOTEK emulator into an Amstrad PCW9512

I agree, remove the floppy first and make sure its addressed as drive A

Then try to boot 9512 CPM (attached). There is also a FF.CFG file that I use.
 

Attachments

  • USB gotek.zip
    448.6 KB · Views: 27
I updated to 3.35 because older versions doesn't seem to work. I use it replacing the floppy drive, so I just have one drive as A: (the Gotek). After upgrading the flasfloppy, I copied some DSK image files (CP/M, Locoscript, some games, etc.) but the lines doesn't appear on the screen, just a beep from the PCW. I have the new board an the jumper is set to S0.
 
Gary, I've loaded your files in the USB and works the CP/M for 9512. So I'm not sure why I can't load other DSK images. They works in the PCW emulator, but not in the USB. Thank you for you ff.cfg, reading it carefully I detected some errors in mine.
 
So I take it the led on the gotek flashes to indicate its being accessed but after that nothing ?

Have you tried my files ?
 
Gary, that's it. Led flashes, but then the computer beeps. Your files worked fine. Maybe my DSK are bad?
I tried images made by me from my original 3" disks, and doesnt work, but in the emulator does. Also tried with some free games, uploaded by their programmers, and the same. Not success. Could you try my DSK file to verify if is OK?
 

Attachments

  • abadia-1_2.zip
    233 KB · Views: 9
Some news here!
I've been able to run programs running CP/M, but not the bootable DSK. Any idea why?
 
It doesn't look like a normal boot disk to me, though it is technically a "Bootable" image and is marked with the PCW9512 boot code.

Here's what I found on your image.

?>mount "Abadia 9512.dsk" a:\
Mounting Abadia 9512.dsk as a:\

?>a:
Opening A: as default drive

A>dir

ABADIA .EMS 11904 Bytes
A .BIN 16384 Bytes
B .BIN 16384 Bytes
C .BIN 16384 Bytes
F .BIN 16384 Bytes
G .BIN 16384 Bytes
H .BIN 16384 Bytes
I .BIN 16384 Bytes
J .BIN 16384 Bytes
K .BIN 16384 Bytes
L .BIN 16384 Bytes
11 Files on disk image
Disk capacity: 177152 bytes
2048 bytes free in 2 allocations.

A>stat
Disk Information on current image.

Disk Image Information:
Title:EXTENDED CPC DSK File
Disk-Info

Creator:CP/M Box -Habi
Tracks: 40
Sides: 1
Track Length: 0
Unused:‼§‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼‼
Track Data Length: 4608
---------------------------
Total Number of tracks on disk: 40
---------------------------
Reading Track 0
Track Title:
Track Number: 0
Side Number: 0
Sectorsize: 0
Number of Sectors on track: 0
GAP3: 0
Data bytes per Track: 0

---------------------------
Reading Disk Sector 0, Track 0, Disk Identifier
XDPB AMSTRAD/ZX+3 DISK. Extended Disk Parameter Block contents;

! ! ! ! ! ! ! !
0000 - 00 00 28 09 02 01 03 02 2A 52 00 00 00 00 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - ++(+++++*R+++++"++++++++++++++++

Boot Sector Checksum:1
01=PCW9xxx, 03=ZXSpectrum+3, FF=PCW8xxx

I think this disk Is:
DiskType: 0
Sides: 1 (Byte1=0=1 side, Byte 1=1=2 sides)
Tracks: 40
AMSectors: 9
AMSectSize: 2
Actual Sector Size: 512
AMReserved: 1
AMBlockSize: 3
Actual Allocation Size: 1024
AMDIrectory: 2
AMGap: 42
AMGap2: 82
AMChecksum: 0

Allocations: 175
Last Allocation: 0AF
Directory Allocations: 2
Disk Data 'Formatted' Capacity: 177152 bytes
Free Space: 2048 bytes
Available Directory Extents: 53
Bytes per allocation pointer: 1

A>



So there are no files per-se.... Just a lot of "Bin" files, but nothing I'd associate with a typicaly 9512 boot disk... What shows up when you boot on the emulator? Also, it's a 180K boot disk, which does not fit with the 9512. ( A 9512 can boot from a 180K disk, but that's not what it's CPM disks were. ). In fact, I can even modify a 8512K disk to boot a 9512, so there's more to it than just that.

The files on the supplied image from Gary however look like this;

RAMTEST .COM 10101 Bytes
ASSIGN .SYS 128 Bytes
BASIC .COM 28345 Bytes
CPMKEYS .COM 1024 Bytes
DAISY .COM 3200 Bytes
DATE .COM 2944 Bytes
DDFXHR8 .PRL 15104 Bytes
DDFXLR8 .PRL 12288 Bytes
DDHP7470.PRL 11008 Bytes
DDSCREEN.PRL 5120 Bytes
DEMO .BAS 1408 Bytes
DEVICE .COM 7424 Bytes
DIR .COM 14592 Bytes
DISCKIT .COM 9472 Bytes
DUMP .COM 1024 Bytes
ED .COM 9344 Bytes
ERASE .COM 3712 Bytes
EX1 .BAS 1664 Bytes
EX2 .BAS 2944 Bytes
EX3 .BAS 4352 Bytes
EXGSX .BAS 1664 Bytes
EXJTSAM .BAS 2048 Bytes
EXJTSAM2.BAS 3584 Bytes
EXJTSAMI.BAS 128 Bytes
GENCOM .COM 14848 Bytes
GENGRAF .COM 1536 Bytes
GET .COM 6528 Bytes
GSX .SYS 1408 Bytes
GSXPREP .BAS 256 Bytes
HELP .HLP 96896 Bytes
HELP .COM 7168 Bytes
HEXCOM .COM 1152 Bytes
HIST .UTL 1280 Bytes
INITDIR .COM 32000 Bytes
KEYS .DRL 896 Bytes
KEYS .WP 896 Bytes
LANGUAGE.COM 1024 Bytes
LIB .COM 7168 Bytes
LINK .COM 15744 Bytes
LOGO .COM 50432 Bytes
LOGO .SUB 128 Bytes
MAC .COM 11776 Bytes
MAIL232 .COM 4096 Bytes
MATRIX .COM 2176 Bytes
PALETTE .COM 1024 Bytes
PAPER .COM 2176 Bytes
PATCH .COM 2560 Bytes
PIP .COM 8704 Bytes
PROFILE .SUB 128 Bytes
PUT .COM 7040 Bytes
RENAME .COM 2944 Bytes
RMAC .COM 13568 Bytes
RPED .BAS 7040 Bytes
RPED .SUB 128 Bytes
SAVE .COM 1792 Bytes
SET .COM 10368 Bytes
SET24X80.COM 1024 Bytes
SETDEF .COM 4096 Bytes
SETKEYS .COM 2048 Bytes
SETLST .COM 2048 Bytes
SETSIO .COM 2048 Bytes
SHOW .COM 8448 Bytes
SID .COM 8064 Bytes
SUBMIT .COM 5376 Bytes
TIMEOUT .COM 2048 Bytes
TRACE .UTL 1280 Bytes
TYPE .COM 3072 Bytes
XREF .COM 15488 Bytes
A35 .FIB 384 Bytes
J25CPM3 .EMT 43392 Bytes
8000COPY.COM 8064 Bytes
DISABLE .XXX 512 Bytes
B180 .XXX 384 Bytes
B35 .XXX 384 Bytes
DISABLEB.FIB 384 Bytes


Interestly, Gary's disk appears corrupt ( But readable and bootable ) to me.. It's a 720K disk, so four times the size of your boot disk - and it contains 2K allocations ( 165 allocations in total ) but seems to reserve 4 allocations for director, which makes the first data allocation on logical sector 25.

But that's not where I'm seeing data, so I'm not sure if there's something strange about the 720K image, or (more likely) my CPM editing software has a bug with logical sector and allocation mapping, because the directory seems correct.

Thanks Gary - It's always good to find an image my software doesn't work with.

BTW, I did make my software open and free. It's useful for changing the boot code from 8512 to 9512 to make many 8512 games and software run on the 9512 and to copy disk images to and from the CPC. I posted up the source code on the CPC forums. If there's an interest, I can post it here too. It's written in FreeBasic

David
 
OK, I learnt something from that disk image - it changes the format interleave mid-disk.. So the directory allocations have two different interleave structures entirely.... Not something my software expected.

Looks like I have to update my logical sector translation routines to read the TIB sector interleave data for every track, not just once at the beginning.

David
 
OK, this is interesting Gary, that file you provided David as a system disk has the following interleave...

The below is the order in which the logical sectors are laid down on each track ( ie, the order in which the sectors are played back once the track is accessed ).

?>interleave
Track: 1 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 2 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 3 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 4 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 5 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 6 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 7 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 8 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 9 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 10 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 11 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 12 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 13 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 14 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 15 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 16 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 17 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 18 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 19 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 20 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 21 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 22 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 23 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 24 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 25 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 26 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 27 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 28 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 29 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 30 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 31 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 32 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 33 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 34 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 35 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 36 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 37 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 38 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 39 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 40 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 41 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 42 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 43 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 44 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 45 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 46 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 47 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 48 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 49 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 50 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 51 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 52 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 53 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 54 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 55 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 56 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 57 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 58 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 59 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 60 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 61 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 62 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 63 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 64 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 65 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 66 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 67 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 68 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 69 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 70 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 71 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 72 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 73 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 74 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 75 4: 6: 8: 1: 3: 5: 7: 9: 2:
Track: 76 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 77 7: 9: 2: 4: 6: 8: 1: 3: 5:
Track: 78 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 79 1: 3: 5: 7: 9: 2: 4: 6: 8:
Track: 80 4: 6: 8: 1: 3: 5: 7: 9: 2:

Do you have any idea what it looks like this? Is it a copy of a real disk? I'm wondering if its like that so it can pick up the first sector more rapidly after changing track?

I don't think the Gotek simulates the track change time, so if that's the case, that disk image is optimized for physical disks and would be inefficient on a Gotek image?

Thanks
David.
 
If anyone wants the crappy editing program I wrote to handle Amstrad style CP/M disks on a PC, you can download the source here:


There's a binary there, but please only use the BAS file if possible. I don't virus scan the binaries.

It's pretty poorly written but lets you see what's in a DSK file, edit the checksums, copy files between images and between the host PC and the DSK images. It actually has a lot of functions including being able to format blank DSK files ( that haven't been tested with an emulator, but a real PCW seems to read them OK last I checked, assuming I didn't mangle the code. ).

It's command-line driven, though has it's own CLI ( I'll add something to make it work direct from the CMD CLI later ). Once you run it, you can type in commands - a mix between DOS and CP/M... And Question Mark brings up a help menu.

It's designed to use the full PC text area - so open a CMD Window, expand it to full size and then run the executable.

It can dump sections of the disk, show allocations or sectors, change boot sector information, move files, delete files, format DSK images, and show file information.

Apologies for it being a bit crap, but it mostly works, and I can't think of any other simple program that lets you get most 8256 bootable games running on a 9512...

David
 
Try with this image file. Maybe is better than the first one.
 

Attachments

  • Abadia_9512.zip
    65.1 KB · Views: 8
That image is smaller and might be custom software, but isn't a normal CP/M boot disk.

E>dir
ABADIA .EMS 32401 Bytes
PG0 .BIN 0 Bytes
PG1 .BIN 0 Bytes
PG2 .BIN 0 Bytes
PG5 .BIN 0 Bytes
PG6 .BIN 0 Bytes
PG7 .BIN 0 Bytes
7 Files on disk image
Disk capacity: 177152 bytes
63488 bytes free in 62 allocations.

E>
E>dirhex
Disc Directory Allocations: 2

! ! ! ! ! ! ! !
0000 - 00 41 42 41 44 49 41 20 20 45 4D 53 00 11 00 FE 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 - +ABADIA EMS++++++++++++++++++++
0020 - 00 50 47 30 20 20 20 20 20 42 49 4E 00 00 00 00 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 - +PG0 BIN++++++++++++++++++ !
0040 - 00 50 47 31 20 20 20 20 20 42 49 4E 00 00 00 00 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 - +PG1 BIN++++"#$%&'()*+,-./01
0060 - 00 50 47 32 20 20 20 20 20 42 49 4E 00 00 00 00 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 - +PG2 BIN++++23456789:;<=>?@A
0080 - 00 50 47 35 20 20 20 20 20 42 49 4E 00 00 00 00 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 - +PG5 BIN++++BCDEFGHIJKLMNOPQ
00A0 - 00 50 47 36 20 20 20 20 20 42 49 4E 00 00 00 00 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 - +PG6 BIN++++RSTUVWXYZ[\]^_`a
00C0 - 00 50 47 37 20 20 20 20 20 42 49 4E 00 00 00 00 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 - +PG7 BIN++++bcdefghijklmnopq

If you are familiar with CP/M disks. those files are all showing "0" bytes, but in the directory structure, they have marked allocations. Looks like this image has found another bug in my software.... 0 = 128

In fact, the disk is quite full....
E>fat

Fat Tables:
00-01-02-03-04-05-06-07-08-09-0A-0B-0C-0D-0E-0F
0000-DR DR 01 01 01 01 01 01 01 01 01 01 01 01 01 01
0010-01 01 02 02 02 02 02 02 02 02 02 02 02 02 02 02
0020-02 02 03 03 03 03 03 03 03 03 03 03 03 03 03 03
0030-03 03 04 04 04 04 04 04 04 04 04 04 04 04 04 04
0040-04 04 05 05 05 05 05 05 05 05 05 05 05 05 05 05
0050-05 05 06 06 06 06 06 06 06 06 06 06 06 06 06 06
0060-06 06 07 07 07 07 07 07 07 07 07 07 07 07 07 07
0070-07 07 -- -- -- -- -- -- -- -- -- -- -- -- -- --
0080--- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0090--- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
00A0--- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
DR=Directory Allocation
01 ABADIA .EMS 32401 Bytes
02 PG0 .BIN 0 Bytes
03 PG1 .BIN 0 Bytes
04 PG2 .BIN 0 Bytes
05 PG5 .BIN 0 Bytes
06 PG6 .BIN 0 Bytes
07 PG7 .BIN 0 Bytes
63488 bytes free in 62 allocations.

The extents are marked as 0, but that should mean 128 so this should be 16384 bytes per file... Looks like I have more bugs to fix - Thanks for posting that image.

It is a 9512 boot disk though, as was the one before it, but the code isn't CP/M that I can see. CP/M seems to be missing from this disk also. Or it's some kind of custom CP/M.

Do you know what that disk is supposed to do? I assume it loads the BIN fines and they do something? Maybe from some kind of snapshot program?

David.
 
I'm guessig what's happening. My Gotek board is SFRKC30AT437. Maybe the new chip is doing something weird.
I can run CP/M provided by Gary, so I presume the Gotek is well installed and working. I can´t load any DSK file, doesn't matter if is bootable or not. When I try to change the disk in CP/M, after pressing A>LIST the computer sends disk error and I can´t read the image. If I return to the CP/M disk, it works again, and I can run Basic or Logo. Maybe my DSK files are bad? I don't think it, because yesterday I was able to load one of them (non bootable), but now I can't even read it. Those DSK files worked fine with emulator. Any idea what is happening? Can anyone give me a tested DSK image to test if my images are bad?
Thanks in advance for your patience.
 
I can't remember where I got it :(

But it works fine on my 9512. What is also interesting, if you do the initial boot with the 9512 CPM disk, then switch to a 8256 file after the lines I can run 8256 programs.

I will send you a zip of the programs.
 
Gary C, I was able to load almost all my CP/M software using your "swapping" method: changing disc after lines appear. But I still can't run autoboot images. Could be a problem with my Gotek board version? (SFRKC30AT437).
 

Attachments

  • 3.jpg
    3.jpg
    523.3 KB · Views: 3
  • 308331027_655884965775815_7767037660778129002_n.jpg
    308331027_655884965775815_7767037660778129002_n.jpg
    143.7 KB · Views: 3
Makes sense. If the autoboot is an 8256 then you will have to list the director and run the program directly.

Its been a while since I have powered up my 9512 so I need to have another play

sent you a PM with a link to amstrad software.
 
If you are familiar with CP/M disks. those files are all showing "0" bytes, but in the directory structure, they have marked allocations. Looks like this image has found another bug in my software.... 0 = 128
That's not a bug in your software -- that's out-of-spec values in the filesystem, leading to undefined behaviour. Even the CP/M 3 utilities disagree on how to handle the files: TYPE will try to display their contents, but DUMP will stop with "ERROR: No Records Exist". STAT under CP/M-86 reports "Recs 0 Bytes 16k".
 
That's not a bug in your software -- that's out-of-spec values in the filesystem, leading to undefined behaviour. Even the CP/M 3 utilities disagree on how to handle the files: TYPE will try to display their contents, but DUMP will stop with "ERROR: No Records Exist". STAT under CP/M-86 reports "Recs 0 Bytes 16k".

Thanks John, that makes a lot of sense. I've updated my software to handle the exception now both ways.

Did you know why the Interleave changes like it does with respect to the index in the map I posted earlier? Is it something to do with allowing for stepping between tracks when reading and writing?

Thanks
David
 
Back
Top