Choose Your Own Vector Map

August 22, 2022 by Matthew Carlson 7 Comments

There are adults out there driving who were born after Google Earth came out. Potentially distressing facts aside, those who were around to remember the magic of scrolling in and out with infinite levels of detail was an experience that burned into our brains. Perhaps still curious 21 years later, [Craig Kochis] dove into how vector maps work by implementing one himself.

Some standard helper functions convert latitude and longitude into Mercator coordinates (x and y coordinates on the screen). He used WebGL to draw a canvas, making the whole thing interactive on the webpage itself. The camera position and zoom level stored as a matrix that is used to transform the map projection. By grabbing polygons that describe the shape of various borders and then converting those polygons into triangles with earcut, [Craig] has a part of a country rendered to a screen. Continue reading “Choose Your Own Vector Map” →

Recreating DOOM On A Homebrew 8-Bit CPU

August 16, 2022 by Lewin Day 14 Comments

[James Sharman] has been working away on a 8-bit CPU of his own design. Naturally, with his computing device largely functional, the obvious question was asked: can it run DOOM? [James’] latest video explores this question, showing just how close he was able to get.

[James’] 8-bit pipelined CPU also has its own UART, VGA adapter, and sound adapter all built up on discrete components on various PCBs. There’s also a custom interface for a SNES controller as an input device. However, it’s fundamentally well below the specs that DOOM originally required at launch. His 8-bit CPU runs at just 4 MHz, with 64 KB of RAM. This compares poorly to the 32-bit, 33 MHz Intel 386 chips and 4 MB of RAM originally recommended to run the game.

In lieu of running the real thing, [James] demonstrated the limitations of his machine by coding his own demo, nicknamed Doomed. It’s able to average 19 fps video output at a resolution of 80×60, and consists of over 5,000 lines of hand-written assembly code. Fundamentally, it’s a basic 3D engine not dissimilar to Wolfenstein 3D, though without any actual gaming interactions involved.

[James] could have simply stated the machine won’t run DOOM. However, trying to get something similar up and running was a useful learning experience, and in his own words, highly satisfying. This attitude of pushing on in the face of adversity is what propels many other DOOM porting efforts.

Continue reading “Recreating DOOM On A Homebrew 8-Bit CPU” →

Self-Hosted Pi Pico Development

August 1, 2022 by Jenny List 30 Comments

Older readers and those with an interest in retrocomputing may remember the days when a computer might well have booted into a BASIC interpreter. It was simultaneously a general purpose device that could run any software it would load, and also a development environment. Not something that can be said for today’s development boards which typically require a host computer on which to write code. Have we lost something along the way? Perhaps an answer to that question can be found in [lurk101]’s self-hosted development environment for the Raspberry Pi Pico.

It presents itself as a shell, with a flash file system, a port of the vi editor, and a C compiler. We might think of vi as being more at home on a UNIX-derived system, but in this case it’s a port of the vi included in BusyBox. Meanwhile the compiler comes from amacc project.

Of course, this still requires a terminal of some type which in practice will mean a host computer. But the feat is nevertheless an interesting one, and we can see that it might not be impossible given the Pico’s surprising versatility to being some of the terminal features onto the chip itself.

It’s worth noting that this isn’t the first attempt we’ve seen to put a command line interface on a development board.

Why Fedora Decided To Give CC0 Licensed Code The Boot

July 29, 2022 by Tom Nardi 57 Comments

The term “open source” can be tricky. For many people, it’s taken to mean that a particular piece of software is free and that they can do whatever they wish with it. But the reality is far more complex, and the actual rights you’re afforded as the user depend entirely on which license the developers chose to release their code under. Open source code can cost money, open source code can place limits on how you use it, and in some cases, open source code can even get you into trouble down the line.

Which is precisely what the Fedora Project is looking to avoid with their recent decision to reject all code licensed under the Creative Common’s “Public Domain Dedication” CC0 license. It will still be allowed for content such as artwork, and there may even be exceptions made for existing packages on a case-by-case basis, but CC0 will soon be stricken from the list of accepted code licenses for all new submissions.

Fedora turning their nose up at a software license wouldn’t normally be newsworthy. In fact, there’s a fairly long list of licenses that the project deems unacceptable for inclusion. The surprising part here is that CC0 was once an accepted license, and is just now being reclassified due to an evolving mindset within the larger free and open source (FOSS) community.

So what’s the problem with CC0 that’s convinced Fedora to distance themselves from it, and does this mean you shouldn’t be using the license for your own projects?

Continue reading “Why Fedora Decided To Give CC0 Licensed Code The Boot” →

Google Quantum, Virtually

July 28, 2022 by Al Williams 18 Comments

Want to try a big quantum computer but don’t have the cash? Google wants to up your simulation game with their “Quantum Virtual Machine” that you can use for free.

