mos6507's Blog - Menu in progress

[RSS Bot]

What's going on now is I've submitted a kernel variation to Delicon that uses queues for the color register changes per row, and I added a function call that sends the user input registers to the ARM on each frame. So really the ARM can pretty much take over the VCS to drive the menu. The only thing it isn't doing is generating any audio, which could be added if it were deemed important

 

Prior to this I was doing a rather lame attempt at debouncing the console switches. I have my own notion of how to handle the menu navigation which I thought I'd share here. Maybe I could get some feedback. Delicon wasn't thrilled with it but I think people should be able to get used to it rather easily if they think of the switches more like keys on a keyboard. It's like working with shift keys or the two mouse buttons. Normally when you click it doesn't do anything unless you realease the button.

 

The goal was to make the menu generally navigable with just the select and reset switches. So I have to implement "chording". So instead of doing things on "switch down", I'm doing it on "switch up". The advantage here is I can get four different scenarios. switchup on reset, switchup on select, switchup on reset (with select still held down) and switchup on select (with reset still held down).

 

So I was intending to have this meaning:

 

reset = move highlight down

select = move highlight up

 

reset (with select down) = page next

select (with reset down) = page previous

 

Then there is a need for an "enter" or "select" function. This could be triggered by any trigger button, which means the joystick triggers or any paddle. But that would still leave the keypad controllers out of the mix. I don't think the ARM is going to be able to process the keypads.

 

I have debated trying to autodetect controllers but I really don't think it's possible. You can do something like have the user hold down a button on powerup but if he doesn't do something like that then there are not enough hints to tell the VCS what's connected.

 

At any rate, even with Chimera queues I don't think there is room for a paddle read in the kernel.

 

So what I was thinking of doing is only allow the page next and previous events to fire when the highlight is at the top row. That would make sense since the highlight would pop back to the top as you page anyway. The top row would have some kind of header text so you wouldn't ever select off of the top row. Then when you move the cursor down, either switchup event with the other switch down would be interpreted as enter.

 

I didn't really want to get any other console switches invovled because they aren't momentary and you'd wind up fiddling with them after the game loads.

 

Opinions welcome.

 

http://www.atariage.com/forums/index.php?a...;showentry=5042