On (10 Nov 94) [EMAIL PROTECTED] wrote...
> Okay okay.... I'd realised that last night -- I missread the standards
*Grin*
> sheet :( But.... it still doesn't seem to make a difference, and I'm still
> having problems as regards missing bytes... I *think* the signal is
> bouncing a lot.. Distance to drive, I reckon. Have to checkk :(
Send me the current versions exact schematic ASAP! any CSHOW compatable format
will be fine:-) ALSO details of the logic states of the fixed lines on the
IDE-bus ie which are pulled high or low and which are left floating as that's
important too!
At worst get a FAX image file using BGFAX and a FAX machine as a scanner Brian
would probably help out with the FAX machine to use as the scanner:-)
> Hey Si don't I get a prototype board? or at least a pcb layout so I can
> build my own to begin development of my cp/m+ bios with it?
> Yep, you will -- when Martin's finished... at the moment, we're only
> reading half sectors...
Eeek, ok I'll be patient...
In response to imc (I think) you mentioned how ini couldn't be used if the
data port was split into 2 I/O locations....
Well IF you use A8 to determine which data register then inir would still be
fine as it'll cycle through odd/even etc. PLUS you'd have control over *when*
a word is actually xfered;-)
And of course it'll still fit in a block of eight 8bit I/O addresses.
It would also remove the need for the flip-flop to count the data acceses and
probably make it easily converted to GAL from the PROM design especially if
running from the drive2 slot where the 2 lines /RD & /WR are condensed into
the single WRL/RD line:-)
> Oh, and btw: here's a q: what do you think of the partition data, and where
> should the boot sector of the active partition be loaded and called from?
I had a quick scan through it, though I need to export it and study it
properly as this reader software doesn't expand hard-TABs so it won't line up
until I read it externally.... CPM OLR CRR never had that problem...sigh...
The BOOT loader for the specific operating system may be initialy hard-coded
into the bootstrap portion of the multirom dependant on the type of partition
selected eg ALL CP/M derivatives expect the first logical/physical sector of
the boot disc will be loaded to address Zero and JP,d to zero. That is then
supposed to load either the full system image ala CPM1&2 or a cut down loader
ala CP/M3. the bootstrap routine could offer 2 cp/m boot types... one takes
over the entire machine and loads into ram bank 0 or bank 8 to allow a 256k
native mode to reside in the lower 256k:-)
Though the latter Hi-loading CP/M3 could be handled from native mode if it'll
boot as a 256k on a 512k Sam to save MultiROM code. Which may be better as
it'll make sure there's a native-mode ready to swap to from the hi-cp/m3
system;-)
CP/M was not designed to share a HD with non-CP/M partitions so we'd have to
also pass the boot partition location on the HD to the boot loader. That's TBA
We can probably do this using registers to save traversing ram pages in the
512byte loader:-)
The ideal location for the final section of the CP/M style bootstrap would be
in the ROM1 section right at the end of it so it would disable ROM0 at block A
setup the HL/DE/BC registers with the drive partition data to pass and end the
64k address space with ROM1 OUT (&FA),A instruction disable and fall off the
end back to the boot-loader code at &0000;-)
Somthing like:-
LD HL,(start_cyl) ; used by boot sector code so it doesn't need to look it up
LD DE,(part_idx) ; passed to cold_boot bios to tell it where to look in table
; for partition size, We might not boot off the first part.
LD BC,(drive_base) ; We might have multiple IDE cards so this'll tell which
; one to use;-)
; May require disabling the MultiROM RAM to avoid contention if it's enable;-)
LD A,%00100000 ; switch out ROM1 & ROM0 and page in ram zero
JP go_cpm
ORG &FFFE
go_cpm:
OUT (LMPR),A
END ; literaly
on entry to the boot-sector code BC points to base addres. so I don't need to
check LMPR there <G> All I'd need to do is setup a multiple sector read from
the sector after the boot loader and load to whatever address I link the image
to and jump to it! The entire boot-sector code should take up much less than
128 bytes!
The state of the HMPR is not important as the latter loader will set that up
itself:-)
> I was thinking of at &4000, namely because it'd mean the DOS could be
> loaded into external memory ;)
Even if the boot sector was loaded at or above &8000 you'd still be allowed to
set LMPR to the same as the current HMPR and jump down low... Amazing what can
be done in 512bytes of properly size optimised code!
The way the native stuff boots is entirely upto you... To be honest I don't
know enough about the native mode boot operations to advise on a compatable HD
alterative, I did think about get the ROM disasembly but nevr bothered as I
don't use native mode if I can help it;-)
Undefined operating systems eg Unix must, by their yet to be designed
character, be booted from an existing operating system eg a CP/M .COM or
native CODE file.
The only native software I use is LERM SAMDISK Ver2 to repair the odd
corrupted track and that VERY rarely, Oh and COMET when hacking ProDos source
about but that's only because it's easier bringing up a boot disk from native
mode.
> Not enough space... the DOS takes up *just* 16k... I've had to hack out a
> lot of routines to get it working in there, and I *still* get dodgy sector
> reads :(
Are you hacking MasterDos with the aid of Source from Andy or are you hacking
it from your own disasemblies of it? If the latter it might be worth giving
Andy a bell and ask him if you can have a copy of the source for private use
only:-)
With the aid of your schematic etc. I *should* be able to pin the sector read,
and probably write, problems down for you:-)
>> PPS If I was BOB I'd page the DISC2 address space between the FDC and the
>> IDE card using spare bits in the internal sam-elite printer strobe port
>> and have an IDE port on the oposite end to the parallel socket!
> Welll.... he wants to use LPT2 ... stupid bugger :(
He certainly aint a Bruce Gordan!
Regards.
JT.
--
|Fidonet: Johnathan Taylor 2:2501/307.9
|Internet: [EMAIL PROTECTED]
|
| Standard disclaimer: The views of this user are strictly his own.
