AIM-65 SBC

[MrBiff]

Hi,

I am in the process of building an AIM-65.
Before committing to a complete PCB, I am designing a reduced version AIM-65 Mini.
I intend to use the TTY feature with a MAX232 and to leave out the keyboard and the display till the next revision.
I am still debating using the expensive DL1416 parts or substituting a cheaper display.
This is why I have added a 6847 comp video circuit.
I am using the AIM-65 R5 version as the basis of my design.
I was wondering if anyone else had already done something similar?
I have attached my draft schematic.

Thanks

[HansO]

http://retro.hansotten.nl/6502-sbc/emuf ... ompatible/

a AIM65 clone design.

[Biff]

Here is my micro AIM-65 version 2.
My first version was missing the 6532 which is used for the TTY/RS232 parameters.
I guess I should have translated the german article sice it has the 6522/6532 combo as well.
My next project will either be the full AIM 65 or a CRT module.

[barrym95838]

Very nice! You should cover your EPROM window to reduce the risk of unstable behavior.

[6502user]

I have three question about the AIM-65 Micro V2_2022-04-02:
1.- Are you loading the AIM Monitor firmware from Rockwell onto your 27C256 EPROM?
2.- What is the use of the H4 pinheader jumper between CA1 and CB1 on VIA 65C22?
3.- Did you use a 65C22 VIA instead of a 6522 VIA for some reason?

And a note if you are not going to use the AIM65 keyboard:
You might not need the RIOT 6532 by enabling access from $A400 to $A4FF addressing to your RAM area instead to use the 6532's R/W memory space, or by modifying the monitor's .asm code to allocate some parameters in the memory area that you want and then and reassemble it.
So easy as rewrite:

Code: Select all

                    ;      **********************************
   0147             ;      *  Ex_6532 ADDRESSES (A400-A7FF) , parameters new area in RAM    * 
   0147             ;      **********************************
   0400                  *=$A400  ; eliminates this line changing it by the following 
   XYZW                  *=$XYZW  ; where $XYZW is the start address area in RAM that you want use to reallocate the parameters

Then, reassemble all the monitor .asm code and load it in an EPROM.

[drogon]

barrym95838 wrote:

Very nice! You should cover your EPROM window to reduce the risk of unstable behavior.

FWIW: I made this in the 80's:



It has been kicking about my room/office(s) since then, sometimes on a shelf, sometimes in a box and recently I decided to remove the UVEPROM and read it... It disassembled just fine.

Sample size 1, YMMV, etc.

-Gordon

[Dr Jefyll]

barrym95838 wrote:

You should cover your EPROM window to reduce the risk of unstable behavior.

drogon wrote:

I decided to remove the UVEPROM and read it... It disassembled just fine.

In case it's unclear, Mike wasn't warning about accidental erasure of the EPROM. Instead, the problem is a temporary effect that can appear when light is allowed to strike the die... and which will disappear when the die is restored to darkness.

I personally got bitten by this in 1994. In my case the chip in question was a 68HC705 EPROM-based microcontroller. According to my understanding (gained after the fact), the PN junctions on the die can translate light into voltage, just as does the PN junction in a photovoltaic cell. On a PV that's a good thing, but of course on an EPROM these voltages are unexpected and not exactly.... helpful.

-- Jeff

[drogon]

Dr Jefyll wrote:

barrym95838 wrote:

You should cover your EPROM window to reduce the risk of unstable behavior.

drogon wrote:

I decided to remove the UVEPROM and read it... It disassembled just fine.

In case it's unclear, Mike wasn't warning about accidental erasure of the EPROM. Instead, the problem is a temporary effect that can appear when light is allowed to strike the die... and which will disappear when the die is restored to darkness.

I personally got bitten by this in 1994. In my case the chip in question was a 68HC705 EPROM-based microcontroller. According to my understanding (gained after the fact), the PN junctions on the die can translate light into voltage, just as does the PN junction in a photovoltaic cell. On a PV that's a good thing, but of course on an EPROM these voltages are unexpected and not exactly.... helpful.

-- Jeff

Interesting - although in the 80's I was doing uv-eproms for about a dozen different systems (mostly 6502 but one 8085 not that that matters), and don't recall ever using the sticky black tabs for the windows, however I'm now reminded of the "XENON DEATH FLASH" "feature" on Raspberry Pi's which I suspect is a similar effect. (Light bouncing off the PCB into an exposed bit of silicon on an top-covered chip only).

-Gordon

[Dr Jefyll]

Yes, I readily agree -- it's a rule you can very often get away with breaking. And I'm as guilty as anyone, because I myself very often did break it (and did get away with it)! But having no awareness of the issue puts you at risk of a very bad headache if and when it does crop up. You'd end up fighting an elusive intermittent, and no amount of connection wiggling or extra bypass capacitors would help you.

-- Jeff

[BillO]

I don't think you have to go to the effort of putting something black over the window. A simple white paper label should suffice. You will them get no direct light from strong sources. Plus you can write (or print) an ID on it so can keep track of version/function/date/etc...

[GARTHWILSON]

When I went to a seminar for PIC microcontrollers in the mid-1990's when they were mostly EPROM-based, the instructor warned about possible misbehavior caused by light coming through the window and hitting the die; so I just set something on it in testing, to keep the light out.