So what does it actually do?

Normal upscalers just stretch pixels, and the result looks soft and waxy. Magnific does something different. Where other tools try to recover likely detail, Magnific invents it, hallucinating pores, threads, foliage and surface grain. Sometimes that looks stunning. Sometimes it rewrites your picture completely, and that depends on how far you push it.

You control this with a “creativity” slider. Keep it low and the image stays close to the original. Push it high and the tool starts making its own decisions. Some people love that and some hate it, so I’d say try it on a test image before you commit anything important.

A quick bit of history

Magnific was built by two Spanish founders, Javi Lopez and Emilio Nicolas, and was founded in 2023 and acquired by Freepik in May 2024. Since then things have moved around a lot. According to one 2026 roundup, its billing, credits and AI tools now run through the Freepik account system. Another source says Freepik itself rebranded as Magnific in 2026, and a third says the old Freepik-era docs now redirect to magnific.com. The naming is confusing, I know. If you’re searching for the tool, expect to land on either site.

Where it works best

From what I’ve seen and read, it shines in a few places:

• AI art from Midjourney or similar tools that looks flat or smooth
• Illustrations and game assets
• 3D renders and architecture visuals
• Old, low-resolution photos you want to rescue

It’s weaker when you need faithful results. If you’re working with a logo, a product photo, or a screenshot with text, the invented detail can change things you didn’t want changed. For that, one comparison notes the Precision mode preserves text, logos and UI pixels faithfully, while Creative mode is the one that gets artistic with it. Pick the mode based on whether changed pixels would be a problem for you.

How big can you go?

Marketing says up to 16x. In real use, one reviewer puts the practical limit closer to 8x. Honestly, you rarely need more than 4x for most work. Past a certain point you’re just asking the AI to imagine things.

What does it cost?

This is the part that stings a bit. Magnific isn’t cheap. Access through Freepik has been tied to the Premium+ plan at $39 per month, and one review lists the cost at roughly $0.05 to $0.20 per upscale, depending on size and settings. Prices change often, so check the current page before you subscribe. If you only upscale a few images a month, the subscription is hard to justify.

A few tips if you try it

1. Start with the creativity slider low, then raise it slowly.
2. Use the prompt box. A short note like “fine painterly texture” can steer the result.
3. Don’t upscale to the maximum just because you can.
4. Always compare against the original. Zoom in and look at faces and hands first, since that’s where weird surprises hide.

The honest verdict

Magnific is the best option I know of for adding believable detail to AI art. It’s also pricey, a bit unpredictable, and not what you want for anything that has to stay exact. If your work is creative, it’s worth a month’s trial. If your work is product shots or documents, a faithful upscaler like Topaz Gigapixel will probably serve you better.

Keywords: Magnific AI, Magnific AI review, AI image upscaler, upscale AI images, Magnific AI pricing, Freepik Magnific, AI image enhancer, Midjourney upscaler

The headline for me was Meta’s Muse Spark Open. Meta released it on October 15, with 816 billion total parameters, 42 billion active parameters and a one-million-token context window

Those numbers sound abstract, so here’s what they mean:

• Open weights means developers can download the model, not just rent access to it through an API.

• Active parameters are the part of the model doing the work at any moment. Only a slice runs at a time, which keeps it efficient.

• A million-token context window means you can feed it a huge codebase or a pile of documents in one go.

This comes alongside Meta’s other launch this week. Muse Wonder and Muse Wonder Full were announced on October 12. Open weights are a separate track from those.

Why you should care: if you build websites, apps or tools, you now have more choices than “pay per token to one company.” You can test locally, keep your data on your own machine, and control costs.

2. NVIDIA is going after specialised agents

NVIDIA also made a move. Its October 15 release introduced Nemotron 3.5 Super VL, a 120-billion-parameter visual model with 12 billion active per token. It’s aimed at specialised agents, meaning AI that doesn’t just chat but looks at screens, images and documents and then does something with them.

3. Local AI is now a gadget category

AI hardware is getting personal. Amazon announced Bee Frontier, a wearable personal AI device, and Bee Eclipse, a magnetic phone attachment. Whether people will wear these every day is still an open question, but the direction is clear: AI that sits with you all day instead of living in a browser tab.

If you want to see this stuff in person, the Open Intelligence Foundation is running Open Source AI Week across the San Francisco Bay Area from October 16 to 25, with more than 60 community events, including an on-device AI hackathon. Many of these events are worth following online even if you can’t attend.

