[Qemu-devel] Support NEC PC-98x1 on QEMU

[Qemu-devel] Support NEC PC-98x1 on QEMU

[武田 俊也]

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

Hi members,

This is the patch to support NEC PC-98x1 on QEMU.

Now it is the experimental and has many limitations.
- support itf/bios/ide-bios dumped from PC-9801BX4 only
- cannot boot from ide/fdd drives
- can boot only internal ROM BASIC

I plan to develop pseudo itf rom image to support every PC-98 bios image
and finaly I aim to boot FreeBSD/pc98 on it.

There are some screenshots on my website:
http://homepage3.nifty.com/takeda-toshiya/qemu/index.html

Thanks,
TAKEDA, toshiya

[-- Attachment #2: qemu-20090906-pc9821.zip --]
[-- Type: application/x-zip-compressed, Size: 48573 bytes --]

Re: [Qemu-devel] Support NEC PC-98x1 on QEMU

[Stuart Brady]

Takeda-san,

> This is the patch to support NEC PC-98x1 on QEMU.

Ooh, awesome! :)

Some hopefully useful feedback, though...

There's no need to add this as a whole new architecture, although
perhaps the use of TARGET_PC98 was only meant to be temporary...

As the patch isn't against the latest code in Git, I suppose it's not
intended for inclusion just yet...  Still, it'd be nice to see it
cleaned up slightly, and applied! :)

AFAICT, the only PC98-specific behaviour in existing source files
relates to handling of:

 * DMA
 * i82078 floppy controller
 * i8259 interrupt controler
 * A20 gate

The only truly CPU-specific feature that I can see is the A20 gate
handling.  While I don't understand why (or whether) that particular
change is needed, it could certainly be done without any #ifdefs.
For the other changes, I expect that it needs to be made clear that
they really are PC98-specific, and that they are not just workarounds.

BTW, I think most subscribers to this list (and particularly the
maintainers) will be more likely to look at patches if they included
inline, or attached as text/plain (with the -N flag to include new
files in your patch).  Zip format can be a slight disincentive for
review by those with no special interest in the patch in question...

Looks like great work, though!

Cheers,
-- 
Stuart Brady

Re: [Qemu-devel] Support NEC PC-98x1 on QEMU

[武田 俊也]

Dear Stuart,

>There's no need to add this as a whole new architecture, although
>perhaps the use of TARGET_PC98 was only meant to be temporary...

The problem is that now TARGET_I386 is used for both 2 meanings,
cpu is i386 and the arch is PC/AT.

I used TARGET_PC98 for the meaning cpu is i386 and the arch is PC-98x1,
so I needed to change every defined(TARGET_I386) used for the meaning
the cpu is i386, to defined(TARGET_I386)||defined(TARGET_PC98).
I agree this is not good.

I suggest adding the definition TARGET_PCAT to divide theses meanings
so we can easily add none PC/AT machine with i386 cpu like PC-98x1.

For PC/AT:
	#define TARGET_I386
	#define TARGET_PCAT
For PC/AT x64:
	#define TARGET_I386
	#define TARGET_X86_64
	#define TARGET_PCAT
For PC-98x1:
	#define TARGET_I386
	#define TARGET_PC98

I will post the patch before repost PC-98x1 patch.


About A20 line gate:

In PC/AT arch, only A20 line is masked and when cpu is reseted it is not masked.
You know, In PC-98x1 arch, A20 and upper lines are masked and when cpu is reseted 
they are masked.

Now A20 gate is hard-corded in i386 core, but it is only PC/AT specifications
probably by external circuts, not cpu internal.
It may be possibly better to move a20 gate codes to pc.c and pc98.c,
but I think it is allowable to keep them in cpu core with #ifdef for each arch.

I want your comments.

Thanks,
TAKEDA, toshiya

Re: [Qemu-devel] Support NEC PC-98x1 on QEMU

[Alexander Graf]

On 08.09.2009, at 11:41, 武田 俊也 wrote:

> Dear Stuart,
>
>> There's no need to add this as a whole new architecture, although
>> perhaps the use of TARGET_PC98 was only meant to be temporary...
>
> The problem is that now TARGET_I386 is used for both 2 meanings,
> cpu is i386 and the arch is PC/AT.

No, that's what the -M switch is there for. Admittedly x86 has rather  
few machine descriptions, but PC-98 really is just a "non-PC/AT"  
machine, so it belongs there.

[...]

> About A20 line gate:
>
> In PC/AT arch, only A20 line is masked and when cpu is reseted it is  
> not masked.
> You know, In PC-98x1 arch, A20 and upper lines are masked and when  
> cpu is reseted
> they are masked.
>
> Now A20 gate is hard-corded in i386 core, but it is only PC/AT  
> specifications
> probably by external circuts, not cpu internal.
> It may be possibly better to move a20 gate codes to pc.c and pc98.c,
> but I think it is allowable to keep them in cpu core with #ifdef for  
> each arch.

Sounds like that should be a config variable in the CPU description,  
so you can set the default CPU be "486,+a20mask" or so.

In general, all the changes should be runtime variable dependent, so  
the same binary can run PC/AT and PC-98.

