Vince Weaver

> The CPU (the Motorola 68000) initiates all communication in the case of the Macintosh

Minor nitpick but the video controller has direct access to RAM and when the visible part of the display is being drawn by the video controller, it does cycle-stealing DMA that preempts the CPU.

You can read in depth about it from Steve Chamberlain, the designer of an FPGA low level clone of the Mac Plus here: [0]

By the way but this why the compact Macs have CPU performance of about a 6 MHz 68000 when clocked at almost 8 MHz. About half the time the display is being redrawn. And about half the memory bandwidth is used up at those times.

Bit of a tangent but the Apple II used a similar approach for its video system. As the article notes, the 68K has a prefetch queue. So it's always reading ahead which is what you get from reading an open bus. But the 6502 is a simple CPU without that fancy prefetch queue, so if you read a non-extant address on the Apple II you get what the video system just read and drew in the previous half-cycle. It's possible to sync up the CPU with the video system this way; something otherwise impossible on the Apple II. [1]

[0] https://www.bigmessowires.com/2011/08/25/68000-interleaved-memory-controller-design/

[1] http://www.deater.net/weave/vmwprod/megademo/vapor_lock.html

If you're going to be writing assembly on Linux, you should decide which of the two major syntaxes to learn:

- AT&T (gas, gcc inline assembly)
- Intel (nasm, fasm, yasm, but also gas)

Some links to help you decide:

Pro-gas: http://www.deater.net/weave/vmwprod/asm/ll/README.gas_sucks

Anti-gas: http://x86asm.net/articles/what-i-dislike-about-gas/

Neither/both: http://www.ibm.com/developerworks/linux/library/l-gas-nasm/index.html

Neither: http://webster.cs.ucr.edu/AsmTools/WhichAsm.html

If you decide to go with AT&T/gas, check out "Programming from the Ground Up", by Jonathan Bartlett:

http://download.savannah.gnu.org/releases/pgubook/

If you decide to go with Intel/nasm, see "PC Assembly Language" by Paul A. Carter:

http://www.drpaulcarter.com/pcasm/

Also, the following tutorial is focused on DOS/8086, but it's really unique in that it's very interactive, and provides you with a fully functional assembly interpreter and 8086 simulator:

http://www.btinternet.com/~btketman/tutpage.html

I highly recommend it for getting a quick feel for the basics, though some of the DOS/8086 specific stuff in it won't apply to Linux.

Thanks for the link!

Adapting the Project Oberon compiler code generation isn't that difficult, but the devil is in the details :). My student Rikke described some of the challenges porting Project Oberon to RISC-V in her project report (https://github.com/solbjorg/oberon-riscv/blob/master/report.pdf).

I assume that the most time-consuming task to get Project Oberon to run on ARM/Raspberry Pi would be to write device drivers for more complex devices, e.g. USB and Ethernet. These could be written in Oberon (which would be a considerable effort) or possibly be abstracted by using a bare-metal hypervisor that supports VirtIO device abstractions, e.g. Vmware ESXI. This way, one would only have to implement VirtIO drivers in Oberon, which is considerably less complex.

Connecting a PS/2 keyboard and mouse instead of USB might also be an alternative, since drivers for PS/2 are far less complex: http://www.deater.net/weave/vmwprod/hardware/pi-ps2/

> What sticks in my mind from my limited exposure to SuperH is that there's no load immediate instruction, so you have to do a PC-relative load instead.

SuperH has a mov #imm, Rx that can take an 8-bit #imm. But you're right, literal pools were used just like on ARM.

Things I liked about SuperH: 16 bit fixed-width insn format (except for some SH2A and DSP ops), T flag for bit manipulation ops, GBR to enable scaled loads with offset, xtrct instruction, single-cycle division insns (div0, div1), MAC insns.

In terms of code density SH was quite effective, see here http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf or here http://www.deater.net/weave/vmwprod/asm/ll/ll.html

It's got some smooth and color graphics and while we don't get to hear the delightful 1-bit speaker of the Apple IIe, the Mockingboard is much gentler on the ears in this nicely synthesized multi-part song which appears to be custom-composed by mA2E just for this demo.

From the description:

2023 edition of my annual Christmas Demo tradition. Recorded on real Apple IIe with Mockingboard card.

by Desire, code by Deater, Music by mA2E

There's some vapor-lock / vblank detection/ non-typical mid-screen mode switches happening here.

for more info/disk image see: http://deater.net/weave/vmwprod/xmas23/