What Needs to be done for a NeXT Emulator

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

Previous topic - Next topic

zombie

Quote from: "andreas_g"Hello all,

I have some time for programming these days. Are there any feature requests or issues that need to be fixed in a future release of Previous?

Regards,
Andreas


A super useful feature would be to set up a "shared folder" feature.  I see for printer options you can send print jobs to a specified folder directory.  What would be great would be to be able to specify a shared folder were the NeXT machine would read it like a folder or a separate drive, and it would just be a folder on the Mac/Host machine.

It would make moving files back and forth a lot easier without having to resorting to using NFS.

andreas_g

Quote from: "zombie"It would be great to make the loading of roms and disks work more like native apple file system. It's a bit painful to set those paths.

Implementing native GUI elements is not among my goals. But if someone wants to do it, that would be great.

Quote from: "zombie"Also, it would be great to have a "turbo boost" feature where we could say add a CPU multiplier. To run at say 10X (or a slider that lets us set the multiplier) the 33MHz clock rate. A bit like the Pyro chip. Since modern CPUs could run things a LOT faster, if we could tap into that, it would be fun (to see how fast Mandlebrot runs). And maybe a MAX TURBO setting that would run the emulator as fast as possible on the host machine.

Something similar is already implemented. In advanced system preferences just choose "variable" for CPU clock. Then all user mode code will be executed with maximum speed, while all supervisor code will be executed at normal speed. This has two effects: On one hand all user applications are accelerated quite a lot using all available CPU power and on the other hand all supervisor code will be executed at normal speed using only as much power as is necessary (for example while being idle). I think this gives a good balance on speed vs. efficiency.

Quote from: "zombie"A super useful feature would be to set up a "shared folder" feature.  I see for printer options you can send print jobs to a specified folder directory.  What would be great would be to be able to specify a shared folder were the NeXT machine would read it like a folder or a separate drive, and it would just be a folder on the Mac/Host machine.

It would make moving files back and forth a lot easier without having to resorting to using NFS.

I agree that this would be a very useful feature. Simon started some time ago with something like that. It would require some kind of "file system translator" mapping files and directories from the host file system to NeXTstep's UFS. That is no trivial task. It would require to reverse engineer the file system and stuff like disk labels and partition tables.
Just thinking about it: Maybe best would be to create a new category for SCSI devices like "virtual disk" where you can select the folder that should be mapped.

zombie

Quote from: "andreas_g"
Quote from: "zombie"It would be great to make the loading of roms and disks work more like native apple file system. It's a bit painful to set those paths.

Implementing native GUI elements is not among my goals. But if someone wants to do it, that would be great.

Quote from: "zombie"Also, it would be great to have a "turbo boost" feature where we could say add a CPU multiplier. To run at say 10X (or a slider that lets us set the multiplier) the 33MHz clock rate. A bit like the Pyro chip. Since modern CPUs could run things a LOT faster, if we could tap into that, it would be fun (to see how fast Mandlebrot runs). And maybe a MAX TURBO setting that would run the emulator as fast as possible on the host machine.

Something similar is already implemented. In advanced system preferences just choose "variable" for CPU clock. Then all user mode code will be executed with maximum speed, while all supervisor code will be executed at normal speed. This has two effects: On one hand all user applications are accelerated quite a lot using all available CPU power and on the other hand all supervisor code will be executed at normal speed using only as much power as is necessary (for example while being idle). I think this gives a good balance on speed vs. efficiency.

Quote from: "zombie"A super useful feature would be to set up a "shared folder" feature.  I see for printer options you can send print jobs to a specified folder directory.  What would be great would be to be able to specify a shared folder were the NeXT machine would read it like a folder or a separate drive, and it would just be a folder on the Mac/Host machine.

It would make moving files back and forth a lot easier without having to resorting to using NFS.

I agree that this would be a very useful feature. Simon started some time ago with something like that. It would require some kind of "file system translator" mapping files and directories from the host file system to NeXTstep's UFS. That is no trivial task. It would require to reverse engineer the file system and stuff like disk labels and partition tables.
Just thinking about it: Maybe best would be to create a new category for SCSI devices like "virtual disk" where you can select the folder that should be mapped.


