#m68k

[verilog-official]

its fascinating how Gentoo can run on a 486. a completely modern operating system running on a CPU from 1989.

and theoretically you can run any software on it because you can just compile it targeting the 486, theoretically. even running like Firefox, assuming you have enough RAM.

hell, you might even be able to get it to run on a Motorola 68000, which is 10 years older than the 486, and Gentoo runs on it! though idk if lots of modern software could run on it because it's a completely different architecture. theoretically it should be possible tho

[memedical-attention]

I’ve been thinking about this for a little while — something I’d want to do if I had the time and money would be to design a Motorola 68000-powered tiny (10” or smaller) laptop. Modern CMOS 68K implementations are very power-efficient and decently well-suited to handheld and portable devices (see: TI-92 series), and if combined with a crisp, modern monochrome OLED display, could get you days of continuous usage without needing a recharge! Add a few megabytes of RAM, some peripherals (IDE/CF controller, ISA or S-100 slots, DMA controller, SPI bus, RS-232 port, SD or CF slot, PS/2 port for a mouse, text mode + hires monochrome video card, etc…), and you have a nice, flexible system that can be rarely charged, doesn’t require ventilation, and can be just thick enough to fit the widest port or slot on it.

The main issue would be software support: nearly all existing operating systems that ran on a 68K were either intended for very specific hardware (Classic Mac OS, AmigaOS) or required more than a flat 68000 (NetBSD, Linux, or any other UNIX requiring MMU paging). So, it would probably end up being a custom DOS with some multitasking and priv level capability, or perhaps CP/M-68K (but I don’t know how much software was ever written for that — also, it provides a “bare minimum” hardware abstraction of a text-mode console and disk drive). A custom DOS, with a nice, standard C library capable of running compiled software, would probably be the way to go.

The software question perhaps raises another, harder question: What would I use this for? Programming? Then I’d want a text editor, maybe vi(m) or something like that. OK. Vim just needs termcap/(n)curses or whatever to draw the text, and not much else. That’s doable! You’d just need to provide text-mode VT100 emulation and termcap/curses should “just work” without too much issue. I like writing C, so I’d need a compiler. Now, I’m assuming this simplistic operating system would be entirely written in a combination of assembly language (to talk to hardware and handle specific tasks such as switching processes and privilege management and whatnot) and C (to handle most of the logic and ABI). I could probably cross-compile GCC and be good to go, aside from handling library paths and executable formats that don’t comply with POSIX (I have no intention of making yet another UNIX-like system). Hopefully, most other command-line software (that I actually use) will follow suit without too much trouble. I don’t know how much work it is to get Python or Lua to a new platform (though NetBSD on the 68K already supports both), but Python (or Lua) support would bring a lot of flexibility to the platform. Despite me being a Python hater, I must admit it’s quite an attractive addition.

What about graphics? All the software I’ve mentioned so far is text-mode only, yet historical 68K-based systems like the Mac and Amiga had beautiful graphics! Implementing X11 would be a massive pain in the ass, considering how much it relies on UNIXy features like sockets (not to mention the memory usage), and I really don’t want Wayland to have anything to do with this. I guess I’d have to roll my own graphics stack and window manager to support a WIMP interface. I could copy Apple’s homework there: they also made a monochrome graphics interface for a M68K configured with a handful of MiB of RAM. I could probably get a simple compositing window manager (perhaps make it tiling for a modern vibe ;3). Overall, outside of very simple and custom applications, functionality with real software would be problematic. Is that a big problem? Maybe I want an underpowered notebook I can put ideas and simple scripts down on, then flesh them out more fully later on. An operating system allowing more direct access to the hardware, plus direct framebuffer access, could yield some pretty cool graphing/basic design utility.

I’d need a way to communicate with the outside world. An RS-232 UART interface, similar to the HP-48 calculator (or the TI-92’s GraphLink, only less proprietary) would help for providing a remote machine language monitor in the early stages, and a real link to a more powerful (and networked) machine later on. I think real networking would defeat the purpose of the machine — to provide a way to remove yourself from modern technology and hardware, while retaining portability, reliability, and efficiency of modern semiconductor manufacturing techniques. Giving it a CF or SD slot could provide a nice way to move files around between it and a computer, maybe providing software patches. A floppy drive would be amazing: it would provide a way to store code and text, and would be just about the right storage size for what I want to do. Unfortunately, there’s not really a good way to maintain the size of the laptop while sticking a 3.5” (or worse, 5.25”) floppy drive in the middle of it. To my knowledge, 3.5” floppy drives never got thin enough to properly fit with all the other expansion slots, socketed components, and user-modifiable parts I’d want. A completely solid-state design would likely be the best option.

Anyway, uhh… I hope this made some semblance of sense and I don’t sound insane for going on a rant about building a modern computer with a 1979 CPU.

[ui-alcoholic]

Sinclair QL (1984)

The Sinclair QL (for Quantum Leap) is a personal computer launched by Sinclair Research in 1984, as an upper-end counterpart to the ZX Spectrum.

Based on a Motorola 68008 processor clocked at 7.5 MHz, the QL included 128 KiB of RAM, which is officially expandable to 640 KiB and in practice, 896 KB.

It can be connected to a monitor or TV for display. Sinclair recommended the "SINCLAIR VISION-QL" RGB monitor for usage with the QL. When connected to a normally-adjusted TV or monitor, the QL's video output overscans horizontally. This is reputed to have been due to the timing constants in the ZX8301 chip being optimised for the flat-screen CRT display originally intended for the QL.

