Commander X16

StephenHorn wrote: ↑Thu Jun 01, 2023 2:53 am

ch4rl3sb wrote: ↑Thu Jun 01, 2023 1:56 am I'm talking about "barriers to entry," here.

If I may offer some folksy wisdom from decades spent in my craft: It is very easy for people, who are already familiar with an otherwise inscrutable concept, to completely glaze over its difficulty after years or even decades of experience with it. In the case of retro computing this is literally multiple decades, and even some of the more liberal definitions of many decades.

...But unless I were writing the math library documentation myself, from scratch, with an eye towards complete and total newcomers to the field of programming as a whole, I would still have likely glazed right over the FACC. This is because my own multiple decades of experience made the concept completely obvious. That isn't meant to say it's obvious to everyone (or even should be), only that my own brain was already so familiarized with the idea that it didn't skip a beat. Knowledge and experience transferred with total transparency.

I'm sorry you struggled to figure out the FACC for a long time, and I wish you'd asked about it here on the forums or the Discord server sooner. Please don't hesitate to ask questions: Our first rule here is "Comment with kindness", so we take our positive attitudes and helpfulness seriously...

THIS! EXACTLY!

Most people are trying to be very helpful. But even then, it can sometimes feel like...
(Dusting off a tattered, ancient book,) "Here's the tome of arcane lore... what you're looking for should be in here... somewhere... if you can decipher the script and cryptic references."

So... with all that.

Does anyone have a clue why suddenly an irq handler that has worked since the beginning would suddenly not be setting the flag that helps me time my game?

Oh, and are R41 and R43 running near 8mhz natively, now? when I removed the timing irq, my spaceships sped across the screen much faster than I was anticipating, since previously, my code wasn't actually completing in one frame.

StephenHorn wrote: ↑Thu Jun 01, 2023 2:53 am And please feel free to help us identify documentation that needs to be written, or that is difficult to parse and understand. We're too close and too familiar with the project and its inner workings, we are going to miss things without help from folks who need the documentation the most.