4. The uncomfortable part: agents are being used for attacks

Here’s where the news gets serious. Gambit Security detailed fully automated hacking services that use open-source AI tools to continuously attack hundreds of sites for relatively low per-attack costs. In plain words, attacks that once needed skilled people can now be run on autopilot, cheaply and at scale.

Companies are reacting. Security teams are rushing out playbooks, and a new RSA platform aims to discover, protect and govern AI agents in heavily regulated organisations. One startup, Opsin, raised a growth round to expand its product that maps agent ownership, permissions and runtime actions.

What this means for regular users and small site owners:

1. Update everything: CMS, plugins, frameworks. Automated attackers love old versions.

2. Use strong, unique passwords and 2FA, because credential theft is the easy target.

3. Give AI tools the minimum access they need. If an agent doesn’t need your email, don’t connect it.

4. Check your logs now and then. Odd traffic spikes are often the first sign.

5. Big Tech is spending like never before

One more number puts all this in context. Coverage from October 18 cites roughly $750 billion of 2026 capex, per Bloomberg Businessweek, from the largest tech companies. The same roundup reports that Microsoft dropped a deal to rent 23,000 Nvidia chips at a UK site run by Nscale. Even at this scale, compute is the scarce resource, and the companies are still shuffling who gets it.

So what should you do this week?

• Learners and students: try a small open model locally. Running one yourself teaches you more about how AI works than any article.

• Developers: look at open weights for projects where privacy or cost matters, but treat agent permissions as a security issue from day one.

• Site owners: patch, back up and turn on 2FA. It’s boring advice that works.

• Everyone else: be a little skeptical of “AI will do it all for you” claims, and stay curious.

Final thoughts

This week showed two sides of the same trend. Open and local AI is giving ordinary people and small teams real power. The same openness is lowering the cost of automated attacks. The people who do well will be the ones who learn the tools and also take safety seriously.

What was your favourite AI story this week? Let me know in the comments.

Microsoft released Windows 11 version 26H2 (also called the Windows 11 2026 Update) on September 29, 2026. It is a small update, not a big redesign. It arrives as an "enablement package" (KB5121794), so installing it feels like a normal monthly update: a small download and a restart.

Key facts:

• It works on PCs that already run Windows 11 version 25H2 or 24H2.

• PCs running version 26H1 cannot install it, because 26H1 is built on a newer platform.

• Installing it restarts the support clock. Reports say you get about 24 months of support on home editions and 36 months on business editions.

Why it matters for developers: If you build or test software on Windows, you do not need to worry about big compatibility problems. Microsoft describes this release as predictable and low-disruption. It is still smart to test on one machine first before updating all of your computers.

2. Apple HomeView: A $299 Smart Display With the New Siri

On October 13, 2026, Apple announced HomeView, a smart home display with a 7-inch touchscreen on a speaker base. It costs $299 in the US and goes on sale on November 13. There is a tabletop version and a wall-mounted version.

What it does:

• Controls lights, locks, thermostats and cameras.

• Makes FaceTime calls, plays music and video, and works as a digital photo frame.

• Uses face recognition so each family member sees their own home screen and widgets.

• Works with Matter and Thread smart home devices.

• Runs the new, more conversational "Siri AI". According to AFP, it is built on Google Gemini technology.

This is also one of the first big launches under Apple's new CEO John Ternus, who took over from Tim Cook on September 1.

Why it matters for designers and developers: HomeView shows a new kind of screen. The interface changes depending on how far away the person is standing, and it adapts to who is looking at it. If you study UI/UX, this is a great example of designing for different distances, different users and voice plus touch together.

3. AI Coding Agents Are Moving Into Your Daily Tools

AI coding helpers are no longer just chat boxes that suggest a line of code. They are becoming "agents" that can take a task, work on it and send back finished changes for you to review.

• At Microsoft Build 2026, GitHub introduced the GitHub Copilot app, a desktop app where developers can start, watch and guide several AI coding agents at once, then review and merge their work through normal pull requests.

• Earlier in 2026, GitHub added Claude and OpenAI Codex to its Agent HQ feature, so developers can choose different agents inside GitHub and VS Code.

Beginner advice: AI can write code fast, but it can also make mistakes. Learn the basics first (HTML, CSS, JavaScript, Git, how a backend works). Then use AI as an assistant, and always read and test the code before you trust it.

4. Chrome Now Updates Every Two Weeks

