What Needs to be done for a NeXT Emulator

cjbriare · August 16, 2010, 07:34:34 PM

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.

cuby · August 17, 2010, 02:15:21 AM

Quote from: "cjbriare"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

cjbriare · August 17, 2010, 02:39:16 AM

Quote from: "cuby"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.

gilles · August 18, 2010, 07:03:10 AM

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.

jvernet · August 18, 2010, 07:25:40 AM

Quote from: "gilles"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

itomato · August 22, 2010, 03:21:26 PM

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!

gilles · August 23, 2010, 02:35:01 AM

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...

jvernet · August 23, 2010, 03:23:58 AM

Quote from: "gilles"
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.

gilles · August 30, 2010, 09:23:55 AM

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.

gilles · September 07, 2010, 04:30:47 AM

Still working from hatari sources.
Removed sound, most of video, fdd ,hdd, mfp, reworked memory.

I now have a 68040 + memory + VRAM + ROM trying to boot.
It should compile on linux, win32 and macos (as do hatari).

gilles · September 12, 2010, 01:10:04 AM

Put some files on the svn at sourceforge:
http://sourceforge.net/projects/previous/develop

For now it's just a very simplified version of hatari 1.4.0 with a basic next memory mapping.
Tested only under linux (ubuntu 10.04), but should be ok for win32 and macosx.

Everyone is welcome to join the project.

jvernet · September 14, 2010, 01:45:20 PM

It build on MacOsX.

Need to add SDLmain.m and SDLmain.h from guiosx folder (blank template).

gilles · September 16, 2010, 03:31:13 PM

revision 4 should be a bit more like an emulator, (I removed too much calls from original hatari code

).
Shortcuts, menu and screen refresh are now handled.
For now crashes very early in POST just after a basic video RAM test.

ebann · September 16, 2010, 07:14:08 PM

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.

andreas_g · September 16, 2010, 11:59:07 PM

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!