6502.org

Posted: **Mon Jul 27, 2020 11:33 pm**

I finally finished the design for a compact flash and RTC adapter for my C02 Pocket SBC. PCBs came in today, so I put one together. As of now I have zero code written for it, but with all of the parts installed and powered up, the C02 Pocket SBC still boots up, so at least there's nothing shorted as far as I can tell. I also have the PLD programmed and installed, so that seems to have it's output lines correct as well.

I plan on spending a bit of time later this week starting to write some routines to access the CF-Card first, then will look at doing the same for the RTC. The latter has 256 bytes of non-volatile RAM which is accessible via two I/O ports (one for address offset and one for data). I plan to use this NVRAM for holding configuration data, which will free up some EEPROM space.

Here's a few pics attached.... hoping this will be a success. Once a BIOS is completed, I'll be looking to write a translation layer to use FLEX (BillG working on this).

Posted: **Wed Sep 02, 2020 1:23 am**

Sorry for the late response. If you need some reference code for talking to the RTC please let me know.

BTW, there is a subtopic within my POC V1 topic about relying on the 1511's watchdog for accurate timekeeping. It's best to consider the watchdog as "approximate" in that regard. The TOD clock, on the other hand, exhibits good long-term stability and can be trusted.

Posted: **Wed Sep 02, 2020 2:33 am**

Hi BDD,

Thanks for replying on this... much appreciated. I've not had a chance to start writing any code just yet, but have spent some time defining the BIOS functions for both the IDE interface and the RTC access.

I also recall your POC V1 discussion where you tried to use the 1511 for the jiffy clock and the issues. Like you, I'm also using the timer/counter on the NXP UART (SCC2691 in my Pocket SBC) for a (10ms) jiffy clock.

For the RTC BIOS functions, I went back to the BIOS calls that (IBM) implemented for the initial RTC hardware which was implemented with the PC-AT (1984...). These calls are via INT 1Ah:

0- Read RTC
1- Set RTC
2- Read RTC Time (HH:MM:SS)
3- Set RTC Time (HH:MM:SS)
4- Read RTC Date (Mon/Day/Year)
5- Set RTC Date (Mon/Day/Year)
6- Set RTC Alarm
7- Reset RTC Alarm

Granted, I need to go back to my old BIOS listings to see the differences between calls 0 and 1 vs 2 and 3. As the 1511 has 256 bytes of NVRAM, I'll likely use calls 0 and 1 to read and write the 256 bytes of NVRAM. As the 1511 uses BCD values, I'll convert them to binary and load my existing RTC code, albeit I'll need to implement month/day/year for the next BIOS release. Currently I just calculate seconds, minutes, hours and days... with days being a 16-bit count.

I''m also leaning towards a small set of calls for the CF-Card, which is configured for true IDE mode. As there's a number of typical BIOS INT 13h calls that don't apply to the CF-Card and also some that are handled, but nothing done by the CF-Card (for compatibility), I'm leaning towards the following:

0- Reset/Initialize CF Card (Test ready (diags), Set PIO mode, Zero pointers)
1- Get Status/Error code from last operation
2- Read One or more blocks from CF Card
3- Write One or more blocks to CF Card
4- Verify One or more blocks to CF Card
5- Set Transfer Address for Read/Write/Verify
6- Set starting LBA for Read/Write/Verify (24-bit address = 8GB)
7- Read CF Card Parameters (total LBA Count, PIO mode, etc.)

The idea is to keep the BIOS functions short and simple and use LBA only, no CHS access. When trying to use it with an OS (like Bill's upcoming Flex for the 6502 or Richard Leary's DOS/65) which use CHS access, there will be a translation layer to provide what the OS needs to function and provide sector/block level access via the actual BIOS. It would also allow the CF-Card to be divided into multiple virtual drives to get around the filesystem limitations for older OSes.

Still defining/redefining this in my little brain but should start writing code soon. In the meantime, I'm doing house projects, car projects, visiting/helping Mom (since Dad passed away in March) and starting to learn 68000 assembly for a 68K based Pocket SBC project

Posted: **Wed Sep 02, 2020 5:16 am**

