exxos blog - random goings on

Blogs & guides and tales of woo by forum members.
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

Sector erase seems to be working now :)

I seem to have found another "bug" in Hisoft basic :roll:

Code: Select all

TMP&=&HE00000 + (&H800 * CNT%) 

Where E00000 is the Flash address, +800*cnt as we need to count up from bit 12 only..

CNT is only counting from 0 to 31.. and % means 16 bit number, & means 32bit number. So no way can that line count higher than a 32bit number.. but it crashes with arithmetic overflow error :roll:

So what I actually had to do is declare CNT as a 32 bit number..

Code: Select all

TMP&=&HE00000 + (&H800 * CNT&) 
And now it programs just fine...

So basically I cannot add together a 16-bit and 32-bit number for some reason :roll:

So below the first address was programmed with a test value, and then the eraser continues, so it prints out the before and after value of the first addressing flash.. So seems to be working now :)
IMG_4434.JPG
IMG_4434.JPG (89.62 KiB) Viewed 4059 times
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

Booting from Flash ends up with a row of bombs :roll:

I've been trying to dump the ROM contents to a file.. it works in steem and shows correct hex data for the ROM contents.. on a real ST, nope, comes back some bizzare patterns...

1.jpg
1.jpg (73.38 KiB) Viewed 4044 times

I was using hisofts OPEN,PRINT to file and the bits had to be rotated to come out at the right value, I mean WTF ? Printing also seems to screw it up with what seems to be line feeds which I can't get rid of, so I just dumped ROM using OS calls instead.. which works in steem..

Code: Select all

A& = FCREATE%("DUMP.IMG",0)
H& = FOPEN%("DUMP.IMG",1)
A&=FWRITE&(H&,262144,&HE00000)
A&=FCLOSE%(H&)
Oddly when I dump HEX code to the screen on the ST, the values are all correct.. so I don't know why saving to file goes nuts..unless its because I am using cosmosex..

If anyone knows of any programs to dump TOS206 space to a file then let me know.. its the only way I can verify whats written in the flash actually matches the file properly...

EDIT:

Tried with a floppy and get other crazy stuff now..
2.jpg
2.jpg (73.85 KiB) Viewed 4040 times

EDIT2:

Tried this... works in steem, but just get a blank file on a real ST

Code: Select all

DATA$="1234567890"
A&=FWRITE&(H&,LEN(DATA$),VARPTR(DATA$))
:pullhair: :pullhair:

Steem is running TOS206 so maybe these functions are buggy in TOS104 :shrug:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

Given up with the ROM save stuff.. dumped a routine to check some random addresses in the ST program and they look fine.

So this now take the pi** because... I swapped the flash bank to another one, programed it, now the ST boots from flash!! so there must be a bad bit in the flash bank I was using somewhere :cussing: :cussing: :cussing:


EDIT:

Seems to verify fine for a second, then throws up several errors.. then is fine for a bit again.. then just loops errors constantly :shock: :shock:

IMG_4435.JPG
IMG_4435.JPG (298.52 KiB) Viewed 4029 times

It prints, ADDRESS, READ FROM ROM, EXPECTED..

So the flash just chucks out zero constantly... so some very poorly flash.. typical.. :roll:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

So the plot thickens.. Icky had a similar issue, but it would only work in bank 2, I not tried other banks, just bank 1 is "faulty" and bank 4 worked for me..

So for some reason the flash is just reporting all zero's. I can only assume at this point that the erase isn't working and not setting FFFF.. So when the software tries to program the data, it can't, because the address hasn't been wiped.. and assuming bank 4 for me just happen to have FFFF (erased) out of the factory.

So when I get home, I will do a routine to verify the sectors have actually been set to FFFF.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

Hmmm...

IMG_4436.JPG
IMG_4436.JPG (46.29 KiB) Viewed 3968 times
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

keli wrote: Wed Jul 03, 2019 7:14 pm Edit Even though you're accessing both bytes at once, the second byte still has its own address.