Alex

Re: [Qemu-devel] Support NEC PC-98x1 on QEMU

[Stuart Brady]

On Tue, Sep 08, 2009 at 04:36:04PM +0200, Alexander Graf wrote:
> 
> On 08.09.2009, at 11:41, 武田 俊也 wrote:
> 
> >The problem is that now TARGET_I386 is used for both 2 meanings,
> >cpu is i386 and the arch is PC/AT.
> 
> No, that's what the -M switch is there for. Admittedly x86 has rather  
> few machine descriptions, but PC-98 really is just a "non-PC/AT"  
> machine, so it belongs there.

I'd agree with this.

BTW, note that when TARGET_X86_64 is defined, TARGET_I386 is too!

(I'm really tempted to see how badly I would get flamed if I tried to
change 'TARGET_I386' to 'TARGET_X86', as i386 means '32-bit' to me...)

> >About A20 line gate:

[snip]

Ahh, makes a lot more sense now.

> Sounds like that should be a config variable in the CPU description,  
> so you can set the default CPU be "486,+a20mask" or so.

The 486 added an 'A20M' pin which removed the need for some of the
external circuitry for A20 gate handling.  (Also, there's 'fast a20 
gate' handling which seems to be entirely internal to the CPU...)
However, it sounds as though this only ever masks line A20, and not
any of the higher lines, so external circuitry would still be required
for the PC98 family.

So, strictly, this would depend on the chipset, and not the CPU, which
makes me wonder whether anyone would really need the option...

> In general, all the changes should be runtime variable dependent, so  
> the same binary can run PC/AT and PC-98.

Yeah, definitely...

For A20 handling, I suppose an extra member in CPUX86State is needed,
which would be initialised right after checking 'env' in pc_new_cpu()
and pc98_init1().

For the others, it's probably a matter of adding an extra member in the
device state struct and a corresponding parameter in the device init
function.

Allowing MAX_FD in fdc.c to be chosen at run-time might even be useful
for some other targets, too! :)

Cheers,
-- 
Stuart Brady

Re: [Qemu-devel] Support NEC PC-98x1 on QEMU

[武田 俊也]

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

Dear Alexander and Stuart,

Thank you very much for your comment.
I understand qemu implements rule and I agree with your opinion.

I modified my patch based on the codes received from git yesterday.
Please refer the attached archive.

-M pc98 and -M pc98pci are added to TARGET_I386.
-M isapc causes crash on windows now, and -M pc98 is same.
-M pc98pci is okay.

I added private_features to i386 for any features not defined in cpuid,
and I defined a20mask feature on it.

Thanks,
TAKEDA, toshiya

>On 08.09.2009, at 11:41, 武田 俊也 wrote:
>
>> Dear Stuart,
>>
>>> There's no need to add this as a whole new architecture, although
>>> perhaps the use of TARGET_PC98 was only meant to be temporary...
>>
>> The problem is that now TARGET_I386 is used for both 2 meanings,
>> cpu is i386 and the arch is PC/AT.
>
>No, that's what the -M switch is there for. Admittedly x86 has rather  
>few machine descriptions, but PC-98 really is just a "non-PC/AT"  
>machine, so it belongs there.
>
>[...]
>
>> About A20 line gate:
>>
>> In PC/AT arch, only A20 line is masked and when cpu is reseted it is  
>> not masked.
>> You know, In PC-98x1 arch, A20 and upper lines are masked and when  
>> cpu is reseted
>> they are masked.
>>
>> Now A20 gate is hard-corded in i386 core, but it is only PC/AT  
>> specifications
>> probably by external circuts, not cpu internal.
>> It may be possibly better to move a20 gate codes to pc.c and pc98.c,
>> but I think it is allowable to keep them in cpu core with #ifdef for  
>> each arch.
>
>Sounds like that should be a config variable in the CPU description,  
>so you can set the default CPU be "486,+a20mask" or so.
>
>In general, all the changes should be runtime variable dependent, so  
>the same binary can run PC/AT and PC-98.
>
>Alex
>
>
>

[-- Attachment #2: 20090909-pc9821.tar.gz --]
[-- Type: application/x-gzip, Size: 37351 bytes --]

Re: [Qemu-devel] Support NEC PC-98x1 on QEMU

[Alexander Graf]

On 09.09.2009, at 15:29, 武田 俊也 wrote:

> Dear Alexander and Stuart,
>
> Thank you very much for your comment.
> I understand qemu implements rule and I agree with your opinion.
>
> I modified my patch based on the codes received from git yesterday.
> Please refer the attached archive.

Two more things here:

1)

Don't top-post.

Write your reply directly below the text you're referring to. If  
you're not replying to something specific, just write it at the bottom.

That makes it easier to see when something is an answer to something  
different - and it's the way most (all?) open source mailing lists  
work ;-)

2)

Attaching as an archive is really bad for review. Usually I'd just  
comment on code in-line, meaning that I reply to the mail and write my  
comment below the source code line in question.

That doesn't work with attachments, which is why Stuart asked you to  
inline it, and hereby I do too.

As soon as you post an inline version, I'll give you some comments on  
the code :-).

Alex