CLS 9 through 255 will print MICROSOFT - it's one of their little easter eggs.There is also a mode on Coco 1's and 2's (and works on the Dragon as well) where you can tell the SAM chip inside to double the clock speed of ROM access (and BASIC is in ROM) while leaving the RAM speed alone, which gives a good speed boost to BASIC programs (which use both). Do POKE 65495,0 to enable 1.78 Mhz ROM/0.895 MHz RAM, and POKE 65494,0 to switch it back to it's normal default 0.895 MHz for both ROM and RAM. You can try the benchmark again with that. (The Coco 3 has a separate POKE that does full double speed on both). Re: The 6309 upgrade. The chip defaults to 6809 mode and runs pretty well identical. Machine language programs (or patches to BASIC) can kick it into native mode that runs about 10-15% faster, and also use its extra instructions and commands. There are multiple games (and the OS9 operating system) that have versions that can use the 6309 to it's advantage; they can be found on the Color Computer Archive (and more will be coming as we get time to get to them). As it stands though, the 6309 only uses 1/10th the power of the 6809, so at the very least your Coco should run cooler.
Thanks for an excellent comment once again :) This I have to test. Do you know if the 6809 had any "hidden" instructions that was "miss-used" by programmers and that can cause issues with programs after swapping the 6809 out with a 6309?
@@retroandgaming I don't believe so. The 6309 added new instructions but unless the software is written for the 6309 it will be the exact same speed as the original 6809. There was a period of many years when people thought the 6309 was identical to the 6809 because Hitachi didn't release info about the new instructions. With a 6309 installed you should be able to run NitrOS-9 I think.
What I remember from The Day was that the effect of the poke is immediate (you'll see the cursor blink at double speed) but after a short while, the system would crash, presumably because of overheating. I could see where a more energy efficient chip would prevail under those conditions.
@@AureliusR - NitrOS9 has been back ported to the 6809 as well (so new features and better speed in the OS with both chips). Some games, for precise timing occasionally used illegal instructions on the 6809 for specific cycle delays; on a 6309 this triggers the illegal instruction trap which usually caused crashes. It is possible to enable native mode and run existing pure 6809 code faster (quite a few instructions will run a cycle or 2 faster), as long as the program doesn't rely on grabbing/saving registers on the the stack (only CC, A and B will be in the same spot - the new E & F accumulators are saved at that point on a 6309 in native mode, so other register offsets on the stack will offset by 2. OS9 relies on this (hence the rewrites of level 1 and 2 to produce the original NitrOS9), but most single programs don't. FIRQ is unaffected.
@@kpnconsulting8739 - From what I remember, most of the time it just required removing or changing a capacitor or resistor (sorry, don't remember the details offhand) and then they worked fine. From the Coco 1 "F" board on (including all Coco 2's), they all worked fine in double speed ROM mode, and most "D" and "E" boards either worked out of the box or just needed the little mod (I remember my D board did need to hardware update). If one had really slow RAM's, they might need upgraded to faster ones, but the ones Tandy normally used were fast enough.
Running the same code, at the same clock speed, on a 6809 or 63C09 will be identical. The 63C09 is rated for up to 3MHz clock, compared to 1MHz for the base 6809. But at the same clock speed you need some code which will take advantage of the 6309 enhancements to see any performance improvements.
@@retroandgaming @retroandgaming Indeed. I strive to learn something new every day! It keeps us young. Great to see your CoCo. I never owned one, but the 6809 has always been my favourite 8-bit processor to code for, having stared out with the Motorola 6800, then the 6809 on home built systems in the late 70's / early 80's. 🤓
CLS 9 through 255 will print MICROSOFT - it's one of their little easter eggs.There is also a mode on Coco 1's and 2's (and works on the Dragon as well) where you can tell the SAM chip inside to double the clock speed of ROM access (and BASIC is in ROM) while leaving the RAM speed alone, which gives a good speed boost to BASIC programs (which use both). Do POKE 65495,0 to enable 1.78 Mhz ROM/0.895 MHz RAM, and POKE 65494,0 to switch it back to it's normal default 0.895 MHz for both ROM and RAM. You can try the benchmark again with that. (The Coco 3 has a separate POKE that does full double speed on both).
Re: The 6309 upgrade. The chip defaults to 6809 mode and runs pretty well identical. Machine language programs (or patches to BASIC) can kick it into native mode that runs about 10-15% faster, and also use its extra instructions and commands. There are multiple games (and the OS9 operating system) that have versions that can use the 6309 to it's advantage; they can be found on the Color Computer Archive (and more will be coming as we get time to get to them). As it stands though, the 6309 only uses 1/10th the power of the 6809, so at the very least your Coco should run cooler.
Thanks for an excellent comment once again :) This I have to test. Do you know if the 6809 had any "hidden" instructions that was "miss-used" by programmers and that can cause issues with programs after swapping the 6809 out with a 6309?
@@retroandgaming I don't believe so. The 6309 added new instructions but unless the software is written for the 6309 it will be the exact same speed as the original 6809. There was a period of many years when people thought the 6309 was identical to the 6809 because Hitachi didn't release info about the new instructions. With a 6309 installed you should be able to run NitrOS-9 I think.
What I remember from The Day was that the effect of the poke is immediate (you'll see the cursor blink at double speed) but after a short while, the system would crash, presumably because of overheating. I could see where a more energy efficient chip would prevail under those conditions.
@@AureliusR - NitrOS9 has been back ported to the 6809 as well (so new features and better speed in the OS with both chips). Some games, for precise timing occasionally used illegal instructions on the 6809 for specific cycle delays; on a 6309 this triggers the illegal instruction trap which usually caused crashes. It is possible to enable native mode and run existing pure 6809 code faster (quite a few instructions will run a cycle or 2 faster), as long as the program doesn't rely on grabbing/saving registers on the the stack (only CC, A and B will be in the same spot - the new E & F accumulators are saved at that point on a 6309 in native mode, so other register offsets on the stack will offset by 2. OS9 relies on this (hence the rewrites of level 1 and 2 to produce the original NitrOS9), but most single programs don't. FIRQ is unaffected.
@@kpnconsulting8739 - From what I remember, most of the time it just required removing or changing a capacitor or resistor (sorry, don't remember the details offhand) and then they worked fine. From the Coco 1 "F" board on (including all Coco 2's), they all worked fine in double speed ROM mode, and most "D" and "E" boards either worked out of the box or just needed the little mod (I remember my D board did need to hardware update). If one had really slow RAM's, they might need upgraded to faster ones, but the ones Tandy normally used were fast enough.
Running the same code, at the same clock speed, on a 6809 or 63C09 will be identical. The 63C09 is rated for up to 3MHz clock, compared to 1MHz for the base 6809. But at the same clock speed you need some code which will take advantage of the 6309 enhancements to see any performance improvements.
Yup, I know that now :) You live and learn!
@@retroandgaming @retroandgaming Indeed. I strive to learn something new every day! It keeps us young. Great to see your CoCo. I never owned one, but the 6809 has always been my favourite 8-bit processor to code for, having stared out with the Motorola 6800, then the 6809 on home built systems in the late 70's / early 80's. 🤓