Two video modes are available, 256 × 256 pixels with 8 primary RGB colours and per-pixel flashing, or 512 × 256 pixels with four colours: black, red, green and white.

Development

The QL was conceived in 1981 under the code name ZX83 as a portable computer for business users. It had a built-in ultra-thin flat-screen CRT display similar to the later TV80 pocket TV, printer, and modem. As development progressed, it eventually became clear that the portability features were overambitious, and the specification was reduced to a conventional desktop configuration.

The electronics were primarily designed by David Karlin, who joined Sinclair Research in summer 1982. The industrial design was done by Rick Dickinson, who already designed the ZX81 and ZX Spectrum range of products.

The QL was designed to be more powerful than the IBM Personal Computer, and comparable to Apple's Macintosh. While the CPU clock speed is similar to that of the Macintosh, and the later Atari ST and Amiga, the 8-bit databus and cycle stealing of the ZX8301 gate array limit the QL's performance.

Sinclair had commissioned GST Computer Systems to produce the operating system for the machine, but switched to QDOS, developed by Tony Tebby as an in-house alternative, before launch. GST's OS, designed by Tim Ward, was later made available as 68K/OS, in the form of an add-on ROM card. The tools developed by GST for the QL would later be used on the Atari ST, where GST object format became standard.

[vadapega]

Was asked about the Cave Story transition effect, wether or not it can work on the SEGA Mega Drive / Genesis, here's an attempt at it.

Read more for an indepth explanation why this isn't so easy and why it still looks weird:

So the backstory was that, as I was watching someone play a bit of this Cave Story homebrew for the Mega Drive, we've noticed that all transitions were palette fades rather than the usual Diamond effect, and so I explained why the effect is much harder to pull off than one would expect it:

This is the animation itself, 16 frames in length repeated for the whole screen, rather simple and something you might(?) expect from an older game but in reality it's a lot more difficult to pull off.

If it were a 8x8 sized animation, this wouldn't be a big issue, you'd just write over every single tile in VRAM for the tileset and fill it in, no problem, Streets of Rage does this in the credits sequence and title as a fade in.

But since we're dealing with a 16x16 pattern, we cna't do this, at least not without curating the tilemap to be friendly for such an effect, which would limit map editing a lot.

So we have another choice, which is to sacrifice one of the available layers for the transition alone. One could sacrifice one of the tilemap layers but unless the other layer's already filling the screen, this would be too noticeable. One could fade the colours for that layer in particular and then overwrite it with the tiles, but ya may as well be doing a full fade at that point, especially if you're intending to use more than one palette for the layers... so i went with an even worse solution: Sprites.

As it turns out, you can just barely fit an entire screen with just sprites, the biggest size you can have is 32x32 and it takes 80 of them to fill the entire 320x224 (NTSC) / 320x240 (PAL) screen area.

The sprite limit is exactly 80 sprites so the sprite table will be filled up with just the transition effect alone.

Now one might think "Hey, the sprite limit for any given horizontal line is 20 sprites and it only takes 10 sprites to fill the screen horizontally, can't we just move the sprites vertically every 32nd scanline? I thought of that too! but there's unfortunately another limit, a Sprite pixel limit.

You can only have 320px of sprites at any given horizontal line, meaning even with free slots, there are too many sprites already on screen so this isn't going to work, there's no way around it.

Now, one could swap between a 16x16 sized version during the start and swap to the 32x32 sized ones after hitting the threshhold to bypass this issue... quite honestly I didn't think of that at the time, it would halve the px limit and should make it near seamless, definitely something I'd like to workshop in the future!

Sure, all sprites will disappear halfway through the transition, but at that point most of the view will already be blocked by the effect so you're ideally not going to notice this happening.

EDIT : Only now am I told that Cave Story has different kinds of transitions depending on doorways and such, maybe giving me more than just the file for the transition for context for someone who didn't grow up playing Cave Story would be nice x.x

[techav]

On Celebrating Errors

Isn't it beautiful? The lovely formatted tables of register and stack contents, the trace of function addresses and parameters, the error message ... it's the most beautiful kernel panic I have ever seen.

Why on earth would I be so excited to see a computer crash? What could possibly be beautiful about a kernel panic?

This kernel panic is well-earned. I fought hard to get it.

This kernel panic came from a current NetBSD kernel, freshly compiled and running on Wrap030, my 68030 homebrew computer. It is the result of hours upon hours of work reading through existing code, scattered documentation and notes, writing and rewriting, and endless compiling.

And it's just the start.

As I've said before, a goal of this project has always been to build something capable of running some kind of Unix-like operating system. Now that I finally have all the necessary pieces of hardware, plus a good bootloader in ROM, it's time to give it a shot. I'm not that great with this type of programming, but I have been getting better. I might just be able to brute force my way through hacking together something functional.

It is hard.

There is some documentation available. The man(9) pages are useful, and NetBSD has a great guide to setting up the build environment for cross-compiling the kernel. There are some published papers on what some people went through to port NetBSD to this system or that. But there's nothing that really explains what all these source code files are, and which parts really need to be modified to run on a different system.