That's because you are doing a 16bit access. POKEW writes two bytes to memory - the higher half of the value at the given address and the lower at address+1. The 68000 can only do that at word boundaries, that's why you get an address error when writing a word to an odd address. In other words: memory on the 68000 is byte addressable, but accessed on the bus in 16 bit words (using UBS and LBS to mask off the unwanted half for byte accesses).
So should I connect LDS and UDS to A0 on the flash chips ? With 16bit access I assume A0 would just end up low all the time. Though it dosent seem right as wouldn't keeping A0 low all the time basically disable all the odd addresses in each flash chip ?!

I am still somewhat confused to how I ended up needing to rotate bits. Its more like CPU A1 shouild be flash A1, but then A0 on the flash can't drive odd addresses. It just seems like the flash data sheet is wrong as it doesn't take into account A0 :roll:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
keli
Posts: 97
Joined: Tue Aug 22, 2017 1:34 pm

Re: exxos blog - random goings on

Post by keli »

exxos wrote: Mon Jul 08, 2019 3:02 am
So should I connect LDS and UDS to A0 on the flash chips ? With 16bit access I assume A0 would just end up low all the time. Though it dosent seem right as wouldn't keeping A0 low all the time basically disable all the odd addresses in each flash chip ?!

I am still somewhat confused to how I ended up needing to rotate bits. Its more like CPU A1 shouild be flash A1, but then A0 on the flash can't drive odd addresses. It just seems like the flash data sheet is wrong as it doesn't take into account A0 :roll:
No, since you have two 8 bit chips for each half of a 16 bit word, CPU A1 goes to flash A0, CPU A2 to flash A1, etc. You could use LDS and UDS to limit the chip select or write enable signals to only one of the two flash chips in case you want to use byte level writes to only write to a single flash chip, but I think that's does not make sense in this case.

The shifting happens exactly because of this doubling up of flash chips. Each 16 bit word takes up 2 bytes (obviously) and therefore an even and an odd (CPU) address (for word access you only specify the even address). You access odd bytes on the flash chips by using CPU addresses, where the second to last bit is set (addresses not divisible by 4.)

The flash data sheet is right, but it documents the addresses from the view point of the single 8 bit chip. It can't know or assume you are using a pair on a 16 bit bus. (For instance if you were using a 32 bit bus, you could use 4 flash chips together, and then you'd have to multiply each address in the flash data sheet by 4.)
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

Thanks for clarifying.

I figured out what was going on now. I did a new routine to use the chip erase feature of the flash, that is insanely fast by the way! Then when programming the bank, it booted from flash just fine. So it was the erase routine which was at fault. The first problem was that because it used high bits only for sector erasing (A18-A12) I had actually counted from A0 12 times, which left me on bit 11 not bit 12 :roll: So basically it was only erasing half the flash. I then later realised that I also needed to double the address as well.

So my first erase routine was technically only erasing quarter of the flash bank, after I fixed the A12 issue, it was actually erasing half of the flash, now I fixed the bit rotations, it now erases the full bank properly. I have booted successfully TOS104 & TOS206. Icky also confirmed its working and hes also tried EMUTOS. so basically we now have under control RTC & FLASH :)

At the moment each flash bank selected on board by a jumper link. This will be controlled via a software register, so flash banks can be selected by software. The spanner in the works in all this is there is a separate jumper which selects either motherboard ROMs, or flash ROM to boot from. This jumper also doubles up as a write enable for the flash...

The issue is that the motherboard ROMs have to be booted from because flash is not programmed yet, and the NVRAM registers have not been set up yet either.So if the ROM jumper was done in the register, machine would likely try and boot from flash which has not been programmed yet, so the machine would not boot up. So the only way to force the machine to use on-board ROM is, is via a jumper link or a switch. Basically whenever the flash is programmed, it would have to be booted off the motherboard ROMs.