Thanks. I've been trying out the variable speed. Below I see it gets to about 48mhz effective speed but not more on my MacBook Pro. I guess that's about as fast as it will go? I will try on my Mac Pro later to see if it can do better. It runs so solid I guess I was under the impression we might be able to see a 10x speed up of like 300MHz effective or so..

The folder sharing would be huge and I have little doubt it's easier said/asked than done! :D

Maybe something like FUSE would help? https://osxfuse.github.io

eagle

For file sharing, what about something like what other VM environments do? VMware and VirtualBox create what looks to the guest like a native remote mount; in our case, we would use NFS to the client. If Previous could take a Mac directory and present it as an NFS share to the VM, that would be awesome.
My NeXTs:
NeXT Computer prototype (68030-25 x2, 68040-25)
Two NeXTstations (68040-25)
All mono

andreas_g

Quote from: "eagle"For file sharing, what about something like what other VM environments do? VMware and VirtualBox create what looks to the guest like a native remote mount; in our case, we would use NFS to the client. If Previous could take a Mac directory and present it as an NFS share to the VM, that would be awesome.

That is one possibility of file sharing. But then the user still needs to set up NFS on NeXTstep. Therefore the benefits over just setting up an NFS share are not that big. The option with the disk is probably more user friendly.

nuss

Quote from: "andreas_g"Hello all,

I have some time for programming these days. Are there any feature requests or issues that need to be fixed in a future release of Previous?

Regards,
Andreas


Hi Andreas,

would it be possible, to provide a screen capturing feature for video recording?

Cheers
Nuss

zombie

UPDATE: The below is wrong, you can do fresh install. Details in thread from link below.

One thing we need is for the emulator to be able to do a fresh install from original installation cds. Right now that seems impossible.

http://www.nextcomputers.org/forums/viewtopic.php?p=24976#24976

zombie

Wish list of features:

(1) Shared folder to make moving data between emulator and host OS easier
(2) Shared clipboard. So I can copy text/image between host OS and Previous
(3) Previous remember last path visited in selecting ROMs and ISO disk images. It always restarts in some place and I have to click through so many sub directories. Or at least a setting to set the 'base path' is and always start at that set path for any new drives or ROMs that I go searching for
(4) 4GB empty drive. I believe this is possible with a 1k (instead fo 512byte) block size.

neozeed

I just telnet into the VM, and mount a NFS share for #1/2

Clipboard will require an agent just as shared folders would require NFS emulation
# include <wittycomment.h>

eagle

Quote from: "neozeed"I just telnet into the VM, and mount a NFS share for #1/2

Clipboard will require an agent just as shared folders would require NFS emulation

How reliable is your NFS connection?  Mine works okay for small things, but when I try to do larger transfers, it falls over.
My NeXTs:
NeXT Computer prototype (68030-25 x2, 68040-25)
Two NeXTstations (68040-25)
All mono

neozeed

Quote from: "eagle"
Quote from: "neozeed"I just telnet into the VM, and mount a NFS share for #1/2

Clipboard will require an agent just as shared folders would require NFS emulation

How reliable is your NFS connection?  Mine works okay for small things, but when I try to do larger transfers, it falls over.


It was working fine for me, I had to tweek the packet size to 512 in the mount command.

I had the exact syntax I use in a post here...
http://www.nextcomputers.org/forums/viewtopic.php?p=23758#23758

I had been using the flags:

mount -t nfs -o fs,mnttimeout=1,retry=1,rsize=512,wsize=512,retrans=1 synology:/volume1/Data /mnt/data


to mount my synology NFS share.
# include <wittycomment.h>

eagle

Cool - thanks! I'll retry my NFS mounts with these options to see if they work better.  Also, yes, it definitely wants a hosts entry; I always niload the hosts file, but I'm surprised that I didn't document it when I wrote my automounter howto: http://www.nextcomputers.org/forums/viewtopic.php?t=3598
My NeXTs:
NeXT Computer prototype (68030-25 x2, 68040-25)
Two NeXTstations (68040-25)
All mono