exxos's Atari, Amiga & retro forum

Posted: **11 Dec 2019 18:01**

@stephen_usher please reread ickys reply. https://www.exxosforum.co.uk/forum/viewt ... 140#p30172

Posted: **11 Dec 2019 19:22**

exxos wrote: 11 Dec 2019 18:01 @stephen_usher please reread ickys reply. https://www.exxosforum.co.uk/forum/viewt ... 140#p30172

Oops. I did miss the bit about the header.

Posted: **11 Dec 2019 19:43**

stephen_usher wrote: 11 Dec 2019 19:22
exxos wrote: 11 Dec 2019 18:01 @stephen_usher please reread ickys reply. https://www.exxosforum.co.uk/forum/viewt ... 140#p30172
Oops. I did miss the bit about the header.

It's already done. We are now utilising the JTAG header so one can plug in a battery of their choice, of course an appropriate rated one :) Car batteries need not apply :lol:

Posted: **11 Dec 2019 22:33**

Hehe... I dunno, with the correct circuitry it might run it for a few centuries.

Posted: **11 Dec 2019 22:52**

So while doing some testing, the issue becomes that GLUE decodes TOS1.xx space, as well as the PLD. This basically ends up in a issue where the MB ROM can hold TOS102 for example, and the flash TOS104. With GLUE decoding TOS1.xx space it results in a conflict.. There is a jumper to disable the flash, but it may also conflict with EMUTOS as well. So as TOS versions can be anything, I just want to make all this idiot proof.

its not so simple to disable GLUE either. If I don't let GLUE see /AS going low on ROM space, it seems to think it can start a DMA cycle and the floppy screws up. This is why I did the last moment change on the H4 to jumper ROM_CE (JP13) Which isolates GLUE ROM_CE lines, and the PLD just does it all instead. GLUE still sees the ROM address and decodes, but ROM_CE needs to be isolated so it doesn't conflict. I won't go into all this in detail.

This is a caveat for original STFMs etc, as it has no such jumper... BUT.. This STFM DUALTOS board https://www.exxosforum.co.uk/atari/last/ ... tm#UBESTFM Does have CE isolate option with a solder jumper. So anyone who wants to run flashy in a STFM will need that new ROM board.. or they could also probably isolate CE on the GLUE solder pad, or remove the LS11 etc. There could be other workarounds in that program the flash and simply remove the MB roms after programming. But working out fitting to original machines isn't high up on my to do list currently and the DUALTOS board will be my suggested solution as its designed for this "problem" anyway.

Overall, as I said before, These projects are geared for the H4 mostly, where fitting and operation is "simple". As always, fitting to original STFM's etc will need a lot more hacking about.

Posted: **12 Dec 2019 18:10**

Been working on this today and run into a odd thing again..

How the test firmware was working, was to boot from TOS104, And the flash would be programmed in TOS206 space. This all worked fine. Earlier I decided to move to a higher address and now the flash doesn't seem to be accepting commands again :roll:

I basically went from...

Code: Select all

POKEW (&HE0AAAA),&HAAAA
POKEW (&HE05554),&H5555
POKEW (&HE0AAAA),&H9090
PRINT "MID "+ BIN$(PEEKW(&HE00000)), HEX$(PEEKW(&HE00000))

To..

Code: Select all

POKEW (&HE4AAAA),&HAAAA
POKEW (&HE45554),&H5555
POKEW (&HE4AAAA),&H9090
PRINT "MID "+ BIN$(PEEKW(&HE40000)), HEX$(PEEKW(&HE40000))

So I just moved from $E000000 to $E400000, updated the firmware to decode that range.. up to $E4FFFFF in fact.. I am reading the contents of the black, and I can see TOS206 there.. but for some reason the commands are does not working any more :stars: :stars:

EDIT:

