Re: I write a patch for Japanese NEC i386 old computers.

Re: I write a patch for Japanese NEC i386 old computers.

[Ernest Sales]

On Sun, 25 Mar 2007 00:00:32 +0100 Yoshinori K. Okuji wrote:

> I have a question about the naming. Is it usual to call the platform
"nec98"? 
> I don't know how it is called in Linux/PC98 or FreeBSD(98), but it should
be 
> named in a similar way, I guess.

AFAIK in FreeBSD it is known as pc98, see for instance:

http://www.freebsd.org/relnotes/6-STABLE/hardware/

...but you better check this is the architecture you mean.

Regards,
Ernest Sales

---------------------------------------------------------------
plain text emails preferred, cf http://expita.com/nomime.html

Re: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello, all.

1. name of architecture.

In Japan, The 'PC-98' means the NEC PC-9800 series and its compatible
machines.
But, In the other country, 'PC98' means a hardware standard set by Microsoft
and
a consortium of hardware manufacturers.
I afraid to mistake, so named as 'NEC98'. But, I do not have a intent to
persist this name.

2. sharing of code with PC's.

Sharing of code with PC's bring me several problems.
Firstly, In this time, My patch includes a lot of PC's code. But amount of
the PC-9800 depended code will increase.
Secondaly, when changes PC's depended code, PC-9800 code shuld change also.
I think GRUB2 is next generation
of GRUB, not on the stable.

3. known bugs/problems of patches in this time.

* Scroll routine of console has a bug, bares trashes on the lowest line.
Should fix.
* Remains code of VGA and VBE, I'll replace to PC-9800 graphics routine.
* In the high-rezo mode, I do not have tested, not have any datasheet and
machine.
   (NEC released a few high-rezo supported machines, so this is little
problem.)
* Algorythm of transfering from LBA to CHS, I have trusted the answer of
BIOS. Should compute myself.(difficult)
* SASI/ATAPI device is not supported, should support this.(difficult)
* Listing devices by 'ls' command. when exists not-ready removable device,
its command ends with fail.
* cannot boot the FreeBSD(pc98). Should fix.
* 'play' command is not tested.
* On booting the Linux with framebuffer console,  cannot display correctly.
* First NEC PC-9801, PC-9801E, PC-9801F, and PC-9801M are not supported.
Support those.(not a big problem.)

4. Wish to discuss.

* Support of different sector-sizes, MO(Magneto Optical) disk uses
512/1024/2048 b/s(bytes per sector).
  CD-ROM uses 2048 b/s, FD of formatted by PC-9800 series often uses 1024
b/s, Old OS uses 256/128 b/s.
* When doing 'chainloader' command, the all disk devices cannot use via
'dev.c',
  because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
  I think it is disirable to do 'grub_loader_unload_func' on 'grub_*_boot'.

I try to fix this patches, and disclose in future.

Regard,

-- 
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

Re: I write a patch for Japanese NEC i386 old computers.

[Yoshinori K. Okuji]

On Wednesday 28 March 2007 17:27, Hitoshi Ozeki wrote:
> 1. name of architecture.
>
> In Japan, The 'PC-98' means the NEC PC-9800 series and its compatible
> machines.
> But, In the other country, 'PC98' means a hardware standard set by
> Microsoft and
> a consortium of hardware manufacturers.
> I afraid to mistake, so named as 'NEC98'. But, I do not have a intent to
> persist this name.

It is very difficult to say what name is appropriate. As far as I know, there 
is no consensus about this. FreeBSD uses "pc98", but I guess this is only 
because 386BSD(98) used "pc98", which was probably named by Ishii-san or 
Kojima-san.

Uhmm, very difficult. You are right, PC98 might be a bit confusing for some 
people. But NEC98 is unusual to me, and it sounds like excluding Epson's 
models.

For now, I prefer "pc98", because it is at least consistent with FreeBSD.

> 2. sharing of code with PC's.
>
> Sharing of code with PC's bring me several problems.
> Firstly, In this time, My patch includes a lot of PC's code. But amount of
> the PC-9800 depended code will increase.

