A Scratch-Built Commodore 64, Turing Style

Building a Commodore 64 is among the easier projects for retrocomputing fans to tackle. That’s because the C64’s core chipset does most of the heavy lifting; source those and you’re probably 80% of the way there. But what if you can’t find those chips, or if you want more of a challenge than plugging and chugging? Are you out of luck?

Hardly. The video below from [DrMattRegan] is the first in a series on his scratch-built C64 that doesn’t use the core chipset, and it looks pretty promising. This video concentrates on building a replacement for the 6502 microprocessor — actually the 6510, but close enough — using just a couple of EPROMs, some SRAM chips, and a few standard logic chips to glue everything together. He uses the EPROMs as a “rulebook” that contains the code to emulate the 6502 — derived from his earlier Turing 6502 project — and the SRAM chips as a “notebook” for scratch memory and registers to make a Turing-complete random access machine.

[DrMatt] has made good progress so far, with the core 6502 CPU built on a PCB and able to run the Apple II version of Pac-Man as a benchmark. We’re looking forward to the rest of this series, but in the meantime, a look back at his VIC-less VIC-20 project might be informative.

Continue reading “A Scratch-Built Commodore 64, Turing Style”

MilliForth-6502, A Forth For The 6502 CPU

Forth is popular on small computers because it is simple to implement, yet quite powerful. But what happens when you really need to shrink it? Well, if your target is the 6502, there’s milliForth-6502.

This is a port of milliForth, which is a fork of sectorforth. The sectorforth project set the standard, implementing a Forth so small it could fit in a 512-byte boot sector. The milliForth project took sectorforth and made it even smaller, weighing in at only 336 bytes. However, both milliForth and sectorforth are for the x86 architecture. With milliForth-6502, [Alvaro G. S. Barcellos] wanted to see how small he could make a 6502 implementation.

Continue reading “MilliForth-6502, A Forth For The 6502 CPU”

Take A Little Bit Of Acorn To Work

When we think of 8-bit computers, it’s natural to start with home computers. That’s where they live on in the collective memory. But a Z80, a 6502, or similar was more likely to be found unseen in a piece of industrial machinery, doing the job for which we’d today reach for a microcontroller. Sometimes these two worlds intersected, and thus we come to the EuroBEEB, a derivative of Acorn’s BBC Micro on a Eurocard. [Steve Crozier] has performed extensive research into this system and even produced a recreated PCB, providing a fascinating window into embedded computing in the early 1980s.

The EuroBEEB was the work of Control Universal, a Cambridge-based company specialising in embedded computers. They produced systems based upon 6502 and 6809 processors, and joining their product line to the then-burgeoning BBC Micro ecosystem would have been an obvious step. The machine itself is a Eurocard with a simple 6502 system shipped with ACORN BBC Basic on ROM, and could be seen as a cut-down BBC Micro with plenty of digital I/O, accesible through a serial port. It didn’t stop there though, as not only could it export its graphics to a “real” BBC Micro, it had a range of expansion Eurocards that could carry the missing hardware such as analogue input, Teletext, or high-res graphics.

The reverse-engineered PCB comes from analysis of surviving schematics, and included a couple of gate array logic chips to replace address decoding ROMs in the original. If it seems overkill for anyone used to a modern microcontroller, it’s worth remembering that by the standards of the time this was a pretty simple system. Meanwhile if you only fancy trying BBC BASIC, there’s no need to find original hardware.

A 6502, In The Shell

Shell scripting is an often forgotten programming environment, relegated to simple automation tasks and little else. In fact, it’s possible to achieve much more complex tasks in the shell. As an example, here’s [calebccf] with an emulated 6502 system in a busybox ash shell script.

What’s in the emulator? A simple 6502 system with RAM, ROM, and an emulated serial port on STDIO. It comes with the wozmon Apple 1 monitor and BASIC, making for a very mid-1970s experience. There’s even a built-in monitor and debugger, which from our memories of debugging hand-assembled 8-bit code back in the day, should be extremely useful.

