Hanusz L. | 6 Oct 10:10 2009

Support for 16 head harddisk on OLD Interactive Unix configured for 15 head harddisk

Hello,

 

I have an old system running Interactive Unix on a 15 head harddisk (4Gb).

I would like to clone this system to a 16 head harddisk because it is now difficult to find 15 head harddisks.

 

The problem is that I cannot modify the system which think it has a 15 head harddisk.

I suppose that Interactive unix use the Int13 interrupt mechanism to access the disk (am I wrong ?).

 

I wonder if there is a possibility to modify openbios so that a 16 head harddisk is used and is simulated as a 15 head harddisk by the bios ?

I would probably have to modify the drivers/ide.c file to do a conversion.

 

My questions are:

-          Can openbios boot Interactive Unix ?

-          What implementation should I use ?

 

Thanks for any help,

 

Leszek Hanusz

This e-mail message has been scanned for Viruses and Content and cleared by  Mailsecurity software
<div>

<div class="Section1">

<p class="MsoNormal"><span>Hello,</span></p>

<p class="MsoNormal"><span>&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">I have an old system running Interactive Unix on a 15
head harddisk (4Gb).</span></p>

<p class="MsoNormal"><span lang="EN-GB">I would like to clone this system to a 16 head harddisk
because it is now difficult to find 15 head harddisks.</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">The problem is that I cannot modify the system which
think it has a 15 head harddisk.</span></p>

<p class="MsoNormal"><span lang="EN-GB">I suppose that Interactive unix use the Int13
interrupt mechanism to access the disk (am I wrong ?).</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">I wonder if there is a possibility to modify openbios
so that a 16 head harddisk is used and is simulated as a 15 head harddisk by
the bios ?</span></p>

<p class="MsoNormal"><span lang="EN-GB">I would probably have to modify the drivers/ide.c
file to do a conversion.</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">My questions are:</span></p>

<p class="MsoNormal"><span lang="EN-GB">-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><span lang="EN-GB">Can openbios boot Interactive Unix ?</span></p>

<p class="MsoNormal"><span lang="EN-GB">-<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><span lang="EN-GB">What implementation should I use ?</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">Thanks for any help,</span></p>

<p class="MsoNormal"><span lang="EN-GB">&nbsp;</span></p>

<p class="MsoNormal"><span lang="EN-GB">Leszek Hanusz</span></p>

</div>

This e-mail message has been scanned for Viruses and Content and cleared 
by&nbsp; Mailsecurity software 
</div>
Lennart Sorensen | 6 Oct 19:49 2009
Picon
Picon

Re: Support for 16 head harddisk on OLD Interactive Unix configured for 15 head harddisk

On Tue, Oct 06, 2009 at 10:10:10AM +0200, Hanusz L. wrote:
> I have an old system running Interactive Unix on a 15 head harddisk (4Gb).
> I would like to clone this system to a 16 head harddisk because it is now difficult to find 15 head harddisks.
> 
> The problem is that I cannot modify the system which think it has a 15 head harddisk.
> I suppose that Interactive unix use the Int13 interrupt mechanism to access the disk (am I wrong ?).

I highly suspect you are wrong.  DOS uses INT13.  Boot loaders use INT13.
Anything runing protected mode does not.  Anything 32bit is protected mode.

> I wonder if there is a possibility to modify openbios so that a 16 head harddisk is used and is simulated as a
15 head harddisk by the bios ?
> I would probably have to modify the drivers/ide.c file to do a conversion.
> 
> My questions are:
> -          Can openbios boot Interactive Unix ?
> -          What implementation should I use ?
> 
> Thanks for any help,

Are you running this on real hardware or on qemu or what?  If the OS
actually uses CHS access to the disk, then I don't think you can do
anything on real hardware since the disk isn't likely to help you out
translating.  If the OS actually uses LBA (as most sane OSs have done for
many years), then it doesn't matter and the CHS is just partition table
related and doesn't do anything after the partitions have been located.

I am sure qemu could be made to emulate a disk with any desired geometry
though.

If real hardware, well replacing the BIOS on a system is a lot of hard
work given you have to figure out all the hardware initialization that
must be done.  It still doesn't solve the fact that the disk when
receiving CHS based commands isn't going to be 15 heads.

--

-- 
Len Sorensen

G 3 | 14 Oct 15:45 2009
Picon

OpenBIOS version 1.1?

Is there a roadmap or plan that states when version 1.1 of OpenBIOS  
will be declared? I'm wondering this because a lot of features have  
been added to OpenBIOS since version 1.0 was released (7 months ago).

Blue Swirl | 14 Oct 19:57 2009
Picon

Re: OpenBIOS version 1.1?

On Wed, Oct 14, 2009 at 4:45 PM, G 3 <programmingkidx@...> wrote:
> Is there a roadmap or plan that states when version 1.1 of OpenBIOS will be
> declared? I'm wondering this because a lot of features have been added to
> OpenBIOS since version 1.0 was released (7 months ago).

Well, my plan was to follow QEMU releases, with OpenBIOS 1.1 released
together with QEMU 0.11, but that didn't happen.

