Moving games to the 5200

[vitoco]

The difference of the O.S. (BIOS) between the A8 and the 5200 is known, and moving something from the 5200 to the A8 needs some adjustments because some things are not in the same place, but almost all the required features are available. But going in the opposite direction needs much more extra work, because there are lots of things missing or incomplete in the 5200.

 

I've read lots of docs and sources, including the equates (*.inc) for both systems, Transporting Atari Computer Programs to the Atari 5200 (ANALOG #15 article by Claus Buchholz), the 5200 BIOS (which is a bit different from PAM OS Source), Altirra sources and some 5200 games using Altirra's debugging tool.

 

With these, I've done some mappings, reassembled and run successfully in 5200 mode of Altirra, but I don't want to reinvent the wheel for the required VBI, NMI, IRQ, or whatever is still missing, like full shadow registers management.

 

Is there some work with sample code already published about what must be done to give the 5200 the compatibility for the missing features like the shadow registers?

 

Also, could it be better to bypass the 5200 initialization and to include a whole new BIOS in the cart with all the required A8 features?

 

Thanks for any hint or link...

 

[phaeron]

Most of what you're missing probably is not applicable for the 5200 anyway. IRQ usage is mostly limited to keyboard, which will have to be rewritten anyway. You can't replace the NMI dispatcher and a fair amount of stage 2 VBI like input handling and OS timers is also largely non-applicable. Memory is also at a premium with only 16K available. The compatibility layer for interrupts should be short, maybe a couple of pages of asm. Hopefully the programs you're targeting don't need CIO and E:/S:, which you could bring over but are fairly large.

 

[Wrathchild]

Not sure how you've missed this thread?

 

Will PM you.

[vitoco]

33 minutes ago, phaeron said:

Hopefully the programs you're targeting don't need CIO and E:/S:

I'm trying to provide the enough environment for Fastbasic programs to run in the 5200, the integer version for the moment (still deciding on floating point version, because it could also require to provide some FP libraries). I've discarded all CIO handling, provided basic text modes for GRAPHICS statement with simplified routines to print text through standard POSITION and PRINT statements. No PLOT and DRAWTO though...

 

At the moment, I've been able to crosscompile and run a couple of demos, but before going into the mappings for the controllers, I need to include some missing A8 items in the interrupts, like the shadow registers for the triggers, and an equivalent for the COLRSH register, which it is required by Fastbasic's DLI feature.

 

I should provide some extra management for the controller's keyboard handling, reading one of them on each VB or something like that, and provide access to those values from shadow registers using Fastbasic builtin functions.

 

I just want to make it easier to novice programmers to get into the 5200, just like bB does for the 2600 and 7800.

 

3 minutes ago, Wrathchild said:

Not sure how you've missed this thread?

I didn't miss that, but my work is focused in Fastbasic... I think that it is also available through WUSDN, right?

 

If your hint was AlienSwarm, thanks... I'm on it.

 

[vitoco]

I decided to keep the NMI and IRQ handlers from the 5200 console, but I'm quite frustrated.

 

I added a deferred VBI to handle some of the required feaures, and that seems to work OK, but problems started when I tried to manage the keyboards, starting with the one of port 1 only.

 

I set up a small keyboard routine for the NMI and sometimes I can read all the keys I press, including the 2nd action button, but sometimes I can read just the first key I press, and then nothing!!! There is no interrupt for the following keys. The only difference is that DLIs are enabled when they don't work.

 

I've set in Altirra some write breakpoints into registers like IRQEN to find unintended bit changes, but now I'm thinking that there is some correlation of events I'm not aware.

 

Hints?

 

[phaeron]

Use the .pokey debugger command to check the IRQ enable state. The 5200 hardware design fires lots of IRQs as long as a key is pressed, so you should be seeing the IRQ handler get called even if you miss an interrupt.

 

One way this can get screwed up is if you stomp POKMSK. In that case, the IRQ enable state doesn't get scrambled until after the next interrupt.

 

Also, there is a subtle but important difference in the 5200's VBI deferred processing: it happens with IRQs still masked and isn't bypassed even if the I flag is set on the stack. This means that unlike the computer OS, the 5200 OS will allow (VVBLKD) to run in the middle of an IRQ handler, and in particular, the deferred keyboard handler (VKYBDF). If this causes problems then you will need to have the (VKYBDF) handler wrap its critical code in INC CRITIC/DEC CRITIC to avoid data races.

 

[vitoco]

6 hours ago, phaeron said:

Use the .pokey debugger command to check the IRQ enable state. The 5200 hardware design fires lots of IRQs as long as a key is pressed, so you should be seeing the IRQ handler get called even if you miss an interrupt.

Thanks! That gave me a hint of what was happening.

 

The problem was that Fastbasic runtime was resetting SKCTL register and enabling the debounce bit each time I played a sound.

 

6 hours ago, phaeron said:

One way this can get screwed up is if you stomp POKMSK. In that case, the IRQ enable state doesn't get scrambled until after the next interrupt.

This is from 5200 ROM:

;Keyboard Interrupt
    lda  #$BF     ; (this is $40 EOR $FF)    
    sta  IRQEN    ;Clear IRQ
    lda  $00      ;Get POKMSK
    sta  IRQEN    ;Set IRQEN from shadow ($40)
    jmp  ($0208)  ;Jump to Keyboard IRQ vector

