AIM-65 homebuilt semi-replica

[Marta]

A new MPU has arrived and the JSR (ABS,X) problem has departed. Everything looks fine at the scope, the JSR "lands" spot on the intended target. The instruction is re-inserted where it was ment to be when all this trouble started and everything works perfectly!

Hopefully the computer will be OK now. Even if the JSR (ABS,X) is a very expendable instruction, having the problem present gave an iffy feeling. The hardware must be absolutely trustworthy when programming and magic effects pops up. Not a shadow of a doubt that it's the software that is in error.

I'm still very curious if the old MCU really is bad. I will do one more test with it. Hardwire the $FC opcode by eight resistors on a breadboard and see what happens. Will try to have that done in the next week, but no promises.

Any comments are highly appreciated.

[BigEd]

Relatively surprising, but I think a conclusive result!

[Dr Jefyll]

Your previous test was quite persuasive, but somehow I'm mildly surprised anyway by this latest result. You certainly seem to have proven there's a problem, but yes -- when you get time, please do the "$FC opcode with resistors" test and report back. (Ideally you should test *both* chips, just to "test the test".)

Also I wonder, is this a random error in the wafer that became your chip, or was there a design flaw that affected one or more entire batches of chips? Probably the former, but we'll never know... unless we can find an Erratum report, or a sibling Sanyo chip which can be tested.

-- Jeff

[BigEd]

(I would suspect a 'test escape' - a chip with a flaw, not picked up by the production test. One bad via, one leaky transistor, might be enough. There's also the possibility of a field failure, caused by contamination, metal migration, hot carrier injection, even crystal lattice defect...)

[Marta]

I will see if I can do the test ASAP and also test with a higher clock.

Did the old 800nm Sanyo contain dynamic circuitry?

I have searched quite a lot for errata, but turned out negative. The faulty chip has an uncommon(?) date stamp of 9906, but is bought directly from WDC around 2003 so it's 100% genuine.

[Marta]

The machine now seems to work nice and stable, so I'm going on to make programs for it.

One of the first tasks is to allow something else than tape to be used to store/load using the built in commands. The AIM monitor program has the "U"ser option for device. The character output has to be blocked before transfer to the Linux and even if sending char-by-char the file has to be closed. But how to know when to flush the last incomplete block and close the file?

The best I can come up with is to use one of the F-keys as a maual EOF, or do the same from the PC side. Timer is not an alternative when waiting for Y/N prompt. Looking for end record takes CPU and does not work for all output sources. A hack in the monitor does not work for BASIC and others.

This issue must have been there even back then, so does a standard solution exist? Or was all media of character type and without the need of closing?

[BigEd]

I think probably everything was characters, which were written as they were output.

So your best bet might be one or more heuristics: don't necessarily close, but flush the file when there's a pause, or an end of line character, or a user request. Is a timer certainly not an option? The code that's waiting for a prompt is presumably spinning, so it could count while it spins.

[Marta]

It worked out that the best solution was to have a manual close signal initiated from the PC that flushes the buffer and close the file. The 816 can of cource also initiate this from new programs that are aware of that files needs closing.

Now to the next issue, that was slightly unexpected.
Using the SAVE command in the original AIM BASIC and selecting U as device just outputs a string of CRLF's and a ^Z. Using the GWBASIC works just fine.

Does any of You have any info about this?