Although the default machine has a generous 32k of RAM and 16k ROM, you can easily adjust these limits by editing machine.sh. In addition, you can get a log of execution via a socket if you like. Don’t expect it to run too fast, and we did have to adjust the #! line to get it to run on our system (we pointed it to bash, but your results may vary).

What you use this for is up to you, but we’re sure you’ll all agree it’s an impressive feat in the shell. It’s not the first time we’ve seen some impressive feats there, though. Our Linux Fu column does a lot with the shell if you want further inspiration.

Retrotechtacular: Point-of-Sale Through The Years

In days gone by, a common retail hack used by some of the less honorable of our peers was the price tag switcheroo. You’d find some item that you wanted from a store but couldn’t afford, search around a bit for another item with a more reasonable price, and carefully swap the little paper price tags. As long as you didn’t get greedy or have the bad luck of getting a cashier who knew the correct prices, you could get away with it — at least up until the storekeeper wised up and switched to anti-tamper price tags.

For better or for worse, those days are over. The retail point-of-sale (POS) experience has changed dramatically since the time when cashiers punched away at giant cash registers and clerks applied labels to the top of every can of lima beans in a box with a spiffy little gun. The growth and development of POS systems is the subject of [TanRu Nomad]’s expansive video history, and even if you remember the days when a cashier kerchunked your credit card through a machine to take an impression of your card in triplicate, you’ll probably learn something.

Continue reading “Retrotechtacular: Point-of-Sale Through The Years”

Building A Reproduction Apple I

If you think of Apple today, you probably think of an iPhone or a Mac. But the original Apple I was a simple PC board and required a little effort to start up a working system. [Artem] has an Apple I reproduction PCB, and decided to build it on camera so we could watch.

For the Apple I, the user supplied a keyboard and some transformers, so [Artem] had to search for suitable components. He wisely checks the PCB to make sure there are no shorts in the traces. From there, you can watch him build the machine, but be warned: even with speed ups and editing, the video is over an hour long.

If you want to jump to the mostly working device, try around the 57-minute mark. The machine has a basic ROM monitor and, of course, needs a monitor. There was a small problem with memory, but he eventually worked it out by inhibiting some extra RAM on the board. Troubleshooting is half of the battle getting something like this.

Want to look inside the clock generator chip? Or skip the PCB and just use an FPGA.

Continue reading “Building A Reproduction Apple I”

Using AI To Help With Assembly

Although generative AI and large language models have been pushed as direct replacements for certain kinds of workers, plenty of businesses actually doing this have found that using this new technology can cause more problems than it solves when it is given free reign over tasks. While this might not be true indefinitely, the real use case for these tools right now is as a kind of assistant to certain kinds of work. For this they can be incredibly powerful as [Ricardo] demonstrates here, using Amazon Q to help with game development on the Commodore 64.

The first step here was to generate code that would show a sprite moving across the screen. The AI first generated code in all caps, as was the style at the time of the C64, but in [Ricardo]’s development environment this caused some major problems, so the code was converted to lowercase. A more impressive conversion was done in the next steps, as the program needed to take advantage of the optimizations found in the Assembly language. With the code converted to 6502 Assembly that can run on the virtual Commodore, [Ricardo] was eventually able to show four sprites moving across the screen after several iterations with the AI, as well as change the style of the sprites to arbitrary designs.

Although the post is a bit over-optimistic on Amazon Q as a tool specifically for developers, it might have some benefits over other generative AIs especially if it’s capable at the chore of programming in Assembly language. We’d love to hear anyone with real-world experience with this and whether it is truly worth the extra cost over something like Copilot or GPT 4. For any of these generative AI models, though, it’s probably worth trying them out while they’re in their early stages. Keep in mind that there’s a lot more than programming that can be done with some of them as well.