Tuesday, September 27, 2016

More 68000 Assembler Required

*INCLUDE '/equ/jsysequ.asm'

latch   equ 0ffffff20h   ; also tried 0bfffff20h
year    equ 0ffffff26h   ; also 0bfffff26h


      move.l #latch,a0  ; first must read latch
      move.b (a0)+,d1   ; read latch into d1

      move.b #10,(a0)+  ; set hour
      move.b #11,(a0)+  ; set minutes
      move.b #12,(a0)+  ; set seconds
      move.b #09,(a0)+  ; set month
      move.b #24,(a0)+  ; set date
      move.b #98,(a0)   ; set year

      move.l #latch,a0
      move.b (a0),d1    ; second read sets clock

      move #0,   D3
      jsys #_exit


Subtitle: Feel free to assist me!

See Also: Cromemco Millennium Bug

Marcus was never a big fan of Motorola 68000 assembler.  To set things in context, in the late 1970's and early 1980's three CPU  (i.e. processor) families were commonly used for Personal Computers.

- Motorola 6800 and if lucky 6809

- MOS Technology 6502

- Intel 8080 and then mostly Zilog Z80

At the time many embryonic business computers ran the CP/M operating System (or variant) and were powered by a Zilog Z80 processor with 64K Bytes of RAM memory.

However for Marcus and most other visionaries it was generally accepted that the Motorola 68000 processor  (and its follow on 68010 68020 68030) variants were the future.

That was until IBM announced the IBM PC using the Intel 8088 processor, and as a purist I would say ruined everything  (some would say changed everything).

A Shameless Z80 supporter
I did start with Intel 8080 assembler but I immediately felt at home with Z80 Assembler programming. The assembler mnemonics and instruction set were elegant and logical and simple.

By comparison the Motorola 6800 assembler or 6502 assembler was horrid.

Imagine the angst then when the computers we Engineered and Sold and programmed for traded up to Motorola 68000 assembler.   Aargh.   I did love the architecture and register layout of the Motorola 68000.  It was just the Assembler syntax felt alien to me.   Here then are some specific grumbles:

- The assembler syntax to me was inconsistent.

move.w   d0,d1  ; copy d0 register into d1
move.w   d0, AB1248H ; copy d0 into the contents of memory AB1248 Hex
; to me this should be move.w d0 (AB1248H).  Pah!

- The wrong way around Gromit

move #1,d0  ; load register d0 with the number 1
ld a,1      ; The Z80 was from right to left. Load A reg with 1.  Better!

- I had to remember different mnemonics for byte and word and long


come on!

- Processor capability confusion.  The 68010 had 32 bit registers but only a 24 bit address bus, but the 68020 has 32bit address and data bus, so to me this was added complexity I did not welcome

- Privilege levels, were there but not that useful.  Certainly did not map well onto the UNIX system architecture that I was familiar with

- Fancy Instructions:
There were many fancy auto increment instructions that allowed for a pointer to be incremented before or after an activity.  Whilst this looked very clever, it was actually too clever.  Meaning that I could do it at assembler level, but I was completely stumped as how to implement this in Compiler design,  at the time this made me feel like a dumbo!

Back to My Problem

First please read up my unsuccessful attempts to sort out the Cromemco Millennium Bug.  For the reasons below I can see that interaction directly with the clock hardware is not going to fix it.  But I ask somebody:

- Is my program working correctly
- What about the IO mapping, what memory addresses should I use?
- Am I programming it right, I mean the reading of the 1/100 register

Read And Comment Please:

 I dug up the Intersil ICM7170 datasheet and it became clear when I also downloaded the 'millennium' errata that direct programming would not change the outcome at the Operating ystem Level since the year is stored as a 2 digit number in this Hardware Clock. The OS is responsible completely for handling year 2000.

This is the Port IO layout

Memory mapping on the XXU Processor card

Anyway, my program attempts to set the date via raw assembler to 1999, but after the time command is run, it has not changed to 1999.

Lastly there is no XMU Memory Management installed and I presume that although this is a user program it can write to the IO ports as the above diagram shows?

Oh yes,  I initially missed this, because it was a footnote in the intersil pdf!
Without the 2 reads of the 1/100 second register I understand nothing gets set.  Hmm.

A Happy Ending?

There is no happy ending thus far.   But I am hopeful that this post might provoke a response from somebody with more Assembler knowledge than I who can help me towards a solution.  That solution to actually set the Hardware Clock.  And then I use the Cromix /bin/time.bin command to read that changed time and print it out.

A decent M68000 Assembler tutorial