Re: More RamFactor observations

[BLuRry <brendan.robert@gmail.com>]

Other findings:

The "extra" ports are just duplicates of 0-3.  I suppose they didn't have a need to hook up an unused address line so bit 2 of the i/o port address is a don't-care.

Also, it's either the case that the //gs gets a very different set of routines or (and this is more likely) that I have no idea how to dump the c8 rom portion of the card from the monitor and I'm actually mooking at motherboard rom.

-B

On Sunday, August 19, 2012 1:35:28 AM UTC-5, BLuRry wrote:
> On Sunday, August 19, 2012 12:09:37 AM UTC-5, BLuRry wrote:
> 
> > I was able to fire up my RamFactor and perform some more verification to see why my emulated attempt was not working.
> 
> > 
> 
> > 
> 
> > 
> 
> > Firstly, there are more I/O ports active than stated in the documentation.  But I can't figure out what they do except that they are not necessarily constant.
> 
> > 
> 
> > 
> 
> > 
> 
> > Secondly, the c0xf register switches firmware banks but it will always read FF.  I hadn't implemented this correctly.
> 
> > 
> 
> > 
> 
> > 
> 
> > Lastly, I noticed the pointer is not incrementing properly.  Is there a reliable reference for the exact bus behavior of each opcode and addressing mode?  I need to ensure that every opcode is properly simulating an I/O read or write when it should.  The RamFactor manual warns of this behavior but is unfortunately very unspecific.
> 
> > 
> 
> > 
> 
> > 
> 
> > -B
> 
> 
> 
> Ok, I found the instructions -- all of which are "fetch-modify-store" instructions that don't use processor registers (e.g. ROL, ROR, ASL, LSR, INC, DEC).  I made a very small test to compare to the real thing and now the slinky counter increments for those instructions.
> 
> 
> 
> But I still have no idea how it computes the ram size or why the diagnostic is failing.
> 
> 
> 
> Getting closer though!