6502.org

I've been working on this in some spare time and finally have an initial version which is working.
This is in support of the RTC/CF-Card adapter I posted earlier:
viewtopic.php?f=4&t=6223

Some of it's been a bit tricky to get working, with a lot of reading through the SanDisk documentation and also Seagate's documentation for IDE. I've not yet done exhaustive testing, nor have the BIOS additions been optimized for speed or size yet. Fortunately, everything is working and the following routines are available against the CF-Card IDE Controller and DS1511 RTC chip:
This BIOS runs against my C02 Pocket SBC and is an update based on the 2.05 version with the RTC and IDE support added. There are some minimal changes to some parts of the existing BIOS, mainly the ISR that maintains the software RTC function. I've done a fair amount of commenting in the source, but I would recommend anyone looking thru this code to also consult the documentation from Maxim for the DS1511 and the Compact Flash documentation from SanDisk.

After more testing is done, I'll likely do some updates and eventually add this to my Github page, albeit I'll be working on an updated adapter schematic and PCB layout. I also need to look more closely at the IOCS16 line and using it for 16-bit data transfers using the SO input on the CPU. So far, there's some conflicting information between what Seagate state in their IDE documentation and what SanDisk state in theirs.... so time to get out the scope and data analyzer for more testing. Data transfers are using the DRQ line in the Status register and the ISR is added via an insert vector. In the mean time, this BIOS should be suitable for testing against an OS/Filesystem.

Of the two, I'd consider Seagate to be more authoritative. They were manufacturing IDE disks well before SanDisk opened their doors.

Have you worked out the details on partitioning yet.

I suggest making one of the partitions a smallish drive which can be imaged from a virtual disk file to aid in getting files in and out.

On the other hand, when dealing with CF instead of rotating media, SanDisk may be closer to the truth...

