6502.org Forum Projects Code Documents Tools Forum
It is currently Fri Nov 01, 2024 3:29 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programming

All times are UTC




Post new topic Reply to topic  Page 2 of 3
  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
  Previous topic | Next topic 
Author Message
floobydust
PostPosted: Tue Oct 13, 2020 2:02 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I've done some additional testing on using the /SO line.

First, the /SO pin does in fact set the overflow flag, no issue there, and of course, the CLV instruction will clear it. So the current WDC chip works as it always has. All good news....

However, I've not been successful at using this for handshaking the data transfer from the CF-Card (in True IDE mode). The transfer loop never breaks... which means the IOCS16 line continues to remain active. My guess is the IOCS16 line does not reset unless the Status register is read (which shows the DRQ - data request bit) as part of the loop. I'll need to break out the logic analyzer again and do some additional testing on this one. In any case, if this turns out to be the case, then there's no benefit to using the IOCS16 line to trigger the /SO line... as reading the Status register appears as the only working form of handshaking for data transfer (outside of different design which uses DMA, which isn't happening for my hardware design).

I've updated the new BIOS and will post it once I get some additional testing done... so far, so good.... data transfer rates are in excess of 250KB per second and vary a bit between different size CF-Cards.

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Thu Oct 15, 2020 3:55 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I've run basic tests using the update BIOS via the JUMP table calls.... which have changed slightly. I've also managed to streamline the code bit. I've decided to post it here along with the updated Monitor which also required some changes to support the new RTC code, etc. I've got some additional CF Cards on order which should arrive next week, so I'll do some additional testing on these as well. In the meantime, the code posted has been working reliably.

Attachment:
C02Monitor3.asm [161.34 KiB]
Downloaded 40 times

Attachment:
C02BIOS3.asm [111.92 KiB]
Downloaded 44 times


On a side note, I've noticed that the Maxim DS1511 runs on the fast side... gaining a second or more per day. Granted, the accuracy specified in the datasheet is +/- 1 minute per month. I just think it's fairly poor accuracy compared to most standard system boards these days.

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Oct 15, 2020 7:38 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8468
Location: Midwestern USA
floobydust wrote:
On a side note, I've noticed that the Maxim DS1511 runs on the fast side... gaining a second or more per day. Granted, the accuracy specified in the datasheet is +/- 1 minute per month.

±1 minute per month averages to ±2 seconds per day, which means your RTC is running within spec. Self-contained RTCs are not the most stable time sources, which is why it is best to use the RTC only to get an initial date and time, and thereafter use a binary software clock driven by a stable timebase that runs in the megahertz range. That's why I use the DUART's counter/timer to count jiffies. The drift on the 3.6864 MHz oscillator is small (I use 100ppm oscillators, which are the Walmart version), and timekeeping drift is about one fourth of what I was seeing with the DS1511.

Quote:
I just think it's fairly poor accuracy compared to most standard system boards these days.

Actually not. My company has built hundreds of servers since 1988 and I probably can count on both hands the number of motherboards whose RTCs kept good time, meaning within a few seconds per month. It's just the nature of the beast.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Thu Oct 15, 2020 7:51 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10971
Location: England
(A quick check suggests 1 second per day is about 12 ppm.)
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Oct 15, 2020 6:32 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8468
Location: Midwestern USA
BigEd wrote:
(A quick check suggests 1 second per day is about 12 ppm.)

I seem to recall that I worked that out around five years ago and came up with the same range. That was when I discovered the watchdog function in the DS1511 ran a little fast.

Of course, a 100 ppm or 50 ppm rating for an oscillator is a worst-case number. Odds are pretty good most production parts will be better than that.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
thedrip
PostPosted: Thu Oct 15, 2020 8:19 pm 
Offline

Joined: Tue Oct 02, 2018 4:22 am
Posts: 48
And here I was upset that my SBCs were 1s apart after a month!

My work laptop loses 4 minutes over a 2 day weekend.
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Thu Oct 15, 2020 9:06 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Well, I know that the RTC chip is within specification.... but then again, I have four of my C02 Pocket SBC boards running which are much more accurate with the BIOS RTC code, which uses the 16-bit counter/timer of the SCC2691 with it's own crystal, hence my mention of the DS1511 accuracy. As Ed noted, 12ppm is about right... still, I have older PS/2 Servers that are still within 10 minutes or so, after more than 20 years of sitting around, go figure.

On the other side of this post, I'm fairly happy with the last BIOS update... the detection strategies for the RTC and IDE have worked out well and the supporting code for each device has been working properly as well. The entire BIOS is just a bit over 1.5KB and has a fair amount of function for it's size (I still have 252 bytes of contiguous BIOS space left). I think the hardware and software are now at an initial level where getting an existing OS (Flex or DOS/65) working are now possible.

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Fri Dec 18, 2020 9:02 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Still making progress on this project... and am writing a utility for the RTC and CF Card. I have found that setting the Date/Time on the DS1511 is a bit odd. After loading the registers and enabling the transfer, the time is always about 2-3 seconds behind. This seems to imply that the RTC doesn't transfer the new settings and start counting right away. I've not found anything in the datasheet that would tend to explain this delay, but I don't see how it would a coding problem... the datasheet is pretty clear on setting the clock.

