What Needs to be done for a NeXT Emulator

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

Previous topic - Next topic

cuby

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

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)

jvernet

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

gilles

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

gilles

it was RTC ram registers :)
now it does not need the patch anymore...
but I need to add RTC_STATUS support I think.

gilles

updated svn (Rev 6), now go to Testing screen without dead loop error (& flashing LED).

ebann

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

jvernet

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

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!

gilles

great simulator :)
cannot try because it crashes my browser but seems real impressive.

ebann

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

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...

jvernet

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

itomato

Wow - this is very cool!

I'm incredibly impressed at the rate of progress!  Go, Gilles!! :o
-itomato

gilles

most of the progress is in fact from UAE team for much better support of 68040.