24 Aug
2012
24 Aug
'12
2:44 p.m.
Liam Proven wrote:
Hey, John, welcome! Have you just joined or been here
lurking all along?
Just joined.
In CP/M, isn't the BIOS just a file on disk
anyway?
It is, but adding functionality to it without the loadable driver
facility would be nowhere near as straightforward. You'd need to work
out how to allocate memory to your additional feature, how to hook it
into the various BIOS data structures, and then how to get the .EMS
self-unpacker to relocate it to the right place. And since it would be
infringement of copyright to distribute the patched file, you'd have to
distribute a program that did that patching.
Chuck Guzis wrote:
Suppose I wanted to use 1.44M 3.5" floppies. The
hardware (with a
bit of tweaking) is capable of it. No way to get to the boot
software, however. Suppose I wanted to boot from a home-built CF
card...
In theory you could replace the boot ROM (desolder the 8041, read its
contents, and burn an 8741 with the new boot image. Or even an 8742, if
you wanted more than 256 bytes of boot program). In the 9512 it would be
even easier, because the corresponding microcontroller used an external ROM.
It was also possible for peripherals plugged into the expansion port to
provide their own boot ROMs; Cirtech's external hard drives did so, for
example, and they advertised a similar device that booted from flash.
--
John Elliott
25 Aug
25 Aug
2:12 p.m.
On 24 Aug 2012 at 19:44, John Elliott wrote:
In theory you could replace the boot ROM (desolder
the 8041, read
its
contents, and burn an 8741 with the new boot image. Or even an 8742,
if you wanted more than 256 bytes of boot program). In the 9512 it
would be even easier, because the corresponding microcontroller used
an external ROM.
Hmmm. Tony seems to think that the boot code resided in the ASIC,
but that would have been the difficult way to go about it.
Thanks for the info about the hard disk providing its own boot code.
That's definitely a starting point.
--Chuck
5:14 p.m.
On 24 Aug 2012 at 19:44, John Elliott wrote:
That is what I was told by one of the designers at Amstrad.
Using the 8041 as a boot ROM would be problematic IMHO. There could be
code i nthere to preset the boot ROM bytes one at a time on a noraml read
cycle I suppose -- i nfact that could eb why the PROG pin is conencted to
a signal o nteh SIC alled NBOOT. Readign the ROM directly involves
overvoltaging one of the 8041 pins, I can't eee the circuitry to do that.
Waht does a PCW do (or not do) if powered up with the pritner
microcontroller missing.
In theory you could replace the boot ROM
(desolder the 8041, read
its
contents, and burn an 8741 with the new boot image. Or even an 8742,
if you wanted more than 256 bytes of boot program). In the 9512 it
would be even easier, because the corresponding microcontroller used
an external ROM.
Hmmm. Tony seems to think that the boot code resided in the ASIC,
but that would have been the difficult way to go about it.
Thanks for the info about the hard disk providing its own boot code.
That's definitely a starting point.
Wht does the MDIS/ signal on the expansion connetor do? It gors to the
gate array and nowhere else/ From the name it might be 'Memory Disable'
and might, indded, disable the internal boot ROM if pulled low at the
right times.
I didn't relaise before I looked at the schemtaics that the video and
sync signals are on thet expansion conenctor too.
-tony
6:59 p.m.
On 08/25/2012 05:14 PM, Tony Duell wrote:
That would be insane as 8041 was a 1Kb (code space) embedded micro with
and trivial IO port designed as a intelligent IO device. Boot code there
would have to be small and the main system would still need a boot to get
the code out as the 8041 could not be a bus master
(it could be a DMA target/source).
One can be creative but that seems like the hard way to get things done and
every system I've seen that has the 8041 used all the code space to do more
useful things (printers, keyboard scanning or IO for examples).
Allison
On 24 Aug 2012
at 19:44, John Elliott wrote:
That is what I was told
by one of the designers at Amstrad.
Using the 8041 as a boot ROM would be problematic IMHO. There could be
code i nthere to preset the boot ROM bytes one at a time on a noraml read
cycle I suppose -- i nfact that could eb why the PROG pin is conencted to
a signal o nteh SIC alled NBOOT. Readign the ROM directly involves
overvoltaging one of the 8041 pins, I can't eee the circuitry to do that. In theory you could replace the boot ROM
(desolder the 8041, read
its
contents, and burn an 8741 with the new boot image. Or even an 8742,
if you wanted more than 256 bytes of boot program). In the 9512 it
would be even easier, because the corresponding microcontroller used
an external ROM.
Hmmm. Tony seems to think that the boot code resided in the
ASIC,
but that would have been the difficult way to go about it. Waht does a PCW do (or not do) if powered up with the
pritner
microcontroller missing.
Thanks for the info about the hard disk providing
its own boot code.
That's definitely a starting point.
Wht does the MDIS/ signal on the expansion
connetor do? It gors to the
gate array and nowhere else/ From the name it might be 'Memory Disable'
and might, indded, disable the internal boot ROM if pulled low at the
right times.
I didn't relaise before I looked at the schemtaics that the video and
sync signals are on thet expansion conenctor too.
-tony
26 Aug
26 Aug
3:10 p.m.
In theory
you could replace the boot ROM (desolder the 8041, read
its
contents, and burn an 8741 with the new boot image. Or even an 8742,
if you wanted more than 256 bytes of boot program). In the 9512 it
would be even easier, because the corresponding microcontroller used
an external ROM.
Hmmm. Tony seems to think that the boot code resided in the
ASIC,
but that would have been the difficult way to go about it. would have to be small and the main system would still
need a boot to get
the code out as the 8041 could not be a bus master
(it could be a DMA target/source).
I thought for a momnen that perhaps the Z80 wasn't involved in booting
the mahcine, and that hardwired logic in the gae array set up the FDC,
read i na sector, and wrote the data to RAM. After all, the FDC and the
system DRAM are both connected to the gate array.
But I don't think that can happen. The problem is that the A) input
(register select) and the CS/ input (conencted to A7 fo the Z80 address
bus) are both conencted to the Z80 address lines. While those lines are
lso conencted to the gate array, there doesn't seem to be any way for
force the Z80 to 3-state them, sicne the gate array doesn't drive the
BUSRQ/ signal.
So it looks like the Z80 must run bootstrap code that sets up the FDC,
reads a secotr, and writes it to RAM. That's a fairly simple program, and
it could easily be done with hardwired logic simulating a ROM inside that
gate array. I would think that would be a lot easier than trying to run
code stored in an 8041 ROM.
One can be creative but that seems like the hard way to get things done and
every system I've seen that has the 8041 used all the code space to do more
useful things (printers, keyboard scanning or IO for examples).
SSure. The PCW uses an 8041 (maybe an 8042, all I have is the Amstrad
part number) to control the standard dot-matrix printer. This chip sits o
nthe Z80 bus, the port liens go to the printer conenctor. The pritner
itslf is essentaiall jsut driver cirucits.
The main parts o nthe lgoic board of the PCW are : Z80A processor, a
custom gate array chip, 256K or 512K DRAM, a 765 FDC chipop and data
separator and this pritner controller 8041. The gate array handles DRAM
timing and refresh, video genreation, the serial interfave to the
keyboard (clock + data line, the keyboarsd has an 8048 or something in
it), etc. And I believe it contains the boot code.
-tony
4298
days inactive
4300
days old
4 comments
4 participants
participants (4)
-
ajp166＠verizon.net -
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
jce＠seasip.demon.co.uk