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.

[daver]

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.

Hi, Do you have the nitros9 code available. I have tried using the nitros9 repository but not making much headway in modifying to suit the 6809 board. My dsk is different as I have a memory mapped CFcard. Got flex running off that.

[epaell]

It gave me a bit of a headache getting my head around it when I was first doing this and I ended up cheating and just modified the corsham variant of the code (particularly as that system was already very similar to the one that I was adapting for) because I wasn't sure how to create my own. Unfortunately the code base has changed since then ... however, I recently went through the same process adapting it to work with the Fujinet card (which also has an SD and WiFi access) and I worked out how to separate an "MECB" version and adapt it to work with the MECB system (although I didn't get as far as switching to 6309 on that). I've just added that to my GitHub in case it is helpful:

https://github.com/epaell/MECB/tree/mai ... SW/nitros9

I did have some rough notes in this second attempt to remind myself what needed to be changed which I'll post here in case it helps:

Code: Select all

defs/mecb.d
- Needs to define all hardware addresses and device specific information

Level1/mecb/bootfiles
- makefile (contains needed modules need for boot - need to replace pio with fnio, clock2_cshsd->clock2_mecbfn)

Level1/mecb/bootrom
- makefile (contains modules needed for boot rom - kin,krnp2,init and boot_mecbfn)

Level1/mecb/cmds
- makefile (can keep the same as corsham version)

Level1/mecb/defs
- defsfile.asm (use mecb.d instead of corsham.d
- makefile (use mecb.d instead of corsham.d)

Level1/mecb/defsfile - replace corsham.d with mecb.d
Level1/mecb/makefile - replace CORSHAM with MECB

Level1/mecb/modules/
- rel.asm (needed to initialise ACIA and provide basic terminal I/O during boot)

- boot_cshsd.asm (change to boot_mecbfn.asm)
- Provides disk read capability to perform initial load of nitrOS9 into memory

- pio.asm (provides parallel I/O routines to access disk and RTC) - replace with fnio.asm for FujiNet routines

- clock2_csdhsd.asm (Provides routines to read FN time)

Level1/modules/
- clock.asm (needs to set up and handle timer interrupt for time slicing processes)
- krn.asm (there are some bits that need to define memory use

You can also check for instances of "mecb" throughout the files to see where it comes up (particularly in the common files to see where it is modified to work with that system). I believe the only place I deviated from my original plan above was that I placed the FujiNet routines in ROM so that it could be used by both the boot process and the system (it's a bit of a hack as it requires jumping to a fixed location - which kind of goes against the philosophy of OS9). If I placed it in the module (fnio) then I'd still need to have a version of it in ROM and it seemed a bit silly to duplicate that code twice (the memory availability in OS9 was bad enough as it was). I also added a ccopy.sh script which helped to start from a clean slate, compile the code, make the disk and copy across various test files to it.

You'll also need to set up a couple of environment variables:

Code: Select all

export NITROS9DIR=$HOME/local/src/nitros9
export PORTS=mecb
export LISTDIR=$NITROS9DIR/lst

The first tells the make system where the source is, the second tells it which port to build (otherwise it builds everything) and the third one makes it generate listing files (which I found useful for debugging).

You may also want to update the startup and password file for your system (I added a bunch of dummy users in there when I was playing with the multiuser/task switching side of things.

Hope this helps you get up and running!

BTW, I do have the original codebase for the original version where I modified the corsham version of the code and can provide that if that is also helpful but as I mentioned, the GitHub codebase has moved on since I made those changes.