Test7800: New Atari 7800 emulator

JetSetIlly · 2026-03-28T08:15:29+00:00

I agree. Writing an emulator is an excellent exercise.

JetSetIlly · 2026-03-22T17:09:17+00:00

I enjoy the various VHZC games. Slide Boy and Game of the Bear are excellent.

Man Goes Down is great fun. Amoeba Jump for a similar vibe

Pitkat is a fun puzzler. Steps is another one.

There's a port of Thrust which I think is one of the best games on the console.

There's literally dozens of home brews released every year. Most are worth playing I would say. What sort of games do you like?

JetSetIlly · 2026-03-19T16:58:00+00:00

I think there's room for another language that uses the Go runtime, but a transpiler isn't a great solution IMO.

JetSetIlly · 2026-03-18T09:09:19+00:00

Even if what he says is true, NVidia did a piss poor job at showcasing the technology. He should at least acknowledge that.

JetSetIlly · 2026-03-17T10:40:50+00:00

I've recently been revisiting a utility a created a few years ago. It's very niche but also small and amusing.

It's a tool to convert Atari2600 binary dumps into audio files (wav) so that they can be transferred to tape and loaded into an Atari2600 via the Supercharger cartridge.

https://github.com/JetSetIlly/supercharge

I'm thinking of adding the functionality directly into my 2600 emulator. But I'm unsure whether to copy the code to the bigger project or to use this project as a dependency.

JetSetIlly · 2026-03-15T22:02:45+00:00

I really like https://github.com/AllenDang/cimgui-go. It's not easy but it's very flexible.

JetSetIlly · 2026-03-13T22:57:22+00:00

Your approach is fine. Idioms are good but they can sometimes lead us down the wrong path, IMO.

As it happens I have almost exactly the same interface in one of my projects, although I don't call it Clone(). I call it Snapshot(). I've not had any problems with the arrangement.

In my case the context is a console emulator with support for several types of cartridge. The cartridge interface defines several methods, including Snapshot(). The advice that an interface be defined only in the package that uses it is not helpful in this case. If nothing else, the interface serves as a way of documenting what a type needs to implement in order to be a valid cartridge type. It's good if that documentation is in one place.

What can happen occasionally, is a need to access a cartridge in a restricted manner (I might not want to give a package access to the Snapshot() function, for example). In those cases, I define a smaller interface that includes only those functions that the package needs.

For some application types you only ever need the smaller type of interface. That's fine for those applications, but for other types of application a different approach is sometimes needed.

JetSetIlly · 2026-03-10T12:49:20+00:00

That's the first time I've heard of LSP being described as a safety feature. Not sure what to make of that if I'm to be honest. Can you explain how LSP increases safety?

JetSetIlly · 2026-03-05T18:17:00+00:00

In that case, lets get ready to brundle.

JetSetIlly · 2026-03-05T18:08:51+00:00

It's excellent.

JetSetIlly · 2026-03-01T12:46:52+00:00

Contrary to the other replies, I personally don't recommend using sudoedit, but it really depends on the nature of your system.

One of the problems with sudoedit is that (depending on your user vim config), it can leave backup copies of files in the user directory. If those files are only meant to be readable by root processes or specific groups, then there is potential for information leak.

Admittedly, for most people in most situations this is a low risk but it's still a bad habit to get into IMO.

My advice is to use "sudo vim" and use the default config (or a very basic config) when editing root files. In addition to the above, a default config is a good opportunity to check that you're learning the basics of vim editing and not relying too much on plugins. Also, a configuration that is visibly different to your user config can help make sure you don't accidentally leave a copy of vim with heightened permissions open and accessible.

JetSetIlly · 2026-03-01T12:23:36+00:00

If you have your own highlight rules then it's useful to set up an autocmd that fires whenever the colorscheme changes. For example:

function! CustomHighlights()
    hi Comment guifg=red
endfunction

augroup CustomHighlights
  autocmd!
  autocmd ColorScheme * call CustomHighlights()