I had a few false starts, but ultimately found an existing 68k architecture, cesfic, which was a bare minimum configuration that could serve well as a foundation for my purposes. I copied the cesfic source directory, changed all instances of the name to wrap030, made sure it still compiled, then set about removing everything that I didn't need. It still compiled, so now it's was time to add in what I did need.

... how ... do I ... ?

This is where things get overwhelming very quickly. There is documentation on the core functions required for a new driver, there's documentation on the autoconf system that attaches drivers to devices in the tree, and there's plenty of drivers already to reference. But where to start?

I started by trying to add the com driver for the 16550 UARTs I'm using. It doesn't compile because I'm missing dependencies. The missing functions are missing because of a breaking change to bus.h at some point; the com driver expects the new format but the cesfic port still uses the old. So I needed to pull in the missing functions from another m68k arch. Which then required more missing functions and headers to be pulled in. Eventually it compiled without error again, but that doesn't mean it will actually run. I still needed to add support for my new programmable timer, customize the startup process, update hardware addresses, make sure it was targeting 68030 instead of 68040 ...

So many parts and pieces that need to be updated. Each one requiring searching for the original function or variable declaration to confirm expected types or implementation, then searching for existing usages to figure out what it needs ... which then requires searching for more functions and variable types.

But I got something that at least appeared to have all the right parts and compiled without error. It was time to throw it on a disk, load it up, and see what happened.

Nothing happened, of course. It crashed immediately.

I have no debugging workflow I can rely on here, and at this stage there isn't even a kernel console yet. All I could do was add little print macros to the locore startup code and see where it failed. Guess, test, and revise.

I spent a week debugging the MMU initialization. If the MMU isn't properly configured, everything comes to an abrupt halt. Ultimately, I replaced the cesfic machine-specific initialization code and pmap bootstrapping code with functions from yet another m68k arch. And spent another day debugging before realizing I had missed a section that had comments suggesting it wasn't for the 68030 CPU, but turned out to be critical for operation of kernel memory allocation.

Until this point, I was able to rely on the low-level exception handling built into my bootloader if my code caused a CPU exception. But with the MMU working, that code was no longer mapped.

So then came another few hours learning how to create a minimal early console driver. An early console is used by the kernel prior to the real console getting initialized. In this case, I'm using the MC6850 on my mainboard for the early console, since that's what my bootloader uses. And finally the kernel was able to speak for itself.

It printed its own panic.

The first thing the kernel does is initialize the console. Which requires that com driver and all the machine-specific code I had to write. The kernel is failing at its step #1.

But at least it can tell me that now. And given all the work necessary to get to this point, that kernel panic data printing to the terminal is absolutely beautiful.

[orbofrommyshows]

This is probably just full programmer projection but how pissed do you think Turbo was when fifth gen games started rolling into the arcade? Guy takes all this time to learn code and learn the different assembly languages like z80 and 6502 and maybe even m68k and he's probably reaching a point where he thinks he has it all figured out.

And then around the mid-ish 90s games along the same vein as Sugar Rush start coming out.

And now not only are they running on an assembly language Turbo had probably not seen before (MIPS), but they're also being programmed mostly in C, a completely different language that he will be learning for the first time without the help of any book or reference cards.

And so now he's almost worse off, because not only does he have to juggle figuring out which MIPS opcodes are the same and which opcodes are different from the previous assembly languages he learned (and handling 32 bit architecture) but now he's also gotta learn what inline embedding is and how to do it in a language he is only now encountering.

Oh to be a fly on the wall (or bug in the code lmao) when he was dealing with that.

[identifying-computers-in-posts]

Today in Computer History (01/24/2024):

On this day forty years ago, Apple Computers released the first All-In-One PC with a GUI to see mass-market success. The Macintosh (later called the Macintosh 128k or the “thin Mac”) was equipped with an m68k microprocessor, 128 kilobytes of ram, a 9” 512x342px CRT display, and a single 3.5” floppy drive, all housed in a beige box.

The commercial for the Macintosh, directed by Ridley Scott, was titled “1984” and aired during Super Bowl XVIII two days before launch (watch it here!). The computer also came with a keyboard and single-button mouse. It sold over 70,000 units within the first one hundred days of being available.

Read about the benefits of Apple Computers introduction to GUI and more about the Thin Mac here and here!

[this-week-in-rust]

This Week in Rust 526

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @ThisWeekInRust on Twitter or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community

Official

Blog: Launching the 2023 State of Rust Survey Survey

A Call for Proposals for the Rust 2024 Edition

Project/Tooling Updates

ratatui: a Rust library for cooking up terminal user interfaces - v0.25.0

Introducing Gooey: My take on a Rusty GUI framework

Two New Open Source Rust Crates Create Easier Cedar Policy Management

Introducing FireDBG - a Time Travel Visual Debugger for Rust

Fornjot 0.48.0 - open source b-rep CAD kernel written in Rust

Committing to Rust for kernel code

A Rust implementation of Android's Binder

Preventing atomic-context violations in Rust code with klint

Rust for Linux — in space

Observations/Thoughts

Rust is growing

A curiously recurring lifetime issue

The rabbit hole of unsafe Rust bugs

Faster Rust Toolchains for Android

The Most Common Rust Compiler Errors as Encountered in RustRover: Part 1

Nine Rules for SIMD Acceleration of your Rust Code (Part 2): General Lessons from Boosting Data Ingestion in the range-set-blaze Crate by 7x

What I Learned Making an embedded-hal Driver in Rust (for the MAX6675 Thermocouple Digitizer)