OK I plugged that address range into my old firmware and it works, so I broke something at some point today :(

EDIT2:

Back working again.. I just copy/pasted the flash control code from my previous version and working again... I did do some tweaks, but nothing which should have broken it :roll:

Posted: **12 Dec 2019 20:06**

So more firmware updates...

:cry: :cry: :cry: :cry: :cry: :cry: :cry:

The status register I tried to program in tipped the PLD over the edge :roll:

Code: Select all

Fitter_Pass 1, Preassign = KEEP, LOGIC_DOUBLING : OFF 
 ... 
Fail to route variable ST_BGACK in Block 2
Fail to route variable A20 in Block 4
Fail to route variable ST_BGACK in Block 2
Fail to route variable ST_BGACK in Block 2
Fail to route variable A20 in Block 4
Fail to route variable A22 in Block 2
Fail to route variable ST_BGACK in Block 2
Fail to route variable A20 in Block 4
Fail to route variable A9 in Block 2
Fail to route variable ST_BGACK in Block 2
Fail to route variable A20 in Block 4
Fail to route variable clk_8 in Block 1
Fail to route variable A9 in Block 2
Fail to route variable A22 in Block 2
Fail to route variable ST_BGACK in Block 2
Fail to route variable clk_8 in Block 1
Fail to route variable A9 in Block 2
Fail to route variable A19 in Block 2
Fail to route variable A22 in Block 2
Fail to route variable ST_BGACK in Block 2
Fail to route variable A20 in Block 4
Fail to route variable A9 in Block 2
Fail to route variable A22 in Block 2
Fail to route variable ST_BGACK in Block 2
Fail to route variable A9 in Block 2
Fail to route variable A22 in Block 2
Fail to route variable ST_BGACK in Block 2
Fail to route variable A19 in Block 2
Fail to route variable ST_BGACK in Block 2
Fail to route variable ST_DTACK in Block 2
Fail to route variable A21 in Block 4
Fail to route variable clk_8 in Block 1
Fail to route variable ST_BGACK in Block 2
Fail to route variable ST_DTACK in Block 2
 ## Warning : Routing fail

EDIT:

Interesting that it then compiles if I route to a FF :roll:

Code: Select all

TMP2.CK = clk_8;
TMP2.D = ADDR:[FF8964] & ST_RW ;

Posted: **13 Dec 2019 14:14**

Some changes I am currently doing In the software.

IMG_4742.JPG

Basically doing a proper menu system to change the flash banks rather than changing bits in the registers which people will probably find difficult to understand.

The ROM_DIS jumper on the board acts as a override for bit 2 in the 7F RTC register. So any eventuality that somebody manages to totally brick the thing somehow, the jumper on the board can be used to force the MB ROM's to be used. Otherwise this is controlled via bit 2 in software. Basically when bit 2 = 1, it disables the flash banks, and enables the MB ROM's. When bit 2 = 0 , it disables the MB ROMs and enables the flash banks.

The MB ROMs have to be in use to allow the flash to be programmed. The problem is that if a flash bank is running, you cannot change the bank number in order to program it as the OS is running from the currently selected flash bank. Similarly, you cannot program the flash bank which is currently in use as the OS will likely crash. While there may be workarounds to all this, I am not really interested in looking to anything else which will just overcomplicate things. I am also really struggling to fit all this inside a ATF 1504 already. Firstly the original state of the flash will be basically in a "bricked" condition, so the motherboard ROMs have to be used and booted in order to program the flash in the first place, so in order to keep things simple, that philosophy will always be used.

Bits 0 & 1 in register 7F set the flash bank number (00 to 11, 1 of 4) .

In the register dump menu, there is a new register called "SR". this is almost a mirror of the 7F register. However, the register is only set when being written to. If example someone changes the ROM_DIS jumper on the board itself, the internal PLD register would get updated, but obviously the PLD cannot program the register in the RTC RAM. So the SR reads directly the internal registers in the PLD. The bits are mirrored into D8,D9,D9 and "mirror" the 7F register bits 0,1,2, with the exception that the SR register will update in real-time the ROM_DIS bit 2.

So now the software knows the actual state of ROM_DIS, and assuming the motherboard ROMs are in use, we can now cycle through the 4 flash bank addresses and report the TOS versions as shown in the image. so in this particular example, BANK 1 reports TOS 104, and BANK 4 TOS206. in this mode, you can change flash banks and program them one at a time. If you are running from flash, the software can only report the currently running TOS version and you are not allowed to program the flash banks in this mode.

Regardless of the status of ROM_DIS, be it you have selected running from motherboard ROM or flash, changing the TOS version which is currently in use will require you to reset your machine as it will basically crash. Essentially this is like ripping out TOS104 ROM's and replacing them with EMUTOS while the power is still on.. It just isn't going to work like that. I am going to try and program a automatic cold boot into the software, but currently I will just put a message in the software that you will need to reset your machine manually.

As mentioned in the above post,I have remapped the flash write bank to $E400000. Basically yesterday I realise that while the motherboard ROMs would need to be in use in order to program the flash which was currently in TOS206 space, I thought moving the flash address out of 206 space will basically mean TOS104 and/or TOS206 can be used on the motherboard ROM itself. So if you have one of my DUALTOS boards, You can have 2 ROM versions such as 104 & 206 in the "fixed" ROM on the dualtos board. This is in addition to the 4 flash banks.

So as mentioned previously, the GLUE's ROM_CS signal needs to be broken on original machines, either by using my DUALTOS STFM ROM board, or removing the LS11 and feeding ROM_CS from flashyclock instead. On the H4 there is a proper pin for this connection.

Regardless of which ROM is selected, ROM or flash, settings are stored in register 7F which are restored each time the machine is powered on or reset. So for example if you select TOS206 in flash and power off your machine, next time you power on it will automatically boot into TOS206. Similarly if you have EMUTOS selected in flash and power off your machine, next time you power on it will automatically boot into EMUTOS. So you do not need to worry about having to repeatedly select the TOS you want to use. It is basically a " set and forget" operation.

In terms of this post, I hope I can also report the version of EMUTOS soon as well.

https://www.exxosforum.co.uk/forum/viewt ... 06&p=30315

Doing the software updates will keep me busy for a few days yet... And then I need to thoroughly test it all out :)

