I remember seeing ads for the ZX80 in electronics magazines, and losing my mind as a little kid over them. Later on I did an electronics class as a teenager, and the tutor brought in his ZX80. It was amazing to see it in the flesh.
Later on, my friend's older brother had a Spectrum. All the local magazines had photos of the games, and it was incredible to play them and see them "for real". The rubber keyboard with pre-programmed BASIC keywords, later on a full-sized keyboard and some kind of expansion pack (with disk drives I think?). And his older brother showing me how crazy the memory layout for graphics was. Good times.
I certainly find that now, going back to uni. In a couple of subjects we get the option to prepare a cheat sheet, and I would say I actually look at less than 10% of it. The act of preparing it forces me to revise, and internalise the facts and ideas.
Interesting spec. Why go for 48K of RAM and not at least 64K (the full address space without paging)?
Back in the day 48K got used as a way of binning in the ZX Spectrum (Z80 based) to make use of cheap "bad" memory. Surely RAM prices aren't that crazy now? :P
Wouldn't this be because the ROM is taking up address space and they don't have bank switching? One of the future goals is to copy the ROM and RAM and switch it out of the address space.
That's how it was on the Spectrum, at least - it had 64k of RAM but the bottom 16K was permanently mapped to the ROM[0].
Might have been interesting if they'd allowed you to page out the ROM to access the extra 16K - load a small routine from tape that contains your own tape loading routine, swap out the ROM, load the rest of your app, bob's your uncle. Would have needed some shenanigans to swap in the ROM on reset, obvs.
This was exactly one of the many hardware projects that were published in the spanish magazine microhobby.
Long story short: it added 16K of RAM that was mapped at 0, and allowed both manual control with buttons or software control via a port to decide if it is mapped only for writes or it is mapped for both reads and writes.
My understanding was that Sinclare got to 48K using 8× 4116 + 8× 4532 chips where the 4532 was basically a 64K-bit 4164 where only half the chip worked.
> One of the future goals is to copy the ROM and RAM and switch it out of the address space.
I'm trying to figure out the video part, there is a demo screen that is showing pretty high res in color, and this says 1024x600 and 256 colours- that is mighty impressive for a 6502, that is driving way more pixels that I ever saw in that era, so I was expecting there was some other chip being used as a screen buffer and graphics chip...
but it looks like the LCD has to be bit banged by the CPU data bus directly? I see the 8 bit data bus is going straight to the LCD thru a buffer IC.
I don't see where in the memory map there would even be enough space for a screen buffer that large to be located, so I take it you have to write you own graphics handling yourself and pick a spot in memory for it all?
> RA8889 is a low power TFT controller with powerful display functions and build-in internal SDRAM memory. In order to quickly refresh the screen content with the display memory, RA8889 provides not only parallel, 8080/6800 8/16-bit MCU interface, but also 3/4 wire SPI and IIC serial interface. Plenty powerful functions are provides from RA8889, such as multiple display buffers, Picture-in-Picture, transparency control, display with rotation & mirror, and build-in JPEG and AVI decoder.
I wondered the same thing, and it looks like it uses this CMOS-compatible high level TFT driver: https://www.raio.com.tw/en/RA8889.html with a character generator, geometry primitives, etc.
> I don't see where in the memory map there would even be enough space for a screen buffer that large to be located
1024 × 600 with 256 colours is 600 kB. Even in monochrome, it would be over 64 kB.
> but it looks like the LCD has to be bit banged by the CPU data bus directly?
Even at 20 Hz, that would involve writing over a ten million pixels per second, giving you about 1 CPU cycle per pixel ⇒ there’s no way to do that with this CPU.
These sorts of project should be using the 68000 or the 65816 which both give a 24 bit address bus. Meaning they get 16 MB of address space to work with. They can make directly addressable frame buffers at high resolutions and reasonable color depths, and still have lots of memory available for programs and data.
Let's say I'm upgrading a large software enterprise application.
I start the upgrade process.
After 5 minutes, the process determines that the upgrade will require an extra 1.5GB of storage and asks me if I would like to continue with the upgrade.
After 15 minutes, I'm presented with a username / password prompt to enter credentials to retrieve a package from an external resource needed for the upgrade.
After another 5 minutes, the upgrade process has detected that there are a number of derelict files detected and asks for permission to remove these files.
As a frequent internal tool writer, I’d say it’s a fact of life but an undesirable one. I’m always trying to avoid pausing for credentials in the middle of a run, either by doing them right at the beginning or by using some sort of durable credentials system like ssh keys.
There’s always two people at every company who refuse to set up auth automation though, so you end up handling it. They are very stubborn. Even when it trips them up in front of observers while executing an urgent task, I’ve only occasionally convinced them to agree to set up trust instead of typing a password every single time.
Which is to say, I have to support password prompts even though they drive me up the wall.
It's a product of the scope limited interface granted to agents. They get a terminal stream so everything goes into the stream. Piling on more in-band signaling is just going to become a security nightmare. It would be better to have a safe way to query process state that can be locked down as needed.
As someone who works on a lot of CLI tools at work I actually like the idea of implementing this in some of our long-running tooling, completely independent of the AI agent use case.
The original idea I had being that CI environments, or anywhere that shows terminal output, could use a streaming ANSI parsing library to detect when a program sent a 'change window title' OSC event and then start a new collapsable section in its output. This would let programs update the actual terminal window title with its current state when running locally and update the CI interface when running in CI.
Adding in the ability to specify the program's current status and (optionally) progress could be extremely useful in CI environments as well. Imagine, for example, a long-running analysis task which uses OSC 7501 to say that it's currently running and is 75% of the way done. CI could expose that in the UI to provide useful information to the end-user without having to print a progress bar or multiple progress lines to the fake terminal it's being run in.
I sometimes use the AI prompt to do a similar thing: I'm struggling with a problem, or putting my ideas down in a coherent manner, so I write a prompt, and in doing so the idea crystallises for me. I've tried doing this just in a text editor, but there's something about having the next action be "submit this to X" that clicks my brain into higher gear.
I suppose it's very similar to drafting a letter or an email to someone.
My pet project in those days was writing a C++ X-Windows gui toolkit, and I took a lot of inspiration from Tk. Both design, and "how do I do this" from the source code were invaluable.
Yes the legacy Cisco IOS had a Tcl interpreter built in, you can drop in to the repl with the tclsh command. The command is still there on newer Linux based IOS versions
It's honestly harder - you have to do a lot of extra work to ensure your work is traceable. It's super fast in doing things you have no overview of - it makes pretty figures, it runs command line jobs etc. and I'm sure there are mistakes in there. For now I'm pretending Claude Science is an IDE, like Positron/VSCode, and I have to keep enforcing proper git usage etc. so I can reproduce this work
Edit: compared to my tools before, it generally uses the same tools in the same way, just 20x faster than me and I mostly struggle to keep up and verify what it's doing
Sounds exactly like Claude Code (and ilk) tbh. Just a lot of the stakes are lower and a lot of people are more comfortable with it (e.g. there were always people blindly copying and lasting from StackOverflow) I suppose.
> have to keep enforcing proper git usage etc. so I can reproduce this work
Depending on what you mean here, it might be worth looking at jj, which works with git repositories. One of the features is that everything gets committed at change time (kind of) which may or may not be helpful to you here.
For CS students I agree. For non-CS students, who need programming as a way to use computers as a tool, I think they do need a solid understanding of what a computer does and what it's limitations are (and what it's capable of), but for their day jobs (once they graduate), they will most likely be getting AI to do everything for them. As long as they can reason about what's happening, to understand the results and to improve them, this seems likely to be the path in the future.
This is an introductory programming course, designed for non-CS students e.g. engineers and scientists.
> Learning outcomes
> 2. Explain key concepts in AI-assisted programming, including Large Language Models (LLMs), prompting, problem decomposition, and top-down design.
> 3. Apply the workflow of AI-assisted programming and prompt-engineering techniques to guide and improve code generated by AI assistants.
This course used to be non-AI (last year), and they rewrote recently to incorporate AI tools, as they realised the writing's on the wall for non-programmers.
It must be quite challenging to write curriculum when the underlying technology (AI) is changing so quickly.
Later on, my friend's older brother had a Spectrum. All the local magazines had photos of the games, and it was incredible to play them and see them "for real". The rubber keyboard with pre-programmed BASIC keywords, later on a full-sized keyboard and some kind of expansion pack (with disk drives I think?). And his older brother showing me how crazy the memory layout for graphics was. Good times.
reply