6502.org

I've opted to start a new thread for this, vs my older thread about moving to 3.3V circuitry.

I used an extra Version 1.00 PCB I had and built up a 3.3V C02 Pocket SBC by simply changing out parts with 3.3V counterparts and resistor changes from 3.3K to 1.5K. By building up an adapter to replace the SCC2691 with a SC28L92 (which will run at 3.3V or 5V) I had a working system. I rewrote parts of my existing 3.04 BIOS to support the SC28L92 and a few minor changes the Monitor code as well. Part one done!

With a bit of cobbling on an existing RTC/CF-Card adapter, I swapped out the 5V parts for 3.3V parts and was able to get that working as well. With the BIOS changes required to support the DUART (both channels), I had to move some Page Zero locations around and as such, made a couple minor changes to the ROM version of DOS/65. Finally, I cobbled a ribbon cable to the bottom of the PCB and hooked up a Hitachi Microdrive with the 35-pin PATA interface. I ended up re-writing part of the BIOS to support that drive and a couple extra routines to enable or disable the on-board Write cache. I also modified the LBA Read/Write routines to support multiple block transfers. I further modified the DUART routines to take advantage of the 16-byte FIFO for transmitting data. I'll take another look at the receive FIFOs later, once I have the second port connected to something.

So, here's a pair of schematics for the two boards (the second showing the CF-Card connector):
Note that I will NOT be making a new set of PCBs for the above schematics. Again, this is the working prototype. The end goal is a single PCB with mostly SMT components and a single ATF1504 CPLD to replace the ATF22LV10C and the ATF16LV8C PLDS. This will take some time, as the next phase it to create a daughter-board to plug into the C02 Pocket PCB and have a short ribbon cable that goes to the ATF16V8 socket on the RTC/CF-Card PCB. This will allow me to sort out the single CPLD configuration.

And, here's the current bits of code for the BIOS, Monitor, Constants, DOS/65 and SIM module that makes it all go.
I've had this code running for quite some time (despite some newer dates shown in the source files). Hopefully some others will find this post useful if planning to move to the 3.3V arena. So far, this has been a fun project. I'm looking forward to getting the single CPLD working and eventually a single PCB to built everything on. Also, the RAM will be 12KB as will the Flash ROM and hopefully a flexible memory map on the fly.

I'm continuing working on the prototype. Since this old post, I've made changes to both the main CPU board by replacing the 32KB SRAM with a 128KB SRAM and the RTC/CF-Card adapter, replacing the CF Card with a Microdrive.

A simple change was made to the ATF22LV10 PLD to alter the memory map, now with 56KB of RAM and 8KB of EEPROM. No changes were required for the Microdrive, but the BIOS has been changed to support some of the features that the Microdrive supports, like multiple block transfers and the ability to enable/disable write caching. Note that the Microdrive BIOS is basically IDE, so one should be able to use any standard IDE interfaced drive to the adapter with nothing more than a connector change.

Attached are the updated schematic images... albeit there are no PCBs being made for these, as it's only a prototype for now.

The updated BIOS and Monitor (4.02) are also attached. The Monitor has the ability to boot from the Microdrive, but I'm working on the code that will be the partition block and boot block... works in progress.
The attached zip file has many goodies... source code for the BIOS, Monitor, MD-RTC Utility, Flash utilities to update the Monitor and BIOS insitu, RAM Test and the initial Partition Block.
Should anyone care... have fun!

The design was the result of pouring over the Seagate ATA interface reference manual for too many hours!

In short, sending commands and getting status from ATA devices are all 8-bit. The only 16-bit transfers are for data, either reading or writing all 16-bits at once. There is a feature you can set for 8-bit data transfers, but what fun is that? The device default is 16-bit data transfers.

The '573 latches are wired inversely to one another. In the schematic, the lower latch, U2, has it's inputs wired to the upper 8-bits of the Microdrive. The latched output of U2, is wired to the CPU data bus. This is reversed with the upper latch, U3, which has it's inputs wired to the CPU data bus and it's latched outputs wired to the upper 8-bits of the Microdrive.

The timing is such that, when a read operation is performed, U2, latches the upper 8-bits of data. So at the same time the CPU reads the lower 8-bits, the upper 8-bits get latched. The CPU then reads the latch to get the upper 8-bits. The write operation is done opposite. The CPU has to write the upper 8-bits of data to latch U3 first, then writes the lower 8-bits of data to the Microdrive. When the write operation to the drive is performed, U3 is also selected to present the latched data on the upper 8-bits of the drive.

All of the decoding and timing is done via the ATF16LV8 PLD. It does two functions: First, it takes a single 32-byte wide I/O select and decodes that into the chip select for the RTC, the two register select lines for the Microdrive and decodes two addresses for the latches. Second, it generates timing signals to control the 4 lines of the two latches. The timing to drive the latches is coupled to the Microdrive Read and Write operations, meaning they (the latches) are only driven in one direction when the Microdrive Data Register is accessed. One is driven to latch during a read operation and the other is driven to present it's latched during a write operation. The latches can be read for one and written to the other separately at their own I/O address.

Below is the CUPL code for the PLD:
There are 5 address lines that are routed to the PLD as inputs, along the I/O select to Pin9, the decoded Read and Write lines from the C02 Pocket and the CLK line (which isn't used. as the Read and Write lines are clock aligned)... hardware safety feature
- The RTC needs 19 addresses which are not contiguous... the first 17 are, the other two are spaced up by two, so the chips select decodes 19 addresses for it.
- The Microdrive has two chip selects, one for the main set of registers, which is a total of 8. The second select only has 2 registers.
- The latches are assigned two I/O addresses, one or read and one for write.

The hex addresses above show the logic for the latches.The Microdrive Data register is at an offset of hex 18. The latches are at an offset or hex 14 and 15. The latches are selected only when the Microdrive Data Register is selected, one to latch data in during a read and the other to present latched data to the Microdrive during a write. The latches can be accessed separately at address offsets hex 14 and 15 to either read data from one, or write data to the other. It's actually pretty simple for timing.

The BIOS simply has an extra read cycle to get the upper 8-bit of data. Writing requires that the upper-bits are written to the latch first, then the write operation to drive.

The reason behind implementing the 16-bit port is for performance. This becomes more advantageous when you have a CPU clock that is running faster than the ATA design spec can handle (per documentation, is 8MHz). You can add wait states when accessing the drive on reads or writes, then move the data around at higher CPU clock rates. With an 8MHz CPU clock (and no wait states in this design), I can obtain data transfer rates around 360KB/second on a read and around 320KB/second on a write.

This same interface can drive a compact Flash as well, which I did initially. I switched to the Microdrive for some specific reasons:
- physically smaller than a CF Card... with a larger space advantage when you include the socket for the CF Card.
- Being rotating media, you don't have wear-leveling and varying data rates on write operations.
- Being a true IDE device, multiple block reads and writes are supported.
- Testing has shown overall performance to be better than Compact Flash and more consistent (onboard caching for read and write)... but yes, there is still rotational latency.

Hope this explains it...