Posted: **14 Dec 2019 13:03**

I ran into another slight hiccup , in that its a bit rubbish not being able to view the flash bank versions while flash is active. So I worked out how to get around this problem, but it needs a circuit tweak for starters. Problem then is the 1504 is full and there isn't any room for any more code in it. Which then made me think, theres no room for the alt-ram code either :roll:

So Monday, I will rip off a 1508 from the SEC boosters I got built ages ago, and thankfully its a drop in for the 1504. Then do some bodge wires to try out the mods. Which needs more firmware coding and a chunk redoing in the ST software as well. Icky had developed the V4 board, but we skipping that one now, as we now moving onto V5 which Icky hopefully can start working on soon.

On a good note, the operation of the whole thing seems to work fine. Just I want to try and make it as user friendly as possible, so its going to be a bit longer before we get this project done. But I am giving it all my free time to try and get this project done ASAP as I have the SEC boosters and IDE and 50 other projects which need to get done.

Posted: **14 Dec 2019 13:55**

exxos wrote: 14 Dec 2019 13:03 So Monday, I will rip off a 1508 from the SEC boosters I got built ages ago, and thankfully its a drop in for the 1504. Then do some bodge wires to try out the mods. Which needs more firmware coding and a chunk redoing in the ST software as well. Icky had developed the V4 board, but we skipping that one now, as we now moving onto V5 which Icky hopefully can start working on soon.

V5 started :) am hoping we can get the PCBs ordered before the holidays, as long as we don't find any issues.

exxos's Atari, Amiga & retro forum

Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board

Re: Flashy Clock - Yet another DEV board