Rust Walkthroughs

Rust: Traits

Write a Toy VPN in Rust

Getting Started with Actix Web in Rust

Getting Started with Rocket in Rust

Generic types for function parameters in Rust 🦀

Benchmarking Rust Compiler Settings with Criterion: Controlling Criterion with Scripts and Environment Variables

[series] Multithreading and Memory-Mapping: Refining ANN Performance with Arroy

[series] Getting started with Tiny HTTP building a web application in Rust

Miscellaneous

Embedded Rust Education: 2023 Reflections & 2024 Visions

The Most Common Rust Compiler Errors as Encountered in RustRover: Part 1

Default arguments for functions in Rust using macros

[audio] Rust in Production Ep 1 - InfluxData's Paul Dix

[audio] Episode 160: Rust & Safety at Adobe with Sean Parent

Crate of the Week

This week's crate is constcat, a std::concat!-replacement with support for const variables and expressions.

Thanks to Ross MacArthur for the self-suggestion!

Please submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

Ockam - Fix documentation warnings

Ockam - Library - Validate CBOR structs according to the cddl schema for nodes/models/secure_channel

Ockam - Implement events in SqlxDatabase

Hyperswitch - [REFACTOR]: [Nuvei] MCA metadata validation

Hyperswitch - [FEATURE] : [Noon] Sync with Hyperswitch Reference

Hyperswitch - [FEATURE] : [Zen] Sync with Hyperswitch Reference

Hyperswitch - [REFACTOR] : [Authorizedotnet] Sync with Hyperswitch Reference

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from the Rust Project

386 pull requests were merged in the last week

enable stack probes on aarch64 for LLVM 18

add new tier 3 aarch64-apple-watchos target

add hexagon support

add the function body span to StableMIR

allow async_fn_in_trait traits with Send variant

cherry-pick "M68k: Fix ODR violation in GISel code (#72797)"

AIX: fix XCOFF metadata

-Ztrait-solver=next to -Znext-solver

actually parse async gen blocks correctly

add a method to StableMIR to check if a type is a CStr

add more suggestions to unexpected cfg names and values

add support for --env on tracked_env::var

add unstable -Zdefault-hidden-visibility cmdline flag for rustc

annotate panic reasons during enum layout