Good point. If you think it is hard to share code, please don't try to share 
too much. Something I really want to avoid is to use a lot of cpp 
conditionals, only to share code.

> Secondaly, when changes PC's depended code, PC-9800 code shuld change also.
> I think GRUB2 is next generation
> of GRUB, not on the stable.

Yes, but I don't think it will change radically. I would like to change the 
way of reserving memory for GRUB, but this change should not affect so much.

> 4. Wish to discuss.
>
> * Support of different sector-sizes, MO(Magneto Optical) disk uses
> 512/1024/2048 b/s(bytes per sector).
>   CD-ROM uses 2048 b/s, FD of formatted by PC-9800 series often uses 1024
> b/s, Old OS uses 256/128 b/s.

I think there are two different ways to address this issue. One way is to use  
variable sector size. This looks elegant, but this affects the disk device 
API very much. The other is to use fixed sector size, as it is for now, but 
align boundaries at a device driver level. The latter way is used for GRUB 
Legacy to support CDROM, and it works well.

I don't know which way is better. What do you think?

> * When doing 'chainloader' command, the all disk devices cannot use via
> 'dev.c',
>   because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
>   I think it is disirable to do 'grub_loader_unload_func' on 'grub_*_boot'.

Could you elaborate on why this is bad?

Okuji

i386-pc 'chainloader' is something wrong. (RE: I write a patch for Japanese NEC i386 old computers.)

[Hitoshi Ozeki]

Hello,

I wrote:
> * When doing 'chainloader' command, the all disk devices cannot use via
> 'dev.c',
>   because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
>   I think it is disirable to do 'grub_loader_unload_func' on
'grub_*_boot'.

Okuji-san wrote:
> Could you elaborate on why this is bad?

At first, excuse me. 'grub_loader_unload_func' is not bad.
Please see 'grub-1.96/loader/i386/pc/chainloader.c' and
 'grub-1.96/kern/loader.c'

When we execute the 'boot' command, process the 'grub_loader_boot()'
--------------------------------------------------
grub_loader_boot (void)
{
  if (! grub_loader_loaded)
    return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");

  if (grub_loader_noreturn)
    grub_machine_fini (); <--- includes 'grub_biosdisk_fini()'
  
  return (grub_loader_boot_func) ();  <--- call the
'grub_chainloader_boot()'
}
--------------------------------------------------

And 'grub_loader_boot()' passes to 'grub_chainloader_boot()'