floobydust wrote:

For the RTC BIOS functions, I went back to the BIOS calls that (IBM) implemented for the initial RTC hardware which was implemented with the PC-AT (1984...). These calls are via INT 1Ah:

0- Read RTC
1- Set RTC
2- Read RTC Time (HH:MM:SS)
3- Set RTC Time (HH:MM:SS)
4- Read RTC Date (Mon/Day/Year)
5- Set RTC Date (Mon/Day/Year)
6- Set RTC Alarm
7- Reset RTC Alarm

I no longer recall what functions 0 and 1 did in the AT BIOS, but using them to instead access the 1511's NVRAM sounds reasonable.

I have not exploited the 1511's alarm feature.

Quote:

As the 1511 uses BCD values, I'll convert them to binary and load my existing RTC code, albeit I'll need to implement month/day/year for the next BIOS release. Currently I just calculate seconds, minutes, hours and days... with days being a 16-bit count.

I developed a UNIX-style date-and-time time_t variable for use in POC V1.1 onward. The variable takes two forms: core and storage. In core, time_t occupies 48 bits, of which bits 0-39 are the number of seconds that have elapsed since the epoch and bits 40-47 are normally unused but are a symbolic overflow area. The epoch used with this arrangement is midnight of Sunday October 1, 1752, and is based on UTC. I chose that epoch because the British Empire switched from the Julian calendar to the Gregorian one in September 1752. The changeover involved excising 12 days from September, which would have been a hassle to accommodate.

In the storage version of time_t, bits 0-39 are the same as in the core version, but bits 40-47 are used to store the value of the 8-bit timekeeping jiffy counter, which cycles between $00 and $63, decrementing with each jiffy IRQ (time_t and the uptime counter increment when the jiffy count reaches $00). The instantaneous value of that counter is captured by the BIOS call that returns time_t to a calling program. The result is the stored time can be resolved to the nearest 10 milliseconds.

Library functions external to the BIOS are used to translate between time_t and broken-down (human-readable) time. The library functions use 64-bit, four-function arithmetic to do their work, which is readily implemented in assembly language. Due to my method of implementation, the maximum date that can be translated without error is Friday December 31 23:59:59 9999 UTC.

Along with the time_t value, I maintain a 32-bit uptime counter, which is always initialized to $00000000 at reset. Like time_t, uptime is incremented at one second intervals and may be used for a variety of purposes, such as programmed time delay (sleep) functions or measuring a program's run time (i.e., similar to the time function in UNIX/Linux). The interrupt code that handles time_t and uptime is surprisingly succinct, even on a 65C02.

Quote:

I''m also leaning towards a small set of calls for the CF-Card...The idea is to keep the BIOS functions short and simple and use LBA only, no CHS access.

Use of LBA is wise, as doing so greatly simplifies filesystem-access computations.

Quote:

When trying to use it with an OS (like Bill's upcoming Flex for the 6502 or Richard Leary's DOS/65) which use CHS access, there will be a translation layer to provide what the OS needs to function and provide sector/block level access via the actual BIOS. It would also allow the CF-Card to be divided into multiple virtual drives to get around the filesystem limitations for older OSes.

Translation between LBA and CHS probably should occur in the OS, not the BIOS. It's generally best to avoid adding OS-specific features to a BIOS, as that tends to reduce the generality of the machine.

Posted: **Wed Sep 02, 2020 8:32 pm**

Well, I looked up the old AT BIOS listing... functions 0 and 1 were against the timer, not the CMOS RTC (as they refer to it in BIOS), so using those functions to read and write the NVRAM of the 1511 will work out fine.

As for the other calls, specifically for the RTC, I'm thinking to keep it simple to use less (EEPROM) space. I'm trying to keep the BIOS and I/O space within 2KB. The I/O space is 160 bytes (5- I/O selects at 32 bytes each). I also have a Jump table of 32 entries (which will be full with the RTC and IDE calls added). I currently have 1080 bytes free, so I'm hoping to get the IDE and RTC functions in that space. The main reason for the RTC is to allow an accurate timestamp when creating or modifying files within an OS. This of course assumes that the OS will have timestamp information in the directory entry, so BIOS calls would mainly be used for that. If I can fit more function in the BIOS space, then that would be a plus.

