What Needs to be done for a NeXT Emulator

Started by cjbriare, August 17, 2010, 01:34:34 am

Previous topic - Next topic

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.
Power management is enabled.

cuby

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

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.
Power management is enabled.

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 :)

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

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
--
Apple & NeXT

itomato

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! :D
-itomato

gilles

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

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.
--
Apple & NeXT

gilles

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

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

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

It build on MacOsX.

Need to add SDLmain.m and SDLmain.h from guiosx folder (blank template).
--
Apple & NeXT

gilles

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

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.
White Box running OPENSTEP 4.2
Dual Pentium III 550MHz | 320MB ECC SDRAM
Matrox Millenium II 8MB
SanDisk 2GB Compact Flash (CF-to-IDE)

andreas_g

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!