While there's nothing new about 3.3V circuits and parts, they just don't seem to be that common for home-brew stuff like most of here end up building. As 5V parts become less over time, not to mention that DIP parts are also becoming less available (as new manufacture) lower voltage SMT parts are becoming more prevalent from the usual parts distributors (Mouser, Digikey, etc.). Based on all of this, along with preferring denser populated PCBs, I've opted to start designing and building with SMT parts and go towards 3.3V as well.

For a start, my plan is to modify one of my existing C02 Pocket SBCs. The existing parts which will need to be swapped out are:

EEPROM - AT28C256
PLD - ATF22V10
CPU Reset - TL7705B
NMI trigger - DS1813
UART - SCC2691
6MHz DIP-8 Clock Oscillator
FTDI USB-UART - 5V

According to the Datasheet, the existing Alliance 32KB SRAM is good down to 2.7V. I've managed to sort the other required components which are:

PLD - ATF22LV10 (in DIP-24)
CPU Reset - TL7733B (in DIP-8)
NMI Trigger - DS1233A (TO-92)
EEPROM - AT28BV256 (SOIC-28)
DIP-8 Can Oscillator in 3.3V supply
FTDI USB-UART - 3.3V (DB-9 connector replacement)

I also located an adapter to convert the SOIC-28 to 28-pin DIP. I also have some SC28L92 DUARTs, so I'll make an adapter for that. I can move the crystal and loading caps onto the adapter board and repurpose one of those pins on the SCC2691 for the extra address line required. As the replacement EEPROM is rated at 200ns, I'll likely only get 8MHz operation, which is fine, as this is just an initial test to get a working system.

If this is successful, then I'll modify one of the Compact Flash / RTC adapter boards and see if I can get that working at 3.3V as well. For the older IDE standard, 8MHz is pretty much the specification limit, but there's no harm in attempting to push it a bit quicker if everything else survives. As the W65C02S is easily overclocked at 5V, it will be interesting to see how much it can be overclocked from it's 3.3V 8MHz rating. Also wondering if anyone has tried a 3.3V system and what clock speed was achieved.

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

Changing to 3.3v does open up a lot of possibilities for CPLD's and even FPGA's. But it also reduces the amount of historical 6500 chips that can be used, there are not many 6502 peripheral chips available in 3.3v.

I'm a bit more confident with SMT now, but one of the bigger issues is ROM's. A socketed chip can be programmed, but a soldered one is a lot harder. I've been thinking about options for in-place programming but haven't come up with a lot of solutions. One plan was a socket for a programmer, but that is complex and takes up space. I know others have had success using more modern microcontrollers to put code in RAM before starting the CPU, but I'm going to try using a SPI FLASH and using a CPLD to copy it out to RAM at startup. I hope I have enough space left in the CPLD to do this, but the big advantage is that there is no slow ROM on the bus, so faster CPU speed should be easier.

Well, I started working the first phase of moving to a 3.3V platform. As I'm basically cobbling this up using an existing C02 Pocket SBC, I first needed to swap out the SCC2691 UART and get a SC28L92 DUART working, as it will operate at both 3.3V and 5.0V.

I made a small adapter on perf-board with a pair of dual-pin headers to plug into the 24-pin DIP socket and a PLCC-44 pin socket. As I need more than 24-pins for the DUART, I added a small crystal and a couple 24pF caps for the local oscillator and was able to re-purpose one of those pins for the extra address line. The SCC2691 only needs 3 address lines while the SC28L92 needs 4.



After making up the adapter, I added one bodge wire to the Pocket SBC board and the hardware part was done. An interesting side note... I hate doing hand-wiring and counting pins these days... bores me to tears. I used ExpressPCB software, made a quick schematic using the two UARTS, added a crystal and caps, then went to PCB layout. I added the two sockets, then flipped the PLCC socket over and linked the schematic to it. By showing the wiring links, I had a quick and easy method to highlight pin connections and was able to wire it up quickly.

Plugging it into the Pocket SBC...



While I was traveling, I modified my existing BIOS and Monitor and was able to get the first serial port working. Only a few changes were needed to the Monitor, mainly removing some caveat code for managing the higher speeds of the SCC2691 (which is quirky to get 115.2K). The BIOS changes were more, as I also added all of the page zero variables and the routines to support the second serial port. I still need to finish the ISR to handle the second port, but it's all working including the counter/timer, break and receive/transmit under interrupt control.

Just for chagrins, I kicked up the clock speed... 12-MHz was no issue... 16-MHz didn't do anything... but there's other bottlenecks there with the EEPROM and the SRAM speeds (70ns). I doubt the ATF22V10 would be a speed issue, so it's also likely that the DUART can't run with a 16-MHz clock rate.

Now that phase 1 is completed, it's time to cobble up a 3.3V system (spare PCB will be used) and see if I can that do power up and run.... ah the fun!

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

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

Yes, I've been through the datasheet on this quite a bit... it is slower at 3.3V, but not by a huge margin. Still, I agree that it won't manage 16 MHz at the lower voltage, which is okay.

