Use of Motorola 68000 family Operation Code 1010

[Scratch.HTF]

For the 16 bit opcode Bits 15-12, Operation Code 1111 (Line 1111 Emulator/Unimplemented F-Line Opcode) is for the coprocessor interface/68040 and CPU32 extensions/68851 MMU, but I am curious about devices which use code 1010 (Line 1010 Emulator/Unimplemented A-Line Opcode) - the Motorola Programmer's Reference Manual which includes CPU32 instructions (M68000PM/AD Rev. 1) lists it as unassigned/reserved and I discovered that early Apple Macintosh computers use this code for ROM-based routines (with Bits 11-0, up to 4096 (2^12) additional software interrupts can be implemented) - the Program Counter in the Stack frame (Format $0) refers to the address of the instruction which generated the Unimplemented Opcode exception.

[brucehoult]

My recollection is that once the Mac got popular Moto decided to never put any peripheral on the A-line.

[DiTBho]

• Line 1111 Emulator/Unimplemented F-Line Opcode, is for the coprocessor interface/68040 and CPU32 extensions/68851 MMU
• Line 1010 Emulator/Unimplemented A-Line Opcode, is for unassigned/reserved

1010 is used in the CPU32 evaluation board(1) by the ICE hardware.

edit:
(1) e.g. EVS, EVO, ...

[harerod]

My recollection is that once the Mac got popular Moto decided to never put any peripheral on the A-line.

Saw "Line 1010" and immediately remembered "LINE A" low level graphics interface of Atari ST TOS.

[brucehoult]

My recollection is that once the Mac got popular Moto decided to never put any peripheral on the A-line.

Saw "Line 1010" and immediately remembered "LINE A" low level graphics interface of Atari ST TOS.

Yes, using the same set of 4096 illegal instructions, for the same reason as Apple.

[bsdphk]

Line-A opcodes were often used as the system-call gate, because it could carry 12 bits of argument directly in the instruction.

One example I have at hand is the Rational R1000/s400 IOC processor, which runs a small kernel in protected mode, and all other software asks the kernel to do things through 0xa0xx instructions like this:

  00010226 ; --------------------------------------------------------------------------------------
  00010226 ; KC13_ReadRtc
  00010226 ; Comes from:
  00010226 ;     GetRtc() : TimeStamp @0x11710 C
  00010226 ; --------------------------------------------------------------------------------------
  00010226                                        KC13_ReadRtc:
  00010226 a0 13                    |        |            KERNCALL        #0x13
  00010228 ; --------------------------------------------------------------------------------------
  00010228 ; KC14_WriteRtc
  00010228 ; Comes from:
  00010228 ;     SetRtc(a: TimeStamp) @0x11892 C
  00010228 ; --------------------------------------------------------------------------------------
  00010228                                        KC14_WriteRtc:
  00010228 a0 14                    |        |            KERNCALL        #0x14

[BitBangBro]

My recollection is that once the Mac got popular Moto decided to never put any peripheral on the A-line.

Saw "Line 1010" and immediately remembered "LINE A" low level graphics interface of Atari ST TOS.

I've never saw a logic for those. At the time, Atari was hyping this trick as something insanely cool and "fast".
But I fail to see where that speed argument comes in.
When executing such an instruction CPU generates an exception.
Which means that it saes internal state on the stack etc.

So where is thart speedup supposed to come out from ?
Isn't it faster to just call the relevant routine without all that internal state-save&restore kerfuffle ?

[brucehoult]

It's not fast at all. It's to minimise the size of client code that makes huge numbers of calls into the OS/Toolbox, as it needs just a 2 byte opcode for the call (once arguments are set up obviously), not at least six bytes for a call to an absolute address. I also insulates apps from having ROM routine addresses hard-coded so that different models can have different ROMs.

It's also smaller than the more modern practice of putting the syscall number in a register and having a single entry point or single trap e.g. as in Arm EABI (syscall in register) vs OABI (syscall embedded in SWI instruction).

These early 32-bit machines had scarcely more RAM than the 8 bit machines they replaced, especially the first Mac.

[paulca]

So my 68000 white room design (follow on from my Z80 build) is still in my head only.  I use designing it to put me to sleep which it is effective at.

However when I read this thread it took me a few seconds to start going.... "Mmmm..  I see software interrupts.  I was wonder which bit of the CPU I was going to abuse for that."

However there may be easier ways than interrupts for IPC.

