IDISP and ACSOURCE branches

Juergen Buchmueller pullmoll at t-online.de
Tue Jun 26 18:09:05 PDT 2007


On Tue, 26 Jun 2007 09:34:47 -0700 (PDT)
"Eric Smith" <eric at brouhaha.com> wrote:

> It's unlikely that the PROM dump (or the PROM itself) is bad, since
> the bit differences are not of a uniform polarity.
>
> I suspect that it is a discrepancy between the documentation and
> actual implementation.

I agree. It's actually working fine to use the PROM for the branches. It
took me some time to work out the bits, and the (small) differences made me
nervous, but they seem to be alright.

Meanwhile I got the mouse halfway working. If you get it right, then all of
a sudden R37 begins counting the "real time" and the memory refresh task
updates the RTC RAM address... nice to see how it all plays together.

My current investigations are in the memory errors section. I think you
(we) will actually need to implement it all and correctly to get a working
emulation! Of course creating the Hamming code and Parity bits for every
double-word access is costly, but it looks like the boot code from e.g. the
Mesa0.dsk is actually expecting this piece of hardware in sane and working
condition :-O

I changed my code to use an array of RAM_SIZE/2 double-words (uint32_t) for
main memory and another array of RAM_SIZE/2 bytes (uint8_t) which contains
the 7 bits of check data: 6 bits Hamming code and one Parity bit. This very
closely matches the real hardware, except I don't have four "memory cards",
but all in one so to say.

Each memory access reads the RAM[mar/2] dword. This happens in load_mar. A
write then modifies the even [0-15], or odd [16-31] half of the dword,
depending on mar & 1, and then writes it back to RAM[mar/2], generating and
writing the 7 check bits at the same time.

A read should also generate the check bits, this time using the stored
previous check bits instead of all 0s. The calcualted Hamming code
syndrome and parity error flags would then wake the parity error task in
case of an actual error; the first error, to be exact.

This happens whenever the parity checking is enabled, and when code reads
from memory that was not yet written to. We probably won't have real memory
errors on a PC's hardware, while it'd be fun to simulate this on
occasion :-)

The error on a read seems to be the reason for a huge BLT (block transfer)
during the boot, which copies memory to self for 0000000-0176777. I was
wondering what this may be good for, and now I understood the reason why.

And yes, it looks like all this is really needed. I also think there's code
that "jumps" to the memory mapped I/O in certain ranges and will cause an
"exception", i.e. the parity task looking at the memory error
address (MEAR register), storing the values in RAM locations somewhere...

I'm by far not through with this, and can now only tell it will be good for
hours of fun ;-)

Juergen


More information about the Altogether-devel mailing list