The apparent system timer halt is very strange – I just looked at the schematic and the system timer clock depends only on signals which are coming straight from the 8284, so NMI shouldn’t be able to affect it. Are you by any chance doing 2 interrupts per frame (9956 count) and getting a skipped interrupt due to running with interrupts off for ~8ms? Otherwise it sounds like a faulty 8253, which is sometimes going into the wrong phase. If you’re using mode 3, it might work better in mode 2.

Unfortunately, I discovered last night that the PCjr palette register mechanism will output random garbage while the palette change is in progress, which is likely why they built a hardware vertical retrace interrupt into the system — so that you could change the entire palette without affecting the picture. So they traded one type of “CGA snow” for another…! And your tricks for getting the system into lockstep don’t work on PCjr, it has a completely different DRAM refresh mechanism that is handled by the video circuitry. Finally, I found that something — I’m not sure what yet — can actually halt the system timer for short periods of time on PCjr (likely something to do with the NMI). I had a border change built into the interrupt so I could see where it was firing, and at some point after some keyboard and joystick handling, it started firing in the middle of the screen!

In other words, I’m not sure what kinds of raster effects are possible with these glitches, but I’ll experiment.

The PCjr is likely easier to get into lockstep *because* it doesn’t have DMA — everything is handled by the CPU. But I’m going to go back to PC+CGA programming before I try to get that deep into PCjr.

PCjr has a real hardware one! Why am I not using it? I know you know the answer :-) but for those not familiar with what we’re doing: Because I want slightly more time to do things before the screen starts drawing. I programmed PCjr’s VINT (IRQ5) to change the border color so I could see where it was firing and I saw nothing, which means it really is firing right as the beam is going back up the screen. However, there is a border around the drawable area, so by making my own interrupt that fires right after the last scanline is drawn, I get some extra time to do things “invisibly” as long as I’m not changing the border color itself.

Code for timing when to start the interrupt:

Procedure InitChannelCGAVINT(channel,accessMode,mode:byte;divisor:word);
const
  chan0base=$40;
var
  modecmd,lobyte,hibyte,chanport:byte;
begin
  {check for valid input allowed:
    only channels 0 and 2 (1 is for DRAM REFRESH, do NOT touch!)
    only accessmodes 1 through 3 (0 is not an access mode)}
	if not (channel in [0,2]) or not (accessMode in [1..3]) then exit;
  {precalc how we're going to set the channel, so we don't tie up too much
  time with interrupts turned off}
  modecmd:=(channel shl 6) + (accessMode shl 4) + ((mode AND $7) shl 1); {bit 0 always 0 for 16-bit mode}
  lobyte:=lo(divisor);
  hibyte:=hi(divisor);
  chanport:=chan0base+channel;
  {must make these changes atomic, so disable interrupts before starting}
  asm
    {get to end of display cycle}
    mov   dx,m6845_status
    mov   bl,c_vertical_sync
    mov   bh,c_display_enable or c_vertical_sync
    mov   ah,c_display_enable
    mov   cx,199
    pushf
    cli
  @WDR:
    in    al,dx
    test  al,bl
    jz    @WDR  {wait if not vertically retracing}
    {Now we are tracing back up the screen.  Wait until first scanline.}
  @hor1:
    in    al,dx
    test  al,bh
    jnz   @hor1 {wait until not horizontally or vertically retracing}
    {Now we are drawing our first scanline.}
  @hor2:
    in    al,dx
    test  al,ah
    jz    @hor2 {wait until horizontally retracing}
    loop  @hor1 {loop 199 more times}

    {set new rate}
    mov     al,modecmd
    out     CTCModeCommandReg,al
    xor     dx,dx
    mov     dl,chanport
    mov     al,lobyte
    out     dx,al
    mov     al,hibyte
    out     dx,al
    popf
  end;
end;

So anyway, I decided to just take the same route as the Amiga/C64 programs: I’d just read the raw sectors of the disk and write them back to another disk. Much to my surprise this actually worked: the copied disk would boot and play just fine. Apparently there was no real copy protection, just ‘security through obscurity’.

I have later found cracked copies of the game though, where the crackers turned the bootable disk into a regular EXE file which could be run from MS-DOS. Now that’s some nice cracking. Reminds me of those C64 crackers who would convert a multi-part game on tape to disk (or vice versa), or some would even take a two-sided disk, and crunch it to fit on a single side.
I suppose Demonlord is such a guy.

But I joined the PC world when XTs at 9.54 MHz were all the rage. Mine could switch back to 4.77 MHz, but I have no idea if it would be cycle-exact to the original PC. At that point it wasn’t revelant anymore anyway.
I know that everything I had since then could be tweaked in the BIOS, with all sorts of waitstates, shadow rom and all that, which greatly affected performance. So even if you had two identical machines, there was no guarantee that they’d perform the same. In fact, part of the whole PC experience was to maximize the performance by getting the right hardware, and then finding the most optimal settings. Especially in the 486-age, out-performing your friend’s machine was the thing :)

While different machines operated differently, just about every 4.77MHz 8088 system with a CGA card (IBM or clone) operates identically to each other. I can see the benefit of creating a class-specific emu just like any other C64, A500, etc. emu. The only difference being that the C64 etc. emus had classes of only one member :)

Dosbox takes too much liberty though, not bothering to do any timing for instructions for example (they’re all ’1 cycle’ within the emulation logic). But I think PCEm does a nice job. The speed is comparable to a real PC with a similar configuration. And that’s about as good as it ever got anyway.

I was thinking of dedicating a table (for hardware) and a few bins (for software) where the table has an IN and OUT end, and the bins are IN and OUT as well (OUT software means it’s been imaged properly and is ready for dissemination).

physical computers, on the other hand, are relatively incompressible, at least if they are to remain functional. :)

since surplus unix workstations started following me home in the late 90s, I’ve been wrestling with reconciling reality with my dreams. systems that are currently powered up and performing useful work are one thing, but when systems have sat on the shelf for the last decade collecting dust, it’s increasingly hard to justify keeping them. (which of course makes me want to get some sort of rotation schedule in, but I’m just kidding myself…)

I completely empathize with you, and share in your gut-wrenching feelings of retroactively losing potential knowledge.

One thing I did was decide if something’s genetics were worth preserving, and I made an executive decision to kill all hardware that used those miserable Dallas chips (ex PS/2 Model 35/55/65). I did a couple of Dallas grind/peel/solder mod jobs to fit a CR2032 carrier off some junk Pentium mobo, but the effort was too much for the gain. When you’re young, time is unlimited and “I’ll get to that someday” projects are easy to accumulate, as you get a bit older you realize time is a limited resource, and all those shelved projects have become a psychological drain. Once removed from sight, I found my mood improved considerably

I also made an executive decision to kiil scads of genericlone adapter cards. How many unidentifiable driverless IDE paddle cards do you need? My answer was zero. I kept several ST01′s, and various Adaptec and Future Domain cards I could find drivers for, and a the oddball stuff like caching IDE controllers.

I read your page on the Editors. Consider using an EGA card rather than CGA. No “snow”. The switches on the EGA can be set so it’ll emulate a CGA and drive a CGA display. It can even be configured with the switches to drive the monochrome displays. The EGA driving CGA display doesn’t need the memory daughter card, a non-upgraded basic 64k EGA can drive the CGA display.

If you’ve got a Hercules Plus card laying around, the Brief editor can be configured to do a 43 line mode with that card too. Its not super fast, but those extra lines make quite a difference in your visual perception of code when programming. 25 lines isn’t a lot of visible context.