Flashy Clock - Yet another DEV board

All the good stuff hardware and software wise for the Phoenix H5 series motherboards.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: Flashy Clock - Yet another DEV board

Post by exxos »

Icky wrote: 14 Dec 2019 13:55 V5 started :) am hoping we can get the PCBs ordered before the holidays, as long as we don't find any issues.
Yeah, they gonna be like a week behind this time of year, so that plus a few days shipping.. its gonna have to go off to fab within the next couple of days :roll: Though like I said before, its getting the bits, building them.. testing.. its taking a lot of time up. So I am really gonna try to at least get the 1508 working on the current board tested, at least to the point I can give the go-ahead to get V5 made. Then I can tidy the whole thing up firmware and software wise while V5 in getting built.

As a probably not good idea, I wonder if we pushed to a 6 layer board, what would be the chances of getting the alt-ram chips on the bottom of the pcb as well ? 6 layer boards are like double the cost of 4 layers, but with the alt-ram boards costing like 5 times over the norm due to its "issues" then it may actually be cheaper to mash the alt-ram on , say a V6 design.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: Flashy Clock - Yet another DEV board

Post by exxos »

Flashy is undergoing a PLD transplant...

IMG_4744.JPG
Capture.JPG

EDIT:

Yep its monday :roll:

Capture.JPG
You do not have the required permissions to view the files attached to this post.
User avatar
PhilC
Moderator
Moderator
Posts: 7440
Joined: 23 Mar 2018 20:22

Re: Flashy Clock - Yet another DEV board

Post by PhilC »

Actually, that looks good for a Monday
If it ain't broke, test it to Destruction.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: Flashy Clock - Yet another DEV board

Post by exxos »

PhilC wrote: 16 Dec 2019 15:34 Actually, that looks good for a Monday
Its progressed now... I managed to program the thing by pressing down on one side of the PLD. The machine booted and crashed with 4 bombs on desktop. So I've gone around the PLD 4 times now and now its just stuck with a row of bombs on the screen :roll:
User avatar
PhilC
Moderator
Moderator
Posts: 7440
Joined: 23 Mar 2018 20:22

Re: Flashy Clock - Yet another DEV board

Post by PhilC »

Ah that old chestnut as the saying goes.

Post a pic and maybe we can spot something perhaps?
If it ain't broke, test it to Destruction.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: Flashy Clock - Yet another DEV board

Post by exxos »

Took the chip off and resoldered it again, now it seems the booting up fine, but it seems to be totally ignoring the TOS selection :roll:

EDIT:

Now its booting :D
User avatar
PhilC
Moderator
Moderator
Posts: 7440
Joined: 23 Mar 2018 20:22

Re: Flashy Clock - Yet another DEV board

Post by PhilC »

:excited: :stars: :dizzy: :cheer: :cheer: :cheer:
If it ain't broke, test it to Destruction.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: Flashy Clock - Yet another DEV board

Post by exxos »

Ironically, the extra signals I wanted to add in just happened to be right next to pins I need to connect to, so I just needed to solder blob across two pins twice..

Capture.JPG

Next up the firmware and software changes, which will keep me busy for a while...
You do not have the required permissions to view the files attached to this post.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: Flashy Clock - Yet another DEV board

Post by exxos »

So far this is working, but I have a weird fault which makes no sense...

I map the start of each flash bank to these addresses...

FIRMWARE:

Code: Select all

FREG1 = ADDR:[E80000..E8FFFF] & !CPU_AS ; // 00
FREG2 = ADDR:[E90000..E9FFFF] & !CPU_AS ; // 01
FREG3 = ADDR:[EA0000..EAFFFF] & !CPU_AS ; // 10
FREG4 = ADDR:[EB0000..EBFFFF] & !CPU_AS ; // 11

SOFTWARE

Code: Select all

PRINT HEX$(PEEKW(&HE80000)), HEX$(PEEKW(&HE80002))
PRINT HEX$(PEEKW(&HE90000)), HEX$(PEEKW(&HE90002))
PRINT HEX$(PEEKW(&HEA0000)), HEX$(PEEKW(&HEA0002))
PRINT HEX$(PEEKW(&HEB0000)), HEX$(PEEKW(&HEB0002))
And it outputs...
IMG_4745.JPG
However, I don't understand where the bottom row "3EBC 10" is coming from... I mean address $EB0000 isnt used for anything else is it ?! It should be reporting the same as the top row "602E 206" which is the start of 206 ROM... I have 206 programmed in bank 1 and bank 4, so bank 4 should report the same but it does not :(

