Flashy Clock - Yet another DEV board

[czietz]

Note that the more address space you use, the more incompatibilities with 3rd-party hardware you get. Those I know of without looking anything up: Adspeed uses $F40000, Magnum ST (optionally) uses $F40000, Lightning ST uses $F80000.

[exxos]

I'm a bit limited because I need 17 0's. But Lighting doesn't have flash ? , so why does it need 17 zeros ?

[czietz]

Well, Lightning ST address space is as it is. And it happens to be $F80000 - $F80009. Same happens with other third-party peripherals where vendors chose an address that (to their knowledge) was unused at the time. But please understand my comment just as a mere remark. Buyers of the Lightning ST would probably buy a Cloudy board to have flashable TOS, anyway. So the potential for collision is small.

[exxos]

I guess Lighting could drop down to $F70000 - $F70009 ? But like you say, these are kits which shouldn't really ever be used together anyway.

Conflicts are likely to happen with multiple things, like you say magnum. Though in terms of the H4, people should use the alt-ram board designed for it. Magnum is a old board and not really suitable for a motherboard designed in 2019. I know it was just a example, but its not really possible to know and avoid every hardware conflict.

All I can say is everything will be "H4 compatible" and be backwards compatible with original STFM machines, but if people start to try mixing hardware produced recently with hardware from 30+ years ago, then they are on their own :)

[exxos]

Now I know I am tired now...

Code: Select all

IF MID$(Q$,7,2) = "11" THEN  FBANK =4 : PRINT "FLASH BANK 4 IS <B>SELECTED</B>"

Now where's my HISOFT manual gone....

[exxos]

While falling asleep last night, some ideas popped in my head how to go about doing everything differently. So I have been working on these ideas most of the day. Though I seem to be having some really weird issues which are proving rather a challenge to track down :roll:

For example, I am using a register FF8966 To write a value into, I latch this internally in the PLD, and I use another register to read back those values FF8964.

So I do this for example :

Code: Select all

IF A = 1 THEN POKEW(&HFF8966),&B1111111111111100  ' SET BANK 1
IF A = 2 THEN POKEW(&HFF8966),&B1111111111111101  ' SET BANK 2
IF A = 3 THEN POKEW(&HFF8966),&B1111111111111110  ' SET BANK 3
IF A = 4 THEN POKEW(&HFF8966),&B1111111111111111  ' SET BANK 4

T% = PEEKW (&HFF8964) ' read what we get back 
Q$=BIN$(T%)
PRINT  "STAT-REG "+ Q$  + "  " + str$(T%)

So I am only changing D0 and D1 basically.

I then read back the values in the PLD registers, where I should get back the same as above.. but nope... I get back

Code: Select all

00
01
10
00

So how the heck can the first three values come back correctly, and yet the fourth one comes back as 00 ?! :roll:

I have been scratching my head for the past several hours on this. Some other parts of the code are doing strange things as well. Though it is difficult to track down if this is a firmware or a software issue.

I actually mirror some other bits as well and those one seem to be working. I am really starting to wonder if something strange is going on with the PLD itself or compiler.

I did wonder if the BIN$ command was broken somehow, but I outputted the actual variable and bank 1 and bank 4 were the same number.

EDIT:

Even more odd, when I just do this alone...

Code: Select all

POKEW(&HFF8966),&B1111111111111100  ' SET BANK 1
T% = PEEKW (&HFF8964) : Q$=BIN$(T%) : PRINT  "STAT-REG "+ Q$  + "  " + str$(T%)

POKEW(&HFF8966),&B1111111111111101  ' SET BANK 2
T% = PEEKW (&HFF8964) : Q$=BIN$(T%) : PRINT  "STAT-REG "+ Q$  + "  " + str$(T%)

POKEW(&HFF8966),&B1111111111111110  ' SET BANK 3
T% = PEEKW (&HFF8964) : Q$=BIN$(T%) : PRINT  "STAT-REG "+ Q$  + "  " + str$(T%)

POKEW(&HFF8966),&B1111111111111111  ' SET BANK 4
T% = PEEKW (&HFF8964) : Q$=BIN$(T%) : PRINT  "STAT-REG "+ Q$  + "  " + str$(T%)

I just get back "00" constantly :WTF: :stars:

[exxos]

So finally figured it out. I outputted the 2 registers onto a header and they were hardly going high for 50ns and the voltage was erratic to say the least.

I started taking bits out of the code and basically took out CPU_AS and CPU_RW and I got a lot more activity on the pins then! But without CPU_AS the bus would be in transition states and falsely triggering my register. So I thought I would just use ST_RW as CPU_AS would be driven low when ST_RW was driven low anyway, and the feker worked then! So I had a bad solder joint on CPU_AS.. but it gets better....

ST_AS is driven from CPU_AS internally in the PLD. So as to how it could have even booted up in this condition is beyond me.. So I resoldred CPU_AS and... it stopped booting totally.. after much faffing about, it would only boot if I squeezed the left side of the CPU pins.. Lots of contact cleaner later.. still nothing.. So resoldered the several pins on the left of the CPU.. now it boots, and now it shows what it should!

IMG_4749.JPG

So this board must have had 2 bad solder joints the entire time :roll:

Now time for sleep... :dizzy:

[Icky]

So this board must have had 2 bad solder joints the entire time :roll:

Now time for sleep... :dizzy:

I think I built that board originally for you :roll: Why is it always bad solder joints. :(

[exxos]

I think I built that board originally for you :roll: Why is it always bad solder joints. :(

The headers looked fine though that's the odd thing. But I think its the headers themselves as I've had trouble before. I think they need cleaning with IPA. before soldering.

If you did solder it then there's something odd with the solder as well. It seems to act like leadfree stuff. I add flux and have to put the iron on 400c and can't seem to get it to melt. When I do I turns into a blob. I thought Caroline built those though ?

[Icky]

@exxos - FC v3's were built by me and that yukie lead free solder. BUT now I have some leaded stuff thanks to you :)