The mechanism I am still debating over is the handover from "User space" to "OS space".  If, as in my design, those two memory address mappings are virtual/paged.  So you could have a basic "jump" call which gates the input, causes the switch to supervisor mode.  That means the address of that function has to be in "shared memory" between user and kernel or the user space can't call it.  Decoupling via an interrupt, which is how Linux does this on the simple form, IIRC, the interrupt facilitates the switch to "supervisor/kernel" mode easier.  Using an illegal instruction to force an interrupt on demand and retain that OPCode looks like they should have realised people would use it for that.

Does the 68000 offer any easier methods to do that AddressSpace->AddressSpace hand over?  Am I missing something more fundamental?

Would it also be considered "taboo" to use the upper 8 address bits?  The addresses are 32bit yes?  But there are only 24 external address lines.  Does that not mean you could use those extra 256 sets of addresses as "flags"?

[brucehoult]

Does the 68000 offer any easier methods to do that AddressSpace->AddressSpace hand over?  Am I missing something more fundamental?

The 68000 has no address spaces. Or, I should say, it has exactly one address space. It also has no memory protection, other than putting things in ROM.

Would it also be considered "taboo" to use the upper 8 address bits?  The addresses are 32bit yes?  But there are only 24 external address lines.  Does that not mean you could use those extra 256 sets of addresses as "flags"?

It's a very very bad idea, and all such CPUs should force the upper bits to all be the same, and either all 0s or else all the same as bit 23 (in this case).

The 68000 didn't, and Apple put metadata in the upper 8 bits of pointers, and this caused them problems just three years later when they introduced 68020 machines and they were limited to using 16 MB RAM for the OS and apps, despite being physically able to install 128 MB. Two more years later Apple introduced "32 bit clean" ROMs in the Mac IIci and Mac IIx. A IIx ROM could be retrofitted to the original II.

Arm did the same stupid thing, but even worse, because they put the actual hardware CPU status flags in the upper 6 bits of the program counter. They fixed this in ARMv3 in 1991. It did allow slightly more efficient return from an interrupt. But I suppose it prevented things like setting the carry flag as a status return from functions (a very common trick on 8 bit CPUs)

[BitBangBro]

So my 68000 white room design (follow on from my Z80 build) is still in my head only.  I use designing it to put me to sleep which it is effective at.

I have been  toying with the idea to go for the bragging rights:

• Most insanely overclocked native MC68000 system on the planet
• Fastest MC68000 system on the planet, both single thread and multithread.
• First MC68000 system in which the CPU would be just at center of external state machine, where CPU would just drive external dumb "artillery".
• Amongst other things, first MC68000 system with rpedictive address decoder - that is address decoder that would predict the next fetch(es) of the CPU and start them early.

I've managed to dig-out the document,d escrtibing MC68000 timings in detail and fetches in sequence as they happen for each instruction.

One of interesting side effects was that such a machine could easily and relatively effectively get around MC68000's limit of 16MB address space.
Other would be that since MC68000 would be just a part of the bigger state machine, simply executing legal MC68000 instructions could have vastly different effect than one would expect, based on just instruction opcodes.

But, as often happens, there was no time.

[paulca]

Sorry, the basic design Im going for is a CPU+Custom MMU ala FPGA.   Fully wrapped unless I find shortcuts that don't hurt.

So all address bus contents will arrive at the FPGA and it will do an ignorant page look up and return "BUS FAULT" is none exists.  If one does exist it will map it out to physical RAM/ROM accordingly.  Obviously the addresses mapped to those "tlbs" page look ups are locked to supervisor page set.

I know the 68000 has limitations for the "full unix like kernel".  The main one being that it does not support "restore" after the BUS FAULT.  The options are to immediately retry the failed instruction or switch to supervisor mode and lose the context.

The main feature this prevents is the swapping and dynamic allocation sides of virtual memory.  In a modern linux when an MMU bus error occurs the x86 arch provides a way for the kernel to update memory tables/paging/swap etc. and then retry the instruction.

For my purposes this is a known limitation and I'm okay without dynamic bus faults.  In my purposes it will be fine that the process gets a "Address violation" and is kicked out of memory.  Guru mediation.  Although I'm told that was actually a CPU exception that was to be caught later, but ended up never being, just the red box error.  I would like an address bus fault to be caught.  A red screen of death would happen if the kernel/supervisor bus faulted.

It should maybe obvious, my purpose, asides building the hardware for fun, is in "white room" OS development purely for fun.

[BitBangBro]

Sorry, the basic design Im going for is a CPU+Custom MMU ala FPGA.   Fully wrapped unless I find shortcuts that don't hurt.

SO why not use MC68010 implementation then ?
That one can handle bus fault and stores enough info so that instruction can be retried.

[paulca]