Another thing that would be helpful for the Kernal and Math functions is a note as to cpu cycles used. (approximately). Like the 6502 opcodes list for instructions. (http://www.6502.org/tutorials/6502opcodes.html)

ch4rl3sb wrote: ↑Thu Jun 01, 2023 3:11 am Does anyone have a clue why suddenly an irq handler that has worked since the beginning would suddenly not be setting the flag that helps me time my game?

Oh, and are R41 and R43 running near 8mhz natively, now? when I removed the timing irq, my spaceships sped across the screen much faster than I was anticipating, since previously, my code wasn't actually completing in one frame.

Without more details about the implementation, it can be difficult to troubleshoot problems with interrupt handler timing. As far as I'm aware, nothing should have changed in the emulators that would effect the ordinary vblank IRQ processing. The last time someone on here struggled with them, it was because they'd been enabling and hooking up the interrupt handler without wrapping the relevant section in an sei/cli pair of instructions. sei disables IRQ handling on the CPU, cli reenables it. Failing to do this means engaging in a race that you might win most of the time -- until you don't.

I'm not sure what you mean when you're asking if r41 and r43 are running near 8MHz natively. x16emu and Box16 have always attempted to emulate the CPU running at 8MHz, except under very specific circumstances that have to be enabled through a command-line switch or user interaction. However, the emulators have a lot of work to do in a 60hz frame, and most of it needs to happen in a serial fashion, with VERA emulation being the majority of that work. Ultimately, this means that the majority of folks who are able to reliably run the emulators at full speed are those with relatively powerful machines to run the emulators on. Blame that 640x480@60Hz display with its two background layers, 128 sprites, and no limits on what properties can be poked or when... it's what I do, and trying to do substantially better is probably going to require a rewrite and maybe even a whole re-think.

StephenHorn wrote: ↑Thu Jun 01, 2023 8:55 am
Without more details about the implementation, it can be difficult to troubleshoot problems with interrupt handler timing. As far as I'm aware, nothing should have changed in the emulators that would effect the ordinary vblank IRQ processing. The last time someone on here struggled with them, it was because they'd been enabling and hooking up the interrupt handler without wrapping the relevant section in an sei/cli pair of instructions. sei disables IRQ handling on the CPU, cli reenables it. Failing to do this means engaging in a race that you might win most of the time -- until you don't.

Interesting thought. But, it appears to initialize properly, but locks in an infinite loop when it tries to use the timing. i.e. irq handler sets flag to 1. regular code runs all functions through once, then sets a loop to wait until flag != 0. R43 seems to get in infinite loop with flag always = 0.
Here's the (possibly) relevant code

init_irq: ;replace irq handler with custom.
sei
lda IRQVec
sta default_irq
lda IRQVec+1
sta default_irq+1

lda #<custom_irq
sta IRQVec
lda #>custom_irq
sta IRQVec+1
lda #01 ; make VERA only generate VSYNC IRQs
sta VERA_ien
cli
rts

custom_irq: ;custom irq handler.
@check_line_irq:
lda VERA_isr ;check for line irq set.
and #$02
beq @check_vsync
@handle_line_irq: ;for later use
lda #02
ora VERA_isr
sta VERA_isr
@check_vsync: ;check for Vsync irq set.
lda VERA_isr
and #$01
beq @continue
@handle_vsync_irq:
lda #01
sta vsync_set ;1/60th sec timing.
sta ZP_PTR_4
ora VERA_isr ;reset this irq
sta VERA_isr
inc jiffy_count
@continue:
jmp (default_irq)

__restore_irq: ;restore irq handler.
sei
lda default_irq
sta IRQVec
lda default_irq+1
sta IRQVec+1
cli
rts

Is there some documentation for using the debugger so I could check where it actually hangs and values etc.?

Uh, I think the issue is you're turning on VERA's line irq and leaving it on.

It's OK to turn on the vsync irq on and leave it on... that one is supposed to go to the default handler once every 60th of a second, it needs to do that to process the mouse, kyb, etc. But if you try to do that with the line irq, it will blast you with 480 times more interrupts and bring the default handler to it's knees.

If you need to use the line irq, detect it and don't call the default handler. Better yet... don't use it at all unless you really need to.

Edited to add: Wait... I think I'm jumping the gun, you only seem to be writing $01 to VERA_ien... which should be ok. You're only checking the line irq, which should never hit.

I dimly recall there being some PRs having to do with VERA IRQ triggering and line IRQs... ah, yeah, found the change that matters in the emulation code. In January this year (2023 for time travelers from the future), a change went in to match emulation behavior with hardware behavior. On VERA hardware, the ISR bits are set regardless of the state of the IEN bits -- IEN only controls whether VERA generates an interrupt request to the CPU when certain ISR bits are set.

Previous to that change, the relationship in the emulator was the other way around, and IEN bits would control whether ISR bits could ever get set, and VERA would generate interrupt requests if any bits in ISR were set. This means the line interrupt bit is pretty much guaranteed to be set most of the time -- it just doesn't generate interrupts anymore unless the appropriate IEN bit is set.

So what's happening now is that your interrupt handler is entering its line IRQ section, where it didn't before. And the line IRQ section is bitwise-OR'ing the accumulator with the VERA ISR bits before storing the result back into the VERA ISR register. This means the accumulator will have all the VERA ISR bits set, in addition to the bit from the lda #02 immediately beforehand (or maybe it was supposed to be lda #$02, except it's the same value in this case). The subsequent store into VERA ISR is then resetting all the IRQ bits, so when the IRQ handler falls into the vsync IRQ logic, the ISR bit it's checking for is gone.

It's unfortunate we had the wrong behavior in the emulator for as long as we did, and only fixed it in January 2023. I'm fairly certain the line IRQ portion of the bit handling bug dates back all the way to when line IRQs were implemented, but I'd have to do some fairly involved code archeology to determine how far back the more general interrupt generation and bit management bug goes -- suffice it to say, the emulator has been generating interrupt bits and interrupt requests in a subtly incorrect fashion for a long time.

What changed to expose the bug was that the VERA's implementation is now fully open-sourced and has more community eyes on it, meaning that more people than just VERA's original creator can understand its behavior and compare against the emulator. We also have a limited supply of physical dev boards now, which have also been priceless for exposing unexpected differences between the hardware and the emulators -- and unexpected hardware bugs that folks are trying to fix.

StephenHorn wrote: ↑Thu Jun 01, 2023 5:09 pmWhat changed to expose the bug was that the VERA's implementation is now fully open-sourced and has more community eyes on it, meaning that more people than just VERA's original creator can understand its behavior and compare against the emulator.

I really really like this, because I'm used to the inner workings of hardware requiring logic probes, oscilloscopes, and largely guess-and-check work. The VERA's verilog being readily accessible is so nice because you just need to be able to read verilog in order to understand exactly what the VERA does in any situation, and it means we can get the emulator closer to the actual behavior of the hardware from here on.

Haha. I was trying to preserve the state of the vsync bit by writing it back and was resetting it instead. While knowing that writing the line bit was reseting it. Silly me. Will have to see what happens when I get a chance to adjust that code.

And yes, while I was looking at this again this week, I was assuming line isr would never get set, (since I have it turned off.)