Marco! You're back! How are you feeling?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I've been able to work some more on getting POC V2 functional.

The principle struggle has been with the QUART, or rather with the QUART's documentation. The process of getting bi-directional hardware handshaking to function has been hampered by the terse description of the I/O ports that handle this feature. CTS/RTS handshaking with the 28C94 doesn't work the same as it does on the 26C92 and 28L92 DUARTs. As my hookup to the terminal requires hardware handshaking in order to get reliable communication, it took some doing to read between the data sheet lines and determine how to get it working. I have leaped that hurdle and can hammer the terminal with data as fast as possible and get glitch-free transmission. I also can hammer the input to the QUART as fast as the terminal can go (150 CPS) and the QUART will de-assert RTS every time when the FIFO fills.

With this little task out of the way I should be able to start to get a working BIOS put together. An interesting part of it will be in learning how to use the QUART's interrupt "bidding" feature to reduce latency. That won't be necessary for the first cut, as I can poll my IRQ sources, as I am doing with the DUART in POC V1. However, I do want to learn how to do it, as it could pay considerable dividends in performance when a lot of serial I/O is going on.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Sorry, I saw this post yesterday! Thanks, I'm feeling relatively good.

Happy and healthy 2017!

_________________
Marco

He lives, ladies and gentlemen! Glad to see you around, Marco.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Somehow in all the excitement of getting POC V2 up and running I didn't post any "formal" pictures of the unit. Here they are, along with the contraption's schematic.
————————————————————————————————————————————————————————————————————————————

Above is POC V2 ready to run. Major components. starting from the left, are the TIA-232 output jack, MAX248 transceiver (PLCC44 package), NXP SC28C94 quadruple UART (QUART, PLCC52 package), Maxim DS1511Y real-time clock (EDIP28), AMD 27C256-55 EPROM (DIP28 package), two Cypress CY-1049D-10 512KB SRAMs (SOJ36 package), Atmel ATF1504AS CPLD (PLCC44 package above the SRAMs) and last but not least, the W65C816S microprocessor (PLCC44). The SOIC14 package at the MPU's bottom right corner is a 74AC74 flop that produces the Ø2 clock. Two Maxim DS1813 econo-resets are immediately to the right of the 65C816. One is the actual reset generator, the other dampens the NMI circuit. Power input is at the top right corner of the computer. A JTAG port for in-circuit programming of the CPLD is immediately to the left of the CPLD itself.



Above are the four TIA-232 serial ports in a connector style referred to as a "harmonica". These are 8P8C receptacles, often mistakenly called RJ-45. The leftmost port is for the system console. The second from the left port is for linking up to one of my Linux servers so I can transfer in data using Motorola S-record format. The remaining ports are uncommitted and can be used to connect another terminal, a serial printer or other serial device, e.g., a modem. Serial I/O can be run as fast as 921Kbps, simultaneously on all four ports. The default setup configures all four ports to run at 115.2Kbps, with CTS/RTS flow control.



Abover are the console type selection jumpers. One of the projects that I currently have sitting on the back burner is a build of Geoff Graham's VT-100 mini-terminal. This ingenious little gadget uses a microcontroller to both generate a VGA signal and scan a PS/2 style keyboard. While the mini-terminal follows TIA-232 communication standards (8N1, etc.), the hardware interface is at TTL levels, not TIA-232. So I have rigged up POC V2 so communication channel A in the QUART can either connect to the MAX248 and drive the console port as a TIA-232 port, or connect directly to the console port, thus making that port TTL instead of TIA. When the jumpers are configured for TTL the DTR signal becomes Vcc to power the mini-terminal. In TTL mode, the four jumpers on jumper block JP4 are removed so the MAX248 is isolated from the channel.



Above is the power input jack. Like POC V1, POC V2 is designed to be powered by a standard PC power supply, using only the 5 volt source. POC V1 had a four pin Molex connector like found on a 5-1/4 inch floppy disk drive. I decided to use the smaller Berg connector, found on 3-1/2 inch floppy drives, on POC V2. Aside from using less PCB real estate, this connector is less a pain to work with than the Molex one.



Above is POC V2's schematic and parts list, including system architecture and hardware memory maps.

I originally intended to arrange the "expansion port" so that the SCSI host adapter I developed for POC V1 would work. However, I've since developed an updated host adapter that uses active bus termination instead of Thévenin termination, allowing me to use a much longer cable without having to worry about possible bus glitches. Active termination requires use of a local 3.3 volt power source to bias the bus when it isn't in use—everything on the single-ended SCSI bus is high-Z during the bus-free phase, and signals are low-true in all cases. The new host adapter design uses an on-board 3.3 volt LDO regulator to furnish termination power, which means the adapter will draw more juice from the computer. This requirement led to me "repurposing" one of the pins on the expansion port to become a second Vcc source.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Lookin' good, BDD!

