#m68k — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #m68k, aggregated by home.social.
-
ASM-editor is a modern web application for writing, executing and learning M68K assembler code (and MIPS, RISC-V, X86), which uses the SvelteKit framework and the Rust programming language.
Since our last news item, among other things, an introductory course on general assembly languages and an AI assistant in each editor that takes control of the editor and the emulator have been added.
-
Running Adobe’s 1991 PostScript Interpreter in the Browser
https://www.pagetable.com/?p=1854
#retrocomputing #postscript #m68k #laserjet -
PacificPage P·E PostScript Cartridge for HP LaserJet II/III
https://www.pagetable.com/?p=1850
#retrocomputing #postscript #m68k #laserjet -
m68k assembler support: m68kplugin 0.2.2 for JetBrains
In addition to Chris 'platon42' Hodges' MC68000 Assembly Language Plugin for Jetbrains' integrated development environments, Yann Cébron also provides one. Now version 0.2.2 has been released:
-
You can read fast file system drives in Linux, just modprobe the proper kernel module
FFS is not UFS with extras, read the link provided if you are interested
@rl_dane @OpenComputeDesign @moses_izumi
#RetroComputing #Amiga #RetroGaming #FFS #filesystems #programming #M68k
-
Reverse-engineering a 1986, Motorola 68020 printer postscript board and running #DOOM on it: https://www.youtube.com/watch?v=cltnlks2-uU
-
I’ve released a set of LightWave 3D 5.x plugins for AmigaOS, cross-compiled with GCC.
Includes ObjSwap, Fresnel, PBR-lite material shading, and a LensFlare image filter. Latest v0.6.7 improves LensFlare for denser specular/reflection scenes.
-
Amiga MicroPython Port Brings MicroPython v1.27 to AmigaOS m68k
#Amiga #AmigaOS #MicroPython #m68k #RetroComputing #ClassicAmiga #Python #WinUAE
https://theoasisbbs.com/amiga-micropython-port-brings-micropython-v1-27-to-amigaos-m68k/?fsp_sid=5023 -
Anyone want to help figure out the Lisa A-trap dispatcher? I put a disassembly in a gist: https://gist.github.com/eschaton/2c9cdcddccd3dde177005872ddd6e946
-
Someone did it ! A #sun3 clone https://github.com/54weasels/sun3_60
#sunos #sunmicrosystems #m68k #unix -
This new 68000 bears an original-looking Motorola logo.
Does NXP (or whoever licensed the #m68k IP) still labels them like this, or did they send me a vintage MC68000P8 part?
-
I soldered a new 64-pin socket on my #Amiga 500+ board under restoration and plugged in the #m68k.
It's still too early to tell if it works, but I've seen it toggle the R/W signal a few times at power on.
To make further progress, I need to find a Gary, the gate array which controls chip selects and various bus signals.
-
I ordered a single #m68k from the YUXINYUAN store on AliExpress for ¥150 + ¥300 for international shipping from Shenzhen ($2.87 total).
It arrived here in Tokyo in just 4 days. Yes, wow.
-
ASM-Pro 1.22 update: QREPT speeds repeat blocks
#Amiga #AmigaDev #ASMPro #M68K #AssemblyLanguage #Aminet #RetroComputing #Demoscene #AmigaCoding
https://theoasisbbs.com/asm-pro-1-22-update-qrept-speeds-repeat-blocks/?feed_id=7409&_unique_id=6957cfee5cf46 -
What an amazing #retrocomputing hack:
https://github.com/reinauer/amifusePython program which mounts any #Amiga partition on Linux or macOS using the original filesystem handler (e.g. L:SmartFilesystem or L:PFS3) running in an #m68k emulator.
-
RE: https://oldbytes.space/@amoroso/115706283832274942
Speaking of Jack Crenshaw's "Let's Build a Compiler", Ahmed Thabet reformatted the series and published a prettified and browsable version. Nice.
-
Between 1988 and 1995 Jack Crenshaw posted on Usenet "Let's Build a Compiler", a tutorial series on writing a Pascal compiler that generates 68K Assembly. 35 years later Eli Bendersky revisited the series and rewrote the compiler in Python to generate WebAssembly.
https://eli.thegreenplace.net/2025/revisiting-lets-build-a-compiler
-
@nazokiyoubinbou @argv_minus_one in #m68k land the 68008 was a similar 8-bit data path variant of its ancestor, but I hated how Motorola was actually removing features and simplifying the instruction set after the 68020, increasingly relying on emulation for more and more FP instructions. It gave the impression that they themselves are unable to cope with the complexity of their own making…
-
@igorkulman TBF this is standard #Apple fare. A while back I tried to create an Apple ID for my son and got stuck at "Something went wrong. Please try again later"—because I had truthfully specified his age as 13. "You have to be 16 to create an Apple ID" would have been great. "Try again in 3 years" would have been sufficiently helpful, but no. Completely indistinguishable from "network problem" or "server is broken". WTF 🤬
The only brilliant thing about this company is their marketing that somehow managed to get them a "good for non-technical people" reputation even while their error messages were usually gibberish of the sort "The application was terminated due to error -42", *some* of which you could sort of understand if you were nerdy enough to have the #m68k exception vector table memorized (#15: tried to execute FPU code on an FPU-less machine; #5: division by zero, etc.). As long as everything works, it's nice and glitzy, but as soon as there's a problem, Apple stuff gets more hostile than any #Linux. And "I pay for it so I can get support when I have a problem" has been a sad joke for years. -
Manchmal frage ich mich, wieviele Entscheidungen anders gefällt wurden, durch den Mangel an Vernetzung in den Mitt- bis Spät-80ern in der Breite.
Triviales Beispiel: mein lokaler Atari-ST-Computer-Händler in Karlsruhe (Wacker, Südstadt) empfahl mir dringendst *nicht* meinen ST bei ihm aufrüsten zu lassen (TOS 1.0->1.04, Overscan, 4 MB RAM). O-Ton: „das weiß niemand, ob so viele Änderungen dann noch stabil laufen“.
Ich war Schüler, hatte von Elektronik wenig Ahnung, und ging enttäuscht von dannen. Einen neuen Computer konnte ich mir nicht leisten, aber die Upgrades wären drin gewesen (und hätten meinem 1040STF gut getan). Heute weiß ich, dass die Änderungen nicht super kompliziert wären, und definitiv stabil ausführbar.
Damals kannte ich niemanden, der Computer-Elektronik konnte. In Mailboxen war ich erst ab 1991-1992 unterwegs. Daher blieb es mangels anderem Input bei einer Person, einer Aussage und damit (s/m)einer Entscheidung.
Bei allem Geschimpfe über moderne digitale Vernetzung: ich bin schon froh, dass es nicht mehr Ender der 80er ist.
^g
-
@BigBadBiologist ProTip: Install a small LaceScan module for increased resolutions:
• 640×400 becomes 732×480, a 37% increase (only 688×… on the SM124)
• 640×200 becomes 820×284, a hefty 80% increaseWho needs fancy graphics cards when you can push the boundaries of your ST quite a bit!
This add-on goes well with 4 MB of RAM, your productivity applications have waaaay more screen space, e.g. extra 5 lines of text.
-
We have display! 🥳
By chance I think, I didn't set the address.
-
@mainframed767 @smallsco Apple’s default/standard compiler for A/UX is K&R only, so it will compile only old/specially prepared C sources.
Then, there’s the “extra” ANSI compiler from Apple. http://archive.3rz.de/Mac/a-ux/A-UX%20Developer%20Tools%201.1%20(Apple%20ANSI%20C%20compiler).iso.gz that I archived from original CDs. It’s more capable and was part of the SDK for A/UX 3.
Or you could use gcc.
-
Time to analyze these even/odd roms. After some bit fiddling with Python, I have a single "interleaved.bin" that can be loaded into Ghidra.
After loading it into Ghidra we can immediately see a first hint - address $0x04 contains a number: 0x7c8.Beginning of the MC68k memory (first 0x100 bytes) contain a vector table and address 0x04 points to the "entry point".
And if we scroll to the address 0x7c8, we can see valid MC86k code.
-
These are parts of code in Brataccas that may have been written originally targeting the 68008 processor of the Sinclair QL before they were ported to the Atari ST
After some cursory scanning of the Brataccas code, some patterns emerged:
Case 1: Bit-reversal lookup table
This seems unusual and suggests graphics conversion between platforms with different pixel bit-ordering. The QL stored pixels in a different bit order than the ST - this table appears to be useful to convert graphics assets that were originally in Sinclair QL format.
; Bit-Reversal Table (L00A0-L00A4)
L00A0:DS.W 128,0
L00A2:LEA L00A0(PC),A0
MOVE.W #$FF,D7
L00A3:MOVE.B D0,D1
MOVEQ #6,D2
ROXR.B #1,D1
ROXL.B #1,D4
L00A4:ROXR.B #1,D1
ROXL.BCase 2 Excessive byte operations
Throughout the code, there's an unusual preference for byte operations:
MOVE.B (A0)+,D0
MOVE.B (A0)+,D1On the 68000 (ST/Amiga/Mac), word operations are typically preferred for performance. But the QL's 68008 CPU had an 8-bit external bus - byte vs word operations had similar performance. This coding style hints at optimisation for the 68008, not the 68000.
The disassembly available at the Brataccas website seems to have been produced from a QL to Atari ST port, not the Amiga as I originally thought.
https://www.brataccas.com/Page28.phpThe first part of the code (first 1000-1500 lines or so) is a music tracker, and it's clearly a separate module from the rest, clearly designed to be reusable. There are hints that the I/O ports are Atari-specific and that the engine allows for developers to perform hot-editing of music notes via the MIDI port, which was something incredibly sophisticated for 1985. Some other parts of the code deal with vibrato, legato, and effects during realtime play.
After that block there's what seems to be a sprite blitting engine, but that's as far as I got.
To be continued...
#brataccas #retrocomputing #retrogaming #m68k #SinclairQL #QL #asm #assembler #m68008
-
These are parts of code in Brataccas that may have been written originally targeting the 68008 processor of the Sinclair QL before they were ported to the Atari ST
After some cursory scanning of the Brataccas code, some patterns emerged:
Case 1: Bit-reversal lookup table
This seems unusual and suggests graphics conversion between platforms with different pixel bit-ordering. The QL stored pixels in a different bit order than the ST - this table appears to be useful to convert graphics assets that were originally in Sinclair QL format.
; Bit-Reversal Table (L00A0-L00A4)
L00A0:DS.W 128,0
L00A2:LEA L00A0(PC),A0
MOVE.W #$FF,D7
L00A3:MOVE.B D0,D1
MOVEQ #6,D2
ROXR.B #1,D1
ROXL.B #1,D4
L00A4:ROXR.B #1,D1
ROXL.BCase 2 Excessive byte operations
Throughout the code, there's an unusual preference for byte operations:
MOVE.B (A0)+,D0
MOVE.B (A0)+,D1On the 68000 (ST/Amiga/Mac), word operations are typically preferred for performance. But the QL's 68008 CPU had an 8-bit external bus - byte vs word operations had similar performance. This coding style hints at optimisation for the 68008, not the 68000.
The disassembly available at the Brataccas website seems to have been produced from a QL to Atari ST port, not the Amiga as I originally thought.
https://www.brataccas.com/Page28.phpThe first part of the code (first 1000-1500 lines or so) is a music tracker, and it's clearly a separate module from the rest, clearly designed to be reusable. There are hints that the I/O ports are Atari-specific and that the engine allows for developers to perform hot-editing of music notes via the MIDI port, which was something incredibly sophisticated for 1985. Some other parts of the code deal with vibrato, legato, and effects during realtime play.
After that block there's what seems to be a sprite blitting engine, but that's as far as I got.
To be continued...
#brataccas #retrocomputing #retrogaming #m68k #SinclairQL #QL #asm #assembler #m68008
-
These are parts of code in Brataccas that may have been written originally targeting the 68008 processor of the Sinclair QL before they were ported to the Atari ST
After some cursory scanning of the Brataccas code, some patterns emerged:
Case 1: Bit-reversal lookup table
This seems unusual and suggests graphics conversion between platforms with different pixel bit-ordering. The QL stored pixels in a different bit order than the ST - this table appears to be useful to convert graphics assets that were originally in Sinclair QL format.
; Bit-Reversal Table (L00A0-L00A4)
L00A0:DS.W 128,0
L00A2:LEA L00A0(PC),A0
MOVE.W #$FF,D7
L00A3:MOVE.B D0,D1
MOVEQ #6,D2
ROXR.B #1,D1
ROXL.B #1,D4
L00A4:ROXR.B #1,D1
ROXL.BCase 2 Excessive byte operations
Throughout the code, there's an unusual preference for byte operations:
MOVE.B (A0)+,D0
MOVE.B (A0)+,D1On the 68000 (ST/Amiga/Mac), word operations are typically preferred for performance. But the QL's 68008 CPU had an 8-bit external bus - byte vs word operations had similar performance. This coding style hints at optimisation for the 68008, not the 68000.
The disassembly available at the Brataccas website seems to have been produced from a QL to Atari ST port, not the Amiga as I originally thought.
https://www.brataccas.com/Page28.phpThe first part of the code (first 1000-1500 lines or so) is a music tracker, and it's clearly a separate module from the rest, clearly designed to be reusable. There are hints that the I/O ports are Atari-specific and that the engine allows for developers to perform hot-editing of music notes via the MIDI port, which was something incredibly sophisticated for 1985. Some other parts of the code deal with vibrato, legato, and effects during realtime play.
After that block there's what seems to be a sprite blitting engine, but that's as far as I got.
To be continued...
#brataccas #retrocomputing #retrogaming #m68k #SinclairQL #QL #asm #assembler #m68008
-
These are parts of code in Brataccas that may have been written originally targeting the 68008 processor of the Sinclair QL before they were ported to the Atari ST
After some cursory scanning of the Brataccas code, some patterns emerged:
Case 1: Bit-reversal lookup table
This seems unusual and suggests graphics conversion between platforms with different pixel bit-ordering. The QL stored pixels in a different bit order than the ST - this table appears to be useful to convert graphics assets that were originally in Sinclair QL format.
; Bit-Reversal Table (L00A0-L00A4)
L00A0:DS.W 128,0
L00A2:LEA L00A0(PC),A0
MOVE.W #$FF,D7
L00A3:MOVE.B D0,D1
MOVEQ #6,D2
ROXR.B #1,D1
ROXL.B #1,D4
L00A4:ROXR.B #1,D1
ROXL.BCase 2 Excessive byte operations
Throughout the code, there's an unusual preference for byte operations:
MOVE.B (A0)+,D0
MOVE.B (A0)+,D1On the 68000 (ST/Amiga/Mac), word operations are typically preferred for performance. But the QL's 68008 CPU had an 8-bit external bus - byte vs word operations had similar performance. This coding style hints at optimisation for the 68008, not the 68000.
The disassembly available at the Brataccas website seems to have been produced from a QL to Atari ST port, not the Amiga as I originally thought.
https://www.brataccas.com/Page28.phpThe first part of the code (first 1000-1500 lines or so) is a music tracker, and it's clearly a separate module from the rest, clearly designed to be reusable. There are hints that the I/O ports are Atari-specific and that the engine allows for developers to perform hot-editing of music notes via the MIDI port, which was something incredibly sophisticated for 1985. Some other parts of the code deal with vibrato, legato, and effects during realtime play.
After that block there's what seems to be a sprite blitting engine, but that's as far as I got.
To be continued...
#brataccas #retrocomputing #retrogaming #m68k #SinclairQL #QL #asm #assembler #m68008
-
These are parts of code in Brataccas that may have been written originally targeting the 68008 processor of the Sinclair QL before they were ported to the Atari ST
After some cursory scanning of the Brataccas code, some patterns emerged:
Case 1: Bit-reversal lookup table
This seems unusual and suggests graphics conversion between platforms with different pixel bit-ordering. The QL stored pixels in a different bit order than the ST - this table appears to be useful to convert graphics assets that were originally in Sinclair QL format.
; Bit-Reversal Table (L00A0-L00A4)
L00A0:DS.W 128,0
L00A2:LEA L00A0(PC),A0
MOVE.W #$FF,D7
L00A3:MOVE.B D0,D1
MOVEQ #6,D2
ROXR.B #1,D1
ROXL.B #1,D4
L00A4:ROXR.B #1,D1
ROXL.BCase 2 Excessive byte operations
Throughout the code, there's an unusual preference for byte operations:
MOVE.B (A0)+,D0
MOVE.B (A0)+,D1On the 68000 (ST/Amiga/Mac), word operations are typically preferred for performance. But the QL's 68008 CPU had an 8-bit external bus - byte vs word operations had similar performance. This coding style hints at optimisation for the 68008, not the 68000.
The disassembly available at the Brataccas website seems to have been produced from a QL to Atari ST port, not the Amiga as I originally thought.
https://www.brataccas.com/Page28.phpThe first part of the code (first 1000-1500 lines or so) is a music tracker, and it's clearly a separate module from the rest, clearly designed to be reusable. There are hints that the I/O ports are Atari-specific and that the engine allows for developers to perform hot-editing of music notes via the MIDI port, which was something incredibly sophisticated for 1985. Some other parts of the code deal with vibrato, legato, and effects during realtime play.
After that block there's what seems to be a sprite blitting engine, but that's as far as I got.
To be continued...
#brataccas #retrocomputing #retrogaming #m68k #SinclairQL #QL #asm #assembler #m68008
-
"Fancy a Brataccas bombshell"
#brataccas #bandersnatch #retrocomputing #retrogaming #Amiga #QL #M68k
-
MR Browser is the Package Manager Classic Macs Never Had https://hackaday.com/2025/07/18/mr-browser-is-the-package-manager-classic-macs-never-had/ #softwarerepositories #Retrocomputing #retrocomputing #classicmac #MacHacks #m68k #ppc
-
MR Browser is the Package Manager Classic Macs Never Had - Homebrew bills itself as the package manager MacOS never had (conveniently ignorin... - https://hackaday.com/2025/07/18/mr-browser-is-the-package-manager-classic-macs-never-had/ #softwarerepositories #retrocomputing #classicmac #machacks #m68k #ppc
-
Got a real 68000 computer to hand? Can you run a bit of test code? There's a bit of doubt about a test suite:
> One of the tests in the repo is for ABCD D7, D7, where D7 = 0x397C714F and the X bit is clear. The test specifies the answer should be 0x397C7104
question is from
https://anycpu.org/forum/viewtopic.php?f=12&t=1135#retroComputing #m68k #mc68000
Boosts welcome of course
-
Got a real 68000 computer to hand? Can you run a bit of test code? There's a bit of doubt about a test suite:
> One of the tests in the repo is for ABCD D7, D7, where D7 = 0x397C714F and the X bit is clear. The test specifies the answer should be 0x397C7104
question is from
https://anycpu.org/forum/viewtopic.php?f=12&t=1135#retroComputing #m68k #mc68000
Boosts welcome of course
-
All of them side by side #MC68010, #MC68020, #MC68030 and #MC68040. Absent from this pic here is my framed #MC68000 which ended somewhere in the cellar (along with my framed #AtariTT) after we have moved to a new house and the #MC68060 which is unaffordable right now #Atari #Amiga #m68k #retrocomputing
-
The #MC68020 would fit but, obviously, I have to print a new background 🤣 #Atari #Amiga #m68k #retrocomputing
-
#suntember you say ? This is gonna be fun. Here are two of my favorites. A Sun2/120 and Sun3/60
#m68k #68010 #68020 #sun2 #sun3 #sunmicrosystems -
@Setok @Truck @a13cui @franky Well I got it, but since I wasn't there to collect the prize I didn't bother with it. Sorry 😎
This is a variation of the classic addx texturemapping innerloop as discussed here: https://amycoders.org/opt/innerloops.html
-
Here's the shortest #Amiga program to write "Hello, World!" to shell:
sub.l a0,a0
bsr.b .hopla
dc.b 14,'Hello, World!',10,0
.hopla:
move.l (sp)+,d1
lsr.l #2,d1
move.l $124(a2),a4
moveq #12,d0
jmp (a5)The application can be 4 bytes shorter if you only care about AmigaOS 2.0+ compatibility. I believe there aren't many people around who can explain how (and why) it works.