Google Chrome moved to a two-week release cycle starting with Chrome 153 on September 8, 2026. Before this, new versions came about every four weeks. This means web developers get new features faster.

Recent web platform features include:

• Single-axis scroll containers (Chrome 153).

• Capability elements for camera and microphone (Chrome 153).

• Joint Iteration in JavaScript (Chrome 153).

• The Prompt API, which lets websites use on-device Gemini Nano, arrived earlier in Chrome 148.

Also, the last Manifest V2 extension listings were removed from the Chrome Web Store on August 31, 2026. If you build Chrome extensions, they must use Manifest V3.

Tip for web developers: Before using a brand-new feature, check browser support on MDN or Can I Use so your site works for everyone.

What These Updates Mean for Beginners

1. Learn fundamentals first. Tools change every month, but HTML, CSS, JavaScript, Git and basic system design stay useful.

2. Use AI as a helper, not a replacement. Review everything it writes.

3. Think beyond the phone screen. Smart displays, wall screens and voice interfaces need new UX thinking.

4. Keep up with browser updates. Faster Chrome releases mean new web features arrive sooner.

5. Test before you update. Even "small" OS updates can affect your tools.

Frequently Asked Questions

Is Windows 11 26H2 a big update? No. It is a small enablement-package update that turns on features already delivered during the year and refreshes the support period.

When can I buy Apple HomeView? Apple says it goes on sale in the US on November 13, 2026 for $299.

Do AI coding agents replace developers? No. They handle tasks like bug fixes and refactoring, but developers still plan, review, test and decide what to ship.

How often does Chrome release new versions now? Since Chrome 153 (September 8, 2026), about every two weeks.

Conclusion

This week's tech news shows three big trends: AI is becoming part of everyday developer tools, hardware is becoming smarter and more personal, and the web platform is moving faster. Keep learning, keep building, and check back next week for more updates.

Sources: Windows Central, Microsoft Windows documentation, AFP, Good Morning America, Dexerto, Pulse 2.0, ChannelLife, Chrome for Developers, Supercharge

AI moves from chatbot to operating layer

AI is no longer just answering questions in a browser. OpenAI has expanded its GPT-6 family with cheaper models, while Google is building laptops around Gemini and Apple and Meta are reportedly working together to bring a major open-weight AI model to high-end Macs.

The shift is toward AI as an interface for computing: writing code, managing apps, interpreting context, and acting across services. The Verge reports that ChatGPT can now view Chrome tabs, a small feature that signals a much larger change—AI assistants are beginning to operate inside the user’s digital workspace rather than waiting in a separate chat window.

But capability is outpacing control. Anthropic has warned that self-replicating AI-powered malware could eventually spread through connected smart-home devices, raising concerns that ordinary IoT products could become part of a larger attack chain.

Cybersecurity becomes a global infrastructure problem

The most urgent tech story this week is not a flashy product launch—it is the growing fragility of digital infrastructure.

A cyberattack on contractor BAE Systems disrupted the notice system used by U.S. federal bankruptcy courts, showing how attacks on a single supplier can ripple into public services. Microsoft’s October Patch Tuesday fixed 1,411 vulnerabilities, including three zero-days, while BeyondTrust disclosed a critical Remote Support flaw that has been exploited since August.

For businesses, the lesson is simple: vendor risk is now enterprise risk. Security teams need to track not only their own software, but also the contractors, cloud services, remote-support tools, and connected devices in their supply chain.

Smart homes enter the threat model

Smart devices were once treated as convenience gadgets. They are now part of critical infrastructure.

In France, attackers reportedly tampered with supermarket refrigeration systems, causing temperatures to rise as high as 50°C, spoiling food and creating fire and equipment risks. CERT-FR initially linked the incidents to compromised remote-control systems made by Danfoss.

This matters because smart homes, retail refrigeration, building controls, and industrial IoT often share the same weakness: remote access. As AI agents gain more autonomy, attackers may use them to scan, adapt, and spread across networks faster than traditional defenses can respond.

Governments redraw the rules of the internet

Regulators are also moving quickly.

The European Union has proposed strict age limits for social media, games, and AI assistants, including a ban on social media for children under 13 and limited supervised access until age 15. Australia’s government has introduced digital duty-of-care legislation that would give users an “off switch” for recommender algorithms.

Meanwhile, AI copyright remains a global flashpoint. OpenAI and Anthropic have pressed Australia to reconsider its restrictions on training AI models with the country’s creative content, arguing that a narrow exemption could protect artists while attracting investment.