As for the alarm functions, it's not clear if they would be needed or how I would use them with the current hardware configuration, so perhaps they don't get implemented initially... or ever. i guess it really depends on what other things I think of for future expansion, so time will tell

I agree on the OS doing the translation from CHS to LBA, it makes more sense. In the thread on Flex, posts with BillG, there is a defined interface for such a translation layer for disk and console I/O within Flex. So while it's effectively a translation layer, it's actually part of Flex. The same would apply for DOS/65 as well. Having a new design OS on the 65C02, it "could" use the simple LBA BIOS routines natively, but I don't see me writing such an OS anytime soon.

I'll likely take a look at your POC V1.1 code on the RTC of course... always nice to see an exiting implementation.

Posted: **Thu Sep 03, 2020 3:21 pm**

floobydust wrote:

The main reason for the RTC is to allow an accurate timestamp when creating or modifying files within an OS.

Timekeeping is most efficiently implemented with a purely binary representation of the time and date, such as I described earlier. Among other things, a binary representation lends itself to easy future and past date computations, since the time and date variable (time_t) increments at one second intervals.

Timestamping by reading the RTC will be relatively slow, due to the time required to access hardware and the need to tell the RTC to suspend updates while reading its registers. On a fast system, wait-stating may be required, slowing things down even more.

In practice, modern operating systems only refer to the RTC at boot time to set the local time and date, thereafter maintaining it in software via a jiffy IRQ. This is what I did in my POC units, which keep time in UTC (thus timezone-agnostic). Your BIOS calls to manipulate the time and date variable will need a means to momentarily stop updating to avoid a carry error. There's a simple way to do so with a semaphore that tells the timekeeping part of your interrupt service routine to defer updating for one jiffy.

Quote:

This of course assumes that the OS will have timestamp information in the directory entry, so BIOS calls would mainly be used for that. If I can fit more function in the BIOS space, then that would be a plus.

I'm not familiar with Flex, so I don't know if it provides for timestamping files. As filesystems are usually handled with drivers, you probably could use that approach to cobble up a means to timestamp your files if Flex doesn't support it.

Quote:

As for the alarm functions, it's not clear if they would be needed or how I would use them with the current hardware configuration, so perhaps they don't get implemented initially... or ever. i guess it really depends on what other things I think of for future expansion, so time will tell

I've yet to find a use for the alarm feature in the DS1511. Again, modern operating systems that provide an alarm feature, e.g., Linux, do so in software. Ditto with time delays, which are very easy to do in software.

Quote:

I'll likely take a look at your POC V1.1 code on the RTC of course... always nice to see an exiting(sic) implementation.

There are four functions: read the RTC, set the RTC, read NVRAM and write NVRAM. Reading and writing the RTC is a little hinky because the months register also contains a control bit field. For simplicity and compactness, the two NVRAM functions access all 256 bytes at once, using a buffer pointed to by the .X and .Y registers.

Posted: **Sat Sep 05, 2020 2:35 am**

I agree completely on timekeeping... the RTC is only read on boot-up and then the local time is kept by a jiffy clock timer. I've implemented a jiffy clock using the timer/counter on the SCC2691 UART. The ISR handles jiffys, seconds, minutes, hours and days (0-65535). I'll need to modify it for date, day of week, month and year... which will increase the size. With the 65C02, code size is critical to keep within the initial constraints I've decided on for the allocated BIOS (size).

I'm not really familiar with Flex either... but I've had some exchanges with BillG (who is porting it to the 6502), and read some of the documentation that BillG pointed to... which has been quite informative. There were some posts about adding a timestamp to the filesystem. In any case, timestamping outside of the filesystem would require some modification of the directory management and possibly a change in the OS on what the directory entry looks like... so I'd prefer that to be handled by the OS.

Off hand, I can't really think of any specific use for the alarm either, at least not with my current Pocket SBC. In some cases, it's a solution looking for a problem (to fix)... but it is a capability within the 1511. I guess the jury (of one) is still out on how to use it.. or not.

