Monday, September 26, 2016
More 68000 Assembler Required
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
- 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.
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