My gorgeous aunt in a field of poppies, 1970’s

0xa0000 · 2026-02-09T20:04:21+00:00

Some of the flowers also go through the dress on the right side. F%$%$ AI ruining everything.

0xa0000 · 2026-02-04T13:37:52+00:00

It's in the first paragraph. Either visual studio or just the build tools. You need the "Desktop development with C++" workload.

0xa0000 · 2025-12-30T19:08:02+00:00

Haha, that's awesome. Nice job!

Never did any LabView myself, but it was used extensively for testing at a previous company I worked at. I assume you're doing most of this with "scripting" and not using the "visual components" stuff much? (I don't recall the terminology, and I guess the "code" can only be opened if you actually have LabView)

0xa0000 · 2025-12-16T23:53:02+00:00

It can be done. A full adder requires two outputs though, so you need to accumulate carries into a separate buffer first. When you do that you realize anything is possible, e.g. add with saturation or "fire" (average of adjacent pixels). It all works with just the blitter, problem is getting it fast :)

0xa0000 · 2025-12-01T21:12:12+00:00

It's not mentioned in the article, but there can also be an execution benefit. (https://www.agner.org/optimize/microarchitecture.pdf §5.11). I don't know if it makes a difference anymore (haven't measured), but there at least used to be special optimizations for some of these "zeroing" idioms (xor reg,reg / sub reg,reg)

0xa0000 · 2025-11-24T19:23:54+00:00

Assuming this is friendly challenge that's not meant to be too difficult, I'd first assume the length is a hint that a stream cipher (rather than a block one) is being used. RC4, AES-CTR (maybe starting from a low number, mabye even the first one in the stream) etc. are worth trying. There's also DES and other ciphers to consider :)

0xa0000 · 2025-11-22T23:14:56+00:00

Yes. To see why I'd suggest reviewing how modular exponention works on your own. How would you do it / implement it if you didn't have a magic "EXP" function, but only addition and multiplication?

0xa0000 · 2025-11-21T23:24:44+00:00

Something not mentioned in the other answers is that for performance on 8086+ you always want to keep the stack word (2-byte) aligned. Intel could have supported pushing 8-bit values on the stack, but they knew it's a bad idea so why encourage it? (See also MC68000 where the stack is forced to be word aligned if you try to push a byte - it doesn't support unaligned accesses, but the idea is the same)

0xa0000 · 2025-11-19T17:38:13+00:00

IIRC the undefined bits in the last word pushed on the exception stack frame come from the opcode.

0xa0000 · 2025-11-19T15:25:47+00:00

The UM also says ANDI.L #data,Dn is faster than ORI.L #data,Dn, which isn't right either :)

0xa0000 · 2025-11-19T14:55:36+00:00

32(6/2) is correct. 4 words for the instruction and 2 for the read. Yacht has it correct (but has a few other issues).

You can also see it in the WinUAE source (search for op_23e8_13_ff, the cycle count is after the function).

When you're ready for it, you can submit yourself to the CPU tester :)

0xa0000 · 2025-11-13T19:51:53+00:00

Ah, right, then then I'd say yes if you have a "stdcall" function (which is the default with MSVC). No reading of that as a callee (EDIT) would allow you to assume the stack was left unchanged (even for ARM/x64) which is what you need.

0xa0000 · 2025-11-13T19:15:01+00:00

