6502.org

Happy Thanksgiving!

Is it safe to determine the size of RAM by writing a value to a location, reading it back and if they are the same, you have a RAM address?

Is it possible to programmatically determine which chip you have, such as a 6551,8250, 16450, 16550 etc?

Thanks,

Walter

Not necessarily. For example, before microcontrollers were ubiquitous, I designed a small computer board to control the functions of one of our products, using the address-decoding method I show in the 6502 primer's address-decoding page. I made it able to handle either a 2Kx8 or an 8Kx8 SRAM, so our purchasing department could get whichever one had better availability and price at any given time in during the product life. (We sold it for 13 years, and would have gone much longer if it weren't for political problems internal to the company.) The above test would make it appear that there was 32KB of SRAM, or possibly even more if you start writing to I/O IC registers that would read back the same. In the case of the 8KB SRAM, testing through 32KB would hit the whole thing four times, even though three of those were duplicates of the first, writing and reading the same memory again, and passing the test for 32KB even though there's only 8KB. For the 2KB RAM, it would be 16 times.

Edit, to add: Musing on this, I can imagine a few possibilities for detecting mirroring. Here's one. Even without writing to the RAM, if you know what the possible chip sizes are, you could do something like read a stretch from one (without writing), and see if it matches what you read in another, like what's in $0200-03FF compared to what's in $2200-23FF or $0A00-0BFF. If it matches, it's the same RAM, mirrored into an additional address range. You would be able to figure out how many address bits are left out of the RAM select. (I left out ZP and page 1 since they're more likely to keep changing as the comparison program advances, and I'm sure you're not considering RAMs smaller than 1KB anyway.)


I can't think of any way. Maybe someone else here has an idea.

That's actually how it's 'normally' done. Make sure you leave a bit of free space between the end of RAM and the first writable I/O location where an unwanted write could cause issues or can be read back, and make sure your RAM decoding does not 'wrap'.
You should be able to. Provided they have different numbers of R/W registers that have different behaviors.

To sum up the two seemingly conflicting answers above, in case it's confusing any newbies, the answer is that:

In the general case, no, you can't determine the memory size and peripheral hardware of a totally unknown system. Beyond the possibility of same memory locations being mapped to multiple addresses and the like, there may also be addresses that can put the system into a funny state if written, or even if read. (The Apple II, for example will hide the text screen and give you graphics screen instead if you read certain memory locations.)

However, given a specific known set of configurations, if they're designed well, you can often find a way to distinguish between them. E.g., on the Apple II one can certainly tell which RAM sockets are filled with RAM and how much is in each, and in many cases to figure out whether expansion boards are installed in certain slots.

I think I remember seeing something on my Linux box as the kernel boots about it detecting a serial port. I might dig into the source, but, this being a home built system, I should know what parts I am putting into it

My newest memory map and decoding has a 16 byte hole, at $EF00-$EF0F. Brilliant!

Walter

Apple II had something called a Pascal 1.1 protocol for interface cards (IIe, IIgs) and built in ports (IIc, IIgs) in the firmware rom for identifying devices and rom addresses for built-in routines to access the device. The protocol was generally useful not just for pascal.

Cheers,
Andy

Generally, a RAM tester or detector will need to write and read back a couple of different values, to a couple of locations, at least. Being able to read back what you've written to a single address might only be sensing capacitance on the bus. (Edit: umm, maybe...)

Indeed, if the RAM is buffered (e.g. by a 74LS245) and the RAM is then removed, then the far side of the buffer can "float" for a long period of time. It's not perturbed by the opcode fetches (which I suspect is what you were thinking when you said maybe...)

This happened to me, with an Electron AP6:
https://stardot.org.uk/forums/viewtopic.php?f=3&t=13835

The schematic is in the first post of this thread:
https://stardot.org.uk/forums/viewtopic.php?f=3&t=6280

Dave

It is important to realise that a MPU or CPU running a simple memory test/check program may be mislead by a number of things and therefore may be unable to distinguish between real unique RAM locations and what appears to it as working RAM, but which is either not RAM or is RAM that has not been fully decoded (which is what Garth was talking about).

If you write a value and then within a short time period read a value from the same address, logic levels beyond a bus transceiver (the 74xxx245 that Dave talks about in the post above) may be maintained temporarily due to stray bus capacitance holding the voltage on each of the data lines. Thus to the simple program it looks like working RAM.

If the address decoding and the actual RAM chip(s) in use do not decode all the address lines, then certain address combinations will read the same RAM location at more than one address.

Some I/O chips / devices will echo the last written value back when read if there is no real readable register at that address.

Bank switching of memory and/or I/O devices can cause even more confusing results.

The result is that a program to detect all these possibilities would be rather complex.

In the real world, most RAM testing programs are designed with specific hardware memory maps in mind. This reduces the complexity because you are then limiting the number of possibilities.

For more, search the internet for ‘RAM testing techniques’ or for ‘test algorithms for RAM’.

For I/O chips, again, a program to try to identify the large number of different I/O chips / devices would be rather complex. If you narrow the field to a small number of different I/O chips / devices, then by studying the datasheet for each chip/device, it should be possible to write a program to at least workout what is not connected, and hence narrow down what is fitted.

However, this does make the assumption that the I/O chips / devices are wired with their register select / address lines in the conventional manner (MPU/CPU A0 to I/O chip’s A0 or equivalent) and that they are fully address decoded.

Not all designs fully decode the addresses, hence a single I/O chip or device can appear in the memory map multiple times. And sometimes the register select / address lines are not wired up as you would expect. Either of these makes the task very much harder.

Mark

No. See above replies about mirroring and the effects of parasitic capacitance.
Not usually. Certain hardware assumptions have to exist in the firmware in order to make such a determination. In PC hardware, the 8250/16450 type UART is assumed to be at specific locations in the I/O memory map because that is how the standard evolved in the PC-XT and latter.

In the case of a home-brew machine, the designer knows what is or isn't present, and what could be present, because s/he designed the circuit that way. I use NXP UARTs in my designs, and place them into the mempry map at specific places. So it's relatively easy to determine if a UART is present or absent at a particular address—test writes to certain register locations, followed by a significant delay, followed by reads of those locations make the determination. It works because of my choice of UART, not due to clever programming.

With plug-in cards, it gets more involved. Most plug-in cards for PC hardware have some ROM for boot code and the PC's BIOS has hooks that look for "option ROMs" during POST. If an option ROM is found some code is executed in it that among other things, tells the system about the hardware on the card. You can do the same thing in a 65C02/65C816 system if you are willing to add the necessary complexity.

Speaking of the 65C816, as it can address more than 64KB, an interesting "mirroring" problem arises that wouldn't affect the 65C02: "phantom" banks. In a system in which, say, only bits 0-3 of the bank are demultiplexed (demuxed), a blind write/read to an extended address can't conclusively determine if the address actually exists. In such a case, only extended address bits A16-A19 are being generated. Hence a bank bit pattern of %yyyyxxxx looks exactly the same as %0000xxxx, where yyyy is any non-zero pattern. yyyy would correspond to A20-A23 if the bank were fully demuxed.

Ah, nice one Dave! Thanks for the link too.

Perhaps we should be asking what your goals are.

In my first reply I assumed you had some idea about the architecture of the system, or had control over the architecture of the system, and that you were mostly interested in getting the BIOS to adapt to configuration changes. It seems others are not making that assumption and treating your questions as general and academic.

The identity of each of UARTs you gave in your list could certainly be determined with software, but not all possible peripherals could be, and if you have no idea what the architecture of your system is, then determining RAM size by writing then reading memory most likely would be just a shot in the dark. You would be better off taking a peek under the cover and seeing what RAM it had installed.

So, perhaps you could let us know your goals here?

Agreed. The last one I wrote would write a block at a time then read it back and do it twice using complimentary patterns (first $AA then $55).

Yeah, I think I should think before I post. I am wanting too much from my system, and havent even finalized the features it will have.

My eyes were way bigger than my skills. I will start with a simple system, and add features after I can get a design running.

But thanks for all the great responses.

Walter

Just randomly musing here ...

If you assume 64K max and contiguous RAM from $0000 to $xxFF then you could write the complement of the page number to a single hopefully innocuous byte in each page in descending order first (e.g. $00 to $FF5A, $01 to $FE5A, $02 to $FD5A ... $FF to $005A) then perform an ascending page search from $005A up to $xx5A until you encountered a value that didn't match what was expected. This plan might still choke on memory-mapped I/O and <256-byte decode granularity, but it should avoid being fooled by mirrored RAM, if I'm not mistaken.

Testing each byte of RAM might be accomplished by filling descending addresses with the XOR of the high half and low half of each alleged address, then reversing direction to see if and when the pattern breaks?