The next C02 Pocket SBC (version 3) will integrate a DS1501W RTC and a 16-bit IDE port as well, so those devices are also on the slow side, with IDE being around the 8 MHz rate and not really designed for more than that. My goal is to use a single CPLD, the ATF1504ASV (3.3V part), to provide all glue logic.

I'm hoping I can manage that bit of design... where I'm thinking it might be possible to have the CPLD provide all clocking. An idea of having a main 16 MHz clock rate and then a divide-by-2 rate of 8 MHz. When any I/O devices are accessed, the 8 MHz clock rate is used. Granted, it's just an idea at this stage... no idea if there's a way to make it work. In any case, 8 MHz would be a decent clock speed for the board.

Still a long way to go... as the plan is to keep the board size at 3.8" x 2.5", hence the "Pocket SBC" naming.

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

Sounds good to me - will follow with interest.

Just for grins, I thought I remove the 4.5V voltage supervisor on CRC65 and lower the voltage until it fails. I found I can lower the voltage to 3.4V and still pass memory diagnostic. The clock is 14.7MHz. CRC65 won't boot lower than 3.4V. However at 3.4V, the mandelbrot benchmark is not running correctly. I need to raise voltage to 3.5V so EhBASIC can run mandelbrot benchmark correctly. To reiterate, this is a standard CRC65 with W65C02, CPLD, RAM, 14.7MHz oscillator and CF disk but with MCP130 voltage supervisor removed.
Bill

Yes, the W65C02 is spec'd to work down at 1.8 volts, and of course Compact Flash will also run at 3.3V, so the only other parts to be concerned with are the CPLD, RAM and the can oscillator. I'm guessing that perhaps the oscillator either stopped working or the CPLD gave up.... as the only other option is the RAM.

I've done more work on the BIOS and got the second serial port written up in BIOS (untested as of now), but I've had the modified C02 Pocket running at 12 MHz for the better part of the day using the Macro facility of the Monitor to endlessly hammer memory, hit the timer consistently (for delays) and drive port A of the 28L92 at 115.2K baud non-stop. It hasn't skipped a beat so far.

I've got parts for building up a 3.3V version of my C02 Pocket... 3.3V rated parts for the RAM, EEPROM, 22V10 PLD, Reset Chip, NMI trigger, can oscillator and the FTDI UART to USB adapter. I'm hoping it just works once I get it built up... in theory, it "should". Once that's done, I'll do the same for my RTC/CF-Card adapter with 3.3V parts and hopefully I'll have a full functioning system running DOS/65, time will tell.

If I'm successful with all of the above, the final phase is to create a single board (mostly SMT parts) and a single CPLD glue logic setup... that will be the bigger challenge. I've also decided on using some of the older Microdrives with the 35-pin PATA interface. These are strictly 3.3V devices, smaller than the same compact flash version and the FPC socket is very tiny, as it's 0.3mm spacing. I'll need some luck on this project... and maybe some assistance on the CPLD... we'll see!

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

I attached my RTC/CF-Card adapter... it didn't boot at 12 MHz... as it first attempts to sense and load data from the RTC, then does a test and config for the IDE port on the CF Card. Not a big surprise... knocked the CPU clock down to 10 MHz and both devices are properly sensed and setup.

I had to make a few minor changes to DOS/65 due to the new BIOS having some different Page Zero usage... but now have DOS/65 running as well. Granted, this is still a 5.0 volt system, but now using the SC28L92 DUART versus the original hardware config using the SC2691 UART.

As the clock rate is higher, performance of the CF-Card transfer rate has gone up... now at 397KB per second, not too shabby!

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

You do have plenty of component choices at 3.3V. Since I'm familiar with Altera products, I personally would use EPM240 or EPM570 as the 3.3V CPLD. EPM240 is about $10 at Mouser, but quite a bit cheaper at UTSource. It has 8K bits of non-volatile memory which is plenty for a bootstrap ROM. It also has twice as many macrocells as EPM7128S so plenty of room to build parallel port, timers, serial ports, etc.

I may have few EPM570 laying around that can be kludged into a CRC65, hmmm...

Yes, the Altera CPLDs are very nice... and I do have a version of Quartus running in a VM.... but I'm not thinking about a boot ROM from the CPLD. My current thinking is to use a 128KB SRAM and a 128KB NOR Flash (socketed) (both are available in 3.3V and 55ns access speed).

On power up, at least 32KB of the ROM is selected... this code will contain a full set of POST routines and a detailed setup menu. (Note: RAM test can be tricky.... but hopefully a memory map swap can be done dynamically under software control.) This will sense for a valid setup config on power up. If one doesn't exist (using a checksum of the NVRAM in the RTC) then the setup is invoked, otherwise the user can hit F1 to enter setup to change things.

