It's been a long time to get to a BIOS release that works well and has good overall performance, but after months of light coding, I've managed a decent BIOS/Monitor setup that has been reliable with the SanDisk Compact Flash Cards. I just finished some initial benchmark tests for data transfer rates (read only so far) and they are quite promising for a high performance storage add-on for a 65C02 based system.

Examining the BIOS sections, which include the interrupt handler and the call for reading a LBA, the maximum calculated data transfer rate with an 8MHz CPU clock is 332.80 KB/Second (where KB is 1024 bytes). This is the best case scenario for running through the BIOS to request an LBA and have it read from the CF Card into memory. This assumes the CF Card is ready on all accesses and the code path is the shortest possible, along with no other interrupts pending (like the UART which has a 10ms jiffyclock).

Using a SanDisk 512MB CF Card, I ran a small test that loads 32,768 sequential blocks into memory. This is 16MB of data, albeit each block gets moved to the same 512-byte buffer. Needless to say, there is the 10ms jiffy clock running which updates the TOD variables and also the Benchmark Timer, which runs via the jiffy clock as well, so there is some additional overhead, plus whatever responses from the CF Card require an extra loop for sensing. I also tested running the CPU at 4MHz, 6MHz and 8MHz.

Here's the timings and calculated transfer rates:

Running CPU at 8MHz:
16MB (32768 LBAs) read from SanDisk 512MB CF Card takes 54.49 seconds
Calculated data transfer rate = 300.679 KB/Second.

Running CPU at 6MHz:
16MB (32768 LBAs) read from SanDisk 512MB CF Card takes 70.96 seconds
Calculated data transfer rate = 230.890 KB/Second.

Running CPU at 4MHz:
16MB (32768 LBAs) read from SanDisk 512MB CF Card takes 103.92 seconds
Calculated data transfer rate = 157.659 KB/Second.

Overall, I'm pretty satisfied with these numbers... I do have some smaller CF Cards which I'll test as well, but initial testing has shown some of the older smaller capacity cards are slower in transfer rate. Once I finish the next PCB layout with some hardware changes, I'll get new PCBs made and build a few adapters to pair up with the standard 6MHz C02 Pocket SBC boards for some long term testing.

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

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

Thanks BDD,

I agree that I need to take another walk through the BIOS code to see where I can reduce clock cycles, as it certainly helps. I'd also note that ALL reads via the BIOS as of now are single LBA reads, i.e., no multiple block reads are supported. While I've been looking to support multiple block reads, the identity block on every CF Card I've examined shows the maximum block per transfer command is 1, so that's how the BIOS is set to run for now. I'll likely try and see if I can get the CF Card to perform a multi-block transfer, but it doesn't take much to fill up memory within a 64KB address space. The BIOS call to set the transfer address can be anywhere in memory (not constrained to a page boundary), but one should check to ensure you don't clobber anything else, as the BIOS routines are currently not checking for available RAM range.

I do have a few common routines that are called by the Read, Write and Verify LBA BIOS calls, to setup the transfer address and LBA parameters, but the JSR/RTS sequence for these is 13 clock cycles. I could add that code inline, but it would take up more EEPROM space, where I'm trying to ensure that all BIOS plus I/O (and I/O config data) is contained in the upper 2KB. I'm also trying to keep the Monitor within a 6KB space, and there's still some additional function to add there.

I've got some additional CF Cards to test still... 16MB, 32MB, 64MB, 96MB, 128MB and an 8GB... so I hope to get to those tested shortly and post the results here.

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

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

I've been working on an updated BIOS version for a bit.... just not a lot of free time with other projects. However, I fixed a few things, improved a few things and did a fair amount of testing with multiple SanDisk CF cards. The results have gotten better overall. The latest transfer rates for read and write were done using a 16MB sequential group of LBAs. I've run the tests multiple times on each card with an 8MHz CPU clock. I'm still not done with my utility program for this, but it's getting closer to a first version. Using the Identity command, details are provided for Model, Serial number, etc. I also put the date printed on the rear label Next to the card name. The older cards are certainly slower, but I've also found cards which are the same model and firmware to have different transfer rates. This leads me to believe that some of them have some assigned alternate blocks. I can't really confirm if all are truly new old stock, as they were acquired over time from various sources.

In any case, here's the results:

C02BIOS Version 3.03

Compact Flash Benchmarking:

******************************************************************************

SanDisk 32MB: 1999

Model Number: SanDiskSDCFB-32
Serial Number: 36302890712
Firmware Revision: vde1.10
LBA Mode Supported: Y
Total LBA Count: 62720

Read Performance: 76.85 seconds for 16MB = 213.19 KB/Sec.
Write Performance: 207.95 seconds for 16MB = 78.78 KB/Sec.

