Emax

What you describe is one method of reverse engineering. It can be done using a logic analyzer with 
a disassembly pod or by writing your own script/program to process the analyzer data. But 
because the NSC32000 CPU is fairly obscure it will probably be difficult to find an off the shelf 
disassembler. So that means someone has to write one and the 32000 is much more complicated 
than a Z80.

A good place to start though would be the boot ROMs as they must contain all the code for the 
power on diagnostics and floppy/SCSI loading of the OS. If the ROM routines arre reused by the 
OS then it may be possible to make modifications at that level before attempting to hack the entire 
OS.

/Tristan

On Thu, Dec 31st, 2009 at 4:29 AM, thenewyorkcowboy <thenewyorkcowboy@...> wrote:

> I realized after I hit 'send' it that 'replacing' the CPU was not
> really feasible, we've had that thread before.
> 
> I guess I was thinking about a way to make something like an
> on-the-fly interpreter or decomplier, like whatever binary code is
> being processed it could be displayed elsewhere converted into hex. 
> Then you would simply go through all the buttons and parameters one
> by one and you would begin to see what commands do what and where the
> subroutines are by comparing the unique pattern to the various binary
> images we already have as well as the OS.  Kind of like reverse
> engineering by using a logic probe like we already talked about but
> something that would temporarily clip on or piggyback off the I/O and
> monitor all the pins at once.  I figured that this 8Mhz processor
> could simply be an interface to a machine code monitor of raw data to
> display it on a computer screen like 'action replay' does on the
> Commodore 64.
> 
> Either way, it is hair-brained or hare-brained.  I do enjoy using
> this forum though as a think tank over a cup of coffee...
> 
> Once we get the FAQ established and tweaked and the RS-422 project is
> out we'll bask in glory and talk about all the new stuff we're able
> to do and that will spark more interesting conversations...
> 
> --- In emax@yahoogroups.com, tu@... wrote:
> >
> > The fundamental issue is we do not have the source code, let alone
> the documentation and development environment. We 
> > have the binaries for the boot ROMs and disk OS but that is not the
> same as the source code. Its a long a difficult road to 
> > disassemble and understand binary files and it is not made any
> easier by the Emax using a fairly obscure and complicated 
> > main CPU. So what you suggest is unlikely to happen any time soon.
> > 
> > /Tristan
> > 
> > On Wed, Dec 30th, 2009 at 4:59 AM, thenewyorkcowboy
> <thenewyorkcowboy@...> wrote:
> > 
> > > I just saw this post on the Yamaha DX group and thought I would
> put
> > > it here for us to comment on as well.  Don't know how it might
> apply
> > > but ideas are welcome.  My initial thought is somehow using this
> to
> > > translate the EMAX source code into something that we could
> > > understand and modify, then we could write a new OS that would
> > > implement the new features of the extra stuff we put in, or
> possibly
> > > if the stars were aligned we could even replace the dated
> > > microprocessor of the EMAX with this one and write brand new
> code...
> > > 
> > > Here is the Wiki: http://en.wikipedia.org/wiki/Atmel_AVR
> > > 
> > > Re: Editor Librarians for TX81Z
> > > Posted by: "Alan Probandt" alan_probandt at yahoo.com  
> > > alan_probandt
> > > Mon Dec 28, 2009 7:18 am (PST)
> > > 
> > > 
> > > Hello,
> > >   I have noticed the trend towards over-complication that was
> > > mentioned in your message and agree.  However instead of
> resurrecting
> > > 1980s 8-bit home computers, I suggest looking into the modern
> > > microcontroller scene that is always improving in terms of
> > > performance for the price.
> > >   I have been doing MIDI development with the Atmel AVR
> > > microcontroller a lot for the past five years or so.  I don't
> have a
> > > lot to show for it, from a professional perspective, but what
> has
> > > been done is in open source and available.  The AVR is almost a
> 1980s
> > > home computer on a inexpensive chip.  There is a 20MHz CPU core
> > > running 130+ op-codes, two or three input/output ports, a 
> serial
> > > port UART or two, a cluster of 10 bit analog/digital convertors,
> > > several timers, and a Flash ROM space of 4K bytes to 128K bytes.
> 
> > > Lacking is big on-board RAM, video, and sound generators.  
> Programs
> > > are written in free assemblers or C compilers and loaded into
> the
> > > flash ROM.  No need for ultraviolet erasers any more. All
> programs
> > > are stored in the ROM. No program code runs from RAM, which
> makes
> > > AVRs different from home computers.
> > >   Video can be done using attached LCD graphics modules that sell
> for
> > > about $20.  Sound ICs have disappeared probably for good, but MP3
> and
> > > MIDI are straightforward to implement.  Massive data storage is
> done
> > > on small cheap SD Flash cards at a cost of about $10 per
> gigabyte.
> > >   AVRs have the same programming 'feel' that the old home
> computers
> > > do, but they are much more widely available.  There isn't any
> concern
> > > that a program written for DOS or Commodore 64 can't be shared
> > > because the hardware is unobtainable.
> > >   The 10-year-old 8-bit 20MHz $8 AVR is on the verge of being
> > > replaced by the $4 50MHz 32bit ARM-family of microcontrollers,
> > > specifically the Cortex M3.  This device is made by many
> companies,
> > > but it is much more difficult to program and is 'overkill' for
> MIDI
> > > applications.
> > >  
> > >   Just a brief update on the alternatives to using
> unprogrammable
> > > desktop PCs for MIDI applications.
> > > 
> > >
> >
> 
> 
>