SD Card

[epaell]

When I shifted to the W6 setting I had the same garbled screen regardless of whether I had the 12 MHz or 16 MHz clock. With the W4 setting things worked fine with the 12 MHz clock but would sometimes seemed to ignore commands sent to the VDP (but the screen would not be garbled).

In other news, I was able to get OS9 running in 6309 mode. This now works on both the DIP 6309 and the PLD one - so both are actually working fine now. The fix was basically to do the same as what the coco version was doing i.e. I just created another copy of the directory and referred back to the 6809 version for the makefiles (with the addition of the 6309 definition). I'm not sure how this is different to what I had originally - perhaps I missed a definition somewhere.

Code: Select all

September 17, 2024  13:12:25
NitrOS-9/6309 Level 1 V3.3.0 on the MECB 6809  2024/09/17 13:12:26


User name?: user1

Process #05 logged on   2024/09/17 13:12:28
Welcome!

Welcome to NitrOS-9 Level 1!


Shell

OS9:cputype
CPU: 6309, running in 6309 native mode.

[Editor]

When I shifted to the W6 setting I had the same garbled screen regardless of whether I had the 12 MHz or 16 MHz clock. With the W4 setting things worked fine with the 12 MHz clock but would sometimes seemed to ignore commands sent to the VDP (but the screen would not be garbled).

Did you mean that W4 was garbled regardless of 12MHz or 16MHz, but at W6 it was fine at 12MHz?

W6 is the longer delay. So, if you did mean W6 was garbled at both 12 & 16MHz, but W4 was okay at 12MHz, then something else weird is going on! (You definately cut the W6 track?)

Either way, it would be interesting to see if a 74AHCT244 makes a difference. If you get the opportunity to try one.

In other news, I was able to get OS9 running in 6309 mode. This now works on both the DIP 6309 and the PLD one - so both are actually working fine now.

That's great (and also relieving), news!

[epaell]

Did you mean that W4 was garbled regardless of 12MHz or 16MHz, but at W6 it was fine at 12MHz?

My apologies, yes that is what I meant to write (I was jumping around between working on the 6309/6809 issue and this other issue and was getting a bit careless with my typing).

I don't have any AHCT devices on me at the moment but next time I place an order I'll include some of those as well to give this a try. It's not a major blocker and everything else seems to work fine at full speed. I just ran some speed tests and get 4.8s for 10 iterations of sieve at 16 MHz with the 6309 setting (6.4s at 12 MHz and 5.1s at 16 MHz with the 6809 setting). It seems to be marginally faster with the 6309 compared to the 6809 (for timing I ran 100 iterations just to get better timing accuracy). I guess this makes sense since in native mode some of the instructions can be a cycle or so faster compared to the 6809, neither the compiler nor the OS are really optimised for the 6309 so I guess it isn't using it to its full capacity. Either way it is giving other computers of the time a run for their money:

[epaell]

Either way, it would be interesting to see if a 74AHCT244 makes a difference. If you get the opportunity to try one.

OK, so I got my hands on a 74AHCT244 and a 74AHCT04 ... neither really made a difference. Now I'm wondering if it was because I didn't make use of the blanking period for the writing to the VDP? I didn't look into how to "gracefully" connect up to the interrupt system in NitrOS9 and so was unceremoniously shoving commands to the VDP at any old time (which I assumed would just result in some flashing of the text/sprites if it updated while the screen was still refreshing). I just rewrote my code to work on the ASSIST09 system using the interrupt-based updates and that seems to work OK under 16 MHz (4 MHz CPU) system with 32 sprites bouncing around the screen.

[Editor]

OK, so I got my hands on a 74AHCT244 and a 74AHCT04 ... neither really made a difference. ... I just rewrote my code to work on the ASSIST09 system using the interrupt-based updates and that seems to work OK under 16 MHz (4 MHz CPU) system with 32 sprites bouncing around the screen.

Interesting finding. It's really good to know that you found a solution via Interupt derived blanking period updates, and the VDP is now working fine at 4MHz!

I recall that switcing to the 74AHCT244 did help me with a speed? issue that I once saw. As I recall, I was running the CreatiVision Sonic Invader code at 4MHz (instead of 2MHz), and I noticed the explosions (which I just assumed are sprite driven), were sometimes occuring at the left of the screen instead of where they were supposed to be (as though the x position was lost).
I didn't get fully to the bottom of why this was (everything else was displaying fine at 4MHz), but changing to the faster 74AHCT244 definately resolved this particular issue for me. But, I didn't see this as an overly important issue, as I was pushing the CreatiVision system & code at twice its designed speed.
To explore the "why?" further, I'd probably need to take a closer look at the game code to understand the mechanism and timing of the explosions, to begin to understand where timing might be impacting this.
At least, I do know they coded the game cycle based on the VDP frame interrupts, as the game didn't run twice as fast!

Apologies for the slow reply, I seem to have been suffering from the dreaded "man flu" over the last week.

[epaell]

were sometimes occuring at the left of the screen instead of where they were supposed to be (as though the x position was lost)

Ah, that's exactly the kind of behaviour I was noticing as well i.e. not so much a corruption in what is displayed but rather more like not quite receiving the right instructions along the way.

I seem to have been suffering from the dreaded "man flu" over the last week

No, problems - hope you have a quick recovery!

When I get a chance I'll see if I can run a few more tests to explore what triggers the problem and/or push the ISR version further.