******************************************************************************

SanDisk 64MB: 2003

Model Number: SanDiskSDCFB-64
Serial Number: 012219I3005L3218
Firmware Revision: HDC2.13
LBA Mode Supported: Y
Total LBA Count: 125440

Read Performance: 53.53 seconds for 16MB = 306.07 KB/Sec.
Write Performance: 58.85 seconds for 16MB = 278.40 KB/Sec.

******************************************************************************

SanDisk 96MB: 1999

Model Number: SunDiskSDCFB-96
Serial Number: MT311440704
Firmware Revision: vcb1.34
LBA Mode Supported: Y
Total LBA Count: 187904

Read Performance: 59.65 seconds for 16MB = 274.66 KB/Sec.
Write Performance: 88.06 seconds for 16MB = 186.05 KB/Sec.

******************************************************************************

SanDisk 128MB: 2003

Model Number: SanDiskSDCFH-128
Serial Number: 012018K2103N5357
Firmware Revision: FhDA0145
LBA Mode Supported: Y
Total LBA Count: 250880

Read Performance: 51.06 seconds for 16MB = 320.87 KB/Sec.
Write Performance: 59.80 seconds for 16MB = 273.97 KB/Sec.

******************************************************************************

SanDisk 128MB: 2003

Model Number: SanDiskSDCFH-128
Serial Number: 012123A0604N4919
Firmware Revision: FhDA0145
LBA Mode Supported: Y
Total LBA Count: 250880

Read Performance: 50.97 seconds for 16MB = 321.44 KB/Sec.
Write Performance: 59.10 seconds for 16MB = 277.22 KB/Sec.

******************************************************************************

SanDisk 512MB: 2004

Model Number: SanDiskSDCFJ-512
Serial Number: 019312D2908E3410
Firmware Revision: HDX4.03
LBA Mode Supported: Y
Total LBA Count: 1000944

Read Performance: 53.24 seconds for 16MB = 307.73 KB/Sec.
Write Performance: 80.12 seconds for 16MB = 204.49 KB/Sec.

******************************************************************************

SanDisk 512MB: 2004

Model Number: SanDiskSDCFJ-512
Serial Number: 012213F1807O2507
Firmware Revision: HDX4.03
LBA Mode Supported: Y
Total LBA Count: 1000944

Read Performance: 50.25 seconds for 16MB = 326.04 KB/Sec.
Write Performance: 68.62 seconds for 16MB = 238.76 KB/Sec.

******************************************************************************

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

Because of the internal wear leveling algorithm, CF access time may vary after each write. Have you measured the read performance first, followed by a write performance test, then measured the read performance again? I believe the modern CF (large capacity) have elaborate wear leveling algorithm, but the older, smaller CF may have simple, more deterministic algorithm.
Bill

Yes, I did some light reading on the wear algorithms and also that defective blocks can be reassigned to spares. So I'm fine with the variance between CF Cards which are mostly identical for Model, Size, Firmware, etc. In general, running the tests time and time again, the results are very consistent. I'm using the Benchmark timer I've implemented in the BIOS and Monitor code, which has a resolution of 10ms... so best case, you're really +/- 10ms on any measurement. It is a bit odd, that the pair of 512MB Cards have consistent performance, but are quite a bit different from one another.... while the 128MB Cards are also consistent, but closer to each other in overall performance. I would also note that the 128MB Cards have a better "balanced" performance, as their respective read and write speeds are much closer than the other CF Cards I've been using.

The good news is that I managed to streamline the BIOS routines a bit and get the transfer rates up to 326KB/Sec. on the one 512MB CF Card. Still.... I've found that other non-SanDisk cards are (still) problematic. I've just submitted an updated PCB and should have those in next week. I added IRQ jumpers for the CF Card and the RTC chip. I also added additional power supply isolation and decoupling for the CF Card, so I'm hoping things are more stable, as I did find certain power supplies (all rated at 3amps) wouldn't work correctly, i.e., weird errors with Xmodem-CRC downloads and odd errors and lockups when accessing the CF Card. Using a 60MHz Tek scope, I couldn't find anything odd with the supply voltage across the supplies, but one in particular just works better. It's not voltage level related, and the noise output between the various supplies is really insignificant.

So, once the new PCBs come in (all 4-layer boards used), I'll get the first one built up and do some additional testing. If the new board works out, I'll build up all 3 boards to mate up to the main SBCs for some longer term testing. I'll also add the new adapter board and BIOS/Monitor code to my Github account. I still need to finish up the RTC/CF-Card utility program, which just gets loaded into RAM and run from the Monitor.

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

