View previous topic :: View next topic |
Author |
Message |
cjbriare

Joined: 09 Jul 2007 Posts: 71 Location: Las Vegas, NV
|
Posted: Mon Aug 16, 2010 6:34 pm Post subject: What Needs to be done for a NeXT Emulator |
|
|
I'm just thinking out loud here, tell me what YOU think.
Im guessing any 68k (030 or 040) emulator would work...right?
you'd just need a good ROM dump...which may be the only thing that has kept a NeXT emulator nonexistent for so long. and which may or may not be legal.
Like if someone had developed a NS version of "CopyROM" so you could pull a ROM image off your old cube or slab.
I saw that NeXT emulator project posted here, but from the looks of it, it has a loooonggg way to go. _________________ Power management is enabled. |
|
Back to top |
|
 |
cuby

Joined: 12 Jan 2006 Posts: 167 Location: Coburg, Germany
|
Posted: Tue Aug 17, 2010 1:15 am Post subject: Re: What Needs to be done for a NeXT Emulator |
|
|
cjbriare wrote: | I'm just thinking out loud here, tell me what YOU think.
Im guessing any 68k (030 or 040) emulator would work...right?
you'd just need a good ROM dump...which may be the only thing that has kept a NeXT emulator nonexistent for so long. and which may or may not be legal.
Like if someone had developed a NS version of "CopyROM" so you could pull a ROM image off your old cube or slab.
I saw that NeXT emulator project posted here, but from the looks of it, it has a loooonggg way to go. |
Emulating the CPU is a solved problem, ROM dumps are readily available. Just a fair bit of reverse engineering of the NeXT chipset, peripheral components, interrupt structure, ... make that two or three man-years. Easy, isn't it?
-- Michael |
|
Back to top |
|
 |
cjbriare

Joined: 09 Jul 2007 Posts: 71 Location: Las Vegas, NV
|
Posted: Tue Aug 17, 2010 1:39 am Post subject: Re: What Needs to be done for a NeXT Emulator |
|
|
cuby wrote: | Easy, isn't it?  |
Easier said then done, that's for sure. haha
Well, i guess if that guy could do it for the Lisa, someone can do it for a NeXT. _________________ Power management is enabled. |
|
Back to top |
|
 |
gilles

Joined: 03 Sep 2009 Posts: 117
|
Posted: Wed Aug 18, 2010 6:03 am Post subject: |
|
|
I've worked a bit on it some time ago but I gave priority to some other projects (ie an emulator for an obscure french 8bit (& also a java emulator for another 8bit)).
I still want to emulate a Next and precisely a NextBus based machine.
I have somewhere something that is 0.001% of an emulator, it starts rom for 2 or 3 instructions, try to talk to nextbus... and dies
The most important information missing for now is to understand low level protocol with nextbus. After that, a precise memory mapping will be needed. |
|
Back to top |
|
 |
jvernet
Joined: 02 Jan 2006 Posts: 79
|
Posted: Wed Aug 18, 2010 6:25 am Post subject: |
|
|
gilles wrote: | I've worked a bit on it some time ago but I gave priority to some other projects (ie an emulator for an obscure french 8bit (& also a java emulator for another 8bit)).
I still want to emulate a Next and precisely a NextBus based machine.
I have somewhere something that is 0.001% of an emulator, it starts rom for 2 or 3 instructions, try to talk to nextbus... and dies
|
Eheh, welcome Gilles. Do you have a NeXSTation ?
Jerome _________________ --
Apple & NeXT |
|
Back to top |
|
 |
itomato

Joined: 27 Dec 2005 Posts: 302 Location: Santa Cruz, CA
|
Posted: Sun Aug 22, 2010 2:21 pm Post subject: |
|
|
I guess a lot depends on what direction you want to take, but in general, a major obstacle is documentation.
On that note, I can say I've delved into the MESS project a little more deeply, specifically trying to identify parts other machine drivers to graft onto the skeleton.
There are several subsystems where 'wheels' may have already been 'invented', or it appears that way on the surface; Floppy/Controller, Disk controller, Video, Network, CPU & DSP (common to Mac, Atari Falcon, etc.), ROM access, instruction execution methods, NuBus, ADB..
Based on what I've seen so far, there are many cases where implementation is dependent on Mac ROM calls, on custom chips (SWIM), or varying degrees of differences in chips, as with NCR vs. Symbios, YouNameIt vs. Brooktree, Crystal vs. 56K DSP, etc.
Identifying components and creating a matrix of the (OSS) pieces which exist elsewhere and are candidates for reuse is a personal milestone, and I think it helps define a development path for any emulator, not that I've ever done it!  _________________ -itomato |
|
Back to top |
|
 |