My basic idea on the 256 bytes of NVRAM is to hold configuration data for boot up. I'm currently keeping config data for soft vectors and hardware config in ROM (96 bytes of page $FE after the 160 bytes of I/O), most of which is copied to RAM and then used for normal operation, being entry/exit vectors for NMI, IRQ, BRK and config parameter data for the UART along with some reserved vectors to use as inserts to those routines. I'm thinking about putting a signature in the NVRAM data and check if it's there on boot up (as it's an adapter card) and use the config data from NVRAM if it's actually there (based on the signature being present). I might implement a checksum to ensure it's correct.... but again, 64KB is a limiting factor here.

Overall, I'm still trying to keep the BIOS and I/O in the top 2KB and the Monitor within 6KB just below the BIOS. Basically... the top 8KB is the Monitor, BIOS and I/O. The remaining 24KB of EEPROM is free for other code. I've managed to modify Enhanced BASIC to fit in less than 10KB and integrated it into my Pocket SBC, but Flex has it's own BASIC, so if/when I can get flex code to implement, I would just prefer to use the Flex BASIC.

I do find your input to be very useful... so do keep pushing on my plans/ideas. I don't claim to have all of the answers... and at the end of day, this is personal hobby stuff, which I openly share. It's fun for me, keeps my mind active and gives me some personal satisfaction on doing something different.

Posted: **Sat Sep 05, 2020 4:04 am**

floobydust wrote:

Off hand, I can't really think of any specific use for the alarm either, at least not with my current Pocket SBC. In some cases, it's a solution looking for a problem (to fix)... but it is a capability within the 1511. I guess the jury (of one) is still out on how to use it.. or not.

I don't think I've ever scheduled any alarms that fire really fast, but one application I did several years ago on the workbench was to test battery life on a new product, taking battery voltages, and, every 15 minutes, printing out the accumulated run time, the current battery voltage, the lowest battery voltage seen over the last 15 minutes (because the load is not consistent), how fast the low-battery LED was flashing (since it is designed to flash faster and faster as the batteries weaken), and whether the product had shut itself down yet because the voltage was too low. Then I was able to use the workbench computer for something else at the same time, with my other program not having to know it wasn't the only one running. I was experimenting with something else and developing code for that, and every fifteen minutes, the printer pounded out another line of battery data.

Posted: **Tue Sep 08, 2020 5:25 am**

I started to write some test routines against the adapter today... pretty simple so far:

For the RTC:
1- I can ready and write the 256 bytes of NVRAM. This was pretty simple, just following the datasheet.
2- I can read the time/date from the RTC. Also pretty simple, following the datasheet.
3- I can set the time/date to the RTC, again... fairly simple following the datasheet.

For the CF-Card (configured in True IDE mode):
1- I wrote a couple routines that test for drive ready and wait for drive busy first which are working.
2- I wrote a routine that resets the drive (it uses the first two routines) which is working.
3- I wrote a routine the runs the internal diagnostics (also uses the first two routines) and it's also working.

For both routines, the drive status finishes up as ready and the error register shows as 01h (no error). The Diagnostic routine does result in a flash of the drive access light when executed. So it's a definite that the CF-Card is responding.

Needless to say, I've got a ways to go on both devices... before I can declare the adapter as working properly. Hoping to get most of this done over the next couple of weeks (in between other projects).

Posted: **Wed Sep 09, 2020 3:07 am**

Some additional progress today:

I added a couple routines for the Compact Flash card. I'm using the SanDisk documentation for writing these routines. My hardware design does route the IRQ line from the CF-Card through a MOSFET to trigger the IRQ line on the 65C02. The MOSFET is required as the IRQ from an IDE controller is active high (65C02 is active low). As I'm not actually servicing this IRQ as part of my ISR (as of yet), I was getting some wonky results, basically an intermittant lockup on the board. So the routines to access the CF-Card now start with a SEI instruction and end with a CLI instruction. This makes everything stable using polled I/O mode. I'll integrate this into the BIOS later and extend the ISR to handle the IDE controller properly.