The new PCBs came in the other day... they look very nice. I decided to the build the first one up... and it fired right up... well, not literally, but it's working fine. I'm still working to finish up the loadable utility program for the adapter, but I have a BIOS and Monitor version that have been working very well, so that code along with the updated hardware design and description will get added to my Github account shortly.

Here's a pic of the new adapter and the Pocket SBC it cables to... using a short (around 1") 30-pin cable.




and the BIOS/Monitor code

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

floobydust: that looks really good!

Why did you decide on CF as opposed to say SD (basically an SPI interface vs. all those pins)? Not at al a criticism of any sort - genuine curiosity.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Thanks Enso,

Deciding for IDE/CF-Card... overall, it was an easier hardware implementation to interface to my C02 Pocket SBC, that's one reason. Software to make it go is another... per below.

I looked at the SD interface that Richard Leary is using with his DOS/65 implementations for the WDC W65C02SXB and Daryl Rictor's SBC2... where it attaches to a 65C22 VIA port. That would be four chips added to an adapter and somewhat more complicated. For the software, it's bit-banging and timings. If you change the CPU clock, you also need to change the VIA timer values or software timing loops, depending on which one you're using. I have Richard's source code for all of this, but the BIOS I wrote to support the CF Card in True IDE mode is smaller and is not dependent on any CPU clocking, provided of course you don't exceed the timings specifications for the interface, which is mostly limited to 8MHz (no wait states).

For the IDE interface, it's well documented, been around quite some time and IDE drives, CF Cards and Microdrives are readily available and quite inexpensive these days. I can use the same BIOS for all of them without any change. I also have a large collection of 2.5-inch IDE drives and a decent collection of CF Cards plus a 340MB IBM Microdrive.

The single PLD chip really simplifies the hardware design, but it could be simplified more if only implementing an 8-bit interface, but I just wanted the 16-bit data port... which does add a bit to the BIOS code, but overall, the BIOS is still quite small... less than 1.75KB. The BIOS supports the SCC2691 UART for interrupt-driven receive and transmit with 128-byte FIFOs, the Counter/Timer for a jiffy clock, a Maxim DS1511Y RTC for Date/Time plus the CF Card in True IDE mode. A fair amount of I/O support in a small ROM footprint. It also has a JMP table at $FF00 for all available functions, which simplifies using it from other programs, like the companion C02Monitor, EhBasic and DOS/65.

The overall performance vs CPU overheard is also very good as the data transfer timings above show. I've just completed some updates to the BIOS, now at Ver 3.04... which I'll post shortly. It fixes a couple minor things and some general source cleanup.

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

What parts are you using? I can just barely see the logos on the 3 smaller chips, but nothing else.

_________________
-------------------------------
Have an awesome day!

The full details, schematic, PCB layout, etc. are all on my GitHub repository.

In short, there are two 74HC573 octal latches. These form the 8-bit data I/O latch for the upper 8-bits of the 16-bit data path to/from the Compact Flash card. The third chip is an Atmel ATF16V8 PLD. This is the single glue logic that decodes and logically provides the drive signals for the pair of octal latches and the chip selects for the CF Card and the RTC.

Note that there are also dedicated read and write signals which are provided from the host board, which is the C02 Pocket SBC. I would suggest you take a more detailed look at both of the projects on my GitHub page... all of the details for everything are there... full schematics, PCB layouts, etc. and all of the software to make everything go, including the code for the PLD devices.

Any questions, just ask of course... also, perhaps share your schematic. That would make it easier for me to give you some guidance on how to add this adapter to your system.

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

I will share a schematic once I have one that is up to date, which may be a while considering I'm re-working a lot of stuff to account for replacing the 65C51 with an SC28L92.

_________________
-------------------------------
Have an awesome day!

Well, replacing a 65(C)51 with a SC28L92 should be fairly trivial from a hardware side. I replaced a 6551 with a SCC2691 (earlier NXP/Philips UART) which has the same basic hardware differences. Software is more involved, but you can easily start with my BIOS that supports the SCC2691... some minimal changes will run a single channel of the 28L92.

I suggest you configure the 28L92 for Intel mode, not Motorola mode. You will need to provide phase 2 clock qualified /Read and /Write signals, which are the same as /OE and /WR for static RAM and a positive going Reset signal. The Reset can be easily done using a TI TL7705 (or inverting your existing /Reset signal). Details on this can be found on my C02 Pocket SBC, which uses it.

Good luck as you proceed on your project... there's lots of expert help out here on the forum!

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

I'm following the "Interfacing the SC28L92" guide posted by BDD, and using it alongside a MAX248 to make a dual RS-232 interface. But I'll take that luck if you don't mind

_________________
-------------------------------
Have an awesome day!