The emerging global pattern is clear: countries want innovation, but they increasingly want sovereignty, safety, and accountability built into the technology stack.

Hardware and consumer tech: the AI PC era expands

Consumer hardware is also being reshaped by AI.

• Google has begun taking pre-orders for “Googlebook,” a new laptop category built around Gemini and aimed at Android users.

• Apple has started rolling out iOS 27, including its long-delayed Siri AI overhaul.

• Amazon is showing new “Bee” personal AI wearables that listen to conversations and suggest actions—products that immediately raise privacy questions.

• Tesla finally revealed its next-generation Roadster after nearly a decade of delays, amid speculation about deeper Tesla–SpaceX integration.

The common thread is that hardware is becoming a delivery mechanism for AI services. That creates convenience, but it also means more microphones, sensors, cameras, and behavioral data in people’s homes and pockets.

What to watch next

1. AI agent safety — Expect more scrutiny of models that can browse, use tools, and take actions without constant human approval.

2. Supply-chain security — The BAE Systems incident and widespread zero-day exploitation show why third-party risk management is now board-level work.

3. AI regulation — Age limits, copyright rules, algorithmic transparency, and AI safety laws will define the next phase of the internet.

4. Privacy-first AI devices — Wearables and smart-home products will face pressure to prove that “always listening” does not mean “always recording.”

The code in your ROM (which is what we’ll call the EEPROM to save me some typing) is responsible for all the fundamental stuff that is crucial to the operation of the computer. It is essentially an operating system. This code includes I/O — reading input and writing output to whatever sources and destinations you have — perhaps some maths routines, and a whole host of functions that most, if not all, of your user programs need. You can always relegate some less-critical functions to library files that you include into your program code. But putting the code in the ROM has the benefit of not wasting valuable RAM. It’s always available — all you have to do is call it. But that’s the snag.

Before we go on, however, a word of warning. I have no idea how you write an operating system. What you’re about to read is how I did it. And it works, which is encouraging. However, I’m not claiming this is the best way to do it.

Changing locations

My personal homebrew computer, the Zolatron, is built around the 65C02 CPU, so all the example code here is going to be 6502 assembly — specifically for the Beebasm assembler. But the concepts should transfer to pretty much anything.

What we’re going to be dealing with here are functions (aka subroutines). With the 6502, you call them with jsr <address> (jump to subroutine followed by its 16-bit address in the memory map). The function ends with rts, the equivalent, more or less, to the return keyword in higher level languages.

The problem we have is that address. What is it?

Let’s say you have a function in the ROM that reads a byte from the input stream (in the Zolatron’s case, that’s a serial port) and the function for doing that is at address $DCC8 in the ROM. So our user program code just needs to use the line:

jsr $DCC8

When the code returns from that function, the byte will be in the accumulator. Job done. So where’s the problem?

Yes, the function is at $DCC8 — for now. But if I make a change to the ROM code and burn a new copy, it’s entirely possible, and even quite likely, that the location of that routine will have changed. Now all my user programs are broken.

And trying to remember, even with the aid of pencil and paper, the addresses of all the OS functions is a nightmare, as well as asking for trouble. Sure, you could keep documentation telling you where the functions live, but that’s an additional maintenance chore and one subject to error.

The benefits of labels

Within a specific program, we get around this annoying habit through the cunning use of labels. Let’s take a look at the code for that ‘read byte’ function:

.read_byte

.read_byte stz FUNC_RESULT stz FUNC_ERR ldx STDIN_IDX .read_byte_next lda STDIN_BUF,X beq read_byte_EOB ; 0 means end of buffered text sta FUNC_RESULT inx ; For next time stx STDIN_IDX jmp read_byte_end .read_byte_EOB ; At the end of the buffer lda #ERR_EOB sta FUNC_ERR lda STDIN_STATUS_REG ; Clear the STDIN flags in the status reg and #STDIN_CLEAR_FLAGS sta STDIN_STATUS_REG stz STDIN_IDX ; Reset index stz STDIN_BUF .read_byte_end rts

(By the way, if you want to follow along, all the code for this project is in the Zolatron GitHub repository. You’ll find the above code in the ROM / include / funcs_io.asm file.)

Note the .read_byte label at the start. During assembly, this label will contain the address of the first instruction of the routine (stz in this case). Elsewhere in the ROM code, to call this function we just use jsr read_byte. The assembler handles the task of replacing the label with the appropriate address.