The new routines are:
1- Drive Identify (command code ECh): This provides a 512-byte block of information which tells a lot about the device. It includes basic parameters like LBA count, CHS details, other specific settings, serial number, Vendor device name, etc.

2- A Block read routine: As the Identify command requires reading a block of data, this routine reads the block from the CF-Card and places it into a buffer (at $0400 - $05FF). This is also a nice test for the hardware design, as I implemented a bidirectional latch for reading/writing the upper 8-bits of the interface, so it uses 16-bit data transfers. This also verifies more of the ATF16V8 PLD programming. Also, one needs to swap the high and low byte for each 16-bit read, so that's done in the block read routine.

Here's the basic IDE routines I've come up with so far... none are optimized and more testing is required:

Code: Select all

;
IDE_RESET       ;A Reclibrate command
;According to Sandisk, the Recalibrate command is essentially a NOP,
; as there are no moving parts and nothing to calibrate. However, there is
; the option of setting LBA mode by setting bit 6 in the mask for DRV-HEAD
; NOTE: for testing, all routines are turning the IRQ off so the BIOS ISR doesn't
; get hung up intermittantly.
;
        SEI                     ;Disable IRQ
        JSR     TST_IDE_RDY     ;Wait for IDE to be ready
;
        LDA     #%11100000      ;Get Select Mask (LBA Mode, Drive 0)
        STA     IDE_DRV_HEAD    ;Select Drive 0, Head 0
        LDA     #$10            ;Get Recalibrate command
        STA     IDE_COMMAND     ;Send command to IDE
;
        JSR     TST_IDE_BUSY    ;Wait for drive Busy
        CLI                     ;Enable IRQ
        RTS                     ;Return to caller
;
IDE_DIAG        ;Run internal Diagnostics on the CF-Card controller
; This is just a basic function within the CF-Card controller...
;
        SEI                     ;Disable IRQ
        JSR     TST_IDE_BUSY    ;Wait for IDE to be ready
;
        LDA     #%00000000      ;Get Mask for Drive 0
        STA     IDE_DRV_HEAD    ;Select Drive 0
        LDA     #$90            ;Get Diagnostic Command
        STA     IDE_COMMAND     ;Send to IDE controller
;
        JSR     TST_IDE_BUSY    ;Wait for drive Busy
;
        LDA     IDE_STATUS      ;Get IDE Status Register
        LDX     IDE_ERROR       ;Get IDE Error Register
        CLI                     ;Enable IRQ
        RTS                     ;Return to caller
;
IDE_IDENTIFY    ;Identify Device
; This requests a 512-byte block of data that shows capabilities, etc.
;
        SEI                     ;Test for IRQ issue - disable
        JSR     TST_IDE_RDY     ;Wait for IDE to be ready
        LDA     #%00000000      ;Select Drive 0
        STA     IDE_DRV_HEAD    ;Select Drive 0
        LDA     #$EC            ;Get Identify Command
        STA     IDE_COMMAND     ;Send Command to IDE
;
        JSR     TST_IDE_BUSY    ;Wait for IDE to accept command
        LDA     #$00            ;Setup buffer address
        STA     SPARE_B0        ;Store low byte
        LDA     #$04            ;Block Buffer Address is $0400
        STA     SPARE_B1        ;Store high byte
;
        JSR     IDE_READ_BLK    ;Read a Block of drive
        JSR     TST_IDE_RDY     ;Wait for drive ready
        LDA     IDE_STATUS      ;Get IDE Status Register
        LDX     IDE_ERROR       ;Get IDE Error Register
        CLI                     ;Enable IRQ again
        RTS                     ;Return to caller
;
IDE_READ_BLK    ;IDE Read a Block of data
; - Data needs to be swapped (high byte - low byte) when read
        PHA                     ;Save registers
        PHX
        PHY
        LDX     #$00
IDE_RD_RBLK
        LDA     IDE_DATA        ;Read low byte (high byte in latch)
        TAY                     ;Xfer low byte to Y Reg
        LDA     IDE_16_READ     ;Read high byte from latch
        STA     (SPARE_B0)      ;Store high byte
        INC     SPARE_B0        ;Increment pointer
        BNE     IDE_RD_BLK1
        INC     SPARE_B1
