Virtual blinky - 68000 assembler learning lab

[paulca]

I have a long running project with the 68k.  Hardware and software.

However it progressed into the C runtime layer fairly quickly and the asm I do have lives in the bootloader.s and is basically just a mem copy.

So I was itching to write some bare assembler for fun, learning.

I used Mushahi emulator and with claudes help spun up a test rig with bare ASM binaries with a make file and even a step debugger with CPU monitor... in about 10 minutes. 

To keep things useful, but still "super simple" for learning... IO amounts to two addresses.  0x1....0 written to sends to the Unix terminal.  0x1.....1 When read from gives you the last character typed on the terminal.

So what was the first thing I wrote after "printhello:, printstr, printchr"?

print-binary-led-bar.

I couldn't help it.  The tradition would have me move to "What is your name.... Hello name." and pull in "getchr" etc.  But I decided to lift the "LED bar" from the breadboard and put it in the virtual lab.

Now I can finally get around to doing knight rider, chaser, ping pong, bouncer etc.  Excellent for play with bit wise ops.

The 68k is a lot more fun than the Z80 was.  It has many thorns you can grab and regret it.  Like how address offsets are calculated based on the "mid instruction" PC..  The address of the operand, not the address of the instruction.  That one is going to hurt to forget.

Also the way they have "b[cc]" with a branch condition set which is "jump on true", but their dbra - decrement and branch... and branch if false. 

So it's "counter loops" are always "do until" which is a bit of a mind rotation from the "non-incrementing" "do while" versions.  There is also a convention which grates me.  "Exit loops on negative" is the default dbra mode.  So if you start with counterReg=10 it will iteratte 11 times.  There are justifications, but it still deserves a "WTF?"

[brucehoult]

The 68k is a lot more fun than the Z80 was.

That's for darn sure.

Wait until you learn about "ARM"!

I recommend skipping straight to ARMv3 (1991) to avoid the 26-bit address space brokenness (with flags in the hi bits), similar to the 24-bit address space brokenness of original 68k.

64MB ought to be enough for anyone.

[paulca]

Wait until you learn about "ARM"!

I did dive into assembler on the STM32. 

ARM went like this...

I want to move r0 to r5.
Do you want to move all 32?  Maybe 64?  Just the left half, right half, or just a particular quarter 8?   Do you want it moved like for like by word position or something else?  Would you like to make all of the above conditional?  What about a left/right shift operation at the same time?  Or you could add, subtract, or just jump in the same instruction.

It makes RISC into a mockery is what it does.

EDIT.  In fairness, the thing all those "variants" exist for is obvious once you look.  "One cycle, one instruction".  Right?  So how do you get to over unity like the AMD64 et. al.  Which can concurrently execute many instructions per clock cycle using pipelining and parallel predictions.

Solution.  Make variants of all teh instructions to include other operations, so that a smart compiler can effectively pick from a MASSIVE matrix of variants to achieve in one clock cycle what would in any sane human readible asm be many instructions.  Hand writing it... don't think anyone cared in the slightest.

[DiTBho]

The 68k is a lot more fun than the Z80 was.

Wait until you learn about "ARM"!

ARM on the Nintendo GBA should be tempting in this case 

[paulca]

It turns out my choice to go with LED bars and not "text input" turned out to be a nice kind of cruel.

It sort of forced me into various architectural limitations and conventions fairly rapidly.  Operations like "rotate" require alignment with the actual order of bits, versus the bare numbering of them.  Bit 0 is on the right.... not the left.  It forces  you to deal with the "size" suffix on instructions etc. 

Trying to add a delay loop (given this emulated 68k is running in effectively the GHz) brought me against one of the many parts where the "proudly 32bit internal" 68k starts to shuffle it's feet and murmur... i am 16bit.  "MULU" and "MULS" only multiply 16bit operands.  There is no 32*32

Worth the fun for a few hours.  Also sorting out my preferred calling convention at this stage also.  Picking my assembler poison too.


So far this about as advanced as its got... lol

[paulca]

Just as an update.  I got bored eventually.  I ended up at creating an X,Y table of "DRUMS" and made an LED beatbox.  For no purpose other than it forced me into using the "register + offset + displaement" addressing modes.  Turns out it's not quite as straight forward as you might expect.  It does not acutally permit a "true dynamic" X, Y offset.  There is only 1 register for "offset", the displacement is immediate.  So I used displacement for the "column index" (X axis) and equ'd them.

Then I moved on entirely.  Spawned a new emulator and started back even further than "from scratch".  I started with writing my own emulator memory access (bus) accessor functions.

Then the first ASM ROM which went on it, fully established the boot vector table, all 1024 entries and started a "BIT Test" as I called it.  "POST" would be the more common name.  This was literally how I tested the memory bus accessor C functions.  They failed in several "out by one" in byte shifting.

In the upcoming "real" hardware that BIT/POST will also be extremely handy.

This post collides in an interesting way.  When you ask, during POST, "How do I report an error when the thing that reports errors is not tested working yet?"  ie.  You have no IO yet, you just discovered that "Odd Byte access" is broken.  How do you tell the user this has occured before you lock up in the coffin_handler?  (I am definitely renaming my unhandled_exception handler that now).  Guru meditation, but worse.

The answer in the past has been, according to claude, "The address bus" is your first way to speak to the world.  All you need is a latch.  I didn't go too deep into that, but basically, you have a collection of "lock loops" to send the CPU during a fault.  The "latched" address bus LEDs will read the same constant address.  There is your "Fault code".

There are alternatives with the HALT instruction as it has a direct external signal, which can drive the actual "Latch" pin.  However I need to read the manual a little more closely before I go that way.