Y' might want to get into the habit of using a label to keep the EPROM window covered, though, so light doesn't get in. Darkness is important to prevent flaky operation; it's more than just a question of preventing inadvertent erasure. ( Been there, done that -- the no-label mistake -- with an EPROM-based microcontroller.)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Very nice indeed, I've followed the progress and great to see it come to life.

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

Thanks! So far, I haven't run into any hardware show-stoppers. That, of course, doesn't mean they aren't in there, lurking like an alligator in a Florida golf course water trap.


The EPROM in the picture was from my collection of freshly erased ones, so i didn't bother to protect it from the bright lights. Naturally, I'm careful with the programmed ones, since some years back, I had the same experience you did.

I have POC running on one of my desks in my office. I normally keep the office dimly lit—no overhead lighting—because my eyes don't tolerating bright light anymore. Unprotected EPROMs are safe in that environment.

You bring up a good point about using EPROMs. Although we normally think of using intense ultraviolet light to erase an EPROM, one can be erased by almost any strong light source that is in the right wavelength range. Here's what ST Micro has to say about it in the data sheet for a 27C256:

2.10 Erasure operation (applies for UV EPROM)

The erasure characteristics of the M27C256B is such that erasure begins when the cells are exposed to light with wavelengths shorter than approximately 4000 Å. It should be noted that sunlight and some type of fluorescent lamps have wavelengths in the 3000-4000 Å range. Research shows that constant exposure to room level fluorescent lighting could erase a typical M27C256B in about 3 years, while it would take approximately 1 week to cause erasure when exposed to direct sunlight. If the M27C256B is to be exposed to these types of lighting conditions for extended periods of time, it is suggested that opaque labels be put over the M27C256B window to prevent unintentional erasure.

The recommended erasure procedure for the M27C256B is exposure to short wave ultraviolet light which has wavelength 2537Å. The integrated dose (i.e. UV intensity x exposure time) for erasure should be a minimum of 15 W-sec/cm2. The erasure time with this dosage is approximately 15 to 20 minutes using an ultraviolet lamp with 12000 μW/cm2 power rating. The M27C256B should be placed within 2.5 cm (1 inch) of the lamp tubes during the erasure. Some lamps have a filter on their tubes which should be removed before erasure.

Speaking of erasing EPROMs, here is what I use.

The UV light source is a 22 watt germicidal lamp, which emits UV at 253.7nm, short enough to erase 20 EPROMs in 15 minutes. The box on the right hand end has a timer so I don't have to babysit the thing.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I should've been more explicit. Accidental erasure isn't the key point. Darkness is important to prevent flaky operation.

My project demo began behaving intermittently -- after delivery to the customer, embarrassingly. Luckily my partner on the project recognized that photosensitivity might be the cause, and warned me. When I covered the window the symptoms disappeared.

It wasn't a case of erasure. The stored data was intact. But the ambient light was enough to produce photovoltaic effects that upset normal operation. Once the label had been applied we were good to go. It wasn't necessary to reprogram the chip (a 68HC705 EPROM-based microcontroller).

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

When I went to a Microchip seminar on their PIC microcontrollers in the 1990's, I remember the instructor saying you should cover the window during programming. (This was when there were still a lot of EPROM-based PICs.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I wasn't aware that they were so sensitive that they would malfunction, even though the programmed data itself wasn't affected.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It was news to me, too. I don't know what the authoritative explanation is, but certainly the chip has umpteen PN junctions, and I'm ready to believe that a PN junctions exposed to light equals a solar cell -- and the resulting voltages in all those locations wasn't planned for. Anyway, it's darn lucky someone warned me! It seems only fair to pass the warning along.

I'm sure we've all seen cases where the window was uncovered and it DIDN'T result in a problem, and I can't say why that's very often -- but not always -- true. But if things do go scwewy, covering the window is very quick and easy -- definitely worth a try. Otherwise I hate to think how long that problem might've taken to track down.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The Raspberry PI 2 had a similar problem where people could crash the board by using a Xenon flash to take a picture. Apparently, one of the chips wasn't coated opaquely enough to block the light. See https://www.youtube.com/watch?v=SrDfRCi1UV0

I still have a stack of 5&1/4" disk write protect tabs because they worked so well to cover eprom windows