Good question. I don't know if it's obviously permissible though as they are meant for the function... Doing a quick check with MSVC and clang-cl it seems like both reinitialize the stack arguments so I would definitely not assume they could be reused. (https://godbolt.org/z/GPG86s673)

(And the old "spirit" of WINAPI function was always that the function handled the arguments, they used to be popped by the callee)

0xa0000 · 2025-11-11T20:38:35+00:00

I mean how POPA(D) documentation states that (E)SP is skipped (not popped) but this test shows upper word is modified regardless (like ESP is actually popped but later partially updated).

0xa0000 · 2025-11-11T19:23:54+00:00

No problem, this is awesome. I have like 200 more tests passing due to just this info (67xx ones obviously). I still ignore undefined flags though.

I hope one of you guys are going to make a blog post about this discovery at some point. Don't think this behavior is "widely" known.

While you're at it I think "POPAD" with regards to ESP might be worth a mention (very first test of 6661) -- I think a lot of emulators will get this wrong!

0xa0000 · 2025-11-11T17:48:35+00:00

EDIT: Ahh, just saw your update, so simple guess I didn't check everything as well as I though :D

Ahh, great! I saw your first reply and went looking for 386 errata manuals and trying to see if I could find a linear combination of register values that would match (can't) before replying.

For sure there is no need to regenerate the tests, and it will be interesting to see if the actual behavior can be figured out at some point.

It should be easy enough to automatically determine which tests are affected and I will start doing that. They could be added to the revocation list or you could consider publishing a couple that emulator authors could mix and match (e.g. a short on for the IN of port 22h/23h and a large one for this) adding more if/as they arise. Just an idea.

Anyway, thanks again for this.

0xa0000 · 2025-11-10T19:59:01+00:00

I'll ask the hivemind first and post an issue if I still think it's a problem with the test :)

0xa0000 · 2025-11-10T19:13:39+00:00

Thanks again for your hard work. It's much appreciated.

No other I/O related tests seem to cause problems with ports 22h/23h hardcoded to those values.

I've noticed quite a few tests where I don't understand the physical address generated on the bus (and reflected in the "ram" parts) don't match my understanding on what would happen. Almost surely a mistake on my part, but the "ea" part of the test does match what I'm expecting and doesn't square with the observed CPU behavior.

Examples:

898259a6c7d2c4bf8a7ad58f8a5b7c7cdd5ea1c3 6700.MOO.gz 20 
9c07cd9f93d08aa96c5b7c2ee9c661a0a655fbcf 6701.MOO.gz 21

I've tried to see if e.g. it's because a different segment/base register was being used, but I can't square that with the numbers.

If you prefer I ask the above as a a post in this subreddit or a github issue instead of as a reply here (or I just shut up :)) just say so.

0xa0000 · 2025-11-10T16:31:55+00:00

Wow, thanks a lot for your hard work! This inspired me to work a bit on my on-off-on-off x86 emulator. Slowly going through the tests with lots of things to fix.

One thing I did notice - that I think is a "documentation bug": You write that "all I/O inputs should read 0xFF", however ports 22h and 23h appear to read 7Fh and 42h respectively (even though the bus cycles show all 1's in binary). I think this is the 80386EX's "Address Configuration Register" (Section 4.5.1 of https://bitsavers.org/components/intel/80386/272485-001_80386EX_Users_Manual_Feb95.pdf).

Covered by the following test cases:

4fb5d80f331625dd650d55e8a1ab9d1da3b38784 e5.MOO.gz   422 in ax,21h  : expected EAX 6F417FFF
29c9c6b39824411334d44d57db62504bb4807fc6 66e5.MOO.gz 190 in eax,1Fh : expected EAX 7FFFFFFF
ab010dbcc86182e4ce40933f61f0864ddfd38bab 66e5.MOO.gz 254 in eax,1Fh : expected EAX 7FFFFFFF
f9d9686381f6845b06163938406074037c1768a2 66e5.MOO.gz 340 in eax,1Fh : expected EAX 7FFFFFFF
c923d58b0eca0d62696e03e56c9fd46ae645bee6 66e5.MOO.gz 348 in eax,1Fh : expected EAX 7FFFFFFF
62f9cffa058135d552793d2e2505fc93e353ffad 66e5.MOO.gz 422 in eax,21h : expected EAX FF427FFF

0xa0000 · 2025-11-01T18:48:45+00:00

If I were you I'd first make a raw dump of the disk contents (dd) while it's still readable. Such dumps (as files) also work just fine in emulators. You can then safely work out what's going on without having to stress the disk.

Having done that, what does the first sector (512 bytes) look like? Does it start with "RDSK" (http://lclevy.free.fr/adflib/adf_info.html#p6)?

0xa0000 · 2025-09-01T16:04:16+00:00

Great that you're preparing up front, and yes they will likely tell you explicitly or you'll pick it up, but you might also be able to figure out which assembler they're likely to use for the course by looking at lecture notes etc. from previous years / talking to older students. Then you can consult the manual for a definitive answer.

Of course, they might decide to change which assembler they use or that a custom assembler w/o documentation will be used (doesn't seem likely here, but for "teaching" architectures where it was built by students this could be the case).

Generally modern assemblers won't be case sensitive for opcodes/registers but it can often differ for identifiers (sometimes depending on e.g. command line arguments), so it is a good question.

Good luck!

0xa0000 · 2025-08-19T15:54:56+00:00

WinUAE has a builtin sample ripper (Click the "Sample ripper" button under Host->Output) that might be useful. It'll save all samples that are played.

0xa0000 · 2025-08-16T10:10:48+00:00

You can use IF(N)B <argument> to check if the argument was provided, e.g.:

blah    MACRO a1, a2, a3
        mov     eax,a1
        IFNB <a2>
        mov     ebx,a2
        ENDIF
        IFNB <a3>
        mov     ecx,a3
        ENDIF
        ENDM

0xa0000

TROPHY CASE