Happy Birthday, Atari ST!
Already 40 years, where has the time gone?

https://dfarq.homeip.net/atari-st-introduced-april-8-1985/

I am considering the configuration of my Amiga 2000 w/ 68020 accelerator... I would appreciate opinions from drivers of slotted Amigas, here.

I have an Amiga 2000 with SCSI + SCSI2SD, 4MB 16-bit FAST RAM, 1MB CHIP RAM, etc. It also has an A2620 68020 accelerator (14MHz) with 2MB 32-bit FAST RAM which is meager, but makes things noticeably faster on the Workbench. Most of what I do on this is watch demos and play games, though. All I do on desktop, really, is use AmiTCP and ncftp to bring files over and run IMP sometimes.

I recently downloaded the Amiga demo 'Downslope' and noticed it's less fluid / smooth with the accelerator enabled. I've seen this before here and there, but assumed that the accelerator was doing my a solid in demos - giving a bit of a boost.

I commented about this in the Pouet 'Downslope' thread and the developer came in and commented,

---
"Accelerators often introduce an asynchronicity between CPU and chip memory, which adds to chip access latency.
This can be worsened by the occurrance of many interrupts, which can cause additional strain on memory on a higher CPU.
If we are unlucky, not even the much faster execution time of the higher CPU can make up for the additional latencies and strain on chip memory.
It's a matter of focus on the target. There are side effects on higher CPUs which are difficult to anticipate, and usually you have only a limited number of machines for testing."
---

This makes sense, I suppose. Is this common? Are people with '030, '040, '060 accelerators having a lesser experience with demos due to CHIP RAM latency than with base '000? Certainly in some scenarios the more powerful CPU helps hugely for demos and games alike - I've seen this on my '020. But, yes -- demos are the most tightly coded of all Amiga apps, certainly. To the metal, etc.

So I am wondering now, should I remove the accelerator to get the most out of OCS/ECS demos on the system? Yes, I can disable the accelerator with a right mouse click at reboot, but that gets in the way of keeping Degrader's PAL state in effect, causing a hassle. (it's an NTSC A2000, unfortunately).

Anyone been down this road? Thoughts?

Chips on the desk

"The Tool"

It's easy to forget just how huge 68000s in DIP format are. There are a couple of tubes of these 8 MHz parts at A1 in Etobicoke. As ever, the price will be highly dependent on how amusing your haggling skills are.

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

Free the Jaguar!

Jag-Ware

The Golden Age!

Excerpt from the sourcecode of "A Kernel for the MC68000 processor" by Steve Passe, published in the 1986 Dr. Dobb's Toolbook of 68000 Programming, p. 321 ff...

Are there any #MC68000 #mc68k gurus in the audience?
If a program running in usermode accesses the vectors via a data access instruction - what does the 68010 indicate on the function code pins?
Are vector reads escalated to being supervisor code/data reads, even though the code which triggered them is user-mode?

I'm trying to figure out why dereferencing a null pointer is 'fine' on a real #UnixPC but causes problems with the FreeBee emulator (if I disable vector access promotion).

Ever wondered why on #mc68000 a short branch to the next instruction will generate and error when assembling it?

bra.s .next ; will error out
.next:

The offset in the short branch instruction encoding is a 8-bit signed integer. Offset 0 (next instruction) is magic: that actually indicates a "wide" branch instruction with 16-bit offset following the instruction opcode. The offset 0 was of course chosen because branching to the next instruction is kind of pointless.

To actually branch to the next instruction you need to use the "wide form" branch:

bra.w .next
.next:

This instruction encodes to hex "6000 0000". Split down it is:

"60xx yyyy"

...where 8-bit offset xx is 0, which leads the instruction to be decoded as having 16-bit offset word yyyy. This offset word can have any value, including 0 => branch to next instruction.

A pretty much pristine #atarist 260ST mainboard that was sitting in a rather sad looking case with a rusted RF shield... nice .

Someone asked me about the PGA chip sitting on my Mac Studio in a recent toot showing some little glass figurines I brought back from Murano, Italy. They asked if it was a 386. It is, in fact, a ceraminc PGA 68-pin MC68HC000RC12. I didn't have a very clear shot of this chip I recently picked up off eBay, so I took one this morning to share with the person who asked -- and it turned out a rather striking image, to my eye.

I thought I'd share.

(I recently purchased the chip in new condition on eBay because of its nice, square purple ceramic and gold appearance (just to have as a desk bauble) and with a nod to the many MC68K systems I've used over the years -- and still use today.)

For today's #MARCHintosh post, I share a gallery of "screenshots" (camera pointed at CRT to catch that lovely blue tinted glow) of games and such, running on my Mac Plus.

https://www.flickr.com/photos/blakespot/albums/72157604396195465/

For #MARCHintosh today, I post my original 128K Macintosh.

For today's #MARCHintosh post, I share my original Macintosh in a photo with a bit of a liminal lean.

My Lisa 2/10, Mac Plus, and NeXTstation Turbo Color sharing a desk for today's #MARCHintosh post.