I'm looking through a disassembly of the ROM for the Commodore 1541. Specifically I'm looking at the initialization routines. I'm using the disassembly found here: https://g3sl.github.io/c1541rom.html

I'm trying to understand the startup work done in DSKINT. From what I can tell, I see the following steps:

1. Fill zero page with ascending pattern
2. Increment each value in the zero page, read back and verify.
3. Check the ROM checksum
4. Do a RAM test.

Now, #3 and #4, make sense. RAM tests were common. And ROM checks are still done today on embedded devices.

But what was the point of #1 and #2? Why fill the zero page with ascending numbers and then do a read/write/verify? Isn't this just part of the RAM check? And why use two different styles of testing? Anyone know the history/rationale on these steps?

I've dug around, but can't

Well, Page Zero gets hammered for testing first, as it holds many variables and pointers. Granted, it's a bit of an odd test...

Also note that testing the remaining RAM uses indirect addressing, so the RAM address to test is stored in Page Zero. Needless to say, if Page Zero RAM has any issues, the RAM test could fail from erroneous pointers.

BTW - nice find on the 1541 source code. I actually have the full 1581 source code and reformatted it to assemble with WDC Tools.

_________________
Regards, KM
https://github.com/floobydust

I would guess that the ascending pattern and the incrementing is intended to check that all 256 bytes of zero page are present and distinct and writeable. An addressing fault which causes, for example, only 128 bytes to be mirrored twice could be difficult to debug without a specific check.

Interesting. Mirroring is not a failure mode I would have expected. But perhaps detects a common board failure they saw before. Thanks for the suggestion.

My first gig as an intern was at a fabless ASIC company and I wrote some components for built-in self tests for RAMs and CAMs. We never did an ascending type pattern. We did marching 1's, 0xaa/0x55, and read, invert, writeback, readback. And we did check for some cross-coupled faults by writing every other address w/ 0xff/0x00. But the incrementing and ascending we never did.

I was involved in test/diagnostics for computer boards in the late 80s/early 90s and it's amazing the tests the engineers wanted - also weird to find boards that would run the tests for days in the burn-in chambers and fail 30 seconds into a customer program run... I'd often go and check the PCB layouts and try to work out stuff like cross talk, etc. I did enjoy that work for a while.

As for writing address into memory location - it's a valid test for shorted address lines - maybe even shorted data lines if there are separate address and data line buffers between board peripherals - if no buffers then any address line or data line short is really going to stop system starting in the first place... And while I've not seen the code, it's a quick and easy test to do without requiring RAM:



It may also be used to leave RAM in a known state, so debugging can see which locations may have been written.

But sometimes it might just feel like a good thing to do when it's not that effective. I've heard of worse. I think I'd probably follow that with some back to back read/modify/write tests - inc/dec instructions or shifts if I wanted to be fully confident ZP was fine before using it - if I felt the need to power on test at all...

A strategy that I adopted early on in this department was to do a basic functional "quick & dirty" test at the start, then move onto the more complex tests like alternating words, marching ants and so on. It was relatively rare for boards to fail the hard-core tests after they passed the quick and dirty ones and sometimes these were boards with vast quantities of RAM compared to the relative speed of the CPU - for the time, anyway.

A favourite test of mine was writing inverse addresses - but this was on 32-bit systems with a multiplexed address + data bus. That would sometimes throw some weird errors. No use on a 6502, but may have value on '816 systems with many MB of RAM...

CPUs with a block-move instructions were good to test too - especially on larger memory sizes - write a known pattern in the first (say) 1KB, then move that all up memory in 1K increments and test the last K. Lots of nice tricks like that but often very board specific. (We had many different CPU boards and configurations for the system as a whole)

I did start to write some test & diagnostics for the 6502 but never got round to really making it usable. Too many different systems to even think about.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The ECU in my old Fiat uses a 68xx processor with embedded internal ram and eprom. On initialisation, it carefully tests them, 256 bytes each, and uses the same routines while it's running. Unfortunately, it only checks 255 of the 256 bytes... the code contains an off-by-one error

Neil