Sorry, the basic design Im going for is a CPU+Custom MMU ala FPGA.   Fully wrapped unless I find shortcuts that don't hurt.

SO why not use MC68010 implementation then ?
That one can handle bus fault and stores enough info so that instruction can be retried.

I did look at that.  I believe if I go up to the 68020 it had a built in MMU too.

The thing is, 90% of the remaining examples are 68000.  90% of the online community documentation and recovered retro documentation are for the 68000.  Even the 68010 is much harder to find and the documentation is apparently even harder to find, though I haven't looked.  Granted a lot of people disregard it immediately as if you want to run Amiga software it most likely wont.

Basically the further up from the 68000 you get the rarer and more exotic your journey will be.  I want basic where basic will do as it's an easier baseline to build from, since there is no real end goal or purpose for the end result.

The project "planning" aspect is where I stalled out.  I need milestones and micro-goals to lead myself with a carrot of "one more little step".  Right now I have lofty goals of what it could once be, but haven't grounded a first step yet.  With the Z80 there were more practical options for breadboarding a few early prototypes, but honestly that was painful enough there.  For 68000 it will be harder, so ... I expect to spend a lot more of prototype PCBs.  Especially if the first PCB is a "Hello world, CPU+RAM+ROM" with a second function as a CPU tester.  The FPGA wrapper, along with the required 3.3V level shifting is far too big a "first goal".

[paulca]

If it wasn't the 68000... the 80286 is still just about DIY-able.  I believe it has full vmem MMU support too.  I want to stay with the 68000 because I like it and have history with it.

[BitBangBro]

The thing is, 90% of the remaining examples are 68000.  90% of the online community documentation and recovered retro documentation are for the 68000.  Even the 68010 is much harder to find and the documentation is apparently even harder to find, though I haven't looked.  Granted a lot of people disregard it immediately as if you want to run Amiga software it most likely wont.

Wait, I thought you were to implement it in FPGA.
68010 is the same chip for all practical purposes.
It has a "loop mode", VBR (vector base register), IIRC some register for alternate address spaces ( which jsut show in FC0-2 codes during memory access).
And reading the upper byte of status register is privileged on 68010.
For the most part, if you don't use those few extra bits, it behaves like 68000.

There are implementations of 68000 for FPGA and I'd expect to see some for 68010, too.

[BitBangBro]

For 68000 it will be harder, so ... I expect to spend a lot more of prototype PCBs.  Especially if the first PCB is a "Hello world, CPU+RAM+ROM" with a second function as a CPU tester.  The FPGA wrapper, along with the required 3.3V level shifting is far too big a "first goal".

If that means that you want to work with physical 68000 chip, stop dreaming about MMU etc.
MC68000 is kind of slow, especially WRT amount of logic that it uses. So the first thing you need to do is to figure how to "cut through corners" to get the job done at reasonable speed.

In practice this means bit-blit, DMA logic etc.

WHich would be another reason to play with FPGA.
It is a sandcastle studio, ideal for such games as it already has some RAM in the chip and adding external memory is simple.

But if you want to play with original chips, start thinking about cool ways to accelerate functions and to generate display.

[paulca]

But if you want to play with original chips, start thinking about cool ways to accelerate functions and to generate display.

I had no plans for a display.  I was just going to make it a boring old mini-computer style affair.  Like I did the Z80.  That means, it's likely to be ANSI terminal at best for most or all of it's life.

Doing displays for retro computers quickly enters into the analouge work of VGA for which I don't even have a monitor.

Again though, there are HDMI frame buffer hardware ICs available.  Which might then slap me right in the face as you suggest when I discover that a memory mapped/DMA screen buffer is going to be slow as hell without graphics acceleration hardware.

[paulca]

On an FPGA 68000.  It is likely to become part of the toolkit.  I did start with a "pet z80" in a Verilog sim before moving to hardware last time.    More as a hardware design test harness than a simulation.  "If my memory behaves like this and my address gates are like that, it does work right?", confirming tests etc.

A step I skipped for the Z80 I think might be my first 68000 step and that's an Arduino puppet harness.  There are a lot more features with a multi-step transactions in the 68000 architecture.  A lot can be explored that way, while maybe not the exactly timing like for like.

Going to real hardware maintains the authenticity of the build which carries into the "Necessity to write the OS".  I know if I lift too much "off the shelf" that authenticity will be removed and the project diminish.

To reword that.  The experience I want is to place myself into "XYZ's" shoes back in the 1970s/80s who was reading the datasheet for the 68000 and thinking, "How do I build a computer around this?".  While not limiting myself to only retro hardware and using all modern accelerative dev tooling.