Flashy Clock - Yet another DEV board

[exxos]

It seems I have a bad connection on the flashy CPU socket somewhere as it died totally

Now I have just gone for the proper H4 install... and now EMUTOS is working fine... so bizarrely this bad connection didn't effect TOS104, but EMUTOS it did


In any case, I can confirm it now seems to be behaving...

IMG_4982.JPG (70.35 KiB) Viewed 3447 times

IMG_4983.JPG (71.98 KiB) Viewed 3447 times

I hope EMUTOS will pickup the alt-ram later.

[exxos]

ALT-RAM seems to be acting strange

Its just

Code: Select all

SRAMEN = ADDR:[400000..BFFFFF] & !ST_AS;

.. It enables the flash and pulses DTACK.. But I no longer get video, I just get a totally white screen, but the machine is actually running because I can hear the floppy drive running, and if I press escape, it refreshes the floppy, so the machine is running but I just do not see any video at all.. Same results for TOS104, TOS206, EMUTOS

EDIT:

This seems to be a problem with the blitter when alt-ram is enabled

EDIT2:

Blitter is ruled out. I have stripped flashy firmware right back to alt-ram only, and as soon as its enabled, the screen gets random red dots and no video again... I wonder if the CPU fault I had before is a bad address line on the PCB itself somewhere causing this

EDIT3:

Set the address range to ADDR:[800000..8FFFFF] and now machine boots up as normal, but EMUTOS doesn't find any altram

[Icky]

Now I have just gone for the proper H4 install...

That FCV6 looks like it was meant to be there

[PhilC]

Have a look at Agralunds topic about the TF534, I think he used the TT ram space to get it to work with Tos2.06 and Emutos

[exxos]

Have a look at Agralunds topic about the TF534, I think he used the TT ram space to get it to work with Tos2.06 and Emutos

I'm not getting that far.. I can't even get TOS to boot with alt-ram enabled

TT RAM is above 16MB mark, for 32bit CPU, not 16bit, so I doubt his work will help.

[PhilC]

No worries, I'm sure you'll sort it out

[exxos]

I scoped out the SRAM enable.. and its triggering when the floppy is being accessed for starters.. that isn't right.. Its like its decoding the wrong address.. but if that was the case, ROM decoding and the other registers would fail.. ?!

So I wrote some new firmware to pulse the address lines one by one.. This will check the connection from the PLD via the 3.3V buffers to the ST...

IMG_4986.JPG (92.26 KiB) Viewed 3384 times

But all 23 address lines are pulsing, so there is no bad addresses there... so I don't understand how this can happen unless the CUPL compiler is screwing up.. which I will look at next.

I also upped the SRAM range to 8MB - 10MB (it booted that way) and tried poking in STOS.. and I got 255 as expected.. So its not like the decoding is broken, as poking 5MB for example gives bus error as expected.

I even tried the diagnostic cart and did RAM test (4MB) just to be sure, and that works fine as well. Also checked all address pins are pulsing when the CPU is running.. and that seems fine also.

[exxos]

I changed the address to.. [800000..8FFFFF] Again ST boots fine.

I loaded STOS..

Tried $40000.. bus error.. so as expected.

Tried $8FFFF and got back as expected. So address decoding works fine...

IMG_4987.JPG (39.98 KiB) Viewed 3374 times

andyet, if I go back to $400000 range.. the ST goes nuts, no video random corruption etc.. I don't get it

Incidentally, flashy only has code for decoding alt-ram currently, I am using a H4 board, so a "stock ST" setup.

EDIT:
Ignore the 128 above bus error, the value was there from peeking elsewhere, it really does give bus error on $400000...

[exxos]

I am starting to wonder if t he PLD is faulty or something.

I outputted the SRAM_OE to a IO pin.. it NEVER gets accessed (as expected). I had to disable the DTACK code to get it to boot...

BUT..

When I add the DTACK code in which triggers on SRAM_OE access as well (so should never trigger) it then actually does start accessing the address

Code: Select all

S = ADDR:[400000..4FFFFF] & !ST_AS ;
SRAM_OE = !S;
ST_DTACK =  'B'0;
ST_DTACK.OE = S;

So something is screwing up in the PLD somewhere...

I know ST_DTACK code works as it decodes ROM etc and DTACK gets issued then in the full firmware.

So at this point I think the PLD might be faulty, I have emailed Atmel about this issue to see if something is screwing up in the compiled code somewhere, but I cannot see any problems anywhere..

[exxos]

Some progress..

I moved ST_DTACK to a different output pin, in this case I re-used the ROM_OE line..

IMG_4989.JPG (125.23 KiB) Viewed 3397 times

Now the ST boots and the address range works as expected...

IMG_4992.JPG (18.56 KiB) Viewed 3397 times

So something amiss with the PLD somehow


EDIT:

SYSINFO showing something interesting...

IMG_4993.JPG (59.84 KiB) Viewed 3392 times

EDIT2:

So I reset the machine and its gone back to white screen again