DigicoolThings Forum

Oh wait, there isn't even any COCO-specific code - it just uses the same code-base as everything else. I guess I need to check in that path then ... hmm, that brings up gazillions of hits I must say, I really don't like the way the defines work as I always get the logic wrong e.g.
I keep reading that as "if it is not equal to a H6309 then do stuff else do something else" but in fact it is the opposite.

epaell wrote: ↑Mon Sep 16, 2024 3:23 am It got me thinking as well ... the last time I tested this was with the original 6809 board where I had the traditional 40-pin version of the 6309. It might be worth trying to test it with the PLCC version in case I was sent a re-badged/dodgy 6309.

Please do check this. I did check the first of my HD63C09 PLCC chips with an Acetone rub (to check for re-marking), but your comment also alerted me that I haven't gone as far in my HD63C09 PLCC testing to actuallly test some 63C09 specific code (I'd have to write some first).

On the other hand, it's good to hear that you've found no code differences as yet. Although, clearly something is different, for it not to work anymore.

epaell wrote: ↑Mon Sep 16, 2024 3:23 am Oh, something else I noticed, I could push most of the system to work up to 4 MHz (16 MHz clock) but I found that the VDP was starting to behave weirdly (and that's with lots of extra NOPs thrown in to slow access) - so I suspect it probably just hit some limit there. It works fine at 3 MHz (12 MHz clock).

Yes, I remember having to throw in NOPs to get the original Video demos working at 4MHz.

Other things you might want to try are:

a) Check the access speed of your DRAM's. Do you have some faster one you could try? e.g.. 100ns or 120ns, instead of 150ns etc.

b) Try changing the 74HCT244 for a 74AHCT244 instead. I'm currently running the faster 74AHCT244 on my VDP card, from when I swapped it out to edge out a bit more clock speed performance.

c) Further to above you can also experiment with a 74AHCT04, and also try going to the W4 write-delay jumper (instead of W6), when you are running faster DRAM etc.

epaell wrote: ↑Mon Sep 16, 2024 3:27 am I keep reading that as "if it is not equal to a H6309 then do stuff else do something else" but in fact it is the opposite.

Okay, you've got me confused now. I would have read it (like you) as literally "not equal to a H6309 then do stuff, else do something else"

But I see that it does something with register w, which only exists on a 6309. So, clearly it must be the opposite.

Which assembler is that?

Actually, now that I think about it - OS-9 did recognise that I had a 6309 (but running in 6809 mode) so I assume that it must be OK?

I checked the VDP RAM and I do have the TMS4464-10NL variants. I only have the 74HCT chips so AHCT ones might be worth checking ... oh, but hold on, I completely missed the write-delay links - I don't have any of them linked. I should go through your video again to remind myself how they should be set up.

Okay, you've got me confused now

It does my head in every time - it's even more confusing when they have multiple embedded ifs e.g. when defining what source to include for the different variants of platforms that it can run on.

I "think" it is like a BNE i.e. it tests for a non-zero. In this instance H6309 is set to 1 if it is enabled and so will pass that test. But for me, personally, I feel that logic is very confusing and I find it very difficult to read.

NitrOS9 uses the lwtools assembler and linker (http://lwtools.projects.l-w.ca).

epaell wrote: ↑Mon Sep 16, 2024 3:57 am ... oh, but hold on, I completely missed the write-delay links - I don't have any of them linked. I should go through your video again to remind myself how they should be set up.

The W6 link is pre-linked (which the '*' is meant to signify).
So, to try W4, you need to first cut the W6 trace (between the jumper pads), and then solder-short the W4 pads.

Hi All, If you haven't seen it then have a look at this github site for 6809 projects. I have most of this stuff running on my FPGA 6809s, hopefully the porting to MECB when the time comes won't be too difficult ...
https://github.com/nealcrook/multicomp6809
hth David.

Thanks David - that's great!

The nac_notes.txt file is really useful as it tracks many of the issues I went through as well (albeit taking slightly different paths for the MECB as it doesn't have any way to re-map memory - so it is limited to Level 1 I believe; also my SD card interface is closely matched to the Corsham Technologies one so I used that as a base rather than the coco variant). I'll need to read it a bit more carefully once I have time again to see if I can resolve some of the outstanding issues I still have i.e. getting it to run with the 6309 variant and seeing if I can get the drivewire support running (especially as I now have the second serial port available).

Cheers,

Emil.

also try going to the W4 write-delay jumper (instead of W6), when you are running faster DRAM etc.

That just seemed to result a mess on the screen. I'll note that the effect I'm seeing doesn't feel like it is associated with the memory side of things i.e. the display is fine; it's just as if it doesn't get some of the control commands written to the VDP registers. For example, I was writing the time on the display and sometimes it would appear OK and other times only part of it would be visible. Similarly, the sprite would sometimes appear in the wrong location (edge of the screen) and then later appear in the correct location.

epaell wrote: ↑Tue Sep 17, 2024 12:54 am

also try going to the W4 write-delay jumper (instead of W6), when you are running faster DRAM etc.

That just seemed to result a mess on the screen. I'll note that the effect I'm seeing doesn't feel like it is associated with the memory side of things i.e. the display is fine; it's just as if it doesn't get some of the control commands written to the VDP registers. For example, I was writing the time on the display and sometimes it would appear OK and other times only part of it would be visible. Similarly, the sprite would sometimes appear in the wrong location (edge of the screen) and then later appear in the correct location.

Interesting. Is this still going for 4MHz, or are your testing this initially with a reduced (on spec) speed?

If the effect you are seeing only happens after changing from W6 to W4, then this will definitely indicate Memory Access related (as opposed to just CPU <> VDP Register access related).

I think this would therefore (most likely) indicate that the memory access propogation delays (i.e. in relation to the DRAM timing etc.), on your particular VDP Card configuration, are currently too tight for a reduced write-delay.

I'd probably go down the track of trying a 74AHCT244 as the next step, as (from memory) the AHCT provides about half the propogation delay of the equivalent HCT. So, more room to tighten-up the propogation delay by moving to W4 etc. to enable a faster memory cycle (for higher clock speeds).

Of course, the more scientific approach would be to hook-up a multi-channel scope and take a look at the signal timing, to see what is going on.