There's another reason (beyond sign-up to spam) - you can't download or see attachments without registering.

I meant, midnight shown as 00:00am vs. 12:00am

I personally prefer the 24h format, which is non-ambiguous. Analog-clocks are from the past.
Imagine the following:
Sergeant: "Roll call tomorrow zero-six-hundred"
Private: "Sir Serge, A.M. or P.M. Sir?"

Make a screenshot from star-commander with that file opened in hex mode, then I might be able to tell the assembler which was used.
Try Turbo-Assembler or Turbo-Assembler-Macro+ it was very popular and saved files as compressed PRG by default.

I found that most Software and also my radio-controlled clock (when set to 12h mode) showing midnight as 00:00am , there seem to be 2 variants.

I already gave the tip to re-seat the ROM-chip U32 in your first thread with the same question:
http://www.commodore128.org/index.php?topic=3481.0

I doubt that the MMU is faulty because it would affect the native mode also.
For anyone being able to give further tips, we need more info regarding what happens after the go64 or reset with CBM-key held down. 'Doesn't work' leaves us guessing.

There's maybe a piece of plastic or a loose screw as obstacle in the way of the head-move-mechanism. You can move the head-assembly carefully, when the drive is powered off by using the step-motor wheel as you would tune-in a radio station, without a disk in the drive, but the drive door closed.
A Tip for testing: use a formatted but non-important disk instead of your original program disk.

This is not a question of Software, the PC-Disk-Controller can only read/write MFM-formats.
There once were (expensive) special controller cards who could also read/write Apple & CBM GCR-Disks, but I don't know if they are available these days.
The better solution is a real drive hooked via X(E,M,P)1571 cable to the printer port, and transfer via star-commander.
(or write the disk images to a 1581 disk and extract  on the real machine)

Although there seem to be not much interest, here's another short'n'quick:

This lil' routine converts a BCD number in A to it's binary equivalent, returned in A

tmp = $FB

bcd2bin:
PHA
AND #$F0
LSR
STA tmp
LSR
LSR
ADC tmp
STA tmp
PLA
AND #$0F
ADC tmp
RTS

Quote from: BigDumbDinosaur on July 24, 2010, 02:32 AM
...
Incidentally, direction of shift doesn't matter if the total shifts end up being the same.  The routine could be made to work with left shifts, but there's no advantage one way or the other.

Yes, if the # of shifts is the same, but in my specific case the version with asl rol would need 6 shifts, two more (+6 bytes and 14 Tcycles) than the lsr ror variant. Anyway, I made a small change to the original version to free the use of the Y-register, which lengthens the execution time from 57 to 60 TCycles (w/o RTS) but this is more than worth it, because the calling program doesn't need to preserve the register.

;ZP-adresses used
ResLo = $FC
ResHi = $FD

;on entry A is the multiplicator, the result is returned in ResLo = lo byte and ResHi = hi byte (ResHi also in A on return)
;X and A used to hold intermediate results

Mul80:
ldx #$00
stx ResLo
lsr
ror ResLo
lsr
ror ResLo
ldx ResLo
sta ResHi
lsr
ror ResLo
lsr
ror ResLo
pha
txa
adc ResLo
sta ResLo
pla
adc ResHi
sta ResHi
RTS