gilles

Joined: 03 Sep 2009 Posts: 117
|
Posted: Mon Aug 23, 2010 1:35 am Post subject: |
|
|
MESS is a great source of documentation, I think every emulator developper have at least mess sources on his hard drive.
I'm more looking into hatari/aranym/UAE sources for now, I want a stable 68040+MMU core.
Documentation is a real problem, but with time and tools most systems can be reversed.
first step will be:
_ derive hatari or aranym with basic memory mapping.
_ build a custom debugger.
Play, unassemble, comment...
Don't know how much time this will take... monthes, or years... _________________ http://previous.alternative-system.com
http://www.alternative-system.com/?lang=EN |
|
Back to top |
|
 |
jvernet
Joined: 02 Jan 2006 Posts: 79
|
Posted: Mon Aug 23, 2010 2:23 am Post subject: |
|
|
gilles wrote: |
Documentation is a real problem, but with time and tools most systems can be reversed.
first step will be:
_ derive hatari or aranym with basic memory mapping.
_ build a custom debugger.
|
Hatari have a full featured debugger, even for DSP. _________________ --
Apple & NeXT |
|
Back to top |
|
 |
gilles

Joined: 03 Sep 2009 Posts: 117
|
Posted: Mon Aug 30, 2010 8:23 am Post subject: |
|
|
Debugger for hatari only start on WIN32 if you activate some startup option (ie call debugger on exception).
Hatari is great and already multi platform, but it's much more linux friendly than win32... so I'm now migrating (once more) to ubuntu on a new machine.
I'll start to fork and remove atari stuff this week. _________________ http://previous.alternative-system.com
http://www.alternative-system.com/?lang=EN |
|
Back to top |
|
 |
gilles

Joined: 03 Sep 2009 Posts: 117
|
|
Back to top |
|
 |
gilles

Joined: 03 Sep 2009 Posts: 117
|
|
Back to top |
|
 |
jvernet
Joined: 02 Jan 2006 Posts: 79
|
Posted: Tue Sep 14, 2010 12:45 pm Post subject: |
|
|
It build on MacOsX.
Need to add SDLmain.m and SDLmain.h from guiosx folder (blank template). _________________ --
Apple & NeXT |
|
Back to top |
|
 |
gilles

Joined: 03 Sep 2009 Posts: 117
|
|
Back to top |
|
 |
ebann

Joined: 05 Sep 2010 Posts: 45
|
Posted: Thu Sep 16, 2010 6:14 pm Post subject: |
|
|
What the OP was seeking is a 680x0 computer virtualization much like VMware and VirtualBox? Why would a 680x0 emulator running NS/OS be any different than an x86 emulator running NS/OS? For one, an x86 emulator could run in native mode on Intel platform.
If this is the case, it's still an interesting project. |
|
Back to top |
|
 |
andreas_g

Joined: 30 Jan 2009 Posts: 448 Location: Austria
|
Posted: Thu Sep 16, 2010 10:59 pm Post subject: |
|
|
Running NeXTStep on a NeXT hardware emulator (68k processor) gives you some advantages over x86 hardware emulation/virtualization:
There is some important software, that was never ported to x86. The only way to run this software is a NeXT emulator.
With such an emulator you may also be able to run NeXTStep versions 1.x and 2.x.
It is also an advantage to not depend on software like VMware and VirtualBox as they don't officialy support NeXTStep and compatibility may get broken over time.
The only disadvantage may be a loss of speed compared to x86 virtualization. But as computers are getting faster from year to year this issue is not a real problem.
It is great to see progress on this project! |
|
Back to top |
|
 |
|