6502.org

JAMECO used to sell them at fairly reasonable prices, which is where I got the ones I have. Now they have vanished from their site, making me wish I had bought more. I'm doing some investigating to see if there are other sources at reasonable prices.

Incidentally, Microchip (Atmel) continues to produce a 45ns 32KB PROM (OTP EPROM, Microchip P/N AT27C256R-45PU), which is available through Digikey and Mouser. Also available is a 64KB version, P/N AT27C512R-45PU, although it would be of limited usefulness in most 65xx systems.

At some point I'll have to make a decision about future ROM requirements. I'm no fan of EEPROMs, as they are slow and require wait-stating or shadowing if high Ø2 speeds are desired. Flash ROM has about the same level of performance. Maybe I'll work out clock-stretching to deal with it.

Not to go OT, but I'm thinking of using an Arduino UNO with some shift registers to load RAM during initial development. I'm just about burned out on swapping chips in/out of my programmer.

Yes, but from where will the UNO get the data that has to be poked into RAM during boot-up?

From it's internal flash. Uno (Atmega 328) has 32KB of flash. all you need is a minimal "monitor" that can then do xyz-modem to fetch the real code via serial or something into a 64K RAM system... changes to the Uno can be made via serial bootloader in a few seconds. Or you put it all in the Uno if your OS is (say) under about 16KB.

That's not quite how my Ruby 6502/816works, but it has a larger ATmega 1284 and shares the top 256 bytes of RAM with the 6502/816 (Bank 0 in the 816), so can directly write a bootloader there (it's about 200 bytes) that then talks to the Atmega via the same interface to pull the OS (10K), then BASIC (16K), etc. Re-programming the '1284 in my system takes 8 seconds to dump about 80KB of code and data into it via the ICSP interface. Booting the 6502/816 takes under a second to get the OS loaded, then one second more to load BBC BASIC if I need it.

The down-side is that turnaround from changing the OS code to testing it is not even enough time to get out of my chair let alone fetch a cup of tea...

-Gordon

Or... Arrange the address decoding to only map in 1K of the PROM at a time, selectable from the 64K (assuming you can program just 1K at a time), then you can use it 64 times, and if that 1K is enough to serial pull the rest of your code, then it might be good enough?

-Gordon

Sounds like a lot of hoop-jumping, especially since I'm going to need 12KB in my application. Having to use external hardware just to have a BIOS and drivers seems to be a solution in search of a problem.

As I said, I've got quite a few 27C256s, plus I have the capability to erase up to 20 at one time. I'll only use an OTP once the firmware is settled and it's time to move on to the next design.

Neat idea...

(Best approach, probably, is to start a new thread to discuss alternative ROM provision.)

I agree.

Here's the final schematic. PCBs and other parts have been ordered.

As a precursor to getting POC V1.2 up and running I pulled POC V1.1 out of storage and hooked it up to re-familiarize myself with the firmware and monitor. V1.1 POSTed and attempted ISL from the hard drive. So sitting on the shelf for nearly two years didn't seem to bother it any.

While I was piddling around, I removed the 25 MHz clock oscillator and replaced it with one running at 28.322 MHz. The computer POSTed and performed the ISL attempt. Since the oscillator drives a flop to produce Ø2, the system is running at 14.161 MHz, slightly above the maximum official speed supported by the 65C816. Gee, I can recall when a computer running at 14 MHz was a $30,000 piece of hardware.

The one fly in the ointment with running V1.1 at 14 MHz is the real-time clock isn't fast enough to stay with that speed—there is no wait-stating. This will also be a limitation of V1.2. However, the object of V1.2 is to develop software, not set speed records, so I can live with it. Assuming V1.2 runs okay and I get my firmware done, I may Frankenstein the gadget and see if I can get wait-stating on I/O working. It wouldn't be too surprising if the wait-state circuit had a resemblance to this.

I have all parts and have started assembling V1.2, It's kind of slow going working with only one functional eye.

I took a good look at your 1.2 PCB, nice layout with 3 SMT devices, RAM and the MAX238 chips. In every case where I've had to do SMT mounting on (pretty small) PCBs, I do those first, working from the center of the PCB outward, then solder in the through hole parts afterwards. I also use some flux remover and small cotton cloth pieces to clean around the SMT parts after soldering them in and before any through hole parts are mounted. I also inspect them with a fairly powerful magnifier lens to ensure the solder joints are clean and without any bridging.

I also have the same magnifier headset you picked up, but have not yet had a chance to use it for PCB work. I do wish you the best in working under the limited sight conditions you have... if you get into a bind, I'm happy to help out on soldering. In recent years, I've built up around 50 very small PCBs with tiny SMT parts and no failures to date... including 10 of these cool Mini DACs:

https://www.amb.org/audio/gamma1/gallery/y1_8.jpg

POC V1.2 is assembled.
Above are photos of the bare PCB. For some unfathomable reason, I decided to get red boards this time. It wasn't a good idea, as the relatively bright color gave me some grief in trying to place and solder comoponents.

Above, the PCB has the SMT hardware soldered. I mount boards on "legs" to facilitate assembly..

Above is a close-up of the SRAM, which is an SOJ32 package.

Above is a close-up of one of the MAX238 transceivers, which is an SOIC24 package.

More photos in the next post.

Above is an overall view of POC V1.2. Immediately to the left of the power connector at the unit's top right corner is a reset push button. I got tired of shorting out jumper posts with a screwdriver to reset the unit.

Also, note the one chip at the middle of the right-hand side that is socketed. That is the Ø2 clock generator flip-flop. I made it removable so I can test some ideas about clock stretching, which will involve plugging a daughterboard into the socket. This, of course, assumes this thing actually works.

Above is a rear view of the unit, showing the four serial ports and the power connector.

Above is a close-up of the ROM ZIF socket, which plugs into a standard DIP socket soldered into the board.

Next step will be to burn a ROM with some firmware and see if she goes or blows.