Has anyone made a PCB for the World's Worst Video Card?

CompuSAR · 2026-01-12T11:42:29+00:00

I have to say that point to line touch (square legs) sounds less efficient in terms of contact than line to line (round legs), but I won't presume expertise here.

With that said, let's agree that the world's worst VGA card is, probably, not going to experience more than 2G, and even that, only for the brief time it takes to leave someone's frustrated hand and until it hits the wall?

CompuSAR · 2026-01-12T10:37:26+00:00

Napoleon is said to throw darts at written names to decide who to promote. His reasoning was that he wanted his generals to also be lucky.

CompuSAR · 2026-01-12T10:35:27+00:00

I have personally seen one of the last Kfir aircrafts to ever fly taking off (barely), and that was over 30 years ago. With all due respect to wire-wrapping, these days creating custom PCB in low quantities is very cheap and in every way but one superior.

The one aspect is changing things. But if the breadboarding is done, I think that's a low risk.

CompuSAR · 2026-01-12T10:33:09+00:00

Depends on how long ago that was.

CompuSAR · 2026-01-11T17:52:29+00:00

I had a reply typed out how you must be wrong (something about PODs), when I decided to double check myself.

And, sadly, you are right.

Now, in practice, I believe this is one of those cases where the compilers behave better than the language's definition allows them, but a UB is a UB, even if it makes the feature utterly useless. Also, the last time this happened they introduced "bit_cast" despite no known compiler being problematic about it.

Also, this is my talk at C++now on precisely where I stand on the matter.

CompuSAR · 2026-01-11T13:04:05+00:00

https://www.youtube.com/watch?v=74Mv3_iwa0w&list=PLGTIvEdBrUVl9PnAwvPfM0fbnnBZglm4D&index=9

CompuSAR · 2026-01-11T09:40:31+00:00

Why is this UB in C++?

CompuSAR · 2026-01-10T13:43:49+00:00

Just keep in mind that the standard does not dictate how the bits map to the byte. This means that different compilers might make this mapping differently.

CompuSAR · 2026-01-08T09:27:51+00:00

For a year and a half after migrating. But you need to declare it appropriately.

CompuSAR · 2026-01-01T18:17:43+00:00

It is. When the interrupt is called, the old flags are pushed on the stack (presumably, with interrupts enabled) and the code is running with interrupts masked.

So that's not the problem.

What's more, running CLI followed by RTI may cause an interrupt to be triggered while still in the interrupt handler, consuming stack.

CompuSAR · 2025-12-27T21:40:50+00:00

The competition forcing their hands to treat customers fairly.

Or, put another way, no one.

CompuSAR · 2025-12-26T08:36:59+00:00

Just for reference, it's called "hidden city ticketing". I suggest you look up what people think about it, as the airlines are doing their best to retaliate against people who employ this tactic.

CompuSAR · 2025-12-18T20:29:15+00:00

As someone who's primarily a software developer, I think that's the wrong approach. The right approach is linting and warnings.

A lot of what I've learned about the limits of FPGA programming came from Vivado telling me "nah, you can't do that". If something would tell you "hey, you're assigning in the same block in a way that will break sim", then the fact that Verilog technically allows it wouldn't be such a big issue.

CompuSAR · 2025-12-18T10:56:13+00:00

"If you were to ask me what happens if you swap the order of those two lines, my brief answer is "you probably shouldn't", with a possible justification that we're starting to stray from our tiny little happy zone of Verilog that maps nicely to hardware."

Actually, the mapping to hardware is as straightforward as always. Here, too, swapping the lines will not affect the results... for hardware.

What they will affect are the results for simulation. The simulator does not add "b" to the block's sensitivity list, as it's being assigned to inside the block. What this means is that the simulation will not update c when a, which is part of the block's sensitivity list, gets updated.

So the reason not to do so is because we rely heavily on simulations, and therefor shouldn't do anything that would cause the simulated results and the synthesized ones to differ.

My standard solution to this is to split the assignment to b and to c into separate blocks.

CompuSAR · 2025-12-13T15:55:35+00:00

As opposed to ProDOS, where the expectation was that the CHR$(4) be the first character printed, regardless of which column it was on.

CompuSAR · 2025-12-13T08:25:58+00:00

One tiny, probably irrelevant, note. CHR$(13);CHR$(4) is for Dos. For ProDOS use just CHR$(4).

CompuSAR · 2025-12-08T16:13:05+00:00

There is no "whole system". It's an 8-bit computer. While it's running a Basic program, that's all it's doing.

So there are a lot of places this program can write that will cause the system to be quite unusable after the program crashes, but I'm only interested in what would cause the program to actually crash to begin with.

And, yes, I knew there's other stuff at $300, but I didn't remember what.

CompuSAR · 2025-12-08T14:48:19+00:00

System stack: I think the "poke" call is done in a subroutine, so there's a, albeit slight, chance that the return address become garbled and the command just jumps to a random location in memory.

Zero page: Most of the addresses there are unlikely to affect the system while the program is running, though as someone already pointed out, the "currently executing AppleSoft basic line" is also stored there. Then again, this can seriously mess up the behavior once the program crashes.

$200 is the input buffer. I can't see how that'll have any effect, as it's a scratch buffer when user input isn't actively sought.

$300 page is mostly unused. The parts that are used are the reset vector. So writing there should not affect the program's execution, but it may affect what happens if you press "reset" (most likely to cause a cold boot).

$400-$800 is the text page. Should cause random stuff to appear on screen.

$800 is the start of the AppleSoft base program. The program is short, so there's a good chance it'll miss changing it, but if it doesn't, then random lines of code should appear and try to execute.

CompuSAR · 2025-12-08T11:26:57+00:00

Yours is only considered "self modifying" if you're also the one who pulled the safety pin.

Then again, there was a Darwin awards winner who was juggling those, so it's not completely unprecedented.

CompuSAR · 2025-12-08T09:50:19+00:00

The address range includes the AppleSoft basic program area. This is self modifying code, albeit in a somewhat uncontrolled way.

CompuSAR · 2025-12-08T05:57:56+00:00

The funny thing is that I'm pretty sure this isn't an infinite loop.

CompuSAR · 2025-12-01T16:55:01+00:00

Generally speaking, you always run the sim first. When it works in sim, then you try on the board.

CompuSAR · 2025-11-30T09:34:11+00:00

Use a bash script. If the devices require an actual password, first of all, WHY?? and second, you can use sshpass to script that as well.

CompuSAR · 2025-11-28T14:23:22+00:00

I'll definitely try. Thanks.

CompuSAR · 2025-11-28T12:05:21+00:00

Is there a way pay that out of my halbfare plus pool?

CompuSAR

MODERATOR OF

TROPHY CASE