Happily, our new microcode V20 core matches every hash, so 8080 emulation mode seems to be working well.

For all 3 people who will ever use it, rejoice.

We can execute this on our V20 using an 8080 emulator such as Sydex's 22NICE, which supports the V20's 8080 emulation mode.

The V20's emulation mode requires software support - it's not as simple as just running your favorite CP/M program. The program must be located in memory and some strategy for handling interrupts employed.

8080EXR is an 8080 CPU exerciser that runs under CP/M. On real hardware at around 2 MHz or so it takes about 4 hours to complete - a V20 maybe half that. It's still a long process.

The version I have somehow has lost its internal hashes, or maybe that's a separate data file, I don't know.

This is a frame capture from the test running on a real V20, so we can use the 'found' hashes as truth.

#retrocomputing #emulation

I also started working on the Rust version of the code generator.

I've decided to replace MartyPC's V20 with this first. MartyPC's 8088 is pretty damn good already, but its V20 is pretty inaccurate, cycle-wise, so this will be a decent improvement, and I don't have to worry about breaking Area 5150 since it doesn't run on a V20 anyway.

I decoded a bit more of the group decode ROM.

The last four bits are not status outputs, they are an instruction family selector.

Some of these are useful - here's IO operations, at 1111, which was conspicuously missing before, so that's good.

Seeing things like DAD is also good because that has special flag behavior. I was able to use these families to eliminate several of the hardcoded opcode checks in the code.

The 8088 can request a bus cycle and then the EU pauses until it is complete.

The V20 is designed around the idea that stalling the EU should be avoided, so its bus requests are asynchronous for the most part, with a synchronization flag confusingly called F.

Two bus operations can be in flight at the same time. Is two things enough things to have a queue of things? I'm calling it a bus request queue anyway.

Like the 8088 the V20 has to calculate the address to put on the bus at T1 before a bus cycle can begin, and this takes time, but this design allows the address calculation to happen while other stuff is going on instead of making the EU come to a screeching halt.

The V20 has a fairly clean design, with its own set of edge cases.

It's different from the 8088 in little ways, but in ways that were far less annoying to figure out.

trying to make diagrams of what is going on but i am bad at diagrams.

there's a suggestion of a newly discovered register - the queue read latch, but it could also just be something really strange and weird about the instruction queue timing. modelling a separate latch makes the cycles line up.

A productive day. The NEC V20 microcode emulator now passes my hardware-generated V20 test suite, 100%.

That means for every single captured cycle, everything matches: from bus status and queue operation signals, memory reads, writes, code fetches, undefined flags. Everything.

For over 93 million cycles over 3 million instruction tests.

#retrocomputing #emulation

someone should make an interposer board that lets you stick a V20 and an 8088 in your PC and switch between them with a physical switch or something

Using an idea from dreNorteR i'm writing a program that will detect if you're running on an emulator with a V20 or actual hardware (at least, any emulator that isn't emulating the V20 microcode).

If I wanted to be evil I could submit it as a bug report

#retrocomputing

the JCXZ instruction jumps if CX is 0.

my test set for JCXZ never sets CX to 0. Whoopsie.

WR typically has to calculate an address for the write and that incurs a delay.

But if you've already resolved IND and OPR, it appears as if that resolves the pending write address and the V20 can just yeet it immediately.

This is the secret sauce for how the V20 keeps the bus full with string operations while the 8088 sits there peeing on its hands for 6 cycles per iteration. It's pipelining the address calculations.

NEC you freaky.

Here's a cool optimization on the V20 I'm calling write forwarding.

I can call it whatever I want. If you want to call microcode stuff something then decode your own microcode.

This is from the MOVSW instruction:

0A51: SI -> DP                    ---  EC=MR
0A52: SIGMA -> SI   DI -> tmpB    ---  ALU ADD, tmpC
0A53: DI -> DP                    --E  EC=MW, SR=ES

The V20 has a register, OPR, which holds the results of bus operations. Duh. But notice here, there's no OPR. That's odd.

What's happening is that we can pipeline the bus requests. EC=MR requests a read operation from the BIU and before it even starts EC=MW requests a write.

So where the hell is OPR? Well the key is we don't actually need the value. MOVSW just copies it blindly.

So as best as I can tell, if you queue a read and a write back to back the result of the read just goes right back out the write, automatically.

write forwarding. fuck yeah.

The V20 appears to have some pipelining going on, which is fun. The EU can continue in some cases while a bus request is in progress, whereas on the 8088 it would always stall.

This is going to make for an interesting article contrasting the BIU timings between 8088 and V20.

The V20's read displacement timings are funky.

Now begins the long slog of making the core cycle-exact.

You might think running the microcode successfully would give you a cycle-exact emulator, but not necessarily.

You still have to model the various cycle timing details in decoding, prefix handling, EA calculation, and potential bus-gated microcode operations.

My entry for this years GB Pixel Art Jam! The theme was the number 3. As always, it needed to run on original hardware (ie. 4 colours, 160x144px, 192 unique tiles).

The number 3 of course made me think of the Triforce, but instead of doing the Triforce itself, I thought it might be fun to try doing a snapshot of the creation myth depicted in The Legend of Zelda Ocarina of Time.

I think it turned out pretty decent given the time constraints. Hopefully next year the jam won't fall directly on thanksgiving weekend. xP

https://clumsygolem.itch.io/gb-pixel-art-jam-2026-goddesses

#PixelArt #Jam #Gameboy #Zelda #FanArt #ClumsyArt #MastoArt

Every time I test out AlleyCat in an emulator I get stuck playing for a few minutes.