attempt to try to resolve blocking concerns (RFC #3086)

avoid overflow in GVN constant indexing

cache param env canonicalization

check FnPtr/FnDef built-in fn traits correctly with effects

check generic params after sigature for main-fn-ty

collect lang items from AST, get rid of GenericBound::LangItemTrait

coroutine variant fields can be uninitialized

coverage: skip instrumenting a function if no spans were extracted from MIR

deny ~const trait bounds in inherent impl headers

desugar yield in async gen correctly, ensure gen always returns unit

don't merge cfg and doc(cfg) attributes for re-exports

erase late bound regions from Instance::fn_sig() and add a few more details to StableMIR APIs

fix ICE ProjectionKinds Deref and Field were mismatched

fix LLD thread flags in bootstrap on Windows

fix waker_getters tracking issue number

fix alignment passed down to LLVM for simd_masked_load

fix dynamic size/align computation logic for packed types with dyn trait tail

fix overlapping spans in delimited meta-vars

ICE 110453: fixed with errors

llvm-wrapper: adapt for LLVM API changes

make IMPLIED_BOUNDS_ENTAILMENT into a hard error from a lint

make exhaustiveness usable outside of rustc

match lowering: Remove the make_target_blocks hack

more expressions correctly are marked to end with curly braces

nudge the user to kill programs using excessive CPU

opportunistically resolve region var in canonicalizer (instead of resolving root var)

properly reject default on free const items

remove unnecessary constness from ProjectionCandidate

replace some instances of FxHashMap/FxHashSet with stable alternatives (mostly in rustc_hir and rustc_ast_lowering)

resolve: replace visibility table in resolver outputs with query feeding

skip rpit constraint checker if borrowck return type error

some cleanup and improvement for invalid ref casting impl

tweak short_ty_string to reduce number of files

unconditionally register alias-relate in projection goal

update FreeBSD CI image

uplift TypeAndMut and ClosureKind to rustc_type_ir

use if cfg! instead of #[cfg]

use the LLVM option NoTrapAfterNoreturn

miri: visit the AllocIds and BorTags in borrow state FrameExtra

miri run: default to edition 2021

miri: make mmap not use expose semantics

fast path for declared_generic_bounds_from_env

stabilize type_name_of_val

stabilize ptr::{from_ref, from_mut}

add core::intrinsics::simd

add a column number to dbg!()

add more niches to rawvec

add ASCII whitespace trimming functions to &str

fix cases where std accidentally relied on inline(never)

Windows: allow File::create to work on hidden files

std: add xcoff in object's feature list

codegen: panic when trying to compute size/align of extern type

codegen_gcc: simd: implement missing intrinsics from simd/generic-arithmetic-pass.rs

codegen_llvm: set DW_AT_accessibility

cargo: clean up package metadata

cargo: do not allow empty name in package ID spec

cargo: fill in more empty name holes

cargo: hold the mutate exclusive lock when vendoring

rustdoc: use Map instead of Object for source files and search index

rustdoc: allow resizing the sidebar / hiding the top bar

rustdoc-search: fix a race condition in search index loading

rustdoc-search: use set ops for ranking and filtering

bindgen: use \r\n on windows

bindgen: better working destructors on windows

clippy: add new unconditional_recursion lint

clippy: new Lint: result_filter_map / Mirror of option_filter_map

clippy: don't visit nested bodies in is_const_evaluatable

clippy: redundant_pattern_matching: lint if let true, while let true, matches!(.., true)

clippy: do not lint assertions_on_constants for const _: () = assert!(expr)

clippy: doc_markdown Recognize words followed by empty parentheses () for quoting

clippy: fix binder handling in unnecessary_to_owned

rust-analyzer: deduplicate annotations

rust-analyzer: optimizing Performance with Promise.all 🏎

rust-analyzer: desugar doc correctly for mbe

rust-analyzer: dont assume ascii in remove_markdown

rust-analyzer: resolve alias before resolving enum variant

rust-analyzer: add minimal support for the 2024 edition

rust-analyzer: move out WithFixture into dev-dep only crate

rust-analyzer: fix false positive type mismatch in const reference patterns

rust-analyzer: syntax fixup now removes subtrees with fake spans

rust-analyzer: update builtin attrs from rustc

rust-analyzer: fix fragment parser replacing matches with dummies on incomplete parses

rust-analyzer: fix incorrectly replacing references in macro invocation in "Convert to named struct" assist

Rust Compiler Performance Triage

A lot of noise in the results this week; there was an lull in the noise recently, so our auto-inferred noise threshold went down, and thus five PR's were artificially flagged this week (and three supposed improvements were just reverting to the mean). Beyond that, we had three nice improvements: the first to debug builds in #117962 (by ceasing emission of expensive+unused .debug_pubnames and .debug_pubtypes), a second to diesel and serde in #119048 (by avoiding some unnecessary work), and a third to several benchmarks in #117749 (by adding some caching of an internal compiler structure).

Triage done by @pnkfelix. Revision range: 57010939..bf9229a2

6 Regressions, 9 Improvements, 3 Mixed; 5 of them in rollups 67 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs

[disposition: postpone] RFC: Precise Pre-release Deps

Tracking Issues & PRs

[disposition: merge] Support async recursive calls (as long as they have indirection)

[disposition: merge] make soft_unstable show up in future breakage reports

[disposition: merge] Tracking Issue for ip_in_core

Language Reference

No Language Reference RFCs entered Final Comment Period this week.

Unsafe Code Guidelines

No Unsafe Code Guideline RFCs entered Final Comment Period this week.

New and Updated RFCs

RFC: patchable-function-entry

Call for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. The following RFCs would benefit from user testing before moving forward:

No RFCs issued a call for testing this week.

If you are a feature implementer and would like your RFC to appear on the above list, add the new call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Upcoming Events

Rusty Events between 2023-12-20 - 2024-01-17 🦀

Virtual

2023-12-20 | Virtual (Vancouver, BC, CA) | Vancouver Rust

Adventures in egui app dev

2023-12-26 | Virtual (Dallas, TX, US) | Dallas Rust

Last Tuesday

2023-12-28 | Virtual (Charlottesville, NC, US) | Charlottesville Rust Meetup

Crafting Interpreters in Rust Collaboratively

2024-01-03 | Virtual (Indianapolis, IN, US) | Indy Rust

Indy.rs - with Social Distancing

2024-01-09 | Virtual (Dallas, TX, US) | Dallas Rust

Last Tuesday

2024-01-11 | Virtual (Charlottesville, NC, US) | Charlottesville Rust Meetup

Crafting Interpreters in Rust Collaboratively

2024-01-16 | Virtual (Washington, DC, US) | Rust DC

Mid-month Rustful

Europe

2023-12-27 | Copenhagen, DK | Copenhagen Rust Community

Rust hacknight #1: CLIs, TUIs and plushies

2023-12-28 | Vienna, AT | Rust Vienna

Rust Dojo 3: Holiday Edition

2024-01-11 | Reading, UK | Reading Rust Workshop

Reading Rust Meetup at Browns

2024-01-11 | Wrocław, PL | Rust Wrocław

Rust Meetup #36

2024-01-13 | Helsinki, FI | Finland Rust-lang Group

January Meetup

North America

2023-12-20 | Austin, TX, US | Rust ATX

Rust Lunch - Fareground

2023-12-27 | Austin, TX, US | Rust ATX

Rust Lunch - Fareground

2024-01-06 | Boston, MA, US | Boston Rust Meetup

Beacon Hill Rust Lunch

2024-01-08 | Chicago, IL, US | Deep Dish Rust

Rust Hack Night

2024-01-09 | Seattle, WA, US | Cap Hill Rust Coding/Hacking/Learning

Rusty Coding/Hacking/Learning Night

2024-01-09 | Minneapolis, MN, US | Minneapolis Rust Meetup

Minneapolis Rust Meetup Happy Hour

2024-01-14 | Cambridge, MA, US | Boston Rust Meetup

Alewife Rust Lunch

2024-01-16 | San Francisco, CA, US | San Francisco Rust Study Group

Rust Hacking in Person

2024-01-17 | Chicago, IL, US | Deep Dish Rust

Rust Happy Hour

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

The Tianyi-33 satellite is a 50kg class space science experimental satellite equipped with an operating system independently developed by Beijing University of Posts and Telecommunications—the Rust-based dual-kernel real-time operating system RROS. RROS will carry out general tasks represented by tensorflow/k8s and real-time tasks represented by real-time file systems and real-time network transmission on the satellite. It will ensure the normal execution of upper-layer applications and scientific research tasks, such as time-delay measurement between satellite and ground, live video broadcasting, onboard web chat services, pseudo-SSH experiments, etc. This marks the world’s first official application of a Rust-written dual-kernel operating system in a satellite scenario.

– Qichen on the RROS web page

Thanks to Brian Kung for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, mariannegoldin, bennyvasquez.

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

[archiveosorg]

AROS Vision

AROS Vision – the AROS Vision distribution is aimed at Amiga M68k users https://archiveos.org/aros-vision/

[ui-alcoholic]

Amiga 1000

The Amiga1000 was introduced in the summer of 1985 and was the first machine in the Amiga family. Commodore acquired the technology through the acquisition of the Amiga company, which was originally developed by engineers Jay Miner and Larry Kaplan who had left Atari.

The goal was to develop a gaming platform with graphics and sound capabilities ahead of its time. This goal was achieved, but in the process, they created a complete computer instead of a game console.

The technical side of things went well enough, but financial problems meant they had to look for an investor, and ended up with Commodore.

The Amiga 1000 was a true multimedia computer. The 7MHz Motorola 68000 (PAL/7.09MHz PAL NTSC/7.16MHz) and 256kB of memory were roughly equivalent to those offered by the competition. In contrast, the 8-bit stereo sound and outstanding color graphics were well ahead of its contemporaries. However, neither the PC, Atari ST, nor even the Apple Macintosh had a multitasking operating system (AmigaOS). (although until the advent of faster machines, this was a disadvantage rather than an advantage) Read more about the story here: Geekometery - Jay Miner & The Amiga Computer

Check these out too if you are interested in retro computing

the iconic "Amiga ball" which seemed like a fantastic thing at the time.

A1000 cover sheet signed by the team members

A1000 in the Stranger Things 4

[vadapega]

My screen's been looking like this for the past Month, help.

[mipseb]

m68k has linux support but since it was probably an m68000 I see why Linux was used. We had Gentoo installed onto an Mac 190(?) laptop the boot time was six hours.

Linux on a PSP :3

[retrocomp-blog]

SEGA Genesis (Mega Drive) - I used to own one. An excellent 16-bit gaming machine comparable to the Amiga 500 (both also use the same legendary microprocessor Motorola 68000).

[this-week-in-rust]

This Week in Rust 491

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @ThisWeekInRust on Twitter or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community

Foundation

Rust Trademark Policy Draft Revision – Next Steps

Project/Tooling Updates

Nutype v0.2

Announcing tuxedo-rs

rust-analyzer changelog #177

Observations/Thoughts

Improving build times for derive macros by 3x or more

Oxidizing bmap-tools: rewriting a Python project in Rust

Rust: A New Attempt at C++'s Main Goal

Traits are more than interfaces

Optional If Expressions

Building a GStreamer plugin in Rust with meson instead of cargo

Rutie and Magnus, Two Good Ways to Build Ruby Extensions in Rust

Two Rust features that I miss in Other languages

[audio] Rust Analyzer with Lukas Wirth

[audio] Wasmer with Syrus Akbary

Rust Walkthroughs

Understanding Rust Thread Safety

how to run rust code on a circuit playground classic / atmega32u4

Hello World in Rust for m68k with #[no_core] and compiler patches

A syntax-level async join macro supporting branching control flow and synchronous shared mutable borrowing

Build a Lua Interpreter in Rust (English version)

[CN] Zino's implementation of an error type with tracing functionalities using 100 lines of code

Miscellaneous

Introducing Shuttle Batch 2.0

The Rust Foundation's draft trademark policy is far too restrictive

[video] Rust Trademark: Argle-bargle or Foofaraw?

Crate of the Week

This week's crate is onlyerror, a #[derive(Error)] macro with support for no_std on nightly compilers.

Thanks to Jay Oster for the self-suggestion!

Please submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

Quickwit - Upgrade clap from 3.1 to 4.0

Quickwit - Implement quickwit dataset CLI command

Hyperswitch - Migrate to enum_dispatch to reduce runtime overhead

Hyperswitch - move redis key creation to a common module

Hyperswitch - add connector_label field in error type

Ockam - Update ockam status --all to list more of the available resources

Ockam - Remove rustcrypto feature from ockam_vault

Ockam - Create Github Action to update Ockam Command Manual

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from the Rust Project

450 pull requests were merged in the last week

initial support for loongarch64-unknown-linux-gnu

add inline assembly support for m68k

make rust-intrinsic ABI unwindable

allow repr(align = x) on inherent methods

add a backtrace to Allocation, display it in leak reports

add a message for if an overflow occurs in core::intrinsics::is_nonoverlapping

add suggestion to remove derive() if invoked macro is non-derive

added diagnostic for pin! macro in addition to Box::pin if Unpin isn't implemented

assemble Unpin candidates specially for generators in new solver

check for body owner fallibly in error reporting

correct default value for default-linker-libraries

emits non-overlapping suggestions for arguments with wrong types

encode def span for ConstParam

erase lifetimes above ty::INNERMOST when probing ambiguous types

erase regions when confirming transmutability candidate

fix false positives for unused_parens around unary and binary operations

fix transmute intrinsic mir validation ICE

fix: ensure bad #[test] invocs retain correct AST

fix: skip implied bounds if unconstrained lifetime exists

improve safe transmute error reporting

improve the error message when forwarding a matched fragment to another macro

incr.comp.: make sure dependencies are recorded when feeding queries during eval-always queries

preserve argument indexes when inlining MIR

reformulate point_at_expr_source_of_inferred_type to be more accurate

report overflows gracefully with new solver

resolve: pre-compute non-reexport module children

tweak output for 'add line' suggestion

suggest lifetime for closure parameter type when mismatch

support safe transmute in new solver

add a stable MIR way to get the main function

custom MIR: Support BinOp::Offset

switch to EarlyBinder for impl_subject query

tagged pointers, now with strict provenance!

alloc hir::Lit in an arena to remove the destructor from Expr

only emit alignment checks if we have a panic_impl

only enable ConstProp at mir-opt-level >= 2

permit MIR inlining without #[inline]

rustc_metadata: Filter encoded data more aggressively using DefKind

stabilize IsTerminal

don't splice from files into pipes in io::copy

sync::mpsc: synchronize receiver disconnect with initialization

windows: map a few more error codes to ErrorKind

hashbrown: remove drain-on-drop behavior from DrainFilter

regex: first phase of migrating to regex-automata

cargo: change -C to be unstable

cargo: stabilize cargo logout

cargo: use registry.default for login/logout

cargo: use restricted Damerau-Levenshtein algorithm

rustdoc-search: add support for nested generics

rustdoc: correctly handle built-in compiler proc-macros as proc-macro and not macro

stabilize rustdoc --test-run-directory

clippy: collection_is_never_read: Handle unit type

clippy: add manual_slice_size_calculation applicable suggestion

clippy: clear with drain

clippy: fix false positives and false negatives in octal_escapes

clippy: suggest std::mem::size_of_val instead of std::mem::size_of_value

rust-analyzer: don't suggest unstable items on stable toolchain

rust-analyzer: make inlay hints insertable

rust-analyzer: map tokens from include! expansion to the included file

rust-analyzer: fix allow extracting function from single brace of block expression

rust-analyzer: fix explicit deref problems in closure capture

rust-analyzer: bring back LRU limit for macro_expand query

rust-analyzer: fix inference in nested closures

rust-analyzer: fix inverted code lens resolve file version check

rust-analyzer: fix receiver adjustments for extract_variable assist

rust-analyzer: infer types of nested RPITs

rust-analyzer: when running the "discoverProjectCommand", use the Rust file's parent directory instead of the workspace folder

rust-analyzer: parse more exclusive range patterns and inline const patterns

Rust Compiler Performance Triage

A busy two weeks (as last week perf triage was not done). Overall improvements outweigh regressions with an average improvement of -2.6% across a large swath of the test cases. Of particular note was the move to use SipHash-1-3 instead of SipHash-2-4 for StableHasher which improved 184 benchmark tests by an average of 2.3%!

Triage done by @rylev. Revision range: 7c96e40..74864f

Summary:

(instructions:u) mean range count Regressions ❌ (primary) 3.1% [0.2%, 24.4%] 11 Regressions ❌ (secondary) 4.9% [0.4%, 37.4%] 32 Improvements ✅ (primary) -2.9% [-20.4%, -0.3%] 205 Improvements ✅ (secondary) -4.0% [-43.5%, -0.3%] 160 All ❌✅ (primary) -2.6% [-20.4%, 24.4%] 216

6 Regressions, 8 Improvements, 11 Mixed; 6 of them in rollups 119 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs

No RFCs entered Final Comment Period this week.

Tracking Issues & PRs

[disposition: merge] Update the version of musl used on *-linux-musl targets to 1.2.3

[disposition: merge] Tracking Issue for debugger_visualizer

New and Updated RFCs

[new] Use actions/deploy-pages to deploy mdbook output

[new] RFC for associated mathematical constants

[new] improve #[may_dangle] for type parameters

[new] RFC: Cargo feature descriptions & metadata

[new] RFC: Rustdoc configuration via Cargo

[new] Traits for lossy conversions

[new] Split may_dangle and make PhantomData less weird

Call for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. The following RFCs would benefit from user testing before moving forward:

1.69.0 pre-release testing

If you are a feature implementer and would like your RFC to appear on the above list, add the new call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Upcoming Events

Rusty Events between 2023-04-19 - 2023-05-17 🦀

Virtual

2023-04-19 | Virtual (Vancouver, BC, CA) | Vancouver Rust

Kaskada, Rust and Apache Arrow

2023-04-20 | Virtual (Munich, DE) | Rust Munich

Rust Munich 2023 / 2 - hybrid

2023-04-20 | Virtual (Stuttgart, DE) | Rust Community Stuttgart

Rust-Meetup

2023-04-25 | Virtual (Dallas, TX, US) | Dallas Rust

Last Tuesday

2023-04-26 | Virtual (Cardiff, UK) | Rust and C++ Cardiff

Rust-friendly websites and web apps

2023-04-27 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup

Testing Tock, how unit tests in Rust improve and teach

2023-04-27 | Copenhagen, DK | Copenhagen Rust Community

Rust meetup #35 at Google Cloud

2023-04-29 | Virtual (Nürnberg, DE) | Rust Nuremberg

Deep Dive Session 3: Protohackers Exercises Mob Coding (as far as we get)

2023-05-02 | Virtual (Buffalo, NY, US) | Buffalo Rust Meetup

Buffalo Rust User Group, First Tuesdays

2023-05-03 | Virtual (Indianapolis, IN, US) | Indy Rust

Indy.rs - with Social Distancing

2023-05-09 | Virtual (Dallas, TX, US) | Dallas Rust

Second Tuesday

2023-05-11 | Virtual (Nürnberg, DE) | Rust Nuremberg

Rust Nürnberg online

2023-05-13 | Virtual | Rust GameDev

Rust GameDev Monthly Meetup

2023-05-16 | Virtual (Washington, DC, US) | Rust DC

Mid-month Rustful—Introducing duplicate! and the peculiarities of proc macros

2023-05-17 | Virtual (Cardiff, UK) | Rust and C++ Cardiff

Rust Atomics and Locks Book Club Chapter 2

2023-05-17 | Virtual (Vancouver, BC, CA) | Vancouver Rust

Rust Study/Hack/Hang-out

Europe

2023-04-19 | Paris, FR | Rust Paris

Rust Paris meetup #58

2023-04-19 | Trondheim, NO | Rust Trondheim

Rust Embedded with MicroBit:V2

2023-04-19 | Zurich, CH | Rust Zurich

sett: data encryption and transfer made easy(ier)

2023-04-20 | Aarhus, DK | Rust Aarhus

Rust Aarhus meetup #1 at Geanix

2023-04-20 | Munich, DE + Virtual | Rust Munich

Rust Munich 2023 / 2 - hybrid

2023-04-20 | Bern, CH | Rust Bern

First Rust Bern Meetup!

2023-04-21 | Stuttgart, DE | Rust Community Stuttgart

OnSite Meeting

2023-04-26 | London, UK | Rust London User Group

Rust Hack & Learn April 2023

2023-04-27 | Bordeaux, FR | DedoTalk

#2 DedoTalk 🎙️ : Comment tester son code Rust?

2023-04-27 | Vienna, AT | Rust Vienna

Rust Vienna - April - Hosted by Sentry

2023-05-02 | Amsterdam, NL | Rust Developers Amsterdam Group

Fiberplane Rust Workshop

2023-05-10 | Amsterdam, NL | RustNL

RustNL 2023

North America

2023-04-19 | Austin, TX, US | Rust ATX

Rust Lunch

2023-04-19 | Minneapolis, MN, US | Minneapolis Rust Meetup

Happy Hour and Beginner WASM Rust Hacking Session (#2!)

2023-04-20 | Mountain View, CA, US | Mountain View Rust Study Group

Rust Meetup at Hacker Dojo

2023-04-29 | Durham, NC, US | Triangle Rust

Rust Social / Coffee Chat at Boxyard RTP

2023-05-11 | Lehi, UT, US | Utah Rust

Upcoming Event

2023-05-16 | San Francisco, CA, US | San Francisco Rust Study Group

Rust Hacking in Person

Oceania

2023-04-27 | Brisbane, QLD, AU | Rust Brisbane

April Meetup

2023-05-03 | Christchurch, NZ | Christchurch Rust Meetup Group

Christchurch Rust meetup meeting

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

Error types should be located near to their unit of fallibility.

– Sabrina Jewson on her blog

Thanks to Anton Fetisov for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, mariannegoldin, bennyvasquez.

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

[archiveosorg]

Apollo OS

Apollo OS – a m68k distribution, crafted specially for the Vampire V4 Standalone FPGA-based system. The ApolloOS system was build on the AROS https://archiveos.org/apolloos/

[gobusto]

"for now" 🤔

time to Publish My Research, i suppose:

SHUFFLE.COM = It is, the game. I Do Not Care™ about executable files, so I am not reverse-engineering this.

GRAPHUSC.CC1 = Contains 19 compressed graphics files for CGA (and Hercules). Uses big-endian integers for some reason; perhaps related to the existence of the (m68k) Amiga/Atari versions?

GRAPHUSE.CC1 = As above, but for EGA/Tandy.

SAMPLE.CC0 = Contains a single compressed item, as per an individual entry in a .CC1 file. No idea what this is for; the DOS version doesn't have sound (other than PC speaker beeps) AFAIK, so it's not that kind of "sample" at least.

CONFIG.TAT = Contains various strings and stuff related to each of the 4 video modes (CGA/EGA + Tandy/Hercules). Directly references SAMPLE.CC0 and the two .PXI files:

SHUFFLEC.PXI = idk, but probably related to CGA. Contains some interesting strings, such as SHUFFLC3.EXE (which does not exist).

SHUFFLEE.PXI = idk, but probably related to EGA. Contains some different strings, such as SHUFFLE3.EXE and SHUFFLT3.EXE (which also do not exist). I assume T = Tandy here.

i still need to actually decompress the items in the .CC1 (and .CC0) files, but will probably move on to looking at the Atari STe version -- which just has one big SHUFFLEP.UCK data file -- after that, since it does have music (and also the graphics are very slightly nicer).

a few weeks ago, i arbitrarily decided it would be fun to reverse-engineer Shufflepuck Cafe (tl;dr: Pong But With Blorbos) in order extract the graphics (and music?) from it.

but then 2 days later i coincidentally learned that @foone is apparently in the midst of reverse-engineering every Broderbund game ever made.

so now there is a fun time limit component to this apparently.