Vince Weaver

back when the Apple II / Applesoft BASIC twitter bot was a thing similar techniques were the best way to inject assembly language into a BASIC program, though we quickly learned there were more compact ways than REM to get a line ignored. Some examples here, as sadly the apple2twitter bot shut down and deleted their account a while ago. http://deater.net/weave/vmwprod/appleiibot/part7.html

My goodness, the whole site is a gem, an old-school "hacker" in the best sense of the word. http://www.deater.net/weave/ Pages go back to 1996! http://www.deater.net/weave/whatsnew1996.html

Is this yours? http://www.deater.net/weave/vmwprod/mist/ It's cool

Afaik you can do Vapor Lock on Apple - poor mans VBlank detection: http://deater.net/weave/vmwprod/megademo/vapor_lock.html

Uh-oh. Will Portal for Apple II be next? http://www.deater.net/weave/vmwprod/portal/

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/

Cool. Here's one for the Apple II [ http://www.deater.net/weave/vmwprod/portal/ ] and the C64: https://tasvideos.org/2122G

> 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

The Apple ][ hardware did not have a direct way to track vertical blanking. There were hacks that used artifacts in the dynamic memory refresh to sniff out when the VBI was happening. http://www.deater.net/weave/vmwprod/megademo/vapor_lock.html

Apple ][ Fire Demo -- 64 Bytes http://deater.net/weave/vmwprod/apple2_fire/

> 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-cont… [1] http://www.deater.net/weave/vmwprod/megademo/vapor_lock.html

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/

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.