We could still retroactively tag the revisions, for example r505 ->
openbios-1.0-qemu-0.11.

svn | 20 Oct 01:02 2009

r590 - trunk/openbios-devel/arch/ppc/qemu

Author: laurent
Date: 2009-10-20 01:02:10 +0200 (Tue, 20 Oct 2009)
New Revision: 590

Modified:
   trunk/openbios-devel/arch/ppc/qemu/main.c
Log:
ppc: if "\\:tbxi" (mac) fails, try "ppc\bootinfo.txt" (chrp).

This is needed to load the bootloader of OpenBSD.

Signed-off-by: Laurent Vivier <Laurent@...>

Modified: trunk/openbios-devel/arch/ppc/qemu/main.c
===================================================================
--- trunk/openbios-devel/arch/ppc/qemu/main.c	2009-09-21 23:12:02 UTC (rev 589)
+++ trunk/openbios-devel/arch/ppc/qemu/main.c	2009-10-19 23:02:10 UTC (rev 590)
 <at>  <at>  -205,8 +205,12  <at>  <at> 
 static void
 newworld_boot( void )
 {
-        static const char * const chrp_path = "\\\\:tbxi" ;
+        static const char * const chrp_path[] = { "\\\\:tbxi",
+						  "ppc\\bootinfo.txt",
+						  NULL
+						  };
         char *path = pop_fstr_copy(), *param;
+	int i;

 	param = strchr(path, ' ');
 	if (param) {
 <at>  <at>  -237,7 +241,8  <at>  <at> 
                     param = pop_fstr_copy();
                 }
                 try_path(path, NULL, param);
-	        try_path(path, chrp_path, param);
+                for (i = 0; chrp_path[i]; i++)
+	            try_path(path, chrp_path[i], param);
             } else {
                 uint16_t boot_device = fw_cfg_read_i16(FW_CFG_BOOT_DEVICE);
                 switch (boot_device) {
 <at>  <at>  -249,12 +254,14  <at>  <at> 
                     path = strdup("cd:");
                     break;
                 }
-	        try_path(path, chrp_path, param);
+                for (i = 0; chrp_path[i]; i++)
+	            try_path(path, chrp_path[i], param);
             }
         } else {
             NEWWORLD_DPRINTF("Entering boot, path %s\n", path);
 	    try_path(path, NULL, param);
-            try_path(path, chrp_path, param);
+            for (i = 0; chrp_path[i]; i++)
+	        try_path(path, chrp_path[i], param);
         }
 	printk("*** Boot failure! No secondary bootloader specified ***\n");
 }

Mark Cave-Ayland | 31 Oct 12:02 2009
Picon

PATCH: Implement Forth source debugger for OpenBIOS

Hi all,