IDE_RD_BLK1
        TYA                     ;Xfer low byte back
        STA     (SPARE_B0)      ;store low byte
        INC     SPARE_B0        ;Increment pointer
        BNE     IDE_RD_BLK2
        INC     SPARE_B1
IDE_RD_BLK2
        INX                     ;Increment count
        BNE     IDE_RD_RBLK     ;Loop back for 256 words
        PLY                     ;Restore registers
        PLX
        PLA
        RTS                     ;Return to caller
;
; Test for IDE Busy
TST_IDE_BUSY
        PHA                     ;Save A Reg
BUSY_LOOP
        LDA     IDE_STATUS      ;Get IDE Status register
        AND     #$80            ;Mask Drive Ready bit
        BNE     BUSY_LOOP       ;Loop until it's clear
        PLA                     ;Restore A Reg
        RTS                     ;Return to Caller
;
; Test for IDE Ready
TST_IDE_RDY
        PHA                     ;Save A Reg
RDY_LOOP
        LDA     IDE_STATUS      ;Get IDE Status register
        AND     #$40            ;Mask off Ready bit
        BEQ     RDY_LOOP        ;Loop back until set (ready)
        PLA                     ;Restore A Reg
        RTS                     ;Return to caller
;

The block of data from a 16MB Sandisk card looks like this:

Code: Select all

;-D $400
    addr:  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  0123456789ABCDEF
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    $0400  84 8A 01 EA 00 00 00 02 00 00 02 40 00 20 00 00  ...........@. ..
    $0410  7A 80 00 00 20 20 20 20 20 20 20 20 20 30 39 33  z...         093
    $0420  30 31 31 51 30 36 30 36 00 02 00 02 00 04 76 64  011Q0606......vd
    $0430  64 20 31 2E 30 30 53 61 6E 44 69 73 6B 20 53 44  d 1.00SanDisk SD
    $0440  43 46 42 2D 31 36 20 20 20 20 20 20 20 20 20 20  CFB-16          
    $0450  20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 01                ..
    $0460  00 00 02 00 00 00 01 00 00 00 00 01 01 EA 00 02  ................
    $0470  00 20 7A 80 00 00 01 00 7A 80 00 00 00 00 00 00  . z.....z.......
    $0480  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $0490  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $04A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $04B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $04C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $04D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $04E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $04F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    addr:  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  0123456789ABCDEF

;-D $
    addr:  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  0123456789ABCDEF
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    $0500  00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 20  ..............  
    $0510  20 20 20 20 20 20 20 20 20 20 20 30 39 33 30 31             09301
    $0520  31 51 30 36 30 36 00 00 00 00 00 00 00 00 00 00  1Q0606..........
    $0530  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $0540  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $0550  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $0560  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $0570  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $0580  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $0590  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $05A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $05B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $05C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $05D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $05E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    $05F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    addr:  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  0123456789ABCDEF

The "01 EA" bytes at address $0402-$0403 are the number of cylinders in hex (490 decimal). The format is documented in the SanDisk documentation... most of the 512 bytes are reserved and are zeros. LBA count is also shown, as a 32-bit count.

The next routines will be polled I/O as well... read any given block and write any given block... as I'm only planning to use LBA mode, not CHS addressing. Still a long way to go.

Posted: **Wed Sep 09, 2020 3:58 am**

floobydust wrote:

My hardware design does route the IRQ line from the CF-Card through a MOSFET to trigger the IRQ line on the 65C02...As I'm not actually servicing this IRQ as part of my ISR (as of yet), I was getting some wonky results, basically an intermittant lockup on the board.

Why not put a jumper block into the IRQ line from the card so you can eliminate the spurious interrupt until you can write a suitable handler? How do you clear an IRQ generated by the card?

Posted: **Wed Sep 09, 2020 4:19 am**

I know.... hindsight being 20/20 and all...

