I've been working on an Atari 2600 emulator for many years. I've recently decided to end development at v0.34.0 and thought this was a good time for people on Hacker News to see it.
The emulation is complete and the 6507, TIA, RIOT and memory sub-systems are all accurate. It supports all the known cartridge formats, including those that make use of on-cartridge ARM processors and also specialist cartridge types like MovieCart.
The debugger is extensive and, uniquely, allows the emulation to be stepped at a sub-CPU-cycle level. Programs running on the ARM can be inspected at the source code level if DWARF data is available; breakpoints can be added and local/global variables can be inspected.
For the player, games can be played with a simple but effective series of CRT effects (implemented with GLSL shaders) and quick and responsive rewinding of gameplay. In fact, the rewind system plays an important part in the debugger too.
From the perspective of a Go developer, I believe it shows that the language can produce good and useful applications for the desktop. There is an undoubted performance penalty introduced by the use of supporting C libraries (SDL, Dear Imgui, etc.) but it is, in my opinion, not terrible. Other people may disagree with that and I'd be interested in hearing their thoughts.
The project is not worthy of a v1.0 tag but I now consider it complete if not bug-free. I know I've made some poor engineering choices but I believe many of these mistakes were due to my inexperience with the language - I would certainly make different choices today.
I look forward to constructive criticism from the programmers and engineers on Hacker News before moving onto my next project.
> I am not a huge fan of go:generate and similar projects. They add a level of unknown that goes against the core Golang design values.
I'm not sure I would agree with that. go:generate is a core part of Go since v1.4 and the enum generators are the kind of thing that was intended. https://go.dev/blog/generate
That said, enums would be a welcome improvement to the language. But even then, I think go:generate has a place.
"add(ing) a level of unknown" is a very fair description from a code comprehensibility standpoint, since the go:generate directive is about running arbitrary executables.
The is ameliorated somewhat by the fact that go generate is not part of the build process. Its output would typically be checked into the repo. So as long as the generated code is reasonably readable, it should not have too much of an impact on code comprehensibility.
Good summary but the article doesn't mention the engineering of the user interface. In this field of accountancy, I think the UI is an engineering problem at least as important as anything else mentioned in the article.
As someone who works in accountancy (as a bookkeeper/accountant) I have to be brutally honest and say that I've been very disappointed in the UI of all the accounting software packages I've used. None of them give me the immediacy or simplicity of a well organised filing cabinet, they really don't.
I'm not sure what a good solution would look like, but I can't help thinking that making the double-entry system more visible and apparent to the user would be a good start.
> I think the UI is an engineering problem at least as important as anything else mentioned in the article.
Indeed.
> I'm not sure what a good solution would look like
What is interesting is that on the business reporting side (which is in any case deeply enmeshed with the accounting system side) there is a defacto standard (xbrl and its various specifications [1]) which via web technologies (iXBRL [2]) provides a path towards generic web UI patterns.
This was the same perspective i had as an engineer working on a finance problem for accountants and sales. So i would build a nice reporting tool that had modern ui. The people liked it at first but they always regress to spreadsheet. They just ask me to export the data in spreadsheet.
As someone not in accountancy but having worked in corporate and been forced to work on accounting software for managing budgets, approving transactions etc. - you have really gotten the short end of the stick from general usability perspective. There are so many things that don't make sense - even for the accountants that use the system on day-to-day basis - they have workarounds for (what I would consider) the most basic of things (or over-complicated solutions for something basic like manager approvals for logging expenses - why do I have to click through several screens that don't follow any sort of clear, logical flow). And it's so embedded in an organization - that you can rest assured once that client is signed up they're not switching that system. Same for HR software...
I agree, but also our accountants kept asking for the craziest of things. I guess its a problem that the real world of transactions is full of async processes and weirdness. There is always something new weird that will happen, so it always ends up back in a spreadsheet software.
While I managed our start ups finances, I so much preferred to stay doing everything in Excel over having to use our accountants system. And I get a glimpse into SAP from time to time as my wive is an accountant. It's incredible how shitty those systems are from the user perspective.
But I guess, this is what you get when the user is not also the customer.
I love the Practice of Programming. Of all the books on programming that I've read, the lessons of that book are the ones that remain strongest in my mind. I've not read it in many years but I feel it influences my practice everyday.
It was the first time I’ve ever read it and I was surprised how much of it still held true given it’s 25 years old. Some of the specific programming examples are pretty outdated, but the general ideas are as solid as ever!
They mention at one point that Java doesn't have a way to pass a function as a parameter to another function. That was added in Java 8 with lambdas. That's just one off the top of my head.
The only mainstream languages where you can actually pass function references around, without them being sugar for some complex object that the compiler creates are C, C++ and Rust. And it's not trivial to do in Rust.
Yes. The Go implementation from Google is under the BSD licence.
There's also the GNU implementation in GCC that's under the GNU GPL 3 licence. Moreover, the specification itself doesn't seem to have any licencing requirements at all.
So you're absolutely right: Go is the very opposite of proprietary.
The 2600 is streaming the data from the cartridge, including the program that is run on the 2600. We should remember that there's no frame buffer in the 2600, so there's considerable work done by the 2600 every frame - just as there is when its working with any other cartridge.
The 2600 kernel that runs on the 2600 is excellent but the encoding method is what makes a real difference here. Lodefmode did a great job with this. The use of playfield/background and player colour is exceedingly clever.
No frame buffer. The target CRT display scanned an electron beam from left to right in about 63 microseconds, snapped it back in just a couple more microseconds, working gradually downward to produce about 200 such lines before taking a couple milliseconds to return to the top. The 6507 had to literally write the pixels into that raster in real time, and was just skin of the teeth able to do that, hence the phrase 'racing the beam', leaving just the retrace times for any other program code to run. To get video from a cart, all that still has to happen. Pretty cool.
It reminds me of the gameboy player for the SNES, where the entire gb console ran inside the cartridge and used the snes for inputs and display. In this case a PIC controller is the cpu in the cartridge doing the heavy lifting.
Yes. The Harmony Cart and the UnoCart/PlusCart both have ARM chips. Games have been made that make full use of the chip. Probably the most impressive IMO being Robotron from ChampGames.
The PlusCart also includes a WiFi chip for Internet access.
There are several categories of mistake that you can make when bookkeeping. Some are caught by the double-entry system when a trial balance is prepared.
The error you've described is an "error of original entry" and will be invisible if you only look at the trial balance. It can ultimately be caught when you compare the banking ledger with what's actually in the bank.
Other errors that don't appear in the trial balance can be incredibly hard to detect and in fact, may never be noticed. This is where the real art of bookkeeping is IMO.
The types of errors that do affect the trial balance are things like forgetting to enter a purchase in the purchase ledger but entering the transaction into the banking ledger correctly. Silly errors really, but we can all need help to stop us making those.
Interesting. With a bit of work, this would have genuine use for something like a text display on an Atari2600, where the dimensions are significantly limited.
I've used glyphs as small as 4x5 but I've struggled to come up with anything smaller for most characters.
The emulation is complete and the 6507, TIA, RIOT and memory sub-systems are all accurate. It supports all the known cartridge formats, including those that make use of on-cartridge ARM processors and also specialist cartridge types like MovieCart.
The debugger is extensive and, uniquely, allows the emulation to be stepped at a sub-CPU-cycle level. Programs running on the ARM can be inspected at the source code level if DWARF data is available; breakpoints can be added and local/global variables can be inspected.
For the player, games can be played with a simple but effective series of CRT effects (implemented with GLSL shaders) and quick and responsive rewinding of gameplay. In fact, the rewind system plays an important part in the debugger too.
From the perspective of a Go developer, I believe it shows that the language can produce good and useful applications for the desktop. There is an undoubted performance penalty introduced by the use of supporting C libraries (SDL, Dear Imgui, etc.) but it is, in my opinion, not terrible. Other people may disagree with that and I'd be interested in hearing their thoughts.
The project is not worthy of a v1.0 tag but I now consider it complete if not bug-free. I know I've made some poor engineering choices but I believe many of these mistakes were due to my inexperience with the language - I would certainly make different choices today.
I look forward to constructive criticism from the programmers and engineers on Hacker News before moving onto my next project.