druellan wrote: ↑Tue Oct 12, 2021 11:29 am
Is there a way we can detect support for Fuller Box searching for some hexa in the code?
Reading the Fuller joystick involves IN 127 so I'd search for bytes $DB,$7F
Writing to the sound chip involves OUT 63 and OUT 95. As the data port is more likely to be used I'd search for bytes $D3,$5F
Writing to the speech chip (Orator) involves OUT 159,so I'd also search for bytes $D3,$9F
Ideally you need games in .tap or .sna format to make searching easier. Unfortunately a lot of games decrypt themselves once loaded so the snapshot route is probably more reliable. For now I've made do with converting all .tzx files to .tap where possible. Unfortunately it won't convert hyperloaders but in my case most compiled games don't use them (I was searching all games to see which were compiled with MCoder 1, MCoder 2, Softek, etc..)
druellan wrote: ↑Tue Oct 12, 2021 11:29 am
Many of his games have support. Not sure if he had a relation with Fuller or just he owned a box and liked it.
Fuller wasn't around by the time Andy Capp was released, so I guess he just owned a box. Other companies in the past were probably given one to use - I'm thinking Imagine here. Other authors such as Jon Ritman and Simon Brattel probably just owned one.
I own a standard Fuller unit (no speech) and they are good (if a little too loud). This is why I try and add support for the Fuller joystick in my I/F2 carts - it's an interface where i can't just redefine the keys to work (like ZX Interface 2, Cursor, AGF/Protek, DKTronics). I saw in Vectorball a useful Fuller conversion routine where the bits of the Fuller joystick are mirrored (bit 7 to 0, bit 6 to 1 etc.) and then passed to the Kempston routine. Unfortunately their version didn't work, but the logic was sound and I have used it in a few other games as it doesn't require many bytes.
so it's unlikely to make it out in 2021.
