NeXT Computers

NeXT Computer, Inc. => Emulation / Virtualization => Topic started by: cjbriare on August 17, 2010, 01:34:34 am

Title: What Needs to be done for a NeXT Emulator
Post by: cjbriare on August 17, 2010, 01:34:34 am
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.
Title: Re: What Needs to be done for a NeXT Emulator
Post by: cuby on August 17, 2010, 08: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
Title: Re: What Needs to be done for a NeXT Emulator
Post by: cjbriare on August 17, 2010, 08: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.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on August 18, 2010, 01:03:10 pm
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.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on August 18, 2010, 01:25:40 pm
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
Title: What Needs to be done for a NeXT Emulator
Post by: itomato on August 22, 2010, 09: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! :D
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on August 23, 2010, 08: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...
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on August 23, 2010, 09: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.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on August 30, 2010, 03:23:55 pm
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.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 07, 2010, 10: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).
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 12, 2010, 07: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.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on September 14, 2010, 07:45:20 pm
It build on MacOsX.

Need to add SDLmain.m and SDLmain.h from guiosx folder (blank template).
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 16, 2010, 09: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.
Title: What Needs to be done for a NeXT Emulator
Post by: ebann on September 17, 2010, 01:14:08 am
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.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on September 17, 2010, 05:59:07 am
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!
Title: What Needs to be done for a NeXT Emulator
Post by: bkmoore on September 17, 2010, 06:12:56 am
Another advantage of an open-source M68K emulator is it could be ported to older PPC Macs which have no good x86 options for NeXT emulation.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 17, 2010, 08:11:37 am
Probably QEMU would be a good platform to run next68k but a real emulator is a necessary step. Many hardware registers are not documented, in particular the DMA chip. The only partial informations I found are in netBSD sources but comments are a bit short :).

Emulator is now blocked in some rtc chip reading or config. I found a similar code in netBSD rtc.c source.

In very early POST, the stack resides at the end of video RAM in $0B0307xx
Title: What Needs to be done for a NeXT Emulator
Post by: ebann on September 17, 2010, 11:02:26 am
I think that progress would be much faster if you used Basilisk II source code as your base.

http://basilisk.cebix.net/

It uses the UAE 68k CPU emulator engine and the source code is very very modular.

- UAE CPU engine ("uae_cpu/*", not needed on all systems)
- ROM patches ("rom_patches.cpp", "slot_rom.cpp" and "emul_op.cpp")
- resource patches ("rsrc_patches.cpp" and "emul_op.cpp")
- PRAM Utilities replacement ("xpram.cpp")
- ADB Manager replacement ("adb.cpp")
- Time Manager replacement ("timer.cpp")
- SCSI Manager replacement ("scsi.cpp")
- video driver ("video.cpp")
- audio component ("audio.cpp")
- floppy driver ("sony.cpp")
- disk driver ("disk.cpp")
- CD-ROM driver ("cdrom.cpp")
- external file system ("extfs.cpp")
- serial drivers ("serial.cpp")
- Ethernet driver ("ether.cpp")
- system-dependant device access ("sys_*.cpp")
- user interface strings ("user_strings.cpp")
- preferences management ("prefs.cpp" and "prefs_editor_*.cpp")

Basilisk II has been ported to the following systems:

Unix with X11 (Linux i386/x86_64, Solaris 2.5, FreeBSD 3.x, IRIX 6.5)
Mac OS X (PowerPC and Intel)
Windows NT/2000/XP
BeOS R4 (PowerPC and Intel)
AmigaOS 3.x

You can immensely simplify the code by eliminating the diverse types of emulator modes:

"Basilisk II is designed to run on many different hardware platforms and on
many different operating systems. To provide optimal performance under all
environments, it can run in four different modes, depending on the features
of the underlying environment (the modes are selected with the REAL_ADDRESSING,
DIRECT_ADDRESSING and EMULATED_68K defines in "sysdeps.h")"
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 17, 2010, 11:29:34 am
Basilisk is a good emulator but it uses an old variant of uae without real support of MMU (at least it was the case last time I read the code).
An atari TT is much close to a next than a mac, MMU is used by system.
hatari/aranym is a good base for now, to explore the POST rom, it was not too difficult to remove items but it may be a bit limited for timed events (centered on video/cpu/mfp).

For now, the real time clock must be added...
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 17, 2010, 12:52:41 pm
after reading Basilisk code ;)
MMU support seems limited to mac with some black magic :

void REGPARAM2 frame_host_565_lput(uaecptr addr, uae_u32 l)
{
   uae_u32 *m;
   m = (uae_u32 *)(FrameBaseDiff + addr);
   l = (l & 0x001f001f) | ((l << 1) & 0xffc0ffc0);
   *m = swap_words(l);
}

but I agree the code is clear and easy to navigate while hatari is more demo-coder oriented ;)
[edit]
the code sample is a bit wrong, this is videoram access, MMU is not emulated by Basilisk that is limited to a 68020 CPU with a flat 32bit memory model
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on September 20, 2010, 09:41:27 am
Is there somewhere documentation about NeXT harware ? Something else and more detailled than schematics that can be found ?

I took a look in my NeXT Archive DVDs but can find anything interesting wich may help Gilles....

Wee ned a Technical Specifications Manual....

Edit
Seems that there is some information form NeXT, see here  (http://nextstuff.info/db/ByManufacturer/NeXT%20Computer,%20Inc.)

A lot of link are dead, now, like peak, channelu... :( Somes mirros: http://nextstuff.info/
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 20, 2010, 02:10:29 pm
in particular we need information about System control registers 1 & 2 that resides in x0200Cxxx and x0200Dxxx

SCR2 should be real time clock.

We have datasheets of the clock component (at least the old 68HC68T1) but don't know how it is connected to next (access to component are serial).
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 20, 2010, 03:38:01 pm
found this interesting message of monitor in some doc:

Memory Configurations  -  m
---------------------
The  m  command displays information on the memory installed in sockets 0
through 15 (the original NeXT had 16 RAM slots).  The output should be
something like this:

NeXT>m
Memory sockets 0-3 have 4MB page mode SIMMs installed (0x4000000-0x4400000)
Memory sockets 4-7 have 4MB page mode SIMMs installed (0x5000000-0x53fe000)
Memory sockets 8-11 have no SIMMS installed (0x0-0x0)
Memory sockets 12-15 have no SIMMS installed (0x0-0x0)
NeXT>

=> may means that a part of RAM is used for something else, maybe to shadow a part of the ROM?
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 20, 2010, 08:13:42 pm
good news, some information seems correct.

you need to force the boot, otherwise it goes in an endless loop (soft power off?)

r A7=$0B03F7C4
r PC=$01004956

first screenshot :

(http://img411.imageshack.us/i/firstboot.png/)

I'll update svn sources soon
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on September 20, 2010, 08:21:47 pm
clapclapclap !

:D
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 20, 2010, 09:05:12 pm
fixed display details:

(http://img192.imageshack.us/i/bootbis.png/)

(now my laptop screen is not large enough)
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 20, 2010, 10:44:30 pm
svn is updated.
To see the boot screen, you need the Rev2.6_v66.BIN file.
When screen gets scrambled (this pattern may be a video ram test),
type rightAlt + Pause
then in debugger
r A7=$0B03F7C4
r PC=$01004956

(it bypasses a test in ROM)

There is probably a ROM checksum, so cannot patch binary for now...
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 21, 2010, 06:48:10 pm
think I understood how RTC is connected.
RTC is accessed with 2 bit write and 1 bit read from 32bit register SCR2.
to write you need to set data then loop clock with a delay
a write is 2 byte write, register then value
a read is a write for register then a read of value
maybe newer chip have a burst read mode.

netBSD sources are clear when you take them with the right angle :)
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on September 21, 2010, 08:24:33 pm
A little step more ! Nice Job !

I was able to build Previous on MacOsX. Still no debugger yet, need to change Alt-PAUSE to Alt-anythingelse. It should work, but no way....

Gilles really need help !  :D
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 21, 2010, 08:39:58 pm
in configuration.c file:
   ConfigureParams.Shortcut.withModifier[SHORTCUT_DEBUG] = SDLK_PAUSE;

change to another key more macosX friendly...  (PAUSE/F16 seems problematic)
Title: What Needs to be done for a NeXT Emulator
Post by: cuby on September 22, 2010, 02:21:08 am
Quote from: "gilles"
r A7=$0B03F7C4
r PC=$01004956

(it bypasses a test in ROM)


Do you know at which test the ROM actually hangs - is this the RTC you mention in this thread? The code address where the ROM hangs seems to be 0x1002556...

QuoteThere is probably a ROM checksum, so cannot patch binary for now...


There is a checksum, described here:

http://nextcomputers.org/forums/viewtopic.php?t=11&highlight=checksum

However, this only seems to protect the first 22 bytes of the ROM containing the MAC address. So maybe there is still another checksum hidden somewhere?

But, of course, properly emulation the device in question (at least as far as the test is concerned) would be the better approach...

-- Michael
Title: What Needs to be done for a NeXT Emulator
Post by: cuby on September 22, 2010, 04:58:46 am
Soo, I did a lot of disassembling and a little experiment.

The code where the ROM hangs (and where we have to adjust SP and PC to continue) is a function that blinks the error LED (verified on a NeXT here, bit 0 in SCR2 controls it). It's an endless loop (function begins at 0x0100253a, jmp instruction at 0x0100258e jumps back to the beginning and no instruction leaves this loop. No wonder we can't continue from there :-).

So, something must fail before. Perhaps some kind of platform/hardware test? (CPU type, frequency, memory... whatever)
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on September 22, 2010, 07:44:00 am
Quote from: "gilles"in configuration.c file:
   ConfigureParams.Shortcut.withModifier[SHORTCUT_DEBUG] = SDLK_PAUSE;

change to another key more macosX friendly...  (PAUSE/F16 seems problematic)


That's what I did. Doesn't work  :twisted:. There is some test hardcoded elsewhere.
So, I will add to the MacOsX GUI a DebugUI() menuitem. Work fine in Hatari.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 22, 2010, 07:59:16 am
Quote from: "cuby"Soo, I did a lot of disassembling and a little experiment.

The code where the ROM hangs (and where we have to adjust SP and PC to continue) is a function that blinks the error LED (verified on a NeXT here, bit 0 in SCR2 controls it). It's an endless loop (function begins at 0x0100253a, jmp instruction at 0x0100258e jumps back to the beginning and no instruction leaves this loop. No wonder we can't continue from there :-).

So, something must fail before. Perhaps some kind of platform/hardware test? (CPU type, frequency, memory... whatever)


I added SCR1 support with fixed values from jvernet machine. Now the machine is detected as a next station and hangs... somewhere else :)
Can someone give me good values of SCR1 for a 8mb mono 25MHz?

I also added RTC access support, I see that ROM reads the 32 registers (00 to 1F). Tries to set register 0 (0x80) . Read register 0 again and hangs. It may be normal since I do not store values in RTC RAM.

The version of the rom I used for tests is v66.

@jerome, maybe the hatari configuration file is used and bypasses the default configuration, try to rename hatari.cfg/previous.cfg files.

[edit]
also, for checksum... things may be a bit more complex than this expected, It seems that a part of the EPROM is overlaid by RAM.
According to netBSD includes, LSB of SCR2 is the flag for overlay (since netbsd does not use this flag, I suppose they add access to next hardware documents :) )
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 22, 2010, 09:31:03 am
it was RTC ram registers :)
now it does not need the patch anymore...
but I need to add RTC_STATUS support I think.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 22, 2010, 12:53:05 pm
updated svn (Rev 6), now go to Testing screen without dead loop error (& flashing LED).
Title: What Needs to be done for a NeXT Emulator
Post by: ebann on September 22, 2010, 01:21:49 pm
You guys rock!  I would love to help but emulation/virtualization is not my thing... biggest thing I ever tackled was writing a C to Sparc assembly compiler.  Where would one find a simple emulation tutorial... a 6502 CPU would rock as I grew up with that :-)
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on September 22, 2010, 03:33:05 pm
Working!

Playing with SCR1 (change SR1 Read2 value from &h5F to &h2F, for example, and the Testing Windows show a Cube. 1F show a Slab, 03F hang Previous (goes to debuger), etc...
Title: What Needs to be done for a NeXT Emulator
Post by: cuby on September 22, 2010, 04:21:55 pm
Quote from: "ebann"a 6502 CPU would rock as I grew up with that :-)


Hehe, then you should take a look at this: http://www.visual6502.org/JSSim/index.html - 6502 CPU emulation at transistor level. Extremely cool IMHO!
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 22, 2010, 06:58:59 pm
great simulator :)
cannot try because it crashes my browser but seems real impressive.
Title: What Needs to be done for a NeXT Emulator
Post by: ebann on September 22, 2010, 07:31:29 pm
Quote from: "cuby"
Quote from: "ebann"a 6502 CPU would rock as I grew up with that :-)


Hehe, then you should take a look at this: http://www.visual6502.org/JSSim/index.html - 6502 CPU emulation at transistor level. Extremely cool IMHO!


You guys must be EE majors to be enjoying this kind of crazy stuff!  :shock:
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 22, 2010, 08:10:06 pm
to be precise : http://www.diic.fr/jahia/Jahia/pid/340
but it was 15 years ago :)
problem is that in France, you will probably not find a job directly related to such studies... well, business data processing is not that bad... & it pays your bills...
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on September 22, 2010, 08:56:58 pm
Quote from: "gilles"to be precise : http://www.diic.fr/jahia/Jahia/pid/340
but it was 15 years ago :)
problem is that in France, you will probably not find a job directly related to such studies... well, business data processing is not that bad... & it pays your bills...


;)

Back to Previous.  :oops:

How can we read values inside the NSLab Clock Chip (let's call it NVRAM, it store what you can define in the ROM Monitor).

And what are the meaning of these values ? They are important in the test boot phase... Among other things that Gilles need.
Title: What Needs to be done for a NeXT Emulator
Post by: itomato on September 22, 2010, 09:21:25 pm
Wow - this is very cool!

I'm incredibly impressed at the rate of progress!  Go, Gilles!! :o
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 22, 2010, 09:52:30 pm
most of the progress is in fact from UAE team for much better support of 68040.
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on September 23, 2010, 10:35:42 am
I'm very excited to see this.  Keep up the work, guys - I really would love to see a m68k NeXT emulator!
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 27, 2010, 09:00:22 am
Did not find what causes the deadloop for now, but I also had to switch for some days to another project (something a bit different, production statistics for Milkers :) ).
It may be DMA related or somthing wrong in BMAP registers...
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 30, 2010, 12:32:59 pm
It seems the RAM is not supposed to raise a bus error if you are in the correct range 0x04000000 0x05FFFFFF (because at this stage, bus error vector is not correct and ramsize is checked).

I now have 2 strange memory access to 0x06000000 and 0x07000000
Does anyone know what is mapped here? maybe some short internal registers?
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 05, 2010, 04:12:07 pm
more tests...
0x06000000 and 0x07000000 may be RAM banks on original Cube but I do not know exactly why it is tested in v66 BIOS.
I now have a problem with 0x02007000 that should be some global interruption register.
I've played a bit with debugger and could reach the "internal tests failed"
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 12, 2010, 10:37:14 am
update SVN sources, now go to a plain "system test failed" message.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 12, 2010, 07:36:21 pm
The MacOsX Snow Leopard build is here:

http://perso.orange.fr/jerome.vernet/Softs/previousbin.zip

Gilles need help  !!
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on October 12, 2010, 08:39:07 pm
Quote from: "jvernet"The MacOsX Snow Leopard build is here:

http://perso.orange.fr/jerome.vernet/Softs/previousbin.zip

Gilles need help  !!


Gilles, how do we use this?  Nothing happens when I run "previous" from that archive.
Title: What Needs to be done for a NeXT Emulator
Post by: itomato on October 13, 2010, 01:49:09 am
I get:

dyld: Library not loaded: /sw/lib/libpng12.0.dylib
 Referenced from: /Users/*********/Downloads/previousbin/previous
 Reason: image not found
Trace/BPT trap
logout


I don't have a '/sw' directory, and setting my LD_LIBRARY_PATH did nothing.

I have VLC installed, so I used that version of libpng.


mkdir -p /sw/lib
cp -aR /Applications/VLC.app/Contents/MacOS/lib/libpng12.0.dylib /sw/lib/
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on October 13, 2010, 06:26:47 am
@eagle and itomato:

To run the binary from jvernet you need these two things:

1. Create the directory "/sw/lib" and copy libpng12.0.dylib to that directory:

cd /
mkdir sw
cd sw
mkdir lib
cp /usr/X11/lib/libpng12.0.dylib /sw/lib


2. Copy the SDL Framework to the appropriate directory:

I assume your "previous"-binary is in the folder "previousbin" in the folder "x" --> "x/previousbin/previous"

Now you have to go the folder "x" and create the folder "Frameworks". Copy the SDL.framework (which you can get here: http://www.libsdl.org/release/SDL-1.2.14.dmg) to that folder --> "x/Frameworks/SDL.framework"

Now you can launch previous:
Go to the folder that contains the "previous"-binary and launch it:
./previous
@gilles:
Great work!

@jvernet:
Thanks for making this binary available to us!
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on October 13, 2010, 11:13:53 am
Andreas, thanks for the instructions.

Gilles, neat!!!!  Keep up the good work.  I can't wait to see a NeXT hardware emulator!
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 13, 2010, 11:22:04 am
I really need to make a working package for MacOsX. As, for the moment, previous do not do a lot of thing...

Gilles, can you rememember here what do you need for people who have a Cube or NSLab mono in v66 ROM ?

I do not have any v66 system here, and my Mono Turbo (v72) do not work right now...
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 13, 2010, 11:29:34 am
mostly I need precise SCR1 and SCR2 values from a working mono 8mb (it can be a 040 cube or a station). I know SCR2 values are not constants but some bits are.
Also, if possible, I need the real time clock RAM value from a working mono, there is probably a checksum somewhere.
v66 ROM is better, but any mono eprom should be ok.
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on October 13, 2010, 11:50:04 am
I'm not sure what version my systems are, but they are all mono non-turbo systems.  I have a prototype Cube with 3 motherboards (030, 040-25, 040-25), and two stations with 040-25 motherboards.  If you tell me what you need and how to get it, I'll do what I can to get it for you.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 14, 2010, 07:46:13 am
the 040 stations are probably more close to the actual state of the emulator.
We need somthing like a low level monitor that can read/write/display specific physical memory addresses.
I do not have a next station yet, I just work from documents.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 14, 2010, 07:35:02 pm
Quote from: "eagle"I'm not sure what version my systems are, but they are all mono non-turbo systems.  I have a prototype Cube with 3 motherboards (030, 040-25, 040-25), and two stations with 040-25 motherboards.  If you tell me what you need and how to get it, I'll do what I can to get it for you.


You can use the NeXT monitor (cmd+~ at boot) to display these registers.

Jerome
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on October 14, 2010, 08:01:33 pm
OK, let me know how to do it and I'll see if I can get one of my systems configured over the weekend.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on October 14, 2010, 08:32:13 pm
@eagle and everyone who wants to help:

This document discribes the details on how to obtain the values from the SCR1 and SCR2 registers via the ROM monitor (need them for the project):

http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/OperatingSystem/Part2_WritingLKSs/_ApB_ROM/ROM.htmld/index.html

After turning your computer on, immediately when the "loading from disk" message appears (max 3 seconds), you hold down "cmd" and "~", like jvernet already told.

QuoteWithin three seconds of the appearance of the message "Loading from disk" or "Loading from network," hold down the Command and left Alternate keys and press the ~ key.  (If you're using a keyboard that has two Command keys, don't hold down the Alternate key; just hold down one of the Command keys and press the ~ key.)


This brings you to the ROM monitor. Within the monitor you simply type "s" and then the values for the system registers show up.

QuoteOpen System Register

The command

s [systemreg]

accesses the contents of the system registers.  Possible values for systemreg are:

intrstat   Interrupt status register
intrmask   Interrupt mask register
scr1   System control register #1
scr2   System control register #2
If you don't specify systemreg, all of the system registers are opened in the order they're listed above.


After that, you type "m" which shows your memory configuration.

QuoteYou can display information about system memory configuration by entering the command m. This command displays information about the memory installed in memory sockets 0 through 15.

The output from the m command will be something like this:
Memory sockets 0 and 1 (front) have 8MB of page mode SIMMs installed
(0x4000000-0x47fe000)
Memory sockets 0 and 1 (back) have no SIMMs installed (0x0-0x0)
Memory sockets 2 and 3 (front) have no SIMMs installed (0x0-0x0)
Memory sockets 2 and 1 (back) have no SIMMs installed (0x0-0x0)

The ROM monitor reserves some space in the last SIMM to store its internal information.

(quoted from this document: http://www.cilinder.be/docs/next/NeXTStep/3.3/nsa/09_StartShut.htmld/index.html)

Please post these values (system register values and memory configuration) together with your system's specifications.

The prefered machine would be a non-turbe monochrome NeXTstation with ROM 2.5 v66 and 8 MB RAM, but i think the more values from different machines we get, the better it is!
I hope my instructions work. If you have any questions, just ask.
Title: What Needs to be done for a NeXT Emulator
Post by: bkmoore on October 14, 2010, 08:50:41 pm
My system is a non-turbo Color Slab. When I do andreas_g's instructions I get:



CPU MC68040 25 MHz , memory 100 ns
Backplane slot #0
Ethernet address: 0:0:f:0:f8:f6
Memory size 32MB

NeXT>s
intrstat: 00002000<optical>?
intrmask: 80027640<NMI,scc,rtc,optical,scsi,enetTX,enetRX,dsp>?
scr1: 00013002<sid=0,DMArev=1,CPUrev=30,vmss=0,mmss=0,cmss=2>?
scr2: 00000c80<DSPreset,mem256K/4M=0,mem1M/4M=0,ROMwait=0,rtdata>?
NeXT>m
Memory sockets 0 and 1 have 8MB of page mode SIMMs installed (0x4000000-0x4800000)
Memory sockets 0 and 1 have 8MB of page mode SIMMs installed (0x4800000-0x5000000)
Memory sockets 0 and 1 have 8MB of page mode SIMMs installed (0x5000000-0x5800000)
Memory sockets 0 and 1 have 8MB of page mode SIMMs installed (0x5800000-0x5ffe000)
NeXT>


I don't know if any of this is useful because you are trying to emulate a mono slab. But I'm glad to be of help if it is.

Brian
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 15, 2010, 09:35:48 am
with this value (ie CPU Rev = 0x30) the emulator crashes very early with rom V66. So it is an information but does not help right now.
With a little modification of 0x06000000 and 0x07000000 I could have correct values written back to RTC ram. But it crashes soon after with a memory fault.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 15, 2010, 08:08:08 pm
Is there somewhere a little app that can read inside the RTC of a NSLAB ?

There is some parameters (32Bytes) that may be useful for Gilles....

I will take some time tomorow to read more values from my Turbo color and try again to boot up my Turbo Mono. No mono right here at least two month.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 16, 2010, 07:57:36 am
here is what I have:

NeXT>m
Memory sockets 0 and 1 (front) have 32MB of page mode SIMMs installed (0x4000000-0x6000000)
Memory sockets 0 and 1 (back) have 32MB of page mode SIMMs installed (0x6000000-0x8000000)
Memory sockets 2 and 3 (front) have 32MB of page mode SIMMs installed (0x8000000-0xa0000000)
Memory sockets 2 and 3 have 32MB of page mode SIMMs installed (0xa0000000-0xbff0000)
NeXT>



In 0x6000000, I have 01020304 as value. In 0x7000000, I have 00000000
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 16, 2010, 02:54:13 pm
ok, I start to understand the memory map...
there may have 4 banks but only 2 physically. Each side of a memory module is independant (front and back).
So the memory size I have implemented may not be valid :)
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 16, 2010, 03:16:29 pm
My turbo color have 4 DIMM of 32M each, 2 sides.
Title: What Needs to be done for a NeXT Emulator
Post by: bkmoore on October 16, 2010, 05:14:59 pm
The mono b&w slab had eight memory slots for 60 pin SIMM. You could put in up to 32 MB. I have no idea how the slots are arranged. Maybe someone with a non-turbo b&w slab could post.

My non-turbo color slab also has eight memory slots, they are for 72 pin DIMMs. They are paired up, so you have to use two identical parts per pair. But it can use only up to 4 MB parts (four x pair of 4 MB), so the max memory remains at 32 MB.

The Turbo slabs had four slots for 72 pin DIMMS and could take up to 32 MB each allowing a maximum memory of 128 MB.

I don't know if this helps, you probably already know this. But I post it any way so my other post makes more sense.

Brian
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 20, 2010, 07:30:50 am
I'm now using the provided 8Mb RAM map that seems ok.
System tests still fail with access to 0200e00x

IO read at $0200e002 PC=$01008e54
IO write at $0200e002 val=02 PC=$01008e54
IO write at $0200e003 val=c5 PC=$01008e54
IO write at $0200e004 val=ef PC=$01008e54
IO read at $0200e002 PC=$01008e26
IO read at $0200e005 PC=$01008e26
IO write at $0200e003 val=c5 PC=$01008e54
IO write at $0200e004 val=00 PC=$01008e54
IO read at $0200e002 PC=$01008e26
IO read at $0200e005 PC=$01008e26
IO write at $0200e003 val=c5 PC=$01008e54
IO write at $0200e004 val=00 PC=$01008e54
IO read at $0200e002 PC=$01008e26
IO read at $0200e005 PC=$01008e26
IO write at $0200e003 val=c6 PC=$01008e54
IO write at $0200e004 val=01 PC=$01008e54

I suppose it is keyboard access but netbsd does not use 0200e004 and 0200e005
netbsd define 3 long registers here
struct mon_regs {
   u_int32_t mon_csr;
   u_int32_t mon_1;
   u_int32_t mon_data;
};

but mon_1 is never used. So I do not know exactly what the rom is trying to do :)
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on October 20, 2010, 10:48:23 am
Sorry I haven't been able to get the info yet... I have 3 NeXTs and I'm hoping to be able to pull them out of the closet today.  I'll let you know what I find out.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 20, 2010, 12:14:55 pm
Quote from: "gilles"
I suppose it is keyboard access but netbsd does not use 0200e004 and 0200e005
netbsd define 3 long registers here
struct mon_regs {
   u_int32_t mon_csr;
   u_int32_t mon_1;
   u_int32_t mon_data;
};



mon, as monitor ? May be something related to the kind of screen connected to the NeXT ?
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 21, 2010, 04:49:14 pm
maybe mon because monitor and keyboard/mouse use the same port.
Don't know exactly what is the second register mon_1... maybe netbsd's driver coder didn't know much about this register... (unused, generic name)
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 22, 2010, 09:26:26 am
tested with a full 64Mb memory, RTC memory is written with some values:

SCR2 RTC command complete 0 0 94 at PC=$01007842
SCR2 RTC command complete 1 0 f at PC=$01007842
SCR2 RTC command complete 2 0 40 at PC=$01007842
SCR2 RTC command complete 3 0 0 at PC=$01007842
SCR2 RTC command complete 4 0 0 at PC=$01007842
SCR2 RTC command complete 5 0 0 at PC=$01007842
SCR2 RTC command complete 6 0 0 at PC=$01007842
SCR2 RTC command complete 7 0 0 at PC=$01007842
SCR2 RTC command complete 8 0 0 at PC=$01007842
SCR2 RTC command complete 9 0 0 at PC=$01007842
SCR2 RTC command complete a 0 fb at PC=$01007842
SCR2 RTC command complete b 0 6d at PC=$01007842
SCR2 RTC command complete c 0 0 at PC=$01007842
SCR2 RTC command complete d 0 0 at PC=$01007842
SCR2 RTC command complete e 0 11 at PC=$01007842
SCR2 RTC command complete f 0 0 at PC=$01007842
SCR2 RTC command complete 10 0 41 at PC=$01007842
SCR2 RTC command complete 11 0 0 at PC=$01007842
SCR2 RTC command complete 12 0 65 at PC=$01007842
SCR2 RTC command complete 13 0 6e at PC=$01007842
SCR2 RTC command complete 14 0 0 at PC=$01007842
SCR2 RTC command complete 15 0 0 at PC=$01007842
SCR2 RTC command complete 16 0 0 at PC=$01007842
SCR2 RTC command complete 17 0 0 at PC=$01007842
SCR2 RTC command complete 18 0 0 at PC=$01007842
SCR2 RTC command complete 19 0 0 at PC=$01007842
SCR2 RTC command complete 1a 0 0 at PC=$01007842
SCR2 RTC command complete 1b 0 0 at PC=$01007842
SCR2 RTC command complete 1c 0 0 at PC=$01007842
SCR2 RTC command complete 1d 0 0 at PC=$01007842
SCR2 RTC command complete 1e 0 79 at PC=$01007842
SCR2 RTC command complete 1f 0 13 at PC=$01007842

but tests still fail after (SCR1 read).
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 26, 2010, 03:39:39 pm
with the correct structure, the decoded info is
Rtc info:
RTC RESET:x9 ALLOW_EJECT
VOL_R:x0 BRIGHT:x3D HWPWD:x0 VOL_L:x0
NVRAM_HW_PASSWD: 0  0  0  0  0  0
SIMM:F B 6 D
ADOBE: 0  0
POT:11  0 41
console_slot:0
boot_command:en
CKSUM:79 13

SIMM values probed seems bad, maybe SCR2 should set correct bits when memory is accessed.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 26, 2010, 09:48:03 pm
I found checksum control in rom,
checksum should be (in C).
   sum=0;
   for (i=0;i<30;i+=2) {
      sum+=(rtc_ram<<8)|(rtc_ram[i+1]);
      if (sum>=0x10000) { sum-=0x10000;
         sum+=1;
      }
   }

   sum=0xFFFF-sum;

It's a bit strange but it works...

now I force this value in RTC_RAM to bring monitor
Uint8 rtc_ram[32]={
0x94,0x0f,0x40,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0xfb,0x6d,0x00,0x00,0x7B,0x00,
0x41,0x00,0x65,0x6e,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x0F,0x13
};

and we have something interesting :)

(http://img87.imageshack.us/i/captureprevious01.png/)

Uploaded with ImageShack.us (http://imageshack.us)
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 27, 2010, 11:20:55 am
Yeah !!!!

:D

You have to find a way to go in monitor mode before the ethernet boot. Keyboard do not work, i think...

Of course, the only link google show for error is dead:

http://www.channelu.com/NeXT/NeXTStep/3.3/nsa/ApE_Errors.htmld/index.html

Is there some mirrors of channelu somewhere ?
Title: APE Codes
Post by: GrafZahl on October 27, 2010, 03:08:02 pm
The site has been archived by the web archive.

The codes are available here:

http://web.archive.org/web/20061017182824/http://www.channelu.com/NeXT/NeXTStep/3.3/nsa/ApE_Errors.htmld/index.html
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on October 27, 2010, 04:55:01 pm
Gilles, thank you for the update! Great work!

I have another link to the error listing (just in case the above link to the archived page fails some time):

http://www.cilinder.be/docs/next/NeXTStep/3.3/nsa/ApE_Errors.htmld/index.html

There you can look up the meanings of all possible errors. In this case we have:
QuoteError code 41: FPU data registers are faulty.


You can also find this document within NeXTstep 3.x in the directory "/NextLibrary/Documentation/NextAdmin"
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 27, 2010, 08:10:59 pm
Nice ! So error 41 is an FPU error.
Title: What Needs to be done for a NeXT Emulator
Post by: oneNeXT on October 27, 2010, 09:00:43 pm
Here is the result for a 20MB mono station:



CPU MC68040 25 MHz memory 100 nS
Backplane slot #0
Ethernet address:
Memory size 20MB

NeXT>s
intrstat: 00000020<video>?
intrmask: 88027640<NMI,enetRXDMA,scc,rtc,optical,scsi,enetTX,enetRX,dsp>?
scr1: 00011102<sid=0,DMArev=1,CPUrev=11,vmss=0,mmss=0,ccms=2>?
scr2: 00ff0c80<DSPreset,mem256K/4M=f,mem1M/4M=f,ROMwait=0,rtdata>?
NeXT>s
Memory sockets 0-3 have 16MB page mode SIMMs installed (0x4000000-0x5000000)
Memory sockets 4-7 have 4MB page mode SIMMs installed (0x5000000-0x53fe000)
Memory sockets 8-11 have no SIMMs installed (0x0-0x0)
Memory sockets 12-15 have no SIMMs installed (0x0-0x0)


If you really need a 8MB station, i think than a I can find it
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on October 27, 2010, 09:47:05 pm
these values are interesting, I get a crash but with memory configuration errors.
When in monitor, RTC registers may be somewhere in video memory (because initial stack is at the end of video memory). If your rom version is V66 I can find the correct address (If other rom version it will take a little more time).
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on October 30, 2010, 02:24:53 pm
Latest MacOsX Build here:

http://perso.orange.fr/jerome.vernet/Softs/previousbin.zip

Now, it's a real MacOsX app. Should work for everybody under 10.6.
Title: What Needs to be done for a NeXT Emulator
Post by: oneNeXT on October 30, 2010, 05:36:27 pm
Quote from: "gilles"If your rom version is V66 I can find the correct address (If other rom version it will take a little more time).

It is a V66

Another result for a 25MHz,12MB,  ROM 2.5 V66 with no default boot device

NeXT>s
intrstat: 00000000?
intrmask: 80027640<NMI,scc,rtc,optical,scsi,enetTX,enetRX,dsp>?
scr1: 00012002<sid=0,DMArev=1,CPUrev=20,vmss=0,mmss=0,ccms=2>?
scr2: 00ff0c80<DSPreset,mem256K/4M=f,mem1M/4M=f,ROMwait=0,rtdata>?
NeXT>m
Memory sockets 0-3 have 4MB page mode SIMMs installed (0x4000000-0x4400000)
Memory sockets 4-7 have 4MB page mode SIMMs installed (0x5000000-0x5400000)
Memory sockets 8-11 have 4MB page mode SIMMs installed (0x6000000-0x63fe000)
Memory sockets 12-15 have no SIMMs installed (0x0-0x0)


Need a little more time to find a 8Mb station running. I hope it will help you
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on November 01, 2010, 12:13:36 am
Hey guys - I went to do this tonight, but I can't find my NeXT keyboards or mice.  I have a local friend with NeXTs as well, so I'm going to head to his house soon with my systems, in order to gather the information you need.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on November 01, 2010, 09:48:42 am
thanks for all contributions :)
I'm now trying to add some primitive keyboard support since I can now go to the monitor prompt.
At least 2 values for cpu type seems to work, one for a mono station, one for a 68040 cube.
in mono station the monitor complains for memort bank 0x06000000 and 0x07000000, we will have to poke these addresses to know what is supposed to be returned here.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on November 03, 2010, 06:42:38 pm
Quotein mono station the monitor complains for memory bank 0x06000000 and 0x07000000, we will have to poke these addresses to know what is supposed to be returned here.


@everyone who wants to help with this:

We need some values from a non-turbo mono NeXTstation again. We need to know what is stored in the first 8 bytes of the memory banks located at 0x06000000 and 0x07000000 (there should be values even if no RAM is installed there).

You can obtain these values from the ROM monitor using command "e".
Within ROM monitor use these 4 commands:

e 6000000
e 6000004

e 7000000
e 7000004

Each command will return a value followed by a question mark, to exit for the next command you have to type "."
Please post the values together with your system configuration.

Example:
NeXT> e 6000000
6000000: 12345678? .
--> See that the value of address 0x06000000 is 0x12345678; type a period to exit.

You can find a detailed description of the command "e" in this document: http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/OperatingSystem/Part2_WritingLKSs/_ApB_ROM/ROM.htmld/index.html


Again, for those not used to the ROM monitor, this is how you get there:
QuoteWithin three seconds of the appearance of the message "Loading from disk" or "Loading from network," hold down the Command and left Alternate keys and press the ~ key. (If you're using a keyboard that has two Command keys, don't hold down the Alternate key; just hold down one of the Command keys and press the ~ key.)


I hope my instructions help. If you have any questions, just ask!
Title: What Needs to be done for a NeXT Emulator
Post by: oneNeXT on November 04, 2010, 09:46:22 pm
For the 20MB station mono
i gogt the current value

e 6000000 : 06000000
e 6000004 : 06000004

e 7000000 : 07000000
e 7000004 : 07000004


by the  i've checked some values and got some mistake, here 's the good ones:



NeXT>s
intrstat: 00000020<video>?
intrmask: 80027660<NMI,scc,rtc,optical,scsi,enetTX,enetRX,dsp,video>?
scr1: 00011102<sid=0,DMArev=1,CPUrev=11,vmss=0,mmss=0,ccms=2>?

Title: What Needs to be done for a NeXT Emulator
Post by: gilles on November 05, 2010, 07:26:53 pm
the address value echoed to the content, so no memory here. I'll try that on the emulator ;)
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on December 16, 2010, 01:48:56 am
Hi, all.

I finally got around to pulling my NeXTs out, and I borrowed a keyboard from a friend.  We tried all 3 of my NeXTs - two 040-25 stations and one 040-25 Cube - and none of them will go into the monitor.

I had pulled the battery out of all 3 of them, so I had to put a battery into them for them to power on.  They all power on, but all 3 get stuck at "Loading from network."

We tried cmd-~, cmd-cmd-~, cmd-alt-~, and various other combinations, but no combination will go into monitor mode.

Any ideas?

Thanks.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on December 16, 2010, 10:19:08 am
maybe the ADB non/ADB soundbox and rom version problem ?
I found this old post here : http://www.nextcomputers.org/forums/viewtopic.php?t=785&postdays=0&postorder=asc&start=15
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on December 16, 2010, 02:09:27 pm
Hi Gilles.

I thought about that, but neither I nor my friend has any ADB NeXT equipment.  The keyboard he brought was an original NeXT keyboard with a flat (not L-shaped) enter key.  This is the same keyboard that I have packed away somewhere in my garage.

It's just strange that none of the 3 systems would boot.  None of the 3 systems saw its hard drive - all 3 wanted to boot from network.  But, that might be because they had lost configuration RAM because I had pulled the batteries out.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on December 16, 2010, 02:28:01 pm
Configuration is in the real time clock chip but I think that default after memory corruption is to boot from network (confirmed by tests with emulator).
Maybe removing all RAM or bad RAM configuration (f.e. one SIMM missing) will bring the monitor, then you can force the boot device...
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on December 16, 2010, 06:06:57 pm
@eagle:
I found two more threads from people having a similar problem:

http://www.nextcomputers.org/forums/viewtopic.php?t=2119&highlight=battery
http://www.nextcomputers.org/forums/viewtopic.php?t=1652&highlight=battery

Maybe the keyboard is broken. Did you test it on a working machine?
Also it may be that you just had a bad timing with pressing the keys. It seems to be a little bit tricky to find the right moment to get to the ROM monitor. You have to press the keys immediately after "Testing system ..." message disappears.

btw, as gilles already said, it is normal that your system tries to boot from the network. This is the standard setting after removing/losing battery power. Once you are able to enter the ROM monitor you can change the setting to boot from the hard drive.
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on December 16, 2010, 06:18:52 pm
Andreas, my friend pulled the keyboard off of his working Cube, but the Cube hasn't been powered up in a few weeks, so there is the possibility that it went bad, but that's a pretty slim possibility.  He's going to retry it soon.

Also, I've used the ROM Monitor before, but probably 15-20 years ago.  Usually I used it to issue the "bsd" command.  I'm just surprised that we couldn't get into monitor mode.

My wife and I want to rearrange the garage, so maybe I will have an opportunity to pull out one of my keyboards (I have 4) and try that.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on December 16, 2010, 07:55:45 pm
You can press the keys any time after the initial tests have passed in order to break into the ROM monitor, even after booting.
Title: wow
Post by: neozeed on December 27, 2010, 07:40:53 pm
wow this is very cool!...

So, I fired up the OS X 10.6 binary, and started to play....

I found that if I changed the config file like this:

[System]
nCpuLevel = 3
nCpuFreq = 50

And booted with the 1.0 ROM (rev_1.0_v41.bin)...

it'll give an "Exception #4 (0x10) at 0xfe69

Then dump me to the glorious NeXT> prompt!!!!

needless to say it's not registering any keypresses at the ROM prompt.....

but wow, this is very exciting!
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on January 08, 2011, 12:38:28 pm
neozeed, thank you for the hint!

Based on your instructions i did some tests myself and noted that all available ROMs from version 1.0 v41 to 2.5 v66 boot the emulator to the ROM monitor (68030 ROMs - v41 and v43 - with the described changes to the configuration file, others with standard configuration, ROMs for turbo chipsets (3.0 v70 and up) do not work; at least not with standard configuration).

Using ROM 1.0 v41 the ROM monitor displays a message similar to that you get with 2.5 v66 ROM for the fraction of a second:

CPU MC68030 25 MHz, memory 100 nS
Backplane slot #0
Ethernet address: 0:0:f:0:30:90
Memory size 64MB
Testing the FPU

System test failed.   Error code 41.


and then immediately switches to the NeXT> prompt with "Exception #4 (0x10) at 0xfe69":

Exception #4 (0x10) at 0xfe69
NeXT>


Using 1.2 v43 it is quite the same except that "Exception #4" now is at 0xfe83.


With ROM 2.1 v59 it displays:

CPU MC68040 25 MHz, memory 100 nS
Backplane slot #0
Ethernet address: 0:0:f:0:72:fe
Memory size 64MB, parity enabled
Testing the FPU

System test failed.   Error code 41.


boot en(0,0,0)diagnostics


It stops here. (note: the message "parity enabled" seems to be only displayed with this ROM version)

2.4 v65 displays exactly the same as 2.5 v66 does.

I can only agree with neozeed saying this is very exciting!
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on January 14, 2011, 06:34:22 pm
For all of you interested in the meaning of "exception #4" i started a new topic here:

http://www.nextcomputers.org/forums/viewtopic.php?t=2765

Thanks to cuby, there you can find an explanation of this exception and a link to a document describing the meaning of some different exceptions, that may occur.

As this exception seems to be related to 68030 emulation (which is as far as i know not a goal of "Previous") it may be not relevant for further development of the emulator. But i think knowing the meanings of the exception codes can still be helpful at some point.
Title: What Needs to be done for a NeXT Emulator
Post by: ebann on January 19, 2011, 12:45:51 pm
Any new updates on this?
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on March 30, 2011, 06:08:41 pm
Managed to build and run the linux version from sourceforge, but am running into issues on the MacOSX side.  Would appreciate instructions on how to build for MacOSX.

I'm making some progress on the keyboard emulation based upon the NetBSD drivers for next68k.  I have full hardware specs for the ethernet, scsi, and floppy controllers and intend to work on those as well.

I have a working color slab to use as a reference and have made a raw disk image from it.

Anybody else still interested in working on this?
Title: What Needs to be done for a NeXT Emulator
Post by: neozeed on March 30, 2011, 06:10:03 pm
interested? yes, capable? heh in my dreams I guess...
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on March 31, 2011, 10:44:20 am
dtaubert, welcome to the project!

It is great to hear that someone has been able to make progress on the emulator! Can you give us some details about what you have done so far? Do you plan to share your code with us?

I am still highly interested in this project and i am sure many others are too!

I can't help with coding, but i will do my best to help in other ways. I have collected some documentation about NeXT hardware, that i can share with you, if needed.
If you need some specific informations i can try to find them. I can also help with testing and solving problems!

To your compiling problem:
Forum member jvernet already successfully compiled "Previous" on Mac OS X. I try to contact him and ask him if he could give us some instructions.

In the meantime you may find some (very sparse) informations on compiling here: http://hg.berlios.de/repos/hatari/raw-file/tip/doc/manual.html#Compiling%20Hatari
Title: What Needs to be done for a NeXT Emulator
Post by: cuby on March 31, 2011, 12:56:34 pm
Quote from: "dtaubert"I have full hardware specs for the ethernet, scsi, and floppy controllers and intend to work on those as well.
...
Anybody else still interested in working on this?


Definitely (though not too much time ATM). Could you share the hardware specification documents - I think not all of these are easily available?

-- Michael
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on April 01, 2011, 03:39:28 pm
Quote from: "andreas_g"dtaubert, welcome to the project!


Thanks!

Quote from: "andreas_g"It is great to hear that someone has been able to make progress on the emulator! Can you give us some details about what you have done so far?


So far, I have done a datasheet search based upon the chip labels on my color slab hardware, studied the NetBSD next68k arch code, and started coding a keyboard emulator for previous.  I'm also starting to dive into the ROM disassembly that was checked into previous for more data about the operation of the keyboard/mouse registers.

Quote from: "andreas_g"Do you plan to share your code with us?


Of course!  I'll start once I'm able to actually type something into the ROM prompt.
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on April 01, 2011, 03:43:16 pm
Quote from: "cuby"Could you share the hardware specification documents - I think not all of these are easily available?


Have a look under http://www.wazzozazzo.com/~dtaubert/NeXT/ for datasheets and for browsing the arch/next68k portion of the NetBSD-5.1 source.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on April 01, 2011, 05:42:05 pm
hello,
I unfortunatly did not have much time for previous in the last months but I may have a little more time in the next weeks.
Everyone is welcome to join. Keyboard and mouse will be easy to add... but DMA may be a real problem as netBSD code is far from beeing complete and clear about DMA.
For a macosX build, ask Jerome (jvernet), he already compiled under macosX.
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on April 02, 2011, 02:07:39 am
Quote from: "gilles"DMA may be a real problem as netBSD code is far from beeing complete and clear about DMA.

Not to worry - I'm planning to modify the NetBSD boot loader such that it can be used to help probe the operation of some of these hardware devices on my color slab.
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on April 02, 2011, 06:13:16 pm
Got an i386 NetBSD-5.1 system running under VirtualBox and set up a cross development system for next68k.  Managed to build the boot loader from source.  Going to use that to figure out all the key mappings and mouse data.
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on April 03, 2011, 05:52:22 am
Used my hacked up boot loader to figure out the keyboard mappings.  I can now enter commands at the ROM prompt when using the 68030/v41 combo:



Will work on interrupts next to see if we can break out of the diagnostic boot with 68040/v66...
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on April 04, 2011, 10:58:23 am
Thank you for your answers and for keeping us up to date with your work! This all reads very promising!

Regarding the Mac OS X building issues i had no luck contacting jvernet so far. But i am sure he will check back to this thread as soon as he logs into the forums.
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on April 04, 2011, 07:18:21 pm
These settings will allow the v66 ROM to drop to the prompt:

Uint8 rtc_ram[32]={
0x94,0x0f,0x40,0x03,0x00,0x00,0x00,0x00,
0x00,0x00,0xfb,0x6d,0x00,0x00,0x4b,0x00,
0x41,0x00,0x20,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x84,0x7e,
};

gilles, if you add me to the project (check your SourceForge messages), I will check in my current changes that make the keyboard mostly work.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on April 05, 2011, 06:11:01 pm
I'm back ;)

Happy to see previous still alive !

I did not use the CMake system (bored to try to figure out how this work...) so I made a XCode Project wich is OK for Revision 9 from SVN. I can try a build with last change (nothing in SVN yet ?). Wil post the XCode projet tonight.

One thing that may also help, as previous is built from Hatari, an Falcon Emulator: they recently started to work on a new UAE core, wich is much more accurate for 68030/68040/DSP emulation.
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on April 05, 2011, 06:55:12 pm
Some info that I wanted to share about the keyboard/mouse registers:

address  : bits # ROM v66 instructions that use them
----
0x200e000: 80   # 000025a0, 00004046, 000040ee, 000040f6, 000041ac
0x200e000: 20   # 000025c4, 0000411a, 000041b0

0x200e001: 80   # (INT)
0x200e001: 40   # (DATA) 010089e2, 01008b94, 01008c52, 01008e26
0x200e001: 20   # 010089e8, 010089ee, 010089f4
0x200e001: 10   # 010089c2

0x200e002: 40   # 000025b2, 000025ba
0x200e002: 10   # 00003e4e
0x200e002: 02   # (enable?) 01008e66
0x200e002: 01   # 01008baa

0x200e003 - 0x200e007: seems to be a write-only command register
Sample commands:
   c5 ef000000
   c5 00030000
   c5 00000000
   c6 01fffff6

0x200e008 - 0x200e00b: data register
Mouse data:
   0100xxxx
       fe00 - movement up (negative down)
       0100 - right button up
       00fe - movement left (negative right)
       0001 - left button up

Any insight into the meaning of the bits or commands would be appreciated, as would a double check of my decoding of the ROM instructions that test those bits...
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on April 05, 2011, 07:20:30 pm
Here is my sources:
http://www.megaupload.com/?d=AEQ8SJU3

Some changes was make in SDLMain.h/SDLMain.m (remove hatari stuff).
Remove HAVE-X11 (set to 0) in config.h. Change in configuration.c to remove hatari stuff and name config file to previous.cfg, in path.c also.

I do not rememebr HOW i've done the XCode Project from cmake -G Xcode (it's not working "out of the box".

JV
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on April 16, 2011, 07:47:44 am
jvernet:
QuoteOne thing that may also help, as previous is built from Hatari, an Falcon Emulator: they recently started to work on a new UAE core, wich is much more accurate for 68030/68040/DSP emulation.

That sounds quite interesting! Please keep us up to date with this.


dtaubert:
I see that your code has not yet been added to the sourceforge project. I suppose you still have no access to the project?

Maybe you could in the meantime release the code through another channel?
I'm very curious to see how it works!

Have you made further progress? What is planned next?
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on April 18, 2011, 09:51:48 am
sorry for not being here for a while.
I'm checking sourceforge accounts now.

[edith]
ok, now you should have full access...
but it failed by mail on 1st April with an unknown user...
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on April 18, 2011, 01:04:52 pm
about keymaps:
A keymap is found in the "next book" by bruce Webster. It seems to be a scancode table.
Title: What Needs to be done for a NeXT Emulator
Post by: dtaubert on April 18, 2011, 01:32:00 pm
Thanks for adding me to the sourceforge project!

I started messing with scsi support but got to a point where interrupt handling was needed.  I'll clean it up and get something checked in ASAP.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on April 18, 2011, 01:43:09 pm
If your updates are a bit experimental, maybe we could create a subversion Branch.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on May 11, 2011, 02:54:31 pm
dtaubert, what is the current state of your work? What about the source code? Still curious about the working keyboard. Your screenshot is a teaser!   :wink:
Title: What Needs to be done for a NeXT Emulator
Post by: oneNeXT on May 17, 2011, 10:17:48 pm
I wonder if would be possible to make a NeXT release of this emulator.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on May 20, 2011, 02:23:46 pm
I had no news from dtaubert since I gave him svn access. but I'll have a little more time next week. maybe I'll try to play a bit with the informations he posted here.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on May 22, 2011, 04:49:26 pm
Quote from: "gilles"but I'll have a little more time next week. maybe I'll try to play a bit with the informations he posted here.


That would be great!
Title: Any progress on Previous?
Post by: aperezbios on October 07, 2011, 04:18:43 pm
Hey guys, things have gone dark for around four and a half months now. Any progress recently? I see on SF that  and I just successfully compiled Previous using cmake under OS X with no issues, no hacking required (which I was surprised by) although to get it to successfully install, I did have to modify one cmakefile, src/cmake_install.cmake, commenting out a few lines. Here's the trivial diff:


#src$ diff cmake_install.cmake~ cmake_install.cmake

40c40
< IF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
---
> #IF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
42c42
< ENDIF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
---
> #ENDIF(NOT CMAKE_INSTALL_COMPONENT OR "${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified")
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on October 09, 2011, 11:31:44 am
Thank you for the patch.

A lot of things happened during the last few months:

An important document has been discovered:
http://www.nextcomputers.org/forums/viewtopic.php?t=1666
It might be very helpful for implementing SCSI.

A new version of Hatari (1.5) has been released: http://hatari.berlios.de/news.shtml
There are improvements to CPU and DSP emulation among others. Previous could be updated to this new base.

There have also been lots of work on a QEMU based NeXT emulator:
http://www.nextcomputers.org/forums/viewtopic.php?t=2847
It uses some informations from this thread and Previous' source code. It already includes a working keyboard emulation and partially working DMA, ethernet and SCSI emulation. These things could be transferred to Previous.

I did talk to gilles lately. He still intends to continue working on Previous. But at the moment he is very busy.
It would be great, if we could find people that have the time and the necessary skills to help working on Previous.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on November 06, 2011, 10:35:51 pm
I recently played with Xcode and successfully built Previous as an app-bundle using Xcode 4 (using Mac OS X v10.7.2 and Xcode v4.1). Of course, jvernet already made an Xcode project available some time ago. But i want to post some instructions on how to build an app bundle from the default sources.
This is what needs to be done:

To build Previous first you need some tools and libraries. I used MacPorts to install them:
# sudo port install pkgconfig
# sudo port install cmake
# sudo port install libsdl

Next, you need to add, modify and replace some files. I made the necessary files available here: http://dl.dropbox.com/u/44703754/previous_xcode-patch_files.zip

Copy them to the appropriate subdirectories of the previous source folder:

previous/xcode.diff
previous/src/debug/Rev_2.5_v66.BIN
previous/src/gui-osx/English.lproj
previous/src/gui-osx/French.lproj
previous/src/gui-osx/Info-Previous.plist
previous/src/gui-osx/Previous.icns

Replacing the .lproj folders is optional. I am not sure, if the modified .lprojs will work with older versions of Xcode.

Some source files need to be patched. "cd" to the previous source folder and:
# patch -p5 -i xcode.diff
Now you should be able to create the Xcode project using cmake:
# cmake -G Xcode
Additionally, when you are on Mac OS X, Previous will now be built as an app bundle if you compile from Unix makefiles.
# cmake -G "Unix Makefiles"
# make


I prepared the files so that you just have to run the cmake command to create an Xcode project or Unix makefiles. You can download the prepared sources here: http://dl.dropbox.com/u/44703754/previous_patched_11-06-2011.zip

I hope this works for everyone. If you have any problems i would be glad to help fixing them.
I am an Xcode (and programming in general) beginner, so if anyone knows how to further improve this i am of course open to suggestions.

Gilles, if you want we can add the changes to the sourceforge project.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on December 10, 2011, 12:09:08 am
Thanks to andreas, Previous now has basic keyboard emulation and the better cpu core from hatari 1.5 (that should emulate the 030 more precisely).
I've set up a little joomla website for the project here:

http://previous.alternative-system.com

You can also download here binary versions for linux and win32.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on December 14, 2011, 06:25:51 pm
Seems like this is getting there! I will make some (small) disk images available later today so we can work on SCSI support.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on December 14, 2011, 11:58:10 pm
I just posted a small image to http://www.mind-to-mind.com/resources/hdd-001.dd.gz. This is a 105MB generic 3.3 image made from a direct dd of a Quantum ProDrive LPS.
[/url]
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on December 18, 2011, 06:53:36 pm
thanks a lot, I need to understand a bit more SCSI in general to make something usefull but It's a very good start ;)
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on January 23, 2012, 04:54:28 pm
I do not know if this link was known before:

ftp://ftp.cs.tu-berlin.de/pub/NeXT/documents/system/hardware/

May be some interesting docs.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on January 23, 2012, 08:25:43 pm
Since my color next station is very close to my Roland D20, the midi interface schematics is certainly a good find... but for a very different project :)
The color slab schematics may also help to add color support, I already had mono slab schematics but I don't remember color.
Thanx Jerôme.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on January 25, 2012, 11:37:29 pm
Previous 0.3 binaries are available to download :
http://previous.alternative-system.com/index.php/download

We now have a partial scsi read (of raw images). But MMU is only activated with the 68040 core and is broken. Since winUAE 2.3.0 was reported to run netBSD 5 we have some hope to fix MMU for 68040.
Title: What Needs to be done for a NeXT Emulator
Post by: jvernet on January 26, 2012, 05:17:55 pm
Quote from: "gilles"Previous 0.3 binaries are available to download :
http://previous.alternative-system.com/index.php/download

We now have a partial scsi read (of raw images). But MMU is only activated with the 68040 core and is broken. Since winUAE 2.3.0 was reported to run netBSD 5 we have some hope to fix MMU for 68040.


Nice!

Do not know if starting from Hatari was a good idea for previous, although they are also moving to the latest UAE Core. But they still working (hard) on improving it, matching their need of closest cycle exact emulation.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on January 26, 2012, 05:41:14 pm
they moved to winUAE core in hatari 1.6, previously it was plain UAE core but winUAE has some parts coming from Aranym. Also, most of 68k core derives from the old Musashi (also found in mame/mess) with the gen68k binary.
I'm now merging back to winUAE 2.3.0 to reintroduce the try/catch with a hack full of macros and longjmp() in plain C

none of the 68030 core are cycle perfect, it just does not make sense (maybe only for very specific stock falcon demos, on the other hand, 68000 must be cycle exact for atari fullscreen/hardware scroll).
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on January 30, 2012, 11:54:19 pm
more news...
the 68040 cpu is nearly ok (but FPU is still incomplete).
It now finds its attached scsi disks... and ... hangs ;)

(http://imageshack.us/photo/my-images/809/captureprevious032.png/)

Uploaded with ImageShack.us (http://imageshack.us)
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on January 31, 2012, 09:27:58 am
I played a bit with scsi but I need to test in real life what is supposed to reply the next scsi controler for some error cases.
Is there a low level (scsi command) tool for next?
I need to test some calls for missing target, or existing target and missing LUN.
I'll try to dig a bit more in the datasheet but at least the text version does not reveal much on such cases...
Title: What Needs to be done for a NeXT Emulator
Post by: aragon on January 31, 2012, 02:33:38 pm
Found this one:

ftp://ftp.cs.tu-berlin.de/pub/NeXT/misc/old/programming/classes/SCSI2_ToolBox.941207.NI.bs.tar.gz
ftp://ftp.cs.tu-berlin.de/pub/NeXT/misc/old/programming/classes/SCSI2_ToolBox.941207.README

Hope it helps!
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on January 31, 2012, 07:19:11 pm
seems good (in the description). I'll try this on my turbo slab tonight ;)
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on February 01, 2012, 12:13:24 am
ok, the application runs but uses the kernel. So it will help to tune the emulator in a later phase. I'll probably hack netBSD to have have raw scsi events.

now I try to surf from the station  8)
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on February 13, 2012, 09:40:12 am
still working on emulation.
now the processor, timers and most of scsi should work.
Booting still hangs but we are not far from single user boot (for now the init process is not fund on disc image ...).

(http://imageshack.us/photo/my-images/259/captureprevious035.png/)

Uploaded with ImageShack.us (http://imageshack.us)
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on February 13, 2012, 02:09:31 pm
wow! I think this is very impressive! was playing around with the 0.3 binaries... hopefully it will run some day!

regards,
michael
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on February 13, 2012, 09:27:46 pm
This phase is really interesting because we have a partly working system, on the other hand, each try now takes nearly a normal boot time and errors are not so obvious as in the first phases where only 2 or 3 opcodes where launched before crash :)
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on February 14, 2012, 01:34:58 am
Wow, this is so exciting!  Keep up the good work, guys.  I can't wait to be able to emulate a NeXT!
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on February 17, 2012, 01:56:47 pm
still trying, we now need to compare scsi commands results on real hardware but cannot use Nextstep for this. So I'm building a netBSD for target next68k to hack the kernel or bootsector.

Does anyone know if netBSD 5 really support native hard disk?
Netbsd was known to be diskless only for next68k but the root page states that esp (scsi controler) is now supported.

Unfortunatly I cannot use network boot on my station... my "e" key is dead...  (and the "b" is not perfect also...)
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on February 17, 2012, 02:47:09 pm
I believe I installed netBSD on a NeXT mono slab once.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on February 17, 2012, 03:53:43 pm
netBSD + gnustep could be a good alternative OS for our black boxes. But I don't think X was ported to next hardware.

For now it seems to build without any problem, but I need to make a bootable image to try.
First I'll do a clean image on a small sized disc image and see if it can boot.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on February 17, 2012, 04:08:27 pm
I thing there is framebuffer support in NetBSD isn't there? If so, some port of X or some other windowing system might be possible.
Title: What Needs to be done for a NeXT Emulator
Post by: Noth on February 17, 2012, 06:03:21 pm
Could someone please donate a NeXTstation keyboard to gilles? Not being able to netboot is a big issue for his development of Previous.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on February 17, 2012, 09:21:00 pm
I'd be happy to donate any necessary hardware... but I'm n the uS... :(
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on February 17, 2012, 11:38:51 pm
I'll find a way to fix the keyboard. I may also have the same kind of switch in some old mac keyboards.

I'm not certain to be able to install netbsd on hdd, this thread : http://permalink.gmane.org/gmane.os.netbsd.ports.next68k/305
and some traces here shows that scsi was still broken in netBSD 5 RC1 in 2009.

I'll try just a bit more on netBSD but maybe a better strategy is to compile on the next and build a very small bootable image with an scsi test program.
I can boot my next and work remotely by telnet.
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on February 18, 2012, 10:21:00 am
It was my understanding that all of NeXT's hardware was documented, except for two proprietary VLSI chips.

Have you figured out the (partial) functional description of these two chips?

Is this document of any use?

http://www.t10.org/ftp/x3t9.2/drafts/s1/s1-r17b.txt
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on February 18, 2012, 10:40:35 am
according to this document -> http://ftp.sunet.se/pub/NetBSD/NetBSD-5.1.2/next68k/INSTALL.txt SCSI is still not supported. even with the latest NetBSD release 5.1.2

excerpt:

NetBSD/next68k 5.1.2 does not have any local disk sup-
    port, so you must netboot and run diskless.

and


Unsupported hardware

          o   CPUs
              -   68030-25 2-bit grayscale (NeXT Computer)
              -   68040-33 2-bit grayscale (NeXTcube Turbo)
              -   68040-33 2-bit grayscale (NeXTstation Turbo)
              -   68040-33 16-bit color (NeXTstation Color Turbo)

          o   Disk interfaces
              -   on-board SCSI interface and disks
              -   Floppy drive
              -   Optical disk
              -   non-SCSI CD-ROM
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on February 18, 2012, 12:36:17 pm
some documents are contradictory :

here scsi support is confirmed
http://www.netbsd.org/ports/next68k/

but without any real installation method documented.
I suppose the hdd installation is something like booting by network, create local filesystem (probably ffs?, or maybe an older ufs). But the method to put the bootblock is not clear (makelabel command? or a brute force 'dd')
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on February 18, 2012, 06:00:22 pm
I'm pretty sure I netbooted for the HDD install.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on April 19, 2012, 04:04:23 pm
Some time went past since the last update. There has been some more work on Previous. Unfortunately there are still some problems with the SCSI controller so we can't boot yet, but at least we now pass the power-on test.
I've added entry points for most devices (ethernet controller, serial communication controller, mo-drive controller, etc) and added some dummy code to pass the power-on test.
To add real emulation of these devices some more work needs to be done. I think ethernet emulation has highest priority besides fixing the SCSI controller. Any help is welcome!

Here is a screenshot of Previous passing the power-on test in 68030 NeXT Computer mode:

Title: What Needs to be done for a NeXT Emulator
Post by: eagle on April 19, 2012, 10:47:20 pm
Wow, that is excellent progress!
Title: What Needs to be done for a NeXT Emulator
Post by: un on April 20, 2012, 03:31:04 am
This is definitely a challenging project but you've been making great progress!
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on April 20, 2012, 01:44:10 pm
since netbsd does not have a clear status about running on local disc, ethernet is the most important peripheral to emulate. Also it may help to enhance dma emulation.
Unfortunatly, for now I do not have much time for this project. But my next task is a correct 68030 MMU emulation (for now, only 68040 has a correct mmu emulation).
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on May 20, 2012, 08:58:16 am
Hello forum members,

i need your help again. At the moment i am working on memory configurations for all kinds of NeXT machines. There are some things not yet clear. So i need some informations from real hardware:

I need informations about the memory layout of turbo and color machines (cubes and slabs). Also i need values for SCR1 and SCR2 from these machines. You can obtain these values from the ROM monitor with commands "m" and "s".

I have described how to do that on page 5 of this thread:
http://www.nextcomputers.org/forums/viewtopic.php?t=2642&postdays=0&postorder=asc&start=60

Please post the output of these commands together with your machine configuration to this thread.

If you have any other informations about compatible memory modules and sizes, number of memory slots, different board revisions of a machine, etc please share it.
We already have informations for monochrome systems that seem to work on the emulator, but if you have any interesting informations about theses systems they are of course also welcome.

Thanks to everyone who takes the time to help!
Title: What Needs to be done for a NeXT Emulator
Post by: GrafZahl on May 21, 2012, 09:07:10 pm
Here is the s and m output of my turbo color slab with 128 Mb memory installed and Rev 3.3 V74 Rom. Thanks a lot for the great work on preview. I hope it helps.

http://img337.imageshack.us/img337/3299/turboslabcolor.jpg
Title: What Needs to be done for a NeXT Emulator
Post by: mcdermd on May 21, 2012, 11:48:03 pm
My Mono Turbo Slab with 128MB RAM and ROM v74.

CPU MC68040 33 MHz, memory 60 nS
Ethernet address: 0:0:f:12:34:56
Memory size 128MB

NeXT>s scr 1
scr1: ffff4fcf<sid=f,machine=4,rev=f,vmss=3,mmss=0,cspd=7>?
NeXT>s scr2
scr2: 00001080 DSPreset,vmode,local>?
NeXT>m
Memory sockets 0 and 1 (front) have 32MB of page mode SIMMs installed (0x40000000x6000000)
Memory sockets 0 and 1 (back) have 32MB of page mode SIMMs installed (0x60000000x8000000)
Memory sockets 2 and 3 (front) have 32MB of page mode SIMMs installed (0x80000000xa000000)
Memory sockets 2 and 3 (back) have 32MB of page mode SIMMs installed (0xa0000000xbffe000)


http://i45.tinypic.com/ru6z4n.jpg
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on May 22, 2012, 06:17:12 pm
GrafZahl and mcdermd, thank you very much!

I tried the values on the emulator. Unfortunately there seems to be something very different from non-turbo machines. The values that are shown for SCR1 seem to be read from 0x02200000 and 0x02200002 and not from real SCR1 register. So i don't really know what is in the real SCR1.
To find out one could try reading 0x0200c000 from ROM monitor with command "e 0200c000". To confirm one should also read "e 02200000".
If someone wants to try this, it will be for sure interesting. But the chances that it will fix the boot process are very low as it seems we are ending in an infinit loop while interacting with the DSP (which is not implemented). So turbo emulation might be something for later ...

With these new informations i think for now it makes sense to concentrate on non-turbo systems (color should be possible).
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on May 22, 2012, 06:24:33 pm
Andreas, is there a reason to specifically do turbo emulation?  I thought the turbos only provided a faster CPU, and since today's computers are so much faster than the NeXTs of 20 years ago, shouldn't today's CPU speed make up for not having a "turbo" emulator?

Of course, maybe I just misunderstand ... :)
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on May 23, 2012, 05:40:30 am
You are absolutely right when it comes to CPU speed. The only reason for turbo emulation i can think of is memory size. With non-turbo we are limited to 64 MB for monochrome systems and 32 MB for the NeXTstation Color.

As you said, i don't think there are any other benefits we would have from turbo emulation.
Nevertheless i am trying to write the code in a way that adding turbo emulation is easy after having DSP (or at least some dummy DSP). So collecting some values might still be useful for later.
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on May 23, 2012, 01:20:12 pm
Oh, RAM!  Now, that totally makes sense.  I've never owned a turbo so I didn't realize there was a difference in Max RAM spec.
Title: What Needs to be done for a NeXT Emulator
Post by: bkmoore on May 23, 2012, 04:21:59 pm
When it comes to emulating machine speed, is it possible to have the emulator take up fewer system resources from the host computer? NeXT / OpenSTEP seem to take all the resources they can get their hands on, and tend to max out my host computer's CPU.

I would to have a NeXT emulator that could run all the time without destroying battery life.
Title: What Needs to be done for a NeXT Emulator
Post by: aragon on May 24, 2012, 06:52:48 am
Are you talking about running NeXTstep in a VM environment?
I think this has something to do with the VM itself. I recently set up a DOS 6.2 machine in VMware and had to add the dosidle command to properly set up the processor's idle mode. Perhaps this can be done in NeXTstep / Openstep as well?!

Quote from: "bkmoore"When it comes to emulating machine speed, is it possible to have the emulator take up fewer system resources from the host computer? NeXT / OpenSTEP seem to take all the resources they can get their hands on, and tend to max out my host computer's CPU.

I would to have a NeXT emulator that could run all the time without destroying battery life.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on May 24, 2012, 04:16:58 pm
Previous has a function to pause the emulation (i've mapped the keyboard shortcut to command+p). In paused mode it makes almost no use of the CPU (my system reports < 1 %).
So you could run it all the time and pause it while you are not using it. All it is going to use is some memory.
When active it consumes quite a lot of CPU power. Efficiency is not the primary goal of this emulator. It is intended to have maximum compatibility and accuracy.
But maybe there is a way to assign less CPU time to the process from your host system.

Now something different:
Does anyone know if there ever where Turbo machines with 2.x ROMs or non-Turbo machines with 3.x ROMs?
Title: What Needs to be done for a NeXT Emulator
Post by: bkmoore on May 24, 2012, 05:51:59 pm
Yes, when I boot to the console in Previous it maximizes out both cores of my laptop's CPU. The same thing when running OpenSTEP in parallels. It's probably beyond the scope of this project, but it would be nice to see a vintage OS emulator that only requires the amount of system resources that the emulated CPU could generate + overhead needed for the emulator. I don't want the emulator to give OpenSTEP multiple gigaflops of CPU resources as it is just wasted along with my laptop's batteries.

edit: Just checked Previous. It doesn't max out both cores, it runs at about 60% capacity and causes the fan to come on.
Title: What Needs to be done for a NeXT Emulator
Post by: GrafZahl on May 24, 2012, 08:06:34 pm
Just for the sake of information the content of the memory addresses (color turbo slab).

NeXT>e 0200c000
200c000: f0004000?
200c004: f0004000?
NeXT>e 02200000
2200000: ffff5fcf?
2200004: e0000000?


http://img411.imageshack.us/img411/1061/slab.png
Title: What Needs to be done for a NeXT Emulator
Post by: mcdermd on May 25, 2012, 03:32:49 pm
And on the mono Turbo slab:

NeXT>e 0200c000
200c000: f0004000?
NeXT>e 02200000
2200000: ffff4fcf?
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on May 25, 2012, 05:23:32 pm
Thanks again for your help!

This is not what i expected. So it's definitely interesting. I'll try to implement this during the next days.

For now i have another question:
Can someone explain to me what could be meant by "memory write function: A+B-AB function" in the context of hardware?
There are 256 K addresses in the memory map assigned to that.
Title: What Needs to be done for a NeXT Emulator
Post by: un on May 25, 2012, 11:06:42 pm
I'm a bit late but here's the response from my 64Mb turbo colour, rom ver 3.3(v74)


CPU MC68040 33Mhz, memory 60ns
Ethernet address: 0:0:f:1:42:55
Memory Size is 64MB

NeXT>m
Memory Sockets 0 and 1 (front) have 32MB of page mode SIMMs installed (0x4000000-0x6000000)
Memory Sockets 0 and 1 (back) have no SIMMs installed (0x0-0x0)
Memory Sockets 2 and 3 (front) have 32MB of page mode SIMMs installed (0x8000000-0x9ffe000)
Memory Sockets 2 and 3 (back) have no SIMMs installed (0x0-0x0)
NeXT>s scr1
scr1: ffff5fcf<sid=f,machine=5,rev=f,vmss=3,mmss=0,cspd=7>?
NeXT>s scr2
scr2: 00001080<DSPreset,vmode, local>?
NeXT>e 02200000
2200000: ffff5fcf? q
NeXT>e 0200c000
200c000: f0004000? q


SCR2 had different values when I broke into the rom monitor from a booted system than when I broke in on boot.

Update: I broke my "spare" Turbo colour out which has 128Mb of parity ram, this produces ffff5fdf instead of ffff5fcf for 02200000.


CPU MC68040 33Mhz, memory 70ns
Ethernet address: 0:0:f:1:4a:3f
Memory Size is 128MB, parity enabled

NeXT>m
Memory Sockets 0 and 1 (front) have 32MB of parity page mode SIMMs installed (0x4000000-0x6000000)
Memory Sockets 0 and 1 (back) have 32MB of parity page mode SIMMs installed (0x6000000-0x8000000)
Memory Sockets 2 and 3 (front) have 32MB of parity page mode SIMMs installed (0x8000000-0xa000000)
Memory Sockets 2 and 3 (back) have 32MB of parity page mode SIMMs installed (0xa000000-0xbffe000)
NeXT>s
intrstat: 00000000?
intrmask: 00000000?
scr1: ffff5fdf<sid=f,machine=5,rev=f,vmss=3,mmss=1,cspd=7>?
scr2: 00001080<DSPreset,vmode, local>?
NeXT>e 02200000
2200000: ffff5fdf? q
NeXT>e 0200c000
200c000: f0004000? q
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on June 13, 2012, 11:08:54 am
un, thank you for these additional informations! So now we have some informations about the handling of memory speed in Turbo's SCR1 too.

Values are quite complete now for these registers (except turbo cube, but that may be found out by trial and error once the turbo boots to the ROM monitor). I did write some overview directly into the sources as comment. You can find it in sysReg.c.

The logical layout of the main memory is also quite clear now. I made some GUI that makes it possible to select different memory sizes for each logical memory bank (4 banks on most systems). It should be possible to simulate all memory configurations that are possible on real hardware too.

We have 3 different types of memory bank layouts:
all Turbo systems (max 128MB):
bank0: 0x04000000 - 0x06000000
bank1: 0x06000000 - 0x08000000
bank2: 0x08000000 - 0x0a000000
bank3: 0x0a000000 - 0x0c000000

non-Turbo Color Slab (max 32MB):
bank0: 0x04000000 - 0x04800000
bank1: 0x04800000 - 0x05000000
bank2: 0x05000000 - 0x05800000
bank3: 0x05800000 - 0x06000000

all non-Turbo Monochrome systems (max 64MB):
bank0: 0x04000000 - 0x05000000
bank1: 0x05000000 - 0x06000000
bank2: 0x06000000 - 0x07000000
bank3: 0x07000000 - 0x08000000

We also have two exceptions for monochrome Slabs:
On older monochrome Slabs (serial numbers below ABB 002 6300) only the first 2 banks are physically accessible. So the maximum RAM is 32 MB:
bank0: 0x04000000 - 0x05000000
bank1: 0x05000000 - 0x06000000

Monochrome Slabs with higher serial numbers have the same layout than Turbo systems and therefore the maximum RAM for these systems is also 128 MB.
Except the last one, all of these are now implemented in Previous.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on June 14, 2012, 10:50:29 am
Dear NeXT community!

At the moment i am looking for a raw disk image of NeXTstep 1.0. It would be ideal, if it had installed the diagnostic utilities for 68030 in the root directory (http://www.nextcomputers.org/NeXTfiles/Software/Diagnostic_Utilities/). But also without them it would be useful for further experiments. The primary goal is to fix SCSI emulation.

Does anyone have such an image? Or is anyone able to make one?

From earlier attempts we have learned that using NeXTstep's dd program produces images with missing boot sectors. These are useless.
So the only way would be to connect the NeXT's HDD to a machine running some different OS (eg Linux) and use that to creat the raw image.

I hope some copies of the early NeXTstep versions are still around.

If you have such a disk but have no experiences with creating disk images i'd be happy to assist.

Update: Thanks to a helping forum member now we have a working image of NeXTstep 1.0a.
We also have an image of 0.9, but there is a problem with the disk label. The ROM accepts the disk label, but the mach kernel on the disk seems to have a problem with the disk label checksum. The checksum is confirmed to be correct. So it's either a bug in the emulator or a bug in the early kernel.

Update: The problem with 0.9 disk label checksum is fixed. It was a problem with our incomplete DMA controller emulation.
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on August 28, 2012, 05:08:07 pm
Andreas, wow, it sounds like you've made some excellent progress.  I'm still hopeful that we will eventually have an emulator!
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on September 25, 2012, 11:22:15 am
Just a little update for all those interested in Previous:

In the past few weeks i've written an MMU emulation for the 68030 processor. With the friendly help of Thomas Huth from the Hatari emulator team i've been able to properly add the 68030 MMU to Previous.

The 68030 MMU is necessary to be able to emulate the original 68030 based NeXT Computer. It will make it possible to boot old versions of NeXTstep (< 2.x) on the emulator.
It seems as if the 68030 MMU is already working quite well in its current state. But still the boot process hangs at the same place as it does with 68040 emulation (using NeXTstep 3.3). NeXTstep 1.0a also hangs at a simmilar place.
There are some CPU/MMU related problems remaining with function code handling and also with privilege levels and maybe with exception handling.

At the moment i am in contact with Gilles and we are trying to identify and fix these problems.

The updated code is already in the SVN repository.
Title: What Needs to be done for a NeXT Emulator
Post by: gilles on September 25, 2012, 11:50:42 am
8615km away but in contact anyway ;)
We still have a small problem on scsi (both for 68030 and 68040) but now cpu emulation is at the same level, nearly good for nextStep kernel. It just needs some more work ;)
Title: What Needs to be done for a NeXT Emulator
Post by: cbrunschen on September 25, 2012, 12:20:13 pm
Quote from: "andreas_g"Just a little update for all those interested in Previous

[ ... ]

The updated code is already in the SVN repository.


Great! I was just wondering what was going on - sounds like things are getting closer ... :)

Many thanks for all your hard work!

// Christian
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on September 25, 2012, 12:57:14 pm
Man, this is so exciting!  I wish I understood what you guys were doing and could help.
Title: What Needs to be done for a NeXT Emulator
Post by: t-rexky on December 20, 2012, 03:13:43 pm
I am curious if anyone working on the emulator attempted to contact Apple or Canon to obtain some hardware specifications or perhaps kernel source that could help with the emulation?  The kernel source is likely encumbered by licensing issues, but the m68k custom hardware design shouldn't be.  Of course it may have been discarded many years ago...

I sent two separate emails to some executives at Apple many months ago.  Unfortunately this was after Steve's passing and I have received no response or even acknowledgement.
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on December 21, 2012, 03:32:11 am
Try tracking down Avie Tevanian? I think the man to try to get something like that from Apple is Rob Blessin. For the emulator, docs of the two proprietary VLSI chips would be what is needed. Of others, docs for the magneto-optical drive would be very interesting too.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on December 21, 2012, 03:41:54 am
I think kernel and firmware source is only helpful to a degree because it doesn't give you the whole picture. I haven't seen any of the VLSI specs anywhere.
Title: What Needs to be done for a NeXT Emulator
Post by: t-rexky on December 23, 2012, 02:50:16 pm
I will put something together and do a bit of research to find out who to send it too (again).  Thinking of Apple, Canon and Freescale for the VLSI chips, perhaps Fujitsu for the pre-turbo machines, and also Apple for the firmware / kernel / library code.  I am thinking of the code because it would be nice to modernize the kernel and the libraries a bit, particularly with full POSIX support.

I have not done much work on my gcc port lately, but starting to get an itch to get back to it, hence the "excitement" here.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on January 04, 2013, 05:48:51 pm
Of course it would be great to have these things! Especially informations about the VLSI chips are likely to be very useful.

We are still stuck with SCSI/DMA problems.

Please keep us up to date with your work!
Title: It is not looking very good
Post by: t-rexky on January 06, 2013, 02:18:33 pm
Here is the response I got from Freescale:

QuoteThank you for contacting us. Part number SC38TG011CN04 and SC38SG009CN01 are valid parts. Unfortunately this device has been obsolete for several years, we do not have any documentation about it since it was purged before the creation of Freescale. I apologize for that.

In this situation, independent web repositories remains the best source of info about this "archeological" device.

Thank you for your interest in Freescale Semiconductor products and for the opportunity to serve you.


This is very, very disappointing.  I will try Canon next...
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on January 10, 2013, 10:32:46 am
I succeeded in making contact with Avie Tevanian. He wrote back a very nice reply, sympathetic to the project, but said he does not have access to this information. If he doesn't, it is just possible that this information is now lost.
Title: What Needs to be done for a NeXT Emulator
Post by: t-rexky on January 10, 2013, 02:17:30 pm
Quote from: "tomaz"I succeeded in making contact with Avie Tevanian. He wrote back a very nice reply, sympathetic to the project, but said he does not have access to this information. If he doesn't, it is just possible that this information is now lost.


That is super nice to hear!

I suspect that the hardware design details were likely transferred to Canon in 1993 when NeXT Computer became NeXT Software.  I was really hoping that some info was still archived at Freescale and Fujitsu, as I suspect Canon probably disposed of that information as well.  I have a request in with Fujitsu but no responses yet.  I will also be sending in a question to Canon today.  In addition, through some creative searching, I found a few individuals that appear to have worked on the NeXT hardware and ASIC design.  There is a very small chance that they may have retained some of their notes, even though the IP generally never leaves the owner company.

On the software side (kernel, libraries, etc.) I think all the source is encumbered by the BSD4.3 licensing so we may never gain access to it.  But I'm going to wait and see if anything at all comes back from Apple...
Title: What Needs to be done for a NeXT Emulator
Post by: t-rexky on January 10, 2013, 02:43:19 pm
Quote from: "andreas_g"Of course it would be great to have these things! Especially informations about the VLSI chips are likely to be very useful.

We are still stuck with SCSI/DMA problems.

Please keep us up to date with your work!


This is a really stupid question, but I presume that you have been looking at the disassembled kernel code?  I poked around it with nm and otool a few days ago and there are quite a few SCSI symbols in there:

os42m68k% nm sdmach | grep scsi
0407c00e T _scsi_attach
0407c0f8 T _scsi_cintr
0407c0ce T _scsi_docmd
0407c056 T _scsi_dstart
0407bdfa T _scsi_init
0407c306 T _scsi_ioctl
0407c51e T _scsi_msg
040c5c90 S _scsi_ndevices
0407be20 T _scsi_probe
0407c212 T _scsi_reselect
0407c2a4 T _scsi_restart
040b2104 D _scsi_sdswlist
0407c57c T _scsi_sensemsg
0407bec0 T _scsi_slave
0407c4e8 T _scsi_timeout


And a whole bunch of DMA symbols as well:

os42m68k% nm sdmach | grep dma
040b1546 D _clear_dma_on_int
040670b6 T _dma_abort
040c336c S _dma_chip
04066fec T _dma_cleanup
04066524 T _dma_close
0406663a T _dma_dequeue
040665b8 T _dma_enqueue
0406646e T _dma_init
04067154 T _dma_intr
04066672 T _dma_list
040b20be D _dma_recover_rl
040b20c2 D _dma_recover_wl
04066968 T _dma_start
0408e1fe T _en_rx_dmaintr
0408ed68 T _en_tx_dmaintr
040aecb8 D _nfsreadmap
040738f8 T _np_dma_intr
04077660 T _od_dma_intr
0408056c T _snd_device_def_dmasize
04080d62 T _snd_dspcmd_def_dmasize
04017512 T _vfs_fixedmajor
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on January 13, 2013, 01:28:04 pm
The problem is, that from disassembling the code, we are not yet able to find out what the DMA controller is meant to "reply" (or when it should set interrupts).
Maybe someone with better skills about hardware is able to find out more.
Title: Proposal to release the NeXTSTEP source.
Post by: Rob Blessin Black Hole on February 02, 2013, 10:08:50 am
Quote from: "tomaz"I succeeded in making contact with Avie Tevanian. He wrote back a very nice reply, sympathetic to the project, but said he does not have access to this information. If he doesn't, it is just possible that this information is now lost.
Piotr contacted me about this thread so here is the angle I'm working having Avie basically giving a thumbs up is more fuel to the fire. Its like firing up the rebels in Star Wars lol...the force is strong with these ones...
I called my jedi contact in Apple legal and he said he knows the source is still there and said if we can put together a statement or compilation lets call this a community effort of why it would be cool for Apple to release the NeXT source to the NeXT community , he would make sure the right VP sees it, odds of success kind if like getting struck by lightning'. He said he wouldn't make any promises of success but said using our best examples, he suggested I mention my success with cube at the Olympics and fixing the computers that control the optics for the Hubble Space Telescope , along with all of the amazing things that the NeXT community has and are still doing.    May be a support list petition , I have a  cgi page on my site , I'll set up for this proposal where yes can say yes I support it and may be we continue this thread or start a dedicated thread to release the source to point the vp at . Sound Good , I'll start on that cgi may be just modify an existing one, it'll be up in the next few days at blackholeinc.com Best Regards Rob Blessin ,  http://www.blackholeinc.com/specials/survey.shtml  :P
Title: What Needs to be done for a NeXT Emulator
Post by: t-rexky on February 02, 2013, 02:05:26 pm
Thanks a million Rob!

Considering that Apple made a large portion of OS X (Darwin) sources public and NeXTstep / OPENSTEP are approaching 20 years old, I doubt that there are any IP reasons for Apple not to make the sources available.  Perhaps some of the higher level APIs that were never released for Darwin could be problematic, including the Display PS, but we are primarily talking about the core system here (Mach, BSD, system libraries, tools, etc.)

Fundamental to my thoughts is the fact that in 2002 Caldera released the BSD 4.3 and 4.4 sources, amongst others, under a "free" license,  so the BSD parts of NS / OS should not be legally encumbered since then:

http://linuxdevcenter.com/pub/a/linux/2002/02/28/caldera.html
http://www.tuhs.org/Archive/Caldera-license.pdf

Back in the glory days of NeXT one could purchase from NeXT a large portion of their sources for a high four figure or low five figure price.  This apparently included all the Unix software licensing rights, but not some of the IP key to NeXT at the time, such as the m68k hardware drivers, etc.  There are a few posts on this subject on Usenet and also a comment on the old CMU Mach site:

http://www.cs.cmu.edu/afs/cs/project/mach/public/FAQ/NeXT.release

From my perspective, having these sources made available to the community will allow us to continue the NeXT hardware preservation and stewardship, greatly enhancing its overall viability.  Specifically in the context of this thread, the hardware specific sources would help with the development of the Prev emulator.  More generically speaking, they would allow the community to:



Rob, I would be happy to write a few paragraphs based on the above, in a letter format, such that we can start a "petition".  I can also send a note to the Debian m68k mailing list as there are quite a few individuals there that I think would be very much interested in having a viable 68040 platform.

Piotr.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on February 02, 2013, 07:51:28 pm
FWIW. I know for a fact Apple has the source code.
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on February 05, 2013, 07:18:09 am
this would be absolutely awesome if the source became available  :D just WOW!
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on May 05, 2013, 11:19:39 am
I had a very credible person suggest that we strip the packaging off the two VLSI chips and reverse engineer the die. Apparently he knows someone who is very good at it. I think it would be feasible to reverse engineer to the point where we had a full unstructured schematic, showing where the chip's pins go and the internal state flip-flops. Then this could perhaps be simulated in Verilog to reverse engineer the behavioural description.

It would require getting a motherboard which has otherwise been destroyed beyond repair from which the two chips could be recovered (I'm not sacrificing my good motherboards :-) ).
Title: What Needs to be done for a NeXT Emulator
Post by: t-rexky on May 08, 2013, 01:51:42 am
I am actually working on a lead that may provide some of the required hardware information.  Nothing certain at this point, but I am hopeful.  I will provide an update if anything materializes...

I looked at the silicon level reverse engineering possibilities as well, but all the methods appeared to be prohibitively expensive.  If we had some contacts though and a facility was willing to donate their time it would be a different story.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on May 08, 2013, 02:24:15 am
If anyone is interested in doing this, I'd be happy to donate a few boards.
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on May 08, 2013, 07:24:50 pm
Quote from: "gtnicol"If anyone is interested in doing this, I'd be happy to donate a few boards.
I'm pursuing this and will post after I've got more information.
Title: What Needs to be done for a NeXT Emulator
Post by: barcher174 on May 09, 2013, 02:01:02 am
Reverse engineering like this is a daunting task. Given the timeframe and the size of the packaging, these could go well above 20K gates. To put this in perspective, if you were going to pay for this work, you could expect to pay high tens of thousands at the bare minimum.
Title: What Needs to be done for a NeXT Emulator
Post by: Rob Blessin Black Hole on May 24, 2013, 06:06:20 am
Rob,

   As always, it is good to hear from you.  Amazing find on the Mono Turbos.  I bet the flash drive NeXT really screams!

   I have not heard anything back on your source code request.  I do know that your request was presented to the appropriate persons at Apple.  However, I do not have any feedback on their response to your request.  Unfortunately, that probably means that your request was not granted.  Otherwise, I would have heard something.

   Have a great spring / summer.

Hoyt
:(
Title: What Needs to be done for a NeXT Emulator
Post by: t-rexky on May 24, 2013, 09:52:17 am
If the lack of feedback indeed means that our request has not been granted, it would be very, very disappointing news...
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on May 24, 2013, 10:32:06 am
@Rob

what if we try to involve dan noyes of cern? maybe Apple would listen to them?
Title: What Needs to be done for a NeXT Emulator
Post by: Rob Blessin Black Hole on June 01, 2013, 06:26:20 am
Hello : I'm told the cube I just bought sat outside Avies office for years Hmmm ill check it for source, in fact I'm going to look through a lot of old drives . What exactly would original NeXT source look like file type ? Best regards Rob Blessin
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on June 01, 2013, 03:04:39 pm
The source code would look much as it did for Darwin... lot's of C/Objective C code.

Personally, I think the more interesting thing would be getting some info on the custom chips in the NeXT.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on July 10, 2013, 07:33:19 am
Hello forum members!

I've been inactive for some time. But i continued coding for Previous recently. I have some news:
Finally we have a working SCSI processor (called ESP) emulation. I think it is complete for our needs, except some interrupt timing problems.
I have also improved SCSI DMA channel. I think it works as it should for the most part. We still hang early in the boot process, but i think this time we are really quite close.
Next i need to find out the reason for the hang. I'll keep you up to date.

Many thanks go to the forum members who helped by providing all kinds of informations!

tomaz, your suggestion for reverse engineering the DMA chips is quite interesting, but i don't know if it will be very useful for our purpose. I think we should be able to emulate the chip without doing that. I think that would be more interesting if someone tried to build new hardware.
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on July 16, 2013, 10:56:13 pm
Would you be able to put together a functional specification / description of the chip (presumably only its software interface is feasible)?

I presume that much of this information will be decipherable from your code, but a standalone summary spec would, I think, be very interesting.

I'll try to follow up with the guy who said he could reverse engineer the chip. I took a really long time to get back to him after he first suggested this because I was busy with other things, and now he seems to have disappeared. I'll drop him another line in a bit.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on July 19, 2013, 05:42:57 pm
It's definitely possible to make some kind of functional description. But i think it is too early yet. I'm not sure about some things, also different channels have different behaviors.
For now i did most investigations for the SCSI channel. Others, especially Ethernet, have some differences. Also there are quite a lot of differences between the old Fujitsu chips and the later chips used in Turbo systems.

I think we should write such a description as soon as we have a complete overview.
Title: What Needs to be done for a NeXT Emulator
Post by: cjbriare on August 29, 2013, 06:24:19 pm
Dang, I found my way here through a link on Wikipedia, and didn't even realize that I was the OP.


Anyways I read through the thread and I'm very excited for this project, (even if i'm a little late to the party...lol)


great work to everyone supporting this project, keep it up!
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on September 11, 2013, 07:21:44 am
I have some news, good and bad ones ...

I am quite sure that a CPU/exception handling problem prevents us from booting. At the moment i am not able to fix that.

So i used my time to take a closer look at the magneto-optical disk drive. Although on first look it seemed to be very complex, on second view it looks not that complicated. My local development version already successfully reads from an image using DMA. I think it should be possible to emulate the MO disk drive, but there remains a problem:

SCSI hard disk drives "translate" logical block addresses (LBA) to physical disk layout (including spare sectors, etc) in hardware/firmware. So the operating system's driver doesn't need to care about the actual disk layout. All images obtained from such a drive use the same logial block addresses as visible to the driver.

It's different for the MO drive. It lacks such translation, so the operating system's driver needs to care for physical layout using tracks an sectors and also deal with bad sectors an spare sectors. Although the operating system still uses logical block addresses, the driver needs to convert these to physical ones. The consequence is, that there might be areas on the disk, that are accessible and needed by the driver, but are not accessible from user space.
All images obtained from an MO disk also use logical block addresses, but lack the sectors that are only visible to the driver.

It might be possible to bypass this in emulation. Also it might be possible, that these sectors are not needed in normal operation (we won't get bad sectors, so we don't need spare ones).

My main problem at the moment is, that i don't have an image from a magneto-optical disk to test things. I can't use HDD images, because they have different disk labels and differnt disk label locations.
So if anyone has an image of a bootable MO-disk around, this would be very useful for development of an MO emulation!

I remember that we had problems with missing disk labels on HDD images obtained from within NeXTstep. So if someone tries imaging an MO drive with "dd" utility you can check if it is valid by looking at the first 4 bytes of the image. They should be ASCII "NeXT", "dlV2" or "dlV3". I'll happily assist with the process of imaging or fixing missing disk labels.
Update: I think to avoid missing disk labels one needs to use /dev/rod0 indstead of /dev/od0 as input for dd (for SCSI that would be /dev/rsd0).

Why emulate the MO disk drive? Besides from being some kind of "must have" for a NeXT computer emulator, my goal is to make sure we don't have any more SCSI problems.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on September 11, 2013, 01:16:01 pm
I should be able to provide a dump for you. Perhaps of 0.94 or so?
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on September 11, 2013, 02:09:37 pm
That would be great! I think the version does not matter that much. But generally the older verions are more "verbose" when it comes to error messages during boot process. So that one should be fine.
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on September 11, 2013, 02:53:56 pm
I have full sector dumps (249790464 bytes) for several versions. Is that size consistent with having the additional header information you're after?

Edit: Having just looked at them, they don't have the "dlV2", "dlV3" etc. magic numbers at the front ... so I guess I've just learned an important lesson about dumping any images in the future!
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on September 11, 2013, 04:35:48 pm
tomaz, the size of the image seems valid (that would be 15246 tracks, with 16 sectors per track and a sector size of 1024 bytes). But i don't know the total number of tracks of an optical media of this kind. So i can't tell if there are some missing.

The missing disk label might be caused by reading from the wrong block device like described above. But i am not 100% sure about that, because i can't test it.
The images can still be used to build bootable disks from within NeXTstep. The system will create a valid label, when the disk is initialized (we found out while trying to obtain a full image from an SCSI disk).
But it's unlikely they can be used on the emulator.

There is a small chance that the label for optical drives is not at LBA 0, although i think that's unlikely.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on September 13, 2013, 03:16:42 am
I went through and looked at the various dumps I have, and I also tried a dump with a 1.0 MO disk. I even tried cat /dev/rod0a > dump.dd

In all cases, they were missing the disk label. This is actually consistent with what I found with hard disk images as well: unless I dumped the disk from *linux* I could never get the full disk image.

I think this is because NeXT is interpreting the disk label and only exposing the partitions, not the entire disk. In other operating systems there is usually a device for raw disks... something like /dev/rod0, but it doesn't appear to be the case here. I could be wrong... might be time to disk around and figure out what devices the *drivers* are talking to, and whether they're exposed.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on September 13, 2013, 11:16:29 am
Thank you for trying! That is not so good news. So the problem is the missing access to rod0.

Maybe there is another way to extract the disk label (there should be a cli utility called "disklabel" or similar). Unfortunately i have no hardware to test.
If we can extract the label i might be able to glue it to the partition image.

As a last chance i could try building a label "by hand" using one from an SCSI disk image. But success on that is quite unlikely.

Is it possible i could get one of the images with missing label?
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on September 13, 2013, 03:14:38 pm
I'd be happy to get the image to you, and the label. The other issue I've had with these is that I have never been able to get the MO drive working as a SCSI unit, so I really have no way to get a raw dump. I tired pretty much everything I could think of in linux to no avail... though I must claim some degree of ignorance with low-level SCSI hacking.

I actually wrote to Canon in Japan, and also to people that provided drivers for the Canon drives, and about the only real information I got was that they are a non-standard SCSI device. I couldn't even get the windows drivers, or driver sources...

You never know though, it might be possible, once we figure out what these drives actually are, to write a SCSI emulator for them. I've seen a number of  projects where people have emulated the SCSI bus using a microprocessor... they're fast enough now to support the speeds of the older devices, even while emulating SCSI.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on September 13, 2013, 05:20:21 pm
Does the drive offer an SCSI connector?
I don't know how they are connected to the NeXT mainboard. But i don't think it is SCSI. Every primitive function of the drive is controlled by software directly using some special registers (like selecting read/write head, moving head to position, etc). No command descriptor blocks are used and i can't find a reference to common SCSI signals. But i'm not an expert with these things. Maybe it is just some uncommon way of using SCSI.

btw. a different question:
On real NeXT hardware, is it possible to attach more than one MO disk drive? Controller and driver seem both to have the ability to address 2 drives.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on September 13, 2013, 05:58:27 pm
The standard interface is not SCSI, but I have a board that is supposed to make them available via SCSI, and the Canon external SCSI drives obviously had a SCSI interface (might be what this board is in fact). I wrote to Canon (in Japanese even!) and asked about getting the driver, driver source or whatnot, and I got nothing back except that they are non-standard.

I have cubes and cables for system with dual MO drives.

Thinking about it, with the low-level information it should be possible to write a microprocessor routine to do a low-level dump to an sd card or somesuch. That might be the most expedient way to get a complete disk image.
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on September 13, 2013, 08:02:08 pm
Quote from: "gtnicol"I have a board that is supposed to make them available via SCSI, and the Canon external SCSI drives obviously had a SCSI interface (might be what this board is in fact).
It's probably the controller board from the Canon L10132 enclosure which converted Canon L10130's interface (which is the same as the NeXT MO drive's) to SCSI. But it is not a standard SCSI interface, because if you try to connect the L10132 enclosure to a computer with a SCSI port (e.g. a NeXT), it won't recognize it.
Quote from: "gtnicol"I wrote to Canon (in Japanese even!)
By Jove, you speak Japanese?
Quote from: "gtnicol"I have cubes and cables for system with dual MO drives.
How does that work, is it a special cube enclosure / a cable with 3 connectors, or a special motherboard?
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on September 14, 2013, 01:39:16 am
Quote from: "tomaz"
Quote from: "gtnicol"I wrote to Canon (in Japanese even!)
By Jove, you speak Japanese?
Quote from: "gtnicol"I have cubes and cables for system with dual MO drives.
How does that work, is it a special cube enclosure / a cable with 3 connectors, or a special motherboard?


Yes, I speak Japanese and read and write (getting a bit rusty though). So I thought talking to the folk in Japan might be the best way... but no luck. I tracked down someone that used to write firmware for medical imaging devices who said he still had the docs and code, but said he was still covered by an NDA :(

As for dual drives: it's just a dual MO cable. You can fit 2 MO drives into the cube and use the dual cable to connect them together.
Title: What Needs to be done for a NeXT Emulator
Post by: tomaz on September 14, 2013, 07:31:35 am
Quote from: "gtnicol"I tracked down someone that used to write firmware for medical imaging devices who said he still had the docs and code, but said he was still covered by an NDA
By an NDA still in force? And Canon will not release him?
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on September 14, 2013, 02:03:41 pm
Apparently... not sure how true it is. People still make money from being able to convert the Canon media into modern formats... that might be part of it.
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on September 19, 2013, 10:50:04 am
Quote from: "tomaz"
Quote from: "gtnicol"I have a board that is supposed to make them available via SCSI, and the Canon external SCSI drives obviously had a SCSI interface (might be what this board is in fact).
It's probably the controller board from the Canon L10132 enclosure which converted Canon L10130's interface (which is the same as the NeXT MO drive's) to SCSI. But it is not a standard SCSI interface, because if you try to connect the L10132 enclosure to a computer with a SCSI port (e.g. a NeXT), it won't recognize it.
Quote from: "gtnicol"I wrote to Canon (in Japanese even!)
By Jove, you speak Japanese?
Quote from: "gtnicol"I have cubes and cables for system with dual MO drives.
How does that work, is it a special cube enclosure / a cable with 3 connectors, or a special motherboard?


as one can see on gtnicol's picture, there's a nice set of DIP switches on the MO-SCSI converter board. I'm wondering if altering these switches will make it possible to connect an ODD to a standard SCSI port so it will show as a standard optical drive?

Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on September 19, 2013, 01:37:24 pm
This is a little off topic, but I discovered that the 'disk' utility can read absolute sectors using ioctl. It should be possible to do something similar to generate absolute image dumps.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on September 22, 2013, 06:03:03 pm
I have good news:

After a lot of experimenting i finally understand the data structure on a magneto optical disk:

Important facts for the following table:
1 sector = 1024 bytes
1 track = 16 sectors

Offset and size is in sectors:


offset       size       name
    0          8       disk label
    4         12       bad block table
   16         64       status bitmap
   80         88       boot block
  168         88       boot block
  256     246400       partition
246880          8       disk label
246884         12       bad block table
246896         64       status bitmap
247216         16       next defect table
250288          1       canon defect table
250704          1       canon label


Bad block table overlaps with the bad block table contained inside the disk label. This is somehow strange. Maybe the overlapped table is for HDs only and the other one is specific to MO disks. The disk label, bad block table, status bitmap and boot block are duplicated on different places on the disk (for safety reasons).
The defect tables and canon label are repeated (i think 16 times each).

The canon label seems to contain some factory recorded data like lot number and production date. I think the defect table is also factory recorded.

Important note to the data structure of the partition:
The data in the partition block is split up in groups of 100 tracks each.
Every 49th track of a group is not assigned to logical block (sector) addresses (i think these are spare sectors for replacing defects).
This means each group only has 99 usable tracks. Therefore one partition has only 243936 logical sectors (249790464 byte).

While logical sectors are organized this way:
0,1,2,3, ... 47,48,49,50,51, ...
They refer to these physical sectors:
0,1,2,3, ... 47,48,50,51,52, ...

The offset is growing with every group of tracks.

I wrote a small utility in C that can convert raw images of magneto-optical disks obtained from within NeXTstep to images usable for the emulator. I plan to release it here, once it works reliably.
From the two raw images i have for testing, one makes the emulator boot via MO close to the point it goes with SCSI disk images! That is good news for the MO drive emulation code.

It would be still ideal to have some utility that can obtain raw images directly from MO disks from within NeXTstep. This would produce much more reliable results than a converting tool ever can.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on October 03, 2013, 07:40:00 am
I'm still working to improve the magneto-optical disk drive emulation. At the moment i'm playing with the diagnostic utility, trying to pass the tests.

The tests make heavy use of the ECC. I am thinking of also emulating the ECC for complete emulation.

Does anyone know what encoding is used by the MO drive?

From the datasheets that Rob posted some weeks ago (thank you!) i read it is a cross interleaved reed solomon code (CIRC), but it is probably not the one used for CD-ROM.
What we also know is that encoding one sector of 1024 bytes results in 1296 bytes of data.

The diagnostic utility has quite extensive features for monitoring the MO drive. Under the "s" menu, selecting "m.o. drive" and then "i/o" it is also possible to fill a buffer with incrementing data, encode it and print the result to the screen. The output of real hardware could be useful to reverse the ECC.

Another question has occured during development:
There is a strange offset of 4149 tracks in front of the first track that is used by NeXTstep. Is this a hardware limit? Are tracks below this limit readable/writable (for example using the diagnostic utility)?
Are tracks below 4096 still read/writeable?

The converting utility i mentioned in my previous post is not yet ready, because i need to find out some more details first.
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on October 03, 2013, 10:42:41 am
Quote from: "andreas_g"The diagnostic utility has quite extensive features for monitoring the MO drive. Under the "s" menu, selecting "m.o. drive" and then "i/o" it is also possible to fill a buffer with incrementing data, encode it and print the result to the screen. The output of real hardware could be useful to reverse the ECC.


I posted the various outputs to my flickr site -> http://www.flickr.com/photos/87645035@N04/ I hope this will help...
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on October 03, 2013, 05:24:19 pm
Thank you for the quick reply! Some of these are quite strange.

For example "dump ecc code buffer". Just to be sure, the sequence of the commands should be:

i: Fill Write Buffer with incrementing data
n: Encode (wbuf --> mo_code_buf)
o: Dump ECC Code Buffer


If then doing

d: Decode/Dump ECC Buffer

data should be:

00 01 02 03 04 05 06 07 etc
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on October 03, 2013, 05:32:39 pm
since I have no clue about the internals of the stuff you're talking about, I did it wrong, of course  :P

will run it again ASAP and (re-) post the results...
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on October 03, 2013, 05:39:57 pm
okay, upped the new screenshot. this looks more like what you were expecting. let me know if you want me to run any other tests.
Title: What Needs to be done for a NeXT Emulator
Post by: andreas_g on October 03, 2013, 05:58:58 pm
Thank you for your efforts! That one looks much better. I think it's about building parity data for rows and columns using reed solomon codes. I'm quite sure this is going to cause some headaches.   :wink:
But first of all i need to fix some DMA stuff.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on October 17, 2013, 07:54:01 pm
I found a rather interesting MO disk today.





I will dump it and make the image available soon.
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on October 17, 2013, 11:02:35 pm
Wow, that is cool!!
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on October 18, 2013, 12:21:43 am
Available at the following:

https://dl.dropboxusercontent.com/u/33134372/NeXT/mo-0215.dd
https://dl.dropboxusercontent.com/u/33134372/NeXT/mo-0215.dump.gz
https://dl.dropboxusercontent.com/u/33134372/NeXT/mo-0215.tar.gz[/list]
Title: What Needs to be done for a NeXT Emulator
Post by: eagle on October 18, 2013, 12:23:11 am
The first file doesn't exist at dropbox, and the other 2 are too small to be real files.
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on October 18, 2013, 12:24:18 am
Still syncing... eager beaver!
:lol:
Title: What Needs to be done for a NeXT Emulator
Post by: gtnicol on October 18, 2013, 12:36:51 am
Should be all set now.
Title: What Needs to be done for a NeXT Emulator
Post by: mikeboss on October 18, 2013, 10:47:19 am
Quote from: "gtnicol"Available at the following:

    https://dl.dropboxusercontent.com/u/33134372/NeXT/mo-0215.dd
    https://dl.dropboxusercontent.com/u/33134372/NeXT/mo-0215.dump.gz
    https://dl.dropboxusercontent.com/u/33134372/NeXT/mo-0215.tar.gz[/list]


    wow, what a great find  :D  thanks for sharing! I successfully restored it to an optical disk. it looks like this disk was still fresh from the factory..? there's only a single boot precedure logged in /private/adm/messages and it dates to the evening of Thursday, December 21st 1989.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on October 18, 2013, 11:47:06 am
    unfortunately, the optical disk doesn't boot. I was able to mount and read  the disk after restoring though. did I make a mistake during restore? I did it using the following command:

    dd if=/me/mo-0215.dd of=/dev/od0a

    any hints?

    edit: I now have tried it with

    dd if=/me/mo-2015.dd of=/dev/rod0a and no luck. all I'm getting is "write: Invalid argument". tried also /dev/rod0 as target without success.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cuby on October 18, 2013, 01:37:32 pm
    I assume you need a Cube with 68030 board to boot the OD image (I actually have a 030 board here)? Did anyone try to transfer the image to a hard disk partition - I would love to see NeXTstep 1.0 in action.

    Btw., you can also mount the OD dd image on MacOS X using OSXFuse's ufs driver (see https://wiki.gutzmann.com/confluence/pages/viewpage.action?pageId=6651931 for a tutorial, this also works on Mavericks).
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on October 18, 2013, 01:48:12 pm
    Quote from: "cuby"I assume you need a Cube with 68030 board to boot the OD image


    yep, I tried to boot this on a 68030 cube. I only used an 040 board to restore the .dd image to an MO. there's a 1.0a dd image floating around on the net. I successfully restored it to harddrives (or CF cards, to be precise). drop me an e-mail mb@offworld.ch and I'll send you the URL.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on October 18, 2013, 01:50:19 pm
    Quote from: "cuby"Did anyone try to transfer the image to a hard disk partition - I would love to see NeXTstep 1.0 in action.


    I guess this won't work because of the missing disk label..?
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on October 18, 2013, 02:11:58 pm
    okay, tried it again with dd. unfortunately no luck so far. this is what I get:

    CPU MC68030 25 MHz, memory 100 nS
    Backplane slot #0
    Ethernet address: 0:0:0:0:0:0
    Memory size 16MB

    NeXT>bod
    boot od(0,0,0)
    blk0 boot: od()sdmach
    read error
    load failed

    blk0 boot:
    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on October 18, 2013, 02:19:48 pm
    Let me verify the disk tonight, but I think you probably do need to provide a boot label etc. in order to boot.

    Seems like I really need to finish the raw sector dump command... and couple it with a restore command :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on October 18, 2013, 03:17:30 pm
    Quote from: "gtnicol"Let me verify the disk tonight, but I think you probably do need to provide a boot label etc. in order to boot.

    Seems like I really need to finish the raw sector dump command... and couple it with a restore command :)


    I don't think that there's anything wrong with your diskimages. I guess I figured it out: booted the cube from 1.0a on the harddrive and made the MO bootable by issuing the command "disk -b /dev/od0a"  8) this definitely did the trick: the MO is booting now!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 18, 2013, 04:03:08 pm
    gtnicol, thank you for providing the image!
    I used my disk label voodoo utility on it and it boots the diagnostics on the emulator. It also tries booting NeXTstep, but hangs on the usual place (likely CPU related problem). So the image is definitely fine.

    I already had the diagnostic utility running from an SCSI disk image. It is quite useful, because it is very "verbose" with error messages.

    The emulator already passes some of the MO tests (Flag Register W/R, Random Write/Read, Sequential Wr/Rd, W/R Commands, Relative Jump, Seek Time), but fails on all ECC tests (just because it is not emulated) and the Erase Command and Bad ID tests.

    Failing the Erase Command test is strange. It tells me that it successfully reads a sector after erasing (which is of course bad), but in fact it only reads zeroes. Maybe the sector should contain some pattern instead of zeroes after erasing, or the drive should indicate some kind of error.

    Two other things are not yet clear:
    I don't know that the 7 "flag" registers are for. They are initialized with some values, but nothing else seems to happen with them.

    There are 3 registers called "ID" or track#/sector# (2 byte for track, one for sector). They are written with what i think is the actual track and sector to access. But the head is positioned (using seek command) one or more tracks in front the one defined in the ID registers. It is not always the same offset, so this is somehow strange.

    Unfortunately often it is not clear to me what the utility expects to successfully pass a test.
    Has anyone an idea how these things should work in real hardware?

    mikeboss, i read from your last post you already fixed the boot problem. Or is there more need for assistance with the boot block/label problem?
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on October 18, 2013, 04:22:05 pm
    Quote from: "andreas_g"mikeboss, i read from your last post you already fixed the boot problem. Or is there more need for assistance with the boot block/label problem?


    thanks for asking! everything's working fine now.

    downloaded gtnicols image
    moved it from my Mac to the cube via FTP.
    took an MO disk (which still was shrinkwrapped)  :P
    printed the scans of the cover and inlay  8)
    then I let NeXTstep 3.3 initialize the fresh MO disk
    unmount the freshly created volume
    issued the command "dd if=/me/mo-0215.dd of=/dev/od0a"
    waited for 1,5 or 2,0 hours   :roll:
    shutdown the cube
    replace 68040 board with the 68030 board
    replaced the CF card containing NS 3.3 with one containing NS 1.0a
    boot the cube from the CF card
    issued the command "disk -b /dev/od0a" (or was it "disk -b /dev/rod0a" ?)
    shutdown and disconnect the CF card (harddrive)
    booted 1.0a from the MO disk successfully  :lol:
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on October 19, 2013, 07:15:20 pm
    I installed NeXTstep 1.0a from the optical disk to a 1GB hard drive and then made an image of it (diagnostics included). I'll be happy to share if anyone's interested...
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on October 21, 2013, 12:01:49 am
    Quote from: "mikeboss"I installed NeXTstep 1.0a from the optical disk to a 1GB hard drive and then made an image of it (diagnostics included). I'll be happy to share if anyone's interested...

    I would love to have that.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 25, 2013, 12:51:36 pm
    mikeboss, the above procedure sounds quite complicated. But i guess it was fun   :wink:

    btw. the SCSI image might be useful at some point for direct SCSI - MO comparison. I'm intersted.

    In the last days i have worked to improve my disk image converting tool, that should create full MO images from raw partition dumps. But i'm missing an important detail:

    The kernel driver does access physical track number 4149 as logical track 0, the diagnostic utility by default accesses track number 4096 as lowest track. But what is really the first accessible track on a physical media?
    Does anyone have an idea? I guess it can be tested using the diagnostic utility. First and last track for the testing area can be modifyed (default 0x1000 = 4096).

    Alternatively i could just add all 4096 tracks to the beginning of the image with the risk that real world non-accessible tracks can be accessed on the emulator. Maybe not a big problem, but also not perfect, as it potentially wasts 64 MB host machine disk space for every disk image.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 27, 2013, 04:33:04 pm
    I wrote a small utility that can convert raw partition images of MO disks that have been made from within NeXTstep to full disk images suitable for Previous.

    You can load it here:
    od_builddisk 0.1 (https://dl.dropboxusercontent.com/u/44703754/od_builddisk_0.1.zip)

    Besides the image you also need a block0 boot executable, normally located in /usr/standalone.

    The command can be used like this:
    od_builddisk <label version> <boot file> <partition file>

    WARNING:
    This program is highly experimental and contains known problems. Do not start to convert your images. It is likely that future changes to Previous will make those images useless.
    I don't recommend using this utility on NeXT hardware, because it is very slow.

    Any suggestion on improving this tool is welcome. Also if it is just about improving coding style.

    Such utility will never be perfect and is likely to fail on certain images. For getting reliable results, it would be necessary to write a tool for making full disk images directly from within NeXTstep. It would need to be able to directly read physical sectors.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on November 06, 2013, 07:26:40 am
    A community member, who has not been able to register to this forum (there are registration problems also reported by others) has posted some hints on how to make full disk images using NeXTstep at nextcomputers.ch. I can't test it myself, but maybe it helps to make full images for the emulator (should work for both, SCSI disks and MO disks).

    Quote from NXScribbler:

    Quote from: "andreas_g"With standard commands, like dd, we can only read partition data, but not the sectors that are located on the disk in front of and after the partition. There is not only the disk label, but also a bitmap, the boot block, spare sectors, bad sector tables and other important data that is required for booting.


    The standard way to read from or write to anywhere on a 4.3BSD disk is via the device file associated with the pseudo-partition 'h'. This works even if there is no label or anything on the disk, and it works for "sd" as well as "hd" disks.

    If I wanted to read sectors from a disk, for example the first SCSI disk, and I were to use (code without error checking, etc., just informative):

    fd = open("/dev/rsd0a", O_RDONLY); // unbuffered access
    lseek(fd, 0, L_SET); // (or SEEK_SET) position read ptr to offset 0
    read(fd, buf, 512); // read 512 bytes to buffer


    it would indeed read the first sector of the first BSD partition to the buffer, assuming a drive sector size of 512 bytes. (Instead of open() , lseek() , read() one could also use the corresponding functions fopen() , fseek() and fread() , of course.)

    But if I wanted access to other parts of the disk, I would use:

    fd = open("/dev/rsd0h", O_RDONLY);
    lseek(fd, 0, L_SET);
    read(fd, buf, 512);


    This would give me the very first sector of the whole disk , ie where the MBR is, or the first part of the first disk label if there is no partition table (sector 0 in LBA terms, or cylinder 0, head 0, sector 1 in CHS terms).

    The 'h' partition is not a real partition, like 'a'...'g', but signals to the lower level routines that access to the whole disk is required (it needs superuser privileges, BTW). It doesn't matter at all what is written in the partition table about it, it is always available. fdisk for instance uses it to write a partition table entry to the first sector of an empty disk.

    This works for SCSI and ATA disks. I am not in a position to test it with a magneto-optical disk, but I am reasonably sure it should work the same way, substituting "od" for "sd".

    Change the offset in lseek() to direct it to other sectors, put it inside a loop and there you have your disk copier (within the 2 GiB limit of off_t of course). Or simpler still, just give the command

    dd if=/dev/rsd0h of=sd0.img

    As far as I know, that would produce a 1:1 disk image, but I've so far only used it for parts of a disk.

    Beyond that limit, ioctl() calls are to be used (there are special ioctl() commands for label reading or writing, but general access commands are usable as well there).
    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on November 06, 2013, 02:03:07 pm
    I'll give the 'h' dd a test tonight, but I believe I tried that and it didn't work.

    There is a guy that has tried to register that apparently has a utility for doing raw disk dumps.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 06, 2013, 02:18:28 pm
    at least for me, it didn't work ->

    http://www.nextcomputers.ch
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 06, 2013, 02:24:52 pm
    Quote from: "gtnicol"There is a guy that has tried to register that apparently has a utility for doing raw disk dumps.


    http://www.nextcomputers.ch is open for registrations...
    Title: What Needs to be done for a NeXT Emulator
    Post by: scarecrow on November 06, 2013, 06:19:16 pm
    Quote from: "mikeboss"
    Quote from: "gtnicol"There is a guy that has tried to register that apparently has a utility for doing raw disk dumps.


    http://www.nextcomputers.ch is open for registrations...


    "An Error Has Occurred!
    The captcha solution provided is wrong."
    Isn't cat say "Meow" ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 11, 2013, 01:07:25 pm
    I tried it (clicked many times until the meow question turned up...). entered "cat" and the registration went through. hm... you might want try again...
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on January 19, 2014, 05:08:58 pm
    What is the current state of Previous?

    I am creating/created a Previous Mirror -  https://sites.google.com/site/previousmiror/
    Title: What Needs to be done for a NeXT Emulator
    Post by: pitz on January 20, 2014, 05:49:08 pm
    Quote from: "Mominul"What is the current state of Previous?

    I am creating/created a Previous Mirror -  https://sites.google.com/site/previousmiror/


    So, if we mirror this mirror, would it be the next mirror of the previous mirror? :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on January 23, 2014, 06:25:17 am
    Where is the new binary of Previous? I want to play with that! :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on January 26, 2014, 01:25:42 pm
    First i want to provide an update on the state of Previous:

    I have improved SCSI to a good state. Some instructions are not yet emulated, but should be easy to be added as needed.
    I added a fully working MO disk drive emulation, including a working ECC (thanks to Henry Minsky's Reed Solomon Library: http://rscode.sourceforge.net/)!
    The DMA channels for both mass storage devices are also improved to a good state.
    Booting should be possible from both, SCSI disk images and MO disk images.

    But now comes the bad news:
    Previous still suffers from a CPU problem, that i can't fix. I asked Toni Wilen (programmer of WinUAE) for help. He is willing to help fixing the problem, but he needs a working MSVC project to work on. Previous does currently not compile using MSVC. As i don't have a machine running the Windows platform, i can't do this myself.
    I asked a guy for help, who did build an MSVC project for Hatari some time ago. But he could not complete his work on Previous because of restricted time ressources.

    I'm still looking for someone to make Previous build using MSVC. The project can be easily built using Cmake (http://www.cmake.org/). But dependencies need to be fixed.

    I'll have to wait for a CPU fix, until i can do anything useful on Previous.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on January 26, 2014, 06:02:55 pm
    I cannot help about MSVC(Microsoft Visual C++) Because I am a Microsoft Visual Basic 6 Programmer.You can try to make a VM and install Windows and install MSVC.
    Or,
    Please see this link to install Windows on a Mac -
    Mac Basics: Using Windows on your Mac via Boot Camp (http://support.apple.com/kb/ht1461)
    How to Install Boot Camp and Run Windows on Your Mac (http://www.pcworld.com/article/249059/how_to_install_boot_camp_and_run_windows_on_your_mac.html)
    Please don't mind if I make some mistakes! :oops:
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on January 26, 2014, 06:24:28 pm
    Thanks for the hint. I know the ways to run Windows on a Mac, but i don't plan to set up and learn all these things. That would cost me lots of time compared to someone who already works on this platform.
    I hope someone with a running system and some skills in compiling on that platform can help with this.
    Is anyone interested in helping or knows someone with the wanted skills?

    I'm sure Toni Wilen can fix the CPU afterwards, because on WinUAE he already succeeded running Amix and Linux (these are both UNIX(-like) systems like NeXTstep, that use the MMU for memory management).

    btw.: WinUAE now uses Previous' 68030 MMU logic  :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on January 27, 2014, 01:06:46 pm
    For Ethernet please see the Basilisk II(Because Basilisk II has Ethernet and it also works!{I have checked by SheepSaver because SheepSaver uses the Basilisk II drivers and ethernet interface})
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on January 27, 2014, 01:28:30 pm
    Things like Ethernet do not have priority for now.

    At the moment the only thing we need is a working MSVC project for Toni Wilen to fix our CPU like described above. We really need to concentrate on that now.

    Clarification: I can't continue my work on Previous without this. I am looking for help!
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on January 29, 2014, 01:20:21 pm
    I can take a stab at MSVC... what version does he need? 2010? 2013?

    Also where can I grab the source?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on January 29, 2014, 06:12:38 pm
    neozeed, thank you very much for your offer! The target version would be 2010 or 2013, but 2013 is preferred.
    The code can be downloaded at http://sourceforge.net/p/previous/code/HEAD/tree/ as a zip file or via subversion. The actual development branch is /branches/branch_mmu. The basic project structure can be build with cmake.
    If there are any issues, please report back.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on February 19, 2014, 05:48:09 pm


    Good news!

    Toni Wilen helped me to port WinUAE's latest CPU emulation code to Previous. After fixing a bug in the MMU and one in the FPU we are now able to boot up to single user mode!   :D

    Many thanks go to Toni and Vaughan Kaufman, who helped building an MSVC project.

    I am in contact with Toni and we are trying to find a timing related bug that prevents Previous from working on his system. Also i have to add WinUAE's latest FPU to Previous. That will be the next step. Then i'll try to find the cause, why we are not yet going to the login screen. But we are much closer now!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on February 19, 2014, 05:53:32 pm
    WOW WOW WOW WOW WOW

    AMAZING WORK!  I am so excited and impressed.  I am blown away.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on February 19, 2014, 06:00:19 pm
    Very Good News! :D  But I am sad because I can't help with that :(
    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on February 19, 2014, 06:15:54 pm
    Wow, that's awesome! We're very close to having a real emulator now.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on February 19, 2014, 07:41:25 pm
    I know it has been only hours, but I am still very excited over this new development!
    Title: What Needs to be done for a NeXT Emulator
    Post by: barcher174 on February 20, 2014, 03:19:08 am
    Very cool!
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on February 20, 2014, 03:31:11 am
    Superb work!!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on February 20, 2014, 09:23:18 am
    Thanks for all the nice words!

    I got a question for all command line experts:
    In the later stages of booting the processes no longer log their error messages to the screen but to log files. Where are the relevant logs located? How can i read them from single user mode?

    Window server does not start up at the moment. I hope it logs an error. Error and status messages are essential for debugging.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on February 20, 2014, 09:28:57 am
    AFAIK the log you want to have a look at is /private/adm/messages but it's not too verbose...
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on February 20, 2014, 11:00:41 am
    Andreas, if you still have an incomplete or in any way questionable FPU emulation then DisplayPostscript may be affected and preventing the GUI from starting up...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on February 20, 2014, 07:31:41 pm
    Finally i was able to add Toni Wilen's FPU patch. What happend then, was a surprise ...



    There is a lot to do before this gets really useful. If anyone wants to join with programming, i'd be really happy.
    There are some drawing glitches with fonts. I think that is a remaining FPU problem. Also it panics early because the sound DMA channel fails (it is simply missing from emulation, easy to add a dummy for that). And no mouse emulation yet.
    Earlier versions than 2.x do not yet work. They go to some endless loop restarting the Workspace Manager. My next task is trying to fix that.

    But first i'll have a brake   :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on February 20, 2014, 07:44:16 pm
    Andreas, you deserve a break!  WOW WOW WOW

    This is so amazing and exciting!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on February 20, 2014, 09:13:20 pm
    Fabulous work, you're getting so close!
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on February 21, 2014, 12:00:13 am
    Once again Andreas, superb work!  I am delighted that patching the FPU was so effective!
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on February 23, 2014, 05:12:30 pm
    Quote from: "andreas_g"Finally i was able to add Toni Wilen's FPU patch. What happend then, was a surprise ...


    That surprise looks awesome. :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on February 24, 2014, 02:56:56 pm
    WOW WOW WOW WOW
    Very good news! Excellent Work  andreas_g ! Keep Going! :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: Shuren on February 25, 2014, 02:50:42 pm
    Great work!
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on February 26, 2014, 04:48:54 am
    Hi, result of recent work by andreas and toni is really amazing. Binaries will soon be on the website (that was down due to an attack on the server weeks ago).
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on February 27, 2014, 05:36:14 pm
    I updated the Wikipedia entry on the Previous emulator (https://en.wikipedia.org/wiki/Previous_(emulator)) to the latest version v4.0.
    If you have more information to add or enhance, please contact me.

    (I was the original author of this page, too. I wrote it almost 2 years ago (06/2012) to help to track information about the emulator)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on February 28, 2014, 03:34:15 pm
    A new version of Hatari Released! This is the all information I found on the site -

    Quote2013-06-24: Version 1.7.0
    Hatari 1.7.0 has been released. You can download it from http://download.tuxfamily.org/hatari/1.7.0
    Thanks to all the people who contributed to this version with code, ideas, bug reports. Let's keep on improving Hatari !
    Experimental MMU for the 68030 mode
    Improved IKBD/ACIA : full ACIA emulation (timings, serial link, registers)
    Much more accurate MFP : simultaneous interrupts, delayed IRQ, IACK cycles
    IACK cycles for CPU's exceptions (HBL and VBL)
    FDC : better GAPs' timings, angular speed/position used when accessing data
    TT video emulation, with better video modes
    Bug fixes for Gemdos HD emulation
    Some changes to the SDL UI (fileselector, drive LED)
    Lot of improvements to the debugger and to the profiler (CPU and DSP)
    See release-notes.txt for more details.

    So, We can update Previous by the new source code of Hatari!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on February 28, 2014, 05:00:50 pm
    This is the new Home of Previous Mirror -
    https://sites.google.com/site/previousmirror/
    Please give suggestions , reports to nahidbinbaten1995@gmail.com
    If I get any success to build Previous for windows I will post the Manuals!
    To post the manuals I need Your help! Please Help me!
    Title: What Needs to be done for a NeXT Emulator
    Post by: NeXTsociety on March 01, 2014, 05:41:10 am
    Is this Hatari for NeXTSTEP or something?

    Would be cool to have a 68040 Atari running on a Cube.  ;-)

    TJ

    Quote from: "Mominul"A new version of Hatari Released! This is the all information I found on the site -

    Quote2013-06-24: Version 1.7.0
    Hatari 1.7.0 has been released. You can download it from http://download.tuxfamily.org/hatari/1.7.0
    Thanks to all the people who contributed to this version with code, ideas, bug reports. Let's keep on improving Hatari !
    Experimental MMU for the 68030 mode
    Improved IKBD/ACIA : full ACIA emulation (timings, serial link, registers)
    Much more accurate MFP : simultaneous interrupts, delayed IRQ, IACK cycles
    IACK cycles for CPU's exceptions (HBL and VBL)
    FDC : better GAPs' timings, angular speed/position used when accessing data
    TT video emulation, with better video modes
    Bug fixes for Gemdos HD emulation
    Some changes to the SDL UI (fileselector, drive LED)
    Lot of improvements to the debugger and to the profiler (CPU and DSP)
    See release-notes.txt for more details.

    So, We can update Previous by the new source code of Hatari!
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 01, 2014, 06:32:03 am
    Life of emulator is a bit more complex than it seems :)

    Hatari derives from aranym that used a derivative version of UAE CPU core.
    Then Hatari moved to winUAE cpu core, we may consider winUAE the "reference" of most 68k emulators at present time.
    Previous is a spin off of Hatari 1.5.
    Hatari 1.6 used some fixes that I did for previous (merged from winUAE but also corrected for page size and converted to plain C instead of C++ (with weird macros...)).
    Then Andreas did a really huge work on 68030 MMU for previous.
    Hatari 1.7 and winUAE now merged in Andrea's code.

    The point is that all of the 3 emulators are linked at early developpment stage, but does not depend on a stable release like hatari 1.7. Anyway, a new hatari version is a good news... to play atari games and demos ;)
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on March 01, 2014, 04:03:23 pm
    Quote from: "NeXTsociety"Is this Hatari for NeXTSTEP or something?

    Would be cool to have a 68040 Atari running on a Cube.  ;-)


    You will need SDL for NeXTSTEP, or an hard work to get it running, plus very low performances....

    JV
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 02, 2014, 11:22:37 am
    now in color...

    (https://imageshack.com/i/jmyq7dp)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on March 02, 2014, 12:23:41 pm
    Very nice! That's emulating the NeXTstation Color's gfx chip I suppose?
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 02, 2014, 12:29:00 pm
    it's the 12bit mode of color station (non turbo yet because it seems turbo (or latest rom versions) probes for a smaller screen size by default). We will need to emulate a bit more of the chip for a correct detection.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on March 02, 2014, 03:29:16 pm
    Is there is a Mouse emulation? And Great Work Gilles!!!!!!!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 02, 2014, 05:02:02 pm
    mouse is emulated but may get out ouf sync with the window (it is a very common problem with emulators).

    Most of recent work was done by Andreas, not by me ;)
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on March 03, 2014, 12:20:06 pm
    How dow you install Nextstep in Previous ? I have Nextstep/openstep ISO, floppy image, but there is no floppy emulation ???
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 03, 2014, 01:46:21 pm
    Wow, gilles and andreas, this is such amazing work.  I can't wait to play with it myself!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 03, 2014, 06:35:29 pm
    Quote from: "jvernet"How dow you install Nextstep in Previous ? I have Nextstep/openstep ISO, floppy image, but there is no floppy emulation ???

    You can just add the floppy image as an SCSI device (i think on real hardware it would also work with an SCSI floppy drive).

    Make sure you add an empty raw image file as SCSI disk 0. You will have problems rebooting, if you choose a higher number for the drive.
    If you add the floppy as disk 1, boot from ROM monitor with bsd(1,0,0).

    Quote from: "gilles"Most of recent work was done by Andreas, not by me

    Gilles made the fundamentals that enabled me to add some devices and the 68030 MMU. Toni Wilen worked on the CPU side and provided important patches.

    Good work with adding color! All non-turbo systems are on the same state now.
    I plan to build a release soon. But there is still a bug that needs to be fixed. It is either DMA or CPU/MMU/FPU related.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on March 04, 2014, 09:53:23 am
    Quote from: "andreas_g"Good work with adding color! All non-turbo systems are on the same state now.


    That sounds really great. I may finally end up with a color NeXT system, of sorts! :)

    Out of interest - since all of this is running emulated hardware, would there be any significant performance differences between an emulated turbo system and an emulated non-turbo one (on the same 'host' system)? Or from a different view, is the emulation trying to emulate the original performance, or can it simply run "as fast as possible" on the current host?

    Best wishes,

    // Christian
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 04, 2014, 10:21:04 am
    Peronally, i'd like to make it emulate original speed with an option to increase to higher performance. I like the way Mini vMac does it. There you can choose 1x, 2x, 4x ... and "all out".

    Timings are not correct at the moment. It runs just at some undefined speed. There needs some work to be done to adapt timings for Previous. I didn't work on that yet.

    Emulating Turbo systems is not a priority for now. But maybe i will add it some day to enable 128 MB RAM.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 04, 2014, 01:20:26 pm
    Andreas, I like that about Mini vMac too.  I often run at 1x setting just to make it as close as possible to an original Mac Plus.  It would be excellent to see such a feature on the NeXT emulator.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 04, 2014, 06:33:33 pm
    Finally, Previous is also able to boot NeXTstep 0.x and 1.x!    :D

    There is a missing feature. Addressing RAM at special address offsets should combine the existing value in memory with the written value using a function. I don't know how exactly that should work, so for now there is only a dummy.
    That causes for example the white squares underneath the icons in the dock. Once i find out how it should work, i will fix that. If anyone has an idea, please share it.

    Now all systems from 0.9 up to 3.3 are booting. This is a good starting point for further work.

    Title: What Needs to be done for a NeXT Emulator
    Post by: cuby on March 04, 2014, 07:50:18 pm
    Great work! I got Previous (Revision: 320) to run and boot from the 3.2 NeXT floppy and the 3.3 as well as 4.2 OpenStep CD ROM. However, the emulation hangs after mounting the root file system in both cases (no virtual LED activity, so I suppose it has stopped reading the CD image).

    I'm using the 1.0 ROM, the 68030 emulation with 64MB RAM, a 180MB disk drive (empty image) on SCSI ID 0, the floppy image on ID1 and the CD-ROM image on ID6 with the "CD-ROM" checkbox active. Previous runs on OSX 10.9.2 on an iMac 21.5" 2009 (Core2Duo 3.06 GHz).

    Any idea what might go wrong here?

    -- Michael

    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on March 04, 2014, 09:03:55 pm
    outstanding work! the progress over the last weeks has been very, very impressive. simply jawdropping. can't wait to give it a try...
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on March 04, 2014, 09:15:11 pm
    Quote from: "andreas_g"

    Make sure you add an empty raw image file as SCSI disk 0. You will have problems rebooting, if you choose a higher number for the drive.
    If you add the floppy as disk 1, boot from ROM monitor with bsd(1,0,0).


    Doesn't succeeded.. I can't even type bsd(1,0,0) on my french MacBook Keyboard.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jroark on March 04, 2014, 10:15:25 pm
    First of all, very cool!

    What's the process for creating a hdd NS can install on?

    I tried:

    $ dd if=/dev/zero of=sda bs=512 count=2097152

    and then

    $ fdisk -i -a dos sda

    but I always get a error initializing the disk

    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 04, 2014, 10:29:07 pm
    cuby, this hang is a known problem. Unfortunately i have the same issue in certain conditions. The reason is unknown at the moment. You can try a different system (68040). That may work, or may not. I hope to find the cause.

    jvernet, bad key assignment is a known problem too. Some help with this would be great! As a workaround you could try changing the keyboard layout on the host system. For normal letters it works for me. "(" is shift+9 and ")" is shift+0 for me.

    jroak and others: If you use the code from sourceforge, please make sure to enable disk writing in scsi.c, line 578 (change #if 0 to #if 1) and in mo.c, line 1190 (same change). There is a risk of disk image corruption, as the emulator is not yet complete and not tested in all conditions. Only use copies of your images!

    This is software in development. If you use it in this stage, you are likely to find lots of bugs and broken or missing features.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on March 05, 2014, 10:59:00 am
    I know that it's 'bad', but a preinstalled Nextep 3.3 HDD image hosted somewhere would be great.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on March 05, 2014, 08:18:44 pm
    I was wondering ... When you install NeXTSTEP 3.3 for x86 isn't that made of fat binaries? If so, could an install made in VMWare be used as the boot drive in Previous? Or does lippo run at the end of the of install and strip the m68k bits out?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 06, 2014, 12:20:21 am
    Noth, I expect that the installs are very different, but that you could take fat binaries from either install (m68k or x86) and use them on the other platform.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 06, 2014, 06:20:10 pm
    Hey guys,

    I've successfully installed OPENSTEP 4.2 on Previous 0.4 (r321)
    The only problem that I have now is that I can't continue the boot sequence as I need to press Control-C to skip the network configuration. Unfortunately key mapping is wrong and it doesn't work. Any idea?

    Anyway thank you for your amazing work you've done on Previous so far, it's stunning!  :)

    Cheers

    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 06, 2014, 06:42:12 pm
    Nice to see, that OPENSTEP works too. I didn't test it myself.

    Control+C should normally work. If you built from unmodified sources, it should log all keypresses with a message like this:

    Key pressed: left ctrl
    Keycode: $00, Modifiers: $00
    Key pressed: c
    Keycode: $33, Modifiers: $08


    Maybe you find the correct key this way. I'm afraid i can't help more at the moment.

    Update: This might be a problem with SDL. It seems not to send the modifier, if no other key is pressed. Maybe you can try pressing C multiple times while holding down CTRL or first press CTRL with some invalid key, like F1, and then press C while holding it down.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 06, 2014, 06:52:02 pm
    It does!

    Quote
    Key pressed: left ctrl
    Keycode: $00, Modifiers: $00
    Key pressed: c
    Keycode: $33, Modifiers: $08
    Key released: c
    Keycode: $33, Modkeys: $08
    Key released: left ctrl
    Keycode: $00, Modkeys: $00


    I will try but it doesn't seem to work, stay tuned
    Update: Nope not working
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 06, 2014, 07:02:51 pm
    Not shure why i doesn't work, because both codes are sent. But maybe the control key must be sent first without C. I'll set it on my list of bugs.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cuby on March 06, 2014, 08:57:51 pm
    Quote from: "Arths"I've successfully installed OPENSTEP 4.2 on Previous 0.4 (r321)
    The only problem that I have now is that I can't continue the boot sequence as I need to press Control-C to skip the network configuration. Unfortunately key mapping is wrong and it doesn't work. Any idea?

    Quick fix: boot in single user mode (bsd -s in ROM monitor) and edit /etc/hostconfig, change the NETMASTER entry to "-YES-" and edit IP address, netmask, router and hostname. Then reboot.

    Meanwhiles, I got NeXTstep 3.3 to install and boot after fiddling with the setup. However, it usually crashes with an 68040 MMU exception when trying to start an application. The workspace itself comes up fine in most cases.

    -- Michael
    Title: What Needs to be done for a NeXT Emulator
    Post by: cuby on March 06, 2014, 08:59:57 pm
    A nice trick that might help with debugging - you can mount the NeXTstep CD images and also the created disk image using FUSE and the ufs file system (nextstep/nextstep-cd). See https://wiki.gutzmann.com/confluence/pages/viewpage.action?pageId=6651931 for information how to compile this filesystem with the current version of OSXFUSE.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 08, 2014, 01:24:50 pm
    Quote from: "cuby"
    Quote from: "Arths"I've successfully installed OPENSTEP 4.2 on Previous 0.4 (r321)
    The only problem that I have now is that I can't continue the boot sequence as I need to press Control-C to skip the network configuration. Unfortunately key mapping is wrong and it doesn't work. Any idea?

    Quick fix: boot in single user mode (bsd -s in ROM monitor) and edit /etc/hostconfig, change the NETMASTER entry to "-YES-" and edit IP address, netmask, router and hostname. Then reboot.

    Meanwhiles, I got NeXTstep 3.3 to install and boot after fiddling with the setup. However, it usually crashes with an 68040 MMU exception when trying to start an application. The workspace itself comes up fine in most cases.

    -- Michael


    Would work  :)
    But as my keyboard is not properly recognized, it's not that easy to modify this file in single user mode. Better wait for a fix on SVN  :wink:
    In the meantime I always have OPENSTEP in Virtualbox ready to run
    Thanks for your help anyway, I appreciate it

    Cheers
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 08, 2014, 05:56:37 pm
    First off, it's amazing to see how far previous has come recently. It's an exciting time!

    I feel a bit silly asking this, but after compiling previous (r324) here on 10.6.8 and trying for the last hour I still can't get anything to boot.

    I have some OD dumps (0.9, 1.0, 2.0) that I got a few years back from kb7sqi's ftp but when I attach those and try to boot them from the ROM Monitor with "bod" I get "no valid disk label found". Am I doing something wrong or are these dumps bad?

    Update: The closest I've managed so far is to partially boot NS3.3 and OS4.2 but they hang at the same place as for cuby earlier (root on sd2a). But in any case I'd really like to run the earlier stuff. I tried the NS2.2 CD (iso attached to scsi disk 6, floppy image from the cd attached as disk 1, 512mb blank disk attached as disk 0) but it always ended up in a cpu panic.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 08, 2014, 09:13:35 pm
    protokol7, unfortunately it is not possible to use existing MO images directly. This is caused by the differences between the logical and physical layout of the disks. Once everything works, you can copy them back to a disk image using dd from within the emulator.

    The hang is a known issue, which i unfortunately could not fix yet.

    I don't know why 2.2 panics during the boot process. It might be an issue with adding it as SCSI. That works for 3.2 and 3.3, but i have no experiences with 2.2, as i don't have the media.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 08, 2014, 10:09:34 pm
    Thanks for the info andreas. I'm assuming these files are MO dumps. As I said, I got them a few years back and they're named NeXT_0.9.dump.Z, NeXT_1.0.dump.Z etc.

    When I saw your screenshot of 1.0a running I got excited and thought I'd be able to boot these. Guess I'll have to hold out until I can get some version of NS to install and boot.

    As for 2.2 I'm not sure how to even use that. It's not a traditional install CD. Instead it contains floppy and dump images of NS2.2. AFAIK I only have to boot from the floppy and it will write the dmp file on the CD to hard disk. But I haven't gotten that far yet.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 08, 2014, 10:24:56 pm
    The images ending on .dump are most likely made with the dump utility. These archives only contain the files, but no filesystem. They can be copied back to an initialized filesystem with the restore utility. As with raw images, this can be done from within the emulator too.

    I'm sorry i can't make a release now. But with the remaining kernel panic bug on 68040 and the "root on ..." boot hang bug it would be too early.
    My plan is to fix these two before releasing 0.4, and fix all others afterwards.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 08, 2014, 10:33:39 pm
    Thanks again andreas. I haven't used NS/OS in a while now so I forgot about the dump/restore thing. That would explain why I couldn't boot from them :oops:

    I'll focus on 3.x and see if I can get any of them to boot.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on March 09, 2014, 11:49:20 am
    Is there is a way to use dump files in previous? Because I have also a dump file of next step 0.9.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 09, 2014, 12:46:41 pm
    Quote from: "Mominul"Is there is a way to use dump files in previous? Because I have also a dump file of next step 0.9.

    After managing to get NS3.2 up and running last night I restored my NS1.0 dump file to a hard disk inside Previous. Initially it wouldn't boot, but I think that was because I didn't edit the fstab. I've successfully restored and booted the few dumps I have so here's the process I use:

    Build a ISO image file containing the dump files and attach it as a  CDROM. (i use  "mkisofs -o /path/to/output.iso -R -V "Dumps" /path/to/folderwithfiles" for this)
    Add a second hard disk to Previous.
    Boot into NS/OS and let it initialise the new disk (or do it from the terminal with disk)
    Launch terminal and run the following commands:
    su (if not logged in as root)
    cd /UntitledDisk (or whatever the new disk is called)
    rm -rf lost+found .NextTrash
    restore rf /CDWithDumps/file.dump
    rm restoresymtable

    Now open /etc/fstab from the newly restored disk and change the /dev/od0a entry to /dev/sd0a.

    Update 2: I tried restoring the NS1.0 dump file from NS2.2 and this time it worked. After restoring it and editing the fstab to change od0a to sd0a I can boot all the way up to loading the Workspace. Then I just get the NeXT tile loading and crashing over and over. So close...

    Update: Managed to get NS2.2 to install. Not sure if the panics earlier were down to an uninitialised hard disk image or not specifying the rootdev (or both) but it's all good now 8)

    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 09, 2014, 09:17:17 pm
    protocol7, the panic you had with 2.2 install disk happend because it tries using the wrong root device. I verifed it.

    For 1.0: are your sources up to date with branch_mmu? I had the same behaviour before adding a hack for memory write functions.

    To everyone:

    I have not been able to reverse the memory write functions. They are used for some wired two bit graphics drawing. Early versions of NeXTstep (<2) use them a lot. I need your help! The functions need to be tested on real hardware. The following procedure will work on 68030 Cubes. It might also work on other non-turbo monochrome systems, but i'm not sure about that.
    In the following instruction "-" stands for some random value that can be ignored, "x" stands for the value i am looking for.

    This would be the procedure:
    1. Go to ROM monitor.
    2. Type "e 04001000" and hit enter
    3. After the question mark, type "0055aaff" and hit enter
    4. After the next question mark, type "." (it will drop you back to the prompt)
    5. Type "e 10001000" and hit enter
    6. Note the value and after the question mark, type "1b1b1b1b" and hit enter
    7. After the next question mark, type "."
    8. Type "e 04001000" and hit enter
    9. Note resulting value and type "."
    --> repeat step 2 to 9 with following values:

    For step 5 use values 14001000, 18001000 and 1c001000
    Then change the value in step 2 and 8 to 0b001000 and repeat with values in step 5 beeing 0c001000, 0d001000, 0e001000, 0f001000.

    If you make a typo, just restart the above sub-sequence from 2-9 (not the whole sequence).
    Note: when writing to the 0b... addresses you will see some pixels beeing changed on top of the screen. That is normal, because we write to VRAM.

    Please always note the values from step 6 and 9 together with the address from step 5.

    The result should look like this:

    e 04001000
    4001000: --------? 0055aaff
    4001004: --------? .
    e 10001000
    10001000: xxxxxxxx? 1b1b1b1b
    10001004: --------? .
    e 04001000
    4001000: xxxxxxxx? .

    e 04001000
    4001000: --------? 0055aaff
    4001004: --------? .
    e 14001000
    14001000: xxxxxxxx? 1b1b1b1b
    14001004: --------? .
    e 04001000
    4001000: xxxxxxxx? .

    e 04001000
    4001000: --------? 0055aaff
    4001004: --------? .
    e 18001000
    18001000: xxxxxxxx? 1b1b1b1b
    18001004: --------? .
    e 04001000
    4001000: xxxxxxxx? .

    e 04001000
    4001000: --------? 0055aaff
    4001004: --------? .
    e 1c001000
    1c001000: xxxxxxxx? 1b1b1b1b
    1c001004: --------? .
    e 04001000
    4001000: xxxxxxxx? .

    e 0b001000
    b001000: --------? 0055aaff
    b001004: --------? .
    e 0c001000
    c001000: xxxxxxxx? 1b1b1b1b
    c001004: --------? .
    e 0b001000
    b001000: xxxxxxxx? .

    e 0b001000
    b001000: --------? 0055aaff
    b001004: --------? .
    e 0d001000
    d001000: xxxxxxxx? 1b1b1b1b
    d001004: --------? .
    e 0b001000
    b001000: xxxxxxxx? .

    e 0b001000
    b001000: --------? 0055aaff
    b001004: --------? .
    e 0e001000
    e001000: xxxxxxxx? 1b1b1b1b
    e001004: --------? .
    e 0b001000
    b001000: xxxxxxxx? .

    e 0b001000
    b001000: --------? 0055aaff
    b001004: --------? .
    e 0f001000
    f001000: xxxxxxxx? 1b1b1b1b
    f001004: --------? .
    e 0b001000
    b001000: xxxxxxxx? .


    Update: I updated the instruction to also note the read values. Just to be sure it does nothing unexpected.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 09, 2014, 10:10:54 pm
    Hi andreas. I was running r324 at first. I've now updated to r326 and am still getting the crashes with 1.0.

    When I updated the svn again I got r327 down and saw that memory.c has been updated. Unfortunately r327 won't compile here. It fails on rtcnvram.c:

    /previous-code/src/rtcnvram.c:351:6: error: conflicting
         types for 'set_rtc_time'
    void set_rtc_time(int which,int val) {
        ^

    I was able to get NS4.0 (http://i.imgur.com/wi4inZP.png) installed (as an upgrade over 3.3). When I tried to change the system to a NeXTstation Color I got a kernel panic (http://i.imgur.com/bTdgHR9.png) when it tried to load the Workspace.

    I tried to do a clean install of 3.3 on a 040 NeXTstation Color config but first got stuck on the Ctrl+C to skip network config and then after a reboot on the "root on" hang. I'll just stay away from 040 for now. I just tried it in the hope of getting some colour for NS4.0.

    And lastly (another whole day spent messing with Previous. oh dear...) I tried restoring my 0.9 dump in the same manner as I used for 1.0 and 2.0. But I see that 0.9 used an older disk label format so it won't boot from the disk. Is there any way to write a compatible disk label?
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 10, 2014, 03:49:06 am
    Set_rtc_time seems to be also an internal func on some platform, just add a prefix like 'my_set_rtc_time' both in function and where it is called, i'll fix svn
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on March 10, 2014, 08:35:08 am
    did it on a 030 cube:


    e 04001000
    4001000: --------? 0055aaff
    4001004: --------? .
    e 10001000
    10001000: ffffffff? 1b1b1b1b
    10001004: --------? .
    e 04001000
    4001000: 0005161b? .

    e 04001000
    4001000: --------? 0055aaff
    4001004: --------? .
    e 14001000
    14001000: 00000000? 1b1b1b1b
    14001004: --------? .
    e 04001000
    4001000: 1b6fbfff? .

    e 04001000
    4001000: --------? 0055aaff
    4001004: --------? .
    e 18001000
    18001000: 00000000? 1b1b1b1b
    18001004: --------? .
    e 04001000
    4001000: 005094e4? .

    e 04001000
    4001000: --------? 0055aaff
    4001004: --------? .
    e 1c001000
    1c001000: 00000000? 1b1b1b1b
    1c001004: --------? .
    e 04001000
    4001000: 1b6bafff? .

    e 0b001000
    b001000: --------? 0055aaff
    b001004: --------? .
    e 0c001000
    c001000: ffffffff? 1b1b1b1b
    c001004: --------? .
    e 0b001000
    b001000: 0005161b? .

    e 0b001000
    b001000: --------? 0055aaff
    b001004: --------? .
    e 0d001000
    d001000: 00000000? 1b1b1b1b
    d001004: --------? .
    e 0b001000
    b001000: 1b6fbfff? .

    e 0b001000
    b001000: --------? 0055aaff
    b001004: --------? .
    e 0e001000
    e001000: 00000000? 1b1b1b1b
    e001004: --------? .
    e 0b001000
    b001000: 005094e4? .

    e 0b001000
    b001000: --------? 0055aaff
    b001004: --------? .
    e 0f001000
    f001000: 00000000? 1b1b1b1b
    f001004: --------? .
    e 0b001000
    b001000: 1b6bafff? .
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 10, 2014, 09:40:37 am
    Thank you! The output contains something unexpected. The order of the functions is reversed compared to my current implementation. I already tried that earlier with no success. But the read values are interesting! They obviously should be all 0 or all 1 and not a mirror of the actual value in memory. I'll try this in a few hours and report back.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on March 10, 2014, 10:12:18 am
    I ran the test again on a mono 68040 (non-turbo) cube and it gave the exact same results. just so you know...
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 10, 2014, 12:40:55 pm
    Thanks andreas and gilles for the latest fixes! I was able to compile r328 just now and booted 1.0 (http://i.imgur.com/zt5QKGs.png) successfully :)

    Still stuck on 0.9. I tried to initialise a disk using the copy of "disk" from 0.9 but it was still unable to read the disk label (http://i.imgur.com/zTFUDE2.png) and ended up in a panic as you can see. Trying to set the rootdev didn't work as it isn't a recognised flag in the 0.9 kernel.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 10, 2014, 07:01:02 pm
    I was able to fix the memory write functions with the above informations. Obviously reading from these addresses returns all 1 or all 0 and not the actual value in memory. The drawing glitches in 0.x and 1.x are gone. Thanks go to mikeboss for obtaining the values from a real machine!  :)

    protocol7:
    The disk label of the image can be changed manually with a hex editor. But it is a quite complex and time consuming procedure. If you are interested anyway, please PM me your e-mail address.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 13, 2014, 08:10:42 pm
    Good news:
    Toni Wilen has worked on the FPU and finally the bad font drawing is gone! Also i am no longer able to reproduce the panic on 68040 and NeXTstep > 3.

    As it happened randomly, i'm not sure if it is really gone. It would be great if those of you that had problems with the crash could test if it is still there.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 13, 2014, 11:30:00 pm
    With the latest commit I was able to install NS 3.3 and then upgrade it to NS 4.0 with a 040 NeXTstation Color config.

    The last time I tried this I got the "root on sd0" hang and a kernel panic. This time it was smooth sailing on both counts.

    It's also nice to see text rendering properly. I checked some app info panels that had some missing text and they're all displaying correctly.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 14, 2014, 02:43:37 am
    I've been having trouble building Previous on Mavericks.  I have SDL2.framework installed in /Library/Frameworks/SDL2.framework, and SDL is detected during configure:
    -- Found SDL: /usr/local/lib/libSDL.dylib;-framework Cocoa (found version "2.0.2")

    Unfortunately, Previous doesn't build, complaining about SDL:
    [ 10%] Building C object src/gui-sdl/CMakeFiles/GuiSdl.dir/dlgFileSelect.c.o
    /Users/eagle/Source/previous-code/src/gui-sdl/dlgFileSelect.c:322:32: error: use of undeclared identifier 'SDL_BUTTON_WHEELUP'
                   if (pEvent->button.button == SDL_BUTTON_WHEELUP)
                                                ^
    /Users/eagle/Source/previous-code/src/gui-sdl/dlgFileSelect.c:324:37: error: use of undeclared identifier 'SDL_BUTTON_WHEELDOWN'
                   else if (pEvent->button.button == SDL_BUTTON_WHEELDOWN)
                                                     ^
    2 errors generated.
    make[2]: *** [src/gui-sdl/CMakeFiles/GuiSdl.dir/dlgFileSelect.c.o] Error 1
    make[1]: *** [src/gui-sdl/CMakeFiles/GuiSdl.dir/all] Error 2
    make: *** [all] Error 2p


    Anybody have any ideas about this one?

    I would really like to build this and play with NS3.3.  Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: jroark on March 14, 2014, 03:15:59 am
    It requires SDL 1 and is incompatible with 2.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 14, 2014, 12:16:31 pm
    Aha, that was it.  Now to find my NS3.3 and OS4.2 CDs!  They're probably packed up in the garage somewhere. Playtime tonight!  Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 14, 2014, 06:01:14 pm
    Arths, you had troubles with pressing control-C. I posted a patch, but don't know if it works. Please update your sources with the latest branch_mmu and try if it works now.

    eagle, it is maybe easier to use an existing image of the CD. Else you have to clone it with dd to have a 1:1 copy.

    Everyone else:
    Please keep testing for the boot hang (root on ...) and the kernel panic bug. If you still see it or can no longer reproduce it, please report.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 14, 2014, 06:14:41 pm
    Andreas, I'll need to make images of the install CDs, because I don't have any.  I'm pretty sure I know exactly where they are, and I'm guessing that I should use a block size of 512 (maybe 1024) when creating the images.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jroark on March 14, 2014, 06:25:20 pm
    I've noticed that on OSX if you have a case sensitive filesystem the previous.app is not created correctly.

    Here is a patch (http://johnroark.com/case.patch)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 14, 2014, 07:35:01 pm
    Thanks for the patch! It is generally working, but i'd prefer to have Previous.app with upper case P. I've been wondering for some time, why it is created with lower case. Do you have an idea what might be the cause? Fixing it would make the patch obsolete.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jroark on March 14, 2014, 10:11:44 pm
    I seem to be stuck in the unable to hit ctrl-c camp.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 14, 2014, 10:59:24 pm
    Same thing for me  :P
    Title: What Needs to be done for a NeXT Emulator
    Post by: jroark on March 15, 2014, 12:36:24 am
    Quote from: "andreas_g"Thanks for the patch! It is generally working, but i'd prefer to have Previous.app with upper case P. I've been wondering for some time, why it is created with lower case. Do you have an idea what might be the cause? Fixing it would make the patch obsolete.


    Here is a patch (http://johnroark.com/case.patch) for uppercase Previous.app

    add_executable(Previous MACOSX_BUNDLE ${GUIOSX_RSRCS} ${SOURCES} ${GUIOSX_SOURCES})
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 15, 2014, 03:41:28 am
    I'm getting a crash when I press the "OK" button to launch the emulator.  I don't even have to change any of the settings, just press OK and it crashes.  It also crashes when I actually load my settings or change the settings and press OK.  Any ideas what might be wrong?

    The crash report is pretty long, so I have put it here:

    https://dl.dropboxusercontent.com/u/13208710/Previous.crash
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 15, 2014, 04:09:39 am
    I've taken a few shots of Previous in action here, but it struck me that it'd be kinda cool to show the full desktop, with OS X running the OS where it began.

    So here's one. Something you could really only do with emulation :)

    (https://secure.flickr.com/photos/96579068@N05/13158757515/sizes/o/)
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 15, 2014, 04:54:55 am
    Well, I'm stuck at the "root on" hang.  I put my hard disk at SCSI ID 0, floppy at SCSI ID 1, and CD at SCSI ID 6.

    CD image was made by running this:
    sudo dd if=/dev/disk1s0 of=Desktop/NS33.iso bs=512
    Blank hard disk image was made by running this command:
    dd if=/dev/null of=../Desktop/NS33-previous.diskimage count=200000 bs=1024
    I have  tried NeXT Computer, NeXTstation, and NeXTstation Color, and all 3 hang at "root on."  Any ideas what I could try?

    Also, it crashes every time on my MacBook Pro, but runs fine on my iMac.

    PS - protocol7, that's a nice screenshot!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 15, 2014, 07:54:01 am
    That's bad news. So the "root" hang is still there. I got a hint that maybe not moving the mouse during boot process helps. You could try that as a workaround.
    At the moment i am not able to reproduce the hang. So i can't fix it for now.

    The crash (really it is abort) is strange. Are there any messages in the console?

    I hoped that control-C is fixed ... is NeXTstep really expecting the "control" key, or maybe the "command" key? Which key do you press on real hardware?
    (Don't try command-C in Previous, it is mapped for cold reset at the moment. But if we need that combination in emulation, i'll change it).

    btw.: jroak, thanks for the patch! I guess this now also works on case sensitive file systems?
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 15, 2014, 09:47:12 am
    for the NS3.3 boot hang, try not to move the mouse at this stage of booting
    (ie try not to move the mouse after typing bsd if booting in interactive mode).

    I'm unsure if it's a real emulation bug or something that might happen in real life...
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 15, 2014, 12:28:53 pm
    Andreas: I think it's expecting Control+C alright. Here the Control key on my keyboard gets mapped to command, and as you say, command key+c resets the emulator.

    Maybe you could remap the keys so that Control and Command use the proper keys? And map the reset shortcuts to another combo (or just disable them, as it can also be called from the menu)?

    I wasn't sure why I didn't get it last time. Thought it might be because I used a different ROM, but maybe I didn't move the mouse. Will have to pay attention to that.

    Thanks eagle. Sorry to hear you're still having troubles. At least Previous is running OK on your iMac.
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on March 15, 2014, 12:41:44 pm
    On real hardware the Control-C to continue prompt during boot requires the actual "Control" key and not the "Command" key.  It sends a SIGINT to the process.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 15, 2014, 01:15:40 pm
    Quote from: "andreas_g"That's bad news. So the "root" hang is still there. I got a hint that maybe not moving the mouse during boot process helps. You could try that as a workaround.
    At the moment i am not able to reproduce the hang. So i can't fix it for now.

    I think the "don't move the mouse" workaround is it: I am now installing NeXTSTEP 3.3!

    QuoteThe crash (really it is abort) is strange. Are there any messages in the console?

    I don't remember seeing anything else in the other logs in Console.app, but I'll try again and look for some, and post them if I see any.

    QuoteI hoped that control-C is fixed ... is NeXTstep really expecting the "control" key, or maybe the "command" key? Which key do you press on real hardware?
    (Don't try command-C in Previous, it is mapped for cold reset at the moment. But if we need that combination in emulation, i'll change it).

    To skip the network config, you press Control-C on real hardware.  I have had to do that many times.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 15, 2014, 03:38:11 pm
    WOW WOW WOW

    I actually have NeXTSTEP 3.3 for NeXT computers installing in Previous!

    I was able to get past the Control-C problem by booting into single user mode and editing the network config file in /etc (what was it, /etc/hostconfig?), setting appropriate values.  Then, it waited while searching for a NetInfo server, but that is simply a "press C to continue without NetInfo," so it was easy to get past that.  And now it is installing!!

    I am so impressed and excited.  THANK YOU SO MUCH, Andreas and everyone else who was involved!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 15, 2014, 05:12:47 pm
    Should have looked at a real keyboard   :oops:

    The command and control keys where reversed. It is now fixed. Control-C bug should be gone. Please test!

    Also i have remapped the shortcuts to be all command+alt+key.
    It should be now quite unlikely to accidentally press a shortcut.

    For the "root" hang:
    Mouse is a good idea ... it seems there is indeed a bug with the mouse. There must to be a way to disable it that is used by the operating system. Unfortunately i don't know how it is done and can't find anything in the traces. But the diagnostics also expect this. Moving the mouse in diagnostics utility for now produces random letters and symbols.
    At least now we have a workaround till it is fixed. Just don't touch the mouse during boot.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 15, 2014, 06:10:02 pm
    Andreas, I finally got NS3.3 installed, and as it was launching the GUI, it panicked when it was starting the Workspace Manager and Preferences app.  It immediately rebooted.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 15, 2014, 06:41:40 pm
    The remapped keys are working great. I no longer live in fear of seeing that Control-C prompt :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 15, 2014, 06:43:12 pm
    Hey guys,
    I can't successfully build branch_mmu  :?
    I get an error on UAEcpu apparently and it hangs there. Any idea?

    Cheers
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 15, 2014, 07:33:32 pm
    I know that this is asking for the moon, especially at this stage, but does ethernet work for anyone?  I can configure it, and ifconfig shows the interface to be up, but it doesn't seem to work.  Thanks.

    Also, I figured out that my GUI crash was also related to moving the mouse on bootup.  If I don't move the mouse until the GUI is completely loaded, it loads fine.
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 15, 2014, 07:45:12 pm
    maybe it's in CMakeLists.txt (at top level)

    change:
    # Warning flags:
    if(CMAKE_COMPILER_IS_GNUCC)
    set(CMAKE_C_FLAGS "-Wcast-qual -g -O0 -Wbad-function-cast -Wpointer-arith ${CMAKE_C_FLAGS}")
    set(CMAKE_C_FLAGS "-Wmissing-prototypes -Wstrict-prototypes ${CMAKE_C_FLAGS}")
    set(CMAKE_C_FLAGS "-Wall -Wwrite-strings -Wsign-compare ${CMAKE_C_FLAGS}")
    #set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wextra -Wno-unused-parameter -Wno-empty-body")
    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wformat-security")
    #set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wshadow -D_FORTIFY_SOURCE=2 -Werror")
    endif(CMAKE_COMPILER_IS_GNUCC)


    with
    # Warning flags:
    if(CMAKE_COMPILER_IS_GNUCC)
    set(CMAKE_C_FLAGS "-Wcast-qual -g -O0 -Wbad-function-cast -Wpointer-arith ${CMAKE_C_FLAGS}")
    set(CMAKE_C_FLAGS "-Wmissing-prototypes -Wstrict-prototypes ${CMAKE_C_FLAGS}")
    set(CMAKE_C_FLAGS "-Wall -Wwrite-strings -Wsign-compare ${CMAKE_C_FLAGS}")
    #set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wextra -Wno-unused-parameter -Wno-empty-body")
    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wformat-security -std=gnu99")
    #set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wshadow -D_FORTIFY_SOURCE=2 -Werror")
    endif(CMAKE_COMPILER_IS_GNUCC)


    and rebuild configure

    I made this change in trunk because it frequently appears while merging from winUAE
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 15, 2014, 07:50:41 pm
    Thanks Gilles, that is working perfectly  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 15, 2014, 10:35:04 pm
    How would you like to receive bug reports?  I am seeing that somehow my caps lock key got enabled, and I can't get out of it: the Mac's caps lock was not enabled, and flipping it does not change the caps lock in Previous.  Also, trying the other key combinations (alt/option, command, control, shift) does not flip it either.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 15, 2014, 10:47:45 pm
    I think it will be easiest for now to just send me an e-mail. That should be possible via the forum's e-mail button. I need with every bug report a description of reproducibility and error logs from the console (if there is something).
    Every key press gets logged, so in this case there should be something useful in the logs.

    Ethernet controller is just implemented as a dummy. No networking possible yet.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 16, 2014, 09:22:34 am
    Finally  :D
    Mouse seems to be buggy though, it doesn't move properly or at all.
    Also, is there a possibility to change the resolution of Previous? Mine is 1366x768 therefore I can't see the status bar for exemple.  :wink:



    Thanks again for everything!
    Cheers
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 16, 2014, 09:38:37 am
    screen resolution in next black hardware is more or less fixed. It seems that turbo can have a lower resolution (at least the emulator/ROM auto detects a lower resolution) but something is now broken in turbo hardware (in scsi).
    anyway the window itself is still the big one...

    My main PC is also a small one... 1024x768

    I cannot help you for now... but you're not alone...

    For mouse you may try latest trunk version that auto grabs the mouse when you click in the window (and lower mouse sensitivity). On PC Alt-Gr M will give the mouse back to the desktop.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 16, 2014, 10:06:01 am
    Most Turbo hardware is not emulated. The Turbo machines have a different DMA controller and also many other differences. That would need quite a lot of work and is not a goal at the moment (for me at least).

    The problem with stuck modifier keys (e.g. caps lock) should now be fixed (branch_mmu). Also i think it makes sense to map the shortcuts like in branch_mmu to some unlikely combinations. I chose command+alt+key.

    I'm not sure if auto-grabbing the mouse is good. I often had problems with that kind of behavior in other programs when the shortcut for releasing it is unknown or doesn't work for some reason. Command+alt+m works for me. But that is maybe a matter of taste.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 16, 2014, 10:20:40 am
    Command+Alt doesn't work for me, or maybe I can't find the right key  :lol:
    On Linux I'm trying Control+Alt+M, Win ( or Super Key )+Alt+M it doesn't work.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 16, 2014, 10:28:41 am
    I think we need to find a key for shortcuts, that works on all systems.

    NeXT only has one control key on the right side. What about making the left control key the modifier for all shortcuts? Is it missing on any platform?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Arths on March 16, 2014, 10:53:06 am
    That would work  :wink:
    Anyway OPENSTEP 4.2 is up and running!  :D

    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 16, 2014, 11:31:54 am
    right control is missing on most of PC laptops, but there is a "WIN95" menu key that is mandatory here since years.
    porting keyboard for all platforms and layout and also for laptop will not be easy... but it's time to do that now.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 16, 2014, 12:13:47 pm
    I'm now installing NS3.3 in Previous on my MacBook Pro.  I note that it runs much faster on an SSD -- but, then, everything does. :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 16, 2014, 12:19:42 pm
    @arths: on trunk it is still AltGr-m  for a linux/Fr layout keyboard.
    Changes in branch_mmu are good for macosX but not necesseraly for linux/win32. As I said, it's time to do the job correctly for all platforms :)
    and SDL does not help us in the task because it tries to be generic (and fails as all generic libraries fails for the obscure task of keyboard mapping).
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on March 16, 2014, 05:50:07 pm
    Am I seeing dream or in dream! :D
    At last I were able to compile Previous (A great help of Gilles, Thank you!)
    I have Installed NeXTStep 3.3 on Previous! -

    (http://postimage.org/)
    screen shots (http://postimage.org/app.php)

    (http://postimage.org/)
    image upload no compression (http://postimage.org/)
    Thank you All!

    For Ethernet and others we can see the Basilisk II code-
    and we should add the things like external filesystem from basilisk code(for file exchange)
    I have get the mouse buggy -(brunch-mmu)
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 16, 2014, 06:22:30 pm
    Most of mac emulators patch the rom. It's easier for them to code cool features... but we cannot have the same approach since we need to emulate at a lower level (there is a benefit, we are not limited to nextstep, netBSD should also run). Also next hardware do not rely on its rom after initial stage of boot process.

    Some code might be reused anyway, the part that brings a virtual device to the guest OS. Network is enough for everything, then you will create a NFS share on the guest OS, Nextstep can use nfs. But it will take some time to code.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on March 16, 2014, 07:41:59 pm
    I've compiled Previous 0.4 off the mmu trunk in ubuntu 13.10 x64 and it all works! Or at least I get to the rom screen. But I don't seem able to boot the NS33 cdrom image in NextStation Color at all using b sd(1,0,0) or b sd(1,0,1). And I don't understand how you tell the emulator about floppy? I tried linking a floppy image to a scsi device but that won't boot either. So how do you get all this going ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 16, 2014, 09:13:13 pm
    There is no floppy drive emulation. But if you attach the floppy image as an SCSI disk, it will work. For example attach the floppy image as disk 1, CD-ROM image as disk 2 (don't forget the check the CD checkbox) and an empty image as disk 0.
    Then you should be able to boot using
    bsd(1,0,0)
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 16, 2014, 10:11:01 pm
    The mouse capturing is a big help. The mouse is still a bit floaty but I can handle that. The constant losing of sync was more frustrating.

    I tried both the branch and trunk versions. In the trunk the lower mouse sensitivity is a bit too low for me. Also when I used Alt Gr-m to uncapture it, it spammed the system with "m"s.

    With the branch I can toggle mouse capture fine with cmd+alt+m (although it says Alt Gr-m in the title bar).

    The shortcuts in Andreas's branch work great here but if it's a case that some systems and keyboards are missing certain keys, could you use the Keyboard setting in the emulator? It seems to allow you to load up keymap files. So maybe including a few pre-built keymaps for different keyboard layouts would work?

    P.S. Does anyone have the NS3.0 boot floppy?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on March 17, 2014, 03:25:14 am
    We should create a keymap file for previous. Basilisk ii has a keymap file.
    And can we use the basilisk Ethernet code, for previous?
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 17, 2014, 08:54:34 am
    @protocol7: we need to name shortcuts so that the tip in title bar is OK for every platform. (I added this in the title bar to help people find their mouse again but I know the key naming is valid only for some keyboards, it may be right alt on some, or option on macos).

    @mominul: we will provide a basic mapping for every major platform and a mapping file (the menu is already there from Hatari, we need to reintroduce that).
    Title: Speed of emulated machine
    Post by: cbrunschen on March 17, 2014, 11:28:40 am
    Hi all,

    Having a nicely emulated NeXT machine is awesome.

    I noticed that the emulated machine seems to be a lot slower on my brand-new MacBook Pro with a 2.6 GHz Intel Core i7 CPU running Mac OS X 10.9.2 and compiled with Apple's included clang, than on a 2-year-old desktop machine with a 2.67GHz Intel Xeon running Ubuntu Linux compiled with gcc 4.6.3; the Linux machine also has less memory (8GB instead of 16 etc). The difference in speed is quite noticable - even on such things as drawing to the screen from the boot ROM, and even on spinning the wait cursor: it is a lot slower on the newer computer, much more than than I would have expected even on a difference between a desktop/server (Xeon) and a mobile CPU. I would have expected much closer speed parity, and possibly even a small speed advantage for the newer machine (simply because it is newer, at the same-ish clock speed).

    Are there compiler- or OS-specific things that might affect this?

    Best wishes,

    // Christian
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 17, 2014, 12:22:56 pm
    I would expect the 2-year-old desktop system to be about the same speed or slighlty faster compared to the new higher end mobile system. If you notice considerable differences, i'd suspect some compiler specific differences. Maybe the optimization level is not the same?

    Another reason might be different speed of the SDL implementation, especially for screen drawing.

    At last, the not yet perfect timing system of Previous comes to my mind. But i don't know it good enough to tell, if it can theoretically cause general slow down.


    To something different:
    I have coded a little GUI for setting the mouse speed as a user preference. It improves things a little bit. But it is not yet satisfying.
    The main problem is, that all modern systems use a "mouse acceleration curve". If the mouse is moved fast, the operating system increases cursor motion speed further. If the mouse is moved slow, it keeps cursor motion slow to improve precision.

    The problem is, NeXTstep has such a feature too. So we have some kind of "double acceleration". If applying a linear speed adjustment, as we do with Previous at the moment, the problem is, that you get either bad results on slow or on fast motion.
    To get good results, the hosts acceleration needs to be first reversed before the motion data is passed to the emulated hardware. I'll try if i can get something useful here.

    Does anyone know how these acceleration curves are usually calculated? Are they simple exponential functions like: distance^factor ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 17, 2014, 12:26:03 pm
    Andreas, thinking specifically of the mouse, I was wondering if it would be possible to send absolute mouse coordinates to the OS.  If that is possible, that would be best I think.  Is something like that possible, or would that require a specific driver in the OS?
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 17, 2014, 12:54:46 pm
    something that may slow down on a specific platform is too frequent screen refresh.
    The actual system is far from perfection, it just nearly achieve 50-60Hz screen refresh and a 33MHz emulated machine.
    my 6years old laptop under linux is enough for full speed.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 17, 2014, 01:31:19 pm
    eagle, unfotunately that is not possible. We can't track the position of the mouse cursor "inside" the emulated machine. Even if we knew the exact algorithm of NeXTstep for cursor movement, it would depend on too many things to build a reliable absolute cursor positioning.

    About speed: If Gilles gets full speed (about 60 Hz) on his 6-year-old laptop running Linux that indicates Linux has a considerable speed advantage over Mac OS X. I am running Mac OS X on a 5-year-old desktop and only get an estimated 3 Hz emulated screen refresh.
    For example the wait cursor (spinning disk) needs a few seconds for a full rotation. (Note: compiler in no optimization mode for fast compile times).
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on March 17, 2014, 02:39:57 pm
    Quick bug report, using the NeXTstation colour with 3.3, the date & time frame in prefs crashes the entire app when selected. No idea why, never seen this behaviour before.

    Strangely once the m68k boot floppy was inserted the CDROM became bootable... Oh well, at least it works.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on March 17, 2014, 04:44:10 pm
    This may be for bug in rtc.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on March 17, 2014, 05:00:18 pm
    Quote from: "andreas_g"
    For example the wait cursor (spinning disk) needs a few seconds for a full rotation. (Note: compiler in no optimization mode for fast compile times).


    Curious....
    On my own MacBook (2012 AMcBookPro), with the latest build, my feeling is that the screen drawing and overall speed is a lot faster than real harware (boot screen show in a second).
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 17, 2014, 05:09:15 pm
    I'm starting to see "System test failed.  Error code 42." when I launch Previous.  Anybody have any idea what that means?

    ---

    Edit: the more I look into this, the more I think it's related to the hardware I chose to emulate: when I choose a 16MB 68030 Cube, I get error 42.  When I choose a station, I don't get an error.

    And, my guess is that error 42 has to do with networking.  The system boots fine even with that error.

    ---

    Also: I have now run Improv and Stealth in NS2.2.  Those are two of the things I have missed the most over the years.  Neat stuff!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 17, 2014, 06:47:43 pm
    That error is fixed in branch_mmu. It was an FPU incompleteness. I'm sure Gilles will merge on next occasion.

    jvernet, that's interesting. Do you have noticeable mouse cursor or keyboard input lagging? If you have, can you describe approximately how bad it is (e.g. how long does it take in average for a character to show when typing in ROM monitor)?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 17, 2014, 06:57:49 pm
    Has anyone tried Mathematica 1.0 in Previous?  It keeps crashing for me on NeXTSTEP 2.2... :(

    But, I have no idea if my binaries are still good, and I don't know how to use the app, so there's no telling what the problem is. :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on March 17, 2014, 10:33:48 pm
    Quote from: "andreas_g"I would expect the 2-year-old desktop system to be about the same speed or slighlty faster compared to the new higher end mobile system. If you notice considerable differences, i'd suspect some compiler specific differences. Maybe the optimization level is not the same?


    Possible; though all I'm doing is running 'configure' and 'make', with no particular options (beyond identifying the correct readline library to use on Mac OS X).

    Quote from: "andreas_g"Another reason might be different speed of the SDL implementation, especially for screen drawing.


    Also possible, and perhaps more likely. In fact, I ran a small experiment: I built Previous inside a VirtualBox VM running Debian Linux, on the same Macbook Pro. It ran noticably faster than the "native" Mac OS X build - both when displayed within the virtual machine's screen, and when displayed remotely over X to Xquartz on the Mac OS X side.

    Quote from: "andreas_g"At last, the not yet perfect timing system of Previous comes to my mind. But i don't know it good enough to tell, if it can theoretically cause general slow down.


    I noticed one strange thing by the way: When emulating a NeXTstation Color, the settings screen claims to run at 25 MHz; the status bar below the screen says 16 MHz; and the boot monitor says 20 MHz. Something, somewhere, is ... confused :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on March 18, 2014, 09:04:48 am
    Quote from: "andreas_g"That error is fixed in branch_mmu. It was an FPU incompleteness. I'm sure Gilles will merge on next occasion.

    jvernet, that's interesting. Do you have noticeable mouse cursor or keyboard input lagging? If you have, can you describe approximately how bad it is (e.g. how long does it take in average for a character to show when typing in ROM monitor)?


    Well, I managed to get a working NS33 disk image yesterday, and, no, it's not so fast....
    Mouse lag, but typing in the monitor is not so bad.
    I used the branch mmu previously and found it faster than trunk used yesterday. Gilles made some tweak to have better graphical performances, are they in the common trunk ?

    More over, as I only have a Macbook with a 13" screen, i do not see the bootom of the screen.
    Title: What Needs to be done for a NeXT Emulator
    Post by: wizard on March 18, 2014, 07:13:45 pm
    I am on a mac, how do you guys press CTRL-C in Previous 0.4? When the prompt asks to skip networking , CTRL-C is not working on my end (just shows the c character).
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 18, 2014, 07:15:33 pm
    Quote from: "wizard"I am on a mac, how do you guys press CTRL-C in Previous 0.4? When the prompt asks to skip networking , CTRL-C is not working on my end (just shows the c character).

    You need to boot into single user mode ("bsd -s") and edit /etc/hostconfig to configure networking with static address and configuration.  Once you do that and reboot, it will get past that part, then hang at NetInfo, but to bypass NetInfo you just have to press the C key to continue.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 18, 2014, 07:47:10 pm
    The key mapping might not be fixed in the trunk (control and command were swapped and command-c reset the emulator).

    The branch_mmu build that Andreas works on fixed it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on March 18, 2014, 08:53:19 pm
    Quote from: "eagle"
    Quote from: "wizard"I am on a mac, how do you guys press CTRL-C in Previous 0.4? When the prompt asks to skip networking , CTRL-C is not working on my end (just shows the c character).

    You need to boot into single user mode ("bsd -s") and edit /etc/hostconfig to configure networking with static address and configuration.  Once you do that and reboot, it will get past that part, then hang at NetInfo, but to bypass NetInfo you just have to press the C key to continue.


    If you edit the hostconfig file to just add a hostname and change everything else from AUTOMATIC to NO it doesn't hang on NetInfo after that.

    I can't seem to get the install media to boot any further than it detecting that the root device is sd1a when trying to install as an 030 or 040 Cube (not trying turbo at all). I suppose this is normal for the time being.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 18, 2014, 09:32:36 pm
    Quote from: "Noth"
    Quote from: "eagle"
    Quote from: "wizard"I am on a mac, how do you guys press CTRL-C in Previous 0.4? When the prompt asks to skip networking , CTRL-C is not working on my end (just shows the c character).

    You need to boot into single user mode ("bsd -s") and edit /etc/hostconfig to configure networking with static address and configuration.  Once you do that and reboot, it will get past that part, then hang at NetInfo, but to bypass NetInfo you just have to press the C key to continue.


    If you edit the hostconfig file to just add a hostname and change everything else from AUTOMATIC to NO it doesn't hang on NetInfo after that.

    Thanks for the tip.  I'll update my configs with NO instead.

    QuoteI can't seem to get the install media to boot any further than it detecting that the root device is sd1a when trying to install as an 030 or 040 Cube (not trying turbo at all). I suppose this is normal for the time being.

    I have been installing with the hard disk as sd0, the boot floppy at sd1, and the CD at sd6, and have been using an 030 Cube or a color station for most of my installs.  Depending on the build you are using, you will want to make sure you don't move your mouse after you run "bsd" to boot.

    And, Andreas/gilles/whoever: it's very cool that you can turn off verbose diagnostics to watch the old-school graphic boot sequence!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on March 18, 2014, 09:36:55 pm
    eagle: thanks for that.

    I've compiled Previous on the Raspberry Pi under the Raspbian distro, it works!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 18, 2014, 11:50:30 pm
    Raspberry pi? Wow. Very neat!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: jroark on March 19, 2014, 12:58:22 am
    Quote from: "Noth"eagle: thanks for that.

    I've compiled Previous on the Raspberry Pi under the Raspbian distro, it works!


    Is it usable?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on March 19, 2014, 02:08:59 pm
    Quote from: "jroark"
    Quote from: "Noth"eagle: thanks for that.

    I've compiled Previous on the Raspberry Pi under the Raspbian distro, it works!


    Is it usable?


    Well I ran it remotely using ssh -X ... so it was extremely slow. Not really usuable because the CPU was devoting 80% of it's power to the ssh session! Maybe I'll try a VNC session to see if it works any better.
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 19, 2014, 08:00:11 pm
    most of nowadays xwindows applications cannot run very fast remotely.
    An SDL application that sends Xwindows messages is not something very optimal :)
    I do not expect a raspi to emulate full speed of a 68040@25 but it could be close.
    I have a model B raspi, I may try this later but my TV resolution will be too small (using PAL composite output, I do not have any hdmi screen/TV).
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on March 20, 2014, 03:20:39 pm
    Quote from: "gilles"most of nowadays xwindows applications cannot run very fast remotely.
    An SDL application that sends Xwindows messages is not something very optimal :)
    I do not expect a raspi to emulate full speed of a 68040@25 but it could be close.
    I have a model B raspi, I may try this later but my TV resolution will be too small (using PAL composite output, I do not have any hdmi screen/TV).


    I setup Xvnc and connected with that.. now previous uses 80% of proc and is pretty sluggish. My i7 laptop runs previous at full if not slightly faster speed.

    Btw, the native resolution for NeXT hardware was 1152x852 or something similar, I don't suppose we could have a toggle to switch between 1024x768 and 1152x852 in the GUI?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 20, 2014, 03:31:06 pm
    To be exact, it was 1120x832.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on March 20, 2014, 05:12:01 pm
    I'm running Hatari on my Raspbery (overclocked to 950 Mhz). It cannot run at full speed a Falcon at 16Mhz, so a NeXt.... Too much FrameSkip.

    It's OK for a 68000@8Mhz ST.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 22, 2014, 09:08:52 am
    I did a few changes to keyboard and mouse events (thanks to mikeboss for finding the correct values). The changes are in branch_mmu.

    Everyone affected by the "root on" hang: Please check, if you can still reproduce it with the latest code.
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 22, 2014, 11:33:21 am
    just tested on a "fresh" linux box.

    Hang is still present.

    As I supposed the new shortcut is non existent on linux so we will have to use a specific key for each platform.
    Default mouse acceleration is much too fast (here on a regular usb mouse)
    again default values will have to be platform specific.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 22, 2014, 02:22:01 pm
    Andreas, booting NS3.1, I have the "root on" hang, with the latest build in branch_mmu.  I haven't seen the "root on" hang for several builds, but this is also my first time ever booting 3.1.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on March 22, 2014, 04:45:30 pm
    I haven't gotten the root hang with the current branch (or any since you made those fixes to the 040 emulation a little while back). Even tried moving and clicking the mouse during boot.

    I see moving the mouse no longer sends random letters when booted into the diagnostics tool.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 22, 2014, 05:02:47 pm
    The hang seems to be still here. Its accidental nature makes it very hard to debug. But i'm sure sooner or later we'll find it.

    The random characters on 68030 diagnostics are fixed. The mouse can be disabled. Real hardware has a feature to disable devices. I added it to Previous.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 23, 2014, 11:59:29 am
    I know I keep asking for the world, but would it be possible to have Previous run a VNC server or RDC server to which we could connect remotely? :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on March 26, 2014, 10:50:26 pm
    I'm trying to run NeXTSTEP 3.1 on previous 0.4 and I'm also getting the "Workspace Manager Error" like eagle does.

    the "root on" hang seems to be anything but random: it only happens while trying to emulate a cube. as soon as I'm trying to boot NS 3.1 while emulating a NeXTstation I'm not getting the hang anymore.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 28, 2014, 07:17:16 pm
    At this point, I have created a bunch of config files, one per OS, and I have created a script I can run to copy the correct config file into place, then launch Previous.  Due to a bug in Previous, I cannot set it to skip the configuration screen, but I can set it to boot the SCSI disk so all I need to do is hit OK in the config screen.

    I also created 2 small disks: one is called LocalApps, and the other is called LocalLibrary, and they mount exactly where they should.  These disks are now attached to all of emulated systems, so all of my apps are available to all of the emulated systems.

    I also created another disk called "Exchange," which is also mounted in all of the emulated systems, for the purposes of exchanging data between the emulated systems.

    Very, very fun stuff.  Thank you gilles, andreas, and others for all of your hard work.

    And, for those who are interested, Stealth.app does not run in 3.x. :)  But, it does run in color, and 2.1 can be run in color, so that's neat.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 01, 2014, 09:58:12 am
    Hi, My first try with NextStep :)
    I'm trying to boot Nextstep with Previous in OSX 10.8.5 without success.
    I have : 3.2 and 3.3 boot floppyimages, NextStep 2.2 and 3.3 iso.
    Setting the machine to be a MonoStation, 68040, 33mhz.
    I try by setting SCSI disk 0 to an empty image (btw what format should that be ?)
    disk 1 to the floppyimage,
    disk 2 to the NS 2.2 or 3.3 iso or burned disk...
    then i try b sd command but i get :
    sc: SCSI bad i/o direction
    or crash...
    Could someone tell me what i'm doing wrong, or do i need something else ?
    Thanks.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 01, 2014, 12:10:49 pm
    Quote from: "galgot"Hi, My first try with NextStep :)
    I'm trying to boot Nextstep with Previous in OSX 10.8.5 without success.
    I have : 3.2 and 3.3 boot floppyimages, NextStep 2.2 and 3.3 iso.
    Setting the machine to be a MonoStation, 68040, 33mhz.
    I try by setting SCSI disk 0 to an empty image (btw what format should that be ?)
    disk 1 to the floppyimage,
    disk 2 to the NS 2.2 or 3.3 iso or burned disk...
    then i try b sd command but i get :
    sc: SCSI bad i/o direction
    or crash...
    Could someone tell me what i'm doing wrong, or do i need something else ?
    Thanks.

    galgot, create a disk image by executing a command in Terminal.  The following will create a 1GB disk image:
    dd if=/dev/null of=NEXTSTEP_3.3_hard_drive.hd bs=1024 count=0 seek=1024000
    Feel free to put that wherever you want, just change the of= parameter.  Then, attach that hard drive in Previous.

    To boot from the floppy, enter the following command in the ROM Monitor:
    bsd(1,0,0)
    That should do it, at least for the 3.3 one.  And, 2.2 should work exactly the same way.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 01, 2014, 02:08:16 pm
    Hello galgot,
    You should make a blank image and mount the image to scsi disk0. as  eagle said(because I am a Windows user)
    floppy image to scsi disk1.
    iso file to scsi disk2 and check it as a cd-rom.

    on rom-monitor type-
    bsd(1,0,0)

    Sorry if I make any mistakes! :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 01, 2014, 05:49:03 pm
    Thanks both for your patience eagle and Mominul.
    I've done as you said:
    create a disk image with dd.
    Attach to disk0
    floppy to disk1
    CD image to disk 2 (cd checked).
    Still no joy, this is how far i can get :



    :/
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 01, 2014, 05:52:34 pm
    If you're working on the latest version of branch_mmu code, you will want to make sure that you do not disable the configuration screen: make sure this is set to TRUE in your config file:
    [ConfigDialog]
    bShowConfigDialogAtStartup = TRUE


    I'm getting a panic right now in 3.3, but not when I show the config dialog.

    Also, for 3.x and 4.x I am using a NeXTstation Color; for 2.x I am using a NeXT Computer.  Turbo emulation does not work currently.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 01, 2014, 07:34:23 pm
    This looks like a configuration issue. If eagle's suggestion doesn't help, please send me your configuration file (if you saved one) and describe step by step how you start and configure Previous.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 01, 2014, 09:04:14 pm
    Ok so i've edited my config file, there was no line like [ConfigDialog]...
    so i added that :
    [ConfigDialog]
    bShowConfigDialogAtStartup = TRUE

    But still panic.

    Here is how i start previous :
    -open the app
    -load my config
    SCSI Disk looks like this :

    and System looks like this :

    then i click OK
    i then get the dialog box saying:
    "the emulated system must be reset to apply these changes.
    Apply changes now and reset the emulator ?"
    i click OK
    then when i get:
    System test failed.  Error code 41.

    Boot command:
    Default boot device not found.
    Next>

    I do bsd(1,0,0)

    Note if i set the CPU clock in the system options to 33Mhz, if i go back to the System options window, it shows 8Mhz ..!
    And sometime it shows both ! :


    Here is the config file:
    http://galgot.free.fr/transit/pr.cfg.zip

    Thanks again for the help.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 02, 2014, 12:19:22 am
    galgot, try checking out the branch with this, then compiling this:
    svn checkout svn://svn.code.sf.net/p/previous/code/branches/branch_mmu previous-branch
    I don't know what version you have, but that version's config screen doesn't look like the one I have.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 02, 2014, 12:34:23 am
    And I thought it was just me. I haven't seen a config screen like that at all.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 02, 2014, 02:36:10 am
    Hello galgot,
    I think you have downloaded Previous binary from Previous website and Previous version is 0.3.
    Download the source just like eagle said and compile.
    The problems should be gone now.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 02, 2014, 09:04:45 am
    :oops: OK was indeed doing something wrong :lol:
    I'm hiding under my desk in shame...
    Mmu_previous-branch downloaded and compiled now.
    Starts ok... But i can't  type brackets for the bsd(1,0,0) command.
    the upper keyboard numbers keys are not recognized.
    should i get a map file for the keyboard setup , for a MacBook-pro, French keyboard ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 02, 2014, 09:28:18 am
    Key re-mapping is not yet implemented. It could be taken from Hatari. I think the task would not be very difficult with some C programming skills, but i am busy with other things at the moment.
    eagle once had a short look at it, but i don't know if he started working on it.

    I'm in contact with Toni Wilen to fix a remaining FPU problem. Obviously most or all non-Turbo NeXT machines used early version 68040 CPUs. They have a slightly different FPU (FPU version: 0x40, compated to 0x41 on later revisions).
    NeXTstep 2.0 seems to only work with these and not with the later ones.

    Maybe some users of Turbo and non-Turbo hardware could read the chip ID (the code with 68040 in it, something like XC68040RC25E)? That might be useful to identify what machines used what revision of the processor.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 02, 2014, 10:28:19 am
    I didn't get too far with it yet, but it doesn't look too bad.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 02, 2014, 02:06:35 pm
    Can any give me the keymap from Hatari? I will see can I do some thing! :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 02, 2014, 07:14:35 pm
    The funny thing is keyboard was working perfectly with old 0.3 binary...
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on April 03, 2014, 02:39:46 pm
    You could try configuring what keyboard layout your OS uses. I switch between standard US and Swiss French on a regular basis, especially when using emulators. That way I never get characters I can't enter on the keyboard through lack of available symbols. The US keyboard is the default for all lowlevel stuff on any OS / platform, it's not that hard to learn!
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 03, 2014, 03:45:25 pm
    Quote from: "Noth"You could try configuring what keyboard layout your OS uses. I switch between standard US and Swiss French on a regular basis, especially when using emulators. That way I never get characters I can't enter on the keyboard through lack of available symbols. The US keyboard is the default for all lowlevel stuff on any OS / platform, it's not that hard to learn!


    Many Thanks Noth .That worked :p
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 06, 2014, 03:54:14 pm
    is there new binaries for win32 or os x anywhere?  I'm compilerless @ the moment  :?
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 06, 2014, 04:58:43 pm
    Quote from: "neozeed"is there new binaries for win32 or os x anywhere?  I'm compilerless @ the moment  :?

    I think there's a few bugs in the 040 code that's holding up an official 0.4 release. Here's the latest branch_mmu commit (http://ge.tt/api/1/files/5orD7vW1/0/blob?download) for OS X, compiled on 10.6.8. It might complain about missing dylibs like sdl if you don't have them installed. If so you'll have to install those and then it should run. I don't know how to build it any other way.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 12, 2014, 08:32:14 am
    it looks as if some bugs have been squashed  8) having a NeXT emulator is a dream come true. muchas gracias to everybody who made this possible

    NeXTSTEP Release 2.0 now boots just fine:




    here's NeXTSTEP Release 1.0a running Mathematica 1.0

    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 12, 2014, 08:16:00 pm
    Ok working now for me too :) happy.
    Here a shot along side MacMini screen running WM 0.92, just for fun.

    Only the mouse is very draggy and unprecise, other than that works very well.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 12, 2014, 09:18:38 pm
    galgot, on what OS are you running WM 0.92?  FreeBSD?
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 12, 2014, 10:42:47 pm
    Quote from: "eagle"galgot, on what OS are you running WM 0.92?  FreeBSD?


    On Mac OSX 10.5.8 Running XQuartz. Installed via Fink. WM 0.95 is avaihable with macport, but installation didn't worked :/
    I also use WM on Debian on other macs, it's my fav linux environment for now :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 16, 2014, 05:51:12 am
    eagle, are you still working on improving keyboard input?
    How far did you get?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 16, 2014, 11:30:48 am
    Hey Andreas.  I got your email the other day, and I'm sorry that I haven't replied.  I've been looking at it some, but I haven't made any progress beyond that.  If someone else wants to take a look at it, it won't hurt my feelings.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 18, 2014, 08:56:38 am
    Thanks for the reply. I plan to release 0.4 very soon now. The only thing i'd like to do before is to test if NeXTstep 0.8 boots.

    There will be known bugs in that release, including the "root on" hang, bad key assignment (including shortcuts) and timing problems causing hangs when mounting MO and SCSI disks.
    These will be fixed in the next release. I don't want hold 0.4 back longer. Maybe we can find some more help when 0.4 is out.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 18, 2014, 11:30:48 am
    Good to hear a 0.4 release is coming soon. It'll help those who can't build from svn.

    Does 0.8 differ enough from 0.9 to causes problems with Previous?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 19, 2014, 07:38:23 am
    Quote from: "protocol7"Does 0.8 differ enough from 0.9 to causes problems with Previous?


    I don't know it. Therefore i need to test it   :wink:

    There have been critical differences between 0.9 > 1.0, 2.0 > 2.1 and 3.1 > 3.2.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 19, 2014, 12:36:09 pm
    Ah I see.

    I don't have 0.8 so I can't help you there.
    Title: Previous on Mavericks
    Post by: ijelorriaga on April 20, 2014, 01:15:18 pm
    Is there a link to a binary that works under OSX 10.9.3?
    All the ones here do not start even with XQuartz installed.
    Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on April 22, 2014, 10:21:45 am
    There was some progress on the MESS NeXT driver (Link (http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=44666&page=414)).
    Maybe contact to the MESS developer Olivier Galibert would be interesting for the previous developers (contact page: Link (http://forums.bannister.org/ubbthreads.php?ubb=showprofile&User=80))?

    Obviously, it can boot now some NeXTstep OS 3.x:
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 22, 2014, 05:29:37 pm
    ijelorriaga, you need the SDL library (on Mac OS X copy to /Library/Frameworks). In the final release version i will include SDL within the application bundle.

    Kitchen2010, thank you for the hint! Very interesting to see that MESS now also boots NeXTstep. There seem to be some problems with drawing the GUI, but colors look much better. I'll try to contact the developer.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 22, 2014, 07:35:22 pm
    Quote from: "andreas_g"... but colors look much better.


    the colors of this MESS/NeXT indeed seem to be accurate. I just checked with screenshots (TIFF) I have from NS 3.3 on i386 (hardware & VMWare)  and M68k/NeXTdimension). in VMWare, the colors are only a tiny little bit off.

    default desktop color should be R:87 G:86 B:117 and grey (window titlebar, menus etc) should be R:169 G:169 B:169
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 22, 2014, 07:37:59 pm
    Mike, I did notice that the colors being displayed by my VMware VM running NeXTSTEP 3.3 x86 are close to what I see in that MESS screenshot.

    Color accuracy would be lower on my personal priority list, because (as you can see from my signature), I have only ever had grayscale NeXT systems, so to have ANY color in Previous is nice.  8)
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 22, 2014, 07:45:41 pm
    Quote from: "eagle"Mike, I did notice that the colors being displayed by my VMware VM running NeXTSTEP 3.3 x86 are close to what I see in that MESS screenshot.

    Color accuracy would be lower on my personal priority list, because (as you can see from my signature), I have only ever had grayscale NeXT systems, so to have ANY color in Previous is nice.  8)


    and I am probably the only living soul on earth who wishes that there's a 2-bit greyscale display-driver (1120x832) for NeXTSTEP/OPENSTEP on VMWare  :P
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 22, 2014, 07:49:29 pm
    Quote from: "mikeboss"and I am probably the only living soul on earth who wishes that there's a 2-bit greyscale display-driver (1120x832) for NeXTSTEP/OPENSTEP on VMWare  :P

    You know, I would dig that.  2-bit grayscale is much easier to look at than is straight B&W.

    For my NS2.x instances of Previous, I have 2 config files to choose from: one color, one grayscale.  With NS3.x and OS4, I have color only, but for v2, I set up both.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on April 23, 2014, 04:41:47 am
    Quote from: "mikeboss"
    Quote from: "andreas_g"... but colors look much better.


    the colors of this MESS/NeXT indeed seem to be accurate. I just checked with screenshots (TIFF) I have from NS 3.3 on i386 (hardware & VMWare)  and M68k/NeXTdimension). in VMWare, the colors are only a tiny little bit off.

    default desktop color should be R:87 G:86 B:117 and grey (window titlebar, menus etc) should be R:169 G:169 B:169


    Colors are 12-bits value tucked into the top bits of 16-bits words.  Bits 12-15 are red, 8-11 are green and 4-7 are blue. 0-3 are always 0xf.

    Donc forget to duplicate the bits when converting to rgb24, e.g. 0xc becomes 0xcc.

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 23, 2014, 03:00:15 pm
    I was fiddling with src/convert/high640x8.c, modifying the for loop on lines 126-127, and I succeeded in getting an all-black screen one time (couldn't see a thing), and blue-tinted screen another time.  It was really neat, but pointless. :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 23, 2014, 07:15:06 pm
    The color drawing problem is solved. We forgot to change color depth for SDL. It always converted our colors to 8-bit (256 colors).

    eagle pointed me to a bug that prevented drawing acceleration by only drawing changed pixles. That one is fixed too.

    galibert, thank you for the hint with bit duplication! That one is also fixed now for full accuracy. Good to see you in the forums, already wanted to contact you. I think some communication helps both, MESS' and Previous' NeXT emulation.

    Note for Mac OS X users:
    There is a known bug in SDL that causes a blue tinted output in some circumstances (e.g. after minimizing and maximizing the window). Other emulators suffer from this too. If it gets too annoying, we can later switch off drawing acceleration on the Mac OS X release of Previous 0.4.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 23, 2014, 07:24:26 pm
    Wow, the colors look so much better now!  Thanks, Andreas.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on April 23, 2014, 08:37:04 pm
    Quote from: "andreas_g"I think some communication helps both, MESS' and Previous' NeXT emulation.


    I think so too.  It's not a race.

    Two things I found out today if you want to do network emulation:
    - packets *must* be at least 64 bytes (it's in the ethernet standard) or the kernel will drop them on the floor.  Pad with zeroes.
    - the mb8795 passes on four more bytes extra, probably the ethernet crc.  The kernel doesn't care what's in there, but they must be there.

    I really need to find out why the all-black theorical white-on-black though (windows titles, terminal windows...), it's real annoying.

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 24, 2014, 12:18:22 am
    Quote from: "eagle"Wow, the colors look so much better now!  Thanks, Andreas.

    QFT!

    The colour emulation was one of the more obvious bugs so it's great to see that one finally squished.

    Thanks to Kitchen2010 for pointing out the MESS driver and to Olivier for the input. I'm sure both sides will benefit from this collaboration.
    Title: still doesnt work
    Post by: ijelorriaga on April 24, 2014, 12:20:03 am
    Quote from: "andreas_g"ijelorriaga, you need the SDL library (on Mac OS X copy to /Library/Frameworks). In the final release version i will include SDL within the application bundle.
    .


    I put 1.2 and 2.0 framework an still doesnt work... trying build 0.3... and nothing....
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 24, 2014, 12:24:55 am
    2.0 won't work. You need 1.2.15.

    I didn't copy the framework, I installed it using Homebrew (http://brew.sh/). You can also use MacPorts I guess.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 24, 2014, 06:38:15 am
    galibert, i'm aware of the extra bytes. It's already handled in our dummy ethernet controller for the power-on test.
    There are also 15 extra bytes for outgoing packets. If i remember correctly, they are also all 0.

    I'm not an expert with hardware design, but maybe the ethernet encoder/decoder (Fujitsu MB 502A) needs these extra pulses from the DMA controller to receive parity bytes and send parity, preamble and other ethernet frame parts.

    I definitely want to add networking at some point. First i'd need to add some cross-platform networking library.

    ijelorriaga, 0.3 is very outdated. It is quite useless. You can try to compile the latest code from the repository (http://sourceforge.net/p/previous/code/HEAD/tree/). But i recommend to wait for the binary release of 0.4
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 24, 2014, 07:22:03 pm
    Quote from: "andreas_g"Note for Mac OS X users:
    There is a known bug in SDL that causes a blue tinted output in some circumstances (e.g. after minimizing and maximizing the window). Other emulators suffer from this too. If it gets too annoying, we can later switch off drawing acceleration on the Mac OS X release of Previous 0.4.

    This is definitely an issue on both of my systems, so I searched the source code and figured out how to disable it: you set the environment variable SDL_FBACCEL to 0, then start Previous.  Since I'm starting Previous from the command line, it is getting the environment from the shell.

    Also, here's a screenshot of Previous and VMware, both running NeXTSTEP 3.3.

    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on April 25, 2014, 02:34:55 pm
    NS0.8 image is at https://dl.dropboxusercontent.com/u/33134372/NeXT/ns08.dd.gz

    I tested this in the latest Previous build... it boots fine but the mouse is a bit jerky. Some keyboard input also causes a panic.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 25, 2014, 02:41:16 pm
    Quote from: "gtnicol"NS0.8 image is at https://dl.dropboxusercontent.com/u/33134372/NeXT/ns08.dd.gz

    I tested this in the latest Previous build... it boots fine but the mouse is a bit jerky. Some keyboard input also causes a panic.


    Thanks for sharing this. Can't wait to give it a try.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 25, 2014, 04:52:19 pm
    Thanks gtnicol for providing the images!
    Thanks for Colour support!
    I have set this things to previous-
    System - NeXT Computer
    SCSI -  ns08.dd (Extracted)

    If I boot by rom-Monitor -

    (http://postimage.org/)
    hosting images (http://postimage.org/)

    rebooting rebooting but no results! :shock:

    by setting Boot options - SCSI Disk

    (http://postimage.org/)
    image hosting over 5mb (http://postimage.org/)

    Then

    (http://postimage.org/)
    free photo upload (http://postimage.org/)

    Here he stops

    (http://postimage.org/)
    image upload no compression (http://postimage.org/)

    :shock: but mouse is moveable
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 25, 2014, 05:19:48 pm
    gtnicol, thank you very much!
    There was indeed a problem that caused panics. Luckily it was a very simple issues. There were some registers missing from the DMA. After adding them, everything seems to be good.
    There are some inconsistencies in the image's file system. But after auto-rebooting three times it seems to work properly. I think that one is image related and not an emulation problem.

    Finally, i think i can prepare to release 0.4 during the next days!
    I'll add a very short readme with known bugs and missing features.
    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on April 25, 2014, 08:03:06 pm
    I will go back and check the image... that should have been a direct HDD image, but it may have been the one after panicking.

    From memory, NS 0.8 will always check the file system when booting, and it's quite lax about saving things too, so you have to be a bit careful!

    One other thing I noticed is that trying to boot the 68030 with the 2.5 ROM seems to fail?
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 25, 2014, 10:22:36 pm
    I was able to boot it OK with a 030 setup after letting it repair the disk (the second time it said to fsck manually) but I had two mouse pointers which was a bit weird. I also had to run it on my MacBook as my PC was tied up, so I was stuck with the bottom of the screen missing due to the 1280x800 res. I'll build the latest version now and try it again.

    Updated and no double mouse pointers this time :)

    Title: What Needs to be done for a NeXT Emulator
    Post by: jroark on April 26, 2014, 02:13:04 am
    Silly question... How does one shutdown NeXTStep 0.8? Logout only logs out and shutdown from the terminal is not found?
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 26, 2014, 02:14:01 am
    Control + F10 does it here.
    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on April 26, 2014, 02:51:48 am
    I went back and checked the disk image, and it is the one that came directly from the HDD I used to verify it booted properly. I found 0.8 to be a little fragile, but that said, I have also configured a network of 0.8 machines and had them send email messages with voice attachments to each other.

    Think about the time period... quite an amazing feat of engineering all around.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 26, 2014, 07:08:26 am
    Quote from: "gtnicol"One other thing I noticed is that trying to boot the 68030 with the 2.5 ROM seems to fail?


    I think that is normal behavior. As far as i know the ROMs are "assigned" like this:
    1.x: 68030 Cube
    2.x: non-Turbo 68040 machines
    3.x: Turbo machines
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 26, 2014, 09:46:42 am
    grayscale is now accurate, too  8)

    Title: What Needs to be done for a NeXT Emulator
    Post by: domiel on April 26, 2014, 11:44:19 am
    Is anyone else still having problems getting Control-C to work during the install?

    (I'm using branch_mmu, and I've built it on OpenSUSE 13.1)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 26, 2014, 01:19:38 pm
    No I don't have the problem. Is your Previous version is 4. The problem may be for wrong keymap.
    Title: What Needs to be done for a NeXT Emulator
    Post by: domiel on April 26, 2014, 01:59:09 pm
    I'm building the source from the repository.

    Also, keymap is US so it shouldn't be a problem.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 26, 2014, 09:06:06 pm
    Keyboard input is very platform sensitive. I can only test on Mac OS X.
    I guess your keyboard has a key that is labeled as control? It would be interesting what is logged when you press control-C.

    The debugging code is in keymap.c, line 252 and line 267.
    To see debugging messages you may need to set nTextLogLevel in the configuration file to 4. Or you can quickly modify the sources with printf to log the values.
    Title: What Needs to be done for a NeXT Emulator
    Post by: pl212 on April 26, 2014, 10:19:27 pm
    0.8 booted fine under Previous build 354, OS X Mavericks:



    FSCK took forever, but seemed only to run once.  Initial desktop, after opening a window or two:



    Mouse is pretty erratic, however -- jumpy and unpredictable. Have not yet tried adjusting the mouse scaling settings...
    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on April 27, 2014, 12:56:21 am
    I compiled Previous on Ubuntu 12 64 bit, and had pretty much the same thing... fsck once, and after that, basically fine (except the mouse).
    Title: What Needs to be done for a NeXT Emulator
    Post by: domiel on April 27, 2014, 11:04:04 am
    Andreas, I was going to test the logging you mentioned in your previous response but I just noticed that when you start previous up and go into the config there is a keyboard option with the following;

    Symbolic
    Scancode
    From file

    Mapping file:

    It's currently set to Symbolic but I'm wondering if I aught to have it differently?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 27, 2014, 11:53:41 am
    Those preferences have no effect. The keyboard mapping code is not yet implemented for Previous. I might remove that keyboard dialog, until it gets useful.
    Title: What Needs to be done for a NeXT Emulator
    Post by: domiel on April 27, 2014, 12:27:17 pm
    Andreas,

    Here's the keycodes I get in the log when I try and Ctrl-C:

    Key pressed: left ctrl
    Keycode: $00, Modifiers: $08
    Key pressed: c
    Keycode: $33, Modifiers: $08
    Key released: c
    Keycode: $33, Modkeys: $08
    Key released: left ctrl
    Keycode: $00, Modkeys: $00
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 27, 2014, 12:44:52 pm
    It recognizes the key as "left control" but sets the modifier bit for "left meta" ...

    In your personal build you can change keymap.c, line 134 and replace KMOD_LCTRL and KMOD_RCTRL with KMOD_LMETA and KMOD_RMETA.
    This is really bad handling on the SDL side! I will have to fix it together with the other keyboard mapping in a future release. There is no easy fix for this.

    Alternatively you can try if the "meta" key is seen as control. On my Mac keyboard "meta" is the command key.
    Title: What Needs to be done for a NeXT Emulator
    Post by: domiel on April 27, 2014, 01:24:15 pm
    By the way, I often get:

    "System test failed.   Error code 91."

    on startup but it's not consistent.

    Any thoughts on this?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 27, 2014, 01:33:42 pm
    This is a simple timing problem. On fast host systems, the power-on test will not see the real time clock tick before its internal timer runs out. Therefore it reports that our clock is broken (error code 91).
    Sometimes it will see it tick nevertheless because the time to the next tick is random depending when you launched the emulation.

    This is nothing to worry about. It should not cause any side effects. But of course timings are something we need to improve on.
    Title: What Needs to be done for a NeXT Emulator
    Post by: domiel on April 27, 2014, 01:37:19 pm
    Sigh!

    Your quick fix in substituting Ctrl for Meta didn't seem to work for me  :(

    Strangely it's still picking up the key the same way :?

    Key pressed: left ctrl
    Keycode: $00, Modifiers: $08
    Key pressed: c
    Keycode: $33, Modifiers: $08
    Key released: c
    Keycode: $33, Modkeys: $08
    Key released: left ctrl
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 27, 2014, 02:19:39 pm
    This is impossible. It can only print "Modifiers $09".
    Maybe something is wrong with compiling. Check if it really uses "translate_modifiers" and not "modifier_keydown". You can replace line 169 and 170 the same way than before (CTRL --> META) and check if the output changes.
    Title: What Needs to be done for a NeXT Emulator
    Post by: domiel on April 27, 2014, 03:27:34 pm
    Quote from: "andreas_g"This is impossible. It can only print "Modifiers $09".
    Maybe something is wrong with compiling. Check if it really uses "translate_modifiers" and not "modifier_keydown". You can replace line 169 and 170 the same way than before (CTRL --> META) and check if the output changes.



    Argh!

    The trunk which I'd compiled originally created a binary called 'previous' and branch_mmu created a binary called 'Previous' (note the difference in case)... so I've been running the trunk the whole time :oops:  :evil:

    So, now I can install NS3.3 _but_ the window now says "shortcut-m" to release the mouse.... I've tried every key combination I can think of and none work.

    And then, once I've done an install of 3.3 and reboot it gets stuck on 'root on sd0'

    :(

    In any case... thanks for your efforts! Real close now :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 27, 2014, 03:37:57 pm
    I know reading READMEs is not very popular. But please everyone read the one i included with the sources recently and check for known issues before reporting them here. It starts to get quite time consuming to respond to the issues repeatedly. Also it makes this thread quite unreadable.

    I'm glad control-C is not broken again. The shortcuts will be fixed together with the other keyboard issues later. It is not that simple.

    UPDATE: I added a quick fix for shortcuts that should enable everyone to get out of mouse locked mode. There is still the problem that shortcuts interfere between host and guest systems.
    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on April 27, 2014, 03:44:37 pm
    FWIW. I have been looking at the jerky mouse problem, and it's pretty clear that the SDL and NeXT layers are fighting over mouse acceleration. I found that on Ubuntu, and probably other systems, disabling host OS mouse acceleration (xset m 0 0) makes the mouse action much smoother.

    Perhaps there is some way to map the absolute mouse positions and thereby bypass all the acceleration code?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 27, 2014, 04:17:25 pm
    Mouse motion inside the guest system is variable. So it is not possibly to track the mouse cursor. Also i don't know of a way to make SDL use raw mouse motion data. I don't think it is possible.

    But there is a chance that the exponential adjustment from the mouse menu helps you.
    It "decelerates" the mouse motion like this (example values for 0.88 in pixels):
    2 --> 2
    10 --> 8
    20 --> 14
    100 --> 58

    The smaller the setting, the more it will shrink large values (0.5 would be square root). This should compensate for host mouse acceleration without making the guest cursor stop on slow movement.
    In combination with the linear adjustment it should be possible to find a good setup for slow and fast movement with a bit of experimenting.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 28, 2014, 03:26:49 pm
    Andreas, I was wondering if it would be possible to have multiple emulators running simultaneously.  Of course, I will have to undo the shared disks I have created (this becomes more feasible after we have networking, because I can move the shared disks to NFS), but it would be a very nice feature.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 28, 2014, 03:45:26 pm
    Quote from: "eagle"Andreas, I was wondering if it would be possible to have multiple emulators running simultaneously.


    at least in OS X this is no problem at all: just duplicate "Previous.app" and start one after the other...


    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 28, 2014, 04:39:34 pm
    Quote from: "andreas_g"I definitely want to add networking at some point. First i'd need to add some cross-platform networking library.

    For Ethernet we can see Basilisk II slirp Ethernet driver. It is cross-platform. Here is its Technical Manual (http://basilisk.cebix.net/TECH). We have to recode the code with Fujitsu MB 502A (http://www.nextcomputers.org/NeXTfiles/Docs/Hardware/Datasheets/Ethernet-nonTurboNeXT/Fujitsu_MB502_MB8795.pdf). The main problem is there are no book like Inside NeXT(like Inside Macintosh,Inside AppleTalk). I am thinking that we will have to search again the netbsd sources!
    And also I have started writing Previous User's Manual for Gilles and Andreas so they can include the manual with the releases.
    Can any tell me how to boot by floppy on real NeXT hardware?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 28, 2014, 04:43:27 pm
    Mominul, to boot from floppy, you run "bfd" from the ROM Monitor after inserting the floppy.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 28, 2014, 04:52:49 pm
    Quote from: "mikeboss"
    Quote from: "eagle"Andreas, I was wondering if it would be possible to have multiple emulators running simultaneously.


    at least in OS X this is no problem at all: just duplicate "Previous.app" and start one after the other...

    Sure, that works.  I guess I'll do that, for now anyway.  It would be nicer if a single instance of the application could run multiple emulated systems, like VMware Fusion's virtual machines.  I guess that's really a feature for some time in the distant future.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 28, 2014, 06:04:07 pm
    Quote from: "eagle"Andreas, I was wondering if it would be possible to have multiple emulators running simultaneously.

    That will need quite big changes. Or maybe some kind of wrapper that starts multiple instances of the emulator automatically. That may be something for later ... much later   :wink:
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 30, 2014, 04:21:17 am
    Dear NeXT community,

    i'm happy to be able to finally announce the availability of Previous v0.4.

    You can load the binary for Mac OS X here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.4.zip).

    It should run on Mac OS X v10.5.8 and later (only on Intel Macs). Please read the README before running the application. This is software in early development state. Make sure you only work on copies of your images.
    Before reporting bugs, first check if the are in the known issues list.

    Builds for Windows and Linux will follow soon. Homepage update will follow soon too.
    Previous 0.4 is branch_mmu, revision 357 in the repository.

    This was only possible with the help of Toni Wilen, who fixed the CPU/MMU/FPU part recently and of course Gilles and many others (check the README).

    Have fun testing   :wink:

    Andreas

    btw. Kitchen2010, can you update Wikipedia? Previous is now confirmed to boot all versions of NeXTstep and OPENSTEP!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on April 30, 2014, 10:49:17 am
    Thank you, andreas_g for all your hard work !

    I will update the Wikipedia page (https://en.wikipedia.org/wiki/Previous_(emulator)) when the project page gets updated information on Previous Release 0.4.

    Unfortunately, all my screenshots on the Wikipedia page, taken from this thread, was taken down because they are not with free copyright.
    Can someone provide me with screenshots of every version of NeXTStep (0.8, 0.9, 1.0, 2.1, 2.2, 3.2, 3.3 and 4.0 beta) and OpenStep (4.0, 4.1, 4.2) running in Previous and some with some original NeXT software (Lotus Improv, Altsys Virtuoso, Wolfram Mathematica 1.0, Adobe Illustrator 3) released under GPL, please ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 30, 2014, 11:40:13 am
    You're welcome to use any of mine (https://secure.flickr.com/photos/96579068@N05/sets/72157642153393653/). I updated them recently now that Previous is displaying colour correctly.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 30, 2014, 12:26:36 pm
    feel free to use any of my screenshots, too ->

    http://www.flickr.com/photos/87645035@N04/
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 30, 2014, 12:55:54 pm
    You're also welcome to use any of the screenshots I posted.

    Also, a screenshot of mine was removed from wikipedia too; it was a NeXT-based Lotus Improv screenshot.  Before we posted that, there were only Windows-based screenshots, but all of those were removed too.

    It's off-topic, but I really don't understand the copyright problems with posting screenshots of software I own.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on April 30, 2014, 01:18:24 pm
    Quote from: "eagle"It's off-topic, but I really don't understand the copyright problems with posting screenshots of software I own.

    I don't know exactly how wikipedia operates but I imagine the issue is that you have to give permission for the photos to be used.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 30, 2014, 03:16:58 pm
    I have been able to install Openstep 4.2 User. I get the install image from galgot. Here the I mages -

    (http://postimage.org/)
    upload picture (http://postimage.org/)

    (http://postimage.org/)
    image upload free (http://postimage.org/)

    And also Kitchen2010 you can use all image I posted on the forum and you can license the images as GPL or what you like!
    I am writing the Previous User's Manual.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on April 30, 2014, 07:43:28 pm
    Many thanks for that last version.
    Works very well !
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 07, 2014, 06:33:16 am
    I've been working on the magneto-optical disk drive emulation during the last days.

    I found some bugs. Now it seems to fully work for NeXTstep 0.8 to 2.2, and maybe also 3.0.
    But there remains a strange issue that is confirmed for 3.1, 3.3 and 4.0beta (3.2 and OPENSTEP untested):
    After building the MO disk it first boots fine. But on second boot, the Workspace Manager won't come up and goes to an infinite loop with grey screen. The disk remains corrupted on all subsequent tries. Only original 68030 NeXT Computer is affected. 68040 NeXTcube seems to work without that issue, bon't also won't boot disks that are already corrupted under 68030.

    I know, it's unlikely, but does anyone know of such an issue with real hardware?

    After making the MO drive work, i'd like to work on keyboard input. But i think it might make sense to switch to SDL 2 first. Anyone interested in helping with that? First of all it would require some changes to the cmake files. I've not been able to make it see SDL 2 yet.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on May 08, 2014, 07:18:00 am
    I am kicking around of SDL 2!
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on May 08, 2014, 11:41:11 am
    Quote from: "andreas_g"I've been working on the magneto-optical disk drive emulation during the last days.


    Did you identify which error correction method it uses?

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 08, 2014, 12:21:01 pm
    It most likely uses cross interleaved Reed Solomon Codes:

    Every sector has 1024 byte of user data. Imagine them as square of 32 x 32 byte. Every column and every row is then encoded using RS(32,36). This generates 4 parity bytes for each row and column.

    The columns are encoded first and the parity bytes are appended under each column. Then the rows are encoded, including the parity bytes of the previously encoded columns, inserting the parity bytes at the end of the row. Decoding of course works in reversed sequence.

    This is an example for an encoded sector (simplified with 8 data bytes), where d = data, r = row parity bytes, c = column parity bytes:
    d d d d d d d d   r r r r
    d d d d d d d d   r r r r
    d d d d d d d d   r r r r
    d d d d d d d d   r r r r
    d d d d d d d d   r r r r
    d d d d d d d d   r r r r
    d d d d d d d d   r r r r
    d d d d d d d d   r r r r

    c c c c c c c c   r r r r  
    c c c c c c c c   r r r r
    c c c c c c c c   r r r r
    c c c c c c c c   r r r r


    It seems to work properly, correcting all errors in the power-on and diagnostic tests and giving correct error counts. Nevertheless is seems to be not 100 % accurate, because the generated parity bytes are not idetical to those from real hardware. I tried all available generator polynomials without finding the same values. It seems there must be something special in the algorithm.

    For my implementation you can have a look at mo.c, starting at line 782 and Henry Minsky's RSCODE (http://rscode.sourceforge.net/).
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on May 08, 2014, 07:58:26 pm
    Quote from: "andreas_g"Nevertheless is seems to be not 100 % accurate, because the generated parity bytes are not idetical to those from real hardware.


    Very nice, thanks.  Do you have dumps from real hardware available?

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 09, 2014, 06:41:54 am
    This is an example of an encoded sector with test data:
    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F   97 2E B3 0A
    20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F   55 2A FD 82
    40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F   0E 26 2F 07
    60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F   CC 22 61 8F
    80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F   B8 3E 96 10
    A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF   7A 3A D8 98
    C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF   21 36 0A 1D
    E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF   E3 32 44 95
    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F   97 2E B3 0A
    20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F   55 2A FD 82
    40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F   0E 26 2F 07
    60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F   CC 22 61 8F
    80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F   B8 3E 96 10
    A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF   7A 3A D8 98
    C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF   21 36 0A 1D
    E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF   E3 32 44 95
    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F   97 2E B3 0A
    20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F   55 2A FD 82
    40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F   0E 26 2F 07
    60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F   CC 22 61 8F
    80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F   B8 3E 96 10
    A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF   7A 3A D8 98
    C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF   21 36 0A 1D
    E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF   E3 32 44 95
    00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F   97 2E B3 0A
    20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F   55 2A FD 82
    40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F   0E 26 2F 07
    60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F   CC 22 61 8F
    80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F   B8 3E 96 10
    A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF   7A 3A D8 98
    C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF   21 36 0A 1D
    E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF   E3 32 44 95

    45 9B E4 3A 1A C4 BB 65 FB 25 5A 84 A4 7A 05 DB 24 FA 85 5B 7B A5 DA 04 9A 44 3B E5 C5 1B 64 BA   76 A9 9F 40
    B0 1D F7 5A 3E 93 79 D4 B1 1C F6 5B 3F 92 78 D5 B2 1F F5 58 3C 91 7B D6 B3 1E F4 59 3D 90 7A D7   FA DA B0 90
    AF 9F CF FF 6F 5F 0F 3F 32 02 52 62 F2 C2 92 A2 88 B8 E8 D8 48 78 28 18 15 25 75 45 D5 E5 B5 85   E1 02 7A 99
    5A 19 DC 9F 4B 08 CD 8E 78 3B FE BD 69 2A EF AC 1E 5D 98 DB 0F 4C 89 CA 3C 7F BA F9 2D 6E AB E8   6D 71 55 49
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 12, 2014, 06:48:41 pm
    Andreas, I updated to revision 361 today, using the main trunk, not a branch, and I note that the mouse is working much better now!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 13, 2014, 07:02:28 am
    Trunk is outdated. You will see some of the old FPU related problems, bad colors and crashing NeXTstep 0.8.

    The version in trunk uses fixed mouse motion speed adjustments. That is now adjustable from the GUI (Mouse menu).
    You'll get the same result when setting linear adjustment to 0.1 for locked mode and 0.5 for unlocked mode and leaving exponential adjustment at default (1.0).
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on May 15, 2014, 08:52:54 am
    Quote from: "andreas_g"i'm happy to be able to finally announce the availability of Previous v0.4.

    You can load the binary for Mac OS X here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.4.zip).

    It should run on Mac OS X v10.5.8 and later (only on Intel Macs).
    Great work! It seems to require Mac OS X v10.7. But patching two bytes: 0020da29 33 -> 32, 00001cd9 33 -> 32 in Previous.app/Contents/MacOS/Previous, makes it run on 10.6. The reason is that Lion builds it to use /usr/lib/libedit.3.dylib, but 10.6 has /usr/lib/libedit.2.dylib.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on May 15, 2014, 10:19:30 am
    OK, I updated the Wikipedia-Entry (http://en.wikipedia.org/wiki/Previous_(emulator)) on Previous to the final version 4.0 and placed also some galleries of screenshots there.
    Unfortunately andreas_g's uploaded screenshots of the first boots are no longer available at DropBox, so I could not add them, too.
    Feel free to donate some more screenshots.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on May 20, 2014, 06:11:05 pm
    Quote from: "andreas_g"This is an example of an encoded sector with test data(...)[/code]


    Thanks.  Took me a little while to understand how RS worked, but now I think I have it.  The GF(256) mod is the usual 11d, and the generator polynomial is (x-1)(x-2)(x-4)(x-8 ).  E.g. alpha is 2, and they, unusually, start with alpha**0.

    Gonna try to write the corresponding code.

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 21, 2014, 05:29:08 am
    Well done! I didn't manage to understand all of that. Can you patch RSCODE to make it work that way?

    I'm still trying to make the MO drive work properly. It already works in many situations, but with later NeXTstep versions and with dual MO drives it fails quite frequently.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on May 21, 2014, 05:51:42 pm
    Quote from: "andreas_g"Well done! I didn't manage to understand all of that. Can you patch RSCODE to make it work that way?


    I'll send you my code once it works (I encode correctly, but I don't decode yet).  What's the original byte order btw?

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 21, 2014, 06:37:58 pm
    Quote from: "galibert"What's the original byte order btw?

    I'm not sure what you mean. I guess you are thinking about endianness?
    I don't know how that is related to the ECC. I'm afraid i don't know the answer.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on May 21, 2014, 08:16:23 pm
    Quote from: "andreas_g"
    Quote from: "galibert"What's the original byte order btw?

    I'm not sure what you mean. I guess you are thinking about endianness?
    I don't know how that is related to the ECC. I'm afraid i don't know the answer.


    I mean the order of the data in the 0x510 bytes block.  Is it as you copy/pasted it (which means they move the data around when they compute the ecc) or did you reorganize it to make it readable?

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 22, 2014, 05:30:57 am
    Thanks for the clarification! The byte order on a real machine is exactly how i posted it.
    The "row" parity bytes are inserted between the data bytes and the "column" parity bytes are appended at the end the way you see it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on May 23, 2014, 11:57:07 am
    Quote from: "andreas_g"Thanks for the clarification! The byte order on a real machine is exactly how i posted it.
    The "row" parity bytes are inserted between the data bytes and the "column" parity bytes are appended at the end the way you see it.


    Thanks.  Here you go then, you should be able to integrate that code (http://dspnet.fr/~galibert/nextmo.zip) without any particular difficulty.

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 24, 2014, 04:12:47 pm
    Thank you very much! I added it to Previous (not yet in SVN).
    With some minor modifications it now passes all diagnostics! Good work!

    I had to reverse the decoding sequence to decode rows first. Else it would give unexpected error counts.
    I removed decoder repeating, because i don't think real hardware will do that.

    Also did some minor renaming to match Previous' style.

    You can look at the modified version here: rs.c (https://dl.dropboxusercontent.com/u/44703754/rs.c.zip)

    Please tell me what header i should use to reflect your contribution and the license.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on May 24, 2014, 07:13:11 pm
    Quote from: "andreas_g"Please tell me what header i should use to reflect your contribution and the license.


    Just use the same license than the rest of previous :-)

     Olivier Galibert.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on May 27, 2014, 10:40:40 am
    Hello Andreas I have added new Previous icon and did some changes to Previous.
    To Linux Users - Please check that the Left ctrl-alt-m is able to grab the Mouse.
    Here   https://dl.dropboxusercontent.com/s/ky6uls6yickxtwe/Previous%20branch-mmu.zip
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 27, 2014, 04:35:55 pm
    I added your patch and new icon with minor modification.
    Please check if it works.

    I also updated the icon for Mac OS X with the one made by galgot. Thanks for that!

    The new ECC code is also in SVN.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on June 01, 2014, 05:08:52 pm
    Please replace CMakeLists.txt (https://dl.dropboxusercontent.com/s/0z2s523z4s5spxh/CMakeLists.txt) with src/CMakeLists.txt.
    In main.h #elif defined(_WIN32_) does not work.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on June 02, 2014, 09:43:16 am
    Quote from: "andreas_g"I added your patch and new icon with minor modification.
    Please check if it works.

    I also updated the icon for Mac OS X with the one made by galgot. Thanks for that!

    The new ECC code is also in SVN.


    Your welcome :) Happy to have contributed a little.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 02, 2014, 10:23:33 am
    galibert, you wrote an improved ECC encoder/decoder, so i guess you are working on the MO drive in general?
    Feel free to use my code. Unfortunately there are remaining problems. NeXTstep 3.0 and later cause disk image corruption on 68030. When using a setup with 2 MO drives, hangs and other strange behaviors occur.
    Do you have an idea, what might be wrong? Disk image corruption might be DMA related, but i couldn't find the problem. (btw. do you have an idea how unaligned DMA start addresses should be handled in connection with burst reads/writes?)

    After more testing your ECC code seems to be correct in all cases. So that is not a source for my problems.


    Mominul, i'll have a look at the CMakeLists again, but i'm not sure if that will break other things. You wrote the lines for main.h. Can you fix it? I think there will also be changes necessary to shortcut.c.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 02, 2014, 02:17:44 pm
    All, is control-drag working for you in Previous?  I'm using branch_mmu, revision 365.  I'm trying to use Interface Builder to create connections between objects, and control-drag is not creating the line/connection as it should.

    I do know that the control key works, because I can use it in Terminal.

    I have now confirmed that doing exactly the same thing in NeXTSTEP 3.3 for Intel (in VMware), works fine.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on June 02, 2014, 02:55:52 pm
    Here is new main.h (https://dl.dropboxusercontent.com/s/e256vbm1pj5plsv/main.h) and working very nicely on windows.
    please replace src/CMakeLists.txt line 26 with this-set(GUIWIN_RES gui-win/previous-winicon.rc)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on June 03, 2014, 05:53:20 pm
    Thank you Andreas for adding my Patch!   :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 04, 2014, 04:55:30 pm
    Quote from: "eagle"All, is control-drag working for you in Previous?  I'm using branch_mmu, revision 365.  I'm trying to use Interface Builder to create connections between objects, and control-drag is not creating the line/connection as it should.

    I tested it and indeed that is broken. The problem is, that SDL does not report the modifier keys, if no other key is pressed.
    You can try enabling my old modifier code by changing keymap.c, line 127 NEW_MOD_HANDLING to 0. That should fix your problem.
    The problem is, that other users reported that this causes stuck modifiers. I tested but could not reproduce it. So please test for stuck modifier keys too.

    btw. The outdated SDL is a big source of problems. I tried to update to SDL2, but that would need me learn SDL from scratch. I have very little time at the moment. So i can't do that. Maybe someone with SDL skills can help with the update?
    Title: What Needs to be done for a NeXT Emulator
    Post by: SomeGuy on June 06, 2014, 04:29:55 am
    Just thought I would drop in and say nice work on this emulator! It is really awesome being able to see this early NeXT software running.

    I'm getting kind of eager to really try out NeXTSTEP 0.8. :) I buit the Linux version, but when I run it, the mouse cursor flys all over the place. Any ideas on what might be the problem here?

    A Win32 version I was provided with of the latest branch_mmu starts NeXTSTEP 0.8, but the NeXTSTEP desktop immediately crashes. I've tried compiling the Win32 version myself from Linux, but so far every EXE I have coaxed Linux in to building crashes and burns (Obviously I am doing something wrong but don't have time to mess with it any more). If I can't figure out the Linux mouse problem, is there a Win32 build that will boot 0.8? Unfortunately I don't have an Intel Mac to try your MacOS X build.

    Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 06, 2014, 09:06:21 am
    Good to see that there is still some interest in this project!   :)

    The problem with fast mouse cursor is known. You can try to slow it down by adjusting parameters in the "mouse" menu.
    With the help of Thomas Huth from Hatari i'm in the process of switching to SDL2. If we're lucky that will help with the mouse.

    The problem with NeXTstep 0.8 crashing in the Windows build is strange. That should not happen, if it is the latest branch_mmu. I didn't hear reports of that before.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 06, 2014, 10:34:26 am
    Quote from: "andreas_g"
    Quote from: "eagle"All, is control-drag working for you in Previous?  I'm using branch_mmu, revision 365.  I'm trying to use Interface Builder to create connections between objects, and control-drag is not creating the line/connection as it should.

    I tested it and indeed that is broken. The problem is, that SDL does not report the modifier keys, if no other key is pressed.
    You can try enabling my old modifier code by changing keymap.c, line 127 NEW_MOD_HANDLING to 0. That should fix your problem.
    The problem is, that other users reported that this causes stuck modifiers. I tested but could not reproduce it. So please test for stuck modifier keys too.

    Unfortunately that did not seem to make any difference, at least with ctrl-drag.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 06, 2014, 11:09:36 am
    I guess you used latest branch_mmu and you are still on Mac OS X?

    To verify can you please check this:
    Run NeXTstep 3.x and go to a directory you have read/write access using Workspace Manager. The directory needs to contain at least two folders.
    Now grab one of the folders and move it over the other one. Now if you press and hold control, you should see a double-arrow signaling to create a link. If you press and hold alt you should see two squares signaling to copy. Avoid using capslock before doing the test.

    If that works, i guess control should be generally ok.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 06, 2014, 01:24:18 pm
    Found a bug in Workspace Manager in NS 3.3. :)

    I created /me/TEST with /me/TEST/FOO1 /me/TEST/FOO2.  I used 2 viewers, one viewing FOO1, and the other viewing FOO2.  I dragged the FOO1 folder onto the FOO2 folder, and FOO2 opened up to receive FOO1.  Pressing control did not change the cursor, but pressing control + alt changed the cursor to 2 overlapping squares, and releasing control changed the cursor to a double-arrow.

    The bug in Workspace Manager is that I then dropped FOO1 back onto itself, and now I have /me/test/FOO1/FOO1. Oops.

    After all that, the cursor now always changes to a double-arrow cursor, even with no modifier keys pressed.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 06, 2014, 01:31:44 pm
    That sounds quite bad. I think you have the "stuck modifiers" problem.
    I'm afraid you'll have to wait for the SDL2 version for this to be (hopefully) fixed.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 06, 2014, 01:59:18 pm
    Yes, after further testing, I definitely see that I have stuck modifier keys.

    Neither ctrl nor alt activates before I press another key, and then it stays active until I send an unassigned key sequence (such as command-alt-control-shift).  After that, the keys are unstuck.

    And, I did prove that I can invoke ctrl as a lone modifier key if I invoke it as ctrl+alt, then let up on alt.  I can then drag the connection line in Interface Builder, but it's too difficult to get ctrl unset at the same time as I undrag.  Guess I'll wait for SDL2.
    Title: What Needs to be done for a NeXT Emulator
    Post by: SomeGuy on June 07, 2014, 01:19:51 am
    Quote from: "andreas_g"The problem with fast mouse cursor is known. You can try to slow it down by adjusting parameters in the "mouse" menu.

    I tried that, but the cursor still jumped all over the place. It just jumped all over the place a bit slower. :?
    Title: What Needs to be done for a NeXT Emulator
    Post by: SomeGuy on June 11, 2014, 02:02:56 am
    I got the Win32/Mingw version to work properly booting NS 0.8.

    In the file: "newcpu.h" I change the line:
    #if 1   /* set to 1 if your system supports long extended precision long double */
    to
    #if 0   /* set to 1 if your system supports long extended precision long double */

    Here is a compiled version that works for me: Previous_Branch_MMU.zip (http://toastytech.com/guis/Previous_Branch_MMU.zip)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 11, 2014, 05:35:09 pm
    Good to hear it builds and runs properly on Windows!

    Unfortunately i have some bad news for those waiting for SDL2:
    I have now a build of Previous that runs with SDL2. It generally works and seems to be quite a lot faster, but there are remaining bugs that i don't want to introduce. For example on Mac OS X the system shortcuts can't be ignored. Mouse seems to be still accelerated and there is a bug with lost mouse focus after minimizing/maximizing the window.

    I think we'll have to wait until these issues are fixed in SDL2.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 11, 2014, 11:43:32 pm
    Andreas, can we remap command to alt in Previous?  In VMware, in order to send command-h to an app, I have to hit alt-h.  It can be tricky to remember that, but I am reminded of it the first time I send a keystroke to VMware itself.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 12, 2014, 10:49:19 am
    First of all, thanks a lot for the awesome achievements in Previous!!

    I'd like to know if the current status is functional enough for using the compilers and developer tools from the NeXTSTEP Developer CDs. Will that work? Does any NeXTSTEP version run more stable than other in the emulator?

    Also, have the postscript FPU-related glitches and the DMA issues been fixed? I'm asking it because I believe I did read such bugs at the Wikipedia page this week, but I cannot find that anymore, so maybe these bugs have been fixed...

    Also, would it be easy to implement mounting a folder in the OSX host as a disk drive in the emulator? That would be really useful!!

    Thanks!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 12, 2014, 11:32:55 am
    Quote from: "ardi"I'd like to know if the current status is functional enough for using the compilers and developer tools from the NeXTSTEP Developer CDs. Will that work? Does any NeXTSTEP version run more stable than other in the emulator?

    As long as you aren't seeing the stuck modifier key problem, Interface Builder is fine.  I have the Developer Tools installed in every Previous VM that I built.

    QuoteAlso, would it be easy to implement mounting a folder in the OSX host as a disk drive in the emulator? That would be really useful!!

    I think the plan is to use NFS, once networking is working. I don't know of any plans to share a folder directly to the Previous VM.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 12, 2014, 06:38:48 pm
    Quote from: "eagle"Andreas, can we remap command to alt in Previous?

    I don't think we should do that. Swapping alt and command would be a little bit confusing and we would have the same problems again with alt.


    ardi, thanks for the nice words. I think you should have no problems running the developer tools, except some keyboard mapping issues that might occur.

    The FPU and (SCSI-)DMA related problems are fixed. All versions of NeXTstep run.

    Sharing with the host system is not yet possible, because there is no networking in Previous. Unfortunately my time ressources are very restricted at the moment. So please do not expect any new major features in the near future, unless someone else joins in for coding.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 12, 2014, 09:08:51 pm
    Quote from: "andreas_g"Sharing with the host system is not yet possible, because there is no networking in Previous. Unfortunately my time ressources are very restricted at the moment. So please do not expect any new major features in the near future, unless someone else joins in for coding.

    Don't worry, I fully understand. Btw, given that I'm a OSX user, and OSX has great support for disk images, I'm wondering if there would be some easy way of creating a disk image from a folder in OSX in some format that Previous could mount. And also the opposite, if the emulator writes files on a disk, if you could mount such image in OSX in some way.

    Would that be possible? I'm fluent with Terminal and with compiling UNIX tools, so if this can be easily done, point me in the direction.

    Regarding the keyboard issues, has the cause been located, or does it still need to be diagnosed?

    Thanks a lot!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: cuby on June 13, 2014, 12:19:28 am
    Quote from: "ardi"Btw, given that I'm a OSX user, and OSX has great support for disk images, I'm wondering if there would be some easy way of creating a disk image from a folder in OSX in some format that Previous could mount. And also the opposite, if the emulator writes files on a disk, if you could mount such image in OSX in some way.

    MacFUSE/OSXFUSE (user mode file systems, http://osxfuse.github.io) support the nextstep and nextstep-cd UFS filesystem modules. This works fine with "raw" file system images for Previous. It needs a bit of work to compile (since the UFS FUSE modules are only supported in a legacy mode IIRC), however. I probably should find some time to write a HOWTO.

    -- Michael
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 13, 2014, 10:14:09 am
    Quote from: "cuby"
    Quote from: "ardi"Btw, given that I'm a OSX user, and OSX has great support for disk images, I'm wondering if there would be some easy way of creating a disk image from a folder in OSX in some format that Previous could mount. And also the opposite, if the emulator writes files on a disk, if you could mount such image in OSX in some way.

    MacFUSE/OSXFUSE (user mode file systems, http://osxfuse.github.io) support the nextstep and nextstep-cd UFS filesystem modules. This works fine with "raw" file system images for Previous. It needs a bit of work to compile (since the UFS FUSE modules are only supported in a legacy mode IIRC), however. I probably should find some time to write a HOWTO.

    -- Michael

    If it's difficult (or not straightforward) to compile, do you've any precompiled binary for 10.6.x and higher (I mean x86 and x86-64 build, since I'd use this both on 32bit and 64bit Macs). Or do you know any site with precompiled binaries?

    This thing would be greatly useful for Previous until NFS shared folders are implemented, because it would let you transfer files quite comfortably between your Mac and Previous.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 14, 2014, 12:39:05 pm
    I'm in the process of compiling previous on OSX 10.8. It's being difficult because I'm the kind of dude who dislikes system-wide install of third party libraries. So, I compiled SDL-1.2.15, but in my usual fashion (configuring it with --prefix so that when you do 'make install' it's installed on a local dir).

    The problem is the previous cmake system doesn't seem to like a local installation of SDL. When I invoke cmake (with -DSDL_LIBRARY="/whatever" -DSDL_INCLUDE_DIR="/whatever/include" and even with -DCMAKE_C_FLAGS="-I /whatever/include" and the same for -DCMAKE_CXX_FLAGS), then cmake successfully finds my SDL local build:

    -- Looking for include file SDL/SDL_config.h
    -- Looking for include file SDL/SDL_config.h - found


    but unfortunately, when I type 'make', it seems the cmake system totally forgets everything I specified in the cmake command line variables:

    fatal error:
         'SDL_types.h' file not found
    #include <SDL_types.h>
            ^


    What's going on here? Is there anyway I can convince cmake to use my local SDL lib build?

    Thanks!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 14, 2014, 01:19:45 pm
    ardi, finding the SDL_config.h does not automatically mean that SDL was found. There should be another line like:

    -- Found SDL: /Library/Frameworks/SDL.framework;-framework Cocoa (found version "1.2.15")
    Not sure how to fix that problem. But generally i found SDL to be unproblematic. I just dropped the pre-compiled version from the SDL page to my /Library/Frameworks directory.


    Some news for everyone:
    I found out that not only the MO drive corrupts disk images with the combination NeXTstep 3.0 or later + 68030 NeXT Computer. Same problem with SCSI. There must be some emulation bug.
    So i decided to enable the MO drive now (r367). It seems to work quite well, as long as you only use one drive.

    Also i made an SDL2 port, that is not yet in SVN. For all those with some compiling skills: Please compile and test if it fixes some of your issues. You can load the sources here: Previous SDL2 (https://dl.dropboxusercontent.com/u/44703754/previous_sdl2_source_r367.zip).
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 14, 2014, 04:12:55 pm
    Thanks a lot, Andreas. I think I need fresh air, because I believe cmake has succeeded in making me more upset than Microsoft in the Win3.1 days. I don't think I can be used to cmake, because it follows a mindset opposite to mine, and it's broken for SDL on OSX (even cmake developers admit the SDL find module is broken in cmake). I'm trying to convince cmake to use a local SDL build without modifying CMakefiles.txt, and it's getting really hard.

    I've spent a day fighting with this, but I prefer to spend a day rather than installing SDL system-wide...
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 14, 2014, 05:44:35 pm
    Well, it's been tough, but I finally succeeded. Not only I built Previous, but I now have my environment set in a way where I can easily build new versions when you release them, only with a minor change to 'src/MakeLists.txt'.

    The source of my problems were two:

    a) cmake checks for SDL headers by looking for <SDL/SDL_config.h> but however the Hatari source code includes SDL headers without the "SDL/" prefix. This means that you must tell cmake that the SDL headers are at "/MySDLPath/include", but however you must define CFLAGS as "-I /MySDLPath/include/SDL", or otherwise the compile stage will fail.

    b) The cmake SDL find module expects that SDL will be a shared lib. But if you're using a static lib (and it's pretty possible you'll use a static lib if you're building on a local directory), it doesn't add the OSX frameworks as required, so the linking will fail.

    If anybody wishes to build Previous without doing a system-wide install of SDL, these are the steps that worked for me:

    1- Edit 'src/MakeLists.txt'. Look for the line that contains 'set_target_properties'. Just after that line, add a new line like this:
    set_target_properties(Previous PROPERTIES LINK_FLAGS "${LINK_FLAGS} MYSDLPROPERTIES")
    ...where MYSDLPROPERTIES must be the complete output of doing 'sdl-config --libs' on the 'bin' dir of your SDL installation

    2- Create a new subdir for your build in the root directory of the Previous source, and from that new subdir, invoke cmake like this:
    cmake .. -DSDL_LIBRARY="MYSDLPATH/lib/libSDL.a" -DSDL_INCLUDE_DIR="MYSDLPATH/include" -DCMAKE_C_FLAGS="-I MYSDLPATH/include/SDL" -DCMAKE_CXX_FLAGS="-I MYSDLPATH/include/SDL"
    ...where MYSDLPATH is the path where your local SDL build is installed.

    3- Now just invoke 'make', and Previous should build fine, with the app bundle generated in the 'src' dir.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 14, 2014, 08:33:58 pm
    Quote from: "andreas_g"I have now a build of Previous that runs with SDL2. It generally works and seems to be quite a lot faster, but there are remaining bugs that i don't want to introduce. For example on Mac OS X the system shortcuts can't be ignored. Mouse seems to be still accelerated and there is a bug with lost mouse focus after minimizing/maximizing the window.

    I think we'll have to wait until these issues are fixed in SDL2.

    Is the SDL team aware of these bugs? I'm searching for tickets describing these bugs, but didn't find them...
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 14, 2014, 10:06:00 pm
    Quote from: "andreas_g"Also i made an SDL2 port, that is not yet in SVN. For all those with some compiling skills: Please compile and test if it fixes some of your issues. You can load the sources here: Previous SDL2 (https://dl.dropboxusercontent.com/u/44703754/previous_sdl2_source_r367.zip).

    Andreas, sorry for my number of posts today, but I've been building all the day, and wished to report back everything I found.

    After successful build of the SDL-1.2 version, I'm now trying with the SDL2 experimental version. It seems the src/control.c file hasn't been updated to SDL2, because it tries to access some members of SDL_SysWMinfo which no longer exist in SDL2.

    The members that no longer exist and cause errors are:
    wmwindow (line 524 of src/control.c)
    lock_func() (line 525 of src/control.c)
    unlock_func() (line 546 of src/control.c)

    Since these are fatal errors, the compiler stops here.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 15, 2014, 08:16:28 am
    I can't test this myself, but what happens if you do this:
    - Include screen.h
    - Replace line 519 "if(!SDL_GetWMInfo(&info)) {" with "if(!SDL_GetWindowWMInfo(sdlWindow, &info)) {"
    - Comment out line 526 and 547 (lock and unlock functions)
    - Comment out line 525 (wm_win = ...) and replace all wm_win with sdl_win

    Does this help?

    If it does not, go to screen.c, comment out line 188 (Control_ReparentWindow) and comment out that function from control.c. I don't think it is very important for now, because fullscreen does not work anyway.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on June 15, 2014, 02:09:28 pm
    Hello Andreas, You can post your sdl bugs to SDL Forums (http://forums.libsdl.org/index.php)
    At first Register and see This Post (http://forums.libsdl.org/viewtopic.php?t=9845)
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 15, 2014, 09:27:03 pm
    Thanks a lot, Andreas!! Yes, these changes allowed to build Previous.app with SDL2. I cannot confirm if the emulation is good because didn't try it yet, but the app starts and the GUI works.

    However, in order to be able to link it without errors, I had to apply the following change also to line 557 of src/control.c :
    Quote from: "andreas_g"- Replace line 519 "if(!SDL_GetWMInfo(&info)) {" with "if(!SDL_GetWindowWMInfo(sdlWindow, &info)) {"

    Otherwise, the linker complained there was no SDL_GetWMInfo symbol in SDL2, and a fatal error happened. With that change both on lines 519 and 557, the binary is successfully built.

    No idea however if this change in line 557 might have any negative consequences.

    Thanks a lot, Andreas!! Now I'll try to install NeXTSTEP 3.3 on it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 16, 2014, 09:10:59 pm
    Is it normal that the status bar says I'm emulating a 16MHz/68040/32MB/NeXTstation Color if I configured it as 25MHz? The rest of the GUI says it's 25MHz. I'm in the middle of a NS3.3 installation, so I cannot see now what NS thinks about the CPU. I'm using your SDL2 version if that matters...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 17, 2014, 05:25:46 am
    That is normal. There is only 16 and 32 MHz available from the emulated CPU core. But timings are not accurate anyway.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 17, 2014, 07:50:56 am
    Quote from: "andreas_g"That is normal. There is only 16 and 32 MHz available from the emulated CPU core. But timings are not accurate anyway.

    Oh, now I understand why it took so much to install NS 3.3 last night (the bottleneck was when the installer was copying small files, while large files were much faster to install --I assume the cause of this would be that either the CPU is used much more when creating a new file than when just writing to an already open file; or maybe there's some performance issue in the SCSI emulation, but I assume the former).

    Can't this generate problems with the emulator? I saw that the ROM Monitor reported the CPU as 20MHz. I wonder if either the ROM or NeXTSTEP could behave in an undesired way if they detect the CPU model isn't one of the officially supported ones...

    Is there some source file where I could add support for the NeXT-officially supported CPU frequencies?

    Also, I think there's some performance problem in the events input queue in the emulator (or in the screen refresh), because it's not normal that the mouse pointer is only updated at about 5 frames/sec or so... yes, I was running it at 16MHz, but even a Z80A at 3.5MHz could update a mouse pointer at 50 or 60 frames/sec in those days...

    I can't debug this issue now, but I believe I should be able to improve it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 17, 2014, 08:29:32 am
    ardi, your low speed is quite strange. Especially with the SDL2 version i am seeing quite good speed. Can you give me some data about your host system (hardware and operating system)?

    I'd be really happy if you could improve the timing system. CPU cycles are counted from newcpu.c, m68k_run_mmu0X0() and connected to the rest by m68000.h, M68000_AddCycles(). The speed setting is applied there using nCpuFreqShift (i think that part is totally wrong).

    More timings stuff is in cycles.c and cycInt.c and the SDL related part in main.c. I failed to understand how it works.

    Generally the emulated CPU should report how many virtual cycles have been used to execute some instruction. That number should then be used as a base for other timings (like screen refresh, device interrupts, etc) and some algorithm needs to sync it with real time.
    The resulting delays (if the host is fast enough) should be used to idle the emulator and save host CPU cycles. Ideally there should be a way to increase the emulation speed for example 2x, 4x, etc, but that has low priority.

    There is a scheduler for delayed events in cycInt.c. It needs to be possible to specify the delays in CPU cycles or microseconds.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 17, 2014, 08:53:22 am
    It's a Core2 Duo, with 4GB RAM, and 9600GT Geforce, running Mountain Lion 10.8 (that's the machine I used last night, it's a Hackintosh but it works fine).

    Today I can try it with a i3 iMac also running Mountain Lion.

    And I'll also try it with my Late-2010 Macbook Air, but I keep it at 10.6.8 so I need to recompile SDL and Previous at 10.6.x before trying it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 17, 2014, 09:24:42 am
    My system is from 2009. It is also a Core2Duo (2,66 GHz), running OS X v10.9 (Mavericks). So i don't think your system's speed is the problem.

    Maybe something (SDL or Previous) was compiled for debugging (no optimization). I recommend to use the pre-compiled SDL2 binaries from the homepage.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 17, 2014, 10:27:28 am
    Quote from: "andreas_g"My system is from 2009. It is also a Core2Duo (2,66 GHz), running OS X v10.9 (Mavericks). So i don't think your system's speed is the problem.

    Maybe something (SDL or Previous) was compiled for debugging (no optimization). I recommend to use the pre-compiled SDL2 binaries from the homepage.

    Ok, I'll check that, although I'm not sure if I'll have spare time today. If not today, it will be tomorrow.

    I'll also try to take a look at the source files you mentioned, in order to see if I can add support for the NeXT-officially supported CPU frequencies.

    Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 18, 2014, 10:48:02 am
    I think the issue might be caused because of the way I executed Previous the other day. I did it with 'open -a' from Terminal, and I'm afraid something got wrong in that way.

    Today I executed it again (without recompiling anything), but directly invoking the executable inside the bundle. And, to my surprise, I feel it's far more responsive. Also, the SDL2 version is faster than the SDL1.

    For example, booting time (pressing Ctrl+C ASAP on the network message) for NeXTSTEP 3.3 on a 16MHz (wanted to be 25) 68040 with 32MB RAM NeXTstation Color:
    -With SDL1, 2:15 minutes
    -With SDL2, 1:30 minutes

    Andreas, in addition to trying to improve the CPU timing, I'd like to know what are the known bugs about timers, and how could I debug them. Are they caused by unimplemented hardware, or is it just a problem related to the timings inaccuracies in the emulator?

    Other issues I found:
    -The F12 key doesn't invoke the GUI in the SDL2 version (however the F12 key hit is reported by the emulator --I'm running it from Terminal and so I'm seeing the detected key events).
    -For unlocking the mouse, I need to use Shift+Cmd+Alt+m on the SDL2 version. Is that right?
    -The mouse emulation seems a bit strange to me... it sometimes distorts the X/Y motion, depending on your linear/exponential settings... besides, I don't think such options should exist at all... just pass to the emulation the mouse motion without modifying it... otherwise there're two exponential modifications: one done by the host OS, another one done by the emulator on top of that, and perhaps even another one done by NeXTSTEP.

    Well, I'll try to enhance the CPU timings. Also, when you can, explain me about what happens with the "buggy timers" and how could I debug them.

    Thanks!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 18, 2014, 11:17:07 am
    I experienced the same speed improvements from SDL2. It seems to be more efficient on Mac OS X.

    For your issues:
    F12 worked for me after building a new configuration file from scratch. If you have saved your configuration from the old SDL version you need to delete it and save a new one using the SDL2 version (loading the old one and re-saving it won't work). The numeric values assigned to the keys have changed.
    Unlocking the mouse works for me with cmd+alt+m (no shift) but as a side effect it minimizes the window because of a shortcut conflict with the host system. I have not yet been able to fix that.
    The exponential adjustment in Previous is meant to reverse the host's mouse cursor acceleration and prevent "double acceleration" with the guest OS. I wanted to use raw mouse input, but did not find a way to get that from Mac OS X using SDL(2). So this is a workaround.


    For the buggy timers - there are two timers:

    First the event counter:
    It is a free 20-bit counter that gets incremented at 1 Mhz. The code for it is located in ioMemTabNEXT.c, System_Timer_Read(). It is adjusted with a hack, because obviously it did not count with correct speed. That might be a side effect of the broken timings system and/or a bad cycles value from some CPU instructions used for the power-on test.
    Furthermore it is incomplete in a way that a write to the event counter should set it to the defined value.

    Second the hardclock:
    It also counts at 1 MHz. It can be programmed to generate an interrupt after a defined value of time. The code for it is in sysReg.c. To make it work i had to pass the programmed delay value to the scheduler, which is a little bit strange. I would have guessed, that the delay (programmed in microseconds) has to be multiplied with the CPU clock to get the number of cycles for the scheduler. Most likely the scheduler, as a part of the broken timings system, is the problem.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 19, 2014, 08:34:47 am
    Thanks a lot. I'm at it, although not full time because I'm busy these days.

    Btw, is there any reason for keeping "unofficial" CPU speeds in the GUI? Why not just offer the "official" CPUs? ( 68030@25MHz, 68040@25MHz, and for Turbo 68040@33MHz, and Nitro 68040@40MHz ). I think it would be preferable to disable the 33MHz and 40MHz if the selected system isn't Turbo.

    I realize it must be interesting to test "rare/experimental" configurations, but I believe the GUI should be clear about what's an official NeXT configuration, and what's a "tweaked" one.

    Also, btw... what's missing for emulating the Turbo chipset? Are the technical details known for emulating it? And Nitro?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 19, 2014, 03:22:35 pm
    I just compiled the SDL2 version, and it is much, much faster.  Screen repaints are fine for me, but the app no longer grabs the keyboard/mouse.

    Slowing down the NeXT's mouse speed to the slowest, mouse is very useable now.  I would prefer that the app lock the keyboard and mouse, though, because that makes it easier to work with a VM like this, especially when the virtual mouse can't track the host mouse.

    Very nice work, Andreas.

    Updated to add another comment about the speed: on my 2.3 GHz Core i7 MacBook Pro running Mavericks, this feels just about as fast as NeXTSTEP x86 running in VMware on my iMac (Core i5 running Mavericks).  It no longer feels sluggish.  It feels normal.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 19, 2014, 04:51:23 pm
    ardi, the various CPU speeds are hidden in the custom preferences. If you want standard configurations, just select a system and it will use the defaults (it is auto-switching to 16 or 32 MHz because only powers of 2 are available because of nCpuFreqShift). But i'd also prefer to make CPU speed fixed to the standard value and add some 1x, 2x, 4x ... option.

    Turbo is quite different in some points. Especially the DMA controller is different, but also some of the chips on the board. It has low priority, as it won't bring very much benefits.


    eagle, i'm glad to hear it works so well! Mouse grabbing/locking should still work with the auto-lock option enabled. There are problems with the shortcut cmd+alt+m, because it minimizes the window and then the mouse won't be locked after maximizing. That is only caused by the shortcut conflict with the host.
    The keyboard can't be grabbed at the moment. I'm not sure why ... but if i could enable keyboard grab and stop shortcut forwarding the host OS that would also solve the above problem with the mouse lock.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 20, 2014, 09:52:13 am
    Quote from: "andreas_g"Turbo is quite different in some points. Especially the DMA controller is different, but also some of the chips on the board. It has low priority, as it won't bring very much benefits.

    I'm interested in it because 32MB is very little RAM. The only available options without Turbo are 32MB in color stations, or 64MB in monochrome cubes (because NeXTdimension isn't supported yet, so cubes are monochrome in Previous at this time).

    Being able to use the maximum size available for Turbos (128MB) would be very useful for me, because I'm going to use this for real work.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on June 20, 2014, 10:57:19 am
    Quote from: "ardi"because NeXTdimension isn't supported yet, so cubes are monochrome in Previous at this time


    The NeXTdimension is not going to be supported until its firmware is dumped I'm afraid.  The update package I found only flashes part of the rom, annoyingly...

     OG who just fixed the rendering in mess
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 20, 2014, 11:16:59 am
    Quote from: "galibert"The NeXTdimension is not going to be supported until its firmware is dumped I'm afraid.  The update package I found only flashes part of the rom, annoyingly...

    Is there any interesting stuff in that firmware? I ask this because in the NeXTdimension forum it was commented that NeXTSTEP uploaded the software to the ND board at boot time. If that's true, maybe a partial emulation could be achieved by just capturing the software being uploaded to the NeXTdimension at boot time.

    Quote from: "galibert"OG who just fixed the rendering in mess

    That's great!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 20, 2014, 12:33:58 pm
    Andreas, you're correct about the SDL2 and mouse locking.  I was seeing it not lock because Previous already thought it was locked.  When I pressed cmd-alt-m, Previous released what it thought was a lock on the mouse, and then I was able to lock it again by clicking in the window.  With NeXT mouse speed set to the minimum, the mouse is very useable now.  I will definitely not be complaining about its current operation.

    There are a few bugs with the SDL2 version, and you probably already know them all, but I thought I'd post what I'm seeing:
    - In the config editor, there are minor GUI bugs: In the file selector of the config GUI, mouse clicks don't always get recognized, so it can be difficult to make changes.
    - As you know, all meta key strokes are handled by the host OS and the NeXT.  It'll be nice when that one is corrected.  It isn't just OS X that processes the keystrokes: the NeXT gets them too.
    - I have seen the "root hang" several times in this version, where I hadn't seen it in a long time in the SDL1 builds.

    So far that's all I've noticed.

    It's so nice that the modifier keys work now: no more stuck keys!  I'll be able to use Interface Builder! :)

    Great work, Andreas!

    ---

    ardi: I know that NeXT Dimension support is on the wishlist, but I expect things like ethernet to come first, in particular because we already have working color.  You can see the status on the wiki page (http://bit.ly/1iPCcGd).
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on June 20, 2014, 12:42:15 pm
    Quote from: "ardi"
    Quote from: "galibert"The NeXTdimension is not going to be supported until its firmware is dumped I'm afraid.  The update package I found only flashes part of the rom, annoyingly...

    Is there any interesting stuff in that firmware? I ask this because in the NeXTdimension forum it was commented that NeXTSTEP uploaded the software to the ND board at boot time. If that's true, maybe a partial emulation could be achieved by just capturing the software being uploaded to the NeXTdimension at boot time.


    Dunno.  There's still 128K of stuff in there, including the reset vector...

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 20, 2014, 01:56:54 pm
    Quote from: "eagle"ardi: I know that NeXT Dimension support is on the wishlist, but I expect things like ethernet to come first, in particular because we already have working color.  You can see the status on the wiki page (http://bit.ly/1iPCcGd).

    I don't have high interest in NeXTdimension either (it would be very nice, but not a high priority for me). I mentioned it just because of RAM. Currently, if you want color, you're limited to 32 MB RAM, because Turbo isn't supported yet, and because the NeXTdimension isn't emulated yet (if it was you would be able to use 64 MB RAM on a Cube with color display).
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 20, 2014, 02:01:15 pm
    Sorry, when I said "NeXT Dimension," I meant "turbo."  Everybody wants to support more RAM.  Baby steps.  This is still a 0.5 release.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galibert on June 22, 2014, 09:13:46 am
    Quote from: "eagle"I know that NeXT Dimension support is on the wishlist, but I expect things like ethernet to come first


    Note that the ethernet part is not particularly hard, and works in mess.  The real problems is interfacing with the host OS, and the fact that that nextstep uses obsolete parts of the IP protocols...

     OG.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 22, 2014, 12:54:12 pm
    Quote from: "galibert"Note that the ethernet part is not particularly hard, and works in mess.  The real problems is interfacing with the host OS, and the fact that that nextstep uses obsolete parts of the IP protocols...

    I wish I knew more about it.  I have zero understanding how emulators actually work, and that's especially true for the networking part.

    I know it has to be possible: many other emulators and virtualization solutions provide network access.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 23, 2014, 07:36:16 am
    Quote from: "eagle"There are a few bugs with the SDL2 version, and you probably already know them all, but I thought I'd post what I'm seeing:
    - In the config editor, there are minor GUI bugs: In the file selector of the config GUI, mouse clicks don't always get recognized, so it can be difficult to make changes.
    - As you know, all meta key strokes are handled by the host OS and the NeXT.  It'll be nice when that one is corrected.  It isn't just OS X that processes the keystrokes: the NeXT gets them too.
    - I have seen the "root hang" several times in this version, where I hadn't seen it in a long time in the SDL1 builds.

    Can you describe the problem with unrecognized mouse clicks a little more closely? I didn't see that one yet. The problem with shortcuts is known.

    The "root on hang" is not related to SDL. So i don't expect this to disappear, although i didn't see it for some time. It is most likely some weird timing issue. The faster speeds with SDL2 might have an effect on that and therefore you get the hang in different circumstances. That might point to the RTC as a source of the problem, because it ticks at constant rates independently from the emulators speed. I'll have to check if there is any RTC access around the point the hang occurs.

    galibert, do you plan to work on Previous? Some help would be great. Your ECC code works just fine.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on June 24, 2014, 11:49:27 am
    Quote from: "galibert"
    Quote from: "eagle"I know that NeXT Dimension support is on the wishlist, but I expect things like ethernet to come first


    Note that the ethernet part is not particularly hard, and works in mess.  The real problems is interfacing with the host OS, and the fact that that nextstep uses obsolete parts of the IP protocols...

     OG.

    I don't need Ethernet, except for getting shared folders with the host system, via NFS. Has anybody tried to get shared folders in mess with NFS? (IMHO an emulator without shared folders can be a toy or even a cool thing, or a museum interest, but if you want to do anything real with it, you really need shared folders).
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 28, 2014, 01:47:33 pm
    Good news:
    Finally i was able to fix a long standing bug that caused disk images to get corrupted under NeXTstep 3.0 and later using 68030. It turned out to be a mistake im my 68030 MMU code.

    ardi, are you actively working on the timings? I'd be interested in that for Previous 0.5.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on June 29, 2014, 01:38:05 pm
    It's been a while since I updated Previous so earlier I grabbed the latest source and compiled it.

    Initially I tried it on my Yosemite machine but it failed to compile (ld: symbol(s) not found for architecture x86_64). I still have Xcode 5.1.1 installed with the command-line tools for Yosemite so maybe that's the cause.

    Update: It was. Compiled fine with Xcode 6.

    On my Snow Leopard machine it compiled fine but won't launch. It doesn't crash, it just flashes up in the dock and then closes. The console shows "Error: Unrecognized option (-psn_0_110619)". The number varies each launch.

    If I browse into the application bundle and double-click the binary it launches fine. Where is it getting this switch from?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 29, 2014, 04:33:53 pm
    Quote from: "protocol7"On my Snow Leopard machine it compiled fine but won't launch. It doesn't crash, it just flashes up in the dock and then closes. The console shows "Error: Unrecognized option (-psn_0_110619)". The number varies each launch.

    I had the same problem a few times. It seems to be somehow related to compiling. If i made a new Xcode project it worked fine afterwards. Cleaning, etc didn't help.

    Alternatively you can disable in main.c, lines 710 to 713 (if (!Opt_...). That code was never adopted for Previous anyway, so it is useless for now.
    Title: What Needs to be done for a NeXT Emulator
    Post by: protocol7 on June 29, 2014, 06:19:45 pm
    Thanks andreas.

    I don't compile it inside Xcode (just ./configure, make, make install from terminal) but commenting out those lines fixed it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 01, 2014, 09:16:54 pm
    Quote from: "andreas_g"Good news:
    Finally i was able to fix a long standing bug that caused disk images to get corrupted under NeXTstep 3.0 and later using 68030. It turned out to be a mistake im my 68030 MMU code.

    ardi, are you actively working on the timings? I'd be interested in that for Previous 0.5.

    That's great news, Andreas!! Regarding my work on timings, I had to pause it because I've had an oversaturation of work in my job these weeks. I hope to be able to resume studying the previous timings soon, as soon as things go back to normal in my job.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 06, 2014, 12:50:14 pm
    Quote from: "andreas_g"
    Quote from: "eagle"There are a few bugs with the SDL2 version, and you probably already know them all, but I thought I'd post what I'm seeing:
    - In the config editor, there are minor GUI bugs: In the file selector of the config GUI, mouse clicks don't always get recognized, so it can be difficult to make changes.
    - As you know, all meta key strokes are handled by the host OS and the NeXT.  It'll be nice when that one is corrected.  It isn't just OS X that processes the keystrokes: the NeXT gets them too.
    - I have seen the "root hang" several times in this version, where I hadn't seen it in a long time in the SDL1 builds.

    Can you describe the problem with unrecognized mouse clicks a little more closely? I didn't see that one yet. The problem with shortcuts is known.


    Hi andreas.  Sorry for the long delay.  I was seeing sticky buttons in the GUI: they acted like toggles instead of buttons.  I'm not seeing that in the latest build, though.  I'll let you know if I see it again.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on July 11, 2014, 11:33:50 am
    I get error when compiling shortcut.o-
    [ 92%] Building C object src/CMakeFiles/Previous.dir/shortcut.c.o
    /home/Mominul/branch_mmu/src/shortcut.c: In function 'ShortCut_CheckKeys':
    /home/Mominul/branch_mmu/src/shortcut.c:325:26: error: 'KMOD_LMETA' undeclared (first use in this function)
     if (modkey & (KMOD_RALT|KMOD_LMETA|KMOD_RMETA|KMOD_MODE))
                             ^
    /home/Mominul/branch_mmu/src/shortcut.c:325:26: note: each undeclared identifier is reported only once for each function it appears in
    /home/Mominul/branch_mmu/src/shortcut.c:325:37: error: 'KMOD_RMETA' undeclared (first use in this function)
     if (modkey & (KMOD_RALT|KMOD_LMETA|KMOD_RMETA|KMOD_MODE))
                                        ^
    /home/Mominul/branch_mmu/src/shortcut.c: At top level:
    /home/Mominul/branch_mmu/src/shortcut.c:80:13: warning: 'ShortCut_RecordSound' defined but not used [-Wunused-function]
    static void ShortCut_RecordSound(void)
                ^
    /home/Mominul/branch_mmu/src/shortcut.c:165:13: warning: 'ShortCut_InsertDisk' defined but not used [-Wunused-function]
    static void ShortCut_InsertDisk(int drive)
                ^
    src/CMakeFiles/Previous.dir/build.make:816: recipe for target 'src/CMakeFiles/Previous.dir/shortcut.c.o' failed
    make[2]: *** [src/CMakeFiles/Previous.dir/shortcut.c.o] Error 1
    CMakeFiles/Makefile2:119: recipe for target 'src/CMakeFiles/Previous.dir/all' failed
    make[1]: *** [src/CMakeFiles/Previous.dir/all] Error 2
    Makefile:116: recipe for target 'all' failed
    make: *** [all] Error 2
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 11, 2014, 04:19:03 pm
    Mominul, that bug is fixed now. Just forgot to update for SDL2.

    For all:
    I decided to release Previous v0.5 now, because it contains an important bugfix.

    Short release notes:
    - Fixed 68030 MMU bug that caused disk image corruption.
    - Added full emulation of the magneto-optical disk drive (only single drive supported). An empty disk image is included.
    - Updated to SDL2.


    You can load the Mac OS X version here (should run on v10.5 and later): Previous v0.5 for Mac OS X (https://dl.dropboxusercontent.com/u/44703754/Previous_0.5a.zip)

    It would be great if someone could compile and release for other platforms. Previous 0.5 is r381 in the SVN repository.


    Update: Added binary from fixed revision v380.
    Update2: Added another fixed revision v381.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 11, 2014, 04:59:44 pm
    I noticed something interesting today: my mouse pointer does not go straight up and down in Previous 0.5.  I don't know if this happened before, but it's definitely an issue in 0.5/build 379.

    I was unsure of whether I simply wasn't using the mouse very well, so I tested it specifically.  My test was this: place mouse against wall/book -- something flat and straight and taller than the mouse.  Move mouse up and back along wall.  Note that the pointer in Previous gradually slides to the right.

    If I do exactly the same test (up-and-back against a wall) on OS X, the mouse pointer goes straight up and down.

    If it matters, I downloaded the code from subversion and built my own copy.  Also, I am running on Mavericks, 10.9.3.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 11, 2014, 06:07:58 pm
    eagle, good find!

    I was able to find and fix the bug fast. I updated the above binary.
    It was just bad handling of 0 pixel mouse moves. It moved -1 instead, which means 1 pixel to the right or 1 pixel down.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on July 12, 2014, 08:35:21 am
    I get the last error when compiling Previous on cygwin -
    Linking C executable Previous.exe
    /usr/lib/gcc/i686-pc-cygwin/4.8.3/../../../libcygwin.a(libcmain.o): In function `main':
    /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/lib/libcmain.c:39: undefined reference to `WinMain@16'
    collect2: error: ld returned 1 exit status
    src/CMakeFiles/Previous.dir/build.make:1095: recipe for target 'src/Previous.exe' failed
    make[2]: *** [src/Previous.exe] Error 1
    CMakeFiles/Makefile2:119: recipe for target 'src/CMakeFiles/Previous.dir/all' failed
    make[1]: *** [src/CMakeFiles/Previous.dir/all] Error 2
    Makefile:116: recipe for target 'all' failed
    make: *** [all] Error 2
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 13, 2014, 08:02:18 am
    Mominul, i'm not sure how to fix that. You can try to change SDLMAIN_LIBRARY in src/CMakeLists.txt lines 95 to 97 to SDL2MAIN_LIBRARY.

    Else please search the internet for solutions. The problem is Windows specific. I can't test and see if it works. If you search the internet for "undefined reference to `WinMain@16'" and "SDL" you'll get lots of results.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on July 13, 2014, 10:13:55 am
    Hi Andreas,

    Just tried previous 0.5, it do not launch whith a double click,  on my MacBook, with only this message in system.log:

    Jul 13 12:12:23 macbookpro com.apple.launchd.peruser.501[201] ([0x0-0x343343].com.sourceforge.previous[5472]): Exited with code: 1

    But it launch when launched from ommand line...
    ./Previous.app/Contents/MacOS/Previous
    ...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 13, 2014, 02:58:13 pm
    jvernet, bug is hopefully fixed in the latest revision. I replaced the binary in my original post for 0.5. Please test and report back.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on July 14, 2014, 11:26:05 am
    Quote from: "andreas_g"jvernet, bug is hopefully fixed in the latest revision. I replaced the binary in my original post for 0.5. Please test and report back.


    Hi Andreas,
    I too have a problem with that version. Doesn't want to launch, even from cmd line. I get this error :
    Dyld Error Message:
     Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2
     Referenced from: /Applications/Apps Diverses/*/Previous.app/Contents/MacOS/Previous
     Reason: image not found
    Trace/BPT trap: 5
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on July 14, 2014, 12:32:53 pm
    SDL2 is giving us much more headache! :evil:
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 14, 2014, 04:32:54 pm
    Quote from: "galgot"Hi Andreas,
    I too have a problem with that version. Doesn't want to launch, even from cmd line. I get this error :
    Dyld Error Message:
     Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2
     Referenced from: /Applications/Apps Diverses/*/Previous.app/Contents/MacOS/Previous
     Reason: image not found
    Trace/BPT trap: 5


    oops, forgot to add SDL to the latest application bundle. It's fixed now. Just re-download. The application in absolutely identical, but now SDL is called from within the bundle so you don't have to install it to your Frameworks folder.
    Title: What Needs to be done for a NeXT Emulator
    Post by: galgot on July 14, 2014, 06:12:29 pm
    Runs fine now . thanks !
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on July 16, 2014, 09:20:47 am
    OK, updated the information of the Wikipedia page (https://en.wikipedia.org/wiki/Previous_(emulator)) to the latest Release v0.5 of Previous.

    Unfortunately almost all screenshots that I uploaded was deleted by an user rampaging the page and are not available anymore. Can you add some screenshots of the release v0.4 and v0.5 to the Wikipedia page, please ? Thank you !
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on July 16, 2014, 10:33:11 am
    I have also updated my com-emu page.  Kitchen2010 you can have the screenshots from here - http://com-emu.meximas.com/doku.php?id=previous .
    Title: What Needs to be done for a NeXT Emulator
    Post by: jvernet on July 19, 2014, 09:17:02 pm
    Got it running, but wasn't able to make it boot anything.... No one of my disk image (ISO) seems to be usable with Previous.
    I lost an image Gilles send me a while back....
    Title: 2 q´s
    Post by: hUMUNGUs on August 09, 2014, 03:02:01 pm
    1. Previous 0.5 crashes on startup on my OS X. Yosemite b1 setup.
    2. Could someone point my to the NeXT roms ? without donating to TheOldComputer !

    - love the fact that a NeXT emulator is out there. Thanks guys !
    Title: Re: 2 q´s
    Post by: eagle on August 09, 2014, 03:04:00 pm
    Quote from: "hUMUNGUs"1. Previous 0.5 crashes on startup on my OS X. Yosemite b1 setup.


    My Mavericks build of Previous 0.5 didn't work on Yosemite, but I was able to compile Previous on Yosemite, and it works fine.
    Title: What Needs to be done for a NeXT Emulator
    Post by: hUMUNGUs on August 09, 2014, 03:05:39 pm
    Awesome, any way i could get a binary ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on August 28, 2014, 01:38:49 pm
    Hi, sorry for the late reply.  I have uploaded a copy of my current Previous SDL2 build here:

    https://dl.dropboxusercontent.com/u/13208710/Previous-0.5-SDL2-Yosemite.tgz

    You will of course need a copy of the SDL2 library.

    This build only runs on Yosemite.  I am using it on my copy of the Public Beta release 2.

    andreas: have you made any progress on Previous in the last month or two?  I'm hoping to have ethernet sometime soon, because that opens up an entirely new world. :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on August 29, 2014, 06:22:44 am
    Quote from: "eagle"andreas: have you made any progress on Previous in the last month or two?


    Hello eagle and all others,

    i have stopped my work on Previous during the last month. It is unlikely that i will continue development in the future. I'm sorry for the bad news. I hope someone else will pick up the project and complete it. I'd be happy to assist with informations.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on August 29, 2014, 08:43:52 am
    I am very sorry to hear about that ! :(
    The Previous emulator made huge advances the last 12 months up to an almost usable state (MMU, MO-drive, ...).

    May I ask you for the reason (time, job issues, private reasons, etc. ...) ? Perhaps you can still develop on it at a slower speed ?

    How many programmers are in total working on this project besides you ? Will they able to pick up the work from where you stopped ?

    Maybe we should put up a wiki on the dev website to collect the dev information on one place to encourage other programmers to join the project.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on August 29, 2014, 12:52:47 pm
    Andreas, I'm saddened to hear that, but I understand.   I also want to publicly thank you for all of your work on the project.  The NeXT emulator made tremendous advances over the last year, thanks to you and some others.  I really appreciate all that you have done.

    ---

    Hopefully someone who understands networking emulation can work on that part of it, because with that we have an extremely useful, very functional emulator.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on August 29, 2014, 01:04:41 pm
    The main reasons are time and motivation. To make any further progress i'd need to first learn quite a lot of theory. Especially for implementing networking i'd need to learn how to implement Slirp and how to do cross platform thread programming. Also i'd need to learn more about SDL2 and understand more of Hatari's code, CPU timings, etc.

    All this is too much for one single person, especially because i'm not a professional programmer but only a hobbyist. At this point i can only make very little improvements with a lot of efforts. The cost-value ratio has become too low to keep motivation up. I have already used thousands (!) of hours of my free time for Previous.

    Unfortunately i am the only programmer working on the project. But i hope someone can continue where i stopped. There is lots of potential in this emulator.
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on September 09, 2014, 02:48:27 pm
    Thanks for the great work you have done so far.

    You obviously must have functionally reverse engineered quite a bit of the hardware, outside the m68k CPU.

    Is what you have discovered documented anywhere in a single place? And what else must be reverse engineered / what information we have missing?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on September 11, 2014, 07:48:20 am
    Most functionality of the hardware is known. There are data sheets available for all 3rd party chips.
    The custom NeXT chips have been reversed for the most part. But there are some open questions about the MO drive controller and the DMA controller.
    Also i didn't work on sound. There seems to be not much information available about the soundbox.

    Unfortunately there is no documentation about the custom chips available online.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on September 14, 2014, 05:10:32 am
    slirp is very easy to interface to.. I mashed it together with SIMH, and it was pretty trivial.. If you can get the ethernet to point to sending a frame, and receiving a frame it's VERY easy to get going.. you don't even have to mess with threads either.

    I know SDL is a bear, I only played with it in the realm of SDLQuake, in some cheap way to get Quake running on WindowsNT MIPS..
    Title: I hope you don't mind, but I borrowed your SCSI
    Post by: neozeed on October 13, 2014, 01:09:49 pm
    disk emulation.



    I think I spent the most time trying to figure out Basilisk II's SCSI bridge thing, and the Mac's insane desire to set up 256kb scatter/gather groups.

    But your code works great once I have the right bits working.

    :lol:
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 31, 2014, 10:59:08 am
    Quote from: "andreas_g"The main reasons are time and motivation. To make any further progress i'd need to first learn quite a lot of theory. Especially for implementing networking i'd need to learn how to implement Slirp and how to do cross platform thread programming. Also i'd need to learn more about SDL2 and understand more of Hatari's code, CPU timings, etc.

    All this is too much for one single person, especially because i'm not a professional programmer but only a hobbyist. At this point i can only make very little improvements with a lot of efforts. The cost-value ratio has become too low to keep motivation up. I have already used thousands (!) of hours of my free time for Previous.

    Unfortunately i am the only programmer working on the project. But i hope someone can continue where i stopped. There is lots of potential in this emulator.

    Oh, how sad! I fully understand the difficulties. I'm not contributing just because of time, I've no time, so I fully understand you. However, I disagree with the lack of motivation, as I believe I'm not the only one interested in a complete NeXT emulator.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ominimicu on December 17, 2014, 03:13:55 am
    Quote from: "Mominul"I have also updated my com-emu page.  Kitchen2010 you can have the screenshots from here - http://com-emu.meximas.com/doku.php?id=previous .

    just thinking of update mine, thanks for the Info. :lol:






    htc one m8 schutzhülle (http://www.nextcomputers.org/forums)
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 26, 2015, 03:41:06 pm
    Quote from: "ominimicu"
    Quote from: "Mominul"I have also updated my com-emu page.  Kitchen2010 you can have the screenshots from here - http://com-emu.meximas.com/doku.php?id=previous .

    just thinking of update mine, thanks for the Info. :lol:

    That page still lists Previous as an active project. Is it? (I'd hope so)
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on January 26, 2015, 03:48:59 pm
    As far as I know, nobody has done anything with it since andreas_g halted his work. :(
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on January 27, 2015, 08:13:13 am
    it's a matter of sorrow that Previous are getting discontinuted :( I will thank andreas_g, because of he we are getting the mostly workable emulator. He has given  all of his free time to Previous, hat's off to you andreas_g! But I will request andreas_g to continue work on Previous. He can work slowly but please don't discontinue the work on Previous.

    But where are Gilles?
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 27, 2015, 02:07:14 pm
    Quote from: "Mominul"it's a matter of sorrow that Previous are getting discontinuted :( I will thank andreas_g, because of he we are getting the mostly workable emulator. He has given  all of his free time to Previous, hat's off to you andreas_g! But I will request andreas_g to continue work on Previous. He can work slowly but please don't discontinue the work on Previous.

    But where are Gilles?

    Indeed. A fully working emulator of a M68K-based machine would be very useful for my work.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on March 03, 2015, 04:25:42 pm
    Oh, man, how I'd wish to have some spare time for helping develop Previous :( Unfortunately I just have time for using NeXT, not helping write an emulator   :(  I really hope somebody continues this project, the most difficult part is already done IMHO
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on March 08, 2015, 01:32:08 pm
    Hello all,
    I do not have much time for emulators now because most of my coding time is used for my OSS/BSS freelance activity (the other part of my time is for my numerous family ;) ).
    But I can at least maintain/clean the code and make urgent updates.
    Unfortunatly this forum did not sent me notifications for a while... I'm here today because I saw many hits to previous.alternative-system.com (I'm now tidying a bit my websites). so I forgot the emulator a bit...

    [edit]
    win32 build for 0.5 is on the website. cross compile is still ok with SDL2 (but it was a bit tricky to install libs).
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on March 12, 2015, 04:28:46 pm
    @gilles here is a patch mouse-lock-win.patch (https://www.dropbox.com/s/jwas03tg6algu9m/mouse-lock-win.patch?dl=1)  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on March 13, 2015, 05:09:09 pm
    What types of floppy all Next computers use? A list is needed 8)
    Exa:
    1. 0.16
    2. 0.18
    3. 0.32
    4. 0.36
    5. 0.72
    6. 1.2
    7. 1.44
    8. 1.68
    9. 1.72
    10. 2.88
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on March 13, 2015, 07:21:20 pm
    As far as I know, all NeXTs used 2.88 MB floppies
    Title: What Needs to be done for a NeXT Emulator
    Post by: barcher174 on March 13, 2015, 07:56:02 pm
    Quote from: "eagle"As far as I know, all NeXTs used 2.88 MB floppies


    That is correct. And they can read 720K, 1.44mb and 2.88mb disks.

    --
    Brian
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on March 14, 2015, 07:14:42 am
    Thanks eagle & barcher174. It will help me a lot :)
    Now I need information about mo images. What types(size) of image mo drive use?
    I will look on the program that andreas has made to copy a mo disk..

    Update: Previous is super slow on ubuntu. Installation of nextstep took 1 - 2 hours. And all things are slow than ever :x
    Title: What Needs to be done for a NeXT Emulator
    Post by: barcher174 on March 14, 2015, 10:00:30 am
    MO disks are 256MB, 512K block size.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 02, 2015, 07:38:43 am
    Hello all,

    out of curiosity i tested the rev 0.8 v31 ROM with Previous. Unfortunately i ran into a problem. There is an unexpected bus error during the boot process. To find the problem, i'd need a little information from real hardware. Maybe someone can test this for me, preferably using a 68030 Cube:

    Go to ROM monitor and try to access physical address 0xAAAAAAAE with this command:
    e aaaaaaae
    What does it return? If a bus error occurs you will get an error message. Please note it.
    If there is no bus error you'll see something like
    aaaaaaae: 00000000?
    You can stop by simply typing ".".
    Title: What Needs to be done for a NeXT Emulator
    Post by: barcher174 on April 02, 2015, 10:08:18 pm
    Do you have a preference on which ROM version this is done with?
    Title: What Needs to be done for a NeXT Emulator
    Post by: barcher174 on April 03, 2015, 05:30:57 am
    Using ROM 1.0v41 I get:

    Exception #2 (0x8 ) at 0x2c4
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 03, 2015, 07:19:38 am
    Thank you! So it doesn't say "bogus stack frame".
    I'll update the code to make the prototype ROM work.

    Update:
    I made a new release version 0.5.1 with the recent fixes. You can load the binary for Mac OS X 10.6 and later here (removed).

    Update 2:
    I found some more bugs. You can load the patched version 0.5.2 here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.5.2b.zip).
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 04, 2015, 08:20:30 am
    Hello all,

    i'll have some time during the next weeks. If someone can help me, i might be able to add networking capabilities to Previous.

    Unfortunately i have no experiences with networking stuff. I'd need someone to add an interface for sending and receiving packets (slirp?).
    It needs to be cross-platform compatible (Mac OS X, Linux, Windows, other UNIX-like).
    I can help with adding the sources to the project (using cmake).

    If someone can provide the functions for sending and receiving packets, it shoud not be too hard for me to connect to the emulated hardware.

    Anyone interested?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 04, 2015, 05:14:30 pm
    @andreas_g I have hacked bximage and made it to work with Previous. It will create 'flat' hd or fd image. I was working to integrate it with Previous. But I need to write a dialog (hack dlgNewDisk.c) but I need some more time (may be fail ;) ) so if you hack the dialog and integrate with Previous, so I can work with it. Here it is createBlankimage.tar.gz (https://www.dropbox.com/s/qjafde37u146mqw/createBlankimage.tar.gz?dl=1)

    About slirp , neozeed has recently added slirp in Shoebill. It can be a to help us. We will take a look.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 06, 2015, 07:04:06 am
    Thank you for that. I think it might be easier to add some pre-built empty images to Previous, like i did for the MO disk. It would make sense to choose size of the HDDs that were bundled with original NeXT machines.

    But for now absolute priority is on networking. I do not have very much time and need someone's help to get started with this (see above post).
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 06, 2015, 11:59:40 am
    Andreas, I'm excited to see that you have some time to work on Previous again, and agree that networking is the next important item.  Hopefully someone else knows how to do it; I have no idea, or I would offer to help.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on April 06, 2015, 10:15:47 pm
    Quote from: "andreas_g"Hello all,

    i'll have some time during the next weeks. If someone can help me, i might be able to add networking capabilities to Previous.

    Unfortunately i have no experiences with networking stuff. I'd need someone to add an interface for sending and receiving packets (slirp?).
    It needs to be cross-platform compatible (Mac OS X, Linux, Windows, other UNIX-like).
    I can help with adding the sources to the project (using cmake).

    If someone can provide the functions for sending and receiving packets, it shoud not be too hard for me to connect to the emulated hardware.

    Anyone interested?


    I can't claim any knowledge or experience in this area at all; but what springs to mind is the "tap" network interfaces that are available on most modern OSes (Windows, Linux, Mac OS X), see for instance http://en.wikipedia.org/wiki/TUN/TAP and http://tuntaposx.sourceforge.net/.

    // Christian
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 07, 2015, 08:40:46 am
    ive built some tuntap stuff for windows and.... its really tedious.  But slirp, yeah i can do that.

    Ive hacked it into simh, and basilisk ii.

    So sure, i can help.

    Does previous build with vc?  I find it way easier to debug when things go wrong...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 07, 2015, 09:20:19 am
    It does not work with MSVC by default, but I have a custom built MSVC project of an older version of Previous around somewhere. Maybe that can be updated. I'll try to find it later today.

    Thank you very much for your offer!
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 07, 2015, 09:31:08 am
    Quote from: "andreas_g"It does not work with MSVC by default, but I have a custom built MSVC project of an older version of Previous around somewhere. Maybe that can be updated. I'll try to find it later today.

    Thank you very much for your offer!


    No problem, the least i can do for borrowing your SCSI!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 07, 2015, 06:09:41 pm
    I found the project and tried to update to the latest sources. There were many conflicts and some new files and some to remove. I only changed the source files but not the project because i have no MSVC or Windows system running.
    I think it won't work out of the box, but maybe with some minor adaptions. The file is here (https://dl.dropboxusercontent.com/u/44703754/msvc/previous%20msvc%20project.zip).

    Alternatively i added a diff with the changes made for MSVC (but most of the changes are obviously just coding style corrections). Maybe it is easier to add these to the latest sources. The diff is here (https://dl.dropboxusercontent.com/u/44703754/msvc/msvc.diff).

    Last but not least the original and working project for MSVC is here (https://dl.dropboxusercontent.com/u/44703754/msvc/VisualStudioProjectVersion.zip) (maybe useful too). It was made from revision 281 of Previous.

    I hope this helps!


    Update: Tried to strip all coding style stuff from the diff. This makes it more readable. Here (https://dl.dropboxusercontent.com/u/44703754/msvc/msvc%20clean.diff) is the cleaned version.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 11, 2015, 02:02:10 pm


    I need to fix a *LOT* more.. about all it can do is ping... but it's doing something!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 11, 2015, 02:49:21 pm
    This is a huge progress! So you already succesfully connected to the DMA channels?
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 11, 2015, 03:44:31 pm
    Is there a way to force compiling a 32bit version in OS X?

    Cmake tries to make everything too nice, and hides 99.99999999% of the build process so I'm lost on trying to do anything custom build wise here.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 11, 2015, 03:47:19 pm
    Quote from: "andreas_g"This is a huge progress! So you already succesfully connected to the DMA channels?


    Well ICMP works.. but when I run the slirp polling for TCP I crash every time there is TCP data.  I've only built 32bit, so I really don't know if it works in 64bit builds..

    So far my changes are relatively minor.  

    --- ethernet.c 2015-04-11 23:42:55.000000000 +0800
    +++ orig/previous-code-391-trunk/src/ethernet.c 2014-06-20 15:45:30.000000000 +0800
    @@ -17,111 +17,6 @@
    #include "cycInt.h"
    #include "statusbar.h"

    -/****************/
    -
    -//SLIRP stuff
    -#include <arpa/inet.h>
    -struct queuepacket{
    -    int len;
    -    unsigned char data[2000];
    -};
    -
    -//slirp prototypes
    -extern  int slirp_init(void);
    -int slirp_redir(int is_udp, int host_port, struct in_addr guest_addr, int guest_port);
    -extern  void slirp_input(const uint8_t *pkt, int pkt_len);
    -extern  int slirp_select_fill(int *pnfds,
    -                                 fd_set *readfds, fd_set *writefds, fd_set *xfds);
    -extern  void slirp_select_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds);
    -extern  void slirp_exit(int);
    -void slirp_debug_init(char*,int);
    -extern  void slirp_output(const unsigned char *pkt, int pkt_len);
    -extern  int slirp_can_output(void);
    -//queue stuff
    -typedef struct queuepacket *queueElementT;
    -typedef struct queueCDT *queueADT;
    -extern  queueADT QueueCreate(void);
    -extern  void QueueDestroy(queueADT queue);
    -extern  void QueueEnter(queueADT queue, queueElementT element);
    -extern  queueElementT QueueDelete(queueADT queue);
    -extern  int QueueIsEmpty(queueADT queue);
    -extern  int QueueIsFull(queueADT queue);
    -extern  int QueuePeek(queueADT queue);
    -
    -
    -int slirp_inited;
    -queueADT slirpq;
    -static SDL_mutex *slirp_mutex = NULL;
    -
    -//Is slirp initalized?
    -//Is set to true from the init, and false on ethernet disconnect
    -int slirp_can_output(void)
    -{
    -    return slirp_inited;
    -}
    -
    -//This is a callback function for SLiRP that sends a packet
    -//to the calling library.  In this case I stuff
    -//it in q queue
    -void slirp_output (const unsigned char *pkt, int pkt_len)
    -{
    -    struct queuepacket *p;
    -    p=(struct queuepacket *)malloc(sizeof(struct queuepacket));
    -    SDL_LockMutex(slirp_mutex);
    -    p->len=pkt_len;
    -    memcpy(p->data,pkt,pkt_len);
    -    SDL_UnlockMutex(slirp_mutex);
    -    QueueEnter(slirpq,p);
    -    Log_Printf(LOG_WARN, "SLiRP slirp_output a %d",pkt_len);
    -}
    -
    -int jkl=0;
    -
    -//This function is to be periodically called
    -//to keep the internal packet state flowing.
    -void slirp_tick(void){
    -    int ret2,nfds;
    -    struct timeval tv;
    -    fd_set rfds, wfds, xfds;
    -    int timeout;
    -    nfds=-1;
    -    
    -    Log_Printf(LOG_WARN, "SLiRP Tick()");
    -
    -    if(slirp_inited)
    -    {
    -        FD_ZERO(&rfds);
    -        FD_ZERO(&wfds);
    -        FD_ZERO(&xfds);
    -        timeout=slirp_select_fill(&nfds,&rfds,&wfds,&xfds); //this can crash
    -        
    -        if(timeout<0)
    -            timeout=500;
    -        tv.tv_sec=0;
    -        tv.tv_usec = timeout;    //basilisk default 10000
    -        
    -        ret2 = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
    -        if(ret2>=0){
    -            jkl++;
    -            if(jkl>0){
    -            SDL_LockMutex(slirp_mutex);
    -            slirp_select_poll(&rfds, &wfds, &xfds);
    -            SDL_UnlockMutex(slirp_mutex);
    -                jkl=0;
    -            }
    -        }
    -    }//end if slirp inited
    -}
    -
    -static int tick_func(void *arg)
    -{
    -    for(;;)
    -    {
    -    SDL_Delay(5000);
    -        slirp_tick();
    -    }
    -    return 0;
    -}
    #define LOG_EN_LEVEL        LOG_WARN
    #define LOG_EN_REG_LEVEL    LOG_WARN
    #define LOG_EN_DATA 0
    @@ -477,7 +372,7 @@

    void ENET_IO_Handler(void) {
        CycInt_AcknowledgeInterrupt();
    -
    +    
        if (enet.reset&EN_RESET) {
            Log_Printf(LOG_WARN, "Stopping Ethernet Transmitter/Receiver");
            enet_stopped=true;
    @@ -498,27 +393,6 @@
                    receiver_state = RECV_STATE_RECEIVING;
                    /* Fall through to receiving state */
                } else
    -                if(QueuePeek(slirpq)>0)
    -                    {
    -                        ssize_t length;
    -                        struct queuepacket *qp;
    -                        SDL_LockMutex(slirp_mutex);
    -                        qp=QueueDelete(slirpq);
    -                        enet_rx_buffer.size=qp->len;
    -                        memcpy(enet_rx_buffer.data,qp->data,qp->len);
    -                        SDL_UnlockMutex(slirp_mutex);
    -                        Log_Printf(LOG_EN_LEVEL, "[EN] Slirp deQueing %d bytes, %d more packets",qp->len,QueuePeek(slirpq));
    -                        Log_Printf(LOG_EN_LEVEL, "[EN] Slirp Receiving packet to %02X:%02X:%02X:%02X:%02X:%02X",
    -                                   enet_rx_buffer.data[0], enet_rx_buffer.data[1], enet_rx_buffer.data[2],
    -                                   enet_rx_buffer.data[3], enet_rx_buffer.data[5], enet_rx_buffer.data[5]);
    -                        print_buf(enet_rx_buffer.data, enet_rx_buffer.size);
    -                        enet_rx_buffer.size+=4;
    -                        if(enet_rx_buffer.size<ENET_FRAMESIZE_MIN)
    -                            enet_rx_buffer.size=ENET_FRAMESIZE_MIN;
    -                        enet_rx_buffer.limit=enet_rx_buffer.size;
    -                        receiver_state = RECV_STATE_RECEIVING;
    -                    
    -                    }
                    break;
            case RECV_STATE_RECEIVING:
                Statusbar_BlinkLed(DEVICE_LED_ENET);
    @@ -559,12 +433,6 @@
                print_buf(enet_tx_buffer.data, enet_tx_buffer.size);
                if (enet.tx_mode&TXMODE_DIS_LOOP) {
                    /* TODO: Send to real network! */
    -                if(slirp_inited)
    -                {
    -                    SDL_LockMutex(slirp_mutex);
    -                    slirp_input(enet_tx_buffer.data,enet_tx_buffer.size);
    -                    SDL_UnlockMutex(slirp_mutex);
    -                }
                    enet_tx_buffer.size=0;
                } else {
                    /* Loop back */
    @@ -586,29 +454,13 @@
            Log_Printf(LOG_WARN, "Starting Ethernet Transmitter/Receiver");
            enet_stopped=false;
            CycInt_AddRelativeInterrupt(ENET_IO_DELAY, INT_CPU_CYCLE, INTERRUPT_ENET_IO);
    -        Log_Printf(LOG_WARN, "Starting SLIRP");
    -        slirp_init();
    -        slirpq = QueueCreate();
    -        slirp_inited=1;
    -        slirp_mutex=SDL_CreateMutex();
    -        SDL_CreateThread(tick_func,"SLiRPTickThread", (void *)NULL);
        }
    }

    void Ethernet_Reset(void) {
    -    int ret;
        enet.reset=EN_RESET;
        enet_stopped=true;
       
    -    if(slirp_inited){
    -    Log_Printf(LOG_WARN, "Stopping SLIRP");
    -    slirp_inited=0;
    -    slirp_exit(0);
    -    QueueDestroy(slirpq);
    -    SDL_DestroyMutex(slirp_mutex);
    -    SDL_WaitThread(tick_func, &ret);
    -    }
    -    
        enet_rx_buffer.size=enet_tx_buffer.size=0;
        enet_rx_buffer.limit=enet_tx_buffer.limit=2048;
    }
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 11, 2015, 04:10:06 pm
    OK OK  I got it.  Yes it turns out my slirp is 32bit only.

    To build 32bit you need to do

    cmake -DCMAKE_OSX_ARCHITECTURES=i386 .

    To force the blasted thing.

    I need to jiggle the timing better but I did telnet to a bbs!

    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 11, 2015, 04:41:23 pm
    This is quite impressive! If you are on Mac OS X it might be useful to use Xcode for debugging purpose. Maybe you already know, but you can easily create an Xcode project using
    #cmake -G Xcode
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 11, 2015, 05:53:49 pm
    It's late, and I need some Zzzss..

    So here is what I have now for OS X. (Sorry windows users, I thought I trashed my OS X box, but I really trashed mingw32..)

    My binary for OS X here (http://vpsland.superglobalmegacorp.com/old/install/OS%20X%20x86/Previous/Previous-0.52+slirp.7z).

    The source code is here (http://vpsland.superglobalmegacorp.com/old/install/OS%20X%20x86/Previous/previous-code-391+slirp.7z).

    On compiling, you have to manually build slirp.. Its not hard at all since it only seems to work in 32bit mode, something like this:

    $ cd slirp
    $ sh buildOSX106-i386.sh

    A whole bunch of warnings...
    Quote1 warning generated.
         19


    this number *MUST* be 19.... as that is how many object files it should have.

    OK, now be sure to have cmake generate a 32bit build..

    cmake -DCMAKE_OSX_ARCHITECTURES=i386 .

    make, and it'll bomb on linking... ok

    edit CMakeFiles/Previous.dir/link.txt

    look for something like

    debug/libDebug.a

    and add this after it:

    slirp/slirp106i386.a

    And after all that, it should get you an executable.

    I'm on 10.10.3 with latest xcode.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 11, 2015, 06:18:40 pm
    this is great news, impressive!

    I tried to run this new release of Previous on OS X 10.9.5 and 10.10.3 but all I got was an error:

    Previous cannot be opened because of a problem.

    Check with the developer to make sure Previous works with this version of OS X. You may need to reinstall the application. Be sure to install any available updates for the application and OS X.

    Click Report to see more detailed information and send a report to Apple.

    any idea what might have gone wrong?

    regards,
    michael
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 11, 2015, 09:29:33 pm
    Great work, thank you! I was able to build the sources after adding them to the Cmake project. The source code is here (https://dl.dropboxusercontent.com/u/44703754/msvc/Previous_Slirp_b.zip).
    It can be used to build an Xcode project for debugging purpose.

    I also made a quick binary build (download here (https://dl.dropboxusercontent.com/u/44703754/msvc/Previous.app.zip)). I did not test networking yet, but there seem to be problems booting later versions of NeXTstep.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on April 12, 2015, 12:04:49 am
    Quote from: "mikeboss"this is great news, impressive!

    I tried to run this new release of Previous on OS X 10.9.5 and 10.10.3 but all I got was an error:

    Previous cannot be opened because of a problem.


    I had to install SDL 2 after running the program from the terminal
    http://www.libsdl.org/download-2.0.php
    hope this helps!

    I also got it working after ^C'ing through some weird loop at boot. is there anything I need to config in NEXTSTEP? thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 12, 2015, 12:52:14 am
    WOW WOW WOW WOW

    Look what happens when I go away for a day!

    I downloaded Andreas's quick build, but unfortunately it doesn't work on my MacBook running 10.9.5.  "ifconfig en0" does show the correct setup, but I cannot ping the router or my MacBook's address.

    Still, this is AMAZING progress!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 01:07:57 am
    Oh yeah I should have added this...

    You *HAVE* to use the following configuration

    IP address: 10.0.2.15
    netmask 255.255.255.0
    default gateway 10.0.2.2


    DNS can be 10.0.2.3 although you can use 4.2.2.4, I recall nextstep and 8.8.8.8 don't get along.

    The ONLY address you can ping is 10.0.2.2

    I am pretty sure I didn't configure NS 0.8 correctly as I didn't get DNS working so I'm telnetting by ip address.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on April 12, 2015, 01:24:52 am
    Quote from: "neozeed"You *HAVE* to use the following configuration

    IP address: 10.0.2.15
    netmask 255.255.255.0
    default gateway 10.0.2.2


    DNS can be 10.0.2.3 although you can use 4.2.2.4, I recall nextstep and 8.8.8.8 don't get along.


    do I set these via the terminal or using SNS or rather something else?
    also what about broadcast address?

    cheers!  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 02:39:43 am
    Quote from: "andreas_g"Great work, thank you! I was able to build the sources after adding them to the Cmake project. The source code is here (https://dl.dropboxusercontent.com/u/44703754/msvc/Previous_Slirp_b.zip).
    It can be used to build an Xcode project for debugging purpose.

    I also made a quick binary build (download here (https://dl.dropboxusercontent.com/u/44703754/msvc/Previous.app.zip)). I did not test networking yet, but there seem to be problems booting later versions of NeXTstep.


    Networking on NS is a real PITA.  I had these issues on my cube back in the day with a virgin 3.3 install, and connected ethernet it would hang on boot, or take like an HOUR to come up unless you hit control C



    Basically once the tape virtual devices initialize (nrst0 & nrst1), hit control C and it'll boot

    And here is how you should configure NS...



    Remember the config tool screws up the gateway, so you have to manually put it in there.

    Now for the part I don't get, the NeXT Computer booting 0.8 can use TCP just fine, but a NeXTstation booting 3.3 can't use TCP to save it's life.  It seems that the NeXT Computer are incapable of booting 3.3.

    Wait I just got a cube to boot into 3.3 with working network!

    From my config:

    [System]
    nMachineType = 1
    bColor = FALSE
    bTurbo = FALSE
    bADB = FALSE
    nSCSI = TRUE
    nRTC = FALSE
    nCpuLevel = 4
    nCpuFreq = 33
    bCompatibleCpu = TRUE
    bBlitter = FALSE
    nDSPType = 0
    bRealTimeClock = FALSE
    bPatchTimerD = FALSE
    bFastForward = FALSE
    bAddressSpace24 = FALSE
    bCycleExactCpu = FALSE
    n_FPUType = 68040
    bCompatibleFPU = TRUE
    bMMU = TRUE


    I kind of screwed up my keyboard, but you get the idea!

    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 02:43:33 am
    Quote from: "jasonwoodland"
    Quote from: "neozeed"You *HAVE* to use the following configuration

    IP address: 10.0.2.15
    netmask 255.255.255.0
    default gateway 10.0.2.2


    DNS can be 10.0.2.3 although you can use 4.2.2.4, I recall nextstep and 8.8.8.8 don't get along.


    do I set these via the terminal or using SNS or rather something else?
    also what about broadcast address?

    cheers!  :D


    I've only networked 3.3 so in the admin section there is a simple config tool, you can configure it there, but it's buggy and doesn't work right.  Once it's done it's thing, edit it manually and use something like this:

    HOSTNAME=prev33
    INETADDR=10.0.2.15
    ROUTER=10.0.2.2
    IPNETMASK=255.255.255.0
    IPBROADCAST=10.0.2.255
    NETMASTER=-YES-
    YPDOMAIN=-NO-
    TIME=-AUTOMATIC-


    Assuming you want your machine called prev33.  See my previous posts on a machine type that'll boot 3.3 with networking!
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 03:10:20 am
    I checked one thing, the more often the slirp timer fires, the better it is, and it looks like my mutex's are blocking any code stomps so I dropped it to 10ms, and it feels snappier to telnet out.

    From ethernet.c all you have to do is drop the SDL_Delay

    static int tick_func(void *arg)
    {
       while(slirp_inited)
       {
       SDL_Delay(10);
           slirp_tick();
       }
       return 0;
    }


    I will try to figure out why I can't telnet in.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on April 12, 2015, 07:02:22 am
    i don't know much but it seems it isn't receiving packets even though slirp is?
    OS4.2 NeXTstation Color using andreas_g's build a few posts up
    I have NeXTstation selected in System since i cant seem to get anything running on the "NeXT Computer" option. Would that possibly cause this behaviour?

    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 07:06:26 am
    Quote from: "jasonwoodland"i don't know much but it seems it isn't receiving packets even though slirp is?
    OS4.2 NeXTstation Color using andreas_g's build a few posts up
    I have NeXTstation selected in System since i cant seem to get anything running on the "NeXT Computer" option. Would that possibly cause this behaviour?


    I couldnt get the nextstation to do tcp.  Try the cube @33mhz and see how that goes.  (Not the turbo cube, the regular one, but bump the CPU frequency)
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on April 12, 2015, 08:42:41 am
    Quote from: "neozeed"I couldnt get the nextstation to do tcp.  Try the cube @33mhz and see how that goes.  (Not the turbo cube, the regular one, but bump the CPU frequency)


    no luck with the cube either. running NS3.3 on your latest build @33mHz
    seems to be the same as before. to clarify, i ping, i can see rx packets but the OS seems oblivious, same with telnet connections, they just time out in NS.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 09:10:22 am
    Quote from: "jasonwoodland"
    Quote from: "neozeed"I couldnt get the nextstation to do tcp.  Try the cube @33mhz and see how that goes.  (Not the turbo cube, the regular one, but bump the CPU frequency)


    no luck with the cube either. running NS3.3 on your latest build @33mHz
    seems to be the same as before. to clarify, i ping, i can see rx packets but the OS seems oblivious, same with telnet connections, they just time out in NS.


    Try updating to the latest binary from my site maybe me lowering the tick interval to 10ms is better...

    for what it's worth, here is my config file...

    [Log]
    sLogFileName = stderr
    sTraceFileName = stderr
    nTextLogLevel = 0
    nAlertDlgLogLevel = 1
    bConfirmQuit = TRUE

    [ConfigDialog]
    bShowConfigDialogAtStartup = TRUE

    [Debugger]
    nNumberBase = 10
    nDisasmLines = 8
    nMemdumpLines = 8

    [Screen]
    nMonitorType = 1
    bFullScreen = FALSE
    bKeepResolution = TRUE
    bAllowOverscan = TRUE
    nSpec512Threshold = 16
    nForceBpp = 0
    bAspectCorrect = TRUE
    bUseExtVdiResolutions = FALSE
    nVdiWidth = 0
    nVdiHeight = 0
    nVdiColors = 0
    bShowStatusbar = TRUE
    bShowDriveLed = TRUE
    bCrop = FALSE
    nMaxWidth = 800
    nMaxHeight = 600

    [Keyboard]
    bDisableKeyRepeat = FALSE
    nKeymapType = 0
    szMappingFileName =

    [ShortcutsWithModifiers]
    keyOptions = 111
    keyFullScreen = 102
    keyMouseMode = 109
    keyColdReset = 99
    keyWarmReset = 114
    keyScreenShot = 103
    keyBossKey = 105
    keyCursorEmu = 106
    keyFastForward = 120
    keyRecAnim = 97
    keyRecSound = 121
    keySound = 115
    keyPause = 112
    keyDebugger = 100
    keyQuit = 113
    keyLoadMem = 108
    keySaveMem = 107
    keyInsertDiskA = 49

    [ShortcutsWithoutModifiers]
    keyOptions = 1073741893
    keyFullScreen = 1073741892
    keyMouseMode = 0
    keyColdReset = 0
    keyWarmReset = 0
    keyScreenShot = 0
    keyBossKey = 0
    keyCursorEmu = 0
    keyFastForward = 0
    keyRecAnim = 0
    keyRecSound = 0
    keySound = 0
    keyPause = 0
    keyDebugger = 0
    keyQuit = 0
    keyLoadMem = 0
    keySaveMem = 0
    keyInsertDiskA = 0

    [Mouse]
    bEnableAutoGrab = TRUE
    fLinSpeedNormal = 1
    fLinSpeedLocked = 1
    fExpSpeedNormal = 1
    fExpSpeedLocked = 1

    [Sound]
    bEnableMicrophone = TRUE
    bEnableSound = TRUE
    nPlaybackFreq = 44100
    nSdlAudioBufferSize = 0
    szYMCaptureFileName = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS/hatari.wav

    [Memory]
    nMemoryBankSize0 = 16
    nMemoryBankSize1 = 0
    nMemoryBankSize2 = 0
    nMemoryBankSize3 = 0
    nMemorySpeed = 1
    bAutoSave = FALSE
    szMemoryCaptureFileName = /Users/neozeed/.previous/hatari.sav
    szAutoSaveFileName = /Users/neozeed/.previous/auto.sav

    [Floppy]
    bAutoInsertDiskB = TRUE
    bSlowFloppy = FALSE
    nWriteProtection = 0
    szDiskAZipPath =
    szDiskAFileName =
    szDiskBZipPath =
    szDiskBFileName =
    szDiskImageDirectory = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS/

    [Boot]
    nBootDevice = 0
    bEnableDRAMTest = FALSE
    bEnablePot = TRUE
    bEnableSoundTest = TRUE
    bEnableSCSITest = TRUE
    bLoopPot = FALSE
    bVerbose = TRUE
    bExtendedPot = FALSE

    [HardDisk]
    szImageName0 = /Users/neozeed/src/pre/Nextstep 3.3 HD Image With Previous/NS33_2GB.dd
    bAttached0 = TRUE
    bCDROM0 = FALSE
    szImageName1 = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS
    bAttached1 = FALSE
    bCDROM1 = FALSE
    szImageName2 = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS
    bAttached2 = FALSE
    bCDROM2 = FALSE
    szImageName3 = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS
    bAttached3 = FALSE
    bCDROM3 = FALSE
    szImageName4 = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS
    bAttached4 = FALSE
    bCDROM4 = FALSE
    szImageName5 = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS
    bAttached5 = FALSE
    bCDROM5 = FALSE
    szImageName6 = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS
    bAttached6 = FALSE
    bCDROM6 = FALSE
    bBootFromHardDisk = FALSE
    nWriteProtection = 0

    [MagnetoOptical]
    szImageName0 = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS
    bDriveConnected0 = FALSE
    bDiskInserted0 = FALSE
    bWriteProtected0 = FALSE
    szImageName1 = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS
    bDriveConnected1 = FALSE
    bDiskInserted1 = FALSE
    bWriteProtected1 = FALSE

    [ROM]
    szRom030FileName = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS/Rev_1.0_v41.BIN
    szRom040FileName = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS/Rev_2.5_v66.BIN
    szRomTurboFileName = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS/Rev_3.3_v74.BIN

    [RS232]
    bEnableRS232 = FALSE
    szOutFileName = /dev/modem
    szInFileName = /dev/modem

    [Printer]
    bEnablePrinting = FALSE
    bPrintToFile = TRUE
    szPrintToFileName = /Users/neozeed/.previous/hatari.prn

    [Midi]
    bEnableMidi = FALSE
    sMidiInFileName = /dev/snd/midiC1D0
    sMidiOutFileName = /dev/snd/midiC1D0

    [System]
    nMachineType = 1
    bColor = FALSE
    bTurbo = FALSE
    bADB = FALSE
    nSCSI = TRUE
    nRTC = FALSE
    nCpuLevel = 4
    nCpuFreq = 33
    bCompatibleCpu = TRUE
    bBlitter = FALSE
    nDSPType = 0
    bRealTimeClock = FALSE
    bPatchTimerD = FALSE
    bFastForward = FALSE
    bAddressSpace24 = FALSE
    bCycleExactCpu = FALSE
    n_FPUType = 68040
    bCompatibleFPU = TRUE
    bMMU = TRUE

    [Video]
    AviRecordVcodec = 1
    AviRecordFps = 0
    AviRecordFile = /Users/neozeed/src/pre/previous-code-391-trunk/src/Previous.app/Contents/MacOS/hatari.avi


    I'm using an image I found on winworldpc... it looks like a vanilla install.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 12, 2015, 10:37:18 am
    Quote from: "neozeed"it looks like a vanilla install.


    yes, these are vanilla/fresh installs. most of them not even booted once after the installation process was finished. I created these images (on a real cube).

    regards,
    michael
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on April 12, 2015, 10:39:41 am
    this is pretty sweet! just replaced your username with mine and fixed paths for ROM and SCSI drive. using NS3.3 HDD image from winworld and your latest Previous build.
    I've waited a long time for this moment. cheers!

    i used the SNS app to set everything, then edited to /etc/hostconfig to replace -ROUTED- with 10.0.2.2
    also replaced the default local IP with 10.0.2.15 in /etc/hosts
    changed hostname in /etc/hostname
    put "nameserver 10.0.2.3" in /etc/resolv.conf

    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 12, 2015, 11:10:04 am
    Wow.  This is really amazing.  I booted 2.1 in the build from Andreas, and configured my MacBook as 10.0.2.2, and the NeXT as 10.0.2.15.  I enabled the telnet server on my Mac, and was able to telnet to the Mac!

    I did notice that the NeXT is not a server here: the endpoints for the IP connections are both 127.0.0.1.  I guess that's because we're using SLIRP, which is maybe going to give us only outbound connectivity.

    But, wow, how amazing!
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 11:29:06 am
    Quote from: "mikeboss"
    Quote from: "neozeed"it looks like a vanilla install.


    yes, these are vanilla/fresh installs. most of them not even booted once after the installation process was finished. I created these images (on a real cube).

    regards,
    michael


    Oh cool! Very awesome!
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 11:35:03 am
    Quote from: "eagle"Wow.  This is really amazing.  I booted 2.1 in the build from Andreas, and configured my MacBook as 10.0.2.2, and the NeXT as 10.0.2.15.  I enabled the telnet server on my Mac, and was able to telnet to the Mac!

    I did notice that the NeXT is not a server here: the endpoints for the IP connections are both 127.0.0.1.  I guess that's because we're using SLIRP, which is maybe going to give us only outbound connectivity.

    But, wow, how amazing!


    You don't have to configure your MacBook at all.. and yes SLiRP really is for outbound only.

    There is a redirect function but it doesn't work on my Mac, but port 42323 is set to 'telnet' back into the NeXT..
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 11:36:06 am
    Quote from: "jasonwoodland"this is pretty sweet! just replaced your username with mine and fixed paths for ROM and SCSI drive. using NS3.3 HDD image from winworld and your latest Previous build.
    I've waited a long time for this moment. cheers!

    i used the SNS app to set everything, then edited to /etc/hostconfig to replace -ROUTED- with 10.0.2.2
    also replaced the default local IP with 10.0.2.15 in /etc/hosts
    changed hostname in /etc/hostname
    put "nameserver 10.0.2.3" in /etc/resolv.conf


    Awesome!!!  with this config, can you boot your OS42 disk?
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on April 12, 2015, 02:16:37 pm
    Quote from: "neozeed"Awesome!!!  with this config, can you boot your OS42 disk?


    will try soon, got a few intermittent faults i want to understand. after running omniweb (which doesnt load any page) nothing else seems to work? i have to reboot to get networking again.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 12, 2015, 06:45:04 pm
    Quote from: "jasonwoodland"after running omniweb (which doesnt load any page) nothing else seems to work? i have to reboot to get networking again.


    I'm seeing the exact same problem. Also i experienced hangs and crashes related to emulator reset. I think there might be quite a lot of "unclean" code in slirp, which is also the reason it won't work 64 bit. Maybe there is an updated version around somewhere? I think someone updated it for 64 bit for sure.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on April 12, 2015, 06:53:38 pm
    Nice job neozeed!
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 12, 2015, 11:53:16 pm
    Quote from: "andreas_g"
    Quote from: "jasonwoodland"after running omniweb (which doesnt load any page) nothing else seems to work? i have to reboot to get networking again.


    I'm seeing the exact same problem. Also i experienced hangs and crashes related to emulator reset. I think there might be quite a lot of "unclean" code in slirp, which is also the reason it won't work 64 bit. Maybe there is an updated version around somewhere? I think someone updated it for 64 bit for sure.


    something is broken regarding DNS... which is strange.  this is the code that I used to get Internet explorer running on basilisk II... Obviously something NS does  really sends it for a loop.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 13, 2015, 07:29:39 am
    Good work neozeed!
    I have complied Previous with SLiRP support on elementaryOS(linux).Here's how I do:
    downloaded Previous from SF
    pasted neozeed's slirp on src
    builded slirp with
    sh buildLinuxi386.sh
    found the number 19.
    Replaced ethernet.c with neozeed's ethernet.c
    typed configure and make
    make bomb when linking.
    added line slirp/slirplinuxi386.a in link.txt
    again typed make and Previous build successfully.
    ... very easy, isn't it?  8)

    Now I have configured with SNS app but can any tell me how to edit the /etc/hostconfig and other files please?
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 13, 2015, 07:55:05 am
    Quote from: "Mominul"Good work neozeed!
    I have complied Previous with SLiRP support on elementaryOS(linux).Here's how I do:
    downloaded Previous from SF
    pasted neozeed's slirp on src
    builded slirp with
    sh buildLinuxi386.sh
    found the number 19.
    Replaced ethernet.c with neozeed's ethernet.c
    typed configure and make
    make bomb when linking.
    added line slirp/slirplinuxi386.a in link.txt
    again typed make and Previous build successfully.
    ... very easy, isn't it?  8)

    Now I have configured with SNS app but can any tell me how to edit the /etc/hostconfig and other files please?


    I use vi.  But im old..
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on April 13, 2015, 08:52:26 am
    Quote from: "Mominul"I have complied Previous with SLiRP support on elementaryOS(linux).


    good job i'll have to try this on my GNUstep machine!

    Quote from: "Mominul"Now I have configured with SNS app but can any tell me how to edit the /etc/hostconfig and other files please?


    i too use vi but you can use the open command in the terminal to edit with Edit.app (make sure you're logged in as root)

    open /etc/hostname (your host name)
    open /etc/hostconfig (replace "-ROUTER-" with "10.0.2.2")
    open /etc/hosts (add "10.0.2.15 yourhostname")
    open /etc/resolv.conf (add "nameserver 10.0.2.3")
    open /etc/networks (replace that original weird local ip address with "10.0.2.15 yourhostname")

    if the file doesnt exist use "touch /etc/resolv.conf" or whatever

    i don't know if modifying all these files is really necessary but it got it working for me
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 13, 2015, 11:00:06 am
    Wow, this is impressive!

    NTP works great, and NFS mounts a directory.  I assume it works fine, but I've only just started messing with it.  So far, it seems that, in order to mount NFS, the hostname must be in the NetInfo database.  I have forgotten how to use NetInfoManager, but I know how to use nidump and niload, so I was able to add a hostname that way.  Passing an IP address to the mount command does not seem to work, but that's probably a NeXTSTEP problem, not a Previous problem.

    Also, I note that this version of mount_nfs does not support "-o tcp" so the only option is UDP.

    Very very fun stuff.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 13, 2015, 03:05:01 pm
    Im surprised NFS works, while DNS gets it to bomb.  I'll have to rig it to capture packets, and feed slirp on winodws to see what on earth is going on.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 14, 2015, 02:22:33 am

    working on it ...  :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 15, 2015, 04:07:58 pm
    Thank you mominul for your work! Looking forward to see how it works.

    News on networking: Seems Basilisk II is using a 64-bit clean version of slirp. It was a little bit tricky to discover, because the code in Basilisk's main repository does not yet contain the patch for 64-bit support.

    You can load the source code here (https://dl.dropboxusercontent.com/u/44703754/slirp%2064bit.zip).

    I'll add to the Previous repository. But i'll wait with adding the patch for ethernet.c until the remaining problems are fixed. @neozeed: any news on this?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 15, 2015, 05:23:35 pm
    Thanks Andreas! About SLiRP, QEmu also use SLiRP for networking. So it could have a patch for 64bit...
    I am having problem with the GUI. It gets SEG Fault and crashes Previous  :evil:
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 16, 2015, 12:03:29 am
    Quote from: "andreas_g"Thank you mominul for your work! Looking forward to see how it works.

    News on networking: Seems Basilisk II is using a 64-bit clean version of slirp. It was a little bit tricky to discover, because the code in Basilisk's main repository does not yet contain the patch for 64-bit support.

    You can load the source code here (https://dl.dropboxusercontent.com/u/44703754/slirp%2064bit.zip).

    I'll add to the Previous repository. But i'll wait with adding the patch for ethernet.c until the remaining problems are fixed. @neozeed: any news on this?


    It should magically work........ Although I think I started with their slirp.  very strange.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 16, 2015, 07:40:11 am
    Quote from: "neozeed"It should magically work........ Although I think I started with their slirp.  very strange.


    Not sure if i understand correctly. 64-bit seems to work now, but the other problems still remain. For example it is not yet possible to connect to the internet using a web browser inside the guest system.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 16, 2015, 10:13:33 am
    Ok... SEGFAULT problem gone!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 17, 2015, 10:01:57 am
    Here is the diff
    Index: src/CMakeLists.txt
    ===================================================================
    --- src/CMakeLists.txt (revision 392)
    +++ src/CMakeLists.txt (working copy)
    @@ -2,7 +2,7 @@
    cfgopts.c clocks_timings.c configuration.c options.c  change.c
    control.c cycInt.c cycles.c dialog.c dma.c esp.c ethernet.c file.c
    ioMem.c ioMemTabNEXT.c memorySnapShot.c keymap.c kms.c
    - m68000.c main.c mo.c nextMemory.c paths.c
    + m68000.c main.c mo.c nextMemory.c paths.c createBlankImage.c
    ramdac.c resolution.c reset.c rs.c rtcnvram.c scandir.c
    scc.c screen.c screenSnapShot.c scsi.c shortcut.c
    statusbar.c str.c sysReg.c zip.c unzip.c utils.c
    Index: src/gui-sdl/CMakeLists.txt
    ===================================================================
    --- src/gui-sdl/CMakeLists.txt (revision 392)
    +++ src/gui-sdl/CMakeLists.txt (working copy)
    @@ -7,6 +7,6 @@
    dlgAbout.c dlgAdvanced.c dlgAlert.c dlgBoot.c dlgDevice.c
    dlgFileSelect.c dlgHardDisk.c dlgKeyboard.c dlgMain.c dlgMemory.c
    dlgMemoryAdvanced.c dlgMissingFile.c dlgMouse.c dlgOpticalDisk.c
    - dlgRom.c dlgScreen.c dlgSystem.c
    + dlgRom.c dlgScreen.c dlgSystem.c dlgNewDisk.c
    sdlgui.c
    )
    Index: src/gui-sdl/dlgHardDisk.c
    ===================================================================
    --- src/gui-sdl/dlgHardDisk.c (revision 392)
    +++ src/gui-sdl/dlgHardDisk.c (working copy)
    @@ -49,7 +49,8 @@
    #define DISKDLG_SCSIBROWSE6        35
    #define DISKDLG_SCSINAME6          36

    -#define DISKDLG_EXIT               37
    +#define DISKDLG_CREATEDISK         37
    +#define DISKDLG_EXIT               38


    /* The disks dialog: */
    @@ -100,8 +101,8 @@
    { SGBUTTON, 0, 0, 54,21, 8,1, "Browse" },
        { SGTEXT, 0, 0, 3,22, 58,1, NULL },

    -
    -    { SGBUTTON, SG_DEFAULT, 0, 22,26, 20,1, "Back to main menu" },
    + { SGBUTTON, 0, 0, 11,26, 20,1, "Create Blank Disk" },
    +    { SGBUTTON, SG_DEFAULT, 0, 32,26, 20,1, "Back to main menu" },
    { -1, 0, 0, 0,0, 0,0, NULL }
    };

    @@ -240,6 +241,8 @@
                    if (SDLGui_FileConfSelect(dlgname_scsi[6], ConfigureParams.SCSI.target[6].szImageName, diskdlg[DISKDLG_SCSINAME6].w, false))
                        ConfigureParams.SCSI.target[6].bAttached = true;
                    break;
    +    case DISKDLG_CREATEDISK:
    + DlgNewDisk_Main();
            }
    }
    while (but != DISKDLG_EXIT && but != SDLGUI_QUIT
    Index: src/gui-sdl/dlgNewDisk.c
    ===================================================================
    --- src/gui-sdl/dlgNewDisk.c (revision 392)
    +++ src/gui-sdl/dlgNewDisk.c (working copy)
    @@ -1,153 +1,140 @@
    /*
    -  Hatari - dlgNewDisk.c
    +  Previous - dlgNewDisk.c

      This file is distributed under the GNU Public License, version 2 or at
      your option any later version. Read the file gpl.txt for details.
    */
    -const char DlgNewDisk_fileid[] = "Hatari dlgNewDisk.c : " __DATE__ " " __TIME__;
    +const char DlgNewDisk_fileid[] = "Previous dlgNewDisk.c : " __DATE__ " " __TIME__;

    #include "main.h"
    +#include "createBlankImage.h"
    #include "configuration.h"
    -#include "createBlankImage.h"
    #include "dialog.h"
    #include "sdlgui.h"
    #include "file.h"
    -#include "log.h"

    -#define DLGNEWDISK_DECTRACK   3
    -#define DLGNEWDISK_TRACKSTR   4
    -#define DLGNEWDISK_INCTRACK   5
    -#define DLGNEWDISK_SECTORS9   7
    -#define DLGNEWDISK_SECTORS10  8
    -#define DLGNEWDISK_SECTORS11  9
    -#define DLGNEWDISK_SECTORS18  10
    -#define DLGNEWDISK_SECTORS36  11
    -#define DLGNEWDISK_SIDES1     13
    -#define DLGNEWDISK_SIDES2     14
    -#define DLGNEWDISK_SAVE       15
    -#define DLGNEWDISK_EXIT       16

    -static char szTracks[3];
    -static int nTracks = 80;
    +#define DLGNEWDISK_HDSIZE     5
    +#define DLGNEWDISK_HDPATH     7
    +#define DLGNEWDISK_HDBROWSE   8
    +#define DLGNEWDISK_HDCREATE   9
    +#define DLGNEWDISK_FD720KB    13
    +#define DLGNEWDISK_FD144MB    14
    +#define DLGNEWDISK_FD288MB    15
    +#define DLGNEWDISK_FDPATH     17
    +#define DLGNEWDISK_FDBROWSE   18
    +#define DLGNEWDISK_FDCREATE   19
    +#define DLGNEWDISK_EXIT       20

    -/* The new disk image dialog: */
    +char szHDSize[6]; // 10 GB
    +
    +/* The New Disk Dialog dialog: */
    static SGOBJ newdiskdlg[] =
    {
    - { SGBOX, 0, 0, 0,0, 29,14, NULL },
    - { SGTEXT, 0, 0, 6,1, 16,1, "New floppy image" },
    - { SGTEXT, 0, 0, 2,3, 7,1, "Tracks:" },
    - { SGBUTTON, 0, 0, 12,3, 1,1, "\x04" },   /* Left-arrow button  */
    - { SGTEXT, 0, 0, 14,3, 2,1, szTracks },
    - { SGBUTTON, 0, 0, 17,3, 1,1, "\x03" },   /* Right-arrow button */
    - { SGTEXT, 0, 0, 2,5, 8,1, "Sectors:" },
    - { SGRADIOBUT, 0, SG_SELECTED, 12,5, 4,1, " 9" },
    - { SGRADIOBUT, 0, 0, 17,5, 4,1, "10" },
    - { SGRADIOBUT, 0, 0, 22,5, 4,1, "11" },
    - { SGRADIOBUT, 0, 0, 12,6, 9,1, "18 (HD)" },
    - { SGRADIOBUT, 0, 0, 12,7, 9,1, "36 (ED)" },
    - { SGTEXT, 0, 0, 2,9, 6,1, "Sides:" },
    - { SGRADIOBUT, 0, 0, 12,9, 4,1, "1" },
    - { SGRADIOBUT, 0, SG_SELECTED, 17,9, 4,1, "2" },
    - { SGBUTTON, 0, 0, 4,12, 8,1, "Create" },
    - { SGBUTTON, 0, 0, 18,12, 6,1, "Back" },
    - { -1, 0, 0, 0,0, 0,0, NULL }
    -};
    + { SGBOX, 0, 0, 0,0, 58,20, NULL },
    +   { SGTEXT, 0, 0, 22,1, 14,1, "New Disk image" },

    -#define DEFAULT_DISK_NAME "new_disk.st"
    + { SGBOX, 0, 0, 2,3, 54,6, NULL },
    + { SGTEXT, 0, 0, 22,4, 15,1, "Create HD image" },
    +   { SGTEXT, 0, 0, 3,5, 9,1, "Size(MB):" },
    + { SGEDITFIELD, 0, 0, 13,5, 5,1, szHDSize }, // 10 GB
    + { SGTEXT, 0, 0, 3, 7, 5,1, "Path:" },
    + { SGTEXT, 0, 0, 9,7, 28,1, "" },
    + { SGBUTTON, 0, 0, 38,7, 8,1, "Browse" },
    + { SGBUTTON, 0, 0, 47,7, 8,1, "Create" },    

    + { SGBOX, 0, 0, 2,10, 54,7, NULL },
    + { SGTEXT, 0, 0, 22,11, 15,1, "Create FD image" },
    + { SGTEXT, 0, 0, 3,13, 5,1, "Size:" },
    + { SGRADIOBUT, 0, 0, 9,13, 6,1, "720 KB" },
    + { SGRADIOBUT, 0, 0, 19,13, 7,1, "1.44 MB" },
    + { SGRADIOBUT, 0, SG_SELECTED, 30,13, 7,1, "2.88 MB" },
    + { SGTEXT, 0, 0, 3,15, 5,1, "Path:" },
    + { SGTEXT, 0, 0, 9,15, 28,1, "" },
    +    { SGBUTTON, 0, 0, 38,15, 8,1, "Browse" },
    + { SGBUTTON, 0, 0, 47,15, 8,1, "Create" },

    -/*-----------------------------------------------------------------------*/
    -/**
    - * Handle creation of a the "new blank disk image".
    - * return true if disk created, false otherwise.
    - */
    -static bool DlgNewDisk_CreateDisk(const char *path)
    -{
    - int nSectors, nSides;
    + { SGBUTTON, SG_DEFAULT, 0, 18,18, 20,1, "Back" },
    + { -1, 0, 0, 0,0, 0,0, NULL }
    +};

    - /* (potentially non-existing) filename? */
    - if (File_DirExists(path))
    - {
    - Log_AlertDlg(LOG_ERROR, "ERROR: '%s' isn't a file!", path);
    - return false;
    - }

    - /* Get number of sectors */
    - if (newdiskdlg[DLGNEWDISK_SECTORS36].state & SG_SELECTED)
    - nSectors = 36;
    - else if (newdiskdlg[DLGNEWDISK_SECTORS18].state & SG_SELECTED)
    - nSectors = 18;
    - else if (newdiskdlg[DLGNEWDISK_SECTORS11].state & SG_SELECTED)
    - nSectors = 11;
    - else if (newdiskdlg[DLGNEWDISK_SECTORS10].state & SG_SELECTED)
    - nSectors = 10;
    - else
    - nSectors = 9;

    - /* Get number of sides */
    - if (newdiskdlg[DLGNEWDISK_SIDES1].state & SG_SELECTED)
    - nSides = 1;
    - else
    - nSides = 2;
    -
    - return CreateBlankImage_CreateFile(path, nTracks, nSectors, nSides);
    -}
    -
    -
    /*-----------------------------------------------------------------------*/
    /**
    - * Show and process the "new blank disk image" dialog.
    - * Return file name of last created diskimage or NULL if none created.
    - * Caller needs to free the name.
    + * Show and process the New Disk dialog.
     */
    -char *DlgNewDisk_Main(void)
    +void DlgNewDisk_Main(void)
    {
    - int but;
    - char *szNewDiskName, *tmpname, *retname = NULL;
    - sprintf(szTracks, "%i", nTracks);
    + char szNewHD[29];
    + char szNewFD[29];
    + char *selHD, *selFD, *confHD, *confFD;
    + int but, nHDSize;
    + bool bRet;
    + FDtype FDType;

    - SDLGui_CenterDlg(newdiskdlg);
    + SDLGui_CenterDlg(newdiskdlg);

    /* Initialize disk image name: */
    - szNewDiskName = File_MakePath(ConfigureParams.DiskImage.szDiskImageDirectory, "new_disk.st", NULL);
    - if (!szNewDiskName)
    - return NULL;
    + confHD = File_MakePath(ConfigureParams.DiskImage.szDiskImageDirectory, "c.img", NULL);
    + confFD = File_MakePath(ConfigureParams.DiskImage.szDiskImageDirectory, "a.img", NULL);

    - /* Draw and process the dialog */
    do
    {
    but = SDLGui_DoDialog(newdiskdlg, NULL);
    - switch(but)
    + switch (but)
    {
    - case DLGNEWDISK_DECTRACK:
    - if (nTracks > 40)
    - nTracks -= 1;
    - sprintf(szTracks, "%i", nTracks);
    - break;
    - case DLGNEWDISK_INCTRACK:
    - if (nTracks < 85)
    - nTracks += 1;
    - sprintf(szTracks, "%i", nTracks);
    - break;
    - case DLGNEWDISK_SAVE:
    -            tmpname = SDLGui_FileSelect(szNewDiskName, NULL, true);
    - if (tmpname)
    +            case DLGNEWDISK_HDBROWSE:
    + selHD = SDLGui_FileSelect(confHD,NULL,true);
    + if (selHD)
    + {
    + File_ShrinkName(szNewHD,selHD,sizeof(szNewHD)-1);
    + newdiskdlg[DLGNEWDISK_HDPATH].txt = szNewHD;
    + }
    +                break;
    +                
    +            case DLGNEWDISK_HDCREATE:
    + nHDSize = atoi(szHDSize);
    + if (nHDSize > 0)
    + {
    + bRet = Create_HD_Image(selHD,nHDSize);
    + if (bRet != false)
    {
    - if (DlgNewDisk_CreateDisk(tmpname))
    -                {
    -                    if (retname)
    -                        free(retname);
    -   retname = tmpname;
    -                }
    - else
    - free(tmpname);
    + DlgAlert_Notice("Disk image created successfully.");
    + }else{
    + DlgAlert_Notice("Unable to create disk image. See Debug log.");
    }
    - break;
    + }else{
    + DlgAlert_Notice("Please enter a size!");
    }
    +                break;
    +                
    +            case DLGNEWDISK_FDBROWSE:
    + selFD = SDLGui_FileSelect(confFD,NULL,true);
    + if (selFD)
    + {
    + File_ShrinkName(szNewFD,selFD,sizeof(szNewFD)-1);
    + newdiskdlg[DLGNEWDISK_FDPATH].txt = szNewFD;
    + }
    +                break;
    +                
    +            case DLGNEWDISK_FDCREATE:
    + if (newdiskdlg[DLGNEWDISK_FD720KB].state & SG_SELECTED)
    + FDType = FD_720K;
    + else if (newdiskdlg[DLGNEWDISK_FD144MB].state & SG_SELECTED)
    + FDType = FD_1_44MB;
    + else
    + FDType = FD_2_88MB;
    +
    + bRet = Create_FD_Image(selFD,FDType);
    + if (bRet != false)
    + DlgAlert_Notice("Disk image created successfully.");
    + else
    + DlgAlert_Notice("Unable to create disk image. See Debug log.");
    +                break;
    +
    + }
    }
    while (but != DLGNEWDISK_EXIT && but != SDLGUI_QUIT
          && but != SDLGUI_ERROR && !bQuitProgram);
    -
    - free(szNewDiskName);
    - return retname;
    }
    Index: src/includes/createBlankImage.h
    ===================================================================
    --- src/includes/createBlankImage.h (revision 392)
    +++ src/includes/createBlankImage.h (working copy)
    @@ -1,8 +1,22 @@
    /*
    -  Hatari - createBlankImage.h
    +  Previous - createBlankImage.h

    -  This file is distributed under the GNU Public License, version 2 or at
    -  your option any later version. Read the file gpl.txt for details.
    +  Copyright (C) 2015 Muhammad Mominul Huque & Previous Team
    +
    +  This file is distributed under the GNU General Public License, version 2
    +  or at your option any later version. Read the file gpl.txt for details.
    */
    +#ifndef CREATEBLANKIMAGE_H_INCLUDED
    +#define CREATEBLANKIMAGE_H_INCLUDED

    -extern bool CreateBlankImage_CreateFile(const char *pszFileName, int nTracks, int nSectors, int nSides);
    +typedef enum
    +{
    +    FD_720K,
    +    FD_1_44MB,
    +    FD_2_88MB
    +} FDtype;
    +
    +extern bool Create_HD_Image(const char *pszFileName, int nSize);
    +extern bool Create_FD_Image(const char *pszFileName, FDtype eType);
    +
    +#endif // CREATEBLANKIMAGE_H_INCLUDED
    Index: src/includes/dialog.h
    ===================================================================
    --- src/includes/dialog.h (revision 392)
    +++ src/includes/dialog.h (working copy)
    @@ -24,7 +24,7 @@
    extern void Dialog_MouseDlg(void);
    extern bool Dialog_MemDlg(void);
    extern void Dialog_MemAdvancedDlg(int *membanks);
    -extern char* DlgNewDisk_Main(void);
    +extern void DlgNewDisk_Main(void);
    extern void Dialog_MonitorDlg(void);
    extern void Dialog_WindowDlg(void);
    extern void Dialog_SoundDlg(void);



    But.. svn diff is not including the main file CreateBlankimage.c
    /*
     Previous - createBlankImage.c

     Copyright (C) 2015 Muhammad Mominul Huque & Previous Team

     This file is distributed under the GNU General Public License, version 2
     or at your option any later version. Read the file gpl.txt for details.

     This file is derived from & based on bximage program of Bochs project and
     it is highly modified. For now it will create empty 'flat' images for hd, fd.
    */


    /* NeXT floppy drives use 2.88 MB floppy disk. But they can read 720K, 1.44mb floppy disks also.
    * Magneto Optical disks are 256MB and their block size is 512K.
    */

    #include "main.h"
    #include "log.h"
    #include "statusbar.h"
    #include "createBlankImage.h"
    #include <assert.h>

    #define BX_MAX_CYL_BITS 24 // 8 TB

    const int bx_max_hd_megs = (int)(((1 << BX_MAX_CYL_BITS) - 1) * 16.0 * 63.0 / 2048.0);

    /**
    * Creates 'Flat' image.
    * We create HD and FD image by calling this.
    * Return true if saving succeeded, false otherwise.
    */
    bool CreateFlatImage(Uint64 sec, char *filename)
    {
    FILE *fp;
    bool bRet;

    bRet = false;

    // check if it exists before trashing someone's disk image
    fp = fopen(filename, "r");
    if (fp) {
      /* File exists. Send error */
      bRet = false;
      fclose(fp);
    Log_AlertDlg(LOG_ERROR, "ERROR: File exists");
    return bRet;
    }

    // okay, now open it for writing
    fp = fopen(filename, "w");
      if (fp == NULL) {
      /* Internal error. Send error */
    Log_AlertDlg(LOG_ERROR, "ERROR: Could not write disk image");
    bRet = false;
    return bRet;
    }

    Statusbar_AddMessage("Writing Disk Image", 0);

    while(sec > 0)
    {
      /* temp <-- min(sec, 4194303)
        * 4194303 is (int)(0x7FFFFFFF/512)
        */
      long temp = (long)((sec < 4194303) ? sec : 4194303);
      fseek(fp, 512*temp, SEEK_CUR);
      sec -= temp;
    }

      fseek(fp, -1, SEEK_CUR);
    if (fputc('\0', fp) == EOF)
    {
      fclose(fp);
    bRet = false;
        Log_AlertDlg(LOG_ERROR, "ERROR: The disk image is not complete! (image larger then free space?)");
    return bRet;
      }

    /* File created! */
    fclose(fp);
    bRet = true;
    return bRet;
    }

    /**
    * Creates 'flat' HD image
    * Return true if saving succeeded, false otherwise.
    */
    bool Create_HD_Image(const char *pszFileName, int nSize)
    {
      Uint64 sectors = 0;
      Uint64 cyl;
      int heads=16, spt=63;
    bool bRet = false;


      cyl = (Uint64)(nSize*1024.0*1024.0/16.0/63.0/512.0);
      assert(cyl < (1 << BX_MAX_CYL_BITS));
      sectors = cyl*heads*spt;

    if (sectors < 1){
    Log_AlertDlg(LOG_ERROR, "ERROR: Illegal disk size!");
    return bRet;
    }
        Log_AlertDlg(LOG_INFO, "Creating disk image '%s' with size %i MB.", pszFileName, nSize);
      if(CreateFlatImage(sectors, pszFileName) != false ){
          /* Image successfuly created */
        Log_AlertDlg(LOG_INFO, "Disk image '%s' created.", pszFileName);
          bRet = true;
      } else {
            /* File not created */
            Log_AlertDlg(LOG_ERROR, "Unable to create disk image '%s'!", pszFileName);
            bRet = false;
      }


    return bRet;
    }

    /**
    * Creates 'flat' FD image
    * Return true if saving succeeded, false otherwise.
    */
    bool Create_FD_Image(const char *pszFileName, FDtype eType)
    {
      Uint64 sectors = 0;
    char *fd;
      bool bRet = false;

      int cyl=0, heads=0, spt=0;
      switch (eType) {
        case FD_720K: cyl=80; heads=2; spt=9; fd = "0.72 meg"; break;  /* 0.72 meg */
        case FD_1_44MB: cyl=80; heads=2; spt=18; fd = "1.44 meg"; break; /* 1.44 meg */
      case FD_2_88MB: cyl=80; heads=2; spt=36; fd = "2.88 meg"; break; /* 2.88 meg */
      }
      sectors = cyl*heads*spt;

        Log_AlertDlg(LOG_INFO, "Creating disk image '%s' with size %s.", pszFileName, fd);

      if(CreateFlatImage(sectors, pszFileName) != false ){
          /* Image successfuly created */
          Log_AlertDlg(LOG_INFO, "Disk image '%s' created.", pszFileName);
          bRet = true;
      } else {
          /* File not created */
          Log_AlertDlg(LOG_ERROR, "Unable to create disk image '%s'!", pszFileName);
          bRet = false;
      }



    return bRet;
    }


    changes are so minimal!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 17, 2015, 03:30:56 pm
    Thank you! I'll have a look. Just a little note: please do not post such long content inline. It is quite disturbing the other (in this case networking) discussion because you have to scroll over it. Better post links to the files.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 17, 2015, 05:25:31 pm
    sorry andreas. I have done this because I am having problem to setting up dropbon in linux... sorry.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 17, 2015, 09:05:52 pm
    @neozeed: I noticed something strange about networking. When i try to access a page using a web browser the sent packet seems to be cut. For example when i try to access www.nextcomputers.org the packet looks like this:
    FF FF FF FF FF FF 00 00 0F 00 F3 02 08 06
    00 01 08 00 06 04 00 01 00 00 0F 00 F3 02 0A 00
    02 0F FF FF FF FF FF FF 0A 00 02 03 00 01 01 00
    00 01 00 00 00 00 00 00 03 77 77 77 0D 6E


    The last part (77 77 77 0D 6E) is translated to ASCII: "www n". Maybe this points to the problem? I double-checked the DMA channels. They seem to be OK. I have no problems using telnet.

    Update: This is a valid packet. There is some residual data in it to make it minimum packet size. Real problem found, see below.
    Title: What Needs to be done for a NeXT Emulator
    Post by: nextchef on April 17, 2015, 09:07:16 pm
    I am continually amazed by all the creative work that is being done by members of this community, and I wanted to say thanks to everyone involved.

    Well done everyone!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 17, 2015, 11:19:57 pm
    Good news! I found the problem. It seems i made a mistake with the loopback mode of the transceiver. Disabling loop back makes things work (but breaks power-on test). Maybe someone can explain how loopback should really work? Datasheet for the controller is in the files section of this site (http://www.nextcomputers.org/NeXTfiles/Docs/Hardware/Datasheets/Ethernet-nonTurboNeXT/Fujitsu_MB502_MB8795.pdf). I'll update the sources tomorrow. Time to sleep now (after midnight).

    Many thanks go to neozeed for adding slirp and finally making this possible!

    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 18, 2015, 08:35:03 am
    woohoo, congratulations! well done!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 18, 2015, 04:13:25 pm
    Congratulations! Very good news!
    I am getting a error when compiling SLiRP.
    [  1%] Building C object src/slirp/CMakeFiles/Slirp.dir/misc.c.o
    /home/mominul/previous-mmu/src/slirp/misc.c: In function 'fork_exec':
    /home/mominul/previous-mmu/src/slirp/misc.c:369:14: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
       argv[i++] = "slirp.telnetd";
                 ^
    /home/mominul/previous-mmu/src/slirp/misc.c:370:14: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
       argv[i++] = "-x";
                 ^
    In file included from /usr/include/string.h:635:0,
                    from /usr/include/i386-linux-gnu/sys/un.h:37,
                    from /home/mominul/previous-mmu/src/slirp/slirp.h:164,
                    from /home/mominul/previous-mmu/src/slirp/misc.c:10:
    /home/mominul/previous-mmu/src/slirp/misc.c: At top level:
    /home/mominul/previous-mmu/src/slirp/misc.c:433:1: error: expected identifier or '(' before '__extension__'
    strdup(str)
    ^
    /home/mominul/previous-mmu/src/slirp/misc.c:435:1: error: expected identifier or '(' before '{' token
    {
    ^
    .................................................

    make[2]: *** [src/slirp/CMakeFiles/Slirp.dir/misc.c.o] Error 1
    make[1]: *** [src/slirp/CMakeFiles/Slirp.dir/all] Error 2
    make: *** [all] Error 2

    and Andreas, do you checked my code?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 18, 2015, 04:59:22 pm
    I did not yet have a closer look. I want to finish and release a good networking capable version.
    Not sure what your compiling problem is about. Maybe you find something useful in the internet or check the version of slirp used in WinUAE on differences in this section of code. The problem is abviously related to the function "strdup". I have no experiences with the Windows platform.

    I hope to have something ready for release tomorrow.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 19, 2015, 08:07:44 am
    I'm in the process of writing a short howto for network setup in NeXTstep. Can someone give me a procedure for NeXTstep 0.8?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 19, 2015, 01:35:02 pm
    I made a new release version of Previous. You can load version 0.6 for Mac OS X here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.6a.zip).

    Thanks to neozeed we now have networking support in Previous. Just enabe it in the GUI. But make sure you read the setup guide first. Maybe someone can build for other platforms too (and tell me if there are any changes needed to make it build cross-platform).

    Have fun!

    @gilles: Please update the homepage with the latest status, once you have time for it.

    Update: Replaced with fixed version to aviod SIGPIPE crash.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on April 20, 2015, 02:08:12 am
    Nice job!
    Can confirm working using 32MHz/68040/32MB/NeXTstation Color

    Just a heads up, I did set it up using a standard NeXT Computer configuration on one of the earlier builds, it didn't seem to work setting it up using the NeXTstation to begin with, I don't know if this matters.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 20, 2015, 05:25:30 am
    Quote from: "jasonwoodland"Just a heads up, I did set it up using a standard NeXT Computer configuration on one of the earlier builds, it didn't seem to work setting it up using the NeXTstation to begin with, I don't know if this matters.


    That problem should be fixed now. There was some register missing, which then caused NeXTstep to switch the Ethernet transceiver to loopback mode. That register does not exist in the original NeXT Computer. So that model was not affected.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 20, 2015, 04:46:50 pm
    Does network functionality only work with a subset of machine types?  I tried all 3 types (Computer, Cube, and Station), various CPU speeds, various RAM sizes, and color station -- and I cannot ping 10.0.2.2 in any of them.  I'm sure it's user error here, but I can't figure out what I'm doing wrong now.  I can ping 10.0.2.15, and "ifconfig en0" shows the interface to be up.

    Thanks!

    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 21, 2015, 05:52:32 am
    It should work with all machines (it does for me). Make sure you enabled it in the preferences. Check the setup of your guest system.
    If all that does not help, I'd need the preference file and the your disk image to test it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 21, 2015, 11:33:48 am
    Ah, thanks Andreas.  Part of this was user error: I had 2 versions of Previous on my system and I was accidentally running 0.5.2.  I thought I had replaced 0.5.2, and when I downloaded 0.6 again and ran that binary, I now see the Ethernet section in settings.

    However, when I enable that and then telnet to my NAS, port 22, Previous 0.6 crashes.  Is there anything I can give you that will help debug that?

    EDIT: This is interesting: when I telnet to my iMac (10.0.1.2 port 22), it connects and does not crash.  But when I telnet to my NAS (10.0.1.14 port 22) does it crash.  There may be others, but at least I know that one address works.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 21, 2015, 02:02:42 pm
    Quote from: "eagle"However, when I enable that and then telnet to my NAS, port 22, Previous 0.6 crashes.  Is there anything I can give you that will help debug that?


    When it crashes on your Mac, you will usually get a dialog that asks if you want to see a report. Otherwise a report should be under diagnostic or crash reports in the console. I'd need that report to check what function triggers the crash.
    Previous should generally not crash, but I've built in a few aborts() for unfinished or unexpected things. These intended crashes are usually easy to fix.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 21, 2015, 02:47:28 pm
    I'm not getting a dialog box when it crashes, and I get nothing in ~/Library/Logs/DiagnosticReports.  It appears that I did not disable Crash Reporter on this system:
    [eagle@nest:518:/Users/eagle/Library/Logs/DiagnosticReports]defaults read com.apple.CrashReporter
    {
       LogCrashes = YES;
    }
    [eagle@nest:519:/Users/eagle/Library/Logs/DiagnosticReports]
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 21, 2015, 03:43:23 pm
    This is strange ... maybe NeXTstep shuts down the system for some reason? That would cause a normal quit of Previous and thus not save a diagnostic report. But i never saw NeXTstep doing such things without asking first.

    Unfortunately i can't tell the reason for the crash without a report. This is an excerpt from an example report from my system stored in ~/Library/Logs/DiagnosticReports:
    Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
    0   libsystem_kernel.dylib         0x00007fff930c8866 __pthread_kill + 10
    1   libsystem_pthread.dylib       0x00007fff8f61235c pthread_kill + 92
    2   libsystem_c.dylib             0x00007fff92a9bb1a abort + 125
    3   com.sourceforge.previous       0x0000000100021d58 SCSI_Emulate_Command + 760
    4   com.sourceforge.previous       0x000000010000c9d4 esp_select + 452
    5   com.sourceforge.previous       0x000000010000b997 ESP_Command_Write + 39
    6   com.sourceforge.previous       0x000000010001296e IoMem_bput + 94
    7   com.sourceforge.previous       0x000000010006039b op_117c_31_ff + 123
    8   com.sourceforge.previous       0x00000001001680b1 m68k_run_mmu040 + 673
    9   com.sourceforge.previous       0x0000000100167b7d m68k_go + 413
    10  com.sourceforge.previous       0x0000000100016406 main + 614
    11  com.sourceforge.previous       0x0000000100003574 start + 52
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 21, 2015, 04:45:05 pm
    Andreas, in Console.app, I get the following:

    4/21/15 12:43:26.052 com.apple.launchd.peruser.501[198]: (com.sourceforge.previous.103872[4135]) Exited abnormally: Broken pipe: 13


    Unfortunately that is all I get.  Nothing shows up in ~/Library/Logs/DiagnosticReports.

    In order to cause this crash, I launched Terminal in the NeXT, then typed "telnet 10.0.1.2" and saw "Trying 10.0.1.2..." and then it immediately crashed hard.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 21, 2015, 07:23:00 pm
    eagle, thanks for the investigation. That log entry made it clear. I added a line to avoid crashing through SIGPIPE. I updated the version.

    @everyone: Please re-download Previous 0.6. The zip-files is now Previous_0.6a.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 21, 2015, 07:36:58 pm
    Okay, this is simply amazing!!!!

    My MacBook is connected to my Synology DS415+ NAS via OpenVPN (Viscosity client on the Mac).  I am running Previous 0.6a on that MacBook, and my first test was to telnet to my iMac and Synology SSH ports.  Both of those systems are located at my house, and both of those tests succeeded this time.

    My next test was to NFS mount the NAS in the NeXT, and it succeeded.  I had to niload the hostname into the NetInfo database, and then a command in the format "mount HOSTNAME:SHARE /LOCALDIR" worked just fine.

    All I can say is: WOW WOW WOW WOW

    Thank you, Andreas and others, for your amazing work on this software.

    EDIT: I think I shall take my LocalApps, LocalLibrary, and "Exchange" disk images and convert them to NFS shares on my NAS.  Now that we have network, we can also set up the NeXT to use an LPD print server.  I'll have to refresh my memory on how to do that.  I know it's possible, because I did it, but that was a decade ago or more.

    Again: THANK YOU, ANDREAS!

    -----

    Also, I noticed that the system time is now correct when booting NeXTSTEP 2.1.  In my experience with earlier versions of Previous, system time was only correct for NS 3.3 and later.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 21, 2015, 07:58:24 pm
    I know I keep asking for the world, but is it possible to have a VNC server built into Previous?  It would be great to be able to connect to the console remotely.

    8)
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 22, 2015, 02:32:55 pm
    Does F11 still work to pull up the menu?  I am not seeing that work in Previous 0.6a.  Thanks.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 22, 2015, 03:02:40 pm
    The shortcut for the main menu is F12.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 22, 2015, 03:06:29 pm
    Neither F11 nor F12 does anything on my laptop, running Mavericks.  I have checked my keyboard preferences and confirmed that those are not assigned to another function/application.

    Also, I have confirmed that the crash I emailed you about also happens in OS4.2.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on April 22, 2015, 03:26:21 pm
    I have the same issue with F11 and F12 not doing anything on my Macbook Pro (Retina).

    Would it be possible to make their functionality available on Macs at least through menu items perhaps? that way, the risk of having to overload the keyboard would be significantly reduced.

    Best wishes,

    // Christian
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 22, 2015, 06:50:18 pm
    For those having trouble with F11/F12 not working, the problem is probably that you have an old value in the keyOptions field in the config file.  I was successful by renaming previous.cfg file, then launching Previous.app with no config file, then saving a fresh file.  I then ran diff to see what was different, and noted keyOptions and a few other fields.

    Thanks to Andreas for helping me track that one down.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 22, 2015, 08:30:18 pm
    This problem affects all config files created with the old SDL1 version of Previous. The numeric values for the keys changed with SDL2. Everyone who has this kind of problem should delete the old config file and save a fresh one.

    @cbrunschen: Unfortunately i have no experiences with building a Mac OS X GUI application. But maybe someone else wants to create a native GUI for Previous.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 23, 2015, 06:19:51 am
    Here is a patch for linux previous-linux.diff (https://www.dropbox.com/s/l4byeubufacok2w/previous-linux.diff?dl=1)

    If you don't mind, can I get access on sourceforge page? So I can help Previous with my little skills.
    Thanks andreas and neozeed!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on April 23, 2015, 08:17:03 am
    Excuse me Mominul !

    I made an update of your Wiki-Page about Previous (http://com-emu.meximas.com/doku.php?id=previous) to the new v0.6a version with 3 new pictures from this thread. Why did you remove them again from the page ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 23, 2015, 08:39:35 am
    Many many thanks Kitchen2010! Maybe you have made a mistake. You have changed http://com-emu.pixub.com/doku.php/emulator/previous. Please make changes in http://com-emu.pixub.com(Thanks You are right) not in com-emu.maximas.com(I will delete it soon)

    Many Many Thanks. If you want to add anything please add! We can create a emulator world :wink:
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on April 23, 2015, 06:58:05 pm
    Ah sorry ! I have just seen that you have two wikis. I have used that one in your signature (= the older one). :D
    You should consider to change your signature to your new wiki to avoid those problems in future.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 24, 2015, 05:28:32 am
    Quote from: "Mominul"Here is a patch for linux previous-linux.diff

    I'm afraid I don't understand your patch. Why should "signal(SIGPIPE,SIG_IGN);" be disabled on Linux? It is needed to avoid the crash through SIGPIPE that forum member eagle discovered. All UNIX-like systems are affected, including Linux.

    The source repository belongs to Gilles. So I can't give you access. Access only makes sense with some more advanced skills. The code is quite complex and easy to break.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 24, 2015, 08:02:04 am
    Thanks Andreas for your information. I have updated my patch. I had disabled the signal because the gnu c was throwing error about the signals like this -
    /home/mominul/src/previous-trunk/src/enet_slirp.c: In function 'enet_slirp_start':
    /home/mominul/src/previous-trunk/src/enet_slirp.c:151:9: warning: implicit declaration of function 'signal' [-Wimplicit-function-declaration]
            signal(SIGPIPE, SIG_IGN);
            ^
    /home/mominul/src/previous-trunk/src/enet_slirp.c:151:16: error: 'SIGPIPE' undeclared (first use in this function)
            signal(SIGPIPE, SIG_IGN);
                   ^
    /home/mominul/src/previous-trunk/src/enet_slirp.c:151:16: note: each undeclared identifier is reported only once for each function it appears in
    /home/mominul/src/previous-trunk/src/enet_slirp.c:151:25: error: 'SIG_IGN' undeclared (first use in this function)
            signal(SIGPIPE, SIG_IGN);
                            ^


    But now I have found the real problem. It was because you have not included the signal.h file. After adding it the problems are gone.

    Thanks
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 24, 2015, 08:40:19 am
    Quote from: "andreas_g"Good news! I found the problem. It seems i made a mistake with the loopback mode of the transceiver. Disabling loop back makes things work


    When confronted with something like this, I used a 'magical' timer, since the ROM will do the same thing every time you boot, just start a counter to behave that way when the ROM is running it's test, then after the default count is done, act normal.

    I know.. .HACK HACK HACK HACK......  :lol:
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 24, 2015, 11:27:51 am
    neozeed, thank you for the hint! Luckily I was able to fix the problem without needing a hack. It turned out that loopback mode was implemented correctly. There was a system register missing, which caused the host system to set loopback mode intentionally.

    I don't know if forum member eagle already contacted you. But there seems to be a bug in slirp, function "ip_input" that causes segfaults during large file transfers. Do you have an idea, what might be wrong here?

    @Mominul, thank you, i'll include signals.h.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 24, 2015, 11:55:17 am
    Quote from: "andreas_g"neozeed, thank you for the hint! Luckily I was able to fix the problem without needing a hack. It turned out that loopback mode was implemented correctly. There was a system register missing, which caused the host system to set loopback mode intentionally.

    I don't know if forum member eagle already contacted you. But there seems to be a bug in slirp, function "ip_input" that causes segfaults during large file transfers. Do you have an idea, what might be wrong here?

    @Mominul, thank you, i'll include signals.h.


    Well now that is interesting!

    HE did, and i started a build on windows (mingw) and slirp doesnt work at all, outside of udp and icmp.  I reverted the library back to my 32bit.one and i can telnet out (and in!).

    I can mount my synology nfs just fine.and view directories, but even trying to transfer a zero byte file causes it to lock.  It feels like its working like active mode FTP.

    So ill port in my libpcap stuff so wired hosts can use full networking.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 24, 2015, 01:14:41 pm
    Quote from: "andreas_g"@Mominul, thank you, i'll include signals.h.

    Thanks Andreas! But please include the misc.c stuff also. Without it I can't compile Previous in Linux(Ubuntu, elementaryOS).

    Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 24, 2015, 01:27:00 pm
    Quote from: "neozeed"HE did, and i started a build on windows (mingw) and slirp doesnt work at all, outside of udp and icmp.  I reverted the library back to my 32bit.one and i can telnet out (and in!).

    I can mount my synology nfs just fine.and view directories, but even trying to transfer a zero byte file causes it to lock.  It feels like its working like active mode FTP.

    So ill port in my libpcap stuff so wired hosts can use full networking.


    Let me know if you need anything from me... I'm happy to test any build.

    Also, I noticed that FTP does not work from the NeXT.  I figured it was user error (I never tried enabling FTP on Mavericks before this week), but it was definitely port related.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 24, 2015, 02:50:27 pm
    Quote from: "eagle"
    Quote from: "neozeed"HE did, and i started a build on windows (mingw) and slirp doesnt work at all, outside of udp and icmp.  I reverted the library back to my 32bit.one and i can telnet out (and in!).

    I can mount my synology nfs just fine.and view directories, but even trying to transfer a zero byte file causes it to lock.  It feels like its working like active mode FTP.

    So ill port in my libpcap stuff so wired hosts can use full networking.


    Let me know if you need anything from me... I'm happy to test any build.

    Also, I noticed that FTP does not work from the NeXT.  I figured it was user error (I never tried enabling FTP on Mavericks before this week), but it was definitely port related.


    Its the way active mode ftp works... and it sucks.  but it's just the way it is.

    anyways this is like the 10th attempt at replying to this.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 24, 2015, 03:22:33 pm
    Quote from: "eagle"
    Quote from: "neozeed"HE did, and i started a build on windows (mingw) and slirp doesnt work at all, outside of udp and icmp.  I reverted the library back to my 32bit.one and i can telnet out (and in!).

    I can mount my synology nfs just fine.and view directories, but even trying to transfer a zero byte file causes it to lock.  It feels like its working like active mode FTP.

    So ill port in my libpcap stuff so wired hosts can use full networking.


    Let me know if you need anything from me... I'm happy to test any build.

    Also, I noticed that FTP does not work from the NeXT.  I figured it was user error (I never tried enabling FTP on Mavericks before this week), but it was definitely port related.


    Ok, can you try This build of Previous (https://www.dropbox.com/s/abpxj30rmtj6qle/Previous-399-32bit.7z?dl=0)?  I'm curious to see if it is just as bad or what.  Also I find it works better if you 'kick' the stack first by pinging 10.0.2.2 to get it going... Not sure why.  As a bonus, port 42323 will telnet into your machine!

    As I start to do my pcap patches, it occurs to me I don't know how to read the preferences... so in the meantime, on your wired mac, what ethernet interface is the physical ethernet? en0? en1?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 24, 2015, 04:34:20 pm
    en0 is wired; en1 is wifi.

    Edit: neozeed, that build of 0.5.2 crashes on my system.  The crash report is here: https://dl.dropboxusercontent.com/u/13208710/NeXT/CrashReports/Previous_2015-04-24-125520.crash

    The earlier crash I reported was due to me not having XQuartz installed, and once I installed that, it launches now.  This crash was with NS2.1 (that's all I have on my laptop), and it crashes during the hardware test section of the boot, right after it prints "Enet."
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 25, 2015, 01:08:33 am
    Quote from: "eagle"en0 is wired; en1 is wifi.

    Edit: neozeed, that build of 0.5.2 crashes on my system.  The crash report is here: https://dl.dropboxusercontent.com/u/13208710/NeXT/CrashReports/Previous_2015-04-24-125520.crash

    The earlier crash I reported was due to me not having XQuartz installed, and once I installed that, it launches now.  This crash was with NS2.1 (that's all I have on my laptop), and it crashes during the hardware test section of the boot, right after it prints "Enet."


    well that is strange... I'm on 10.10.3 and it doesn't do that...

    Anyways here is my first attempt at a pcap version (https://www.dropbox.com/s/eh1snwfv0g25gg2/Previous-399-32bit-pcap-en0.7z?dl=0).

    The biggest limitation of this is that the host computer cannot talk to the VM.  but the VM can talk to external devices on your network, like your synology NFS box.

    Also for the slirp thing you ususally have to boot with the ethernet disconnected, then at the firmware boot prompt you can plug it in again.

    Although on my limited testing you don't have to plug and unplug the pcap.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 26, 2015, 08:08:21 am
    What floppy controllers NeXTStation or NeXT Cube use? (Intel 82077AA?)
    On which dma channel it is connected?(optical disk?)
    How many drives ? (1?)

    Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 26, 2015, 08:29:50 am
    Quote from: "Mominul"
    floppy controllers ???
    Thanks!


    I've only used a floppy ONCE on my cube, to install 3.3 because my ROM was too old to boot from CD.  and it was a SCSI floppy drive.  Yes, that is correct, it connected to the SCSI bus.  And all it had on the diskette was the 'boot' program, which then could load up the kernel and everything else from the CD-ROM.

    Afterwards I found out that if you dd the contents of a CD to a hard disk, you can just boot directly from that, bypassing the need for a floppy to install 3.3.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 26, 2015, 10:39:28 am
    Quote from: "neozeed"Anyways here is my first attempt at a pcap version (https://www.dropbox.com/s/eh1snwfv0g25gg2/Previous-399-32bit-pcap-en0.7z?dl=0).

    The biggest limitation of this is that the host computer cannot talk to the VM.  but the VM can talk to external devices on your network, like your synology NFS box.

    Also for the slirp thing you ususally have to boot with the ethernet disconnected, then at the firmware boot prompt you can plug it in again.

    Although on my limited testing you don't have to plug and unplug the pcap.


    Maybe it's a problem on 10.9.5, but this pcap version crashes instantly when the ethernet is connected.  So far I have found nothing related to this in my OS X Console or ~/Library/Logs/DiagnosticReports.

    I did find that I can get farther in the boot process if I leave ethernet disconnected, but then when the NeXT starts looking for network (and hangs when it doesn't find it), Previous crashes immediately when I connect the network at that point.  I mean: F12 -> Ethernet -> Connected -> OK -> OK -> crash.  No discernible delay.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 26, 2015, 11:14:57 am
    Quote from: "eagle"
    Quote from: "neozeed"Anyways here is my first attempt at a pcap version (https://www.dropbox.com/s/eh1snwfv0g25gg2/Previous-399-32bit-pcap-en0.7z?dl=0).

    The biggest limitation of this is that the host computer cannot talk to the VM.  but the VM can talk to external devices on your network, like your synology NFS box.

    Also for the slirp thing you ususally have to boot with the ethernet disconnected, then at the firmware boot prompt you can plug it in again.

    Although on my limited testing you don't have to plug and unplug the pcap.


    Maybe it's a problem on 10.9.5, but this pcap version crashes instantly when the ethernet is connected.  So far I have found nothing related to this in my OS X Console or ~/Library/Logs/DiagnosticReports.

    I did find that I can get farther in the boot process if I leave ethernet disconnected, but then when the NeXT starts looking for network (and hangs when it doesn't find it), Previous crashes immediately when I connect the network at that point.  I mean: F12 -> Ethernet -> Connected -> OK -> OK -> crash.  No discernible delay.


    dont connect the network until it's at the NeXT prompt



    Once it's waiting for you to type in bsd, then you can connect the network interface.

    With the ethernet now connected, it should load the kernel



    and fully boot from there.

    Try running it from a console, maybe there is a hint in the output.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 26, 2015, 12:24:32 pm
    Quote from: "Mominul"What floppy controllers NeXTStation or NeXT Cube use? (Intel 82077AA?)
    On which dma channel it is connected?(optical disk?)
    How many drives ? (1?)

    Thanks!


    Yes, the NeXT machines use Intel 82077AA (only 68030 Cube has no floppy controller). The chip is connected to the SCSI DMA channel. I already have some code to emulate this, but there are severe problems with disk geometry. Seems that ROM and kernel address with different geometries. That means it either fails from ROM monitor or fails on the booted system causing floppy disk image corruption. This is the reason i did not post that code. For now this seems to be impossible to fix.

    ROM uses:
    Capacity  C   H   S
    720K     20  2  36
    1440K     40  2  36
    2880K     80  2  36

    NeXTstep uses:
    Capacity  C   H   S
    720K     80  2   9
    1440K     80  2  18
    2880K     80  2  36
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 26, 2015, 03:53:11 pm
    @andreas Can you give me the code please? Does it is connected with DMA? Can it emulate FDC? But why the disk geometry is changing? NeXTStep is right about the geometries.  ROM is confused about the Cylinder and sector ... but why?

    What things will stay here ? Any clues?

       /* Floppy Controller (82077AA) */
       { 0x02014100, SIZE_BYTE, IoMem_ReadWithoutInterceptionButTrace, IoMem_WriteWithoutInterceptionButTrace },
       { 0x02014101, SIZE_BYTE, IoMem_ReadWithoutInterceptionButTrace, IoMem_WriteWithoutInterceptionButTrace },
       { 0x02014102, SIZE_BYTE, IoMem_ReadWithoutInterceptionButTrace, IoMem_WriteWithoutInterceptionButTrace },
       { 0x02014103, SIZE_BYTE, IoMem_ReadWithoutInterceptionButTrace, IoMem_WriteWithoutInterceptionButTrace },
       { 0x02014104, SIZE_BYTE, FDD_Main_Status_Read, IoMem_WriteWithoutInterceptionButTrace },
       { 0x02014105, SIZE_BYTE, IoMem_ReadWithoutInterceptionButTrace, IoMem_WriteWithoutInterceptionButTrace },
       { 0x02014106, SIZE_BYTE, IoMem_ReadWithoutInterceptionButTrace, IoMem_WriteWithoutInterceptionButTrace },
       { 0x02014107, SIZE_BYTE, IoMem_ReadWithoutInterceptionButTrace, IoMem_WriteWithoutInterceptionButTrace },

       /* Floppy External Control */
       { 0x02014108, SIZE_BYTE, IoMem_ReadWithoutInterceptionButTrace, IoMem_WriteWithoutInterceptionButTrace },
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 26, 2015, 05:27:18 pm
    Here (https://dl.dropboxusercontent.com/u/44703754/msvc/floppy_patch1_26-04-2015.zip) you can load the floppy patch, including the new source files. I think somehow both are correct, but the emulation is not. Very complicated stuff.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 27, 2015, 11:36:12 am
    Quote from: "neozeed"dont connect the network until it's at the NeXT prompt



    Once it's waiting for you to type in bsd, then you can connect the network interface.

    With the ethernet now connected, it should load the kernel



    and fully boot from there.

    Try running it from a console, maybe there is a hint in the output.


    I was actually trying to connect network after that.  I have my Previous configs set to boot to disk not to ROM Monitor.  I start with network disconnected, then sometime during the boot process (after the "bsd" command has been run by the ROM Monitor) I connect network, and it immediately crashes.

    I'll try running it a different way and see if I get different results, and I'll let you know.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 28, 2015, 05:36:06 pm
    @Andreas I have updated my sources with rev 401. But your
    check_function_exists(strdup HAVE_STRDUP)
    Doesn't work for me. I am getting the errors about strdup again.

    Thanks
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 28, 2015, 07:07:20 pm
    Are you using Cmake for building? I don't like to add too much preprocessor stuff to the code. That makes it complicated.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 29, 2015, 04:27:50 am
    Yes I am using cmake for building

    Thanks
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 29, 2015, 08:49:10 am
    I'm curious if the problem disappears when you add "#cmakedefine HAVE_STRDUP 1" in cmake/config-cmake.h
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on April 29, 2015, 01:38:29 pm
    Yes, If I add "#cmakedefine HAVE_STRDUP 1" in cmake/config-cmake.h then no error occurs!

    Thanks
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 29, 2015, 05:13:10 pm
    I made a new release version 0.6.1. The GUI for selecting SCSI devices is redesigned and support for SCSI floppy drives is improved. You can load the new version here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.6.1.zip).
    Title: What Needs to be done for a NeXT Emulator
    Post by: scarecrow on April 29, 2015, 10:48:03 pm
    This happened with latest version (0.6.1) OS X:

    "Previous" can't be opened because the identity of the developer cannot be confirmed.

    0.6 works
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 30, 2015, 12:01:44 am
    Quote from: "scarecrow"This happened with latest version (0.6.1) OS X:

    "Previous" can't be opened because the identity of the developer cannot be confirmed.

    Just right-click on Previous.app and select "Open."  Then, confirm your desire to open the app.
    Title: What Needs to be done for a NeXT Emulator
    Post by: scarecrow on April 30, 2015, 12:04:11 am
    Ok thanks :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 30, 2015, 12:25:33 am
    Quote from: "andreas_g"I made a new release version 0.6.1. The GUI for selecting SCSI devices is redesigned and support for SCSI floppy drives is improved. You can load the new version here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.6.1.zip).


    Andreas, in my quick testing, this one is working for NFS to my NAS.  Wow, what an improvement!  I have launched many apps from the NAS, but have not otherwise done extensive testing.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 30, 2015, 05:57:10 am
    @scarecrow: I didn't care about codesigning yet. But maybe it's time to find out how to do that.

    @eagle: This is very strange. I have not made any changes to Ethernet, except the definition for HAVE_STRDUP and including signals.h. So this is either some kind of coincidence or Slirp's strdup was causing the problem. Please check if the crash is permanently gone.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 01, 2015, 02:38:21 am
    Quote from: "andreas_g"@eagle: This is very strange. I have not made any changes to Ethernet, except the definition for HAVE_STRDUP and including signals.h. So this is either some kind of coincidence or Slirp's strdup was causing the problem. Please check if the crash is permanently gone.

    Hi Andreas.  The crash is not gone, but it did get farther.  I ran the same command, but this time I was copying from an NFS mount to an NFS mount (I have already removed the LocalApps disk image from my Previous VMs).  I changed into my NFS directory and did this:

    mkdir COPY
    tar -cvf - LocalApps | (cd COPY ; tar -xvf -)

    When I do that, it definitely gets farther than it did before, but it still crashes.

    And yes, for those who wonder, I do know that I put a -v on both of those tar commands. :)

    Edit: In further testing, I see that this current version (0.6.1) really does work very well, and while my "tar" test above does cause it to crash, normal usage does not.  Even so, something is broken about the way I am doing this.  I am NFS mounting /LocalApps and /LocalLibrary, and I can double-click apps (both bundles and standalone executables) to run them, but I cannot double-click document bundles -- that is, I cannot double-click a .wn bundle/file or a .imp bundle: those show up as text documents, and double-clicking on them produces an error that says the bundle/document is broken.  I have confirmed that they are all owned by "me" and read/write for "me," so I know that's not the problem.

    I have not copied the .wn and .imp bundles to the local drive, so I should do that next.  It's possible that those document bundles are in fact broken.

    Edit again: The only other oddity I have noticed is that I now get an error message in the console saying that the system is not connected to a network, even though Ethernet is connected in Previous settings.  I have to press "c" for it to continue the boot.

    Edit 3: I was finally able to get WriteNow and Improv to register as apps that can handle .wn and .imp documents/bundles, so now those work, even on the NFS mount.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on May 04, 2015, 06:10:54 am
    I am again having the strdup error. "#cmakedefine HAVE_STRDUP 1" defined. But something is wrong.....

    edit: I have found the bug. I have to define "#define HAVE_STRDUP 1" in "/BUILD_DIRECTORY/config.h" file. But we have to do it with cmake ...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 04, 2015, 04:58:24 pm
    neozeed, are you still working on adding PCAP to Previous? I made a quick test with the code you posted a while ago. It immediately exits from line 214:
    Starting Ethernet Transmitter/Receiver
    Pcap version [libpcap version 1.3.0 - Apple version 41]
    ethernet.c: pcap_open_live error on lo0!

    I guess this is the same problem that eagle experienced.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 16, 2015, 12:26:47 pm
    Although interest in this seems to be quite low at the moment, i have made quite a lot of progress on Previous recently. There is now a working floppy drive! Also there are changes that make DMA more reliable. Timings should be slightly better too.

    Everything has progressed quite far. I think the only missing "must have" feature now is sound! And of course networking would need some more improvement (neozeed?).
    It seems Previous runs quite stable all in all. I have not experienced any panics, disk image corruption or similar bad behavior using the last releases.

    You can download Previous v0.7 for Mac OS X 10.6 and later here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.7c.zip).

    Update: Linking to internal SDL2 framework fixed (hopefully). Compatibility with older Mac OS X releases fixed.
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on May 16, 2015, 12:53:06 pm
    Quote from: "andreas_g"Although interest in this seems to be quite low at the moment
    There is interest.
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on May 16, 2015, 01:00:46 pm
    Quote from: "andreas_g"You can download Previous v0.7 here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.7.zip).
    It is crashing for me with "dyld: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2". Do I need to install SDL2 separately?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 16, 2015, 01:32:24 pm
    Quote from: "tomaz"
    Quote from: "andreas_g"You can download Previous v0.7 here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.7.zip).
    It is crashing for me with "dyld: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2". Do I need to install SDL2 separately?

    Thank you for the hint! Obviously i forgot to change my linking command to SDL2. Should be fixed now. Please re-download.
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on May 16, 2015, 02:25:34 pm
    Quote from: "andreas_g"Thank you for the hint! Obviously i forgot to change my linking command to SDL2. Should be fixed now. Please re-download.
    Thanks - I am now getting a crash with "dyld: Library not loaded: /usr/lib/libedit.3.dylib"
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 16, 2015, 02:41:36 pm
    Quote from: "tomaz"
    Quote from: "andreas_g"Thank you for the hint! Obviously i forgot to change my linking command to SDL2. Should be fixed now. Please re-download.
    Thanks - I am now getting a crash with "dyld: Library not loaded: /usr/lib/libedit.3.dylib"

    Should be fixed now too. I guess you are on a slightly older version of Mac OS X?
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on May 16, 2015, 02:48:12 pm
    Quote from: "andreas_g"Although interest in this seems to be quite low at the moment, i have made quite a lot of progress on Previous recently. There is now a working floppy drive! Also there are changes that make DMA more reliable. Timings should be slightly better too.

    Everything has progressed quite far. I think the only missing "must have" feature now is sound! And of course networking would need some more improvement (neozeed?).
    It seems Previous runs quite stable all in all. I have not experienced any panics, disk image corruption or similar bad behavior using the last releases.

    You can download Previous v0.7 here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.7b.zip).

    Update: Linking to internal SDL2 framework fixed. Compatibility with older Mac OS X releases fixed.


    sorry work has been hell.. and personal life has kept me quite busy... my 5month old is quite the drama llama.

    I still want to redo the pcap thing, it works on my test, but Im kind of dismayed about the real world failure....   :oops:
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 16, 2015, 03:27:34 pm
    Quote from: "neozeed"I still want to redo the pcap thing,

    Great! If it already works on your machine then hopefully we're not too far away. If i can do something to help with debugging, please just tell me.
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on May 16, 2015, 03:36:21 pm
    Quote from: "andreas_g"Should be fixed now too. I guess you are on a slightly older version of Mac OS X?
    "dyld: Library not loaded: @loader_path/../Frameworks/SDL2.framework/Versions/A/SDL2"

    I am on 10.6.8. Don't like what Apple has done with later versions of Mac OS X.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 16, 2015, 04:17:01 pm
    Quote from: "tomaz""dyld: Library not loaded: @loader_path/../Frameworks/SDL2.framework/Versions/A/SDL2"

    OK, my fault. Please try again. If it still does not work please PM me your mail address.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 17, 2015, 12:56:24 pm
    Thanks, Andreas. I'll give it another go and see how it goes.  I gave a quick try last night and NS 2.1 wouldn't automount my NAS.  I could telnet to it, so I know the network was working, but it wouldn't mount for some reason.  I even followed the instructions I wrote here (http://www.nextcomputers.org/forums/viewtopic.php?t=3598), but they didn't work for me last night in NS 2.1.  Maybe I'll have more time later this afternoon to play with it again.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on May 18, 2015, 08:06:18 pm
    Quote from: "tomaz"
    Quote from: "andreas_g"Although interest in this seems to be quite low at the moment
    There is interest.

    There is definitely interest!

    // Christian
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 19, 2015, 03:17:30 am
    Andreas, I'm using your version 0.7c, and so far I am unable to get it to crash.  I have NS 2.1 automounting a share on my NAS, and it works with everything I have thrown at it so far.

    Well, as I was typing this, it just crashed on me, but that was a very specific case, so I will test again.  I had mounted my NAS at /Net/HOSTNAME/volume1/nextstep, and was trying to build bash in a subdirectory on that NFS mount.  That probably wasn't a smart thing to do.

    Anyway, it ran all the apps I threw at it, via NFS, without crashing, so I think that was good.  Sometime in the next few days, I'll copy the bash source locally and try recompiling.

    I think you might be right: with network now working as well as it does, sound might be the only missing must-have feature.

    Amazing work, gentlemen!  Thank you so much.

    Edited to add: I'll try my other NS/OS versions, and see about getting networking working in those.  And, the NFS automounter instructions I wrote up did work, but I might have forgotten a few steps when I wrote them up, so I'll update them: I think the IP addresses for both the local host and the NFS server must be in NetInfo, and the fstab entry must be in /etc/fstab and NetInfo.  With all that, it works fine.  Very cool that NeXT included an automounter!

    Edit 2: Somehow Previous got into a state where everything I typed was in ALL CAPS.  I tried toggling the caps lock key, and I tried touching the shift, control, alt/option, and command keys, and none of those was able to reset the capitals.  I did notice that if I held command while pressing a key, it entered a lowercase key.  Might this be a setting of some sort?  Or a bug?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 19, 2015, 10:52:35 am
    Quote from: "eagle"Somehow Previous got into a state where everything I typed was in ALL CAPS.  I tried toggling the caps lock key, and I tried touching the shift, control, alt/option, and command keys, and none of those was able to reset the capitals.  I did notice that if I held command while pressing a key, it entered a lowercase key.  Might this be a setting of some sort?  Or a bug?

    This keeps happening, so it must be a bug of some sort.  I double-checked my config file by removing "previous.cfg" and then launching Previous and saving a new config file.  I then ran diff between my original config file and previous.cfg, and the only differences I see are legitimate: things like RAM size, CPU speed, and disk images.

    I do start with Ethernet connected, and maybe that's still a problem for now.

    Any thoughts about this one?

    Edit: I have been taking screenshots on my Mac, with cmd-shift-3.  Maybe that is causing some sort of problem. I'll reboot Previous and do everything else I did, but skip the screenshot.

    Edit 2: Yup, if I don't take screenshots, it doesn't get into that CAPS ONLY mode.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 19, 2015, 01:08:28 pm
    Glad to see that Ethernet is not broken in v0.7! Do you experience significantly improved stability for networking compared to 0.6?

    Just to be sure: When you talk about crashes, do you mean the guest system crashes or the emulator crashes?

    I remember that I also experienced that caps problem. But I am not sure what is the cause for that. It is either some bug in the modifier key translation of Previous or the shortcut for taking screenshots (or parts of it) overlaps with a shortcut from NeXTstep.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 19, 2015, 03:03:24 pm
    Quote from: "andreas_g"Glad to see that Ethernet is not broken in v0.7! Do you experience significantly improved stability for networking compared to 0.6?

    It does seem to work much better than 0.6, yes.

    QuoteJust to be sure: When you talk about crashes, do you mean the guest system crashes or the emulator crashes?

    I tried it again, this time on my MBP.  My MB is a Core 2 Duo with 2GB RAM, and my MBP is a quad-core i7 with 16GB RAM. :)  MUCH faster.  Anyway, on the MBP, I saw that it is the guest OS that crashes, and I was able to get a screenshot of it.  I'll redo this, with my Terminal window in a different location, so that we can see which test makes it crash.  I was running "./configure" inside the bash source directory.

    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 19, 2015, 03:21:45 pm
    Well, that is definitely an intermittent problem.  I have run configure two more times, and while it doesn't finish (it runs into a Unix problem), it also doesn't crash the guest or Previous.

    Just after running "checking POSIX termios... no" it says "./configure: test: argument expected"

    I guess I'm not going to compile bash today. :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Hialmar on May 19, 2015, 07:27:30 pm
    There is a lot of interest in your emulator for sure :)
    Thanks a lot for all your time !

    The first time I started the 0.7 I had a guest crash and it rebooted ok. Maybe there was something left from the 0.6 that caused the problem.

    The network doesn't work completely for me but it was the same with the 0.6.

    I can ping the router (10.0.2.2) but can't ping the DNS (10.0.2.3), I get a "sendto: Network is down" error.

    I also have some problems with the Caps Lock from time to time but hitting the caps lock key twice returns to normal. I have a french keyboard and I always have problems with SDL apps on OS X due to that. So it may be that.

    Again thanks a lot for this wonderful emulator.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 25, 2015, 10:03:43 am
    I'm glad to hear there is still interest! So i made some more progress and added sound.

    You can load Previous v0.8 for Mac OS X v10.6 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.8.zip).

    Please note that quite a lot of sounds won't work because of missing DSP. But all others should be OK.

    So what will be next? I think we reached a state where we can think about releasing a first final version. My plan would be to try improving the keyboard input and then release v0.9. I hope neozeed can also improve the networking until then. If there are no severe bugs discovered for some time, i'd make it Previous 1.0.

    Things that will be missing from 1.0: DSP, Turbo, NeXTbus, Serial port, Printer and Microphone.

    @hialmar:
    It is strange that networking does not work for you. Did you try setting up a fresh system and configure networking with the "howto" that comes with Previous?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 25, 2015, 11:55:38 am
    Quote from: "andreas_g"I'm glad to hear there is still interest! So i made some more progress and added sound.


    Wow, Andreas, this is amazing!

    In my testing, system beeps work, but that's all I have found to work.  Of course the MIDI sounds don't work, because those require DSP.

    However, I expected the .snd files in /usr/lib/NextPrinter to work, but they don't.  I also expected the email Welcome attachment (SJ.vox) to work, but it doesn't play either.  These .snd and .vox files don't complain, they just don't play.  Do you know if SoundPlayer uses the DSP?

    I'm testing in NS2.1 on a color station with 32MB RAM.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 25, 2015, 01:01:15 pm
    Quote from: "eagle"However, I expected the .snd files in /usr/lib/NextPrinter to work, but they don't.  I also expected the email Welcome attachment (SJ.vox) to work, but it doesn't play either.  These .snd and .vox files don't complain, they just don't play.  Do you know if SoundPlayer uses the DSP?

    I just tested and unfortunately i see lots of DSP calls with these .snd files and the .vox file. SoundPlayer does not always use DSP. It depends on the format of the audio data inside the .snd file. For example the files in NextLibrary/Sounds play without DSP.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 25, 2015, 07:11:43 pm
    Hi Andreas.

    I've been looking at mouse issues with VMware ESXi and Fusion, and I'm wondering if it is possible to interface more completely with NeXTSTEP's mouse driver, or if it would be possible to write a mouse driver for NeXTSTEP that would get absolute locations from Previous, and locate the mouse pointer accordingly.

    I seem to recall asking about that before, but I have spent a while searching the forums and I don't see the original discussion about it.

    Edit: Also, while I'm asking for everything ... :) ... would it be possible to trap OS key sequences?  If I press cmd-Q in OS X, both Previous and the app inside Previous get that cmd-Q: the NeXT app quits, and Previous gives me the "quit" dialog.  If I press escape in the Previous "quit" dialog, Previous does not quit, and only the NeXT app quits.  I know that it is possible in OS X to ignore key sequences (VNC clients typically do this), but I'm not sure if SDL2 supports it.

    Thanks.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 26, 2015, 07:04:55 am
    eagle, I don't think that it is possible to interface with the mouse driver directly. Also I don't think there is a way to write such a driver for the emulated Black Hardware.

    Keyboard input is quite bad at the moment. I'm trying to find a better way, but everything is somehow restricted by the way SDL handles the keys. From what I know, it is not possible to trap host shortcuts using SDL2. Interference between host and guest and emulator application shortcuts and the handling of the modifier keys are the main issues for keyboard emulation. Without that it would be quite easy.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Hialmar on May 26, 2015, 08:10:45 pm
    Quote from: "andreas_g"@hialmar:
    It is strange that networking does not work for you. Did you try setting up a fresh system and configure networking with the "howto" that comes with Previous?


    Thanks for your answer andreas_g.

    I used the disk image found on winworldpc.com and followed the howto.

    What is strange is that I can ping the router but not the DNS. Maybe it's a problem on my Mac. Do I need to setup something on the host ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 26, 2015, 08:15:33 pm
    Andreas, I meant to tell you that on the most recent build, the networking is working very well for me.  I have not had it crash once, and as you know I am using the automounter to NFS mount my NAS.  /LocalApps and /LocalLibrary are links into /Net/HOSTNAME/volume1/nextstep, and they work 100%.

    I still wish for a real host on the network, but I am not going to complain if this is all we ever get. :)

    Edit: I have only been using NeXTSTEP 2.1 in recent testing.  But, I'm sure that others work just as well.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 27, 2015, 05:37:52 am
    @hialmar:
    You do not have to configure anything on the host. At the moment I have no idea what might cause your problem. Sorry for that.

    @eagle:
    Glad to hear that the networking crash is gone. I think there was a little mistake with a mutex.

    btw a question to everyone: Do I need to lock using mutex just to read a variable (C)? Example:
    Two threads running. Thread one is writing packets to a queue. This process includes incrementing a counter, that represents the actual size of the queue. Mutex is locked while doing this.
    Thread two periodically checks the size of the queue by reading the counter. Do I need to lock for reading that counter? Theoretically thread one might put a packet on the queue and increment the counter just at the time the other thread reads it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Hialmar on May 27, 2015, 06:33:17 am
    I will try with NextStep 3.2. I used the 3.3 on the current setting IIRC.

    About the mutex, if you use a 32 bit variable you are safe on a 32 bit or 64 bit system. If you use a 64 bit variable it will only be safe on a 64 bit system.
    However, please note that the fact that you increment the counter after pushing a message doesn't mean that the actual increment will happen after the push. Your compiler might re-order instructions.

    Edit: all the HD images, and some CD images too, disappeared from Winworld :( I have found a 3.1 CD so I will generate a new system with that.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on May 27, 2015, 08:36:19 am
    Quote from: "Hialmar"all the HD images, and some CD images too, disappeared from Winworld :( I have found a 3.1 CD so I will generate a new system with that.


    AFAIK the images are still available at the place where they came from initially ->
    http://www.nextcomputers.org/forums/viewtopic.php?t=3406&start=17
    Title: What Needs to be done for a NeXT Emulator
    Post by: Hialmar on May 27, 2015, 09:15:59 am
    Ah cool. Thanks for the info.
    Apparently it's only temporary on Winworld but it's good to know that they are on mega.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 28, 2015, 12:50:40 am
    Hi Andreas.  I have found a reproducible crash in 0.8.  It happens every time I do this.

    The crash report is here (https://dl.dropboxusercontent.com/u/13208710/NeXT/CrashReports/Previous_2015-05-27-204537.crash).

    Here's what I have: I have a color NeXTstation with 32MB RAM.  I have 2 SCSI disks attached, and an NFS automount.  I am trying to copy files off of the second disk image onto the NFS mount, and it crashes every time.  To do the copy, I run this as root:

    cd /Exchange
    tar -cf - NS* | ( cd /Net/*/*/*/Ex* ; tar -xf - )


    It copies at least some part of the first file or so, then it crashes.  Hopefully that crash report is useful.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 28, 2015, 05:55:54 am
    Thanks for the report. This looks like another SLIRP crash. I can't debug this. I still hope neozeed can make PCAP work with Previous.

    In the meantime I have a question to everyone:
    I'll soon work on the shortcuts. I'm looking for a good shortcut key combination with modifier keys. The main problems are conflicts between host, guest and application. For example:
    Using command as modifier causes conflicts with the host system and the application (cmd-q = quit, cmd-m = minimize, etc). Using alt causes conflicts when trying to type special characters inside the guest.

    So I was thinking about this combination:
    control+alt+x (where x is some alpha key, control is same as strg)

    I think this combination won't cause many conflicts. What do you think?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on May 28, 2015, 07:37:40 am
    Quote from: "andreas_g"I'm glad to hear there is still interest! So i made some more progress and added sound.
    Things that will be missing from 1.0: DSP, Turbo, NeXTbus, Serial port, Printer and Microphone.


    Hey andreas_g !

    I am very glad that you found some time to pick up development of the Previous emulator again ! You made huge advances the last 2 months.

    When you decide to implement full sound support (and modem capability support too) for the 68k NeXTcube/station computers, you need a working emulation of the Motorola 56001 DSP. There are already some emulation cores available of it:
    • Hatari emulator (which you used to create Previous, maybe the simpler approach to try first):
      - Atari Falcon emulation has also a 56k DSP core emulation that interfaces with the M68030 cpu core emulation
      - but 56k DSP core emulation is still experimental and under development, so I do not know how complete it is
      - link to sourcecode: "http://hg.tuxfamily.org/mercurialroot/hatari/hatari/file/bb90e3ca7750/src/falcon"
    • MAME/MESS emulator (it got recently open-sourced to BSD-3 clause and has more complete emulation of cpu and dsp cores)
      - needs probably some interfacing code to core
      - seems to be more complete than Hatari's emulation, so it might be the better way to go to achieve full emulation of the 56k DSP
      - link to sourcecode: "https://github.com/mamedev/mame/tree/bcd0656824540c60a8c24d023d10e19e2f60e795/src/emu/cpu/dsp56k"
    Title: same networking problem as Hialmar
    Post by: bkmoore on May 28, 2015, 08:20:45 pm
    Andreas, first of all much thanks to you, gilles and all the others for your heroic work on the emulator project.  :D

    I have compiled 0.7 (0.2) on my Macbook Pro running 10.10.3 and have had exactly the same network problem as Hialmar. I can ping 10.0.2.2 but cannot ping 10.0.2.3.

    ping:  wrote 10.0.2.3 64 chars, ret=-1
    sendto: Network is down

    I assumed I did something wrong, either in compiling or in the configuration. I am running NS 3.3 clean install without any patches. Maybe it has something to do with version 3.3?

    Normaly I just lurk and wouldn't have written, except see that someone else has the same problem. So maybe it's not just me.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 28, 2015, 08:45:05 pm
    @kitchen2000: Thank you for the hints! DSP is not a goal for 1.0, but maybe i'll have a look later. But if it does not work out of the box, then it might be too time consuming to get it to work.

    @bkmoore: Thank you too for the problem report. I guess it might not be a configuration specific problem, if more users have the same problem. I do not have that problem using 3.3. In fact i tested all versions from 1.0 to 3.3 and all can access the internet. At the moment i have no idea what the problem might be. If i could reproduce it, i might be able to fix it. Maybe we can find similarities between your host setup (hardware, software) that might point us to the problem. My machine is an iMac from 2009 running 10.9.5.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Hialmar on May 29, 2015, 07:32:56 am
    Good to know that I'm not alone ;)
    My computer is a Mac Mini from 2010 running 10.9.5 as well.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Mominul on May 29, 2015, 08:27:25 am
    At first Thank you Andreas for your work on Previous. You have worked very hard for Previous. As previously gilles said that he has been very busy. So he is unable to update the home page. The homepage is now outdated...
    Quote from: "Kitchen2010"... There are already some emulation cores available of it:
    • Hatari emulator (which you used to create Previous, maybe the simpler approach to try first):
      - Atari Falcon emulation has also a 56k DSP core emulation that interfaces with the M68030 cpu core emulation
      - but 56k DSP core emulation is still experimental and under development, so I do not know how complete it is
      - link to sourcecode: "http://hg.tuxfamily.org/mercurialroot/hatari/hatari/file/bb90e3ca7750/src/falcon"


    As I know DSP in Hatari is dummy or not complete.
    And porting MESS DSP in Previous will be somewhat hard.
    Maybe Andreas added a dummy thing dsp.c (https://sourceforge.net/p/previous/code/HEAD/tree/branches/branch_mmu/src/dsp.c)
    Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 29, 2015, 06:09:18 pm
    oops, i just noticed that I also can't ping 10.0.2.3!

    Anyway i can connect to internet pages most times. But sporadically it fails to lookup some host. Maybe this is some SLIRP regression? Have you tried to open web pages? If it fails, re-try with another page.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 30, 2015, 10:04:47 am
    Finally i think the keyboard mapping should be OK. So i made a new release. You can download Previous v0.9 for Mac OS X v10.6 an later here (https://dl.dropboxusercontent.com/u/44703754/Previous_0.9.zip).

    There are now keyboard preferences. If you had problems with key mapping then select the "Scancode" option. Make shure you select your language keyboard layout in NeXTstep system preferences (2.0 and later support that). The mapping then should be quite accurate.

    There are remaining issues with overlapping host and guest shortcuts. I'd need someone with Mac OS X GUI and SDL skills to fix that.

    What's next? I do not want to implement any new features for 1.0. So please report all bugs you find, but no feature requests for now. I'll try to fix as many bugs that i can and then release 1.0.

    @neozeed: Any news on your work on PCAP?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 30, 2015, 12:47:06 pm
    Hey, wow, now with 0.9, the POST issues an audible system beep!  I didn't notice that with 0.8.
    Title: Newbie Question
    Post by: bkmoore on May 30, 2015, 02:28:37 pm
    Thanks a lot for Version 0.9. And with sound too!!!

    I have a newbie question. How do I access the VM from my host computer so that I can transfer files? I normally use Kermit and Telnet to access virtual machines and transfer files. From the terminal on my host computer, I tried:

    telnet localhost 42323

    but that doesn't seem to work for me.
    Title: Re: Newbie Question
    Post by: eagle on May 30, 2015, 07:23:17 pm
    Quote from: "bkmoore"Thanks a lot for Version 0.9. And with sound too!!!

    I have a newbie question. How do I access the VM from my host computer so that I can transfer files? I normally use Kermit and Telnet to access virtual machines and transfer files. From the terminal on my host computer, I tried:

    telnet localhost 42323

    but that doesn't seem to work for me.


    There are two built-in ways to transfer files: NFS and FTP.  I wrote up a howto for using the NFS automounter: http://www.nextcomputers.org/forums/viewtopic.php?t=3598

    You can also use static NFS mounting of course.

    If FTP is a better solution for you, download GatorFTP (https://ftp.nice.ch/pub/next/connectivity/filetransfer/) and get that into your VM.

    There is a third way to get data into your VM, but you can't get data out of it: you can create a CD image and then attach that as a SCSI CD.

    I have personally chosen to set up the NFS automounter: it's easy, and it is just about completely reliable at this point.

    You'll need to initiate these connections from the NeXT.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 31, 2015, 03:50:13 am
    Quote from: "andreas_g"What's next? I do not want to implement any new features for 1.0. So please report all bugs you find, but no feature requests for now. I'll try to fix as many bugs that i can and then release 1.0.

    @neozeed: Any news on your work on PCAP?


    The only issue I'm seeing relates to the network: if I copy any file from the NeXT to the NFS server, Previous crashes.

    And, I find this amusing: tonight I booted Previous, and the POST failed with error 91. :)

    Edit: Andreas, I have noticed recently that Previous causes my Mac's display to not go to sleep.  I'm not sure if that is a bug or if it has been that way for a long time and I never noticed.  I know that apps can set something to prevent that (DVD Player does this), so I wonder if there's something in Previous that can be set to not cause that.  Anyway, like I said, I'm not sure if that is a bug report or a feature request.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 31, 2015, 04:26:05 pm
    eagle, it is "normal" that the POT sometimes failes with error code 91. This means the RTC (real time clock) didn't tick after waiting one second. This is caused by inaccurate timings and is non-fatal. It's listed as known issue in the readme.

    For the sleep issue. I don't know the criteria that Mac OS X uses to decide if it can put the display to sleep. Previous causes quite a lot of CPU activity, even if the guest OS is idle. Maybe that prevents the display from going to sleep. Although i didn't test it, i think that this is not a new issue. Does it still happen, when you pause the emulation or minimize the window?
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 31, 2015, 06:20:11 pm
    Quote from: "andreas_g"For the sleep issue. I don't know the criteria that Mac OS X uses to decide if it can put the display to sleep. Previous causes quite a lot of CPU activity, even if the guest OS is idle. Maybe that prevents the display from going to sleep. Although i didn't test it, i think that this is not a new issue. Does it still happen, when you pause the emulation or minimize the window?


    It doesn't seem to sleep when I pause the emulator, and this is probably another artifact of using SDL.  Oh well...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 01, 2015, 05:43:48 am
    I'll add this to the list of known issues. In this stage of development it would be great to have someone who is used to SDL2 and interfacing it with Linux, Windows and Mac OS X.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jarehart on June 04, 2015, 06:57:24 am
    Hi everyone,

    First, huge thanks to everyone who has worked on Previous!

    With the HAVE_STRDUP fix, I have been able to build a 32-bit binary of r442 (from svn checkout) on Debian Testing (stretch/amd64). I have booted to the ROM monitor successfully and will be fetching install images to test further. I have not yet tried a 64-bit build, but can do so.

    -Jonathan
    Title: Getting files into (and out of) Previous: ftp
    Post by: dnwills on June 06, 2015, 04:00:34 pm
    Quote from: "eagle"There are two built-in ways to transfer files: NFS and FTP.  I wrote up a howto for using the NFS automounter: http://www.nextcomputers.org/forums/viewtopic.php?t=3598

    You can also use static NFS mounting of course.

    If FTP is a better solution for you, download GatorFTP (https://ftp.nice.ch/pub/next/connectivity/filetransfer/) and get that into your VM.

    There is a third way to get data into your VM, but you can't get data out of it: you can create a CD image and then attach that as a SCSI CD.

    I have personally chosen to set up the NFS automounter: it's easy, and it is just about completely reliable at this point.

    You'll need to initiate these connections from the NeXT.

    I'm really, really appreciative of the work you guys have done!

    I'm wondering about all three methods of getting files into (and ultimately out of) the Previous emulator mentioned above, but I'll split this into three parts. This part is about ftp.

    I'm running the following setup:

     Mid 2011 mini
     OS X 10.10.3 Yosemite
     Previous 0.9
     NeXTstation 68040 33 MHz
     NeXTstep 3.3

    My ethernet setup is exactly as described in networking.howto.txt for 0.9.

    Success with ethernet is mixed:

    1) Bootup does not complain about ethernet being unavailable or not connected.

    2) I can ping 10.0.2.2 and 10.0.2.15 from within Previous.

    3) When I ping from Previous to the host computer (manual ip 192.168.1.23), or to an old pismo running OS X 10.4.11 Tiger (manual ip 192.168.1.20), I get ping messages "sendto: Network is down".

    4) Here's a transcript of telnet and ftp attempts in Previous:
    ----------
    next> su
    next: 1# telnet 192.168.1.23
    Trying 192.168.1.23... Connection refused
    next: 2# ftp 192.168.1.23
    ftp: connect: Connection refused
    ftp> quit
    next: 3# telnet 192.168.1.20
    Trying 192.168.1.20... Connection refused
    next: 4# ftp 192.168.1.20
    Connected to 192.168.1.20
    220 unknown0030657e002c.att.net FTP server (tnftpd 20061217) ready
    Name (192.168.1.20:me): dnwills
    331 Password required for dnwills
    Password:
    230-
       Welcome to Darwin!
    230 User dnwills logged in
    ftp> ls
    500 Illegal PORT command rejected
    425 Can't build data connection: Connection refused
    ftp> quit
    221-
       Data traffic for this session was 0 bytes in 0 files.
       Total traffic for this session was 381 bytes in 1 transfer.
    221 Thank you for using the FTP service on unknown0030657e002c.att.net.
    next: 5#
    ----------

    That ftp and telnet should fail on the Yosemite machine is not surprising -- Yosemite accepts only ssh and sftp.

    The failure of ftp on the Tiger machine is not due to Tiger, because ftp from Yosemite to the Tiger machine works perfectly.  The Tiger machine of course cannot ftp to the Yosemite machine.  Neither Tiger nor Yosemite can telnet to the other.

    Am I doing something wrong, or is ftp file transfer not an option at the moment?

    -- David
    Title: Getting files into (and out of) Previous: nfs
    Post by: dnwills on June 06, 2015, 04:52:56 pm
    This part is about nfs.
    Quote from: "eagle"Sample fstab entry:
    HOSTNAME:/mount /Net nfs rw,net 0 0
    With that fstab entry, the automounter mounts at /Net/HOSTNAME/mount.  This directory can of course be accessed either via Terminal or GUI.


    I tried the scheme above with the following steps:

    1) Added two computers with NetInfoManager under machines:
    Key                 Value
    name                dirac
    ip_address       192.168.1.23
    serves              ./local

    name                jost
    ip_address       192.168.1.20
    serves              ./local

    I hope the serves field is correct.  Note that dirac is my mini Yosemite machine, and jost is my pismo Tiger machine.

    2) Added these lines (not at the same time) to /etc/fstab:
    dirac:/usr/local /Net nfs rw,net 0 0
    jost:/usr/local /Net nfs rw,net 0 0

    The result in both cases upon rebooting Previous was that /Net was there, but nothing else.
    The machine entries seem to work properly, because I get the same behavior with "ftp jost" and "ftp dirac" as before with literal ip's.
    Am I doing things right here?  I hope not, because NFS really seems the most promising way to transfer files!
    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 06, 2015, 05:03:48 pm
    I forgot about that FTP problem.  You probably need to use NFS or disk images in order to get data into the NeXT.  In order to get data out, you can use NFS; if you get an SSH client installed, you should be able to use SFTP.
    Title: Re: Getting files into (and out of) Previous: nfs
    Post by: eagle on June 06, 2015, 05:09:00 pm
    Quote from: "dnwills"1) Added two computers with NetInfoManager under machines:
    Key                 Value
    name                dirac
    ip_address       192.168.1.23
    serves              ./local

    name                jost
    ip_address       192.168.1.20
    serves              ./local

    To be honest, I don't remember how to use NetInfoManager anymore; I just used niload and nidump.  I created a hosts file; for you that would look like this:
    192.168.1.23 dirac
    192.168.1.20 jost

    Then niload that:
    niload hosts / < HOSTSFILE

    Quote2) Added these lines (not at the same time) to /etc/fstab:
    dirac:/usr/local /Net nfs rw,net 0 0
    jost:/usr/local /Net nfs rw,net 0 0

    Did you niload those fstab entries?

    Create FSTABFILE with the contents shown above, then niload it:
    niload fstab / < FSTAB_FILE
    After that, reboot and you should see the mounts in /Net.
    Title: Re: Getting files into (and out of) Previous: nfs
    Post by: dnwills on June 06, 2015, 05:13:48 pm
    Quote from: "eagle"I forgot about that FTP problem.  You probably need to use NFS or disk images in order to get data into the NeXT.  In order to get data out, you can use NFS; if you get an SSH client installed, you should be able to use SFTP.

    I forgot to add:

    3)  I tried importing /usr/local on dirac and jost with NFSManager.  With that, when I rebooted Previous, I got directories /Net/dirac/usr/local and /Net/jost/usr/local (IIRC), but again, no content.

    Could you explain a bit more what you mean by "use NFS"?

    I have no idea how to get an SSH client into Previous.  :(
    -- David
    Title: Re: Getting files into (and out of) Previous: nfs
    Post by: dnwills on June 06, 2015, 05:35:34 pm
    Quote from: "dnwills"I have no idea how to get an SSH client into Previous.  :(

    Actually, after trying many things with OS X Disk Utility and dd, I finally figured out how to get a cd image of a folder made by Disk Utility recognized  as a SCSI-CDROM in Previous.  Make it with the format "hybrid image (HFS+/ISO/UDF)".

    So maybe I'll be able to find and install SSH.  I'd still like to know how to "use NFS".  I'll go try to use the export function of NFSManager.
    -- David
    Title: Re: Getting files into (and out of) Previous: nfs
    Post by: eagle on June 06, 2015, 07:54:21 pm
    Quote from: dnwills
    Quote from: "dnwills"I'd still like to know how to "use NFS".  I'll go try to use the export function of NFSManager.
    -- David

    If you create the files as I suggested, then niload them, then reboot, NFS should be working for you, as long as NFS servers are running on those two hosts, and those NFS servers are sharing those filesystems to the system on which you are running Previous.
    Title: Re: Getting files into (and out of) Previous: nfs
    Post by: Rob Blessin Black Hole on June 06, 2015, 10:01:15 pm
    Quote from: eagle
    Quote from: "dnwills"
    Quote from: "dnwills"I'd still like to know how to "use NFS".  I'll go try to use the export function of NFSManager.
    -- David

    If you create the files as I suggested, then niload them, then reboot, NFS should be working for you, as long as NFS servers are running on those two hosts, and those NFS servers are sharing those filesystems to the system on which you are running Previous.



    Hello : I'm not sure if having the NeXT System Administration docs will help but they are online here...
    http://www.cilinder.be/docs/next/NeXTStep/3.3/nsa/ also you can install the documentation packages from both the NeXT User and developer cd's , it is nice because it creates a searchable bookshelf under the directory NeXTlibrary/bookshelves/systadmin   also for mann pages  and developer tools.

    Best Regards Rob Blessin
    Title: Re: Getting files into (and out of) Previous: nfs
    Post by: dnwills on June 06, 2015, 10:46:32 pm
    Quote from: "eagle"If you create the files as I suggested, then niload them, then reboot, NFS should be working for you, as long as NFS servers are running on those two hosts, and those NFS servers are sharing those filesystems to the system on which you are running Previous.

    Success!

    The problem was to coerce Yosemite into being a NFS server, which I did with the help of NFS Manager from http://www.bresink.com/osx/NFSManager.html.

    I also used NFSManager on Previous to set up the import from Yosemite, without making any changes to the originally supplied /etc/fstab.  Now I can read from and write to /Net/dirac/usr/local on Previous, where dirac is the Yosemite machine (192.168.1.23) I entered into the Previous netinfo.

    Wonderful!  Thanks to all!
    -- David
    Title: Re: Getting files into (and out of) Previous: nfs
    Post by: dnwills on June 06, 2015, 10:54:50 pm
    Quote from: "Rob Blessin Black Hole"Hello : I'm not sure if having the NeXT System Administration docs will help but they are online here...
    http://www.cilinder.be/docs/next/NeXTStep/3.3/nsa/ also you can install the documentation packages from both the NeXT User and developer cd's , it is nice because it creates a searchable bookshelf under the directory NeXTlibrary/bookshelves/systadmin   also for mann pages  and developer tools.
    Thanks!
    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 14, 2015, 03:40:47 pm
    Dear NeXT community!

    I'm proud to announce the release of Previous v1.0! Even if i was not able to fix the remaining problems that have been reported, i think you will like it after taking a closer look.  :wink:

    Most features of the NeXT Computer are implemented. It seems to be mostly stable. Most important it did not corrupt any disk image for a long time now. So i think it is worthy a 1.0. It took many month and thousands of work-hours to come here. I hope it is useful for some people.

    You can load the binary for Mac OS X v10.6 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.0c.zip).

    Have fun!


    Update: SDL2 Framework loading fixed.
    Update 2: Fixed preferences bug that caused a crash on startup. Thanks go to eagle for finding this.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Hialmar on June 14, 2015, 04:00:18 pm
    Awesome !
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 14, 2015, 06:56:06 pm
    Quote from: "andreas_g"I'm proud to announce the release of Previous v1.0! Even if i was not able to fix the remaining problems that have been reported, i think you will like it after taking a closer look.  :wink:

    Andreas, congratulations, and thank you very much!  Such amazing work by you and the rest of the team over the years.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 18, 2015, 06:45:41 pm
    Andreas, you were holding out on us!  Amazing work!

    That's all I'm going to say for now.  I want others to be as delighted as I was at this surprise!

    :D  :D  :D  :D  :D  8)  8)  8)  8)  8)
    Title: What Needs to be done for a NeXT Emulator
    Post by: GrafZahl on June 21, 2015, 11:26:06 am
    Congratulations for the great release and thank you and the team very very much for the huge amount of work and time invested. It is a great emulator and was really fun to watch evolving right from the first version up to 1.0 in this forum thread. This thread and the community in general is amazing and so very helpful for a nextstep fan. It is still crazy booting up those old nextstep versions pre 3.0 and seeing them in action while it was hard to find a couple of screenshots of them some time ago. :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: dnwills on June 21, 2015, 12:12:47 pm
    I've been so busy using it with a project I'm working on that I've been remiss with my congratulations.  Heartfelt Congratulations!

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 21, 2015, 04:13:38 pm
    Thank you everyone for the support! I'm glad if it is useful.

    For all those who didn't notice yet, i want to mention that the DSP is emulated in Previous v1.0. It has some minor problems with timings and at least one arithmetic bug, but most music will play properly. If you already have a saved preference file, you will need to enable it in the advanced system preferences.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jroark on June 21, 2015, 06:38:45 pm
    Very nice, it seems really stable. Sound is working, ethernet is working. It's even more responsive than native hardware!

    One minor issue:

    The time drifts forward pretty quickly, ntp even has trouble keeping it sync
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 21, 2015, 07:35:08 pm
    Quote from: "jroark"The time drifts forward pretty quickly, ntp even has trouble keeping it sync

    All VMs are horrible at keeping time.  I just edited /etc/crontab and added a row to set the clock every 5 minutes with ntpdate.
    Title: Damn! Pretty cool!
    Post by: M Paquette on June 22, 2015, 04:18:20 am
    This is pretty damn cool.

    I just downloaded the emulator, aimed it at a v66 ROM, a NS 3.3 ISO, and a 1Gb empty file, and now it's finishing a full NeXTSTEP install!  Congratulation, and well done!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 22, 2015, 05:51:20 am
    Quote from: "jroark"One minor issue:

    The time drifts forward pretty quickly, ntp even has trouble keeping it sync

    This is a known issue. The timers (event counter and hard clock) are very inaccurate. Unfortunately fixing this would require quite a lot of work on the CPU side. The timings for 68030 and 68040 are not correctly handled. Furthermore the timing system of Previous would need to be rewritten. It comes from Hatari, where it works, but is not suitable for Previous' needs.
    Title: What Needs to be done for a NeXT Emulator
    Post by: dnwills on June 22, 2015, 12:16:53 pm
    Quote from: "eagle"
    All VMs are horrible at keeping time.  I just edited /etc/crontab and added a row to set the clock every 5 minutes with ntpdate.


    Would you be willing to share that line?

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on June 22, 2015, 01:15:47 pm
    Quote from: "dnwills"
    Quote from: "eagle"
    All VMs are horrible at keeping time.  I just edited /etc/crontab and added a row to set the clock every 5 minutes with ntpdate.


    Would you be willing to share that line?

    Of course.  And, it was ntp, not ntpdate:
    0,5,10,15,20,25,30,35,40,45,50,55 * * * * root /usr/etc/ntp -sf 10.0.1.14

    10.0.1.14 is the IP address of my NAS, which functions as the NTP server for my home netowrk.  You should be able to use any public NTP server, such as time.apple.com, 0.centos.pool.ntp.org, etc.

    I could of course run that cron job every minute:
    * * * * * root /usr/etc/ntp -sf 10.0.1.14
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 01, 2015, 01:00:40 pm
    Wow, wow, wow. I mean: wow.

    I didn't check this thread since last March, and I just came today hoping somebody could have tried to resume development... and then I found most of my needed features (network, sound) are implemented and it arrived to 1.0 status.

    Thanks a lot. Even DSP. Really thanks a lot!! This emulator is going to be very useful for me, because I'll be able to compile my code on a 68K-based UNIX system, something I really needed in order to test some of my code.

    Btw, It would be supercool if I could compile code stored on my OS X host from the emulator (this way I could edit the code from either OS X or NS, very convenient). I suppose the best way of achieving this would be through NFS, mounting a host folder as read/write filesystem. Then a Terminal in NeXTSTEP could just 'cd' to such directory, and compile the code.

    Reading the thread, I've seen successful attempts to get NFS working, but with some magic needed.

    Is there any easy step-by-step procedure for setting Previous with an OS X host so that a host folder is shared through NFS?

    (I'm asking this just for avoiding reinventing the wheel)
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 01, 2015, 01:37:50 pm
    Quote from: "ardi"Wow, wow, wow. I mean: wow.

    I totally agree!!!

    QuoteReading the thread, I've seen successful attempts to get NFS working, but with some magic needed.

    Is there any easy step-by-step procedure for setting Previous with an OS X host so that a host folder is shared through NFS?

    I documented it here (http://www.nextcomputers.org/forums/viewtopic.php?t=3598), but the short version is this:

    The NFS automounter is very easy to use, and I prefer that to static mounts.  To use the automounter, create a hosts file with the name and address of your server and niload that.  Create an fstab entry as specified at the linked article, and niload that.  Reboot.

    To make it simple for me, I set up links in /auto to the /Net/HOSTNAME/mount locations.  Then, I just cd /auto/whatever and it works.

    I have not tested the NeXT automounter with a destination of "*", so I don't know if that works.

    Note that in the current implementation, NFS access sometimes makes it crash.  Andreas has asked me to provide details on reproducing my setup so that he can test, and I hope to get that to him soon.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 01, 2015, 02:03:34 pm
    Thanks a lot, eagle. Yes, it would be very useful if you could find some hint on what makes NFS crash sometimes, because my wish would be to access all my data from Previous through NFS, so it would be great if that bug can be hunted.

    BTW, did anybody try to hack memory size so that NeXTSTEP sees 128MB even if it's not a turbo system? Or maybe NS gets crazy with that?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 01, 2015, 02:31:20 pm
    There is no way to get beyond 64 MB main memory on non-Turbo systems. There is just no room in the memory map for it.

    For now we are limited to 32 MB on NeXTstation Color and 64 MB on all other systems.

    But I worked a little bit on Turbo systems recently and made some early progress. NeXTstep 2.2 and 3.0 boot, but some important things are broken (networking and DSP). 3.1 and all later versions crash early in the boot process for an unknown reason.
    Even if I can fix these issues, it would need some time to test everything for reliability. So do not expect anything soon.

    I hope to be able to fix the NFS crash, once I can reproduce it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 02, 2015, 09:20:21 pm
    Don't worry, Andreas. But you can be sure there's a lot of interest in Previous. And there will be also much interest in Turbo emulation. I'm saying this because you seemed to imply there wasn't much interest in Previous. Be assured that's not true. There is.

    Just like there would also be a lot of interest on a 64bit G5 Mac emulator (I'm not saying you've to do that, just putting another example of needed emulators).

    I'll be setting up your new Previous version these weeks, as a very important tool for my development (I want to verify my code builds fine on 68K NeXTs).

    Thanks a lot!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 05, 2015, 08:47:03 am
    I have an update on Turbo sytems. I was able to make networking and DSP work and fix a problem related to NeXTstation Turbo Color. The crash with 3.1 and later is gone too. Now there are 2 remaining problems:
    - The Turbo thinks it is a Nitro
    - With NeXTstep 3.1 and later i only get scrambled video output.

    Update: I just found the problem! 3.3 boots now. But still it would be interesting to see why it thinks we are a Nitro.

    Update 2: Instructions temporarily removed.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on July 05, 2015, 01:08:42 pm
    WTF??? something very, very weird is happening on my turbo-cube right now. I did almost all of the commands up until "e 02210000" and that's when the system threw an exception. ok, I thought, I'll start over again. but now it's impossible to execute "e 020c0000" again. even after pulling power and removing the battery. the system now throws an exception when entering "e 020c0000" (it was working in the beginning). hm..? how is this possible??? otherwise the cube works perfectly normal (booting NeXTstep etc). the cube is equipped with 4x32MB SIMMs (with parity checking enabled).

    now I tried to start with "e 020c0004". worked once. on a second attempt it throws also an exception  :?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 06, 2015, 05:42:33 am
    This is really strange! I temporarily removed the instructions. I don't recommend to try it again, until we know what is the reason for this.

    These registers are accessed also by the ROM (read/write). So I can't imagine that it will cause a hardware defect. But without knowing the details, please do not try it again. Do you remember what kind of exception was caused? Is everything else working as usual?
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on July 06, 2015, 07:13:11 am
    the instruction "e 020c0000" now gives

    Exception #2 (0x8) at pc 0x100071e sp 0xbfff2f6
    faultaddr 0x20c0000

    I know for sure that I got a result after entering this for the 1st time.

    apart from this strange behavior the cube seems to run absolutely normal as far as I can tell...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 06, 2015, 07:44:12 am
    Exception #2 is a bus error. This is really weird. Please do not try it again.

    Thinking about it, there might be two reasons:
    1. The address responds unreliably and it was a coincidence, that it worked on the first try, or the hardware only responds to some specific sequence of access.
    2. Something broke (that would be extremely weird).

    If you notice any permanent adverse effects on your machine, please tell me. I'll then try to get a replacement board for you.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on July 06, 2015, 07:56:52 am
    Quote from: "andreas_g"Thinking about it, there might be two reasons:
    1. The address responds unreliably and it was a coincidence, that it worked on the first try, or the hardware only responds to some specific sequence of access.
    2. Something broke (that would be extremely weird).

    If you notice any permanent adverse effects on your machine, please tell me. I'll then try to get a replacement board for you.


    hypothesis #1: I don't believe in coincidence because the exact same thing happens with the following addresses. entering them once and I got a result. on the second attempt I'm getting an exception.

    hypothesis #2: I have never ever experienced something like this. and believe me, I have done a lot of tinkering with all sorts of computers over many, many years  :twisted:

    no worries, the machine seems to be fine... after all it was me who typed in the commands.

    maybe Mike Paquette could chime in? he might have an explantion for this..?
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 08, 2015, 07:37:28 am
    Quote from: "andreas_g"I have an update on Turbo sytems. I was able to make networking and DSP work and fix a problem related to NeXTstation Turbo Color. The crash with 3.1 and later is gone too. Now there are 2 remaining problems:
    - The Turbo thinks it is a Nitro
    - With NeXTstep 3.1 and later i only get scrambled video output.

    Update: I just found the problem! 3.3 boots now. But still it would be interesting to see why it thinks we are a Nitro.

    Update 2: Instructions temporarily removed.

    Do you mean the video is now fine on Turbo systems in all NeXTstep versions?

    Very interesting it identifies as a Nitro: it seems obvious that something isn't identifying itself in a correct way, so fixing this will enhance the hardware accuracy of the emulator.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 08, 2015, 08:35:14 pm
    Yes, video is now fine on Turbo systems in all versions of NeXTstep.
    The last remaining problem seems to be wrong Nitro detection.

    And now comes something weird:
    I did some more experiments and tried to find out what kind of adverse effects might come from the bus errors that mikeboss experienced after trying to access 0x020c0000. There were not only no adverse effects, but now the ROM no longer mistakenly detects a Nitro! At the moment i am quite sure that bus errors at 0x020c00xx are normal behavior for Turbo sytems. The mysterious thing is, that mikeboss was able to read something from these addresses before they started producing bus errors.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 09, 2015, 07:59:01 am
    ¿Is the unexpected Nitro "fix" permanent even if you shutdown the machine and boot it again? If affirmative, that's indeed weird... what did such access change? Some file in the disk? Some NVRAM setting?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on July 09, 2015, 08:16:09 am
    Nice to see that Previous is getting sound support !
    Which emulation core for the Motorola 56001 DSP did you use, the core of the Hatari emulator or the core from the MAME/MESS project ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 09, 2015, 08:21:11 am
    Yes, the fix is permanent. The ROM and kernel detects Nitro on startup. It probes address 0x02210000. If there is a bus error, this means no Nitro is installed. This detections obviously only works if addresses 0x020c00xx respond with bus errors.

    Unfortunately the bus error at 0x02210000 causes a crash when trying to boot NeXTstep 3.0 and later. This might be a problem with the CPU (bus error stack frame) emulation unrelated to Turbo/Nitro. It will cost some time to find and fix the problem.

    Therefore and because Turbo emulation seems to be stable, i decided to release Previous v1.1 now. It adds support for emulating all Turbo machines. Please note, that only NeXTstep 2.2 and later are compatible with Turbo machines. The wrongly detected Nitro has no adverse effects.

    You can load Previous v1.1 for Mac OS X v10.6 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.1a.zip).

    Although Turbo emulation seems to be stable, i still strongly recommend to only work on copies of your disk images and always keep backups.

    Update: Nitro detection bug fixed. Now correctly identifies as normal Turbo.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 09, 2015, 08:23:39 am
    Quote from: "Kitchen2010"Which emulation core for the Motorola 56001 DSP did you use, the core of the Hatari emulator or the core from the MAME/MESS project ?


    I used the one from Hatari. It only had some minor issues and some minor arithmetic bugs remain. But all in all it is very good code.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 09, 2015, 08:59:24 am
    Quote from: "andreas_g"Therefore and because Turbo emulation seems to be stable, i decided to release Previous v1.1 now. It adds support for emulating all Turbo machines. Please note, that only NeXTstep 2.2 and later are compatible with Turbo machines. The wrongly detected Nitro has no adverse effects.

    You can load Previous v1.1 for Mac OS X v10.6 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.1.zip).

    Although Turbo emulation seems to be stable, i still strongly recommend to only work on copies of your disk images and always keep backups.

    Great, great, great!!!  :D  :D  :D
    Thanks a lot, Andreas!! Downloaded both the 10.6 binary and the source.
    Btw, one question regarding timing: If you remember, we talked about CPU timing accuracy a year ago, but I didn't have the time to figure out how the code emulates CPU speed, so I couldn't help. Anyway, does the CPU frequency affect the emulator speed, or is it currently ignored?

    Anyway, I've no idea if Hatari emulates CPU performance accurately or not.

    EDIT:Just found that Hatari claims to be cycle-accurate. But I'm not sure if that applies to the 68040 too or just to the 68030. Instructions take less cycles on the 68040 than in the 68030.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 09, 2015, 02:09:00 pm
    Yes, the CPU frequency selected affects emulator speed, although not in an accurate way. Anyway some settings have no effect (16/20 MHz and 33/40 MHz are the same). From what i know Hatari is quite good with speed accuracy, but also not perfect on 68030 and 68040.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 09, 2015, 07:08:48 pm
    Thanks to Toni Wilen the CPU/MMU bug that prevented correct Nitro detection (or in this case correctly not detecting Nitro) is now fixed. I updated the binary version above.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 10, 2015, 08:29:54 am
    Quote from: "andreas_g"Thanks to Toni Wilen the CPU/MMU bug that prevented correct Nitro detection (or in this case correctly not detecting Nitro) is now fixed. I updated the binary version above.

    Thanks a lot!! While the incorrect Nitro detection can be just a cosmetic issue, however, maybe that MMU bug could perhaps affect memory protection in some applications, and given that I'm going to use Previous for app building and testing, it's great to have this bug fixed. Again, thanks a lot!

    Now, and back to CPU cycle timing, and assuming it's not cycle accurate, has anybody done any CPU performance comparison between Previous and real hardware? Maybe performance can be calibrated to relatively match real machines (or maybe it already is, I don't know). BTW, boot time isn't a good indicator because disk I/O affects it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on July 10, 2015, 08:35:21 am
    the turbo emulation runs beautifully  8)  thank you andreas!!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: barcher174 on July 10, 2015, 01:51:29 pm
    Just wanted to add another thank you. This is amazing work!

    --
    Brian
    Title: Previous Installation instructions please feel free to edit
    Post by: Rob Blessin Black Hole on July 10, 2015, 08:06:35 pm
    Hello NeXT Community: Previous is like turning the amp upto 11 , awesome job everyone.  I'm going to push the envelop on the hardware side a bit when it when the 3.3 install completes on my Mac Mini in a few minutes . I'm going to try using an IMate which converts USB to ADB and an original NeXT ADB Keyboard and NeXT ADB Mouse.  >>> this works but the NeXT ADB mouse is a bit jumpy , it doesn't lock in the Prev app and the NeXT adb keyboards don't have function keys , I'm guessing a special previous NeXT ADB keyboard mapping driver would need to be written to make the power off sound and brightness up/down keys to function, but the keyboard types. A little delay in response; I'm guessing because a software emulator prev is try to communicate with a hardware emulator  IMate still it doesn't crash which happens on VMWare, excellent job on the code .

    So how I installed iPrev 1.1 in a nutshell , I may make a youtube video showing this to help everyone that would like to try out this amazing software, once more kudos to all involved !
    In a nutshell:
    1) Download previous 1.1 and unzip it then launch.
    2) you will need a NeXT rom file , it looks like they are bundled but I was unable to get it to synch so I just downloaded them here http://www.nextcomputers.org/NeXTfiles/Software/ROM_Files/  I went for the V74rom which was  the last rom release for  turbo color and mono chipsets only.
    3) Choose Turbo Color
    4) Choose scsi disk  and unzip I went for the 2.8 gb scsi disk  and set as id 0
    5) Choose your NeXTSTEP ISO image , if you have original install media , you can make an iso image using  these instructions :
    6) will follow below ISO making instructions for OSX...
    1)Create ISO CD/DVD image (.iso) with Mac OS X 1. Insert CD/DVD source
    "The disk you inserted was not readable by this computer."
    Click "Ignore"

    2. Fire up a Terminal, you can then determine the device that is you CD/DVD drive using the following command:
    $ drutil status
    Vendor Product Rev MATSHITA DVD-R UJ-835E GAND
    Type: DVD-ROM Name: /dev/disk1 Cur Write: 8x DVD Sessions: 1
    Max Write: 8x DVD Tracks: 1
    Overwritable: 00:00:00 blocks: 0 / 0.00MB / 0.00MiB
    Space Free: 00:00:00 blocks: 0 / 0.00MB / 0.00MiB
    Space Used: 364:08:27 blocks: 1638627 / 3.36GB / 3.13GiB
    Writability: Book Type: DVD-ROM

    3. Umount the disk with the following command:$ diskutil unmountDisk /dev/disk1
    Disk /dev/disk1 unmounted

    4. Create the ISO file with the dd utility (may take some time):$ dd if=/dev/disk1s0 of=file.iso bs=512b

    5. The ISO image can then be burnt to a blank CD/DVD Disk Utility (Mac OS X 10.3 or later)

    Open Disk Utility, in the Utilities folder (/Applications/Utilities).
    If the disk image you want to use doesn't appear in the list, drag its icon to the Disk Utility window.
    Select the disk image and click Burn.
    Insert a blank CD or DVD into your computer's optical drive and follow the onscreen prompts.

    or if you need the NeXTSTEP software , I have downloadable NeXTSTEP ISO images here (fees help keep lights on at Black Hole) http://www.store.blackholeinc.com/index.php?_a=category&cat_id=85 , I know there are other places to download the iso as well , I also sell original physical NeXTSTEP Software on EBay as Computerpowwow.

    6) Choose scsi device 1 as your ISO image

    7) Save Configuration and it should launch previous to where you see a NeXT>
    8) At the NeXT>bsd(n,0,0)sdmach rootdev=sdna and pressing return replacing n with the drive number of your ISO image  
    9) Boom the installation should start, choose your language and the drive and follow onscreen instructions. pick your keyboard NeXTUSA works for me
    10) After install is complete , you can set the password for me by clicking the calender icon, choose the padlock set it  and then logout.... you will now have a login screen , you can login as root with no password , be sure and set a root password before networking or all hell breaks loose
    11) You can also now install the Y2K patch ISO just go back to the scsi drive section requires rebooting or you can add the Y2k iso as scsi drive 2 at initial set up.   Y2k patch ISO also available for download on the blackholeinc.com site.
    12) Enjoy , I hope that helps.

    13) I'm working on a simple solution that I hope (90%) will work to fix the NeXT Laser Paper Jammed in your printer problem with or without having to replace the intake roller, if it works I'll post results in NeXT work logs and make a video!
    Best Regards Rob Blessin
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 10, 2015, 08:20:36 pm
    Nice instructions Rob. Also don't forget that you can now get a "shared folder" between your Mac and the emulated NeXT, via NFS. Very helpful for convenient sharing of all your work across the two machines!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 10, 2015, 10:12:58 pm
    Rob, excellent instructions.  Thanks.

    I'm trying a fresh install of OPENSTEP 4.2.  A while ago I made images of my OS 4.2 install and dev tools discs; the MD5 checksums of those are:
    cdd35e0b06038ed3e4581a88c00839ae OS42-DevTools.iso
    a506d0c18e27f96b77fbaa1753591909 OS42.iso


    Do those match yours?  I get this error when I try to install with that image, and it doesn't matter at what SCSI ID I put the CD:



    I also tried putting the CD at SCSI ID 1 and running: bsd(1,0,0)sdmach rootdev=sd1a but that results in the same error just shown.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on July 10, 2015, 10:34:23 pm
    Quote from: "eagle"Rob, excellent instructions.  Thanks.

    I'm trying a fresh install of OPENSTEP 4.2.  A while ago I made images of my OS 4.2 install and dev tools discs; the MD5 checksums of those are:
    cdd35e0b06038ed3e4581a88c00839ae OS42-DevTools.iso
    a506d0c18e27f96b77fbaa1753591909 OS42.iso


    Do those match yours?  I get this error when I try to install with that image, and it doesn't matter at what SCSI ID I put the CD:



    I also tried putting the CD at SCSI ID 1 and running: bsd(1,0,0)sdmach rootdev=sd1a but that results in the same error just shown.


    This is what is returned in disk utility:
    Disk Description :   openstep42useriso.cdr   Disk Write Status :   Not mounted
       Connection Bus :   Disk Image   Disk Image Size :   512.2 MB (512,180,224 Bytes)

    and for developer:

       Disk Description :   Apple read/write    Total Capacity :   470.5 MB (470,544,384 Bytes)
       Connection Bus :   Disk Image   Disk Write Status :   Read/Write
             Partition Map Scheme :   No partition map
       Disk Image Path :   /Untitled/Users/user/openstep42_dev.iso

    both of these images result in clean installs from ISO and from burned back up CD preserving the masters!

    Best regards Rob

    Best regards
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 11, 2015, 12:07:07 am
    Something must be wrong with my OS4.2 image: it is 512,487,424 bytes in size, which differs from yours.  My OS4.2 Developer matches yours in size: 470,544,384 bytes.

    My OS4.2 image mounts in NeXTSTEP 3.3, so perhaps I should just boot that and run the updater on that.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 11, 2015, 01:59:14 pm
    I re-imaged my OS4.2 user disc and got exactly the same image (same MD5 checksum).  For some reason, it won't boot in Previous, and the updater doesn't work in NS3.3 either: it complains of bad permissions, as you can see here:



    Is this what everyone else's disc looks like?  I wonder how I could have a bad one...

    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on July 12, 2015, 03:31:30 am
    Quote from: "eagle"I re-imaged my OS4.2 user disc and got exactly the same image (same MD5 checksum).  For some reason, it won't boot in Previous, and the updater doesn't work in NS3.3 either: it complains of bad permissions, as you can see here:



    Is this what everyone else's disc looks like?  I wonder how I could have a bad one...


    I have downloadable ISO on my website , if you like I'll set the php script so you can download it free as you already own it. To save costs on the page you have to download 3 parts as they restrict it to 200 mb and split and concat to stitch together.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on July 12, 2015, 02:03:41 pm
    Or try copying the contents of the CD to a virtual hd with ditto ? Then make any permission changes required...
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on July 12, 2015, 06:52:26 pm
    much to my surprise, there's no OPENSTEP CD in my collection. but I tried to boot both of the two ISO files I have and they failed with the exact same errors. what worked though was the dd-image I still have from an installer I created on a Compact-Flash Card.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on July 13, 2015, 12:30:07 am
    Quote from: "eagle"Something must be wrong with my OS4.2 image: it is 512,487,424 bytes in size, which differs from yours.  My OS4.2 Developer matches yours in size: 470,544,384 bytes.

    My OS4.2 image mounts in NeXTSTEP 3.3, so perhaps I should just boot that and run the updater on that.


    I tested the Openstep 4.2 iso upgrade install from my 3.3 previous install and it worked from scratch with no surprises, I created the ISO image from an Openstep 4.2 User CD.  NeXT I'll try a Openstep 4.2 install from scratch no upgrade and also for the heck of it try the buggy but cool NeXTSTEP 4.0 Alpha aka Openstep 4.0 Alpha with the funky folders and see if it works..
    Title: What Needs to be done for a NeXT Emulator
    Post by: jarehart on July 14, 2015, 04:00:31 am
    To update from my last post on 02 June, I have successfully built Previous 1.1 (r488) and run OpenStep 4.2 inside it on Debian Linux (stretch/amd64). It is a 32-bit build (as I recall reading that 64-bit builds may not work) and it is dynamically linked. Included below are links to the binaries. I have also included the patch needed for slirp to build (trimmed from a diff posted earlier in this thread) as well as the log of my configure command.

    https://www.dropbox.com/s/3g3irga95aik9n9/previous-linux.diff?dl=0
    https://www.dropbox.com/s/2us6w593qt2546t/Previous-configure-output-1.1-r488-linux-x86_32.txt?dl=0
    https://www.dropbox.com/s/f5n4xbsu8oe369j/Previous-1.1-r488-linux-x86_32.tar.gz?dl=0

    My rough build steps are:

    1) svn source pull
    2) configure with flags
    3) patch for HAVE_STRDUP on Linux
    4) build
    5) copy icon into source
    6) make install
    7) create tarball

    Please let me know of any questions, and big thanks again to Andreas and everyone else who is working on Previous!

    -Jonathan

    Edit:

    Also, here are a few screenshots, for the fun of it:

    https://www.dropbox.com/s/9az0urn3bl1vp3h/previous-0.9-r442-20150602-colorslab-rommon.png?dl=0
    https://www.dropbox.com/s/dfndgnzbapw3ler/previous-0.9-r442-20150604-monoslab-os42.png?dl=0

    https://www.dropbox.com/s/wvbla6ldnanwr6b/previous-1.1-r488-20150713-turbocolorslab-rommon.png?dl=0
    https://www.dropbox.com/s/y59iigirwfki21r/previous-1.1-r488-20150713-turbocolorslab-os42.png?dl=0
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on July 14, 2015, 05:57:31 pm
    Quote from: "Rob Blessin Black Hole"
    Quote from: "eagle"I re-imaged my OS4.2 user disc and got exactly the same image (same MD5 checksum).  For some reason, it won't boot in Previous, and the updater doesn't work in NS3.3 either: it complains of bad permissions, as you can see here:



    Is this what everyone else's disc looks like?  I wonder how I could have a bad one...


    I have downloadable ISO on my website , if you like I'll set the php script so you can download it free as you already own it. To save costs on the page you have to download 3 parts as they restrict it to 200 mb and split and concat to stitch together.



    Hello Eagle: I think what may be happening here is the password needs to be set for the me account first,  click the calender icon, set the password
    then logout, you will now have a login panel  and log back in as root !  
    Now try the Openstep 4.2 User upgrade from NeXTSTEP 3.3 while logged in as root it should work.
    I also tried doing an install using my Openstep 4.2 User iso image using the bsd(1,0,0)sdmach rootdev=sd1a and it gave the same error as yours above with it set to cdrom..... so then I connected a floppy in the previous app  and mounted a motorola boot floppy image file and tried bfd, it works initially by going badmagic finds the cd and hard drive and starts the Openstep 4.2 User iso to hard drive install , actually completes phase 1 of the install  and when it asks to reboot it reboots in verbose mode but it hangs on the script right after checkdisk and finding the hard drive where it would identify the cdrom drive image, I suspect something changed in Openstep 4.2 ,  so it never gets to phase 2 where you install all the packages.
    I know when you choose device in Previous you pick if you want it to be a hard drive or cdrom drive before doing the install and this works for all versions of NeXTSTEP but may be what is causing the hang on reboot perhaps something changed in the Openstep 4.2 boot script.
    So I think your Openstep 4.2 image is probably OK and should work from using upgrader . app from root under NeXTSTEP 3.3.
    If anyone else out there replicate the problem with a fresh clean Openstep 4.2 install from iso or cdrom  to verify this basically to help us  that would be great, make sure your NeXT or openstep motobootfloppy image has a fd extension and start the install from the NeXT> by typing bfd with an Openstep 4.2 ISO mounted as the cdrom and a hard drive image ready to go, I'm guessing it is probably something easy to fix.
    It looks like Mike had success in installing Openstep 4.2 from scratch from a DD image I'm wondering if that is an ISO ?
    Best regards Rob Blessin
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on July 14, 2015, 08:25:51 pm
    Quote from: "Rob Blessin Black Hole"
    It looks like Mike had success in installing Openstep 4.2 from scratch from a DD image I'm wondering if that is an ISO ?


    some time ago I created Compact Flash cards with NS 3.3 and OS 4.2 installers on them. I'm pretty sure that I used the dd command to copy the content of the CD-ROMs to the CF card. now the dd image I still have is of this particular installer CF card and it works flawless to run the install procedure.
    Title: Writing to NFS shares from Previous .1
    Post by: dnwills on July 15, 2015, 12:21:57 pm
    Congratulations on getting the Turbo to work!

    I'm running Previous 1.1a with Yosemite on a Mac mini, with NeXTstep 3.3.  I'm exporting NFS shares (rw for everybody) from OS X with the help of NFS Manager, and importing the shares to NeXTstep via NetinfoManager.  I have set up an account in NeXTstep with the same UID as that of the OS X files in the shares.  It doesn't matter in the following whether I use that account or root for the following experiments with writing to shares.

    Reading from the shares in Previous works fine, albeit slowly.  Could that be because its ethernet emulates 10base-T?

    1. Transferring files to the shares from Previous usually crashes Previous. In fact, I've never succeeded in transferring a binary file to the outside.

    2. Change directory (cd) from Previous to a shared OS X directory, and execute the following on a short OS X text file there named infile:

     cat infile >>outfile


    Here outfile did not exist before.  This works, and both infile and outfile display correctly via more in Previous.  Then outfile can be deleted via rm in Previous with no problem.  But if instead I try the cat command a second time on the existing outfile, Previous crashes, and inspection of outfile shows that the second cat had no effect.

    3. The following shell script works fine in a Previous directory containing a short assembly language source file, hello.a:

    echo "Assembling hello.y."
    AAma -b hello.a -o hello.y
    echo "Assembling IOst.y."
    AAma k=15 -b /usr/IOst/IOst.a -o IOst.y
    echo "Linking hello."
    Link -n -o hello IOst.y hello.y


    Here AAma is Veltman's Ann Arbor Macro Assembler for m68k, and Link is his linker, both of which work in Previous.  But when I cd to a shared directory containing copies of the same script and hello.a, the first echo and AAma work fine, as shown by a dump of the object file hello.y, the second echo works, and a message comes from the second AAma which shows it is working, but it finally gives an error message (trying to write past end of file), and a bit later Previous crashes.  The second object file IOst.y does get written, but is empty.

    So I don't know how to write reliably to a NFS share exported by OS X. Has anybody succeeded in doing that?

    I've also tried sftp, but that'll be another message.

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 15, 2015, 12:28:21 pm
    David, I was just about to reply to your other post but then you deleted it.  I figured it would show up here soon enough. :)

    I have exactly the same experience with my NAS, and I have shared files via NFS with OS X before (though not with Yosemite) so I know it works.

    This appears to be a crash inside the slirp code, and Andreas needs instructions on how to set up the NFS server on OS X and how to reproduce it.  I just haven't been able to get that to him yet, because I haven't been able to reinstall OS 4.2.

    Hopefully we can get this one nailed down: it is the last significant issue I know of.
    Title: What Needs to be done for a NeXT Emulator
    Post by: dnwills on July 15, 2015, 01:39:39 pm
    Quote from: "eagle"David, I was just about to reply to your other post, but then you deleted it. I figured it would show up here soon enough.

    Yeah, that's a bit embarrassing -- I'm still learning my way around this forum.  :(
    QuoteThis appears to be a crash inside the slirp code, and Andreas needs instructions on how to set up the NFS server on OS X and how to reproduce it.

    What I use is NFS Manager, http://www.bresink.com/osx/NFSManager.html, which is free with nagging.  I do plan to buy it.  I just followed my nose with it, but would be happy to provide more details if needed.  Here's a snapshot of my personal notes about the Previous side -- see the section on NFS configuration:  https://umich.box.com/s/bizf10yleelpm2hh1h4w5sro0koww1u2
    QuoteHopefully we can get this one nailed down: it is the last significant issue I know of.

    I'm having a problem with SFTP from within Previous, which I've got running as part of openssh 3.1, see http://www.nleymann.de/Nextstep/.  SSH itself works fine from Previous to outside, but whereas SFTP lets me log on, either to my host OS X account or to my remote university account, it immediately drops back into Previous.

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 16, 2015, 09:40:51 am
    If Andreas cannot reproduce it, maybe it could help if you can get an stack trace when the crash happens.

    I'm also very interested in doing exactly what you're trying to do: build source code located in a shared folder (and editing the code as well)
    Title: What Needs to be done for a NeXT Emulator
    Post by: dnwills on July 16, 2015, 01:07:08 pm
    Quote from: "ardi"If Andreas cannot reproduce it, maybe it could help if you can get an stack trace when the crash happens.

    I just emailed a trace to Andreas.

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on July 16, 2015, 01:20:02 pm
    Quote from: "dnwills"
    Quote from: "ardi"If Andreas cannot reproduce it, maybe it could help if you can get an stack trace when the crash happens.

    I just emailed a trace to Andreas.

    -- David

    Great!! Thanks a lot for helping hunting this bug!!  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 17, 2015, 10:46:16 pm
    Quote from: "Rob Blessin Black Hole"Hello Eagle: I think what may be happening here is the password needs to be set for the me account first,  click the calender icon, set the password
    then logout, you will now have a login panel  and log back in as root !  
    Now try the Openstep 4.2 User upgrade from NeXTSTEP 3.3 while logged in as root it should work.
    I also tried doing an install using my Openstep 4.2 User iso image using the bsd(1,0,0)sdmach rootdev=sd1a and it gave the same error as yours above with it set to cdrom..... so then I connected a floppy in the previous app  and mounted a motorola boot floppy image file and tried bfd, it works initially by going badmagic finds the cd and hard drive and starts the Openstep 4.2 User iso to hard drive install , actually completes phase 1 of the install  and when it asks to reboot it reboots in verbose mode but it hangs on the script right after checkdisk and finding the hard drive where it would identify the cdrom drive image, I suspect something changed in Openstep 4.2 ,  so it never gets to phase 2 where you install all the packages.
    I know when you choose device in Previous you pick if you want it to be a hard drive or cdrom drive before doing the install and this works for all versions of NeXTSTEP but may be what is causing the hang on reboot perhaps something changed in the Openstep 4.2 boot script.
    So I think your Openstep 4.2 image is probably OK and should work from using upgrader . app from root under NeXTSTEP 3.3.
    If anyone else out there replicate the problem with a fresh clean Openstep 4.2 install from iso or cdrom  to verify this basically to help us  that would be great, make sure your NeXT or openstep motobootfloppy image has a fd extension and start the install from the NeXT> by typing bfd with an Openstep 4.2 ISO mounted as the cdrom and a hard drive image ready to go, I'm guessing it is probably something easy to fix.
    It looks like Mike had success in installing Openstep 4.2 from scratch from a DD image I'm wondering if that is an ISO ?
    Best regards Rob Blessin


    Well, I kept digging around my NAS and found a disk image called "4.2_Boot_Disk_68k.floppyimage," and, when I insert that as the floppy, and boot from it, it finds the CD and then runs the installer.  It has just been so long since I installed OS4.2 that I forgot how to do it. :)

    Anyway, in an hour or so I should have a fresh OS4.2 image, which I can use to provide instructions to Andreas.

    Edit: Yup, I now have a working OS4.2 installation. Thanks for the tip about the disk image, Rob!
    Title: Revised notes on Previous 1.1a
    Post by: dnwills on July 21, 2015, 09:51:39 pm
    Quote from: "dnwills"Here's a snapshot of my personal notes about the Previous side -- see the section on NFS configuration:  https://umich.box.com/s/bizf10yleelpm2hh1h4w5sro0koww1u2

    I've revised the notes at the link above to include a bit more on NFS setup from the OS X side.

    -- David
    Title: Re: Revised notes on Previous 1.1a
    Post by: eagle on July 22, 2015, 07:24:04 pm
    Quote from: "dnwills"
    Quote from: "dnwills"Here's a snapshot of my personal notes about the Previous side -- see the section on NFS configuration:  https://umich.box.com/s/bizf10yleelpm2hh1h4w5sro0koww1u2

    I've revised the notes at the link above to include a bit more on NFS setup from the OS X side.

    David, this is an excellent write-up.  Now that I have OS4.2 installed, I'm going to set up NFS again while taking notes.  If mine differ from yours, I will post about that.
    Title: Re: Revised notes on Previous 1.1a
    Post by: dnwills on July 22, 2015, 08:02:24 pm
    Quote from: "eagle"
    David, this is an excellent write-up.  Now that I have OS4.2 installed, I'm going to set up NFS again while taking notes.  If mine differ from yours, I will post about that.

    Thanks!  I just updated the notes to replace a reference to Previous 1.0c by one to Previous 1.1a.  The link for the notes is the same as before.

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 23, 2015, 12:39:20 am
    Hopefully sourceforge hurries up and restores the SVN!... another project of mine which uses GIT finally came back online so hopefully Previous lives yet again!
    Title: Re: Revised notes on Previous 1.1a
    Post by: ardi on July 23, 2015, 10:09:25 am
    Quote from: "dnwills"
    Quote from: "dnwills"Here's a snapshot of my personal notes about the Previous side -- see the section on NFS configuration:  https://umich.box.com/s/bizf10yleelpm2hh1h4w5sro0koww1u2

    I've revised the notes at the link above to include a bit more on NFS setup from the OS X side.

    -- David

    Thank you, thank you, thank you  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: jasonwoodland on July 24, 2015, 08:39:24 am
    Hey guys nice work with all the progress made recently!! loving playing mp3's and browsing the web in color! I'm only running a build of 1.0 someone posted a few pages back but I had a few ideas I thought would be cool to add in the future.

    Can the fullscreen function have a stretch/scale option so I can remove the black bars on the sides of my widescreen displays? Also the ability to hide the status bar in fullscreen?

    I don't know about 68k NEXTSTEP but you can run Intel NEXTSTEP in various screen resolutions. It would be awesome if there was a way to hack 68k NEXTSTEP to run in a custom resolution to display perfectly on all our newer displays?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 24, 2015, 12:44:13 pm
    Could someone push the latest version of the Previous source code to GitHub please? I've been waiting to compile 1.x on Linux for several days now and SourceForge SVN is still down today.  :x The 0.5 Windows binaries are OK, but I want sound and network connectivity.

    Maybe you should consider migrating the project to GitHub entirely after this endless SourceForge disaster.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 24, 2015, 02:39:35 pm
    Quote from: "Morn76"Could someone push the latest version of the Previous source code to GitHub please? I've been waiting to compile 1.x on Linux for several days now and SourceForge SVN is still down today.  :x The 0.5 Windows binaries are OK, but I want sound and network connectivity.

    Maybe you should consider migrating the project to GitHub entirely after this endless SourceForge disaster.


    My crappy mac thing which uses git on sourceforge is already up... I read that they were going to do git before SVN so I guess, I picked lucky.

    I have a really old one that uses CVS.  I guess that'll be offline for the better part of forever.   :shock:
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 24, 2015, 03:26:14 pm
    Quote from: "neozeed"
    My crappy mac thing which uses git on sourceforge is already up... I read that they were going to do git before SVN so I guess, I picked lucky.

    I have a really old one that uses CVS.  I guess that'll be offline for the better part of forever.   :shock:

    According to their Twitter feed, CVS/SVN/Bzr are still broken: https://twitter.com/sfnet_ops/status/624329180029677568

    I've found Previous on GitHub, but unfortunately it's 0.5, which I already have as a binary.

    Oh well, if SF doesn't recover soon I could still use the 1.0 OS X build that was posted in this thread. The screen of my MacBook is a bit small though, so I'd prefer to do a Linux build.
    Title: What Needs to be done for a NeXT Emulator
    Post by: jarehart on July 24, 2015, 09:27:03 pm
    Quote from: "Morn76"Could someone push the latest version of the Previous source code to GitHub please? I've been waiting to compile 1.x on Linux for several days now and SourceForge SVN is still down today.  :x The 0.5 Windows binaries are OK, but I want sound and network connectivity.

    Maybe you should consider migrating the project to GitHub entirely after this endless SourceForge disaster.



    Does the Linux (32bit) build from https://www.dropbox.com/s/f5n4xbsu8oe369j/Previous-1.1-r488-linux-x86_32.tar.gz?dl=0 work for your Linux distribution? It is a dynamically linked build.

    (That archive is just the Previous 1.1 binaries, it does not have the ROM binaries.)

    If it does not work, please let me know and I can investigate doing a static build or other options.

    -Jonathan
    Title: NFS shares not working
    Post by: dnwills on July 24, 2015, 10:19:32 pm
    Andreas tried the NFS setup in my Previous 1.1 Guide, and couldn't get it to work.  So I tried the same on my laptop, and failed there, too.  One difference is that I have OS X Server running on my desktop, where NFS does work between Yosemite and NeXTstep on Previous.  I hope to try Server on the laptop tomorrow, to see if that helps, but I wanted to give a heads up that there is a problem, in case anybody is trying and failing.

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 24, 2015, 10:32:33 pm
    Quote from: "jarehart"
    Does the Linux (32bit) build from https://www.dropbox.com/s/f5n4xbsu8oe369j/Previous-1.1-r488-linux-x86_32.tar.gz?dl=0 work for your Linux distribution? It is a dynamically linked build.

    Thanks, Jonathan! Unfortuntately it doesn't work because I'm using the 64-bit version of Arch Linux, so I'm missing some 32-bit libraries such as SDL 2. The latter doesn't seem to be present in the official Arch repos.

    SourceForge has promised to restore Subversion service tomorrow. So either I will be able to compile then or find out how to install lib32-sdl2.  :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 24, 2015, 11:49:50 pm
    Quote from: "jarehart"
    Quote from: "Morn76"Could someone push the latest version of the Previous source code to GitHub please? I've been waiting to compile 1.x on Linux for several days now and SourceForge SVN is still down today.  :x The 0.5 Windows binaries are OK, but I want sound and network connectivity.

    Maybe you should consider migrating the project to GitHub entirely after this endless SourceForge disaster.



    Does the Linux (32bit) build from https://www.dropbox.com/s/f5n4xbsu8oe369j/Previous-1.1-r488-linux-x86_32.tar.gz?dl=0 work for your Linux distribution? It is a dynamically linked build.

    (That archive is just the Previous 1.1 binaries, it does not have the ROM binaries.)

    If it does not work, please let me know and I can investigate doing a static build or other options.

    -Jonathan


    Source is what I'm hoping for.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 24, 2015, 11:53:02 pm
    QuoteSF.net Operations ‏@sfnet_ops  Jul 23
    #SourceForge Mercurial (Hg) service online. Work continues 24x7 on file upload and CVS/SVN/Bzr.



    So I guess my CVS is going to be online before SVN?  crap.

    Anyways my CVS is still offline.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 25, 2015, 09:35:36 am
    Quote from: "neozeed"
    So I guess my CVS is going to be online before SVN?  crap.

    Anyways my CVS is still offline.

    No, according to their blog post (http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-724/), SVN is next and CVS will come after that.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 25, 2015, 09:38:23 am
    SourceForge Allura Subversion (SVN) service - offline, filesystem checks complete, data restoration has completed 22 letters (4 remain). This is our current restore priority. We project restore of data to complete by 7/25, to be followed by data validation and restore of service.  ETA to follow once I/O performance calculated during data validation.



    Should be soon.  No doubt Previous is one of the four.

    I just wonder how bad the shitstorm will be when github looses VC funding what is going to happen there?
    Title: Re: NFS shares not working
    Post by: dnwills on July 25, 2015, 07:01:18 pm
    Quote from: "dnwills"Andreas tried the NFS setup in my Previous 1.1 Guide, and couldn't get it to work.  So I tried the same on my laptop, and failed there, too.  One difference is that I have OS X Server running on my desktop, where NFS does work between Yosemite and NeXTstep on Previous.

    My laptop can see NFS shares now, and without OS X Server.  I discovered that NFS started working when I switched the laptop from wireless to wired ethernet, and then I noticed that my OS X Network settings for DNS were empty in wireless mode.  When I inserted the DNS Server and Search Domains settings recommended for my gateway, NFS shares became visible in Previous.  The wired ethernet mode already had those settings.  Too many moving parts!

    Maybe that removes a distraction from the problem of writing to shares from Previous.

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 26, 2015, 03:02:03 am
    Yay SVN is back up!!!!

    Use this to check out all branches, and everything!


    svn checkout svn://svn.code.sf.net/p/previous/code previous


    We can't lose the source to this, it's simply too amazing!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on July 26, 2015, 03:18:26 am
    Quote from: "neozeed"Yay SVN is back up!!!!

    Use this to check out all branches, and everything!


    svn checkout svn://svn.code.sf.net/p/previous/code previous


    We can't lose the source to this, it's simply too amazing!

    Indeed, it is amazing.  But, the code in svn seems to be v1.0, not 1.1.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 26, 2015, 03:57:20 am
    Quote from: "eagle"
    Quote from: "neozeed"Yay SVN is back up!!!!

    Use this to check out all branches, and everything!


    svn checkout svn://svn.code.sf.net/p/previous/code previous


    We can't lose the source to this, it's simply too amazing!

    Indeed, it is amazing.  But, the code in svn seems to be v1.0, not 1.1.


    branch_mmu?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 26, 2015, 06:35:36 am
    Luckily the code is back online. Version 1.1 is in branch_mmu. But i just merged the branch to trunk, so now trunk is also up to date. Don't worry about further downtimes at sourceforge. I have all the sources locally (even versioned) with tripple backup. But maybe it makes sense if some other people also keep copies of the code. We might also put copies of the code to the forum's file archive (for every version at release time).

    I'm glad to see that Previous compiles and runs on Linux (btw it should also run 64-bit). At the moment i'm trying to set up NFS on my system, so i can reproduce the crash that was reported several times.

    For the screen resolution: From what i know it is not possible to run 68k NeXTstep with different resolutions. Black hardware only supported one single resolution. I have the goal to remove the statusbar in fullscreen mode on my list.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 26, 2015, 09:51:52 am
    Quote from: "andreas_g"Luckily the code is back online. Version 1.1 is in branch_mmu. But i just merged the branch to trunk, so now trunk is also up to date. Don't worry about further downtimes at sourceforge. I have all the sources locally (even versioned) with tripple backup. But maybe it makes sense if some other people also keep copies of the code. We might also put copies of the code to the forum's file archive (for every version at release time).

    I'm glad to see that Previous compiles and runs on Linux (btw it should also run 64-bit). At the moment i'm trying to set up NFS on my system, so i can reproduce the crash that was reported several times.

    For the screen resolution: From what i know it is not possible to run 68k NeXTstep with different resolutions. Black hardware only supported one single resolution. I have the goal to remove the statusbar in fullscreen mode on my list.


    I would request a snapshot of each release milestone in the file area of sourceforge...  since it came online faster, and then it looks more alive ;)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 10:50:05 am
    Just checked out trunk, but compilation on Arch Linux (64 bit) aborts with an error:

    [ 19%] Building C object src/slirp/CMakeFiles/Slirp.dir/misc.c.o
    /home/martin/svn/previous/trunk/src/slirp/misc.c: In function 'fork_exec':
    /home/martin/svn/previous/trunk/src/slirp/misc.c:369:14: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
       argv[i++] = "slirp.telnetd";
                 ^
    /home/martin/svn/previous/trunk/src/slirp/misc.c:370:14: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
       argv[i++] = "-x";
                 ^
    In file included from /usr/include/string.h:634:0,
                    from /usr/include/sys/un.h:37,
                    from /home/martin/svn/previous/trunk/src/slirp/slirp.h:164,
                    from /home/martin/svn/previous/trunk/src/slirp/misc.c:10:
    /home/martin/svn/previous/trunk/src/slirp/misc.c: At top level:
    /home/martin/svn/previous/trunk/src/slirp/misc.c:433:1: error: expected identifier or '(' before '__extension__'
    strdup(str)
    ^
    /home/martin/svn/previous/trunk/src/slirp/misc.c:435:1: error: expected identifier or '(' before '{' token
    {
    ^
    In file included from /home/martin/svn/previous/trunk/src/slirp/misc.c:10:0:
    /home/martin/svn/previous/trunk/src/slirp/slirp.h:304:1: warning: 'ip_reass' declared 'static' but never defined [-Wunused-function]
    ip_reass(register struct ip *ip, register struct ipq *);
    ^
    src/slirp/CMakeFiles/Slirp.dir/build.make:215: recipe for target 'src/slirp/CMakeFiles/Slirp.dir/misc.c.o' failed
    make[2]: *** [src/slirp/CMakeFiles/Slirp.dir/misc.c.o] Error 1
    CMakeFiles/Makefile2:449: recipe for target 'src/slirp/CMakeFiles/Slirp.dir/all' failed
    make[1]: *** [src/slirp/CMakeFiles/Slirp.dir/all] Error 2
    Makefile:116: recipe for target 'all' failed
    make: *** [all] Error 2
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 26, 2015, 11:12:53 am
    Morn76, please try again with the latest revision. There was a pending patch for Linux, that was missing from the repository. The problem should be fixed now.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 12:05:38 pm
    Thanks, Andreas, compiling works on Linux now with the latest version! Yay! :D

    When I play back Steve's welcome message in Mail.app (NS 2.2), audio plays back way too fast, like 2x or 3x the speed it should be. Is this a known bug or something Linux-specific?
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on July 26, 2015, 12:24:12 pm
    Quote from: "Morn76"When I play back Steve's welcome message in Mail.app (NS 2.2), audio plays back way too fast, like 2x or 3x the speed it should be. Is this a known bug or something Linux-specific?


    this works fine on OS X. tested with NS 2.0

    EDIT:
    created a screenrecording -> https://youtu.be/lCPlGgA6tE4
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 01:53:45 pm
    Quote from: "mikeboss"
    Quote from: "Morn76"When I play back Steve's welcome message in Mail.app (NS 2.2), audio plays back way too fast, like 2x or 3x the speed it should be. Is this a known bug or something Linux-specific?


    this works fine on OS X. tested with NS 2.0

    I've timed Steve's speech; it runs about 15 seconds in Previous on Arch. The same message is on YouTube (https://www.youtube.com/watch?v=M3DI3l1tYFc) (<- that's a link, even if you can barely see it) at normal speed and runs 30 seconds. So yeah, factor of 2 difference.

    Maybe this is a PulseAudio issue only, and therefore Linux-specific?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 26, 2015, 02:42:32 pm
    Does the audio sound clipped or stuttering, or is it simply playing too fast (with high pitched voice in this case)? I suppose a problem with SDL2 audio on Linux. Maybe it is worth to give the latest SDL2 2.0.4 development snapshot a try.

    If you want to do some debugging, then you should have a look at audio.c, Audio_Output_Init(), where the sample rate is set.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 03:00:39 pm
    I've recorded the audio: http://home.arcor.de/mdoege/audio/steve_fast.m4a

    I think pitch is correct, it just sounds scratchy and too fast. Maybe this is mono sound being played back in stereo, with short pauses whenever the buffer runs out?

    I'll try it with SDL 2.0.4...

    P.S. Nope, same audio issue with the hg version of SDL (sdl2-hg-2.0.3.r1185.9d44e8794a9b-1)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 26, 2015, 03:50:44 pm
    That sounds awful! As you say, this is not just double speed. It could really be some mono/stereo problem, but the sound data coming from NeXTstep is stereo. Maybe someone with audio skills can have a closer look at the recorded file and find out what kind of problem might cause this kind of distortion?

    I read somewhere that small sample buffers may cause problems. Maybe you can try setting in snd.c, line 17 --> #define SND_BUFFER_LIMIT 40960, audio.c, line 68 --> request.samples = 10240 and includes/queue.h, line 33 unsigned char data[40960] and see what happens then.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 03:54:02 pm
    Quote from: "andreas_g"
    If you want to do some debugging, then you should have a look at audio.c, Audio_Output_Init(), where the sample rate is set.

    In audio.c, it says

    request.channels = 2; /* stereo */

    But in PulseAudio volume control, Previous has mono output. So that seems a bit fishy to me.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 04:02:46 pm
    Quote from: "andreas_g"
    I read somewhere that small sample buffers may cause problems. Maybe you can try setting in snd.c, line 17 --> #define SND_BUFFER_LIMIT 40960, audio.c, line 68 --> request.samples = 10240 and includes/queue.h, line 33 unsigned char data[40960] and see what happens then.

    Tried that. The program compiles and runs fine, but when I start audio playback it crashes:

    [KMS] Sound out command:
    [KMS] Sound out disable.
    [KMS] Sound out command:
    [KMS] Sound out enable.
    [KMS] Sound out double sample.
    [KMS] Sound out double sample by repetition.
    [SCR2] DSP interrupt at level 3
    [SCR2] DSP interrupt at level 4
    [SCR2] Switching DSP interrupt to level 4
    [SCR2] DSP interrupt at level 3
    [KMS] Sound out command:
    [KMS] Sound out enable.
    [KMS] Sound out double sample.
    [KMS] Sound out double sample by repetition.
    [Sound] Restarting loop.
    [SCR2] DSP interrupt at level 4
    [SCR2] Switching DSP interrupt to level 4
    [KMS] Sound out command:
    [KMS] Sound out enable.
    [KMS] Sound out double sample.
    [KMS] Sound out double sample by repetition.
    [Sound] Restarting loop.
    [SCR2] DSP interrupt at level 3
    [SCR2] DSP interrupt at level 4
    [SCR2] Switching DSP interrupt to level 4
    [SCR2] DSP interrupt at level 3
    [KMS] Sound out command:
    [KMS] Sound out enable.
    [KMS] Sound out double sample.
    [KMS] Sound out double sample by repetition.
    [Sound] Restarting loop.
    [SCR2] DSP interrupt at level 4
    [SCR2] Switching DSP interrupt to level 4
    [KMS] Sound out command:
    [KMS] Sound out enable.
    [KMS] Sound out double sample.
    [KMS] Sound out double sample by repetition.
    [Sound] Restarting loop.
    [SCR2] DSP interrupt at level 3
    [SCR2] DSP interrupt at level 4
    [SCR2] Switching DSP interrupt to level 4
    [DMA] Channel Sound Out: Error! Bad alignment! (Next: $07E0F003, Limit: $07E10000)
    Abgebrochen (Speicherabzug geschrieben)
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 26, 2015, 04:07:34 pm
    Quote from: "Morn76"
    Quote from: "andreas_g"
    If you want to do some debugging, then you should have a look at audio.c, Audio_Output_Init(), where the sample rate is set.

    In audio.c, it says

    request.channels = 2; /* stereo */

    But in PulseAudio volume control, Previous has mono output. So that seems a bit fishy to me.


    After you 'request' audio, you need to check what you got back.  I was going through some crazy hell with Quake2 and Basilisk with SDL on this... some fine cards when you ask for 11025 you get 12000 ... which may look close enough but I never could tell why the pitch was off, until someone had a card that only did 44100 ...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 26, 2015, 04:07:55 pm
    I see. The code is not tested with different sample sizes. So that crash is somehow "ok". But the mono/stereo difference from PulseAudio and Previous might well be the cause for the distortion. That would mean, that the problem is related to SDL2/PulseAudio interfacing. If we are lucky, we are not the first to run into this problem. I'll search the internet.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 26, 2015, 04:21:01 pm
    Quote from: "andreas_g"I see. The code is not tested with different sample sizes. So that crash is somehow "ok". But the mono/stereo difference from PulseAudio and Previous might well be the cause for the distortion. That would mean, that the problem is related to SDL2/PulseAudio interfacing. If we are lucky, we are not the first to run into this problem. I'll search the internet.


    This is the hell I went through with SDL to find out just because you 'request' doesn't mean it's what you got.


           SDL_AudioSpec desired, obtained;
           int desired_bits=8;//16;

           /* Set up the desired format */
           desired.freq = 8192;//44100;   //11025? 22050?
           switch (desired_bits) {
                   case 8:
                           desired.format = AUDIO_U8;
                           break;
                   case 16:
                           if ( SDL_BYTEORDER == SDL_BIG_ENDIAN )
                                   desired.format = AUDIO_S16MSB;
                           else
                                   desired.format = AUDIO_S16LSB;
                           break;
                   default:
                           printf("not 8 or 16 sound!?\n");
                           return false;
           }
           desired.channels = 1;//2;
           desired.samples = 8192;//2048;
           desired.callback = stream_func;

           /* Open the audio device */
           if ( SDL_OpenAudio(&desired, &obtained) < 0 ) {
                   printf("Couldn't open SDL audio: %s\n", SDL_GetError());
                   return false;
           }
           switch (obtained.format) {
                   case AUDIO_U8:
                           /* Supported */
                           break;
                   case AUDIO_S16LSB:
                   case AUDIO_S16MSB:
                           if ( ((obtained.format == AUDIO_S16LSB) &&
                                (SDL_BYTEORDER == SDL_LIL_ENDIAN)) ||
                                ((obtained.format == AUDIO_S16MSB) &&
                                (SDL_BYTEORDER == SDL_BIG_ENDIAN)) ) {
                                   /* Supported */
                                   break;
                           }
                           /* Unsupported, fall through */;
                   default:
                           /* Not supported -- force SDL to do our bidding */
                           SDL_CloseAudio();
                           if ( SDL_OpenAudio(&desired, NULL) < 0 ) {
                                   printf("Couldn't open SDL audio: %s\n",
                                                           SDL_GetError());
                                   return false;
                           }
                           memcpy(&obtained, &desired, sizeof(desired));
                           break;
           }
           SDL_PauseAudio(0);
    D(bug("SDL_Audio inited!\n"));

           D(bug("sample bits %d\n",obtained.format&0xff));
           D(bug("speed/freq %d\n",obtained.freq));
           D(bug("channels %d\n",obtained.channels));
           D(bug("samples %d\n",obtained.samples));
    printf("SDL_Audio inited %dbit, %dHz, %d channels\n",obtained.format&0xff,obtained.freq,obtained.channels);


    It was mostly in there from Basilisk, but it wasn't until I printed out all the obtained structure did I see that it was giving me different stuff... I guess in retrospect it kind of makes sense.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 26, 2015, 04:35:01 pm
    neozeed, i think you are right. Obviously in this case we don't get what we requested. Fixing this would require routines to convert our sound data to suit the granted setup, in case it does not match the requested setup. This is not a trivial task. Maybe someone with good audio skills can do it.
    For now i'm afraid we have to live with this or maybe just disable sound output if requested does not match granted.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 04:59:27 pm
    Following neozeed's suggestion, I've added a few printf's to the code. Looks like we do get stereo output as requested.

    According to the printf's, Audio_Output_Init() is called twice. Could that also be a problem?

    $ grep zzz output.txt
    zzz AUDIO wanted 36880
    zzz CHANNELS wanted 2
    zzz AUDIO obtained 36880
    zzz CHANNELS obtained 2
    zzz AUDIO wanted 36880
    zzz CHANNELS wanted 2
    zzz AUDIO obtained 36880
    zzz CHANNELS obtained 2



       printf("zzz AUDIO wanted %u\n", request.format);
       printf("zzz CHANNELS wanted %u\n", request.channels);
       if (Audio_Output_Device==0) /* Open audio device */
       {
           Log_Printf(LOG_WARN, "Can't use audio: %s\n", SDL_GetError());
           DlgAlert_Notice("Error: Can't open audio output device. No sound output.");
           bSoundOutputWorking = false;
           return;
       }
       printf("zzz AUDIO obtained %u\n", granted.format);
       printf("zzz CHANNELS obtained %u\n", granted.channels);
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 26, 2015, 05:03:33 pm
    well that's bizzare.. check the bitrate too for the heck of it.. I donno that's just weird.

    How do other SDL based audio apps work on your setup?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 05:10:33 pm
    Quote from: "neozeed"well that's bizzare.. check the bitrate too for the heck of it.. I donno that's just weird.

    How do other SDL based audio apps work on your setup?

    I've never really noticed any problems, particularly not with mono or stereo mistakes like this. Of course I could try some SDL2 apps to see what Pavucontrol thinks of them in terms of mono or stereo.

    When does Audio_Input_Init() get called? We request a mono stream there, so maybe PulseAudio helpfully "adjusts" all our streams to mono? With PulseAudio you never know what craziness lurks behind the next corner, so everything is possible.  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 26, 2015, 06:09:49 pm
    Quote from: "neozeed"well that's bizzare.. check the bitrate too for the heck of it..

    Obtained bitrate is 44100 as requested.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 27, 2015, 02:53:48 am
    the init/unint is more a function of previous starting up configured one way then I guess it parses the config file, resets to match that, and if you change anything it'll reset again......   if that makes any sense

    So for example here I'm running under OS X with no logging, and I added in some printf's for the audio

    Building CPU, 45961 opcodes (3 1 0)
    CPU=68030, MMU=68030, FPU=68882 ($20), JIT=0.
    - reset
    Memory init: Memory size: 64MB
    Mapping ROM at $00000000: 128kB
    Mapping main memory bank0 at $04000000: 16MB
    Mapping main memory bank1 at $05000000: 16MB
    Mapping main memory bank2 at $06000000: 16MB
    Mapping main memory bank3 at $07000000: 16MB
    Mapping mirrors of main memory for memory write functions:
    Function0 at $10000000
    Function1 at $14000000
    Function2 at $18000000
    Function3 at $1C000000
    Mapping video memory at $0b000000: 256kB
    Mapping mirrors of video memory for memory write functions:
    Function0 at $0C000000
    Function1 at $0D000000
    Function2 at $0E000000
    Function3 at $0F000000
    Mapping device space at $02000000
    Read ROM 65536
    Sound_Reset
    sound_uninit
    sound_init
    SDL_OpenAudio requeted 44100 36880 2 1024
    SDL_OpenAudio granted 44100 36880 2 1024
    FIXME: Resolution_Search
    done.
    Memory init: Memory size: 64MB
    Mapping ROM at $00000000: 128kB
    Mapping main memory bank0 at $04000000: 16MB
    Mapping main memory bank1 at $05000000: 16MB
    Mapping main memory bank2 at $06000000: 16MB
    Mapping main memory bank3 at $07000000: 16MB
    Mapping mirrors of main memory for memory write functions:
    Function0 at $10000000
    Function1 at $14000000
    Function2 at $18000000
    Function3 at $1C000000
    Mapping video memory at $0b000000: 256kB
    Mapping mirrors of video memory for memory write functions:
    Function0 at $0C000000
    Function1 at $0D000000
    Function2 at $0E000000
    Function3 at $0F000000
    Mapping device space at $02000000
    Read ROM 65536
    Sound_Reset
    sound_uninit
    Audio_Output_UnInit
    sound_init
    SDL_OpenAudio requeted 44100 36880 2 1024
    SDL_OpenAudio granted 44100 36880 2 1024
    FIXME: Resolution_Search
    68030 MMU enabled. Page size = 8192


    So once I booted up into NS 0.8 and played some audio (which sounds choppy and slow, previous eats 100% of my CPU so my MacBook Air just isn't up to the task I guess) but it plays and it doesn't keep on re-initing the audio.. That's more of a booting thing.

    Also since I can't display the full screen, it's kind of hard to use, but remember F10 is the power key, to make turning off so much easier.... lol I assume it does the shutdown...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 27, 2015, 06:08:22 am
    If the requested and granted audio setup matches, then it might really be a problem on the host side or with the SDL2/host interface. It is normal, that Previous calls the init functions more than once in certain conditions. That should not cause any problems. But to be sure you could introduce a flag, that prevents the reset function to execute more than once:

    snd.c, line 48, Sound_Reset() --> insert something like this:
    void Sound_Reset(void) {
       static bool first_init = true;
       if (first_init) {
           first_init = false;
           sound_uninit();
           sound_init();
           if (sound_output_active && sndout_inited) {
               Audio_Output_Enable(true);
           }
       }
    }
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 27, 2015, 09:58:21 am
    I think initing twice is because the NeXT computer plays a short test sound during booting, and then the second init for playing the Jobs audio.

    Also, my interpretation of Pavucontrol was wrong; we do get stereo output from Previous after all. Pavucontrol just defaults to a combined view for stereo sources, so it looked like mono. You have to click a button to see both channels separately. My mistake. :oops:

    I've noticed the NS error sound seems to play OK. I accidentally leaned on the Space bar in one of the included NS 2.2 demo apps and got a sound not unlike changing volume on OS X. It did not sound garbled to me. Of course it's a short sound so it's difficult to judge.

    Maybe my CPU is just too slow to keep up with longer sounds from the emulator. It's a Pentium G630 2.7 GHz, so definitely not the fastest around. If CPU speed is the issue here, I think Previous should inform you about that though. Does Hatari/Previous have frame skipping options I could try?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 27, 2015, 10:23:57 am
    Your problem is not related to CPU speed (but you might experience that one too), because then you would see longer play times with short portions of sound alternating with short pauses.

    The init function is only called on startup and during resets. Before doing further investigations, I recommend to try my above code that prevents from calling the init function twice.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 27, 2015, 10:56:40 am
    OK, I've tried your code, but the audio problems persist.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 28, 2015, 02:17:45 am
    for what its worth, on osx 10.10.4 i cant change the preferences file.  And then i deleted it, and it wont safe when trying to recreate.

    The ui buttons just stick down, with no action happening.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 30, 2015, 10:01:30 am
    Quote from: "neozeed"
    I just wonder how bad the shitstorm will be when github looses VC funding what is going to happen there?

    It was just announced they got another $250 million, so I wouldn't worry about it at the moment.  :D  http://www.wsj.com/article_email/github-raises-250-million-at-2-billion-valuation-1438206722-lMyQjAxMTA1NjI1OTEyNzk0Wj
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on July 30, 2015, 10:04:45 am
    Quote from: "Morn76"
    Quote from: "neozeed"
    I just wonder how bad the shitstorm will be when github looses VC funding what is going to happen there?

    It was just announced they got another $250 million, so I wouldn't worry about it at the moment.  :D  http://www.wsj.com/article_email/github-raises-250-million-at-2-billion-valuation-1438206722-lMyQjAxMTA1NjI1OTEyNzk0Wj


    further proof it's 2001 all over again.

    they can't be worth more than $10MM tops.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Morn76 on July 30, 2015, 11:06:14 am
    Quote from: "neozeed"
    further proof it's 2001 all over again.

    they can't be worth more than $10MM tops.

    One of these days Microsoft will take them over and thus kill all open source projects in one fell swoop. Only .Net-based projects will be allowed from then on.  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on August 06, 2015, 01:11:42 am
    not that it matters, but the cmake system on mingw is hopelessly screwed up.

    from botched sdl2 detection, to constantly trying to inject MSVC into mingw, to screwing up all the paths, and circular cmakefiles nonense references.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on August 06, 2015, 06:05:29 am
    It seems there are quite a lot of platform specific problems with Previous. At the moment I have no time to fix them. I prefer to work on the emulator core. Making Mac OS usable via daydream is my next goal. After that I am thinking about adding printing capabilities (to a file).

    I think the other problems might be not too hard to fix for someone with some SLIRP, SDL or Cmake skills. It does not require to know the inside stuff of the emulator itself.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on August 06, 2015, 06:19:43 am
    Quote from: "andreas_g"It seems there are quite a lot of platform specific problems with Previous. At the moment I have no time to fix them. I prefer to work on the emulator core. Making Mac OS usable via daydream is my next goal. After that I am thinking about adding printing capabilities (to a file).

    I think the other problems might be not too hard to fix for someone with some SLIRP, SDL or Cmake skills. It does not require to know the inside stuff of the emulator itself.


    printing would be cool overall.. sigh I just get tripped up with cmake and how it goes in circles.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on August 06, 2015, 11:26:39 am
    Quote from: "andreas_g"After that I am thinking about adding printing capabilities (to a file).

    That reminds me... now that we have networking, I've been meaning to set up printcap to print to OS X.  With CUPS, OS X can share printers via lpd, so NeXT can print to them.  It's what I used to do with my real NeXTs, which I documented somewhere on this forum.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on August 14, 2015, 02:19:57 pm
    Compiled 1.1 on ubuntu x64 and it's working flawlessly... But I was wondering what the key combination to get back to the config menu was so I can switch floppies (going to try Adobe Illustrator)?

    Once again, many thanks for the incredible job done on Previous, just a shame that slirp prevents proper NetInfo interaction on the LAN.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on August 14, 2015, 02:45:57 pm
    Quote from: "Noth"Compiled 1.1 on ubuntu x64 and it's working flawlessly... But I was wondering what the key combination to get back to the config menu was so I can switch floppies (going to try Adobe Illustrator)?


    Should be F12
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on August 14, 2015, 03:15:06 pm
    Quote from: "neozeed"
    Quote from: "Noth"Compiled 1.1 on ubuntu x64 and it's working flawlessly... But I was wondering what the key combination to get back to the config menu was so I can switch floppies (going to try Adobe Illustrator)?


    Should be F12


    Tried F12, alt-F12, right ctrl-alt-F12, no dice.
    Title: What Needs to be done for a NeXT Emulator
    Post by: dnwills on August 14, 2015, 08:32:51 pm
    Quote from: "Noth"Tried F12, alt-F12, right ctrl-alt-F12, no dice.

    With OS X it's ctrl-fn-F12.  Probably won't help with ubuntu.

    -- David
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on August 14, 2015, 09:47:40 pm
    Quote from: "dnwills"
    Quote from: "Noth"Tried F12, alt-F12, right ctrl-alt-F12, no dice.

    With OS X it's ctrl-fn-F12.  Probably won't help with ubuntu.

    -- David


    It doesn't... It's ctrl-alt-o ! Sorry for the noise, it's actually all indicated in the keyboard submenu.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on August 15, 2015, 09:23:38 am
    By the way, to keep your Previous install looking like a true NeXT machine, don't forget to install the BlackIcons package so you get the right coloured icons!

    EDIT: Also I find using keyscans rather than keysymbols gives me a better result with keyboards...
    Title: What Needs to be done for a NeXT Emulator
    Post by: dnwills on August 15, 2015, 12:58:31 pm
    Quote from: "Noth"Also I find using keyscans rather than keysymbols gives me a better result with keyboards...

    Actually, I'm finding the reverse with OS X.  With "Scancode" in "Keyboard options" I don't get the "\|" and "`~" keys.  With "Symbolic" I do get those.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on August 15, 2015, 08:19:13 pm
    Quote from: "dnwills"
    Quote from: "Noth"Also I find using keyscans rather than keysymbols gives me a better result with keyboards...

    Actually, I'm finding the reverse with OS X.  With "Scancode" in "Keyboard options" I don't get the "\|" and "`~" keys.  With "Symbolic" I do get those.


    This is in ubuntu 64bit gnome3/Unity. The only problem is the left windows key keeps to being mapped to Unity stuff depending on combo. so win-h hides a window in Previous but win-q will close Previous. Oh well... I'm just glad to have sorted mouse speed, keyboard stuff and disc/k swapping via menu.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on August 18, 2015, 08:16:21 am
    So I found a dump of NS2.0 on vetusware.com (free registration to download and all that). I can restore it to a disk using restore rf /path/to/dump but when I try to boot it it hangs on "insert disk optical disk" when using an 040 Cube or 030 Next Computer. I tried prepariing an OD device but couldn't work out how to mount it beyond creating it with dd if=/dev/zero of=next.mo bs=512 count=524288 and inserting that device as a MO drive. Thanks in advance (I don't normally get stuck like this...)!
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on August 18, 2015, 09:44:33 am
    you can download dd images I initially created from winworldpc.com. most versions were installed to a 2GB CF card (never booted after install finished).

    https://winworldpc.com/product/nextstep/2x

    or, you could get the whole collection of images of almost every system release:
    https://mega.co.nz/#!h0IRgRLT!WiceqJA2LIhPbWJZvR6CmJstPZwOdZrun8gYo1e-Row
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on August 18, 2015, 10:22:30 am
    Quote from: "Noth"I tried prepariing an OD device but couldn't work out how to mount it beyond creating it with dd if=/dev/zero of=next.mo bs=512 count=524288 and inserting that device as a MO drive. Thanks in advance (I don't normally get stuck like this...)!

    If you want to use the MO drive emulation, you have to use the empty.ecc.od image, that comes with Previous. It is not possible to use simple empty files or images created with dd for that purpose. The provided MO image contains empty sectors (all 1, not 0) and some special factory programmed sectors.

    You can insert that empty optical disk image and for example use restore on it or use BuildDisk to make it bootable.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on August 18, 2015, 01:19:59 pm
    Thanks both of you, I'll give it another try.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on September 09, 2015, 05:02:54 pm
    Hello all,

    it took some time, but i have a new release of Previous ready:
    You can load Previous v1.2 for Mac OS X here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.2.zip).

    The most significant change is compatibility with daydream/darkmatter. There should also be a noticeable change in mouse movement handling. Feedback about the new mouse handling is very welcome.

    I hope you enjoy the latest release! Unfortunately i was not able to fix all reported issues. Any help is welcome.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on September 10, 2015, 12:49:35 pm
    Thanks for the update, Andreas.  I haven't done much with Previous lately, but I'll install and check this one out.

    ---

    Edited to add:

    I like the new mouse handling so far.  Overall, 1.2 is a very solid build.  The NFS problem I previously reported persists, but then I haven't sent any information to you about how to reproduce it, so that's on me. :)  And, even after I send that info, it might not be something you can work around.

    Also, I had an idea today: since you support both scancode and symbolic keyboards, would it be possible to remap the host's alt key to the NeXT's command key?

    When I use the scancode keyboard setting, some keys don't work (notably the ~/` key on my US keyboard), but they do work in symbolic setting.  I don't know if that's a bug.  Also, I think that was the same prior to 1.2, and that I'm only just now reporting it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: one2rock on September 11, 2015, 08:12:35 pm
    Quote from: "andreas_g"Hello all,

    it took some time, but i have a new release of Previous ready:
    You can load Previous v1.2 for Mac OS X here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.2.zip).

    The most significant change is compatibility with daydream/darkmatter. There should also be a noticeable change in mouse movement handling. Feedback about the new mouse handling is very welcome.

    I hope you enjoy the latest release! Unfortunately i was not able to fix all reported issues. Any help is welcome.


    Hi Andreas,

    Is the newest version of Previous v1.2 available as a win32 build?
    Alternatively, is the latest source code availble for download?

    Best regards.
    Michael
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on September 12, 2015, 03:36:41 pm
    thank you andreas! the mouse movement is much better IMHO. I prefer the following values: setting linear adjustment to 0.1 for locked mode and 0.5 for unlocked mode and leaving exponential adjustment at default (1.0).

    regards,
    michael
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on September 13, 2015, 08:11:19 am
    Hello eagle! The emulated command key is mapped to the command key of the host system. Is there a special reason, you'd like to have it mapped to alt? I guess it is the host system shortcut conflict? The problem is, when i map command to alt i need another mapping for alt, which can only be command  :wink:  Then the shortcut conflict would happen with the alt key. That needs to be resolved in SDL, instead of re-mapping the keys.

    For the ~/ key: That one didn't exist on the NeXT keyboard. ~ is mapped to shift-esc and shift-numlock and / is left to the right shift key.
    A method to re-map keys was requested multiple times. It is somewhere on my TODO-list.

    one2rock, unfotunately there is no win32 build at the moment. But you can load the code at http://sourceforge.net/p/previous/code/HEAD/tree/branches/branch_mmu/ and try to compile. Be aware that it was reported to be very tricky to make it compile on Windows because of Cmake and because it won't work with MSVC. I don't have Windows running myself. So i could not test that.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on September 13, 2015, 05:33:26 pm
    Quote from: "andreas_g"Hello eagle! The emulated command key is mapped to the command key of the host system. Is there a special reason, you'd like to have it mapped to alt? I guess it is the host system shortcut conflict?


    This is exactly it.  On OS X and on NeXT, the command key is used for all kinds of shortcuts.  I don't know that I ever used alt on the NeXT.  Also, when running a NeXT OS in VMware Fusion, the alt key works as a command key in the NeXT OS (this is true for NeXTSTEP 3.3, OPENSTEP 4.2, and Rhapsody DR1 and DR2).  I was thinking that it would be nice to have something similar in Previous.

    QuoteThe problem is, when i map command to alt i need another mapping for alt, which can only be command  :wink:  Then the shortcut conflict would happen with the alt key. That needs to be resolved in SDL, instead of re-mapping the keys.


    I totally get that, now that I see that the NeXT keyboard had an alt key (my keyboards are all in storage, so I had to google for an image).

    QuoteFor the ~/ key: That one didn't exist on the NeXT keyboard. ~ is mapped to shift-esc and shift-numlock and / is left to the right shift key.
    A method to re-map keys was requested multiple times. It is somewhere on my TODO-list.


    Sorry, I meant the ~` key.  On the NeXT keyboard, it's at the top left of the numeric keypad, but on my US keyboard it is to the left of the 1 key on the top row.

    I'm off to play some more with Previous! :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on September 13, 2015, 05:51:11 pm
    The backquote/tilde key is mapped to numlock with scancode mapping. That physical place matches the one on the NeXT keyboard. Does that cause problems? It of course might be mapped to the key left to 1. I'll have a look.

    I could introduce an option to swap command and alt keys. That might help the circumstance, that the alt key is not needed very often. But it might also introduce new guest/host conflicts.

    I'll see what i can do.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 04, 2015, 09:37:12 am
    Previous v1.3 is out!

    With the help of Simon Schubiger i was able to add NeXT Laser Printer emulation to Previous. The new version can now print to PNG files. You can load Previous v1.3 for Mac OS X here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.3.zip).

    @eagle: The new version also contains a fix for the ~` key and a new option for swapping command and alt keys.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on October 04, 2015, 12:20:52 pm
    you two have been quiet, busy bees  :P  thank you andreas and simon, once more! happy to see that Previous is still under active development  8)
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on October 04, 2015, 06:10:54 pm
    Quote from: "andreas_g"Previous v1.3 is out!

    With the help of Simon Schubiger i was able to add NeXT Laser Printer emulation to Previous. The new version can now print to PNG files. You can load Previous v1.3 for Mac OS X here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.3.zip).

    @eagle: The new version also contains a fix for the ~` key and a new option for swapping command and alt keys.


    Andreas, wow, these are excellent updates!  Thanks for the cmd/alt swap option!  No more conflict between OS X cmd and NeXT cmd!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on October 05, 2015, 12:07:17 pm
    Great news ! I have updated the Previous information page (http://com-emu.pixub.com/doku.php/emulator/previous) to the latest version.

    * Now with printing to PNG available, can you add other output formats too ? (TIFF, Postscript/PDF, JPEG(?))

    * Do you have any plans to emulate the Serial Communication Controller for serial port and modem capability (last missing feature of the NeXTcube/NeXTstation)
    * Some time earlier, you said that the interrupt emulation system of Previous might need an overhaul. What is the current state about this ?

    * Besides that there are only 2 features still missing from Previous: NeXTdimension graphics board for 24-bit graphics and NeXTbus for clustering of NeXTcube boards

    Thank you again very much for your hard work !
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 05, 2015, 02:56:46 pm
    Quote from: "andreas_g"Previous v1.3 is out!

    With the help of Simon Schubiger i was able to add NeXT Laser Printer emulation to Previous. The new version can now print to PNG files. You can load Previous v1.3 for Mac OS X here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.3.zip).

    @eagle: The new version also contains a fix for the ~` key and a new option for swapping command and alt keys.


    Wow!! Thanks! Thanks! Thanks!  :D  :D  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 05, 2015, 03:07:41 pm
    Quote from: "Kitchen2010"* Besides that there are only 2 features still missing from Previous: NeXTdimension graphics board for 24-bit graphics and NeXTbus for clustering of NeXTcube boards

    I'm not sure if I want NeXTDimension: it's a sad product for me. Having a graphics board so powerful that can run its own OS, with an i860 processor which has specialized instructions for 3D graphics, and only being able to use it as a plain dumb framebuffer is a sad experience. I'll never understand why NeXT did this. According to the docs of the DAC in the NeXTStation Color, there're models of such DAC supporting 24bit color. It would have been much wiser to support 24bit color through that path.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on October 05, 2015, 03:48:09 pm
    Andreas, I'm a glutton for punishment: I just tried to copy a file to my NFS server... Previous 1.3 still crashes, and that's exactly what I expected it would do. :)

    One of these days I need to send some instructions to you...
    Title: What Needs to be done for a NeXT Emulator
    Post by: M Paquette on October 05, 2015, 06:23:06 pm
    Quote from: "ardi"Having a graphics board so powerful that can run its own OS, with an i860 processor which has specialized instructions for 3D graphics, and only being able to use it as a plain dumb framebuffer is a sad experience. I'll never understand why NeXT did this. According to the docs of the DAC in the NeXTStation Color, there're models of such DAC supporting 24bit color. It would have been much wiser to support 24bit color through that path.


    Good thing NeXT didn't do that, huh?
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 05, 2015, 09:24:48 pm
    Quote from: "M Paquette"
    Quote from: "ardi"Having a graphics board so powerful that can run its own OS, with an i860 processor which has specialized instructions for 3D graphics, and only being able to use it as a plain dumb framebuffer is a sad experience. I'll never understand why NeXT did this. According to the docs of the DAC in the NeXTStation Color, there're models of such DAC supporting 24bit color. It would have been much wiser to support 24bit color through that path.


    Good thing NeXT didn't do that, huh?

    Well, don't take my comment too seriously. It's just that seeing an i860 underexploited in such way makes me sad. But at least it's used for accelerating BitBLT,and with good performance results, so it's not 100% idle (although NeXT wouldn't have chosen the i860 if they knew it was only going to be used for BitBLT: they planned to use it for PostScript and for 3D graphics, that's why they chose a powerful RISC processor rather than a cheaper BitBLT ASIC).

    Anyway, back to emulation, I'm not sure it will be possible to accurately emulate it. The "easiest" part will be to get a working i860 emulator (I say it's "easy" because the i860 is documented, although I'm not aware of any working emulator at this time). The hardest part would be to emulate the rest of the board. And it would be really hard because not only it's undocumented, but because only an small part of its potential was ever exploited, so, even if you got access to secret documentation, you wouldn't be able to fully test it with any software as it doesn't exist.

    Of course maybe there's another way of emulating it: intercept the graphics display calls from the OS, try to decipher them, and implement only the DAC and BitBLT commands. Not a real emulation of the board, but it would look the same as a real emulation because only that functionality is used.
    Title: What Needs to be done for a NeXT Emulator
    Post by: M Paquette on October 06, 2015, 02:07:20 am
    Quote from: "ardi"
    Well, don't take my comment too seriously. It's just that seeing an i860 underexploited in such way makes me sad. But at least it's used for accelerating BitBLT,and with good performance results, so it's not 100% idle (although NeXT wouldn't have chosen the i860 if they knew it was only going to be used for BitBLT: they planned to use it for PostScript and for 3D graphics, that's why they chose a powerful RISC processor rather than a cheaper BitBLT ASIC).


    ...planned to...

    Yeah, and also implemented.

    All PostScript marking operations (the drawy thingie PostScript does to make graphics, text, etc) goes through pipelined dual instruction mode code on the i860.  All the NeXT/PIXAR compositing algebra extensions are also running through tight code on the i860.

    All RenderMan operations routed via Hydra to the ND board for display are also accelerated, again using tightly coded dual instruction mode rendering.

    The ND board IS running 24 bit color, with an additional 8 bits per pixel in all window buffers for transparency data in support of the NeXT/PIXAR compositing algebra.  The BrookTree DAC leverages the transparency information provided to manage the live video overlay (controlled via NXLiveVideoView).

    There's a NeXTdimension forum here:  http://www.nextcomputers.org/forums/viewforum.php?f=8

    If you have any questions or are confused by the information I've provided please ask over there, and let's let the Previous folks get on with their good work.  I think Andreas is aware that emulating the ND board takes a bit more than implementing BitBlt and whatever you think DAC commands are.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 06, 2015, 05:22:26 am
    Quote from: "M Paquette"All PostScript marking operations (the drawy thingie PostScript does to make graphics, text, etc) goes through pipelined dual instruction mode code on the i860.  All the NeXT/PIXAR compositing algebra extensions are also running through tight code on the i860.

    All RenderMan operations routed via Hydra to the ND board for display are also accelerated, again using tightly coded dual instruction mode rendering.

    Any pointers to back this info? I searched hard over the years to find the API needed for getting the NeXT-promised performance for Gouraud triangles, and concluded 3D acceleration was planned and discarded.

    Wikipedia also says that DisplayPostscript was planned but never implemented, resulting in the i860 being used only for BitBLT (the exact quote is "Display Postscript never actually ran on the board so the Intel i860 never did much more than move blocks of color data around")
    https://en.wikipedia.org/wiki/NeXTdimension

    Any source available talking about accelerated 3D or accelerated Postscript belong to the release marketing literature, or from emails from people who believed the brochures without being developers, so they never used any API that confirmed the acceleration, just believed the brochures.

    Of course I'll be happy to move this to the ND forum, but I believe this is of interest for Previous, because there's a substantial difference in emulating just the BitBLT and DAC (framebuffer and display control) commands, or emulating a real ND (which is actually a whole computer, running its own operating system)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 06, 2015, 07:04:28 am
    Thank you all for the nice words!

    Quote from: "Kitchen2010"* Now with printing to PNG available, can you add other output formats too ? (TIFF, Postscript/PDF, JPEG(?))

    * Do you have any plans to emulate the Serial Communication Controller for serial port and modem capability (last missing feature of the NeXTcube/NeXTstation)
    * Some time earlier, you said that the interrupt emulation system of Previous might need an overhaul. What is the current state about this ?

    * Besides that there are only 2 features still missing from Previous: NeXTdimension graphics board for 24-bit graphics and NeXTbus for clustering of NeXTcube boards

    From what I know JPEG is not suitable for 1 bit black and white graphics. Generally it won't make sense to use a lossy compression format as the graphics are only a few kB using lossless compression. PostScript and PDF also do not make too much sense, as we can't benefit from their features. The printer data does not contain vector data. It is plain black and white pixel data. Also it is not possible to make multi-page documents, because there is no way to reliably tell the beginning and the end of a document. Furthermore depending on the OS version and preferences the pages are printed in normal or reverse order. TIFF would be an option, but I do not see any benefits over PNG.

    At the moment there are no plans to implement serial ports. I don't see any useful applications for it. Networking can be done using Ethernet without the need for an emulated modem.

    The interrupt handling of Previous has been good for a long time. Maybe then I was talking about the interrupt handling of the DSP. That has already been corrected. Or maybe I was talking about timings. They are still inaccurate.

    NextBus is not difficult to emulate (ignoring the timings). It is just some ID registers and forwarding memory access depending on the address. There is already code for it in Previous. But it is not used because multiple CPU boards are not supported. That would require a major rewrite of the code.

    About the NeXTdimension:
    I think it would be really great to have it running, because I'd love to see 24-bit graphics in Previous. I was thinking about two possible ways to implement it (same as ardi pointed out):
    1. Write a full emulation, which requires writing an i860 CPU emulator and having a copy of the NeXTdimension ROM. That should be theoretically possible, but would be very time consuming and definitely not easy. But I think after having the i860, about 90 % of the work is done. There are almost no devices on the NeXTdimension board. Advantage: emulation would be accurate and work with all possible software. Disadvantage: this would at least double the system requirements of Previous, pushing even modern host computers to their limits.
    2. Write some kind of interpreter for the driver calls. That would require to decode the driver's communication protocol and implement the PostScipt display drawing routines. It would require quite a lot of reverse engineering and learning. Advantage: Certainly more efficient under emulation, no ROM and no knowledge of the hardware required. Disadvantage: Less reliable and will only work with certain software (drivers).

    I'd definitely prefer the first way. But even if one would not run into problems (which is unlikely) it would require an amount of time that I just do not have. So I think we have to live without the NeXTdimension.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on October 06, 2015, 08:29:29 am
    Thank you all for the feedback !

    To answer back:
    • support for printing output formats for some more loss-less bitmap formats (TIFF, GIF) would be nice (but is not mandatory !). What library did you use for PNG ? If it is a multi-format library, it might be just about setting some toggles.

    • There are several serial ports, in fact:
      2x RS-423 serial ports
      1x DSP I/O port (Supports direct I/O access to the DSP)
    The later one would be interesting when you plan to complete the emulation of the MC56001 DSP.

    • NeXTbus emulation should be done when emulation of the NeXTcube board is complete. It is actually a kind of NuBus. I think, there was only 2 boards ever made to fit: the NeXTcube motherboard itself and the NeXTdimension graphics board.

    • There was actually one feature of the NeXTdimension board that was planned but not implemented: MJPEG video compression support. (Wikipedia: "An onboard C-Cube CL550 chip for MJPEG video compression was announced, but never shipped. A handful of engineering prototypes for the MJPEG daughterboard exist, but none actually function.")

    • Information about the NeXTdimension is unclear if there was actually any PostScript/Compositing/Renderman acceleration implemented. Can someone with the real hardware board check what is really accelerated ?

    • Low-Level emulation is always the best if you want compatibility with all the software, but it is very hard to get all the information and it rises the emulator's demands. High-Level emulation is faster and easier to implement (you just need to decode the commands sent by he driver).
    Why not make both approaches and let the emulation user choose what fits best to his demands ? Make a low-level emulation, starting with an i860 processor emulator (that will take much time) and make a high-level emulation either by intercepting the driver's command or implementing a fake graphics card and programming a driver for it (like the uaegfx in WinUAE emulator).

    • NeXTdimension emulation should be regarded as long-time goal (taking at least another 5 years of development). So maybe it should be put back until more information about the hardware (graphics board, i860 processor) is collected. We should first concentrate on completing the emulation of the DSP M56001 processor to get the full sound capabilities.
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on October 06, 2015, 10:43:33 am
    For those who do not know this, please note that Mr. Paquette was the lead engineer for the NS windowing system and for the ND implementation at NeXT...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 06, 2015, 11:31:01 am
    Quote from: "Kitchen2010"• support for printing output formats for some more loss-less bitmap formats (TIFF, GIF) would be nice (but is not mandatory !). What library did you use for PNG ? If it is a multi-format library, it might be just about setting some toggles.

    • There are several serial ports, in fact:
      2x RS-423 serial ports
      1x DSP I/O port (Supports direct I/O access to the DSP)
    The later one would be interesting when you plan to complete the emulation of the MC56001 DSP.

    • NeXTbus emulation should be done when emulation of the NeXTcube board is complete. It is actually a kind of NuBus. I think, there was only 2 boards ever made to fit: the NeXTcube motherboard itself and the NeXTdimension graphics board.

    • There was actually one feature of the NeXTdimension board that was planned but not implemented: MJPEG video compression support. (Wikipedia: "An onboard C-Cube CL550 chip for MJPEG video compression was announced, but never shipped. A handful of engineering prototypes for the MJPEG daughterboard exist, but none actually function.")

    • Information about the NeXTdimension is unclear if there was actually any PostScript/Compositing/Renderman acceleration implemented. Can someone with the real hardware board check what is really accelerated ?

    • Low-Level emulation is always the best if you want compatibility with all the software, but it is very hard to get all the information and it rises the emulator's demands. High-Level emulation is faster and easier to implement (you just need to decode the commands sent by he driver).
    Why not make both approaches and let the emulation user choose what fits best to his demands ? Make a low-level emulation, starting with an i860 processor emulator (that will take much time) and make a high-level emulation either by intercepting the driver's command or implementing a fake graphics card and programming a driver for it (like the uaegfx in WinUAE emulator).

    • NeXTdimension emulation should be regarded as long-time goal (taking at least another 5 years of development). So maybe it should be put back until more information about the hardware (graphics board, i860 processor) is collected. We should first concentrate on completing the emulation of the DSP M56001 processor to get the full sound capabilities.

    For deciding on which of these feature requests should be implemented, I have two questions:
    What would be the benefits of having support for other image formats than PNG?
    What could an emulated serial port (RS-423) or DSP port be used for?

    Previous uses libpng for creating the PNG files. Emulation of the DSP is almost complete, but it seems to have some minor bugs (most likely arithmetic) that cause heavy distortions in some cases.
    Another reason for sound not being played correctly is bad timings. But that only affects special cases and will be very hard to fix.

    My goals for the next release of Previous are fixing the remaining DSP bugs (except for timings) and fix the reported crash in Slirp (or add an alternative library like PCAP --> neozeed, we need you!).

    I have no specific plans for the NeXTdimension. I do not agree that the "high level" implementation will be easier to do. I think both implementations would require advanced knowledge, although in a slightly different area.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 06, 2015, 12:57:24 pm
    Quote from: "t-rexky"For those who do not know this, please note that Mr. Paquette was the lead engineer for the NS windowing system and for the ND implementation at NeXT...

    I certainly didn't know that. [EDIT: deleted the guesses I was doing here about the ND because, to my shame, I didn't realize M Paquette replied to a thread I started about this topic time ago]
    Read the thread because he gives very interesting details there:
    http://www.nextcomputers.org/forums/viewtopic.php?t=3452

    I considered that thread "closed" too early, and missed M Paquette contributions.

    Btw, Andreas, after reading that thread, my impression is that a high level emulation is not possible (at least it's not reasonably feasible if you want Display Postscript and QuickRenderMan to work, as well as any other features that the ND might be doing too and we don't suspect now).

    Much "easier" the low-level emulation. But note the quotation-marks around "easier" :wink:
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 06, 2015, 12:58:43 pm
    Quote from: "andreas_g"
    My goals for the next release of Previous are fixing the remaining DSP bugs (except for timings) and fix the reported crash in Slirp (or add an alternative library like PCAP --> neozeed, we need you!).

    Yes, the NFS write crash has very high priority for me :wink:

    [EDIT: After reading the intro doc about 3DKit, I think I might love to see the NeXTDimension emulation. It must be hard to emulate, but what you get from QuickRenderMan running on top of 3DKit is awesome: http://lisp.gotgeeks.com/Documentation/OPENSTEP/NextDev/Conversion/3.3_Reference/GeneralRef/17_3DKit/Intro3DKit.htmld/
    M Paquette please be kind and provide hints so that these guys can do this stuff!! :wink: (well, of course I'm not asking you to reveal any NDA docs you're not legally entitled to undisclose, just the hints you can actually and legally provide)  ]
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on October 07, 2015, 10:27:16 am
    Thanks for answering !

    • PNG is just fine but I wondered if support of some other lossless bitmap formats could be added with no costs. You used libpng, so you would need more work to add other formats. That is not worth at this point.

    • You could think about support of a vector format though, preferable PostScript, if you cannot get by any other ways inside the NeXTstep OS. (Is it possible to print into a .ps file in NeXTstep, can anyone report ?)

    • Use of the serial port could be:
     - Null modem between 2 NeXT computers (running several instances of the emulator)
       ("http://www.nextcomputers.org/NeXTfiles/Docs/modem_cables.pdf")
     - running the NeXT computer headless (NetBSD support this)
       ("https://www.netbsd.org/ports/next68k/faq.html")
     - for low-level debugging purposes over the serial port (this the main point why you would want this)

    • Use of the DSP port could be:
     - digital sound input (microphone) and output (speakers) which might be interesting if you really want use the DSP and NeXTTime software. (There was even some DSP software that emulated an analog modem)
       ("https://books.google.de/books?id=JzsEAAAAMBAJ&pg=PA23&lpg=PA23&dq=next+DSP+port&source=bl&ots=binZxA7X-E&sig=sgwQgNlBzpFLxq0hETXfjFd77_I&hl=de&sa=X&ved=0CCwQ6AEwBGoVChMI9sX814ewyAIVDOkUCh025QAI#v=onepage&q=next%20DSP%20port&f=false")
     - SoundKit and MusicKit used it. There was even some DSP/sound cards (AST M16, i*link i56) for supplying a M56001 DSP and DSP port for the 486 version of NeXTstep.
      ("http://www.kevra.org/TheBestOfNext/ThirdPartyProducts/ThirdPartySoftware/InputOutputAndStorage/i56-DSPandSoundCard/i56-DSPandSoundCard.html")
      ("http://www.kevra.org/TheBestOfNext/ThirdPartyProducts/ThirdPartySoftware/InputOutputAndStorage/AST-M16/AST-M16.html")
      ("http://www.nextcomputers.org/NeXTfiles/Audio/MusicKit/MusicKit.4.1.README")

    • NeXTdimension emulation:
     Low-Level emulation would be quite laboursome (writing an i860 emulator, collecting some information with the real board) but would be pay out in the end by better compatibility and easier fixing of emulation bugs.
     The High-Level approach needs someone with very good knowledge of the NeXTstep graphics system and ability to patch all the drawing call functions. This approach would pay out if you intend to create a fake graphics card where the host system will do the heavy lifting of the NeXtdimension's work.
     I agree with you that the Low-Level approach is more straightforward than the latter one.

    • If someone wants to start writing an i860 cpu emulation, here is everything useful I could find on the internet:
      ("http://bitsavers.trailing-edge.com/pdf/intel/i860/")

    • Thank you very much for adding DSP emulation for sound support. It is very appreciated having sound working in Previous !

    • I agree with you that fixing of the already implemented features must have higher priority over implementing newer ones. I just wanted to point you to what still can be done to make Previous even better.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Noth on October 10, 2015, 09:59:09 pm
    Quick question, were's the codebase living at currently? The svn base on sourceforge is only sync'ed to 1.2...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 11, 2015, 07:00:38 am
    @Noth:
    The code is still hosted on sourceforge at http://sourceforge.net/p/previous/code/HEAD/tree/. The current releast version is usually in trunk, the latest development version is in branch_mmu.


    @Kitchen2000:
    It is not possible to obtain vector data from the data, that is sent to the printer. Therefore it does not make sense to use a vector format just to embed the bitmap data. But you can create PostScript files from the Print dialog in NeXTstep.
    The descriped uses for the serial port and DSP port all require interfacing with the host. I think the DSP stuff will be quite hard to interface. Interfacing the serial port should be possible, but has no priority for me at the moment.

    I am still thinking about which would be the best or feasible way to emulate NeXTdimension. It might or might not be done. I'll annouce any significant progress here.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 11, 2015, 10:12:54 am
    Quote from: "andreas_g"
    I am still thinking about which would be the best or feasible way to emulate NeXTdimension. It might or might not be done. I'll annouce any significant progress here.

    I've the perception that it can need the same amount of effort that has been put in Previous until now. It's like a computer inside a computer. Yes, it doesn't have peripherals like disk controller, network, keyboard, etc, but on the other hand you've to write the i860 emulator from scratch so I think the effort might be comparable.

    In other words, you'll need spare time for doing this. But, on the other hand, if you do this, you'll be the first developer writing a working emulator for an accelerated display board of a UNIX workstation. Nobody has emulated UNIX accelerated graphics AFAIK (in a working status, I mean).

    BTW, did the ND have any ROM?

    That's important to know...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 12, 2015, 07:26:08 am
    I absolutely agree that emulating the i860 would take quite a lot of time. Please follow this thread for more details about the ROM and emulating NeXTdimension in general:
    http://www.nextcomputers.org/forums/viewtopic.php?t=3677
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on November 12, 2015, 04:18:32 pm
    Quote from: "andreas_g"If you want to use the MO drive emulation, you have to use the empty.ecc.od image, that comes with Previous. It is not possible to use simple empty files or images created with dd for that purpose. The provided MO image contains empty sectors (all 1, not 0) and some special factory programmed sectors.

    You can insert that empty optical disk image and for example use restore on it or use BuildDisk to make it bootable.
    If I have a DD image of a magneto-optical disk, how do I create a valid bootable MO file for Previous?

    Previous is working really well!

    Only occasionally, it causes the emulated VM to hang or crash and reboot - is there any useful information I can collect from some log file and supply it to you to help find the bug that causes these things?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on November 12, 2015, 04:50:58 pm
    tomaz, unfortunately it is a little bit complicated to copy that data back to an MO drive image. First you need to get your dd image into the emulated machine. You can for example put it in a CD-ROM image (using disk utility, create image from folder and select hybrid-image hfs+/iso/udf).

    After that you need to insert the empty.ecc.od that comes with Previous into the emulated MO drive and initilize it from NeXTstep. Finally you can dd your image back to the MO drive.

    There is no direct way to make an image from a magneto-optical disk bootable, because the dd program of NeXTstep does not copy the essential boot sector. It is created during initialization and some tables in it are updated with every write access.

    About your crash: Are you using NeXTstep 3.x and some 68040 system? Do you see a panic window (small console window with some kernel messages in it) when it crashes? If yes, can you spot the line "MMU invalid descriptor during table walk"?
    That is something i saw rarely. It might be related to some SCSI disk I/O timings. But so far i have not found a way to reproduce it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on November 12, 2015, 05:23:31 pm
    Quote from: "andreas_g"tomaz, unfortunately it is a little bit complicated to copy that data back to an MO drive image. First you need to get your dd image into the emulated machine. You can for example put it in a CD-ROM image (using disk utility, create image from folder and select hybrid-image hfs+/iso/udf).

    After that you need to insert the empty.ecc.od that comes with Previous into the emulated MO drive and initilize it from NeXTstep. Finally you can dd your image back to the MO drive.

    There is no direct way to make an image from a magneto-optical disk bootable, because the dd program of NeXTstep does not copy the essential boot sector.
    Do you have the layout of the sectors in your magneto-optical file documented? And is the calculation of the additional (I guess ECC) bits documented? We could make a utility which generates the right kind of file to run on the host OS?

    Quote from: "andreas_g"About your crash: Are you using NeXTstep 3.x and some 68040 system? Do you see a panic window (small console window with some kernel messages in it) when it crashes? If yes, can you spot the line "MMU invalid descriptor during table walk"?
    That is something i saw rarely. It might be related to some SCSI disk I/O timings. But so far i have not found a way to reproduce it.
    Yes, I am using NeXTstep 3.0 on NeXTstation TurboColor. I had Previous crash three times:

    1- the first time it was Previous 1.2, while I was running Installer.app in the VM to install the literature package, and all I saw was that the machine rebooted (it crashed while I was away)

    2- the second time it was also Previous 1.2, after I ran Installer.app to install the same package again, and the machine just froze (the mouse would not move, a colour graphics screen of NextStep was showing, and I had to kill Previous) some time after successfully installing the package (again, I let it run in the background and did something else while it was doing it, so I don't know exactly at what point it froze)

    3 - the third time it was Previous 1.3, and Previous itself crashed while booting up the VM.

    In none of the cases did I get a "MMU invalid descriptor during table walk" message.

    I have two Mac OS X .crash files, and /var/log/system.log messages, would any of that help?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on November 12, 2015, 07:03:16 pm
    I already tried to build valid MO images, but finally it turned out to be impossible. NeXTstep maintains a list in the disk label that describes which sectors are valid/empty/faulty/etc. The label is not contained in the image which means the information is simply lost. It is impossible to rebuild the list from an image.

    About the crash:
    The error message is only visible for a very short time just before it reboots. So if you where away, you had no chance to see it. But from your description i guess it is the same crash, that i experienced a few times. I most likely happened during heavy SCSI disk I/O in the installation process. Was the image that was used to boot when it crashed build with some early (pre 1.0) version of Previous?

    About the crash of Previous 1.3:
    It would be very useful to see the contents of the .crash file. Just send me a PM or an e-mail using the forum's e-mail function. Thanks!
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 21, 2015, 11:29:31 pm
    hi andreas, hi simon

    mike paquette posted a bunch of NeXTdimension test binaries in another thread.
    these might be of use in the future to verify the emulated dimension board...

    https://www.dropbox.com/sh/52it7p1rzriank8/AACeNqox0M6qybpdvvzZmiQwa?dl=0


    regards,
    michael
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on November 22, 2015, 12:01:52 am
    Quote from: "mikeboss"hi andreas, hi simon

    mike paquette posted a bunch of NeXTdimension test binaries in another thread.
    these might be of use in the future to verify the emulated dimension board...

    https://www.dropbox.com/sh/52it7p1rzriank8/AACeNqox0M6qybpdvvzZmiQwa?dl=0


    regards,
    michael


    I'm going to FTP them to the archives as well! Best Regards Rob Blessin
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on November 22, 2015, 10:08:14 pm
    mikeboss, thank you for the hint! Although we are a little stuck with the NeXTdimension at the moment, this will certainly be useful once we get back to it.

    Right now i am hunting a DSP bug. But to confirm, that it is a real bug it would be great if someone could test this on real hardware:
    Using NeXTstep 1.0x start the Mandelbrot demo and run it once with the default parameters and once with X: -0.1, Y: -0.1, Scale: 2, Depth: 3, Colors: 2. Please post a picture of the resulting patterns.

    Thank you in advance!
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 23, 2015, 11:36:33 am
    since there are glitches visible after running it on real hardware, I assume the emulation of the DSP is OK...





    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 23, 2015, 12:01:30 pm
    hm, but something else cought my eye: on real hardware, there's some dithering visible in the light grey area whereas on the emulated system there's no dithering visible! isn't that strange?




    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on November 23, 2015, 12:50:16 pm
    mikeboss, thank you for testing! I definitely did not expect this! How could they get this past Steve Jobs for release? So I've spent some hours hunting a bug that never existed   :roll:
    Maybe next time I'll ask here for testing first.

    For the dithering: As I think this might be controlled by some global system function, did you test with the exact same system version? The only other thing that comes to my mind is that it might be somehow related to the brightness settings. Previous has no adjustable brightness and tells the OS it is on maximum brightness.

    Comparing the real system dithering with the emulated one it seems that not only there is no dithering in the light grey are, but the dithering in the dark grey has horizontal layout whereas on real hardware it has diagonal layout.

    To make sure I do not hunt another non-existing bug: Can someone test on NeXTstep 0.9, DSPMusic Demo and run "Adagio"? Is the audio distorted after a few seconds?
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 23, 2015, 02:29:09 pm
    I ran the mandelbrot again on the cube (double checked: brightness is/was set to maximum). same result, dithering differs from the emulated one. both systems, emulated and real, are running the exact same NeXTSTEP-image I created some time ago: release 1.0a

    edit:
    dithering on the cube is always the same, no matter what level of brightness I set...
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 23, 2015, 03:24:11 pm
    forum-member "pl212" created screenshots of 1.0a some time ago ->
    http://www.nextcomputers.org/forums/viewtopic.php?t=3088

    the two greys differ from the ones I'm getting in Previous.

    screenshots from Previous RGB85 & RGB170
    screenshots from user pl212 RGB102 & RGB152


    unfortunately forum-member "pl212" never disclosed the procedure about how to create screenshots in release 1.0a
    http://www.nextcomputers.org/forums/profile.php?mode=viewprofile&u=957
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 23, 2015, 03:49:58 pm
    the values of the two greys varies throughout the screenshots from "pl212". hmm, need to know how to create screenshots on the cube running 1.0a!
    Title: What Needs to be done for a NeXT Emulator
    Post by: M Paquette on November 23, 2015, 04:02:52 pm
    The generation of "Mandelbrot" figures is floating point intensive.  In particular, the fine details that appear in the renderings are closely related to the maximum precision of the floating point calculations as the function is iterated many, many times.

    The FPU has 80 bit registers (64 bit mantissa, sign bit, and 15 bit signed exponent)

    The 56K DSP is a fixed point processor with 24 bit data words and registers that can be ganged for a 48 bit word, and 56 bit accumulators.

    The different levels of precision produce different results when used to solve heavily iterative math.  That shows up in the displayed results.  (And yes, Prof. Crandall had to explain this to Mr. Jobs...)
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 23, 2015, 04:08:57 pm
    Quote from: "M Paquette"(And yes, Prof. Crandall had to explain this to Mr. Jobs...)

    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on November 25, 2015, 10:02:45 am
    Quote from: "mikeboss"the two greys differ from the ones I'm getting in Previous.

    screenshots from Previous RGB85 & RGB170
    screenshots from user pl212 RGB102 & RGB152

    The greys in Previous are hardcoded. Every pixel is bound to two bits in VRAM and can be 00 (white), 01 (light grey), 10 (dark grey) or 11 (black). These 4 combinations are hardcoded in Previous to RGB255, RGB170, RGB85 and RGB0. The values have been selected arbitrarily and could be changed to different values. There is no known "signal" from the OS to change the greys and I also do not know of a way to get the RGB representation of the greys from NeXTstep. It would be really interesting how user pl212 obtained the screenshots and especially how the greys in the screenshots were calculated.


    Mr. Paquette, thank you for the explanation and for the little Steve Jobs anecdote. This is what I would have expected.   :wink:
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 25, 2015, 12:08:14 pm
    Quote from: "andreas_g"It would be really interesting how user pl212 obtained the screenshots and especially how the greys in the screenshots were calculated.


    I wrote peter (pl212) a PM. not read yet... I'm on it. trying to contact him via twitter now.
    Title: What Needs to be done for a NeXT Emulator
    Post by: pl212 on November 26, 2015, 04:37:26 pm
    Hi all! There are two ways... for small sections, launch Icon.app.  Create a new document (Window -> New).  Then hit Special > Screengrab... The cursor changes to a crop tool; drag a rectangular box around what you want.  Save as TIFF (and be prepared to experience the world of the Tagged Image File Format circa 1989.... lots of incompatibilities!!)

    The other method, for full screenshots, I will post as soon as I remember! (doing research now...)
    Title: What Needs to be done for a NeXT Emulator
    Post by: pl212 on November 26, 2015, 04:40:59 pm
    Ah yes! For fullscreen screenshots, use Scene.app. Both Icon and Scene are in /NextDeveloper/Demos.

    Scene can actually do both fullscreen and sections... it's essentially the predecessor of "Grabber.app" that shipped in later versions. I only see an EPS export so far, but that probably includes the TIFF data encoded therein.

    [/img]
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on November 26, 2015, 10:02:04 pm
    Quote from: "andreas_g"These 4 combinations are hardcoded in Previous to RGB255, RGB170, RGB85 and RGB0.


    so, after finally being able to create screenshots in NS 1.0 (thanks peter!) I can confirm that the RGB values used in Previous are 100% correct. this dithering issue is a total mistery to me...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on November 27, 2015, 05:19:58 pm
    This is indeed a strange issue. One would need to know how the dithering is calculated to find the exact cause. But i think there is some floating point stuff involved. The small differences might point to a rounding or precision issue with the emulated FPU.

    Just an idea ...
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on November 30, 2015, 03:45:18 pm
    Any chance that this issue arises only by dithering a 32-bit (8R8G8B+8alpha, 16.8m colors) screen to a 16-bit (4R4G4+4alpha, 4096 colors) output screen (as you usually do in a color NeXTstation or color NeXTcube without an installed NeXTdimension gfx board) ?

    Dithering might occur in the graphics hardware just when generating the video signal for the monitor using some advanced technique comparable to:
    • <a href="https://en.wikipedia.org/wiki/Frame_rate_control">Frame rate control</a> (temporal dithering used in modern TN LC displays)
    • <a href="http://www.bytecellar.com/2005/02/09/my_hp_9000_7126/">HP Color Recovery</a> (de-dithering on HP 8-bit color hardware, maybe NeXT used a similar technique to do the opposite ?)

    Probably, the graphics saved in the graphics memory is in full color, and all screen grabs (which are just the gfx memory contents) are so too. That means the dithering is in the monitor signal only (= only viewable on real hardware).
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on December 15, 2015, 08:08:19 am
    The contents of the video RAM are exactly what you see on the screen. I still think the dithering issue is most likely caused by some minor FPU incorrectness.

    Only the NeXTdimension board has enough VRAM to hold 32-bit pixel data (4 MB). NeXTstation Color has 2 MB and monochrome systems have only 256 kB.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on December 15, 2015, 08:34:41 am
    Quote from: "andreas_g"The contents of the video RAM are exactly what you see on the screen. I still think the dithering issue is most likely caused by some minor FPU incorrectness.

    Only the NeXTdimension board has enough VRAM to hold 32-bit pixel data (4 MB). NeXTstation Color has 2 MB and monochrome systems have only 256 kB.


    http://www.nextcomputers.org/NeXTfiles/Docs/Hardware/nextstation_color.pdf is the original brochure, I know I read somewhere it was actually 24 bit color that "emulated 32 bit?" may be that is the cause....
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on December 15, 2015, 12:10:59 pm
    Quote from: "Rob Blessin Black Hole"http://www.nextcomputers.org/NeXTfiles/Docs/Hardware/nextstation_color.pdf is the original brochure, I know I read somewhere it was actually 24 bit color that "emulated 32 bit?" may be that is the cause....

    Are you thinking of 24-bit color (8 bits per R/G/B) plus 8 alpha channels?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on December 17, 2015, 05:23:13 pm
    I really don't think that the cause is in the way data stored in VRAM is displayed. In fact that part is quite simple:

    monochrome systems:
    256 kB VRAM for 1048576 pixels with 2 bit each:
    11 = black, 10 = dark grey, 01 = light grey, 00 = white

    color systems:
    2 MB VRAM for 1048576 pixels with 16 bit each:
    4 bit unused, 4 bit red, 4 bit green, 4 bit blue --> 4096 colors

    dimension:
    4 MB VRAM for 1048576 pixels with 32 bit each:
    8 bit unused, 8 bit red, 8 bit green, 8 bit blue --> 16777216 colors

    Actually there are only 958464 pixels displayed on the screen. The off-screen VRAM is used for data during the boot process. The unused bits in the color pixels are maybe used for alpha (transparency) data by software. There is no hardware use for these bits. There is also no hardware 32-bit to 16-bit conversion or anything similar. These things are done by software.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on January 10, 2016, 10:25:50 pm
    For all those following this thread some good news are here:
    http://www.nextcomputers.org/forums/viewtopic.php?p=21909&highlight=#21909

    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 10, 2016, 10:44:14 pm
    How beautiful! My favorite detail is the i860XR notification at the bottom 8)

    BTW, how powerful was the i860 compared to current Intel Core processors? Is it feasible to get near real-time emulation for the 68040 + the i860 in the ND board?

    My only concern now is how to hack NeXTSTEP so that it survives the Y2038 end of the UNIX world, because if I live that long I'm going to wish continue using Previous  8)

    Thanks a lot for this great work!!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: gtnicol on January 11, 2016, 03:05:40 am
    Large round of applause needed for that one!
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on January 11, 2016, 10:52:30 am
    Wow, Andreas, you continue to amaze.  Thank you for your work!
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on January 11, 2016, 12:08:21 pm
    You're welcome. It is fun working on this. Most work on the NeXTdimension side has been done by Simon (schubige). He ported the i860 emulation code from MAME (originally written by Jason Eckhardt) to Previous and re-implemented some features that have been removed for MAME and fixed some bugs. Some things, like dual instruction mode, are still missing. So the i860 is work in progress. But we are confident, that a full emulation will be possible.

    For the speed question: At the moment the timings of the 68k are wrong. Furthermore the relation of 68k and i860 speed is also wrong. In the current state I can't tell, if real-time emulation is possible. But if it is, it would definitely require a host system with good single thread performance.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on January 13, 2016, 10:10:19 am
    Thank you very much, Andreas, for implementing the NeXTdimension graphics card as a feature ! I cannot await the next release of Previous.

    Now almost all important features of the black NeXT hardware are emulated (at least in a rudimentary way). Next goal of the development should be to make the emulator more accurate (e.g. timings) and correct (e.g. colours). Almost certainly, a more accurate emulator will be slower (e.g. if the 68k processor is cycle-exact emulated with prefetching and cache), so it would be nice for the emulator to have a FAST mode, skipping everything that makes emulation slow and is not needed for operation (like Previous now does), and a EXACT mode, implementing everything to perfect emulation on the cost of speed.

    Later on, one could try to fit a Just-in-Time compiler (JIT) for the emulated processor cores (68k, 56k, i860), to make a VERY FAST mode. At least for the 68030/40 processor there is an existing JIT available in the WinUAE emulator, which is already used in some other emulators, too.
    Title: i860 dual instruction mode
    Post by: schubige on January 13, 2016, 08:15:33 pm
    The (in)famous dual instruction mode of the i860 is getting into gears. It's heavily used by the PostScript driver as well as the QuickRenderMan running on the NeXTdimension (see http://1drv.ms/22ZVVfF).  Unfortunately, the Intel i860 manual is verry blurry about some details. Thus if there is some i860 wizard (ideally someone who worked on the i860 CPU or close to the CPU designers) in the forum or if you know someone: I have a few very specific questions. Thanks, Simon  :-) :-)
    Title: Re: i860 dual instruction mode
    Post by: ardi on January 14, 2016, 10:49:25 am
    Quote from: "schubige"The (in)famous dual instruction mode of the i860 is getting into gears. It's heavily used by the PostScript driver as well as the QuickRenderMan running on the NeXTdimension (see http://1drv.ms/22ZVVfF).  Unfortunately, the Intel i860 manual is verry blurry about some details. Thus if there is some i860 wizard (ideally someone who worked on the i860 CPU or close to the CPU designers) in the forum or if you know someone: I have a few very specific questions. Thanks, Simon  :-) :-)

    Wow, there's a QuickRenderMan test in that screenshot!! :shock:

    Regarding the i860, I don't have low-level experience with it, but just had the idea that perhaps you could build a cross-compiler that generates i860 code (in whatever OS you use to work daily: it should be possible to build an i860 crosscompiler in OS X, Linux, BSD, etc...) and maybe it could help you to address some questions by looking at the generated code. I know, not the kind of help you asked for, but I'm pointing it in case it can be of help.
    Title: RIB Test
    Post by: schubige on January 14, 2016, 02:18:19 pm
    Could anyone with a real NeXTdimension system check if the following RIB file can be viewed in 3View.app? (open it - takes a while - and then rotate or move it a bit) It renders sometimes with Previous but usually crashes the NeXTdimension. I wonder if it actually works on a real system.
    https://onedrive.live.com/redir?resid=85F82C85086387B5!58505&authkey=!AHTFiRkLEZcWGHk&ithint=file%2crib
    Thanks!
    Simon

    Update: it seems to crash Previous only with OpenStep 4.2. NeXTStep 3.3 seems to work fine. So if you can test, please test with OpenStep 4.2.
    Title: Re: i860 dual instruction mode
    Post by: cbrunschen on January 14, 2016, 02:29:02 pm
    Quote from: "schubige"Unfortunately, the Intel i860 manual is verry blurry about some details.


    By "the Intel i860 manual" you refer to the several manuals that are available on Bitsavers (http://bitsavers.trailing-edge.com/pdf/intel/i860/), I presume?
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on January 14, 2016, 02:31:50 pm
    Yes, I was referring to these manuals.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on January 17, 2016, 10:33:24 am
    Would this article, i860 microprocessor internal architecture (http://www.sciencedirect.com/science/article/pii/014193319090143J) by Neal Margulis (https://www.linkedin.com/in/nealmargulis), be of use? I don't have a copy, but I'd be happy to pitch in to buy a copy for anyone working on this.

    (The article's author, Neal Margulis, might well know useful things, but his LinkedIn profile states "I started my career at Intel. Other than the people I worked with, I don't want to do anything related to semiconductors ever again so I don't list those jobs." so I am guessing he'd rather not be approached / involved.)
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on January 17, 2016, 11:03:22 am
    Thanks for the reference. In the meantime I found the bug myself and it looks like the i860 emulation works pretty much as expected now. No more pixel garbage, see: http://1drv.ms/1RYaKKu. I did a few optimisations and the i860 runs now also in a separate thread. The performance on my MacBook Pro is between 20 and 50 million i860 instructions per second which is pretty close to what the real hardware achieved.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on January 17, 2016, 12:32:33 pm
    Quote from: "schubige"Thanks for the reference. In the meantime I found the bug myself and it looks like the i860 emulation works pretty much as expected now. No more pixel garbage, see: http://1drv.ms/1RYaKKu. I did a few optimisations and the i860 runs now also in a separate thread. The performance on my MacBook Pro is between 20 and 50 million i860 instructions per second which is pretty close to what the real hardware achieved.


    That sounds and looks absolutely awesome. I am so looking forward to seeing this in action and effectively finally having the NeXTDimension cube I never could afford :)

    I wonder, will Previous allow more than one NeXTDimension card to be emulated at the same time - allowing simulation of the 4-headed (one mono + 4 color monitors) monster? On a multi-core host, with some luck one might end up running the main 68040 and each i860 on one host core each, which could give a great emulated experience. Hmmm ... ! :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 17, 2016, 07:41:49 pm
    Quote from: "schubige"Thanks for the reference. In the meantime I found the bug myself and it looks like the i860 emulation works pretty much as expected now. No more pixel garbage, see: http://1drv.ms/1RYaKKu. I did a few optimisations and the i860 runs now also in a separate thread. The performance on my MacBook Pro is between 20 and 50 million i860 instructions per second which is pretty close to what the real hardware achieved.

    Great!! It's great news that you run the i860 in a separate thread! It's certainly the best way for emulating the ND. If the 68K timings are better adjusted to its realtime performance, it might even help the emulator in being more efficient. But last time I looked at the code, I didn't manage to understand how it manages CPU timings.
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on January 17, 2016, 08:17:24 pm
    Quote from: "schubige"... the i860 runs now also in a separate thread ...

    A thought - would it be possible (I wonder) to run the NeXTDimension simulation as its own process? After all, the boards talking through NeXTBus could in a way be seen as separate computers on a network. Indeed it might be interesting to be able to distribute emulation of a cube and an ND card or two across different computers, potentially, each with its own display ... !
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on January 18, 2016, 12:22:29 pm
    Quote from: "cbrunschen"A thought - would it be possible (I wonder) to run the NeXTDimension simulation as its own process? After all, the boards talking through NeXTBus could in a way be seen as separate computers on a network. Indeed it might be interesting to be able to distribute emulation of a cube and an ND card or two across different computers, potentially, each with its own display ... !


    While technically possible, performance would be very poor because each NeXT bus transfer would have to go through the network. Transfers are usually small (often just 4 bytes) and the overhead would be not worth it. Furthermore, because the NeXTbus does not support hot-plugging of boards, Previous would need to manage startup and shutdown of these (distributed) NeXTdimension board processes. Very complicated... The current thread-based solution has the advantages of a (fast) shared memory space as well as easy startup & shutdown control. Here is a screenshot of a dual-screen setup with Previous: http://1drv.ms/1JUwINq
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on January 18, 2016, 02:22:45 pm
    Quote from: "schubige"
    Quote from: "cbrunschen"would it be possible ... to run the NeXTDimension simulation as its own process?


    While technically possible, performance would be very poor because each NeXT bus transfer would have to go through the network. Transfers are usually small (often just 4 bytes) and the overhead would be not worth it.


    I wonder whether over a modern, switched gigabit ethernet, the performance might still be acceptable for at least some uses; after all, the NeXTbus specification (http://www.nextcomputers.org/docs/NeXTbus_Specification.pdf) says "The NeXTbus has a basic cycle rate of 12.5 MHz, and a mechanism that allows data burst transfers to occur at a rate of 25 MHz. This results in a NeXTbus peak data transfer rate of 100 Mbytes/second"; so gigabit ethernet is in approximately the same ballpark, speed-wise.

    Quote from: "schubige"Furthermore, because the NeXTbus does not support hot-plugging of boards, Previous would need to manage startup and shutdown of these (distributed) NeXTdimension board processes.


    At least in theory it could be done by keeping the processes separate: Start the NeXTDimension processes, each listening on a port for a connection from the main process; then start the main process, telling it where the different NeXTDimension cards are listening. This would move the complexity of starting the processes outside the emulators themselves, and allow possibly even a mix of same-host and remote cards; and could possibly be extended to allow other NeXTbus cards to be emulated (not that there's a huge need for that really).

    Quote from: "schubige"The current thread-based solution has the advantages of a (fast) shared memory space as well as easy startup & shutdown control.


    Absolutely it's easier and faster within a single host and with shared memory!

    That said, I do like the idea of the flexibility that this might bring: most graphics cards support on or two monitors, so in order to be able to simulate a 4-headed cube with 4 physical monitors connected, it might be less expensive to have a couple of computers with two monitors each, rather than one computer with multiple graphics cards.

    (Consider a simulated multi-headed cube built from a couple of Raspberry Pis, each driving one or two monitors ...)

    Quote from: "schubige"Here is a screenshot of a dual-screen setup with Previous: http://1drv.ms/1JUwINq

    That looks awesome. Kudos, lots of them!
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 18, 2016, 02:24:47 pm
    Quote from: "schubige"[...]The performance on my MacBook Pro is between 20 and 50 million i860 instructions per second which is pretty close to what the real hardware achieved.

    Let me suggest to implement a limitation so that the emulator won't surpass the real i860 performance. I'm going to get a powerful new box in the next weeks, and I'd prefer to get a realistic impression of the real ND performance when you release it  8)
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on January 18, 2016, 09:23:24 pm
    Quote from: "ardi"
    Quote from: "schubige"[...]The performance on my MacBook Pro is between 20 and 50 million i860 instructions per second which is pretty close to what the real hardware achieved.

    Let me suggest to implement a limitation so that the emulator won't surpass the real i860 performance. I'm going to get a powerful new box in the next weeks, and I'd prefer to get a realistic impression of the real ND performance when you release it  8)


    I quite like having the ability to set a system to either attempt to emulate a particular speed (usually the original speed inasmuch possible) or simply "run as fast as possible", to allow running compatible software while getting the benefit from at least some advancements in performance.
    Title: Video Playback
    Post by: schubige on January 23, 2016, 11:28:41 am
    I'm currently working on making Previous more real-time aware (branch_realtime). Until now, timing in Previous was mostly based on (virtual) CPU cycles. Depending on your host hardware, this was either faster or slower than reality. I'm linking now various time sources in the NeXT hardware (such as vertical blank, microsecond timer, sound, etc.) to the host system. Thus time elapsed inside Previous is not only counted in CPU cycles but also in microseconds elapsed in reality.

    One of the tests I do is video playback with NEXTTIME. Video playback is a great test because it heavily loads the system (I/O, decoding, sound, pumping video frame to the NeXTdimension, etc) and all that has to be synchronized and happens in real-time.

    I'm having troubles with this video http://1drv.ms/1PtSB2b. Audio stops at roughly 1:30 and shortly after, frames start to drop as well.

    Could anyone of you who has a real NeXTdimension play that video with NEXTTIME, record it e.g. with a phone-camera directly from the screen and upload/send it to me for comparison, please?

    Thanks a lot, Simon
    Title: Re: Video Playback
    Post by: ardi on January 25, 2016, 02:43:28 pm
    Quote from: "schubige"I'm currently working on making Previous more real-time aware (branch_realtime). Until now, timing in Previous was mostly based on (virtual) CPU cycles. Depending on your host hardware, this was either faster or slower than reality. I'm linking now various time sources in the NeXT hardware (such as vertical blank, microsecond timer, sound, etc.) to the host system. Thus time elapsed inside Previous is not only counted in CPU cycles but also in microseconds elapsed in reality.

    :D  :D  :D  Thanks a lot  :!:  :!:  :!:
    One of my wishes has always been to have a reasonable realtime performance in Previous. So, thanks a lot for this effort, I really appreciate it  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on February 14, 2016, 04:04:37 pm
    Hello all,

    I am happy to annouce the release of Previous v1.4! Simon did lots of work on emulating the NeXTdimension and he considerably improved timings and efficiency of Previous. Furthermore there is now a mode to accelerate the emulation beyond the performance of real systems. Other improvements and bugfixes are listed in the readme.

    Emulating the NeXTdimension board was something i thought would not be feasible. But thanks to the i860 emulator from Jason Eckhardt and the work of Simon, who improved and completed parts of it, it finally came true. I hope you enjoy it!

    You can load the binary for Mac OS X v10.6 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.4.zip).
    The binary for Windows can be found here (https://dl.dropboxusercontent.com/u/44703754/Previous_WIN32_1.4.zip).
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on February 14, 2016, 06:34:43 pm
    Quote from: "andreas_g"Hello all,

    I am happy to annouce the release of Previous v1.4! Simon did lots of work on emulating the NeXTdimension and he considerably improved timings and efficiency of Previous. Furthermore there is now a mode to accelerate the emulation beyond the performance of real systems. Other improvements and bugfixes are listed in the readme.

    Emulating the NeXTdimension board was something i thought would not be feasible. But thanks to the i860 emulator from Jason Eckhardt and the work of Simon, who improved and completed parts of it, it finally came true. I hope you enjoy it!

    You can load the binary for Mac OS X v10.6 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.4.zip).
    The binary for Windows can be found here (https://dl.dropboxusercontent.com/u/44703754/Previous_WIN32_1.4.zip).


    Great!!!!  8) I was really waiting for this release!!!! :D

    Thanks a lot for this hard work! BTW, I remember there were some SDL2-related graphics glitches in the first releases... is there any minimum recommended SDL2 version for building the source?
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on February 14, 2016, 09:33:06 pm
    Yes, minimum SDL version is 2.0.4 for Previous 1.4. And the current branch is "branch_realtime".
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on February 14, 2016, 10:00:03 pm
    Quote from: "schubige"Yes, minimum SDL version is 2.0.4 for Previous 1.4. And the current branch is "branch_realtime".

    Great, thanks a lot!!!!
    Title: Browser-based emulation...
    Post by: gtnicol on February 16, 2016, 08:57:50 pm
    https://github.com/naTmeg/ScriptedAmigaEmulator

    Imagine running NeXT emulation in a browser...
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on February 17, 2016, 08:47:05 pm
    Very cool. Impressive, most impressive.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on February 19, 2016, 09:45:29 am
    I have updated the information on the emulator for v1.4 ("http://com-emu.pixub.com/doku.php/emulator/previous").

    Congratulations to the developer team (AndreasG, Simon). You made the emulator almost perfect over the last 2 years!
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on February 19, 2016, 10:06:20 am
    Thanks for the update! I didn't know this page. Btw. the names of the developers are "Andreas Grabher" (spelled with an "h" not an "n"), and "Simon Schubiger". Most of the features under "Future Plans" are implemented by now :-). I like the screenshots on your page, especially the early ones.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on February 20, 2016, 08:17:58 am
    Quote from: "schubige"Yes, minimum SDL version is 2.0.4 for Previous 1.4. And the current branch is "branch_realtime".
    Awesome work I'll check out version 1.4 .

    If no one beats me to it I'll set up a NeXT dimension and try the video you referenced to see if it crashes.  Also want to try out the latest Darkmatter on it.

    I wonder which runs faster a PAL Dimension  or NTSC Dimension .... I happen to have both type of boards.

    Would it be possible to also emulate the Pyro Clock speed doubler 68040 25 Mhz to 50 Mhz in Previous .

    It looks like someone got a just got a screaming deal on a Pyro Cube on EBay recently ! http://www.ebay.com/itm/Next-Cube-Model-N1000-/111897664564?hash=item1a0d9edc34%3Ag%3AHbMAAOSwa-dWtZ8Z&nma=true&si=DadLiBnTmG3cAE89TKZoQYFZyZo%253D&orig_cvip=true&rt=nc&_trksid=p2047675.l2557  , if you are reading this and are the lucky buyer let me know if you need the remaining peripherals to get her up and running, I'll make you a fair deal.  



    Best Regards Rob
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on February 20, 2016, 12:56:26 pm
    Quote from: "Rob Blessin Black Hole"
    Would it be possible to also emulate the Pyro Clock speed doubler 68040 25 Mhz to 50 Mhz in Previous .


    Previous 1.4 is even better than an accelerator board: The new "Variabel" CPU clock speed option (under "System", "Customize") runs user mode code at the maximum speed of your host CPU. Kernel code still runs at the nominal clock rate of the emulated system for compatibility.
    On my laptop this results in an emulated NeXT which is almost 4 times faster than the original  :D See: http://1drv.ms/21fSYWq
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on February 24, 2016, 08:15:55 pm
    OK, I have corrected your names' spellings and added your latest screenshot. ("http://com-emu.pixub.com/doku.php/emulator/previous")
    By the way, I started this entry on wikipedia.com, but it was permanentely vandalized by some people, so I moved it to this place of a friend. I have assembled all information of Previous' progress over the years from this thread (and saved most early screenshots during the process !) because I wanted all information on one spot. I hope you like it ! :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on February 29, 2016, 04:03:30 pm
    Thanks for the corrections & screenshots. It's sad that the wikipedia article can't be updated. If anyone in the forum could do the update on wikipedia, that would be great.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on February 29, 2016, 04:09:00 pm
    I can't believe I never caught on to the "next"/"previous" naming thing.

    Anyway, Andreas, amazing work.  Thank you for your continued work.

    Hopefully at some point we will get better networking support.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on February 29, 2016, 05:02:24 pm
    @Kitchen2010:
    I think before we put the informations on Previous on Wikipedia it needs some update. The status of the components is mostly outdated. CPU, MMU, FPU can be considered complete, although there seems to be a bug in the 68882 FPU. DSP is complete, but has no interface for third party stuff. All memory is complete, nothing experimental in there. DMA channels are complete, except for un-emulated stuff (SCC and Sound input). You did not list all channels (SCSI, Sound out, Sound in, MO, Printer, SCC, DSP, Ethernet transmit, Ethernet receive, Video, Memory to memory). Ethernet hardware is implemented, but has problems with guest to host interfacing. Sound output is also fully implemented. DSP sound is working. SCSI controller is complete. Event counter has no more issues. Daydream ROM box is not emulated, but darkmatter works (that is software). NextBus is implemented. At the moment there are no specific future plans, except for bug fixes.

    @eagle:
    The networking bug is still on my mind. But the problem still is, that i can't reproduce it. Switching to libpcap might be the best solution (or maybe an option to switch between Slirp and libpcap).
    Title: What Needs to be done for a NeXT Emulator
    Post by: cbrunschen on March 01, 2016, 09:38:15 am
    Quote from: "andreas_g"@eagle:
    The networking bug is still on my mind. But the problem still is, that i can't reproduce it. Switching to libpcap might be the best solution (or maybe an option to switch between Slirp and libpcap).


    I think that an option to use a tap interface (https://en.wikipedia.org/wiki/TUN/TAP) on the host would be a good idea: open the tap character device and put ethernet packets on it / read them from it, which then would allow the host to receive them on the corresponding tap virtual ethernet interface, possibly bridging them elsewhere, could be very useful. Or for that matter a tun device, for when only IP packets will be necessary.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on March 02, 2016, 09:31:20 am
    OK, I have updated the entry using your additional information. I think it should be up-to-date now. (Link: "http://com-emu.pixub.com/doku.php/emulator/previous")

    By the way, has anyone already tried to run OpenStep 4.0 and 4.1 on Previous ?
    Near-future plans for the next versions are now fixing remaining bugs and fixing the Ethernet guest to host interfacing (via SLiRP and libpcap or TUN/TAP), right ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on March 02, 2016, 09:33:25 am
    Thanks a lot. I usually use OpenStep 4.2 with Previous 1.4. Works like the other OS versions.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 02, 2016, 10:24:48 am
    Kitchen2010, thank you for the update of the information! I think this reflects the status pretty well. Maybe one should mention that the 68030 und 68040 caches are missing and there is no cycle-exact emulation for all CPUs. I forgot about that one.

    As Simon said, OpenStep works as well as all versions of NeXTstep (OpenStep started working the same time as NeXTstep 3.3 did).

    I think this could be copied to Wikipedia as well.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on March 03, 2016, 07:41:36 pm
    Thank you !
    What is about the Motorola 56001 DSP and the Intel i860XR CPU ? Do they have the caches emulated ?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 03, 2016, 07:57:40 pm
    The instruction cache of the i860 is emulated. The data cache is not emulated.
    The DSP had no cache.

    Anyway the missing caches of the 68030, 68040 und i860XR do not have adverse effects on the emulation. They would only be necessary for cycle-exact emulation.
    Title: What Needs to be done for a NeXT Emulator
    Post by: The_Plumber on March 13, 2016, 05:35:58 pm
    Where can I find a source tarball for version 1.4 ?

    If not available, which branch should I pick on sourceforge SVN?

    Thanks
    Title: What Needs to be done for a NeXT Emulator
    Post by: madcrow on March 13, 2016, 05:40:58 pm
    What kind of CPU power does this take to run? It seems to be really choppy on my Core 2 Duo E8400 which is otherwise pretty fast at 68K emulation. I haven't even tried NeXTdimension emulation yet because even emulating 1 CPU seems slow enough!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on March 14, 2016, 09:19:10 am
    I'll be happy to upload the latest previous 1.4 tarball to the NeXTcomputers.org archive just let me know how to proceed as in where is it located currently? ! Best regards Rob
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on March 14, 2016, 09:26:24 am
    The source can be found at:

    https://sourceforge.net/p/previous/code/HEAD/tree/branches/branch_realtime/
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on March 14, 2016, 09:33:11 am
    Quote from: "schubige"The source can be found at:

    https://sourceforge.net/p/previous/code/HEAD/tree/branches/branch_realtime/



    I'm thinking may be it is best to leave the source code in one place to eliminate mixing older and newer versions as it looks like sourceforge is the go to place... if it isn't broke don't fix it!

    Yes , we welcome new developers to help Andreas and Shubige improve on Previous  amazing work .

    :idea:
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on March 15, 2016, 10:27:13 am
    I have added all the suggestions, which were made in this forum lately, to the Wiki page ("http://com-emu.pixub.com/doku.php/emulator/previous").
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on March 18, 2016, 09:35:58 am
    Quote from: "andreas_g"Hello all,

    I am happy to annouce the release of Previous v1.4! Simon did lots of work on emulating the NeXTdimension and he considerably improved timings and efficiency of Previous. Furthermore there is now a mode to accelerate the emulation beyond the performance of real systems. Other improvements and bugfixes are listed in the readme.

    Emulating the NeXTdimension board was something i thought would not be feasible. But thanks to the i860 emulator from Jason Eckhardt and the work of Simon, who improved and completed parts of it, it finally came true. I hope you enjoy it!

    You can load the binary for Mac OS X v10.6 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.4.zip).
    The binary for Windows can be found here (https://dl.dropboxusercontent.com/u/44703754/Previous_WIN32_1.4.zip).


    Hello All:  Does anyone have the NeXT Dimension Eprom file as I'll upload it to the archives...
    Any help appreciated ! Best regards Rob Blessin :P
    Title: What Needs to be done for a NeXT Emulator
    Post by: pitz on March 24, 2016, 07:23:59 am
    Quote from: "andreas_g"Hello all,

    I am happy to annouce the release of Previous v1.4! Simon did lots of work on emulating the NeXTdimension and he considerably improved timings and efficiency of Previous. Furthermore there is now a mode to accelerate the emulation beyond the performance of real systems. Other improvements and bugfixes are listed in the readme.

    Emulating the NeXTdimension board was something i thought would not be feasible. But thanks to the i860 emulator from Jason Eckhardt and the work of Simon, who improved and completed parts of it, it finally came true. I hope you enjoy it!

    You can load the binary for Mac OS X v10.6 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.4.zip).
    The binary for Windows can be found here (https://dl.dropboxusercontent.com/u/44703754/Previous_WIN32_1.4.zip).


    Congratulations and thanks to the Previous team for all the hard work!  As I posted in http://www.nextcomputers.org/forums/viewtopic.php?t=3847, it also builds and runs on the Raspberry Pi 2.

    Is the use of SDL a factor in emulation speed?  Would there be a noticeable performance improvement if a native screen mechanism is used (with, of course, loss of portability)?
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on March 24, 2016, 04:43:48 pm
    Wow, Previous 1.4 on RasPI is pretty cool. I don't think that SDL adds a lot of overhead. The current version offloads the screen blitting to a seperate thread and should perform much better than the older versions because the main thread runs only the 68k emulation and devices. Did you test it on a RasPI 3 as well? If you want to implement your own screen blitting, fast_screen.c is your starting point.
    Title: Obi Wan uses Previous!
    Post by: Rob Blessin Black Hole on March 29, 2016, 08:08:47 pm
    Hello NeXT Community :

    I thought you amazing Previous developers would enjoy knowing this :

    ***************************************

    Yes - that's cool. I've been demoing a build I got from Wave awhile back.

    Best to you!

    A

    On Mar 28, 2016, at 7:42 PM, Rob Blessin <sales@blackholeinc.com> wrote:

       name :
       Rob Blessin

       comments:
       Hello Andrew: I hope all is well! I know you will enjoy this http://www.nextcomputers.org/forums/viewtopic.php?t=2642 The Previous Emulator allows you to Emulate original NeXT 68K hardware on your Mac running OSX versions NeXTSTEP .9 through Openstep 4.2 and all the original apps as well! You can even set up a Turbo Cube Dimension Feel free to join the forum Best Regards Rob Blessin

       email:
       sales@blackholeinc.com


    Andrew Stone
    @twittelator
    http://stone.com

    **************

    Who's Andrew Stone aka  Obi Wan amazing NeXT / Apple developer

    https://www.stone.com/New.html

    http://www.macobserver.com/tmo/article/andrew_stone_app_developers_obi_wan

    Best regards Rob Blessin   Picture of Zanes , my friend Kim's son's IMac , I upgraded it to run ElCapitan and a hidden suprise Previous (he's only 8 but wants to be a computer programmer and thinks the NeXT's are cool)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on April 08, 2016, 06:39:43 am
    Quote from: "schubige"Wow, Previous 1.4 on RasPI is pretty cool. I don't think that SDL adds a lot of overhead. The current version offloads the screen blitting to a seperate thread and should perform much better than the older versions because the main thread runs only the 68k emulation and devices. Did you test it on a RasPI 3 as well? If you want to implement your own screen blitting, fast_screen.c is your starting point.
    Hello Simon and everyone on the forum: I'm thinking you all may have some knowledge about this  idea  the thread is in the Overclocking hardware section of this forum here http://www.nextcomputers.org/forums/viewtopic.php?t=3855 68040 to 68060 processor upgrade .... would it be possible to port , troubleshoot emulate this theory in Previous  then potentially create a working solution for NeXT hardware...   I found some very good links to free software to do this that is still available and included them in the post .... may be fun to try and if it works the 68060 processor is 3 times faster! Best regards Rob
    Title: What Needs to be done for a NeXT Emulator
    Post by: schubige on April 17, 2016, 08:45:08 am
    If I would ever endeavour on such a project, then I would definitely start with an emulator (Previous of course :-) ). Debugging real hardware is really time consuming and you need the right equipment to do it properly. Nevertheless, it's quite a project because there are differences in the MMU and FPU which needs to be emulated in software. This translates to a modified NeXT ROM as well as an adapted MACH kernel. Timing is also an issue although with the realtime version of Previous we have some know-how now. I would rather try to get a (faster) version of an MC68040 running in an FPGA instead of trying to hack the NeXT software to work with an MC68060. There are some interesting projects around in this area. Have a look at
    http://www.inertial.biz/index.php?title=VC68040 or http://amigabillprojects.wikispaces.com/FP68060.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on April 20, 2016, 09:42:57 pm
    Quote from: "schubige"If I would ever endeavour on such a project, then I would definitely start with an emulator (Previous of course :-) ). Debugging real hardware is really time consuming and you need the right equipment to do it properly. Nevertheless, it's quite a project because there are differences in the MMU and FPU which needs to be emulated in software. This translates to a modified NeXT ROM as well as an adapted MACH kernel. Timing is also an issue although with the realtime version of Previous we have some know-how now. I would rather try to get a (faster) version of an MC68040 running in an FPGA instead of trying to hack the NeXT software to work with an MC68060. There are some interesting projects around in this area. Have a look at
    http://www.inertial.biz/index.php?title=VC68040 or http://amigabillprojects.wikispaces.com/FP68060.


    Hello NeXT Community:  Here is the original source code for
    NeXT 56K library source code for your information

    (I uploaded here http://www.nextcomputers.org/NeXTfiles/Docs/Audio/DSP56001/   ) RB

    Greetings,

    I consulted on the NeXT machine before it was released, writing parts of the
    vector library for the Motorola 56000 signal processing chip. This was
    about 1985-1986.

    The source code for at least part of that library is here, FYI:

    Enjoy!

    --

    With regards,

    John S
    8)
    Title: What Needs to be done for a NeXT Emulator
    Post by: dtaubert on August 18, 2016, 06:32:42 pm
    Wow, you have made huge progress over the last 5 years!

    I'm having trouble getting my NeXTstation Color's 9GB hard drive image to work on previous 1.4.  It had 5 partitions to overcome the 2GB size limitations.  The first partition is fine and passes the root filesystem check.  The second partition shows clean, but the last three all fail to find the superblocks.

    [SCSI] Mode Sense: Block descriptor data: disk is read/write, size = 1165368 blocks, blocksize = 512 byte
    If I did my math right, that should be 17942584 blocks...

    Will work on getting my mac set up so that I can once again build previous from the source.
    Title: What Needs to be done for a NeXT Emulator
    Post by: dtaubert on August 19, 2016, 07:24:57 am
    Easy fix to scsi.c and it came right up!

    I had fun trying to remember my ancient account passwords.  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on August 19, 2016, 10:04:06 am
    Quote from: "dtaubert"Easy fix to scsi.c and it came right up!

    I had fun trying to remember my ancient account passwords.  :D


    You should put your fix into the original sources...
    Title: What Needs to be done for a NeXT Emulator
    Post by: dtaubert on August 19, 2016, 08:36:28 pm
    Quote from: "t-rexky"You should put your fix into the original sources...


    Done!  I'm also going to review the keyboard support to see how closely it matches the implementation that I did so long ago...
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on August 19, 2016, 09:49:26 pm
    Quote from: "dtaubert"
    Quote from: "t-rexky"You should put your fix into the original sources...


    Done!  I'm also going to review the keyboard support to see how closely it matches the implementation that I did so long ago...


    Awesome & thank you!  It is really nice to see some more activity on Previous.  It has been a bit quiet lately.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on August 20, 2016, 09:32:00 am
    Hello all,
    i am busy with many things at the moment. So for now there is no time for working on Previous. But i'm happy to see that one bug has been fixed. Just a little suggestion: Instead of using "long" better use "Uint64". This should avoid portability issues.

    If some more bug fixes find their way into the sources, i'll be glad to build another release version at some point.

    I think it would be great to have an up-to-date homepage for Previous. That would make it easier for people to find it and would also help to show this is some serious software and not just a hack by some forum users  :wink:
    Title: What Needs to be done for a NeXT Emulator
    Post by: dtaubert on August 20, 2016, 08:34:53 pm
    Quote from: "andreas_g"Just a little suggestion: Instead of using "long" better use "Uint64". This should avoid portability issues.


    The fseek() API is very old and uses long as the length type.  On 32-bit ABIs, the bug will still be present even if a 64-bit type cast is used.

    The right way to fix it everywhere is to switch to fseeko(), off_t, and #define _FILE_OFFSET_BITS 64 before including stdio.h.  This will certainly work for all linux and macosx architectures, but I didn't have a way to test it for windows.  So, I decided to stick with long to get it working on x86_64 rather than risk breaking the windows build.

    I didn't fix the %i format warning for off_t for the same reason.  I don't know if windows fully supports inttypes.h or not.
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on October 11, 2016, 01:13:53 pm
    I updated a bit the old homepage.
    Now (now means from now to some days or weeks) I will try to fix win32 cross compiling issues and probably merge back in trunk

    (for an improved stability I will compile linux/win32 targets on a virtual server and not from my laptop).
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on October 12, 2016, 03:42:21 pm
    An up to date "complete and tested" build procedure for linux ubuntu 12.04 and above is now described here:

    http://previous.alternative-system.com/index.php/build

    I'll do the same for windows cross compile under linux host.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 12, 2016, 03:48:30 pm
    Hello gilles, glad to read from you! Looking forward to some updates to the homepage. I never had the chance to test Previous on a platform other than Mac OS X. It would be great if you could fix compiling on other platforms and make some binaries available.
    In the meantime i'm curious if you have any problems with sound output causing short delays in the guest system (it seems to be not noticeable with continuous audio, but with repeated short audio, e.g. playing games).
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 12, 2016, 05:51:11 pm
    I'm also glad to see news, as well as a procedure for building in other OSs. My main machines are Macs, but I also use other OSs, so I welcome the porting instructions. Thanks a lot!
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on October 13, 2016, 07:21:05 am
    @andreas: I cannot do much test until next week because I'm 9000km from home and only with a 12'' old laptop from 2010. It can almost run at fullspeed for a 25MHz 68040 mono but screen is too small (1024x768).
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 17, 2016, 08:32:26 am
    @everyone:
    While trying to make dual MO drives work in Previous a question came up: Has anyone ever tried running two MO drives in one cube like this: one drive contains the bootdisk and the other drive contains no disk? If yes, did it work properly or have there been issues with delays and re-spinning disks?

    After lots of investigations i'm no longer sure if this is a bug in Previous or a bug in NeXTstep.
    Title: What Needs to be done for a NeXT Emulator
    Post by: gilles on October 21, 2016, 05:32:48 pm
    there is an issue with SDL2 under ubuntu 14.04 (at least on my main PC).
    I managed to fix it but with many changes. It may be a multithread issue (the renderer should be created in the thread context otherwise rendering does nothing).
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 23, 2016, 07:25:14 am
    Did you try the latest version of SDL? SDL 2.0.5 was just released a few days ago. Generally my knowledge about threads is quite poor. Simon added them to Previous, which brought quite impressive performance gains on my system. I think he might be able to help with this.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mmu_man on October 25, 2016, 09:58:30 pm
    Hi,
    I also had an issue on Debian Sid (still at SDL2 2.0.4): display doesn't get any update.
    I posted a fix in another thread (http://www.nextcomputers.org/forums/viewtopic.php?t=3949).
    It could be a regression in SDL though, but it's generally a bad idea to call things from different threads with SDL...
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 26, 2016, 09:02:34 pm
    Hello all,

    i am happy to announce the release of Previous v1.5! It uses the latest version of SDL, which supports audio recording. So now we are able to emulate audio recording via soundbox with its awesome telephone quality sound  :wink:

    Previous v1.5 also includes some bugfixes:
    - SCSI disk images greater than 4 GB are now supported (thanks to dtaubert for the patch)
    - The clock works now for dates after 1999 (don't forget to install Y2K patch for NeXTstep 3.3)
    - A problem on Linux, where no display content is shown, is now fixed (thanks to new forum user mmu_man for the patch)
    - A problem with stuck i860 thread which caused NeXTdimension to fail in some rare scenarios is gone

    I hope the new version works for everyone. You can load a binary for Mac OS X v10.6.8 or later here (https://dl.dropboxusercontent.com/u/44703754/Previous_1.5.zip).
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on October 27, 2016, 01:31:22 am
    Andreas, this is a nice update - thanks!

    Unfortunately the network issue I reported persists.  Copying files from an NFS mount eventually kernel panics the system, and copying files to an NFS mount immediately crashes Previous.app.  I didn't expect any change to that functionality, but thought I would test it with the new build.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on October 27, 2016, 06:09:20 am
    eagle, I did not make any changes to this part of the emulator. Fixing that crashing bug and the bug that causes problems with dual MO drives is on top of my list.

    For fixing the slirp crashing bug I need to reproduce it and therefore need to set up NFS on my system (host and guest). My host runs Mac OS X v10.9.5.
    For fixing the MO bug I need confirmation on real hardware. After lots of investigations I'm no longer sure if this is a bug in Previous or NeXTstep.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on October 27, 2016, 11:23:21 am
    That reminds me, I was going to email you with a set of instructions to reproduce the error.  I'll set up a VM running 10.9 and get those instructions to you.

    On the MO bug, my Cube only has one OD and it is no longer functional so I cannot test that for you.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on October 27, 2016, 09:17:58 pm
    Quote from: "eagle"That reminds me, I was going to email you with a set of instructions to reproduce the error.  I'll set up a VM running 10.9 and get those instructions to you.

    I'm also very interested in this bugfix, as it's the only way of having shared folders between Previous and the host.
    Title: Large Hard Drive support in Previous 1.5
    Post by: Rob Blessin Black Hole on December 17, 2016, 10:13:10 am
    Hello: Just taking Previous 1.5 for a spin , I like it.

    The large Hard Drive support  patch does that translate to NeXT Hardware as a patch?

    How Large of a hard drive can we now support and is it one partition ?

    I found mounting a second drive image and then initialising it copying files into it in Previous , then dding that drive image onto an sd works and mounting it on a NeXT Computer works for actually get files out of Previous and onto a NeXT , whats nice is I can download and install apps then test them and move them over to my hardware ...... not lazy about the Networking but I'm up to my eyeballs in NeXT projects lots of fun these days, appreciate all your support and business!  Still ironing out difficulties with the version 6 microsd cards but hopefully we will figure it out soon.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on December 17, 2016, 02:56:48 pm
    Hello Rob,

    no, that patch does not translate to real hardware. It was just a bug inside Previous (used 32-bit integer type for critical variable, which was too small), that prevented reading large files (on host side). So this patch won't change anything about NeXTstep's maximum partition size. That limitation is inside NeXTstep's kernel and probably other parts of the operating system.

    Best wishes,
    Andreas
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 28, 2017, 07:06:45 pm
    Would it take too much work to emulate a dual head cube? What graphics options combinations would be possible? I always work with two displays on Mac OSX, and having two Previous windows, one in each monitor, would be really useful.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on January 28, 2017, 09:53:24 pm
    This is already possible, if you use NeXTdimension. Just go to the graphics menu, enable NeXTdimension board and set "show display" to "both". As a result you will get two separate windows, one NeXTdimension color display and one monochrome display.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 28, 2017, 11:49:29 pm
    Quote from: "andreas_g"This is already possible, if you use NeXTdimension. Just go to the graphics menu, enable NeXTdimension board and set "show display" to "both". As a result you will get two separate windows, one NeXTdimension color display and one monochrome display.

    That's great! Didn't know that! Thanks a lot!!!!
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 29, 2017, 01:01:55 pm
    BTW, one more question, this one about the 68040 FPU: How are transcendental operations being emulated? Do you trigger an exception because the 68040 doesn't support them, or do you just pretend all the 68882 instructions are supported by the 68040? I'm asking this just to know if when building for an emulated Cube in Previous I should link with the alternate transcendental source code which you can find in several 68k sites, or if I'm fine using the standard math functions. I've read transcendentals impose a big performance penalty on true 68040 systems, although I never tried it myself.

    If you are emulating it accurately (issuing the exception), I might feel tempted to disable that in my personal build and pretend I have a Cube with an hypothetical "68040 Pro" :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on January 30, 2017, 06:48:38 am
    FPU emulation is the last major issue in Previous. Using native FPU routines for emulating 68k FPU instructions is very unreliable. At the moment I'm working with Toni and the Hatari community to implement arithmetic operations using SoftFloat routines. We already have the basic functions working. But emulating transcendental functions will be much more complex. Any help is welcome!

    Now to your question: Like real hardware, we raise an exception if any unimplemented instruction is executed on a 68040. The instruction is then emulated by NeXTstep. I do not recommend to force emulation with native FPU routines because as described above this is very unreliable.

    Can you point me to the alternative transcendental source code you mentioned? It might be useful for our SoftFloat implementation.
    Title: What Needs to be done for a NeXT Emulator
    Post by: ardi on January 30, 2017, 04:16:19 pm
    Yes, look here: http://www.nextcomputers.org/forums/viewtopic.php?p=21059&highlight=#21059

    And, for the code, here:
    https://ftp.nice.ch/pub/next/developer/hardware/m68k/

    Apparently this code was written for increasing the FP performance of transcendentals in the 68040. I'm not sure about their accuracy. BTW, you shouldn't need to add such code for the 68040, if you generate an exception the operating system should do the math call in software.

    BTW, did anybody have any real-world experience with this FP performance penalty on the 68040? Was it really that bad?
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on January 31, 2017, 03:39:58 am
    Quote from: "ardi"BTW, did anybody have any real-world experience with this FP performance penalty on the 68040? Was it really that bad?


    I wrote a lot of engineering code on my cube and then on the Turbo Color back in the day, the "ultimate" being a program that optimized propeller geometry using formal numerical optimization methods with penalty functions.  That code used lots of transcendentals.

    I recall that the 040 was overall much faster running the code but I cannot comment on what the performance penalty was associated with transcendentals since I never profiled it.  It run for approximately 10 minutes to fully optimize twist and chord distribution of a propeller on the 68040 Turbo.  

    On a side note, it takes under a second on my 2009 MacBook Pro...
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on March 15, 2017, 09:08:11 pm
    Calling in the calvary as  Previous and all of the talented NeXT developers will be   helpful in contributing to this fun NeXT project http://www.nextcomputers.org/forums/viewtopic.php?t=4028&start=0&postdays=0&postorder=asc&highlight=      more ram and larger harddrive support!
    8) Best Regards Rob
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on March 23, 2017, 07:00:06 pm
    Hello eagle,

    can you test if this patch (https://www.dropbox.com/s/cye3q44xhftfiv9/slirp.diff?dl=0) fixes your NFS crashing issues or any other networking issues?

    Rob, thank you for the like, but i'm afraid i can't help with that one.

    Regards,
    Andreas
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 03, 2017, 08:59:51 am
    You guys are in for a treat.  Over the weekend, andreas_g and I worked on the NFS bug (my part was limited to helping him reproduce it), and he fixed it!  It's pretty interesting that I was the only person hitting this one line of code.

    Anyway, many thanks to andreas_g for sticking to it and fixing that bug!  Previous will be immensely more useful to me now, because I now have the ability to read and write NFS shares.  Since all systems in my home network use the NFS automounter (including NeXT VMs running in Previous), I now have the ability to share filesystems between all Previous VMs.  This will make it easy to share things (both inbound and outbound) with NeXTstep/OPENSTEP running in Previous.

    For those interested in setting up the NFS automounter in NS/OS, see my howto: http://www.nextcomputers.org/forums/viewtopic.php?t=3598
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 04, 2017, 08:28:36 pm
    Hello all,

    i'm happy to announce the release of Previous v1.6! A binary for Mac OS X v10.9 and later can be loaded here (https://www.dropbox.com/s/wjss9s99ak64fpl/Previous_1.6.zip?dl=0).

    The changes include the fix for the long standing slirp crashing bug that forum user eagle helped to track down. It also includes greatly improved FPU emulation, that is now much more accurate and platform independent for the most part. The full list of changes is as follows:
     > Adds SoftFloat FPU emulation. Fixes FPU on non-x86 host platforms.
     > Adds emulation of FPU arithmetic exceptions.
     > Adds support for second magneto-optical disk drive.
     > Fixes bug that caused a crash when writing to an NFS server.
     > Fixes bug that prevented NeXTdimension from stopping in rare cases.
     > Fixes bug that caused external i860 interrupts to be delayed.
     > Fixes bug that prevented sound input under NeXTstep 0.8.
     > Fixes bug that caused temporary speed anomalies after pausing.
     > Improves dummy RAMDAC emulation.

    Have fun with the new version of Previous! If you have any issues using it, please report them here.

    You may have noticed that i have removed the link to the existing homepage from the readme. Obviously it was not maintained and did not reflect the state of development anymore. If anyone is interested in giving Previous a new home(page) please contact me.
    Title: What Needs to be done for a NeXT Emulator
    Post by: mikeboss on April 04, 2017, 08:44:48 pm
    Quote from: "andreas_g"
    i'm happy to announce the release of Previous v1.6! A binary for Mac OS X v10.9 and later can be loaded here (https://www.dropbox.com/s/wjss9s99ak64fpl/Previous_1.6.zip?dl=0).


    DANKE!  8)
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 04, 2017, 08:47:41 pm
    I can host it. I'll get a virtual host set up tonight and then will post a download link.
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on April 05, 2017, 12:30:10 am
    Superb work Andreas, as always!  I am truly delighted that you continue chipping at making Previous better!  Or should I say making LaST better, because this is what I call it  :D

    Thank you!
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on April 05, 2017, 12:40:14 am
    Quote from: "andreas_g"Hello all,

    i'm happy to announce the release of Previous v1.6! A binary for Mac OS X v10.9 and later can be loaded here (https://www.dropbox.com/s/wjss9s99ak64fpl/Previous_1.6.zip?dl=0).

    The changes include the fix for the long standing slirp crashing bug that forum user eagle helped to track down. It also includes greatly improved FPU emulation, that is now much more accurate and platform independent for the most part. The full list of changes is as follows:
     > Adds SoftFloat FPU emulation. Fixes FPU on non-x86 host platforms.
     > Adds emulation of FPU arithmetic exceptions.
     > Adds support for second magneto-optical disk drive.
     > Fixes bug that caused a crash when writing to an NFS server.
     > Fixes bug that prevented NeXTdimension from stopping in rare cases.
     > Fixes bug that caused external i860 interrupts to be delayed.
     > Fixes bug that prevented sound input under NeXTstep 0.8.
     > Fixes bug that caused temporary speed anomalies after pausing.
     > Improves dummy RAMDAC emulation.

    Have fun with the new version of Previous! If you have any issues using it, please report them here.

    You may have noticed that i have removed the link to the existing homepage from the readme. Obviously it was not maintained and did not reflect the state of development anymore. If anyone is interested in giving Previous a new home(page) please contact me.
    Great work Andreas:  I created a new directory so we can now download previous from our NeXT archives here http://www.nextcomputers.org/NeXTfiles/Software/Previous68Kemulator/
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 05, 2017, 12:42:51 am
    I threw together a new website for Previous.

    http://previous.unixdude.net

    I don't know much about WordPress, but it seemed the easiest thing to set up quickly.

    All feedback welcome.  Constructive feedback and positive comments preferred.  8)
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 05, 2017, 06:19:42 am
    Thank you all for the nice words! It is still fun to work on this project.

    @t-rexky:
    Previous is the name that Gilles gave the project when he started it. LaST is of course nice because of its 4 character length. But it is not the exact antonym of NeXT. Therefore and because we can re-use the lower case letter "e" I prefer Previous (PReV).

    @eagle:
    Thank you very much for the quick efforts on making a new homepage! I really love the front page with the NeXT poster!
    But (yeah, it is finally me making a "feature request"   :wink: ):
    I'm not a friend of the blog-style layout. I was more thinking about a classic layout with sections. I suggest a front section including a short description on what Previous is, some kind of status report and one or two screenshots. A second section could contain news and a third section could host downloads of source code, binaries for different platforms and release notes. Last but not least it could make sense to include a section with build instructions and a note that we are looking for coders to help further improving Previous.
    If you decide to go that way and you need specific information or text blocks I can provide those.
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on April 05, 2017, 09:28:47 am
    Yes, I completely understand Andreas.  I had a brief chat about this with Gilles in the past as well.  I am not suggesting the name is changed at all - it's just what I call it personally, the LaST and final NeXT :P
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 05, 2017, 10:46:07 am
    Quote from: "andreas_g"Thank you very much for the quick efforts on making a new homepage! I really love the front page with the NeXT poster!
    But (yeah, it is finally me making a "feature request"   :wink: ):
    I'm not a friend of the blog-style layout. I was more thinking about a classic layout with sections. I suggest a front section including a short description on what Previous is, some kind of status report and one or two screenshots. A second section could contain news and a third section could host downloads of source code, binaries for different platforms and release notes. Last but not least it could make sense to include a section with build instructions and a note that we are looking for coders to help further improving Previous.
    If you decide to go that way and you need specific information or text blocks I can provide those.


    I don't like the blog style layout either. If anyone has any suggestions of another content management system, I'm happy to try out another one.  I don't know WordPress very well, and while I know there are ways to make WordPress not look like a blog, I'm not sure how to do that.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 05, 2017, 11:11:19 am
    @eagle:
    Thank you for you efforts! We are not in a hurry. But on the long term I think it makes sense to have a proper homepage. People tend to think that software loaded from some forum or blog tends to be either faulty or malware. Previous definitely deserves a better image.

    @t-rexky:
    The LaST NeXT  :D  From that perspective the name definitely makes sense. An emulator can never replace the feeling of using real black hardware. But it can help to preserve NeXT software beyond the lifespan of the hardware. So at some (hopefully far away) point in the future, when all hardware has failed, it might really become the last NeXT.
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on April 05, 2017, 03:00:27 pm
    Speaking of which, did you ever get a real in-the-flesh NeXT?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 05, 2017, 05:02:57 pm
    I never owned a NeXT machine. My first computer was an iMac G3 bondi blue (the very first iMac). I often used Mac emulators to run pre-OS X software. Therefore i know that the experience using an emulator is quite different compared to real hardware. It may sound funny, but I think what makes for example SheepShaver feel strange is its excessive speed or "snappiness" and the lack of sounds (e.g. clicking of hard disk drive). Probably the lack of CRT unsharpness is another factor.
    Title: What Needs to be done for a NeXT Emulator
    Post by: pitz on April 05, 2017, 06:52:51 pm
    Quote from: "eagle"
    Quote from: "andreas_g"Thank you very much for the quick efforts on making a new homepage! I really love the front page with the NeXT poster!
    But (yeah, it is finally me making a "feature request"   :wink: ):
    I'm not a friend of the blog-style layout. I was more thinking about a classic layout with sections. I suggest a front section including a short description on what Previous is, some kind of status report and one or two screenshots. A second section could contain news and a third section could host downloads of source code, binaries for different platforms and release notes. Last but not least it could make sense to include a section with build instructions and a note that we are looking for coders to help further improving Previous.
    If you decide to go that way and you need specific information or text blocks I can provide those.


    I don't like the blog style layout either. If anyone has any suggestions of another content management system, I'm happy to try out another one.  I don't know WordPress very well, and while I know there are ways to make WordPress not look like a blog, I'm not sure how to do that.


    If you think we can migrate the authoritative source code repository over to github, I'll set up an organization account (still free) and we can host the site as github pages.  Both source code and the web site can live as separate repositories under the same account.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 06, 2017, 06:31:49 am
    I don't plan to migrate the source code to another platform. I think sourceforge theoretically also has the ability to host web pages!?
    btw. it seems previous.com and previous.org are currently unused  :wink:
    This is not high priority at the moment and I do not want to use too much time for it.

    My plans for near future are as follows:
    - Set up networking under NeXTstep 0.8 and 0.9 and complete the networking instructions. See this thread: http://www.nextcomputers.org/forums/viewtopic.php?t=4080
    - Complete SoftFloat FPU emulation by translating FPSP routines for FSIN, FCOS, FETOX, FLOGN, etc.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Kitchen2010 on April 06, 2017, 07:17:14 am
    I have just updated my wikipage entry (http://com-emu.pixub.com/doku.php/emulator/previous) for Previous v0.6. I have collected there all the information and screenshots of the whole development of Previous so far. If you want create a new homepage for the Previous emulator (github or something else), you may copy the wikipage content.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 06, 2017, 10:47:14 am
    I updated the site I threw together.  Let me know what you think.

    http://previous.unixdude.net/

    I stole one of Kitchen2010's screenshots.... I hope that was okay. :)
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on April 07, 2017, 05:50:33 am
    Hello: Eagle The Previous Website Looks Good!
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on April 08, 2017, 10:45:59 pm
    If I run Previous 1.6, it crashes immediately. If I run it from shell, the following happens% ./Previous
    Segmentation fault
    I can run Previous 1.5 OK. I am on Mac OS X.6.8. I assume this may be because it would have been built on a later version of Mac OS X?
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on April 09, 2017, 04:24:46 am
    Quote from: "tomaz"If I run Previous 1.6, it crashes immediately. If I run it from shell, the following happens% ./Previous
    Segmentation fault
    I can run Previous 1.5 OK. I am on Mac OS X.6.8. I assume this may be because it would have been built on a later version of Mac OS X?
    I just tested Previous 1.6 on an I5 Mini running  Sierra 10.12.4 , it works.
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on April 09, 2017, 10:45:29 am
    Thanks - is there a way for me to make it work on Snow Leopard 10.6.8, though?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 09, 2017, 03:25:22 pm
    tomaz, your guess is right. I was too lazy to build for early versions of Mac OS X. I didn't expect that these versions are still used.

    I made a new build for Mac OS X, which should now run on Mac OS X v10.6.8 and later. No functional changes, just re-built from same source code revision. You can load it here (https://www.dropbox.com/s/n676hsdw567guj2/Previous_1.6a.zip?dl=0).

    eagle, maybe you can update the file on the homepage. btw. Thank you for updating the page with the new text and and screenshots! The new page looks good on my iPhone. But it has some problems if the window/display is too narrow (e.g. holding the phone vertically) and does not work on my Mac using OmniWeb (yes, still sticking to good old OmniWeb).
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 09, 2017, 07:52:12 pm
    Quote from: "eagle"I know I keep asking for the world, but would it be possible to have Previous run a VNC server or RDC server to which we could connect remotely? :D


    Apparently I asked about this 3 years ago, but I didn't see a response.

    Is it possible to provide a VNC or RDP server inside Previous to present the NeXT's framebuffer?  We already have the framebuffer (Previous shows the window), I'm simply asking if it would be possible to present the same framebuffer via VNC or RDP.

    I'm envisioning something like the way VMware Fusion and VirtualBox provide remote access to the virtual machine.
    Title: What Needs to be done for a NeXT Emulator
    Post by: tomaz on April 10, 2017, 01:42:58 am
    Quote from: "andreas_g"I made a new build for Mac OS X, which should now run on Mac OS X v10.6.8 and later.
    Thank you very much, that's super! It now runs.

    But it crashes when I try to boot from the NextStep 3.0 floppy with the following message. However, running older versions of Previous, they seem to crash too.[Floppy] Reset.
    [Floppy] Disable pending reset poll interrupt
    [Floppy] Specify: DMA mode
    [Floppy] Specify: DMA mode
    [Floppy] Specify: DMA mode
    [Floppy] Invalid data rate 03
    [Floppy] Invalid data rate 03
    [Floppy] Geometry error: Blocksize not supported (3)!
    [Floppy] Invalid data rate 03
    [Floppy] Geometry error: Blocksize not supported (3)!
    [Floppy] Invalid data rate 03
    [Floppy] Specify: DMA mode
    Segmentation fault
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on April 20, 2017, 08:48:51 am
    Quote from: "eagle"
    Quote from: "eagle"I know I keep asking for the world, but would it be possible to have Previous run a VNC server or RDC server to which we could connect remotely? :D


    Apparently I asked about this 3 years ago, but I didn't see a response.

    Is it possible to provide a VNC or RDP server inside Previous to present the NeXT's framebuffer?  We already have the framebuffer (Previous shows the window), I'm simply asking if it would be possible to present the same framebuffer via VNC or RDP.

    I'm envisioning something like the way VMware Fusion and VirtualBox provide remote access to the virtual machine.


    Sure LibVNC (https://virtuallyfun.superglobalmegacorp.com/2016/11/24/libvncserver-uae/)!

    Although working out how it properly works was a bit involved, but I did get UAE to run halfway correctly with libvnc....
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on April 20, 2017, 10:28:31 am
    Quote from: "andreas_g"eagle, maybe you can update the file on the homepage. btw. Thank you for updating the page with the new text and and screenshots! The new page looks good on my iPhone. But it has some problems if the window/display is too narrow (e.g. holding the phone vertically) and does not work on my Mac using OmniWeb (yes, still sticking to good old OmniWeb).


    If anyone knows how to fix the page for OmniWeb, please send me changes and I'll incorporate them.  I don't know HTML/CSS well enough to know what's wrong there.  Also, for some reason the menu button (the 3 horizontal lines) doesn't show up on the iPhone.

    Also, I finally got to update the file on the website; sorry that took so long.
    Title: What Needs to be done for a NeXT Emulator
    Post by: nextchef on April 20, 2017, 02:53:22 pm
    Can the newest builds be compiled on linux using the instructions referenced in the link below?

    http://previous.alternative-system.com/index.php/build

    Is there a .deb available or possibly even a PPA for previous to make things even easier?
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on April 25, 2017, 04:31:03 pm
    @nextchef: I think it should it should be possible to just use Cmake to build under Linux (you might need some libraries as pre-requisites, at least libpng and libsdl2). Just go to Previous main directory (where the readme is) and use #cmake . and then #make

    @all: I have implemented all transcendental functions by translating FPSP algorithms to SoftFloat routines. I'd like to see the difference to a real 68882 (FPSP is known to produce different results than real hardware). Can someone with a 68030 Cube run these test programs (https://www.dropbox.com/s/42b8zrwj9zxksxk/FPU_Test.compressed?dl=0)? Just run them from the command line and they will print the results. Please copy the results to a text file and send them to me.
    Tomaz might also post some test programs soon with the aim to reverse the internal CORDIC algorithm of the 68882. If successful, that will lead to 100% exact 68882 emulation.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 05, 2017, 06:00:09 am
    I'm still looking for some real world results for my test programs. Maybe someone has time to run them on a 68030 Cube: https://www.dropbox.com/s/42b8zrwj9zxksxk/FPU_Test.compressed?dl=0
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on May 10, 2017, 11:16:59 am
    OK... I got the latest 1.6 snap to build on Windows after fighting cmake....

    Anyways GDB + SDL2 doesn't work. sigh.

    I did find something weird, that the SLiRP Ethernet has some issues with being plugged in/out as part of booting.

    So as a test I just short circuited all the teardown to do nothing...

       if(slirp_inited) {
           Log_Printf(LOG_WARN, "Stopping SLIRP(aborted)");
           return;


    NeXTSTEP 0.8 is apparently very much a 4.3BSD Tahoe port, so the network config all depends on scripts being able to resolve itself   I suppose in rc.boot you an just do

    ifconfig en0 10.0.2.15 netmask 255.255.255.0
    route add default 10.0.2.2 1
    ping 10.0.2.2 100 2


    naturally you'll need to fix /etc/ttys to allow root access if you want in as root (who doesn't?!)  I should also add that pinging the gateway makes it actually work, I guess the arp get's stuck or something, and the NeXT is such a good customer, that unless someone talks to it, it'll just sit there silent.

    Don't login as root, use su
    NeXT_0_8# hostinfo
    Mach kernel version 1.0.
    Kernel configured for a single processor only.
    1 processor is physically available.
    Primary memory available: 63.99 megabytes.
    slot 0: MC68030 (NeXT) UP
    NeXT_0_8#



    I love the sound + DSP!  wow that's freaking awesome!

    I don't know if it's also happening on Linux/OS X but doing a make VERBOSE=1 shows that CFLAGS is getting set to -O3, and -O0 ..

    That said, wow 1988....

    NeXT_0_8> cc -v
    NeXT version 5e0.8 (GNU version 1.26)


    GCC 0.9 was 1987, amazing how quickly it had progressed, and how early NeXT was 'objectifying' it.
    Title: Networking status - having issues
    Post by: t-rexky on May 10, 2017, 03:57:18 pm
    I tried setting up NS 2.0 on Previous 1.6 over the weekend.  With the 2.0 disk dump I lifted off winworld I keep getting kernel panics almost continuously.  So I tried the 2.1 disk dump and it seems to be behaving fine.  Except - I cannot get the network to function reliably.  I am running on 2011 iMac with the latest OS X.  Here are my observations:



    I re-read old posts in this thread but could not find anything definite.  Any thoughts?  Is this OS X 10.12 related?  Many thanks.
    Title: Re: Networking status - having issues
    Post by: neozeed on May 10, 2017, 04:04:12 pm
    Quote from: "t-rexky"I tried setting up NS 2.0 on Previous 1.6 over the weekend.  With the 2.0 disk dump I lifted off winworld I keep getting kernel panics almost continuously.  So I tried the 2.1 disk dump and it seems to be behaving fine.  Except - I cannot get the network to function reliably.  I am running on 2011 iMac with the latest OS X.  Here are my observations:

    • The network seems to come up, but not reliably.  Many times it appears to be "unreachable" after boot-up.
    • When I manage to get the network running, ftp to my NAS will successfully log-in, but I cannot get any data transfers to work: neither ls, not get or put work.  I get response timeouts at ftp level.
    • I cannot get NFS to work either - trying to mount my NAS results in "access denied", even though I can mount if from any other machine on my LAN.
    • Same network behaviour with NS 3.3


    I re-read old posts in this thread but could not find anything definite.  Any thoughts?  Is this OS X 10.12 related?  Many thanks.


    All I know is from testing on Windows, is that SLiRP really doesn't like the init/deinit/init thing.  I have a Mac laptop at home, but since Apple decided that PPTP is obsolete, I can't connect to my Synology...  I need to get another for home anyway.  

    If you can build from source, I'd start there, find the disconnect, and short circuit it.
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on May 10, 2017, 04:31:15 pm
    Thanks for the suggestion.  I did not have much time to troubleshoot so I thought I would try the "brute force" approach first and ask here.

    Are you on latest Synology software?  I don't have any issues accessing my Synology NAS from any of my vintage machines all the way up to the current OS X.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on May 10, 2017, 04:37:40 pm
    Quote from: "t-rexky"Thanks for the suggestion.  I did not have much time to troubleshoot so I thought I would try the "brute force" approach first and ask here.

    Are you on latest Synology software?  I don't have any issues accessing my Synology NAS from any of my vintage machines all the way up to the current OS X.


    I doubt I'm that current, I use it as storage for my ESXi as well, and I hate rebooting as I usually shut everything down, which takes a while....
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 10, 2017, 04:51:35 pm
    Quote from: "neozeed"
    Quote from: "t-rexky"Thanks for the suggestion.  I did not have much time to troubleshoot so I thought I would try the "brute force" approach first and ask here.

    Are you on latest Synology software?  I don't have any issues accessing my Synology NAS from any of my vintage machines all the way up to the current OS X.


    I doubt I'm that current, I use it as storage for my ESXi as well, and I hate rebooting as I usually shut everything down, which takes a while....


    Yeah, I had to update mine yesterday and whenever I do that, I have to shut down ESXi and I have to disconnect my iSCSI drives.  It's loads of fun if I forget to do that...

    I wish I had a suggestion for t-rexky because I'm running NS 3.3 inside Previous 1.6a, and connecting to NFS without any problem.

    t-rexky, did you try the steps I outlined here?  http://www.nextcomputers.org/forums/viewtopic.php?t=3598
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on May 10, 2017, 05:02:18 pm
    Quote from: "eagle"
    Quote from: "neozeed"
    Quote from: "t-rexky"Thanks for the suggestion.  I did not have much time to troubleshoot so I thought I would try the "brute force" approach first and ask here.

    Are you on latest Synology software?  I don't have any issues accessing my Synology NAS from any of my vintage machines all the way up to the current OS X.


    I doubt I'm that current, I use it as storage for my ESXi as well, and I hate rebooting as I usually shut everything down, which takes a while....


    Yeah, I had to update mine yesterday and whenever I do that, I have to shut down ESXi and I have to disconnect my iSCSI drives.  It's loads of fun if I forget to do that...

    I wish I had a suggestion for t-rexky because I'm running NS 3.3 inside Previous 1.6a, and connecting to NFS without any problem.

    t-rexky, did you try the steps I outlined here?  http://www.nextcomputers.org/forums/viewtopic.php?t=3598


    I should add, that on 0.8, I had to create host entries too, while 3.3 and rhapsody didn't seem to care...  :shock:
    Title: Re: Networking status - having issues
    Post by: neozeed on May 10, 2017, 05:37:33 pm
    Quote from: "t-rexky"I tried setting up NS 2.0 on Previous 1.6 over the weekend.  With the 2.0 disk dump I lifted off winworld I keep getting kernel panics almost continuously.


    I grabbed the "Nextstep 2.0 HD Image With Previous " image, and overlaid my exe ...

    Previous-1.6_build_767.7z (http://vpsland.superglobalmegacorp.com/install/NeXTSTEP/68000/Previous-1.6_build_767.7z)

    (password in the 404)

    and im running on Wine, well, crossover 16.2 and it seems OK.. I booted an 0.8 image I transered onto MO disc, and it was fine, and I can telnet into it, and 2.0 booted up, and I did a basic network config by editing hostconfig and making sure it pings 10.0.2.2 a few times so the gateway will work...

    $ telnet localhost 42323
    Trying ::1...
    telnet: connect to address ::1: Connection refused
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.


    NeXT Mach (ns2) (ttyp2)

    login: root
    root login refused on this terminal.
    login: root
    Type xterm-256color unknown
    TERM = (unknown) vt220
    ns2# hostinfo
    Mach kernel version:
            NeXT Mach 2.0: Wed Nov 21 12:46:53 PST 1990; /ph1_sources/projects/mk-108.1/RELEASE

    Kernel configured for a single processor only.
    1 processor is physically available.
    Processor type: MC680x0 (68030)
    Processor active: 0
    Primary memory available: 64.00 megabytes.
    Default processor set: 40 tasks, 67 threads, 1 processors
    Load average: 0.09, Mach factor: 0.95
    ns2#


    oh yeah edit /etc/ttys so it'll let me login as root.

    68030 25Mhz, no NBIC, Windows exe running through WINE on OS X 10.12.3
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on May 10, 2017, 07:06:00 pm
    Thanks guys!  I will try on one of my semi-vintage PCs and maybe on an old Mac mini with 10.6.  I have followed all the setup procedures and ping works, ftp login works, etc.  Just unable to get any file transfers and NFS to work.  Tried it on two of my Macs to no avail.

    Might have a bit of time on the weekend, but I'm also getting a "new" WatchGuard appliance to play with so there will be some interference.
    Title: What Needs to be done for a NeXT Emulator
    Post by: eagle on May 10, 2017, 07:28:22 pm
    Quote from: "t-rexky"Thanks guys!  I will try on one of my semi-vintage PCs and maybe on an old Mac mini with 10.6.  I have followed all the setup procedures and ping works, ftp login works, etc.  Just unable to get any file transfers and NFS to work.  Tried it on two of my Macs to no avail.

    Might have a bit of time on the weekend, but I'm also getting a "new" WatchGuard appliance to play with so there will be some interference.

    It occurred to me to ask this after my last post: are you using NFS3 on both client and server, or NFS4 on both?  You can't mix them.
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on May 10, 2017, 07:34:12 pm
    I assume that the Synology falls-back to NFS3.  I am using the exact same steps on Previous 1.6 as I am (and have been for years) on my physical TurboColor, both running NS3.3.  Cannot get it to mount from Previous while it works just fine with the TurboColor.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 11, 2017, 06:09:14 am
    Quote from: "neozeed"I did find something weird, that the SLiRP Ethernet has some issues with being plugged in/out as part of booting.

    So as a test I just short circuited all the teardown to do nothing...

       if(slirp_inited) {
           Log_Printf(LOG_WARN, "Stopping SLIRP(aborted)");
           return;


    Thank you for the suggestion. At the moment SLiRP is started and stopped when the guest system starts and stops the emulated Ethernet transceiver or if the user disconnects Ethernet using the preferences. Probably I need to find a proper way to initialize SLiRP once and then stop receiving packets in case Ethernet is not connected or the transceiver is disabled. I need to make sure no packets are received or stacked to the queue while Ethernet is disabled (is stopping SLiRP tick thread enough?).

    Quote from: "neozeed"NeXTSTEP 0.8 is apparently very much a 4.3BSD Tahoe port, so the network config all depends on scripts being able to resolve itself   I suppose in rc.boot you an just do

    ifconfig en0 10.0.2.15 netmask 255.255.255.0
    route add default 10.0.2.2 1
    ping 10.0.2.2 100 2


    naturally you'll need to fix /etc/ttys to allow root access if you want in as root (who doesn't?!)  I should also add that pinging the gateway makes it actually work, I guess the arp get's stuck or something, and the NeXT is such a good customer, that unless someone talks to it, it'll just sit there silent.

    Still no success here. If you don't mind some step by step instructions might be useful. I'd prefer a way through editing hostconfig rather than hardcoding rc.boot. I tried to telnet rainmaker.wunderground.com for testing purpose.

    Quote from: "neozeed"I love the sound + DSP!  wow that's freaking awesome!

    That is one of my favorites too. Knowing how complex this stuff is, it is some kind of miracle hearing correct sound: Reading from disk image, going through buffered DMA channel to memory, going from memory through another DMA channel to the DSP and being processed, result going through DMA channel back to memory and then again via another DMA channel to the sound box and no single bit is lost  :D


    @t-rexky: I'm afraid I can't do anything about the networking issues. This is just not my world. Any efforts to track down and fix issues have failed so far. Definitely need some expert knowledge and debugging skills here.
    For the kernel panics with NeXTstep 2.0: If you send me your configuration file and a link to the affected disk image I'll try to reproduce it. I did not see this issue so far (no panics at all for quite some time).

    @all: Still looking for results on the FPU test program I posted above.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on May 11, 2017, 06:29:05 am
    wish I could help, sadly Im without any black kit.  I picked up a cisco 7000 RP but it turns out it's a 68040 LC, so no math, no FPU! ...

    From OS X with a 1.6 native exe..

    NeXT_0_8# mount -t nfs -o fs,mnttimeout=1,retry=1,rsize=512,wsize=512,retrans=1 synology:/volume1/Data /mnt/data
    NeXT_0_8# df
    Filesystem            kbytes    used   avail capacity  Mounted on
    /dev/od0a             149364  106680   27747    79%    /
    /dev/od0b              86222   70482    7117    91%    /bootdisk/NeXT
    synology:/volume1/Data
                        1420440 -431336 1749376    90%    /mnt/data


    And from Wine with 1.6

    NeXT_0_8# mount -t nfs -o fs,mnttimeout=1,retry=1,rsize=512,wsize=512,retrans=1 synology:/volume1/Data /mnt/data
    NeXT_0_8# df
    Filesystem            kbytes    used   avail capacity  Mounted on
    /dev/od0a             149364  106677   27750    79%    /
    /dev/od0b              86222   70482    7117    91%    /bootdisk/NeXT
    synology:/volume1/Data
                        1420440 -431336 1749376    90%    /mnt/data


    Same pre-release ROM, same 0.8 optical disc image...    :D

    OK so it turns out it really really wants it to have an entry in the hosts file

    $ hostinfo
    Mach kernel version:
    Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64
    Kernel configured for up to 4 processors.
    2 processors are physically available.
    4 processors are logically available.
    Processor type: x86_64h (Intel x86-64h Haswell)
    Processors active: 0 1 2 3
    Primary memory available: 8.00 gigabytes
    Default processor set: 303 tasks, 1280 threads, 4 processors
    Load average: 3.32, Mach factor: 1.33


    MacBook Retina early 2015 with connection over wifi
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on May 19, 2017, 03:18:06 pm
    Quote from: "andreas_g"@t-rexky: [...] For the kernel panics with NeXTstep 2.0: If you send me your configuration file and a link to the affected disk image I'll try to reproduce it. I did not see this issue so far (no panics at all for quite some time).


    Just for record keeping purposes: I forwarded the misbehaving NeXTstep 2.0 image and configuration and Andreas was able to reproduce the panics.  He was also able to confirm that the latest source snapshot resolves these panics.  He believes they were related to a corner case FPU bug...

    ...one stop closer to emulated perfection.

    I still had no time to troubleshoot the networking issue.  Will try neozeed's build on one of my PCs over the weekend.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on May 26, 2017, 11:48:28 am
    @t-rexky: Thank you very much for testing! I'm glad the crash is gone. This patch will be included within the upcoming v1.7 release of Previous.

    @all: To confirm a bug related to networking I need a test on real hardware:
    Any black hardware running NeXTstep 3.3 and connected to the network using thinwire Ethernet connection. Make sure no application is running that uses the network. Then start OmniWeb 2.7 and see if it prints "The network is disabled or your computer isn't connected to it." to the console. You don't need to open any page. It would print the message during startup of OmniWeb.
    If you don't have OmniWeb you can alternatively ping some non-existent IP. That should have the same effect. So does anyone get this message on the console, although the network is connected and working?

    btw. I'm still looking for results for my FPU test program that I posted here a few weeks ago.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on May 27, 2017, 03:00:20 am
    Hello I'll see what I can do when I get back home this evening I'll set up an 030 system and test it out,
    Title: Previous site not available..?
    Post by: jminiko on May 27, 2017, 11:51:03 am
    Hello,

    http://previous.alternative-system.com is not reachable,
    Infinite loop detected in JError as
    but backup git source site is:
    https://github.com/lewellyn/previous

    was wondering why

    Regards

    Jean-Marc
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on May 27, 2017, 01:09:38 pm
    that code is very old..... try the current repo:

    https://sourceforge.net/p/previous/code/HEAD/tree/
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 17, 2017, 10:52:43 pm
    I've got a question to all networking hardware experts out there:

    Imagine a machine connected to a network using thin wire Ethernet. The transceiver of the machine is set up to accept directly addressed packets and broadcast packets. The machine transmits a broadcast packet to the network.

    Will this packet be received by the sending machine? Or more generally: Can the transceiver see his own packets?

    If yes, is this only true for thin wire Ethernet, or is it also true for twisted-pair Ethernet?
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on June 18, 2017, 03:22:04 am
    Based on my understanding a improperly terminated thin net would reflect the packets so you could then see yourself.

    Otherwise I'd say no, you shouldn't see yourself, however something like pcap knows you sent something and it'd register it and it'd look like you can see yourself.  

    When I was hacking Basilisk II a bit, I had to add a filter to make sure I didn't see myself.  I don't think Basilisk cared so much,but it was a waste of time examining packets that it didn't need.  But it's HLE.  I'd imagine that with LLE it may confuse the nic driver as to when it can transmit, or why it's immediately getting a reply back from itself...  The hardware chip should handle a bit about collision detection, I'm not sure about the chip NeXT used thought.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 18, 2017, 08:02:02 am
    NeXT used the Fujitsu 502B Ethernet Encoder/Decoder combined with Fujitsu MB8795B Ethernet Data Link Controller.

    This combination of chips can detect collisions and indicate them through various status bits. But I'm not sure my problem is related to collisions. It seems that the driver expects to see its own packets echoed back. I might be wrong though.

    There is even a bit "Transmitted Packet was Received" in the transmitter status register. I initially thought this was related to loopback mode. But it seems to be more than that. Quote from the data sheet:
    QuoteBit 5 - Read - Transmitted Packet was Received - Indicates that shortly after transmission was completed a good packet was received by the receiver. This is used to indicate self-reception of the packet, which allows the software to take advantage of the hardware address matching even in systems which are designed for half duplex operation. This bit is cleared as each transmission begins.


    I have problems understanding this. It does not sound as if this bit signals an error condition. But it also is not clear about if self-reception is normal.
    Title: What Needs to be done for a NeXT Emulator
    Post by: neozeed on June 18, 2017, 08:36:56 am
    So it expects to see it's own packet and I'd assume it is set to 1 after transmit.  But as soon as a packet it going to be sent it'll get cleared...

    We really need to get you access to a 68k.  Is a 040 good enough?  Like a mono next station?
    Title: What Needs to be done for a NeXT Emulator
    Post by: t-rexky on June 18, 2017, 10:12:25 am
    Quote from: "neozeed"We really need to get you access to a 68k.  Is a 040 good enough?  Like a mono next station?


    I've been "working on" Andreas a bit behind the scenes to get real NeXT hardware  :D , but he has space challenges.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 19, 2017, 10:09:44 am
    neozeed, thank you for the offer/suggestion! But as t-rexky already mentioned, I have limited space and therefore it is unlikely to get a permanent place to run black hardware.

    For the networking issue: I'm still interested in some kind of confirmation that my conclusion on self-reception is correct. I don't want to hide a potential bug by emulating some bogus behavior just to make the driver happy. This would make future debugging even harder.
    Title: What Needs to be done for a NeXT Emulator
    Post by: Rob Blessin Black Hole on June 21, 2017, 07:23:41 am
    Hello: All: I've been trying to get a NeXT hooked up to my Comcast Network , has anyone done this? I have previous working just fine and thought I would be able to move that image onto an sd boot and go on a NeXT.  It lloks like the key is configuring etc/resolv
    Heck Andreas, I thought you had a NeXT? You have been doing absolutely amazing NeXT stuff with out one! Heck I will gladly donate a NeXT MonoTurbo Station  to you , if you just cover shipping. We will put new caps on the board and I'll configure with with an SD , max out the ram I also throw in a modified soundbox shell that is dual compatible and the custom cable you can use for hooking it up to a flat panel and an ADB Keyboard and ADB NeXT Mouse . I'll also put in a New old stock floppy drive and new old stock power supply and update to a V74 rom that is how much I appreciate your work.
    I'm not a rich man but I sincerely would like to help you out , medical expenses due  to rheumatoid arthritis flare ups , aging and just bills are starting to rack up .  I have not been as active because of the pain but good news is they are starting me on Embrel which should help, it is sticker shock how much they charge for embrel $500 to $2000 a month for Embrel but I'm hoping it will be covered  and I won't loose my insurance due to this prexisting RA  condition  and new potential cruel insurance policy that may be implemented .
    I've bought or traded for most of the NeXT stuff I'm donating to you and paid the labor on the caps but it is about heart and not about the money. So if you find space and want to cover shipping I'm estimating from the USPS about $135 just pm me. My NeXT eBay sales and other web sales still keep the lights on so it is a lot of fun for me . A station would not take up very much space please let me know!  :D
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on June 21, 2017, 08:35:46 am
    Rob, thank you for the generous offer! If I decide to finally get some black hardware I'll come back to you and we can talk about the price. But first I definitely need to sort out my living space issues.

    I'm sorry to hear about your health problems. I hope it gets better through the medication!

    About networking: Previous comes with some instructions on how to set up networking. Those instructions should also work for real hardware, if you replace the IP-addresses with the appropriate values for your network setup.

    I'm now quite confident, that on thin wire Ethernet packets can be received by the sending machine, while they are transmitted. I asked some people and while no one could confirm this behavior, they agreed that it is at least plausible. I have a patch here but need to test it a bit more before releasing. The message "The network is disabled ..." is definitely gone when using the patch and until now I could not see any new problems.
    Title: What Needs to be done for a NeXT Emulator
    Post by: andreas_g on July 14, 2017, 10:45:19 pm
    Hello all,

    it took me longer than expected but finally I was able to finalize Previous v1.7!

    This release concentrates mainly on improving accuracy and reliability. There are not much new features, but it adds the ability