Connecting the Apple II bus to 3.3V logic [message #395298] |
Wed, 03 June 2020 13:25 |
|
Originally posted by: Scott Alfter
I've gotten an idea in my head to try knocking together a hard-drive
replacement that would use a MicroSD card. I picked up a TinyFPGA BX
(https://store.tinyfpga.com/products/tinyfpga-bx) a while back to start
learning about FPGAs, and I suspect it'd be up to the task of managing block
reads/writes to an SD card, and maybe even providing ROM to make the device
bootable.
Like nearly everything anymore, the TinyFPGA BX is a 3.3V device, so it
can't attach directly to the Apple II expansion bus. There are some things
that are usually buffered anyway (most cards put a 74LS245 across the data
bus, for instance). From what I've read on the matter, 3.3V outputs will
usually drive 5V inputs adequately, while 3.3V chips with 5V-tolerate inputs
will protect 3.3V inputs. In place of the ubiquitous 74LS245, would I want
a '245 from the LVT or LVC family? For unidirectional signals (such as the
address bus), would a 74HC4050 running at 3.3V get the job done?
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
|
|
|
|
Re: Connecting the Apple II bus to 3.3V logic [message #395405 is a reply to message #395298] |
Fri, 05 June 2020 02:47 |
mdj
Messages: 301 Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, 4 June 2020 03:25:07 UTC+10, Scott Alfter wrote:
> I've gotten an idea in my head to try knocking together a hard-drive
> replacement that would use a MicroSD card. I picked up a TinyFPGA BX
> (https://store.tinyfpga.com/products/tinyfpga-bx) a while back to start
> learning about FPGAs, and I suspect it'd be up to the task of managing block
> reads/writes to an SD card, and maybe even providing ROM to make the device
> bootable.
If you're only interested in the low(er) speed SPI mode of SD, this will work fine, but will be like using a sledgehammer to squash a fly ;-)
> Like nearly everything anymore, the TinyFPGA BX is a 3.3V device, so it
> can't attach directly to the Apple II expansion bus. There are some things
> that are usually buffered anyway (most cards put a 74LS245 across the data
> bus, for instance). From what I've read on the matter, 3.3V outputs will
> usually drive 5V inputs adequately, while 3.3V chips with 5V-tolerate inputs
> will protect 3.3V inputs. In place of the ubiquitous 74LS245, would I want
> a '245 from the LVT or LVC family? For unidirectional signals (such as the
> address bus), would a 74HC4050 running at 3.3V get the job done?
The short answer is yes you can use a HC both as you suggest and in place of the '245, but you will need to use series resistors on the 5v side to limit potential current runaway due to there potentially being gate voltages in excess of VDD.
If you're just planning on a one-off DIY, I would suggest grabbing some 74LVC245 parts in DIP. These are cheap, and you can rig the direction pin either way to turn it into an 8 way level shifting buffer.
Matt
|
|
|
Re: Connecting the Apple II bus to 3.3V logic [message #395436 is a reply to message #395405] |
Fri, 05 June 2020 14:37 |
|
Originally posted by: Scott Alfter
In article <74e6367a-20ea-4fa9-bfc9-b05691d609f8o@googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:
> On Thursday, 4 June 2020 03:25:07 UTC+10, Scott Alfter wrote:
>> I've gotten an idea in my head to try knocking together a hard-drive
>> replacement that would use a MicroSD card. I picked up a TinyFPGA BX
>> (https://store.tinyfpga.com/products/tinyfpga-bx) a while back to start
>> learning about FPGAs, and I suspect it'd be up to the task of managing block
>> reads/writes to an SD card, and maybe even providing ROM to make the device
>> bootable.
>
> If you're only interested in the low(er) speed SPI mode of SD, this will
> work fine, but will be like using a sledgehammer to squash a fly ;-)
The idea I have is to have the FPGA manage communication with the SD card.
The Apple II side of the interface will be some registers and buffers that
are accessed in a slinky-RAM-like manner. To read a block, stuff a block
number into a register, issue a "read" command, wait for the read to
complete (it shouldn't take long as the FPGA is clocked much faster than 1
MHz), and copy the block to the destination buffer. Writes would happen in
a similar manner.
The initial build will likely just provide space to drop in a TinyFPGA BX,
which runs about $40 assembled. The FPGA it uses, a Lattice iCE40LP8K-CM81,
sells for $6 or $7 in small quantities.
It would be possible to bit-bang SPI with simple hardware, but at 1 MHz,
that's going to be painfully slow. There's already this card, which uses a
Xilinx CPLD to do most of the heavy lifting:
https://github.com/freitz85/AppleIISd
It only provides up to 4 volumes at up to 32 MB each, which precludes
setting up a big HFS partition as a "dumping ground" for archives and such.
Otherwise, I'd be inclined to just build one of these and be done with it.
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
|
|
|
Re: Connecting the Apple II bus to 3.3V logic [message #395544 is a reply to message #395436] |
Sun, 07 June 2020 22:39 |
mdj
Messages: 301 Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, 6 June 2020 04:37:13 UTC+10, Scott Alfter wrote:
> It would be possible to bit-bang SPI with simple hardware, but at 1 MHz,
> that's going to be painfully slow. There's already this card, which uses a
> Xilinx CPLD to do most of the heavy lifting:
>
> https://github.com/freitz85/AppleIISd
>
> It only provides up to 4 volumes at up to 32 MB each, which precludes
> setting up a big HFS partition as a "dumping ground" for archives and such.
> Otherwise, I'd be inclined to just build one of these and be done with it..
That's just a question of firmware, so you might be able to save yourself some time by adapting this design. Alternatively you could leave it as-is and adapt the GS/OS driver from the original CFFA card. This would have the benefit of not presenting the large HFS area as a SmartPort unit at all, giving a cleaner experience under ProDOS 8.
|
|
|