NeXT Computers

cjbriare · Joined: 09 Jul 2007 Posts: 71 Location: Las Vegas, NV

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 · Joined: 12 Jan 2006 Posts: 167 Location: Coburg, Germany

cjbriare · Joined: 09 Jul 2007 Posts: 71 Location: Las Vegas, NV

gilles · Joined: 03 Sep 2009 Posts: 117

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 Smile

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 · Joined: 02 Jan 2006 Posts: 79

itomato · Joined: 27 Dec 2005 Posts: 302 Location: Santa Cruz, CA

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! Very Happy

_________________
-itomato

gilles · Joined: 03 Sep 2009 Posts: 117

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

jvernet · Joined: 02 Jan 2006 Posts: 79

gilles · Joined: 03 Sep 2009 Posts: 117

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

gilles · Joined: 03 Sep 2009 Posts: 117

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).
_________________
http://previous.alternative-system.com
http://www.alternative-system.com/?lang=EN

gilles · Joined: 03 Sep 2009 Posts: 117

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.
_________________
http://previous.alternative-system.com
http://www.alternative-system.com/?lang=EN

jvernet · Joined: 02 Jan 2006 Posts: 79

It build on MacOsX.

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

gilles · Joined: 03 Sep 2009 Posts: 117

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

).
Shortcuts, menu and screen refresh are now handled.
For now crashes very early in POST just after a basic video RAM test.
_________________
http://previous.alternative-system.com
http://www.alternative-system.com/?lang=EN

ebann · Joined: 05 Sep 2010 Posts: 45

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 · Joined: 30 Jan 2009 Posts: 438 Location: Austria

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!