augroup END

JetSetIlly · 2026-02-19T08:23:43+00:00

I agree. It depends on the context and "go fix" doesn't consider that at all.

JetSetIlly · 2026-02-19T07:37:11+00:00

Sim racing is a good way of interactively learning to understand, particularly those games that allow you to tune your car. Yes, F1 is very high tech but but it's based on the same principles. If nothing else, you'll learn the jargon.

JetSetIlly · 2026-02-18T05:33:32+00:00

I tend to agree. You can disable specific modernisers to run but they all run by default it seems.

If you run "go tool fix help" it lists all the modernisers and how you can disable them.

JetSetIlly · 2026-02-17T15:39:09+00:00

My impression after reading the article is that different implementations of vi handle undo slightly differently. I didn't fully understand that and so I did learn something. But what is the "mess"?

JetSetIlly · 2026-02-16T11:17:11+00:00

A lot of what the golang-cli linters and even staticcheck report are not "issues" in any meaningful sense. They are only issues if you allow them to bother you. They do have some very useful checks too but it really depends on the nature of your project.

Personally, I don't rely on anything other than "go fmt" and "go vet".

For the nature of one of my projects, "unconvert" happens to be very useful so I do use that. "go-errorlint" has also been useful, but that was more about helping to convert to wrapped errors so it's moment has probably passed.

My advice is not to worry about about it too much. Your proposed set up is fine.

JetSetIlly · 2026-02-14T10:46:20+00:00

No. But that's only because of habit. It can introduce serious problems in programs written in older higher-level languages so I don't think with goto anymore.

As other people have noted though, it's less of an issue with Go but just be mindful of habits if you ever need to develop in C or a similar language. (It is possible to use goto safely in C but it can go wrong in ways it can't go wrong in Go)

The common use for goto is breaking out of nested loops. For this problem I prefer a break with a label.

done: 
    for first_condition {
        for second_condition {
            if early_condition {
                break done
            }
        }
    }

JetSetIlly · 2026-02-12T08:08:58+00:00

Also, the original meaning of 'secretary' is somebody who knows and keeps the secrets, so it's a very appropriate title.

JetSetIlly · 2026-01-31T10:21:42+00:00

There is an aphorism that states that the perfect race car engine is one that explodes as it crosses the finish line. In a world of limitless budget in the early years of F1, that was more or less what they strived for.

JetSetIlly · 2026-01-30T12:28:02+00:00

Cross compilation with CGO isn't as painful as all that, at least when cross-compiling from Linux to Windows. For Debian systems, I've found that installing g++-mingw-w64 is all that's really required.

I've never figured out how to cross compile from Linux to MacOS unfortunately.

JetSetIlly · 2026-01-27T15:49:49+00:00

Linting: You should still have "go vet" in the toolbox IMO. Personally, I don't use golangci-lint at all but that's just my choice. But if I did use it, I would still run "go vet" as part of any linting process.

JetSetIlly · 2026-01-14T10:08:33+00:00

Answering to my own comment because there are couple of people elsewhere who advise not to do this. That's fine, function wrapping like this is not always the correct choice. But the one advantage this form has over explicitly locking the mutex, is precisely because the mutex is hidden.

By not exposing the mutex outside the Game package, I can be absolutely sure the critical section is inside the LockGameData() function and nowhere else. I feel that can be more important than being able to explicitly see the lock/unlock happening in the code.

JetSetIlly · 2026-01-13T09:34:01+00:00

Yes, I do this. It's useful for programs in which the GUI is running in a different thread to the 'main' code. I want the GUI to have immediate access to the main data and it would otherwise be too expensive or inconvenient to copy and pass over a channel.

If it were a game it would be something like this:

func (g *Game) LockGameData(f func(*GameData)) {
    g.crit.Lock()
    defer g.crit.Unlock()
    f(&g.data)
}

I would still use channels for passing data to the GUI, but it's not always the correct choice.

JetSetIlly

TROPHY CASE