Re: 1541 ROM areas recognition

On Thursday 07 November 2013, you wrote:
> On 2013-11-07, at 00:39, Groepaz wrote:
> >>>> Is there a reliable, software way of recognising ROM areas of a 1541
> >>>> (all models)? I mean without knowing what kind of ROM is actually
> >>>> installed. I assume that all of them have to cover up to the end of
> >>>> 6502 address space (if not for anything else then at least due to h/w
> >>>> vectors) but what about the starting point(s) and what if there happen
> >>>> to be some non-contiguous chunks?
> >>> 
> >>> not sure if i understand the question correctly.... but to find out if
> >>> there is rom or ram at a certain address, write to it and see if the
> >>> value changed? (backup/restore the original value ofcourse)
> >> 
> >> Well, finding RAM would be as easy as you wrote. What is needed though
> >> is to distinguish ROM from all other (than ROM) types of things that
> >> may dangle around the corners of address space. Not only RAM. Those may
> >> be RAM but also e.g. port chips, gaps, unconnected address ranges..
> > 
> > it would be easier to give an advice if you'd tell what exactly you are
> > trying to do....
> 
> NP - I once wrote a simple drive-ROM dumper program, which works fine as
> long as I modify it every time a different ROM layout pops up.  Which is
> of course that I need to know the layout in advance. Which means either
> knowing what's inside or opening, checking, analysing, ... I am thinking
> (wishfully - probably) of making the program universal in the sense that
> it could detect ROM areas itself.
> 
> > I have only ever needed something like that to find out how much RAM
> > is installed in the drive and where it is located - all other info is
> > known anyway (like location of i/o chips).
> 
> Not really. DD3 equipped 1541 is a good example of a situation when this
> does not hold true. It has different I/O location (the parallel port PIA),
> different RAM size/location and different ROM size/location.

but that is fairly easy to detect by simply querying the dos error channel, 
isnt it?

so well, what i'd do in the drive would be (in this order)
- check the error channel/poweron message. fortunately those drive extensions 
that added more than just a different ROM were not cloned a lot, so this 
should give a good hint on wether there is someting like dolphin dos 3
- do a ram/rom check. after that you know for certain what cant be ROM because 
it is either RAM or i/o (ie, a value written can be read back)
- do empty i/o check, ie read blocks and check for $ff
- probe for i/o chips at known locations

additionally, maybe try to find some specific ROMs at known locations and 
check by checksum - things like dd3 should be detectable that way

-- 

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ftp.pokefinder.org

If you want to have creative workers, give them enough time to play. 
<John Cleese>


       Message was sent through the cbm-hackers mailing list