• Please review our updated Terms and Rules here

Amstrad PC1512 system Serial Port issue

Phil Saunders

Experienced Member
Joined
May 25, 2014
Messages
95
Location
Milton Keynes, United Kingdom
Hi,

Kind of hoping there is somebody out there wht has knowledge of these specific machines......

The 1512 has NVR that stores config information. One item concerns turning on and off Hardware Flow Control for the serial port. I have the machine set up to control a home-brew CNC machine using a serial cable, and the interface uses hardware flow control, and cant be re-engineered (easily).

Unfortunately, the Amstrad recently trashed the hard drive (30 year old Tandon TM-262). I've re-built it with a XT-CompactFlash IDE adapter, and the machine works fine - however - when I configure the machine for HW flow Control, for some strange reason I can't even begin to fathom, this seems to move all the drive letters after b: up by one spot. IE A: and B: are OK, but C: moves to D: and any RAM drives move up one spot also. This means that the machine then wont load any further device drivers or even run AUTOEXEC, as they all reference C:

Any attempt to access C: produces a 'General Failure' error message. Accesses to D: work fine, as it's what used to be C:

I have no idea how it ever worked - it's been working for years with no maintenance whatsoever, and of course I no longer have the hardware to retrieve the backup from QIC40 tape (I have the tape but not the drive).

If anyone knows how to get HW flow control to work and also successfully boot the machine, please let me know!
 
Serial information on the PC1512 is stored in NVR bytes 23h (bit 7 governs hardware flow control) and bytes 26h/27h (initial baud rates, parity, bit counts).

Does the XT-CF BIOS access the Amstrad non-volatile RAM (either by INT 15h/AH=2, or directly through I/O ports 70h/71h)?
 
Does the XT-CF BIOS access the Amstrad non-volatile RAM (either by INT 15h/AH=2, or directly through I/O ports 70h/71h)?
No, it does call INT 15h with AH=86h, 90h and 91h but only on the AT-builds (ide_at.bin, ide_atl.bin and ide_386.bin). And there are no accesses to ports 70h/71h either.

Try setting the BIOS to use "Full Mode" if it's not already.
 
Last edited:
Hi,

Thanks - I've looked at the technical ref. for the machine and discovered the same info - any idea why this bit being set should have any effect on the hard drive letters?

It's not just using the XT-IDE bios - just the standard HD BIOS on the WD-27X controller does the same. Even if there's no HD at all the re-mapping problem affects RAMdrves too.

Completely stumped :-/
 
Last edited:
Info from Ralph Brown's Interrupt List;

Code:
 Format of Amstrad NVRAM:
Offset	Size	Description	(Table 00405)
 00h	BYTE	time of day: seconds
 01h	BYTE	alarm time: seconds
 02h	BYTE	time of day: minutes
 03h	BYTE	alarm time: minutes
 04h	BYTE	time of day: hours
 05h	BYTE	alarm time: hours
 06h	BYTE	day of week, 1 = Sunday
 07h	BYTE	day of month
 08h	BYTE	month
 09h	BYTE	year mod 100
 0Ah	BYTE	RTC status register A (see #00406)
 0Bh	BYTE	RTC status register B (see #00407)
 0Ch	BYTE	RTC status register C (read-only) (see #00408)
 0Dh	BYTE	RTC status register D
		bit 7: battery good
 0Eh  6 BYTEs	time and date machine last used
 14h	BYTE	user RAM checksum
 15h	WORD	Enter key scancode/ASCII code
 17h	WORD	Forward delete key scancode/ASCII code
 19h	WORD	Joystick fire button 1 scancode/ASCII code
 1Bh	WORD	Joystick fire button 2 scancode/ASCII code
 1Dh	WORD	mouse button 1 scancode/ASCII code
 1Fh	WORD	mouse button 2 scancode/ASCII code
 21h	BYTE	mouse X scaling factor
 22h	BYTE	mouse Y scaling factor
 23h	BYTE	initial VDU mode and drive count
 24h	BYTE	initial VDU character attribute
 25h	BYTE	size of RAM disk in 2K blocks
 26h	BYTE	initial system UART setup byte
 27h	BYTE	initial external UART setup byte
 28h 24 BYTEs	available for user application
Note:	bytes 00h-0Dh are the same on the IBM AT as they are used/updated by
	  the clock chip
There is no mention of any serial port configuration data at NVR offset 23h but there is a "drive count". Could there be a mismatch between two different versions of BIOS and configuration software (i.e. BIOS Setup)? Is it possible that you are not using the correct version of the configuration program (assuming it's a util running from floppy and not from ROM)?

If that's not it then my guess is that it's a bug in the BIOS.
 
Have you tried booting from a floppy with all the references to C: changed to D: instead? It is possible to outsmart a machine sometimes. :)
 
Thanks guys - the 'drive count' refers to the number of floppy drives (1 or 2)

Looks like it might be a bug in the bios - changing all the drive refs to d: does work - I've also discovered that leaving the drive ref off completely (so it uses the current drive - whatever it is at the time) also works - at least for config. sys. I think this must be what I did 25 years ago, though I have no memory of it.

Thanks for the advice!
 
Looks like it might be a bug in the bios

Or, I suppose it could also be a bug in the configuration program. You can use DEBUG (or write a program if you know how to do that) to verify or change the settings.

With a newer version of DOS the third phantom floppy drive should come after any harddrives making the drive letter references less of a problem (would avoid problems with programs that assume the first harddrive is always C:).

Regarding drive letter references in AUTOEXEC.BAT (path statements etc); check for a directory that only exists on the first harddrive (the DOS directory for example) like this;
Code:
if exist D:\DOS\NUL goto RunningFromD
:RunningFromC
path C:\DOS
goto End
:RunningFromD
path D:\DOS
:End

Hope this helps!
 
Or, I suppose it could also be a bug in the configuration program. You can use DEBUG (or write a program if you know how to do that) to verify or change the settings.

With a newer version of DOS the third phantom floppy drive should come after any harddrives making the drive letter references less of a problem (would avoid problems with programs that assume the first harddrive is always C:).

Regarding drive letter references in AUTOEXEC.BAT (path statements etc); check for a directory that only exists on the first harddrive (the DOS directory for example) like this;
Code:
if exist D:\DOS\NUL goto RunningFromD
:RunningFromC
path C:\DOS
goto End
:RunningFromD
path D:\DOS
:End

Hope this helps!

I've only ever seen 1 version of the config program (NVR.EXE) = so it's unlikely its a problem if Amstrad never patched it.

I thought about the DOS issue - it's got 3.2 at present, I don't have a 360K boot disk for a later version to test it.

I came up with a similar section of code at the start of the autoexec.bat file - but in order to get it to run at all I had to use a SHELL command in the config.sys file to load COMMAND.COM from D:\

There's a limit to what can be done with 3.2 - I'll try to get it upgraded to 6.22 so I can write an 'intelligent' config.sys/autoexec.bat to take care of it!

Thanks for the help!
 
Back
Top