I'm most likely going to do a version 1.01 of the PCB layout with some additional changes... as I found a slight error in the CF socket I created and the jumper pin holes are too tight. The same for the backup battery mounting holes... I had to file down the pins to get that to fit, jumpers required pressing in with small pliers. I'll also add an IRQ jumper for the CF-Card as well.

As the backup battery is only used for the kickstart and square-wave output in the absence of Vcc, I'll plan to delete that and the jumper for it. I can likely eliminate the additional power jack and switch. I was thinking that a separate power supply might be required if one were to use a Microdrive instead, but with CF-Cards being so inexpensive, why bother. A few less parts and spread things out a bit... can't hurt.

According to the Sandisk documentation... reading the Status register should clear the IRQ. However, the card responds quite fast, so I found executing either the diagnostic or identity routines would lock up, just not all the time...

Posted: **Wed Sep 09, 2020 4:19 pm**

You know that most CF Cards can be put into a 8 bit mode? I also built a CF Card adapter for the Apple II which was ProDOS compatible. If you want I can look if I find the source code.

Posted: **Wed Sep 09, 2020 4:39 pm**

cbscpe wrote:

You know that most CF Cards can be put into a 8 bit mode? I also built a CF Card adapter for the Apple II which was ProDOS compatible. If you want I can look if I find the source code.

Hi Peter,

Yes, I know about 8-bit mode... I thought about it, but opted to add the latches so I can enable 16-bit data transfers. That's the only 16-bit function... data transfer to/from. I'm also looking to use the -IOCS16 line (active low whenever the CF Card is wanting to perform a 16-bit data transfer) with the /SO pin on the CPU. I used this feature on a diskette controller in the 80's with a WD2797.

I've written a few more routines and have LBA read and write routines working. I also remembered there's an option in the control register to disable the IRQ line... which is probably why I didn't put a jumper for that on the PCB

The good news so far is I now have all of the basic functions working in polled I/O mode:

Test for IDE Ready
Test for IDE Busy
Reset IDE controller (options for LBA mode and disable IRQ)
Run Diags on IDE controller
Identify Drive (16-bit transfer)
Read a Block of data (16-bit transfer)
Write a Block of data (16-bit transfer)

As is usual (for me), I'm using CMOS opcodes and addressing modes. I've also now verified that the ATF16V8 PLD is working as programmed for all functions. I'm using a single 32-byte wide I/O select and can access all RTC registers, all IDE registers and I'm using two addresses for the upper byte latches (one for read, one for write).

The next step is to integrate this into the EEPROM based BIOS and extend the ISR to handle the IDE controller.

Thanks for your help in the past.... especially with WinCUPL!

Posted: **Fri Sep 11, 2020 5:33 am**

I decided to do a brief bit of benchmarking for transfer speeds using my existing polled-I/O routines for reading a 512-byte block and writing a 512-byte block. As expected, writing is slower than reading. To measure the transfers, I'm using the Benchmark Timer which I added to the BIOS and Monitor some time ago. This uses the 10ms Jiffy Clock, so it's resolution is within the 10ms window. To get an idea, I simply stacked the reading of a single I/O function multiple times until I found the Benchmark Timer hit the next threshold, which is from 0.01 seconds to 0.02 seconds to 0.03 seconds.

For reading a single block:

4 block reads (512 bytes x 4 = 2048 bytes) takes 0.01 seconds
8 block reads takes 0.02 seconds
12 block reads takes 0.03 seconds.

Doing some simple math, it works out to about 200KB per second transfer rate. Note that I'm running the CPU at 8MHz. The same block writes were slower, as 8 block writes were showing 0.02 seconds most of the time, but every now and then, would post 0.03 seconds, so likely around 135KB per second. I don't expect the final BIOS with these functions implemented in the ISR to change the overall performance, as the data still needs to be received and sent to the CF-Card.

As the CF-Cards I'm using are limited to a multi block read or write of 1 (per the Identity data), I'll put some additional testing code in place to read and write a contiguous group of blocks once I get more of this code integrated into the BIOS and ISR routines. In any case, it's a pretty quick transfer rate for an 8-bit machine

6502.org

CF-Card/RTC adapter

CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter

Re: CF-Card/RTC adapter