Which is the idea behind the double store in IRQEN, once with the inverted bits and once with the value at POKMSK? This happens on every kind of interrupt.

 

[Rybags]

IRQs can be concurrent and it's up to the interrupt handler to prioritize and execute them in order.

By setting a bit to zero in IRQEN that clears the particular IRQ, then you store the shadow value which potentially reenables it.

 

If you just processed the IRQ without doing that it'd keep triggering the same one.

[vitoco]

What about the multiple keypads? Can each joystick create its own keyboard IRQ? What happens when a key is pressed almost at the same time on different joysticks? Does this depends on the current bits set in CONSOL register to select a keypad? What should I expect when checking bit 3 (key still pressed) of SKSTAT?

 

BTW, I'm iterating through all the controllers by changing bits 0 and 1 in CONSOL (yes, four controllers), one per frame, through the deferred VBI.

 

Thanks for the help!

 

[phaeron]

2 hours ago, vitoco said:

What about the multiple keypads? Can each joystick create its own keyboard IRQ?

No, you have to multiplex this yourself. The keypad scans are just a slightly abused POKEY keyboard scan, which only has one set of keyboard IRQs.

 

2 hours ago, vitoco said:

What happens when a key is pressed almost at the same time on different joysticks? Does this depends on the current bits set in CONSOL register to select a keypad?

Nothing happens, only the keypad that is currently connected to POKEY via the CONSOL bits matters. POKEY's keyboard scan only sees the keypad from the controller that CONSOL has selected.

 

2 hours ago, vitoco said:

What should I expect when checking bit 3 (key still pressed) of SKSTAT?

SKSTAT bit 2 doesn't work for 5200 controllers (bit 3 is the latched SHIFT state).

 

In normal mode, POKEY double-checks keys before reporting them in IRQST and KBCODE. The keyboard scan has four states, and in the first state when it sees a key it latches that key's code into the comparison register. On the second pass, it confirms this key if it is still pressed, asserting the IRQ and latching the code it KBCODE. Similarly, it takes two more states for POKEY to confirm a key up. SKSTAT bit 2 is simply the high bit of this state.

 

The 5200, however, requires debounce turned off, which disables the comparator. This means that instead of checking for the same key on the next scan pass, it checks the very next key as the "confirmation", which always happens because the keypads only hook up bits 1-4 and thus every key is seen by POKEY at N and N+1. This is why debounce is off and must be off to read 5200 controllers. But this also means that POKEY sees and reports a key up on the next two counts N+2 and N+3 instead of two full scans -- the software+hardware configuration causes POKEY to see a constant stream of key ups and downs and on a real 5200, you will not see SKSTAT bit 2 stay low even while holding a button.

 

2 hours ago, vitoco said:

BTW, I'm iterating through all the controllers by changing bits 0 and 1 in CONSOL (yes, four controllers), one per frame, through the deferred VBI.

POKEY's keyboard scan counts 0-63 every scanline, so waiting a full frame guarantees (more than) a full scan and you should be good. Do mind your order of operations, you want to make sure that the keyboard IRQs are reset after changing CONSOL and read out before changing it again.

 

Strictly speaking, you should only need just over 32 scanlines for the keypad, since bit 5 is a don't care in the matrix. However, the top button is connected to Ctrl/Shift/Break, and for that you need a full scan to hit $00, $20, and $30, respectively to latch the top button state.

 

[vitoco]

Thanks for all that info... I could write a deferred VBI to map all the controller buttons into shadow registers and map almost all of them to existing Fastbasic functions. To test them, I wrote a small program that checks for every input using that functions. Cartridge image attached...

 

On 5/17/2021 at 3:34 PM, phaeron said:

Quote

What should I expect when checking bit 3 (key still pressed) of SKSTAT?

SKSTAT bit 2 doesn't work for 5200 controllers (bit 3 is the latched SHIFT state).

A typo... I meant bit 2 as you pointed out. Because of that, I had to replicate the CH, CH1 and KEYDEL shadow registers for each of the four controller's keypads.

 

On 5/17/2021 at 3:34 PM, phaeron said:

Do mind your order of operations, you want to make sure that the keyboard IRQs are reset after changing CONSOL and read out before changing it again.

I found that sometimes a pressed key from one stick was also assigned to the next one. To avoid that, I finally had to disable all the IRQ at the beginning of the VBI and reenable using POKMSK ($40) at the end, with the change of CONSOL in between. Even though this seems to work in Altirra, my test program was run in real hardware and it still happens. How could I be sure that the keyboard was readout before changing CONSOL?

 

On 5/17/2021 at 3:34 PM, phaeron said:

Strictly speaking, you should only need just over 32 scanlines for the keypad, since bit 5 is a don't care in the matrix. However, the top button is connected to Ctrl/Shift/Break, and for that you need a full scan to hit $00, $20, and $30, respectively to latch the top button state.

I'm not sure I understood that statement.

 

BTW, there is a strange behavior with the 2nd button of the sticks. Even though I could read them and assign to shadows, when I perform a Cold Reset (pressing Shift-F5 in Altirra), it seems that bit 3 of SKSTAT remains high even when bits 0-1 of CONSOL change, so all the upper triggers appears as pressed... until one of them is really pressed. It seems to be an issue in Altirra due to the fact that the Shift key was pressed at the moment of the Cold Start. It does not happen when I use the option from the System menu.

 

Thanks again!

 

iotest.car

Edited May 19, 2021 by vitoco
bit 3 = value 8