[NTLK] Announcing Leibniz

[Steve White]

> Have you documented the exact dumping procedure anywhere, for curiosity's sake? 

No.  Roughly speaking, write an ARM routine that’ll enumerate bytes from 0x00000000 through 0x00400000 (ROM space, 4MB). Have it so each byte is written to 0x0148104 (serial data on the Runt chip).  That’s the easy part.

To actually execute it, use the Diagnostics software, go to Evaluation, then Memory Dump and Edit.  Tap in 0x01000000 (start of RAM) and tap the Address button.  Page Up a bit to find enough unused RAM to enter your routine (mine took up a screen’s worth).  Then manually enter the routine.  It’s tedious, as you have to enter the address, tap the Address button, enter the value, tap the Store button.  Do this for every word in the entire routine.  Once completed, page around RAM some more to find the call stack – I just looked for addresses that seemed similarly grouped in ROM.  Overwrite one of the addresses with the location where you stored your ARM routine.  Then sit back and watch the bytes slowly flow over the serial port (IIRC, it was 9600 baud, 8n1).

The fork of NewTen is much easier.

> Under what license? I assume GPL from the third-party libraries.

Given the ARM+FPA code is GPL, I reckon the rest has to be too.  

> Can it be compiled for Mac OS X versions older than 10.6?
> 
> Are you going to document the Runt hardware, or is it already documented  
> anywhere? It would be nice to eventually emulate it on other operating  
> systems, since Objective-C isn't the most portable language.

It wasn’t documented anywhere that I’m aware of.

While it’s no replacement for documentation, the top of runt.h will show you what IRQs and power flags are.  The top of runt.c will detail the registers.  

Memory map is fairly straight forward, ROM space is in the first 16MB.  ROMs tend to be mirrored (e.g. 0x00000004, 0x00400004, 0x00800004 and 0x00C00004 are all the same). There’s a catch with 8MB ROMs (e.g. MP130), where the last 4MB of ROM repeats after the full 8MB block. 

RAM starts at 0x01000000 and runs through 0x012000000 (similarly mirrored).  The Runt resides at 0x014000000.  PCMCIA is at 0x70000000.  Depending on the type of PCMCIA card, it’ll be mapped into different address spaces.  SRAM cards seem to map in at 0x01200000. I don’t recall where the other PCMCIA cards map to — I can go through my Hopper database though and report back if it’s vital.

The core of the emulator is all in C.  Everything is in the emu-core directory, and there’s a Makefile there.  It’ll generate a newton binary, which will run the ROMs in a (crummy) “monitor” environment. That runs fine on non-OSX platforms. And it’s where I spent most of my time...

Porting wise, if you implement newton_display_open() and newton_display_set_framebuffer() you’ll get the frame buffer data. The frame buffer is passed as if you were an LCD e.g. 240 tall x 336 (Junior)/320 (Lindy) wide— so you’ll need to rotate it for display.   Route taps back into it via runt_touch_up() and runt_touch_down().  Leibniz doesn’t really handle any other hardware (sound, serial, PCMCIA, etc) so porting should be that straight forward.  If desired, I could probably write an SDL front-end for it later tonight.

Re: older OS X, probably.  I have a old iBook running 10.4 I could try it on.  Honestly the only reason I dropped the requirements down to 10.6 was for splorp :)

> I was going to try Hammer and Newtsbug eventually, but thanks for letting  
> me know so I don't have to waste my time and be disappointed. ;) Is there  
> any known debugger out there that supports this older protocol?

I’m not aware of any – my copy of Egger doesn’t support anything other than the NuBus boards.  Perhaps Maurice Sharp would know?

-Steve