The confusion on this one shows the Seagate documentation as being more confusing. The signal in question is the IOCS16- line. This line is defined by both Seagate and Sandisk as being asserted when the IDE controller is expecting a 16-bit data transfer (read or write). Also, both docs show it as an active signal at a negative level. The confusion arises with the Seagate docs as they show a timing diagram with the IOCS16- line at a high level when asserted.... then again on a different page they state that the lines in the diagram are shown high when asserted (meaning a high or low level doesn't matter).

In any case, I found that using this line for the handshake had no affect, i.e., it appeared in software to never change state. So I'll break out the scope for an initial scan on this line. There's also the possibility that WDC have effectively disabled the SO line on newer chips. Their documentation still describes it's operation, but also states it was rarely used in the past and is not recommended for future use. So who knows... maybe I'll find another WDC "feature" like I did with the W65C51 ACIA

As for any partitioning (BillG), nothing has been done in that area as of yet. The first round was to validate that the hardware design was working, which includes the PLD programming for the single glue chip. The design is using a single 32-byte wide I/O select from the C02 Pocket SBC and the PLD breaks this out to handle:
- 18 registers of the RTC (1- select)
- 10 registers for the IDE controller (2- selects)
- Upper byte latch (4- selects)
Fortunately, it's all working, so I'm happy about that.

The BIOS design is to keep it simple. LBA mode is the only supported addressing mode against the CF Card and the commands are also kept simple and few. Obviously it's PIO mode only (no DMA hardware function). I've also limited the maximum LBA count to 8GB, which is 24-bits of LBA addressing at 512-bytes per block. I'll likely pick up some additional CF Cards of different capacities soon, as my current stash consists of 16MB, 32MB, 64MB and 96MB. All are working fine with the adapter and BIOS.

On a previous post, I noted some early data transfer tests using my initial routines which all disabled interrupts. It turns out those weren't correct, as testing for the CF Card controller being Ready requires sensing two bits in the status register. Now that everything is working correctly, I've done a lot of testing for reading and writing sequential blocks to and from memory. The results are very consistent. I'm reading and writing at the same speeds. I can read 56 blocks into 28KB of memory in 0.56 seconds, or write 56 blocks from memory into 0.56 seconds. This works out to 50KB/Second. Overall I think this is quite respectable for the simple hardware design. I know BillG has been doing some of the Flex testing with SD cards (bit-banging hardware?), so I'd be interested to know what transfer rates you're seeing with this setup.

Next is to start working on a BIOS translation layer so it the overall hardware (Console/Timer, RTC and CF-Card IDE controller) can be used by Flex and DOS/65, albeit these will be different layers. Just not sure how long that's going to take.... but I've got the Flex adaptation guide to work with.

I'll go out on a limb and say that that is highly unlikely.

While WDC has made subtle device changes over the years, they have never disabled or reassigned the function of any pin without documenting it (the most notable example being VPB, which is VSS on the NMOS part; also MLB, which was a no-connect on the NMOS part). It's true that use of SOB is discouraged in new designs. However, there are existing designs that depend on SOB's function, so WDC would be breaking backward software compatibility if they did disable or reassign SOB. It is extremely unlikely WDC would do that and not announce it via an ECN.

Hmm, that surprises me. Is that official? Any idea why?

Easy answer: systems that use /SO are harder to adapt to using the 65816. There can also be bad interactions with arithmetic routines, unless the /SO input is locked out when not in the latency-sensitive loop.

Equivalent performance is obtained by using the /IRQ input, SEI and WAI - and that is 65816 compatible.

Are those your thoughts, or an official line? I've no problem with individuals advising against the use of SO, of course, if they have reasons. But BDD rather implied something more universal, or official, and that surprises me. AFAIK SO has only very rarely been used anyway, so it seems to me it's hardly worth having a policy about it.

Straight from the datasheet:

Yes, the Datasheet is as posted above. I also used the /SO line back in the 80's for a floppy controller I built based on the WD2797. It was built on a plug-in board for the Vic-20.... and I had to run the /SO line to a unused pin on the expansion connector... and it did work.

Fast forward to now.... I pulled out my logic analyzer and found the IOCS16 line (which is attached to the /SO pin) is toggling for each word transfer. I also noticed that each block transfer is very quick, but are spaced out every 10 milliseconds! This is wrong.... as the jiffy clock is set for 10ms... conclusion: the CF-Card is NOT generating any interrupts! I confirmed it... added more lines to the logic analyzer and sure enough, the ISR was being serviced due to the jiffy timer generating the interrupt. This certainly explains the data transfer being identical for read and write, not to mention exactly at 50KB/Second: 512 bytes per block transferred every 10ms

Turns out the SanDisk documentation is wrong! It specifically states that the interrupt is active on a power up or reset, turns out it isn't. I just changed the BIOS to enable the interrupt and now the data transfer rate is over 240KB/Second! So... I'm already making some updates to the BIOS code.... will also look at trying to use the /SO line being driven by the IOCS16 signal. I'm also thinking the data transfer rate is being affected by the CPU clock speed, as the code to get data to/fromfrom the CF Card has it's own timing per loop, which reads or writes a word (16-bits). I'll try changing the CPU clock to see if the data rate changes as well. In any case, things just got better... still more work to do on the code and eventually an updated adapter.

EDIT: Oops... I had a couple init routines where I turned the interrupt off to get the CF Card configured... and I forgot to turn it back on Note to self: keep scanning your own code first

Actually, using the SEI - WAI method produces a one clock cycle latency when any hardware interrupt occurs. Using SOB and a loop on a BVC instruction, the best that can be attained is two clock cycle latency, and of course, that is only if using the 65C02. If the loop crosses a page boundary then an extra cycle will be consumed.

In a loop accessing I/O hardware, the SEI - WAI method could produce a substantial performance improvement, as the loop may be iterated many hundreds of times during the I/O transaction.

Well well well, thanks for the snippet Chromatix. I stand corrected.

I don't take this quotation as an indication they plan to disable the SOB input on newer chips. I share BDD's feeling that that's highly unlikely.

IMO the real meaning of the quote is, "We're tired of explaining this obscure feature, and urge anyone who's worried about understanding it not to bother."

-- Jeff

Exactly! If you are replacing an NMOS 6502 with the WDC 65C02, don't worry about SOB. If the circuit needs it, it's there. If not, well, it's still there.

If it's a new design and you feel you have a use for SOB, it's there. If not, well, it's still there, but be sure to pull it up to Vcc to avoid any "situations."