Incidentally, the middle two rows are flash memory which has not yet been programmed, so will of course show "FFFF".


EDIT:

I dumped the next byte which was "4EB9" These are listed in TOS though shouldn't be showing as the start of the ROM :shrug:

Capture.JPG


EDIT2:

So I found I was decoding to large a bank elsewhere in the firmware..

Code: Select all

TMP = ADDR:[E40000..EFFFFF];
So updated it to

Code: Select all

TMP = ADDR:[E40000..E7FFFF];
Now I am reporting "FFFF" everytime now :roll: So maybe my register decoding from earlier isn't doing what it should be.


EDIT3:

I forgot to enable the flash :lol: :roll: So now decoding is working again, but still have that stupid "3EBC" thing :WTF:

EDIT4:

I programed TOS104 into BANK2 and now get "91C5" which isn't right either... so I must be doing something dumb somewhere :roll:


EDIT5:

Pondering that I am switching A16 on the ROM when shouldn't be...
Capture.JPG
EDIT6:

Code: Select all

              *
       22221111111111
       321098765432109876543210
E80000 111010000000000000000000  ok
E90000 111010010000000000000000  X
EA0000 111010100000000000000000  ok
EB0000 111010110000000000000000  X
EC0000 111011000000000000000000  ok
EE0000 111011100000000000000000  ok
So some tweaks to not use address ranges which switch A16.. now I get this :roll:

TOS206 looks correct for first row, TOS104 should be in second, 3rd blank "FFFF" and 4th TOS206 again ... just getting back odd numbers again.. I guess BANK1 & 3 are actually correct.. so many I shouldn't be using A17 either ... Which means I basically run out of address ranges as I need 17 zeros and 4 banks of them :roll:

IMG_4746.JPG
You do not have the required permissions to view the files attached to this post.
User avatar
exxos
Site Admin
Site Admin
Posts: 28344
Joined: 16 Aug 2017 23:19
Location: UK

Re: Flashy Clock - Yet another DEV board

Post by exxos »

Soooo.. after the epic in the previous post..

ROM uses A0-A16 , So don't use A17 either then it seems :roll:

Code: Select all

             **
       22221111111111
       321098765432109876543210
E40000 111001000000000000000000  ok
E50000 111001010000000000000000  X
E60000 111001100000000000000000  X
E70000 111001110000000000000000  X
E80000 111010000000000000000000  ok
E90000 111010010000000000000000  X
EA0000 111010100000000000000000  x
EB0000 111010110000000000000000  X
EC0000 111011000000000000000000  ok
EE0000 111011100000000000000000  x
EF0000 111011110000000000000000  x
F10000 111100010000000000000000  X
F40000 111101000000000000000000  OK
F80000 111110000000000000000000  OK

$E40000 is used for the actual flash writing.. So that only leaves $E80000 & $EC0000... I can't use $FF0000 (that would be to easy wouldn't it) as its the IDE registers... BUT there is some space above it...

1.JPG

So I can use $F40000 & $F80000 ...

So updating the software & firmware...

IMG_4747.JPG
I finally see the correct ROM data, 206 - 104 , FFFF, 206 :cheer: :cheer:

So now I can change the flash banks while the OS is actually running on flash. I guess all this might have been possible if programmed in assembly as if the code selected the flash bank and then did a read, and put back the flash bank its running from, that could work providing there was no ROM access between the 2 commands. Though I didn't want to take that risk, because in basic I have no idea what the compiler is doing and it could may well accessing something in ROM in between selecting the bank and reading it.

In anycase, There are actually two levels of flash bank selects now. The flash bank latched condition which is set from the RTC NVRAM, and now a temporary bypass condition which only allows the banks to be changed on one single CPU bus cycle. The analogy of this would be ripping out the motherboard ROMs with the power on, but only for a single bus cycle, and putting the original ROMs back again after that cycle completes. This basically just equates to reading a different address in the memory map.. Of course this is a bit more complicated...

Basically now, the first few bytes of each flash bank are now mapped to 4 different registers, those registers control the flash select lines. So now I can read the version number of each flash bank will make the software a lot more user-friendly ultimately.
You do not have the required permissions to view the files attached to this post.

Return to “PHOENIX ZONE”

Who is online

Users browsing this forum: ClaudeBot and 2 guests