Once the POST routines run and a valid hardware configuration is found (RTC set, IDE device configured, etc.), I'm thinking to use one of the output port lines of the SC28L92 and flip a pin on the CPLD, which will change the memory map (now mostly RAM and no more than 8KB of ROM). The 8KB ROM address will contain the BIOS, a Monitor and a boot loader to load a block of data from the IDE device and start the boot process for DOS/65 or something else.

A while back, I did pick up a couple of the Microchip (aka Atmel) ATF1502/4 devices and their programmer, so I have something to work with... just not sure if one of these devices will handle everything, but I'm hoping so.... much to learn on the CPLD side. I sorta know what I want to do, just not sure how to get there yet.

On a completely different note, I decided to test the small number of compact flash cards that I was having trouble accessing earlier. This goes back to last year... an STI card would not work, nor would a 2GB card that was labelled as SanDisk but the identity data was no brand... neither worked. For some odd reason, these cards now work perfectly fine! I can't explain why... as the only changes to the hardware was swapping the SCC2691 for the SC28L92 and the only BIOS changes were in the init routines, ISR and such required for the SC28L92. The existing BIOS code for the RTC and IDE were not changed at all. So.... I guess I'll try looking into this at a later date, but it's certainly not pressing at this moment.

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

Your CF disks are operating at 3.3V, right? Lower voltage makes a world of difference in lowering system noise.
Bill

Nope, these are on the 5V system... the only change is the SC28L92 DUART in place of the SCC2691. I ran out of 24-pin DIP sockets... so I have these coming on Monday most likely. Once these are in, I'll build up a 3.3V system and move to the next phase of testing. I'm confident of getting an 8 MHz setup, but I'll test and see if I can get any faster at 3.3V. So far, I can get the DS1511 and the CF Flash in IDE mode running on a 10 MHz system without issue, albeit on a 5V system.

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

So, the remaining parts came in today, yay!

I built up an extra C02 Pocket SBC (version 1.00 PCB, which needed 4 bodge wires) with all 3.3V parts. I could only find a SOIC outline EEPROM (AT28BC256-20) which is 200ns access time. I also picked up an adapter from Proto-Advantage which allowed me to plug it into the 28-pin DIP socket.



The other changes required were:

1- Resistors going from 3.3K to 1.5K
2- The ATF22V10 going to an ATF22LV10
3- The TL7705 going to a TL7733
4- The DS1813 going to a DS1233A (which has the pin layout reversed of all things!) and an additional 0.1uF cap across the Panic switch.
5- The FTDI USB-UART adapter going to the 3.3V version.
6- Can oscillator replaced with a 3.3V version (4 MHz)

Once the board was completed, I plugged all the chips in, made an adapter for a 3.3V wall-wart supply and attempted the smoke test. Happy to report, it works!

One sad issue... the PLD I had picked up was the CQZ version... so the newer 55ns SRAM won't work. I'm going to order the newer parts which have a supported voltage range of 3.0 - 5.5V. That "should" resolve the problem. I also used a 0.33uF decoupling cap on the PLD... no luck, made no difference. So the CQZ parts are out going forward... one less issue to resolve.

I also did a quick conversion of my early RTC/CF-Card adapter (also a 1.00 PCB version)... had to change out parts on the board:

1- RTC went to the DS1511W spec, which is 3.3V
2- The pair of 74HC573 latches went to 74LVC573
3- The ATF16V8C went to a ATF16LV8X (which is a TSSOP outline)... once again, adapter sourced from Proto-Advantage.

I now have the adapter working with RTC and CF-Card access. I even brought up DOS/65 and that's working as well. Overall, pretty happy about getting the prototype working so easily. As the EEPROM is only a 200ns part, 4MHz is it.... 8MHz doesn't work, not a big surprise.

My next phase is to replace the Compact Flash with a Microdrive, which uses the 35-pin PATA interface. These are strictly 3.3V devices, so now that I have a working 3.3V system, I can take the approach of wiring one of these in and see if I can get that working. Oh the fun....

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

I picked up some adapter bits to use the Microdrive with it's tiny 0.3mm pitch 35-pin FPC connector. Ebay sourced and quite nice. So, I handwired 34 wires to the bottom of an existing RTC/CF-Card adapter. It worked on first power up, but there's some difference in the BIOS required from what I wrote for Compact Flash cards (running in True IDE mode).

It's a bit of an erector set, but it's a fully functioning system on 3.3V running at 4 MHz. I've also got DOS/65 (my 3.03 CMOS version) running with the drive. Performance is quite good, transfer rates comparable with CF Cards. The drive is dead silent... you just don't hear it when it's running.



I can use this setup to finish updating a new BIOS version and probably some minor changes to the Monitor code. I've still got just over 55 bytes of free space in the upper 2KB allocated for the BIOS, albeit this 2KB area has the I/O carved out of it, which takes 160 bytes. As of now, the BIOS supports the SC28L92 with both serial ports interrupt driven and RAM buffered and the timer for use as a jiffy clock. The IDE portion supports interrupt driven data transfers as well and runs in LBA mode. I'm working on adding multiple block transfers as well, which will speed things up a bit (provided an OS of sorts could use it).

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