The catch is that this convenience is restricted to other code in the same program. Any other program you write will have absolutely no idea what you mean by read_byte.

If we want to call that handy subroutine that’s in the ROM from user code, how do we do that? The answer is, indirectly.

Jump tables The first step is to build a jump table. This is a list of jump instructions and we place these instructions at locations in the ROM code that won’t change. We’ll also assign the addresses of these instructions to constants that we can include in our user code. (As they are just constants used to insert values at assembly time they don’t increase the size of the resulting machine code.)

I’ll admit I was slightly influenced by the BBC Micro when I chose names for these constants. The one I adopted for the ‘read byte’ function is OSRDBYTE and we’ll be following this throughout the article. You can call the constants anything you want.

Let’s set up our list of constants for various OS calls. I decided to put my jump table at address $FF00 (again, it’s your choice although they do need to be in the ROM space). The following definitions are in a file (LIB / cfg_main.asm) that gets included into every user program and well as the ROM code.

\ OS Function Address Table OSGETKEY = \(FF00 ; Get char, waits for user to enter a key & return OSGETINP = OSGETKEY + 3 ; Create input loop OSRDASC = OSGETINP + 3 ; Get next printable char from STDIN_BUF OSRDBYTE = OSRDASC + 3 ; Read next byte from STDIN_BUF OSRDCH = OSRDBYTE + 3 ; Get next non-space printable char from STDIN_BUF OSRDHBYTE = OSRDCH + 3 ; Read 2 hex chars, convert to 8-bit int OSRDHADDR = OSRDHBYTE + 3 ; Read 4 hex chars, convert to 16-bit int OSRDINT16 = OSRDHADDR + 3 ; Read a 16-bit decimal ineteged from STDIN_BUF OSRDFNAME = OSRDINT16 + 3 ; Read string from STDIN_BUF; check valid filename OSRDSTR = OSRDFNAME + 3 ; Read string from STDIN_BUF \ ... and so on ... Now, jsr OSRDBYTE is the same as jsr \)FF09, but a lot easier to read and remember. And OSRDBYTE will alwaysbe at $FF09.

You’ll notice that the addresses assigned are three bytes apart. That’s because the code we’re going to put at each of those addresses consists of a jump (jmp) instruction, which is one byte long, and a two-byte address.

Next, we set up the jump table itself. This lives only in the ROM code and in my case is in the main program file (z64-main.asm). We set the origin to $FF00, then have a list of jmpinstructions each of which points to a corresponding vector address (more on that in a moment). Again, we're just using constants for those addresses, not direct values.

\ OS Call Jump Table ORG \(FF00 jmp (OSGETKEY_VEC) jmp (OSGETINP_VEC) jmp (OSRDASC_VEC) jmp (OSRDBYTE_VEC) jmp (OSRDCH_VEC) jmp (OSRDHBYTE_VEC) jmp (OSRDHADDR_VEC) jmp (OSRDINT16_VEC) jmp (OSRDFNAME_VEC) jmp (OSRDSTR_VEC) \ ... and so on ... This table has to be in the exact same order as the one above and have the same number of entries. That’s because this whole technique works by using offsets. For example, the constant OSRDBYTE is the fourth item in the first list, and so will automatically pick up the address \)FF09. The corresponding instruction in the jump table is also the fourth item. And this is a theme we’ll come back to.

What’s the vector victor? So far, when you use the instruction jsr OSRDBYTE the assembler knows this means jsr $FF09 so goes to that address and picks up the next instruction which is jmp (OSRDBYTE_VEC). Like I said, it's just another constant holding the value of an address. But it's not the address of the function we're trying to reach. Or it is, but in a roundabout way.

This instruction is using indirection, or vectors if you prefer.

For this new list of addresses, I’ve used the same name as the previous list but just appended ‘_VEC’. Here’s the start of this bit of code which, again, gets included in all program code (the Zolatron file is LIB / cfg_page_2.asm):

\ OS Vector Location Table OSGETKEY_VEC = $0200 OSGETINP_VEC = OSGETKEY_VEC + 2 OSRDASC_VEC = OSGETINP_VEC + 2 OSRDBYTE_VEC = OSRDASC_VEC + 2 OSRDCH_VEC = OSRDBYTE_VEC + 2 OSRDHBYTE_VEC = OSRDCH_VEC + 2 OSRDHADDR_VEC = OSRDHBYTE_VEC + 2 OSRDINT16_VEC = OSRDHADDR_VEC + 2 OSRDFNAME_VEC = OSRDINT16_VEC + 2 OSRDSTR_VEC = OSRDFNAME_VEC + 2 \ ... and so on ... Again, we need to have the same number of entries in the same order as the previous tables.

