Crazy to think how things would have been different if all of the various techniques and mysteries of the CoCo we understand now had been compiled into a book and sent back in time to the 80s.
the understanding of old hardware has only really become possible to the level it is today through the help of emulators, though much of it could've been better utilized at the times when they were cutting-edge if more behavior was documented and if developers had had more time to get familiarized with the hardware they were working with. many games were developed with minimal documentation and very little time to work with, as many games were scheduled to come out alongside or shortly after consoles' releases, giving developers very tight schedules and little time to get well-acquainted with their hardware. what's possible with modern understanding of old technology is quite mindboggling though, see kaze emanuar's work on super mario 64, or for a better comparison to the coco, see selicre's databurst, a super mario world romhack that does things that simply should not be possible on real hardware.
I remember all the cool projects in the Hot Coco Magazine and The Color Computer magazines back in the day. I always wanted to build the seismograph or the Armatron robotic arm project but never did. Amazing stuff for this youngster. The possibilities really are endless with that joystick port. Instead I spent my time with my uncle making some of the best BASIC entertainment the world will never know. P.S., I was probably the first person in the state of Oregon to beat Dungeons of Daggorath.🙂
Plenty of CoCo memories for me as well. Interestingly, many of them involve my uncle as well. He was the only member of my family who shared my interest in computers.
One small suggestion. Try storing the three possible axis results as either a negative, zero or positive ie. left = -1, centre = 0, right = 1. When you read JoyRX the condition code bits will be set, enabling you to BMI, BEQ or BPL etc. without needing comparisons. Also substituting TST with either LDA or LDB will save a couple of cycles. Hope this helps. 🙂
The whole -1,0,1 thing is definitely something I should be doing. I know better! I don't know why I did 0, 1, 2. Using LDA/LDB instead of TST where possible is a great idea that I hadn't considered, so I double-checked cycle counts. Sure enough, TST extended is 7 cycles, and LDA/B extended is 5 cycles. Seems kind of crazy that an opcode that does "more" (a load + condition code setting vs. just condition code setting) takes fewer cycles. I'm sure there's an excellent hardware-design reason for that, but I don't know it. 😁
I have a suspicion that once you test with real joysticks, you're going to need to make your routine a slight bit more complicated to avoid jitter on the boundary values due to noisy and/or dirty pots in the joysticks. Which will make your routine marginally slower but still substantially faster than the ROM routine.
Thx for the mention :)
Crazy to think how things would have been different if all of the various techniques and mysteries of the CoCo we understand now had been compiled into a book and sent back in time to the 80s.
the understanding of old hardware has only really become possible to the level it is today through the help of emulators, though much of it could've been better utilized at the times when they were cutting-edge if more behavior was documented and if developers had had more time to get familiarized with the hardware they were working with. many games were developed with minimal documentation and very little time to work with, as many games were scheduled to come out alongside or shortly after consoles' releases, giving developers very tight schedules and little time to get well-acquainted with their hardware. what's possible with modern understanding of old technology is quite mindboggling though, see kaze emanuar's work on super mario 64, or for a better comparison to the coco, see selicre's databurst, a super mario world romhack that does things that simply should not be possible on real hardware.
I remember all the cool projects in the Hot Coco Magazine and The Color Computer magazines back in the day. I always wanted to build the seismograph or the Armatron robotic arm project but never did. Amazing stuff for this youngster. The possibilities really are endless with that joystick port. Instead I spent my time with my uncle making some of the best BASIC entertainment the world will never know. P.S., I was probably the first person in the state of Oregon to beat Dungeons of Daggorath.🙂
Plenty of CoCo memories for me as well. Interestingly, many of them involve my uncle as well. He was the only member of my family who shared my interest in computers.
One small suggestion. Try storing the three possible axis results as either a negative, zero or positive ie. left = -1, centre = 0, right = 1. When you read JoyRX the condition code bits will be set, enabling you to BMI, BEQ or BPL etc. without needing comparisons. Also substituting TST with either LDA or LDB will save a couple of cycles. Hope this helps. 🙂
The whole -1,0,1 thing is definitely something I should be doing. I know better! I don't know why I did 0, 1, 2. Using LDA/LDB instead of TST where possible is a great idea that I hadn't considered, so I double-checked cycle counts. Sure enough, TST extended is 7 cycles, and LDA/B extended is 5 cycles. Seems kind of crazy that an opcode that does "more" (a load + condition code setting vs. just condition code setting) takes fewer cycles. I'm sure there's an excellent hardware-design reason for that, but I don't know it. 😁
I have a suspicion that once you test with real joysticks, you're going to need to make your routine a slight bit more complicated to avoid jitter on the boundary values due to noisy and/or dirty pots in the joysticks. Which will make your routine marginally slower but still substantially faster than the ROM routine.
That would not be surprising! But that is a problem for future-me.