Whilst spending some time working on debugging SPARC64 support with 
Qemu/OpenBIOS, it became readily apparent that progress was being 
hampered by the lack of debugging facilities in OpenBIOS (see 
http://lists.openbios.org/pipermail/openbios/2009-August/003949.html). 
Hence I've been working on adding a source debugger to OpenBIOS which 
should enable developers to step/trace through Forth words in order to 
locate bugs in the lower level Forth OpenBIOS code.

The attached patch implements a Forth Source Debugger based upon the 
IEEE-1275 specification; it is not a comprehensive implementation but 
has already proved to be very useful in my tests here. A sample session 
using the debugger goes something like this:

Welcome to OpenBIOS v1.0 built on Oct 31 2009 10:09
   Type 'help' for detailed information

[unix] Booting default not supported.

0 > : bar ." test " ;  ok
0 > debug bar
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
  ok
0 > bar
: bar  ( Empty )
0xf7e11f0c: (")
: (")  ( Empty )
0xf7dfd928: r>  ( f7e11f0c )
0xf7dfd92c: dup  ( f7e11f0c f7e11f0c )
0xf7dfd930: 2  ( f7e11f0c f7e11f0c 2 )
0xf7dfd934: cells  ( f7e11f0c f7e11f0c 8 )
0xf7dfd938: +  ( f7e11f0c f7e11f14 )
0xf7dfd93c: over  ( f7e11f0c f7e11f14 f7e11f0c )
0xf7dfd940: cell+  ( f7e11f0c f7e11f14 f7e11f10 )
0xf7dfd944:  <at>   ( f7e11f0c f7e11f14 5 )
0xf7dfd948: rot  ( f7e11f14 5 f7e11f0c )
0xf7dfd94c: over  ( f7e11f14 5 f7e11f0c 5 )
0xf7dfd950: +  ( f7e11f14 5 f7e11f11 )
0xf7dfd954: aligned  ( f7e11f14 5 f7e11f14 )
0xf7dfd958: cell+  ( f7e11f14 5 f7e11f18 )
0xf7dfd95c: >r  ( f7e11f14 5 )
0xf7dfd960: (semis)
[ Finished (") ]  ( f7e11f14 5 )
0xf7e11f1c: type test  ( Empty )
0xf7e11f20: (semis)
[ Finished bar ]  ok
0 > bar
: bar  ( Empty )
0xf7e11f0c: (")
: (")  ( Empty )
0xf7dfd928: r>
[ Up to bar ]  ( f7e11f14 5 )
0xf7e11f1c: type test  ( Empty )
0xf7e11f20: (semis)
[ Finished bar ]  ok
0 >

As eluded to in earlier posts to the list, my initial attempts at adding 
debug support were focused on storing additional information in the 
rstack. Unfortunately this created extra problems in debugging some of 
the more interesting Forth words, since they would manipulate the return 
stack and cause the debugger to get confused.

My final implementation works in a much more simple way; when the debug 
word is invoked with the name of the word to debug, the start and end 
addresses of the word are added to a debug linked list. Then in the 
next() function, we iterate through the linked list to see if the 
current PC lies within one of the functions within. If this is the case, 
we enter the source debugger in step/trace mode as appropriate.

Having given the patch a reasonably good test here, I'm quite pleased 
with the additional functionality it provides. The only minor downsides 
I can see are that the patch adds extra work in docol(), semis() and 
next() in order to update the debug linked list. I've tried to wrap most 
of the complexity in conditional while() statements so that it is only 
invoked while the debugger is active, and so should have a minimal 
impact on normal runtime performance (which seems to be the case here).

Please test the patch and let me know if it requires extra work in order 
for it to be considered ready for committing to the OpenBIOS SVN repository.

ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs
Hi all,

Whilst spending some time working on debugging SPARC64 support with 
Qemu/OpenBIOS, it became readily apparent that progress was being 
hampered by the lack of debugging facilities in OpenBIOS (see 
http://lists.openbios.org/pipermail/openbios/2009-August/003949.html). 
Hence I've been working on adding a source debugger to OpenBIOS which 
should enable developers to step/trace through Forth words in order to 
locate bugs in the lower level Forth OpenBIOS code.

The attached patch implements a Forth Source Debugger based upon the 
IEEE-1275 specification; it is not a comprehensive implementation but 
has already proved to be very useful in my tests here. A sample session 
using the debugger goes something like this:

Welcome to OpenBIOS v1.0 built on Oct 31 2009 10:09
   Type 'help' for detailed information

[unix] Booting default not supported.

0 > : bar ." test " ;  ok
0 > debug bar
Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
  ok
0 > bar
: bar  ( Empty )
0xf7e11f0c: (")
: (")  ( Empty )
0xf7dfd928: r>  ( f7e11f0c )
0xf7dfd92c: dup  ( f7e11f0c f7e11f0c )
0xf7dfd930: 2  ( f7e11f0c f7e11f0c 2 )
0xf7dfd934: cells  ( f7e11f0c f7e11f0c 8 )
0xf7dfd938: +  ( f7e11f0c f7e11f14 )
0xf7dfd93c: over  ( f7e11f0c f7e11f14 f7e11f0c )
0xf7dfd940: cell+  ( f7e11f0c f7e11f14 f7e11f10 )
0xf7dfd944:  <at>   ( f7e11f0c f7e11f14 5 )
0xf7dfd948: rot  ( f7e11f14 5 f7e11f0c )
0xf7dfd94c: over  ( f7e11f14 5 f7e11f0c 5 )
0xf7dfd950: +  ( f7e11f14 5 f7e11f11 )
0xf7dfd954: aligned  ( f7e11f14 5 f7e11f14 )
0xf7dfd958: cell+  ( f7e11f14 5 f7e11f18 )
0xf7dfd95c: >r  ( f7e11f14 5 )
0xf7dfd960: (semis)
[ Finished (") ]  ( f7e11f14 5 )
0xf7e11f1c: type test  ( Empty )
0xf7e11f20: (semis)
[ Finished bar ]  ok
0 > bar
: bar  ( Empty )
0xf7e11f0c: (")
: (")  ( Empty )
0xf7dfd928: r>
[ Up to bar ]  ( f7e11f14 5 )
0xf7e11f1c: type test  ( Empty )
0xf7e11f20: (semis)
[ Finished bar ]  ok
0 >

As eluded to in earlier posts to the list, my initial attempts at adding 
debug support were focused on storing additional information in the 
rstack. Unfortunately this created extra problems in debugging some of 
the more interesting Forth words, since they would manipulate the return 
stack and cause the debugger to get confused.

My final implementation works in a much more simple way; when the debug 
word is invoked with the name of the word to debug, the start and end 
addresses of the word are added to a debug linked list. Then in the 
next() function, we iterate through the linked list to see if the 
current PC lies within one of the functions within. If this is the case, 
we enter the source debugger in step/trace mode as appropriate.

Having given the patch a reasonably good test here, I'm quite pleased 
with the additional functionality it provides. The only minor downsides 
I can see are that the patch adds extra work in docol(), semis() and 
next() in order to update the debug linked list. I've tried to wrap most 
of the complexity in conditional while() statements so that it is only 
invoked while the debugger is active, and so should have a minimal 
impact on normal runtime performance (which seems to be the case here).

Please test the patch and let me know if it requires extra work in order 
for it to be considered ready for committing to the OpenBIOS SVN repository.

ATB,

Mark.

--

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

Gmane