Has anyone else noticed this problem?

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sat Dec 19, 2020 5:42 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8468
Location: Midwestern USA
floobydust wrote:
Still making progress on this project... and am writing a utility for the RTC and CF Card. I have found that setting the Date/Time on the DS1511 is a bit odd. After loading the registers and enabling the transfer, the time is always about 2-3 seconds behind. This seems to imply that the RTC doesn't transfer the new settings and start counting right away. I've not found anything in the datasheet that would tend to explain this delay, but I don't see how it would a coding problem... the datasheet is pretty clear on setting the clock.

Has anyone else noticed this problem?

I haven't. Can you post your code for setting the DS1511's clock?

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


Last edited by BigDumbDinosaur on Sat Dec 19, 2020 3:55 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
floobydust
PostPosted: Sat Dec 19, 2020 7:04 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Here's the snippet of code that sets the RTC of the DS1511:

Code:
RTC_TIME_SET
                STZ     RTC_CONTROL_B           ;Clear TE bit for RTC Set
                SED                             ;Set decimal mode
;
                LDA     RTC_LOAD+0              ;Get Century
                STA     RTC_CENTURY             :Set Century
                LDA     RTC_LOAD+1              ;Get Year
                STA     RTC_YEAR                ;Set Year
                LDA     RTC_LOAD+2              ;Get Month
                STA     RTC_MONTH               ;Set Month
                LDA     RTC_LOAD+3              ;Get Date
                STA     RTC_DATE                ;Set Date
                LDA     RTC_LOAD+4              ;Get Day
                STA     RTC_DAY                 ;Set Day
                LDA     RTC_LOAD+5              ;Get Hours
                STA     RTC_HOURS               ;Set Hours
                LDA     RTC_LOAD+6              ;Get Minutes
                STA     RTC_MINUTES             ;Set Minutes
                LDA     RTC_LOAD+7              ;Get Seconds
                STA     RTC_SECONDS             ;Set Seconds
;
                CLD                             ;Clear Decimal mode
;
RTC_TIME_SYNC
                JSR     M_RDCHAR                ;Get character from user
                CMP     #$0D                    ;Check for C/R
                BNE     RTC_TIME_SYNC           ;Loop until C/R entered
;
                LDA     #%10000000              ;Get TE Bit to enable update
                STA     RTC_CONTROL_B           ;Set normal Transfer Mode
;
                LDA     #<RTC_CONFIRM           ;Load Message address
                LDY     #>RTC_CONFIRM           ;into A/Y regs
                JSR     M_PROMPTR               ;Send message to console
RTC_END
                JMP     USER_INPUT              ;Prompt User to return or continue


I load the registers first, then wait for the enter key to finish setting the TE bit, which should move the updated register over and start the RTC clock function.

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
Martin A
PostPosted: Sat Dec 19, 2020 9:14 am 
Offline

Joined: Sat Jan 02, 2016 10:22 am
Posts: 197
Silly question, why switch to decimal mode to do the register loads?

Doesn't setting the decimal flag only affect ADC and SBC ??
Top
 Profile  
Reply with quote  
Chromatix
PostPosted: Sat Dec 19, 2020 10:28 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
Yes, the D flag only influences ADC and SBC. You don't need it set to merely move BCD values around.

More importantly, it looks like you're loading the RTC registers with a time, then waiting for user input before resetting the TE flag. This results in the RTC's internal operations being inhibited for several seconds, probably, which I'm sure upsets some internal counters that are used to divide the 32kHz oscillator into seconds. I think you might find it works better if you keep the period where TE is set as short as possible, ie move the wait for user input to the very top of the code given above.
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Sat Dec 19, 2020 1:48 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I agree on the SED/CLD comment... however, when I initially tried setting the RTC, it locked up the chip... so I added the SED/CLD and that fixed it. I never bothered to revisit this part of the code, but I will.

On the TE bit, at first I was flipping the bit immediately in the code without waiting for input.... but it still ends up being 2-3 seconds behind what the registers are set for.