--------------------------------------------------
grub_chainloader_boot (void)
{
  grub_device_t dev;
  int drive = -1;
  void *part_addr = 0;
  
  /* Open the root device.  */
  dev = grub_device_open (0);  <--- Ouch! Cannot open device!
  if (dev)
    {
      grub_disk_t disk = dev->disk;
--------------------------------------------------      

I experience this trouble during my work,
 so 'grub_chainloader_boot()' doesn't open the root device in PC-9800 patch.

RE: i386-pc 'chainloader' is something wrong. (RE: I write a patch forJapanese NEC i386 old computers.)

[Hitoshi Ozeki]

Hello,

I wrote:
> Please see 'grub-1.96/loader/i386/pc/chainloader.c' and
>  'grub-1.96/kern/loader.c'
> 
> When we execute the 'boot' command, process the 'grub_loader_boot()'

(omit it)

To sum up, On 'chainloader' of i386-pc,
However 'grub_loader_boot()' executes 'grub_device_open()', it will fail
always.
But 'grub_loader_boot()'  do it.

If this behavior is wrong, we do only fix it.

What I wish to know is which is the boot drive.

1. 'root' environment indicates it.
2. argument of 'chainloader' command indicates it.

For example:
grub> set root=hd0,1
grub> chainloader (hd0,2)0+2
grub> boot

If the 1st is, boot from (hd0,1) and bootloader is (hd0,2)0+2.
If the 2nd is, boot from (hd0,2) and bootloader is (hd0,2)0+2.

...Aha! EFI looks to choose 1st. Should I obey it?

Re: i386-pc 'chainloader' is something wrong. (RE: I write a patch forJapanese NEC i386 old computers.)

[Yoshinori K. Okuji]

On Saturday 31 March 2007 06:24, Hitoshi Ozeki wrote:
> > Please see 'grub-1.96/loader/i386/pc/chainloader.c' and
> >  'grub-1.96/kern/loader.c'
> >
> > When we execute the 'boot' command, process the 'grub_loader_boot()'
>
> (omit it)
>
> To sum up, On 'chainloader' of i386-pc,
> However 'grub_loader_boot()' executes 'grub_device_open()', it will fail
> always.
> But 'grub_loader_boot()'  do it.
>
> If this behavior is wrong, we do only fix it.

You are right. This is wrong. I will have a look later.

> What I wish to know is which is the boot drive.
>
> 1. 'root' environment indicates it.
> 2. argument of 'chainloader' command indicates it.
>
> For example:
> grub> set root=hd0,1
> grub> chainloader (hd0,2)0+2
> grub> boot
>
> If the 1st is, boot from (hd0,1) and bootloader is (hd0,2)0+2.
> If the 2nd is, boot from (hd0,2) and bootloader is (hd0,2)0+2.
>
> ...Aha! EFI looks to choose 1st. Should I obey it?

Yes. This is the intented behavior. The distinction is important, because you 
might want to save a boot sector at somewhere else, and chainload it later. 
This feature makes recovery much easier.

Okuji

Re: i386-pc 'chainloader' is something wrong. (RE: I write a patch for Japanese NEC i386 old computers.)

[Yoshinori K. Okuji]

On Friday 30 March 2007 11:34, Hitoshi Ozeki wrote:
> I wrote:
> > * When doing 'chainloader' command, the all disk devices cannot use via
> > 'dev.c',
> >   because of doing 'grub_loader_unload_func'  on 'grub_loader_set'.
> >   I think it is disirable to do 'grub_loader_unload_func' on
>
> 'grub_*_boot'.
>
> Okuji-san wrote:
> > Could you elaborate on why this is bad?
>
> At first, excuse me. 'grub_loader_unload_func' is not bad.
> Please see 'grub-1.96/loader/i386/pc/chainloader.c' and
>  'grub-1.96/kern/loader.c'

I have fixed this right now. Thank you.

Okuji

RE: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello, all.

Okuji-san wrote about the different(128-2048 bytes) sector-size support:
	 I think there are two different ways to address this issue. One way
is to use  
	 variable sector size. This looks elegant, but this affects the disk
device 
	 API very much. The other is to use fixed sector size, as it is for
now, but 
	 align boundaries at a device driver level. The latter way is used
for GRUB 
	 Legacy to support CDROM, and it works well.
	 I don't know which way is better. What do you think?


Maybe, The implement of GRUB legacy comes from PC architecture.
On the PC architecture BIOS, regards 512 bytes as a block. And
BIOS requires a number of blocks.

On NEC PC-9800 series, Disk BIOS requires data size in byte,
not a number of sectors. Data size must be divisible by sector size.
And the partition table starts with LBA sector 1, and its length
equals to sector size.

It's too difficult to change the API.

I think to set the GRUB_DISK_SECTOR_SIZE as the least.
(As far as I know, The least hardware sector size is 128 bytes.)
and add the variable to 'struct grub_disk'. Its variable stores 
 sector size(blocks per sector).

In this case, A name of 'GRUB_DISK_SECTOR_SIZE' does not match
the actual situation. I'd like its name changed.

-- 
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

RE: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello, all.
	
Okuji-san wrote about the different(128-2048 bytes) sector-size support:
	I think there are two different ways to address this issue. One way
is to use
	variable sector size. This looks elegant, but this affects the disk
device 
	API very much. The other is to use fixed sector size, as it is for
now, but 
	align boundaries at a device driver level.
	(omit)
	 I don't know which way is better. What do you think?
	
I wrote in last article:
	I think to set the GRUB_DISK_SECTOR_SIZE as the least.
	(As far as I know, The least hardware sector size is 
	128 bytes.) and add the variable to 'struct grub_disk'. 
	Its variable stores 
	 sector size(blocks per sector).

In addition, Let me talk about the recent PC-9800 patch.
I use the GRUB_DISK_SECTOR_SIZE in a meaning of default sector size(=512).
and add the variable 'sector_size' to 'struct grub_disk'. 
GRUB_DISK_SECTOR_SIZE is used to initialize the 'sector_size'.
GRUB_DISK_SECTOR_SIZE is replaced with 'sector_size' in most case.

Re: I write a patch for Japanese NEC i386 old computers.

[Vesa Jääskeläinen]

Hitoshi Ozeki wrote:
> Hello, all.
> 	
> Okuji-san wrote about the different(128-2048 bytes) sector-size support:
> 	I think there are two different ways to address this issue. One way
> is to use
> 	variable sector size. This looks elegant, but this affects the disk
> device 
> 	API very much. The other is to use fixed sector size, as it is for
> now, but 
> 	align boundaries at a device driver level.
> 	(omit)
> 	 I don't know which way is better. What do you think?
> 	
> I wrote in last article:
> 	I think to set the GRUB_DISK_SECTOR_SIZE as the least.
> 	(As far as I know, The least hardware sector size is 
> 	128 bytes.) and add the variable to 'struct grub_disk'. 
> 	Its variable stores 
> 	 sector size(blocks per sector).
> 
> In addition, Let me talk about the recent PC-9800 patch.
> I use the GRUB_DISK_SECTOR_SIZE in a meaning of default sector size(=512).
> and add the variable 'sector_size' to 'struct grub_disk'. 
> GRUB_DISK_SECTOR_SIZE is used to initialize the 'sector_size'.
> GRUB_DISK_SECTOR_SIZE is replaced with 'sector_size' in most case.

Just a quick comment. Should we one day have direct support for CD-ROM's
or such devices which have larger sector sizes, I would propose that
this information should be dynamic and device specific. This change
probably causes some issues about how should grub be installed on
devices having sector size != 512. And should there be emulation layer
for 512 byte sector size? At least El Torito does provide this...

Re: I write a patch for Japanese NEC i386 old computers.

[Ernest Sales]

On Thu, 29 Mar 2007 00:27:06 +0900 "Hitoshi Ozeki"
<h-ozeki@ck2.so-net.ne.jp> wrote:

> 1. name of architecture.
>
> In Japan, The 'PC-98' means the NEC PC-9800 series and its compatible
machines.
> But, In the other country, 'PC98' means a hardware standard set by
Microsoft and
> a consortium of hardware manufacturers.
> I afraid to mistake, so named as 'NEC98'. But, I do not have a intent to
> persist this name.

I am unaware of the subtleties of architectures, but here is more specific
info of what is called "pc98" by the *BSD people, so you can make up your
mind:

FreeBSD:
http://www.freebsd.org/relnotes/6-STABLE/hardware/pc98/support-sys.html
NetBSD: http://netbsd.org/Ports/
NetBSD: http://www.nisoc.or.jp/~karl/netbsd-pc98/ (in japanese)

Regarding the Linux distros I didn't do my homework yet.

Cheers,
Ernest Sales

Re: I write a patch for Japanese NEC i386 old computers.

[Yoshinori K. Okuji]

On Thursday 29 March 2007 08:39, Ernest Sales wrote:
> I am unaware of the subtleties of architectures, but here is more specific
> info of what is called "pc98" by the *BSD people, so you can make up your
> mind:
>
> FreeBSD:
> http://www.freebsd.org/relnotes/6-STABLE/hardware/pc98/support-sys.html
> NetBSD: http://netbsd.org/Ports/
> NetBSD: http://www.nisoc.or.jp/~karl/netbsd-pc98/ (in japanese)

Yes, *BSD call it "pc98".

> Regarding the Linux distros I didn't do my homework yet.

Nothing is defined in Linux. AFAIK, the patch for Linux does not make any 
directory, but just patches existing code.

Okuji

RE: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello, all.

Okuji-san wrote:
Nothing is defined in Linux. AFAIK, the patch for Linux does not make any 
directory, but just patches existing code.



Those pages are Linux porting project. Called as ''Linux/98 project".
Long ago, called as "Seraphim project". I don't know the origin of its name.
http://sourceforge.jp/projects/linux98/
http://linux98.sourceforge.jp/
http://www.kmc.gr.jp/proj/linux98/
(written in Japanese language, and this project have slept in now.)

Linux/98 2.5.67 (bk9) uses 'pc9800' directory.
Ex) "arch/i386/mach-pc9800"

And Linux/98 2.4.20 (2003/3/2 snapshot) uses it.
Ex) "arch/i386/boot/pc9800"