I chose to have these addresses in Page 2 of the memory map, which is in RAM.You can choose any convenient area in RAM, but RAM it must be. This time, the addresses the constants point to are two bytes apart because what’s going to be found at each address is just another 16-bit address.

In the case of our OSRDBYTE call, the jmp (OSRDBYTE_VEC) is interpreted by the assembler as jmp ($0206). But $0206 is not the address to which execution actually jumps. Those parentheses indicate that this in an indirection. What actually happens is that the processor checks what values are stored in locations $0206 and $0207 and uses those as the target address.

Remember that our read_byte function is at address $DCC8, and that the 6502 is little endian. To complete the process, we need to have stored the value $C8 at address $0206 and $DC at $0207. The processor constructs the address $DCC8 and jumps to that.

You may have noticed that, so far, we have set up two tables of constants and the jump table with values that need never change.

Actual addresses Finally, we get to the bit where we tell a program where the ROM functions exist. The required code is part of the ROM’s initialisation routine. Each OS call gets an entry looking something like this:

lda #<read_byte ; OSRDBYTE sta OSRDBYTE_VEC lda #>read_byte sta OSRDBYTE_VEC + 1 This code takes the low byte of the address of the OS function and writes it to the vector address. Then it takes the high byte and writes it to the vector address + 1. Remember that this is ROM code, so when you assemble the ROM firmware it knows the location of functions such as read_byte and can replace the labels with appropriate addresses. The same goes for the constants. So the assembler actually sees this code as:

lda #<DCC8 ; OSRDBYTE sta $0206 lda #>DCC8 sta $0206 + 1 You can see why using constants and labels is much easier.

I’ve shown the entry just for the read_byte function, even though you need an routine like this for every OS call, because the order in which you set them up isn't important. There's no offsetting like before.But keeping them in the same order as the other tables makes sense from a code maintenance perspective.

How it works Let’s do a run-through of how all of this comes together.

When the machine is booted, the ROM code runs and, one by one, reads the addresses of OS functions and stores them in a table in Page 2 of RAM.

When you run a user program, if it includes the instruction jsr OSRDBYTE, the processor reads this as jsr $FF09(because we gave it that list of constants). So it jumps to $FF09 thinking it's going to find the OS function. But it actually encounters the instruction jmp (OSRDBYTE_VEC), which it interprets as jmp ($0206). It looks to see what values are stored in locations $0206 and $0207, which happen to be $C8 and $DC and subsequently makes a jump to $DCC8, where it finally encounters the ROM's read_byte function.

Press enter or click to view image in full size Diagram showing how looking up the address of a ROM function works. Note that all these OS functions must end with rts (return from subroutine) because we started this journey with jsr.

This might seem convoluted. But because it’s all based around labels and constants, there’s no need to keep track of (or even know) the actual addresses of functions or the OS calls.

As the three main tables all have corresponding entries in the same order, we’re effectively just using offsets into tables (a bit like offsets into arrays). In our code, we just use the constants for the OS calls and let the assembler take care of the details. If you edit the code so that the actual address of the OS function changes, this method automatically takes care of that.

Much jumping If this all feels like a lot of jumping around, I can understand, but it really isn’t.

Other than the original jsr instruction in the user code (which you need anyway), there is just one additional jump to get to the function code. Of the four blocks of code we've examined that make up this process, two are just definitions of constants, one is a table of addresses that is created automatically on boot-up and the jump table is the only one that contains actual (indirect) jump commands.

There is, by the way, another benefit from doing it this way. As we saw, that final jump instruction lives in RAM. Your user program could actually change the address to which this OS call indirects, replacing it with its own routine. All it has to do is modify the address stored in $0206 and $0207.

When writing a user program, I just need to include the two files with the constant declarations. It looks like this:

INCLUDE "../../LIB/cfg_main.asm" INCLUDE "../../LIB/cfg_page_2.asm" ; OS Indirection Table Now, all the OS functions are available from any user program. Just remember to keep an eye on the order of those first three tables. And if you add a new OS function in ROM, you need to update all four of the code blocks. But you never need to worry about where OSRDBYTE is hiding.

You can find all the stories related to this project on the Zolatron feature page.

There is also a GitHub Zolatron repo with the code, datasheets and other documents.