NeXT Emulation in QEMU

Hi All,

I am working on adding NeXT emulation to QEMU for Google Summer of Code. I am currently focusing on fixing m68k emulation in the QEMU core, but will soon be focusing on the NeXT hardware itself. I have gone over the documentation I have found here, but still have a few unknowns. The first of which is the NeXT memory map, as far as if/where video ram is in the address space, and where memory mapped i/o resides. Does anyone have this information?

Thanks

Hello!
I would recommend you visiting the topic "What needs to be done for a NeXT emulator". They have got the basics now, with CPU code from the Hatari Atari ST emulator. I am not one of them, but it's a hint. Maybe you could help them as well. :roll:

Well, I've made some progress: http://brycelanham.imgur.com/qemu_next
The thing now gets stuck with Exception #0 (0x0) at 0x700. I'm guessing the stack/stack pointer is getting screwed up, as at no point does the emulator execute anything at 0x700.

Well done on getting even that far! I look forward to seeing how this evolves, could be very useful for later.

Hello blanham!

Interesting project! Did you find the cause for the exception? Have you been able to make some more progress?

I suppose you have already taken a look at "Previous"!? (from the topic that iMachinchilla did recommend)

If you take informations/code from Previous' sources please also share your knowledge with us when you make further progress beyond what is already implemented in Previous.

Maybe you can even find the time to implement the code written for qemu also in Previous.

I'm still hard at work on my project.

I fixed a ram allocation bug, and added keyboard support. I am now working on adding ethernet, though the DMA implementation is giving me all sorts of headaches.

http://brycelanham.imgur.com/qemu_next#SV8xn

Anyone know any ex-NeXT engineers? Or am I going to have to email Steve?  :)

Also, I am idling in ##next on freenode if anyone has questions/suggestions.

Forum member dtaubert has done some work on "Previous" and told he was working on SCSI. Also he planned to modify the NetBSD boot loader to probe the hardware on his NeXTstation.
He has been inactive in this forums for some time now but maybe you are able to contact him nevertheless.

Furthermore there are some diagnostic utilities for NeXT hardware in the forum's software archive:

http://www.nextcomputers.org/NeXTfiles/Software/Diagnostic_Utilities/

Maybe you can find out some details about how the hardware should work by disassembling them (just an idea, i really don't know if disassembling and "reading" these files is possible at all).

Good luck!

Well, I have ethernet mostly working.
The NetBSD bootloader loads, and then hangs trying to mount a nfs share
http://brycelanham.imgur.com/qemu_next#NsSXC
while the NeXT bootloader hangs, though I only have a shot of it throwing a read error though:
http://brycelanham.imgur.com/qemu_next#IZTzD
(While working on scsi support I found a bug in my DMA code, so it may no longer hang, haven't had a chance to check as of yet)

I then switched over to adding SCSI support, as the esp100/nc53C90 chip is already support by QEMU.
I've spent the past couple of days trying to track down a bug in the scsi code. I figured out a patch last night, which then crashed because of a bug in QEMU's return to exception instruction. Manually stepping over this and setting the pc/sp got me this:
http://brycelanham.imgur.com/qemu_next#kQ9J4

I'm pretty sure that the error is a result of mmu emulation being non-existent, so I'll probably be focusing on that next.

Wow, it's so exciting to see all this progress!  Hopefully we'll have a 68040 NeXT emulator working at some point.  I really miss Improv, and hate that it was m68k only.

Is anyone else trying to build this on Lion using macports?

I have compiled the latest source code (from here: https://github.com/blanham/qemu-NeXT/tree/next-cube) for Mac OS X.
The binary should work on Mac OS X v10.5.8 and later on all platforms (PPC, i386 and x86_64). You can download it here: http://dl.dropbox.com/u/44703754/QEMU-NeXT_09-13-2011.zip


At the moment only a few things already work:
Boot to ROM monitor, Keyboard input, SCSI (partially, no booting possible yet), Ethernet (partially?, did no tests on this)
But i think it might still be fun to play with it.

You can start with this command:
./qemu-system-m68k -M next-cube -drive file=your_image_file,if=scsi,unit=0

You can even add multiple disks. This example is for adding one floppy disk image and one CD-ROM image:
./qemu-system-m68k -M next-cube -drive file=your_floppy_image,if=scsi,unit=0 -drive file=your_cd_image,if=scsi,media=cdrom,unit=1

You can find documentation for QEMU here:
http://qemu.weilnetz.de/qemu-doc.html

Seems to me like it would make sense to consolidate efforts?

You are absolutely right! It makes no sense to continue working on 2 parallel projects. The QEMU based project is currently progressed further, when it comes to already usable features, like keyboard input. That is the reason i put in some efforts to compile it.

But i think, that Previous is the better choice. The best argument for Previous and against QEMU is that exotic systems in multi-system emulators like QEMU are very difficult to maintain and often break, when the emulator gets updated.

I think that Hatari/Previous also has other benefits like DSP emulation, configurability (choose CPU type, etc; maybe good for emulating 68030 and 68040 based NeXT systems), a graphical user interface, etc

So from my point of view, it would make sense to concentrate all efforts to work on Previous.

And the merger has even more positive sides:
No competition between two different products and maybe faster progress.
So if one does not have the time, the others can proceed with Previous.
Also, I would like to present two new names instead of "Previous":
eNeXT and NeXTem.

I am not a programmer, but I am interested in the Previous project because I have an interest in retro-computing as a whole. And a NeXT emulator would be a benefit for other emulators, like Mini vMac or Basilisk II.

I see interest has picked up again. I've been a bit busy with the start of term, but I'm still giving thought to QEMU-NeXT. I think I'll continue with qemu, not only because of the inbuilt scsi and network subsystems, but also the ease of debugging by using its built in support for remote gdb connections. There is also the issue that I have limited time during the school year, and I'd rather spend it improving what work I've done, then having to first learn how the hatari code works, and then having to graft everything on to it. There's also at least on or two people working on the mess NeXT driver again. I don't think the parallel work is as much a problem as not communicating what work we are doing. I plan on writing up some documentation soon on how things like the network chip and dma work.

As far as the current source on github, SCSI booting should work, if one has a raw image of a NeXT hard disk with either NeXTStep 2.x or 3.x on it. It detects the disk and then goes into a loop trying to scan the rest of the SCSI bus. If I can fix this it should atleast be able to boot to single user mode. Floppy support is completely broken at the moment, there's some weirdness I have yet to figure out. Networking works, but the built-in slirp bootp server has to be hacked to supply the correct packet format the prom expects.

I am always idling on IRC as ChickeNES in ##next on freenode. I'll be pleased to talk to anyone who is interested in NeXT emulation.

What environment are you using for development on qemu-NeXT?

A combination of Snow Leopard/Ubuntu 64bit. I'm not sure if it builds properly on Lion as of yet.

I don't think merge is a good option for 2 open source projects.
Merge may only be usefull for closed projects but from a technical point of view, a merge never really happens, one project lives with the whole information and the other is just stopped.