According to the datasheet, the internal oscillator/counter continues to run and update the internal registers regardless of the TE bit setting. The TE bit should only be halting the updating of the accessible registers, but there seems to be an issue on transferring the updated registers... hence my post :(

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sat Dec 19, 2020 4:33 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8468
Location: Midwestern USA
floobydust wrote:
Here's the snippet of code that sets the RTC of the DS1511...I load the registers first, then wait for the enter key to finish setting the TE bit, which should move the updated register over and start the RTC clock function.

Aside from the unnecessary SED — CLD, which others have pointed out, you have some hinkiness in your routine. Here is a listing of the code I use (written for the 65C816 in native mode):

Code:
04276  ;================================================================================
04277  ;
04278  ;putdtr: WRITE RTC DATE & TIME REGISTERS
04279  ;
04280  ;   ————————————————————————————————————————————————————
04281  ;   Preparatory Ops: .X: source address LSB
04282  ;                    .Y: source address MSB
04283  ;
04284  ;                    Source must contain 8 BCD values in
04285  ;                    the following order:
04286  ;
04287  ;                    Offset  Content      Range
04288  ;                    —-—-—-—-—-—-—-—-—-—-—-—-—-—-
04289  ;                      $00   seconds      $00-$59
04290  ;                      $01   minutes      $00-$59
04291  ;                      $02   hours        $00-$23
04292  ;                      $03   day-of-week  $01-$07
04293  ;                      $04   date         $01-$31
04294  ;                      $05   month        $01-$12
04295  ;                      $06   year LSB     $00-$99
04296  ;                      $07   year MSB     $00-$39
04297  ;                    —-—-—-—-—-—-—-—-—-—-—-—-—-—-
04298  ;
04299  ;   Returned Values: .A: entry value
04300  ;                    .B: entry value
04301  ;                    .X: entry value
04302  ;                    .Y: entry value
04303  ;
04304  ;   MPU Flags: NVmxDIZC
04305  ;              ||||||||
04306  ;              ++++++++———> entry values
04307  ;
04308  ;   Example: ldx #<todbuf
04309  ;            ldy #>todbuf
04310  ;            jsr putdtr
04311  ;   ————————————————————————————————————————————————————
04312  ;
04313  00D47D  08            putdtr   php                   ;save MPU state
04314           longr
04315  00D47E  C2 30                  rep #%00110000
04316  00D480  0B                     phd
04317  00D481  5A                     phy
04318  00D482  DA                     phx
04319  00D483  48                     pha
04320  00D484  A9 00 00               lda !#kerneldp        ;set default...
04321  00D487  5B                     tcd                   ;direct page
04322           shortr
04323  00D488  E2 30                  sep #%00110000
04324  00D48A  98                     tya                   ;storage address MSB
04325  00D48B  EB                     xba                   ;move to MSB of .C
04326  00D48C  8A                     txa                   ;storage address LSB
04327           longx                 ;16 bit index regs
04328  00D48D  C2 10                  rep #%00010000
04329  00D48F  AA                     tax                   ;source index
04330  00D490  A9 80                  lda #d11temsk
04331  00D492  1C 0F C3               trb io_rtc+wr_crb     ;halt register updates
04332  00D495  A0 00 00               ldy !#0               ;register offset
04333  ;
04334  00D498  A9 00         .0000010 lda #0                ;dummy value
04335  00D49A  C0 05 00               cpy !#wr_mon          ;month register?
04336  00D49D  D0 05                  bne .0000020          ;no
04337  ;
04338  00D49F  B9 00 C3               lda io_rtc,y          ;get month & control
04339  00D4A2  29 E0                  and #d11ecmsk         ;discard old month value
04340  ;
04341  00D4A4  15 00         .0000020 ora mm_ram,x          ;get new value
04342  00D4A6  99 00 C3               sta io_rtc,y          ;write RTC
04343  00D4A9  C0 07 00               cpy !#wr_yrhi-wr_sect ;all registers written?
04344  00D4AC  F0 90                  beq getdtraa          ;yes, done (below)
04345  ;
04346  00D4AE  E8                     inx                   ;next location
04347  00D4AF  C8                     iny                   ;next register
04348  00D4B0  80 E6                  bra .0000010

...

04172  00D43E  A9 80         getdtraa lda #d11temsk
04173  00D440  0C 0F C3               tsb io_rtc+wr_crb     ;resume register updates
04174           longr
04175  00D443  C2 30                  rep #%00110000
04176  00D445  68                     pla                   ;restore MPU entry state
04177  00D446  FA                     plx
04178  00D447  7A                     ply
04179  00D448  2B                     pld
04180  00D449  28                     plp
04181  00D44A  60                     rts

You shouldn't just blindly write into the month or control registers because they contain bitwise data that control operation of the DS1511. Also, what's the point of waiting until the user strikes <CR> to set the TE bit? You've already written to the RTC registers, so the date and time have been changed whether the user immediately strikes <CR> or waits until next week to do so. All the delay will do is determine when the new values actually take effect. TE should be cleared only for the length of time required to set the new date and time. If you wait to set TE your time will lag by however long you waited.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
cjs
PostPosted: Sun Dec 20, 2020 3:51 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
BigDumbDinosaur wrote:
Also, what's the point of waiting until the user strikes <CR> to set the TE bit?... If you wait to set TE your time will lag by however long you waited.

That's the point, I think. You put in not the current time but a time slightly in the future, and then hit Enter when that time arrives, so that the time is set accurately despite the varying amount of time it takes to type in the time you're setting.

(Though, as others have pointed out, doing all the writes after pressing Enter will take so little extra time—a few hundred microseconds—that separating the two won't give you any extra accuracy.)

_________________
Curt J. Sampson - github.com/0cjs
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 3
  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

Board index » 6502.org Users Forum » Programming

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
6502.org is an ongoing project by Mike Naberezny and contributors.