qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stuart Brady
Subject: Re: [Qemu-devel] Support NEC PC-98x1 on QEMU
Date: Tue, 8 Sep 2009 23:37:34 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]