On the face of it, it sounds like marketing-speak for just another quantum simulator. But if you read the post, it sounds like it attempts to model effects from a real Sycamore processor including qubit decay and dephasing along with gate and readout errors. This forms what Google calls “processor-like” output, meaning it is as imperfect as a real quantum computer.

If you need more qubits than Google is willing to support, there are ways to add more computing using external compute nodes. Even if you have access to a real machine of sufficient size, this is handy because you don’t have to wait in a queue for time on a machine. You can work out a lot of issues before going to the real computer.

This couldn’t help but remind us of the old days when you had to bring your cards to the central computer location and wait your turn only to find out you’d made a stupid spelling mistake that cost you an hour of wait time. In those days, we’d “desk check” a program carefully before submitting it. This system would allow a similar process where you test your basic logic flow on a virtual machine before suffering the wait time for a real computer to run it.

Of course, if you really need a quantum computer, the simulation is probably too slow to be practical. But at least this might help you work out the kinks on smaller problems before tackling the whole enchilada. What will you do with a quantum computer? Tell us in the comments.

Google, of course, likes its own language, Cirq. If you want a leg up on general concepts with a friendly simulator, try our series.

The Orbtrace debugger hardware connected to a development board t hrough a 20-pin ribbon cable. The development board has a green LED shining.

ORBTrace Effort: Open Tool For Professional Debugging

July 26, 2022 by Arya Voronova 35 Comments

There are some fairly powerful debugging facilities available on today’s microcontrollers — if your code crashes mysteriously, chances are, there’s a debugging interface that could let you track down the exact crash circumstances in no time. Sadly, debugging tools for these powerful interfaces tend to be prohibitively expensive and highly proprietary, thus, not friendly for hobbyists. Now, there’s a community-driven high-capability debugging platform called ORBTrace, brought to us by [mubes] and [zyp].

With parallel trace, you get a constant stream of consciousness, every exact instruction executed by your CPU. [mubes] and [zyp] set out to tap into the power of parallel trace debugging for Cortex-M processors. and the ORBTrace project was born. Relying on the Orbuculum project’s software capabilities, this FPGA-based debugger platform can do parallel trace and the more popular high-speed SWO trace – and way more. ORBTrace has the potential to grow into a powerful debug helper tool, with enough capabilities for anyone to benefit. And of course, it’s fully open-source.

The ORBTrace platform has plenty of untapped potential. There’s the battle-tested JTAG and SWD that you can already use with all the open tools you could expect. However, there’s also plenty of available resources on the FPGA, including even a currently unutilized RISC-V softcore. If you wanted to add support for any other family of devices to this debugger, sky’s the limit! And, of course, there’s cool software to go with it – for example, orbmortem, which keeps a ring buffer of instructions in memory and shows you the last code executed before your CPU stops, or orbstat, a tool for profiling your embedded code.

If you’re looking to purchase effortless feature parity with Segger or Lauterbach devices, the ORBTrace doesn’t promise that. Instead, it’s an open debugging toolkit project, with hardware available for purchase, and software just waiting for you take control of it. This project’s community hangs out in the 1BitSquared discord’s #orbuculum channel, and gateware’s advancing at a rapid pace – welcoming you to join in on the fun.

ORBTrace is a powerful tool for when your goals become large and your problems become complex. And, being a community-driven experimental effort, we’ll undoubtedly see great things come out of it – like the Mooltipass project, originally developed by Hackaday community members, and still going strong.

Looking At Fortran In 100 Seconds

July 16, 2022 by Al Williams 36 Comments

Usually, when we are talking about old computers, we are thinking of BASIC interpreters. But [Fireship] reminds us that it was originally Fortran and promises to give you the essentials in 100 seconds. We didn’t think you could do much in that short amount of time, but we have to admit that they did a pretty good job.

Of course, it doesn’t hurt that we know Fortran — you probably aren’t going to be able to put it on your resume after watching this video. On the other hand, we were impressed with how much they did squeeze in. If you haven’t touched Fortran since the 1960s and 1970s, you should know that it has changed. Pointers, dynamic memory allocation, and even objects are all possible. It is still a very capable language and very adept at crunching large sets of numbers. Besides, there are many sophisticated algorithms you can borrow from decades of Fortran development.

If you decide you want to have a go, there is, of course, GNU Fortran. Honestly, as much time as we spent writing Fortran in years past, we don’t recommend it for new job prospects. But if you have some period hardware and want an authentic experience, it might just be the way to go. Or, just fire up a browser if you want to play.

Not everyone agrees, though, that Fortran is on the wane. There are efforts to bring it even more up to date. You can even use it for web development.

Continue reading “Looking At Fortran In 100 Seconds” →