-- 
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

I write a patch for Japanese NEC i386 old computers.

[小関 一志]

[-- Attachment #1: Type: text/plain, Size: 286 bytes --]

Hello, all.

I write a patch for GRUB 1.95. this is able to run GRUB2 under NEC PC-9800
series.
(NEC PC-9800 is Japanese i386 computer, but its hardware design is different
with PC.)

Attach file: grub-1.95-nec98.diff.gz (113Kbytes)

Regards.
--
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

[-- Attachment #2: grub-1.95-nec98.diff.gz --]
[-- Type: application/x-gzip-compressed, Size: 115133 bytes --]

Re: I write a patch for Japanese NEC i386 old computers.

[Hollis Blanchard]

On Sun, 2007-03-25 at 00:53 +0900, 小関 一志 wrote:
> Hello, all.
> 
> I write a patch for GRUB 1.95. this is able to run GRUB2 under NEC PC-9800
> series. (NEC PC-9800 is Japanese i386 computer, but its hardware design is different
> with PC.)
> 
> Attach file: grub-1.95-nec98.diff.gz (113Kbytes)

Thanks for your hard work!

You seem to have copied many files from i386/pc to i386/nec. A better
approach would be to share them directly, for example by moving them to
the i386 directory.

Could you separate your changes to common code (e.g. the code movement
above, get_diskinfo, etc) and post those patches separately? That way we
don't have a 650KB (!!!) patch to review.

The code movement patch should just be a list of
        old location -> new location
(that way it doesn't take up much space at all :) .

-Hollis

RE: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

Sorry, my last article is too large, and includes copied part.
I prepare for separated and removed copies patch.

Attached file: grub-1.95-nec98-patches.tar.gz (61Kbytes)

When you want to make the source tree for nec98, type below
$ tar xzf grub-1.95.tar.gz
$ tar xzf grub-1.95-nec98-patches.tar.gz
$ sh ./make-source-tree.sh
[end]

(file map)
boot/i386/pc/* -> boot/i386/nec98/*
commands/i386/pc/* -> commands/i386/nec98/*
conf/i386-pc.mk -> conf/i386-nec98.mk
conf/i386-pc.rmk -> conf/i386-nec98.rmk
disk/i386/pc/* -> disk/i386/nec98/*
include/grub/i386/pc/* -> include/grub/i386/nec98/*
(none) -> include/grub/i386/nec98/sca.h
include/grub/i386/pc/util/* -> include/grub/i386/nec98/util/*
include/grub/pc_partition.h -> include/grub/nec98_partition.h
kern/i386/pc/* -> kern/i386/nec98/*
kern/i386/pc/* -> kern/i386/nec98/*
loader/i386/pc/* -> loader/i386/nec98/*
partmap/pc.c -> partmap/nec98.c
term/i386/pc/* -> term/i386/nec98/*
util/i386/pc/* -> util/i386/nec98/*
video/i386/pc/* -> video/i386/nec98/*

'include/grub/i386/nec98/sca.h'  defines PC-9800 BIOS informations.
'video/i386/nec98/*' is only copied, hack nothing(PC-9800 does not have VGA
and VBE).

-- 
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

[-- Attachment #2: grub-1.95-nec98-patches.tar.gz --]
[-- Type: application/x-gzip-compressed, Size: 62259 bytes --]

Re: I write a patch for Japanese NEC i386 old computers.

[Yoshinori K. Okuji]

On Saturday 24 March 2007 20:01, Hitoshi Ozeki wrote:
> boot/i386/pc/* -> boot/i386/nec98/*
> commands/i386/pc/* -> commands/i386/nec98/*
> conf/i386-pc.mk -> conf/i386-nec98.mk
> conf/i386-pc.rmk -> conf/i386-nec98.rmk
> disk/i386/pc/* -> disk/i386/nec98/*
> include/grub/i386/pc/* -> include/grub/i386/nec98/*
> (none) -> include/grub/i386/nec98/sca.h
> include/grub/i386/pc/util/* -> include/grub/i386/nec98/util/*
> include/grub/pc_partition.h -> include/grub/nec98_partition.h
> kern/i386/pc/* -> kern/i386/nec98/*
> kern/i386/pc/* -> kern/i386/nec98/*
> loader/i386/pc/* -> loader/i386/nec98/*
> partmap/pc.c -> partmap/nec98.c
> term/i386/pc/* -> term/i386/nec98/*
> util/i386/pc/* -> util/i386/nec98/*
> video/i386/pc/* -> video/i386/nec98/*

I have a question about the naming. Is it usual to call the platform "nec98"? 
I don't know how it is called in Linux/PC98 or FreeBSD(98), but it should be 
named in a similar way, I guess.

Thanks,
Okuji

RE: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello,

From: grub-devel-bounces+h-ozeki=ck2.so-net.ne.jp@gnu.org 
>I have a question about the naming. Is it usual to call the 
>platform "nec98"? 
>I don't know how it is called in Linux/PC98 or FreeBSD(98), 
>but it should be 
>named in a similar way, I guess.

I expect to mistake 'PC98' for the Microsoft PC98 specification.
EPSON's PC-9800 compatible machines? Uum...

Regards,

-- 
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

RE: I write a patch for Japanese NEC i386 old computers.

[Hitoshi Ozeki]

Hello, all

Appendix: memory map of GRUB on NEC PC-9800 series.

At most machines have only one hardware mode, it is 'normal mode'.

[normal mode]

Start	End	Usage
0x000000	0x0003FF	stack space of BIOS initial boot loader and
real mode interrupts
0x000400	0x0005FF	BIOS system common area(BIOS parameter and
workarea)
?	0x001FFF	Real mode stack
0x007C00	0x007FFF	Chainloader loads a bootloader temporary,
and boot.img uses here for data area.
0x008000	?	GRUB kernel
?	0x01FFFF	Limit of bootloader(boot sector and its next sector
loaded lower than here)
0x068000	0x077FFF	Disk buffer
?	0x07FFFF	Protected mode stack
0x080000	?	Heap
0x0A0000	0x0A7FFF	Console text RAM, CG(Character Generator)
window and NVRAM
0x0A8000	0x0BFFFF	Video RAM(RGB)
0x0C0000	0x0DFFFF	extended BIOS ROM
0x0E0000	0x0E7FFF	Video RAM(E).
0x0E8000	0x0FFFFF	BIOS ROM

Few machines have two hardware mode, normal mode and high-rezo mode.

[high-resolution(high-rezo) mode]

Start	End	Usage
0x000000	0x0003FF	stack space of BIOS initial boot loader and
real mode interrupts
0x000400	0x0005FF	BIOS system common area(BIOS parameter and
workarea)
?	0x001FFF	Real mode stack
0x007C00	0x007FFF	Chainloader loads a bootloader temporary,
and boot.img uses here for data area.
0x008000	?	GRUB kernel
?	0x01FFFF	Limit of bootloader(boot sector and its next sector
loaded lower than here)
0x068000	0x077FFF	Disk buffer
?	0x07FFFF	Protected mode stack
0x080000	0x0BFFFF	protected mode memory window
0x0C0000	0x0CFFFF	I forget.
0x0D0000	0x0DFFFF	extended BIOS ROM
0x0E0000	0x0E7FFF	Console text RAM, CG(Character Generator)
window and NVRAM
0x0E8000	0x0EFFFF	I forget.
0x0F0000	0x0FFFFF	BIOS ROM

Regards.

-- 
 Hitoshi Ozeki h-ozeki@ck2.so-net.ne.jp

Re: I write a patch for Japanese NEC i386 old computers.

[Yoshinori K. Okuji]

On Monday 26 March 2007 06:24, Hitoshi Ozeki wrote:
> Appendix: memory map of GRUB on NEC PC-9800 series.

Thank you for your information. Could you please add this information to the 
wiki:

http://grub.enbug.org/MemoryMap

Okuji