(as no one had explained the little trick inside, I'll give a tip - the summing at the end adds A*64 + A*16)


The generic 8x8 bit multiply from above can also be modified to not use the Y-register:

;DOUBLE-PRECISION MULTIPLICATION -- PRODUCT IN FAC1
;
;    -----------------------
;    .A = 8 bit multiplicand
;    .X = 8 bit multiplier
;    -----------------------
;    .A = used
;    .X = used
;    -----------------------
;
dpmult   sta fac1
         stx fac2              ;save operands
         lda #0
         sta fac1+1            ;clear product MSB
         ldx #8                ;bits to multiply
;
dpmult01 asl a                 ;shift partial product LSB
         rol fac1+1            ;rotate partial product MSB
         asl fac2              ;shift multiplier
         bcc dpmult02          ;skip add if next bit is zero
;
         clc                   ;add partial product to...
         adc fac1              ;multiplicand
         bcc dpmult02
;
         inc fac1+1            ;bump partial product MSB
;
dpmult02 dex
         bne dpmult01          ;next bit
;
         sta fac1              ;save product LSB
         rts
;

I'm jealous 

What was wrong with this one ?
http://www.commodore128.org/index.php?topic=3462.msg16977#msg16977

I don't see a major difference or advantage, but some useless code in your new version.
for ex. this:
lda $0d00
   ldx $0d01
   cmp #00
   bne cont
   cpx #00
   beq end
can be shortened to:
LDA $0d01
BEQ end
- the Z and N flags are set by loading a value, there's no need for an extra CMP#0, unless something in between had changed the flags.
And here:
lda #146
   jsr toscreen
   lda $0d02 ;why not LDX $0d02
   tax
   iny ;not used anywhere
   lda $0d03
   jsr digit

why not enter the basic here?:
; List Subroutine

5123: A0 03   LDY #$03
5125: 84 4B   STY $4B
5127: 84 11   STY $11
5129: 20 32 8E   JSR $8E32   ; Print Integer
512C: A9 20   LDA #$20

512E: A4 4B   LDY $4B
5130: 29 7F   AND #$7F

5132: 20 0C 56   JSR $560C
5135: C9 22   CMP #$22
5137: D0 06   BNE $513F
5139: A5 11   LDA $11
513B: 49 FF   EOR #$FF
513D: 85 11   STA $11

513F: C8   INY
5140: F0 DE   BEQ $5120
5142: 24 55   BIT $55
5144: 10 03   BPL $5149
5146: 20 AC 59   JSR $59AC   ; Insert Help Marker

5149: 20 EC 42   JSR $42EC   ; Get From ($61) Bank0
514C: F0 3D   BEQ $518B
514E: 6C 06 03   JMP ($0306)   ; Print Tokens Link [5151]

The blinking itself only means that something went wrong, while accessing the disk, not necessarily that the drive is defective. (more likely the disk is flaky)
It might be as simple as 'file not found' - you can tell more if you read the error channel, when this happens. If you're in native mode, tap <shift> <F7> or type monitor to enter the ML-monitor, at it's prompt type @<return> and you'll see the error-msg. of drive #8

I almost forgot - you can also type ?ds$ in basic 7

No, just the other way around (counter clockwise)

1|--U--|14
2|       |.
.|       |9
7|___|8

Yes, 7406 and 74LS06 have the same functionality, you can use it.
The same goes for the suffix N of the 74LS14 (specifying a temp. range or package - not important here).
If you replace those parts yourself take notice of their orientation, pin no. 1 is usually marked on the board, the IC's have a notch or other marker at the top of the package, where pin 1 is.

Yes, those are the parts. Replace U12 first and see if the drive is responsive again, if not replace U9 also. Maybe, as you already opened the drive, check if the CIA 8520 is seated correctly in it's socket.

look at the pin numbers, you'll find 6 x U9 and 6 x U12 (each IC has 14 pins 2 are not shown VCC - 14, GND - 7)

7406 and 74ls06 are the same, the latter is 'low power shottky' (usually build in)
U9 and U12 has each 6 of those inverters shown in the schematic U12 is for the output and should be replaced first (74ls06)

Then you have indentified the clock line as not ok - so see which parts are connected to that line. those 74ls06 74ls14 are cheap but you'll need someone to de-solder them for you if you don't have the skills.

If the cables are ok and the c128 communicates with other IEC devices, then you have to check for defective parts inside the drive. If your're lucky only a 74ls06/74ls07/74ls14 needs to be replaced (most common).
See the schematic I posted above which shows the IC's connected to the IEC socket on the right side.

Maybe you're able to track down which line is not ok -
enter the ML-mon. again as you did before but this time enter no drive cmd.
type in:
>fdd00
the first value shown should be 'C7' if not, then '47' means the data line is at fault, or if the value is '87' the clock line is not ok.
If the value was 'C7' modify the first byte to 'CF' clear the rest of the line with ESC Q - the new read value should be '4F' this test was fo the ATN line.

the description is a bit thin -
what do you get after Go64 or power-cycle/reset with held-down CBM-key ? (blank screen, blue screen, weird charset chaos)
Any modules in the catridge-port ? (if so, remove them temporary)
Maybe reseat the ROM's (U32,U33) by lifting them up slightly and pressing them firmly into the socket again.

to track down the error you might follow a strategy which excludes one possibility after the other.
Begin with disconnecting all devices, except the '81. As I understood your description the drive performs it's internal self-test without failure, to exclude a defective cable (the cheap ones may not even connect all lines - I've got some which didn't connect SRQ) replace with a spare one, or one you know of working flawlessly. Next power-on the C128 & drive, then goto the ML-Monitor and request an error status with @[dev#] this does not access the disk, but transfers data over the IEC-bus.
If you retrieve an error status "74, CBM DOS..." the ser. communtication parts of the drive (8520/6526 & 74LS06/07) are ok (hopefully).
If the former was ok, try a cmd which accesses the disk (i.e. dir - @[dev#],$ ) - if it hangs then, it's most probably caused by a problem with the power supply. During the motor-start phase the drive mechanic draws a higher current than normally, this can cause a voltage drop and a subsequent crash or lockup of the CPU. I solved this sort of irregularity with a new wiring of the drives power cord straight to the power plugin-socket plus an additional capacitor (4700uF) between +5 and ground.

If the former doesn't work (C128 hangs), then most probably one ore more of the IC's connecting to the IEC bus are defective, you can test in power-off state with a multimeter if one of the lines is short to ground, then look up the schematic (attached) which parts connect to which line.

Ugh, whats up here? - been away only shortly.

looking for a working example ?
The key is to save those VDC-registers which are modified due to the custom code, at the beginning, and restore them on exiting. It's not req. to blank-out the full editor rom-range (c400 - ce00) which includes many routines that doesn't touch the VDC. The stack-sniffing part is limited to page $CDxx and only required if the screen-update is part of the IRQ-handler.
Caution - the following code is spiced with 'magic-numbers' straight from the build-in ML-Monitor

*= $1300 ;

stack = $0100

WRITE80 = $cdca
WRITE_Reg = $cdcc
READ80 = $cdd8
READ_Reg = $cdda

cia1tenth = $dc08
cia1sec = $dc09
cia1min = $dc0a
cia1hour = $dc0b

SYSIRQ = $fa65 ;default IRQ-handler

IRQentry: ;from vec. $0314/15
cld ;important - the interrupted prog might have used decimal-mode

jsr ReadTime ;read to buffer ~0.5sec interval

tsx
lda stack +7,x ;get interrupted prog loc. Hi byte
eor #$cd
beq continue ;skip vdc access if in range $CDxx

usrsub:   ;anything that modifies VDC-registers goes here
jsr DispUpd ;upd. VDC display
continue:
;insert additional jsr that don't mess with the VDC here

jmp SYSIRQ ;to std. IRQ handler

ReadTime:
lda cia1tenth
and #$04
smod:
cmp #$00 ;upd. time buffer ?
bne updtime
lda #$2c ;op-code bit
sta usrsub ;disable DispUpd -> no new data (yet)
rts

updtime:
sta smod +1
lda #$20  ;op-code jsr
sta usrsub ;enable DispUpd

ldy #$00
lda cia1hour
and #$1f
cmp #$12
bne chk_pm
lda #$00 ;noon or midnight
chk_pm:
bit cia1hour
bpl no_change
clc
sed
adc #$12
cld
no_change:
jsr bcd2asc
iny  ;skip separator
lda cia1min
jsr bcd2asc
iny
lda cia1sec
bit cia1tenth ;un-latch clock

;sub bcd to ascii decode
bcd2asc:
pha
lsr a
lsr a
lsr a
lsr a
ora #$30
sta TimeBuf,y
iny
pla
and #$0f
ora #$30
sta TimeBuf,y
iny
rts

DisplUpd:
;save upd pointer -1 & last written data
ldx #$13 ;vdc-reg. 19 (update lo)
jsr READ_Reg
sec
sbc #$01
sta VupdSavL
jsr WRITE_Reg
dex   ;vdc-reg. 18 (update hi)
jsr READ_Reg
sbc #$00
sta VupdSavH
jsr WRITE_Reg
jsr READ80  ;read back last written data (reg 31)
sta VdtaSav

;now the clock display
ldx #$13  ;set upd location to $0048 (top-right corner -8)
lda #$48
jsr WRITE_Reg
dex
lda #$00
jsr WRITE_Reg

ldy #$00  ;output buffered time string
outloop:
lda TimeBuf,y
jsr WRITE80
iny
cpy #$08
bcc outloop

;restoring the registers used, before exiting
ldx #$13
lda VupdSavL
jsr WRITE_Reg
dex
lda VupdSavH
jsr WRITE_Reg
lda VdtaSav
jmp WRITE80

;Time string
TimeBuf .byte '00:00:00'
;saved VDC register values goin' here
VupdSavL .byte $00
VupdSavH .byte $00
VdtaSav .byte $00

the above would work if dev#9 weren't present - it's almost everytime possible to use dev no. 30 as temporary one.
In general the u0> cmd only exists on 1570/71/81 but not on 1541 (or emulated) drives.

the above has a bug - you're using 4 reubase addresses (0 to 3) actually reubase + 3 is translen.

sorry for the delay - I was on a (too short) holiday trip to the Netherlands.

back to the topic - I've tried a few different things, but the only working solution is to copy each basic line to a buffer in ram0 and trick the basic list routine in thinking there's just one line (btw. your detokenize-call decodes just one byte at location $61/$62).
Another thing is the original load addr. of the basic-prog. (you'll like to analyze) - if you load to an user-specified addr. (here to bank1 $0401) the kernal doesn't save the file's first two bytes anywhere, so to get these, 1st open the file, then read & save the first 2 bytes, close the file, set-up to load to addr. 0401 in bank1 and finally call the kernal-load routine.

The following program-snippet expects to find a already loaded program-file in bank1 @ $0401 & that the system rom's are enabled on entry (start), it will list the program from 1st to the last basic-line.

;ZP-adresses used:
;user define
srcptrlo = $FB
srcptrHi = $FC
buffer = $FE00 ;top-most page of ram0 likely unused.

;fixed (used by rom-code)
llinelo = $16 ;used to limit the line no. range
llinehi = $17
wrklo = $61
wrkhi = $62 ;used by the list routine as pointer to actual location

curline = $EB ;current screen line - see note(s)
sh_flags = $D3 ;shift flags

;subroutine fetch from ram1
FTINIT:
STA $02AA ;adj. ZP pointer
Fetch_r1:
LDX #$7F  ;RAM1 MMU config
JMP $02A2 ;fetch

;INIT pointers
START:
LDA #$00  ;buffer $FE00 - $FEFF
LDX #>buffer  ;hi byte of buffer, page aligned
STA wrklo
STX wrkhi
TAY ;A = Y = $00
STA (wrklo),Y ;init byte before link ptr.
DEY
STA (wrklo),Y ;end of prog marker
DEY
STA (wrklo),Y
TYA
LDY #$01
STA (wrklo),Y ;link ptr lo (buffer)
INY
TXA
STA (wrklo),Y ;link ptr hi (buffer)

LDA #$01 ;src start (ram1)
LDX #$04
STA srcptrlo
STX srcptrhi
LDA #$FF ;list unconditional
STA llinelo
STA llinehi

;new (next) line
next:
LDY #$01  ;set lo buffer start adr. + index to link hi
STY wrklo
LDA #srcptrlo  ;ZP loc. to use for fetch (immediate value)
JSR FTINIT    ;read linelink hi
BEQ finish    ;if zero -> end of prog.

INY
JSR Fetch_r1  ;basic line # lo
STA (wrklo),Y
INY
JSR Fetch_r1  ;basic line # hi
copyl:
STA (wrklo),Y

;copy to buffer until 00 = end of basic line

INY
JSR Fetch_r1
BEQ copyend ;skip if end of line
CPY #$FC   ;overflow check
BCC copyl  ;loop if not
LDA #$00   ;line too long condition

copyend:
STA (wrklo),Y

INY
TYA
CLC
ADC srcptrlo    ;advance src. pointer to next line (link)
STA srcptrlo
BCC no_ih
INC srcptrhi
no_ih:

JSR $50E5  ;basic list rom-routine entry

DEC curline ;undo additional linefeed

;simplistic scroll stopper - halts as long as <CBM>,<CTRL> or <Shift> keys pressed
halt:
LDA sh_flags
BNE halt

JMP next ;repeat with next line

;end marker of src. reached
Finish:
BRK ;continue your code here (or RTS)

Notes:
- during the list portion ($50e5) the rom-code checks for Run/Stop key and if pressed exits to Basic (ready vector) - to avoid this, set SEI before the call or redirect the ready-vector.
- as this routine tricks basic in thinking only one line (the currently copied) exist, the rom-code inserts an additional linefeed after each line (hence the 'DEC curline zp-loc. $EB)

revised/simplified version