Technically it should be possible to boot from one flash bank, and programme another flash bank, but then it creates more problems that if someone tried to program the same flash bank as they booted from, it will trash the OS and likely crash. I think monster gets around this by disabling interrupts. There is of course possible issues where someone managed to corrupt the NVRAM, it would again prevent the machine from booting up. Overall it just seems to get over complicated and messy to do something which should be simple.

There is of course a slight advantage in having a switch as well, as you could actually still use the motherboard ROM's as well. The flash can hold 4 TOS versions, so with the MB ROM's, its actually 5 ROM's which can actually be selected. but I do think having a physical switch to force booting from motherboard ROMs is probably a good idea anyway. Technically it could be possible to use a DUALTOS board and control that from the PLD for 6 TOS versions. But I'm don't really see the point in having more than 4 TOS versions anyway.

So the pencilled in idea is basically that the motherboard ROMs will just be used to Initially boot from, and set up the flash and RTC. Once it has been set up, the jumper is moved and it disables the motherboard ROM, and boots from the flash instead. Of course if at any point something does get "bricked" user can always select the motherboard ROM's and re-initialise the RTC & Flash.

So in terms of how this will likely work.. Is that there will be a shadow register in the PLD, which will mirror the last address in the NVRAM. So when the register is set up ( written to ) it will programme the register in the NVRAM, and also program the shadow register in the PLD. The PLD will then control the four flash banks. So each flash bank will be selectable via software. When a read happens to that register, it will of course be read from the NVRAM.

The problem with all this is that the register in the NVRAM needs to be read when the machine is powered up, as it needs to select the correct flash bank. I have been giving this a lot of thought today.. Basically the PLD will have some " bit bang logic" which will access the register in the NVRAM on boot up. Because the RTC bus is multiplexed, we actually have to select the address first, and then we get the data.. Driving the databus isn't so simple from a PLD. but I thought the address it will have from boot up is going to be $FF anyway. so it just makes life a lot easier to use that address in the NVRAM. The NVRAM only actually goes up to $7F (7 bits not 8) but this isn't a problem anyway.

So the boot sequence would actually be that the machine comes out of reset as normal, but the reset signal is rooted via the PLD. The PLD will then toggle the CS lines etc on the RTC and force the CPU to keep in reset while all this happens. The first cycle will latch the data bus which will be of course $FF anyway, so the second cycle will have the RTC dump the data from register $7F onto the databus. the PLD will then latch the state into its internal registers, which will then of course translate into selecting one of the flash banks to boot from. Once that has happened, the PLD will release reset to the CPU, and the machine should boot as normal.

So basically what happens is, whichever flash bank you select, it'll save it in the NVRAM, and it would automatically select your saved bank
when the machine is booted up. Incidentally, this type of "system" will ultimately be used in the boosters.. Where the booster on/off will also be software controlled in the future.. But that is probably a long way off yet.

Meanwhile, Icky is making up a couple more of the current boards, as we need testers, and software programmers to finish off some software things. At some point we will start updating the design to include what is mentioned above in the next version.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

In other news..

My new motherboard print out has come, so I can do a bit more checking on the holes etc now.. So far it looks pretty much spot on now.

IMG_4437.JPG
IMG_4437.JPG (80.42 KiB) Viewed 3921 times
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23505
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

Been busy trying to fix my bench PSU..Think it was a HY5003 had a really odd fault where 35V output dropped to 12V under 2amps load.. it wouldn't go below 8V.. loading it with 1K caused the voltage to go up 2 volts.. total chaos..

Probing around I just happen to push down on pin 6 of the 741 op-amp and it started to behave! :shock: The soldering looked fine.. but I put a socket in and stuck in a NE5534 instead (didn't have a crappy 741 anyway) ... it now seems to be behaving fine.. bizzare... It seems to not go above 41V now.. possible it could be a HY3003.. can't remember, transformer says 5003 on it.. who knows.. but having it working again is a win!

IMG_4439.JPG
IMG_4439.JPG (372.32 KiB) Viewed 3898 times

Now to try and put it back together..... :roll:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Post Reply

Return to “MEMBER BLOGS”