The Sinclair QL Forum

recently my cst qdisk interface reported a checksum error on firmware 1.19


Anyone got a rom image so i can burn a new v1.19 rom

i cannot calculate the checksum to this rom , my programmer says ;

0x001A DC28

if someone on the forum can re-calculate to see what is wrong .


what i extracted form the installed one ( with the checksum error ) ;

I'm on contact with a user of Facebook that post a picture of a cst disk with this version to try to save the ROM and send me it by email, hopefull in some days I can provide to you.

It's scrambled, so you need to swap bits before get the readable code, checksum is the last two bytes of the 12kb part. The last 4kb is not used.

I ENCOURAGE to all owners of any interface, don't care the revision it have, to made a dump and share, to avoid this happens again, Dilwing site is a huge help for this cases.

Meanwhile you should be able to burn version 1.18 as a quick-fix.

Waiting for your post ,

sounds good , let's hope he can supply a backup

I have Bads and Goods News, I think is funny, but not sure that other think the same...

I was in contact with Andrews Craig from facebook, he has a working 1.19 Interface and a eprom programmer, so he was kind enough to remove ROM from his interface and read it.

(And this is de Bad News) his attempt to read the rom was not sucefully and his dump was corrupt and show a pattern of bad bits.

I compared the ROM of techy and this one and determine that bits 1 to 6 fo both rom are equal, also determine that problem was in bit 0... I do some aditional checks changing the checksum of the techy's rom, and alwais got the message of checksum error... and I think... wait... if...

So I burn the file that techy upload without changes, put in the interface, and.... NO CHECKSUM ERROR (thats the Good News).

so the funny part is that techy dump of the ROM was alwais correct, and we wait months for nothing, it works and I was able to access to the disk.

@Techy: the problem in your interface, can be a bad contact in the socket of the IC, in the socket of the QL, or a damaged eprom that QL can't read correctly but your eprom reader can read.
Also can be caused by a bad 7805 in the interface, try to check the voltage with a multimeter and burn the ROM y another eprom and check again.

I apreciate you feedback to confirm that the ROM dump is OK.

That is progress !!

Thank you !!!!!, i will re burn a fresh eprom this weekend an verify the socket on my interface .

Hi,

I started to look at this problem, but it seemed others were more capable.

The problem the CST Rom data is jumbled up due to data and address lines not being standard. I first thought that this was a prote tion for thr CST ROM.

I think it needs a matrix to jumble/unjumble the code to be burned to ROM.

I will look out my notes on this.

Hi Derek et Al

Depending upon the data/address line 'jumbling' used in the Thor 20, I can provide a SBasic routine to map either way from a raw/straight image to/from the physical layout - a routine I developed for the Thor XVI Main and IO ROMs.

Let me know.

I use a tool for windows call "AFS Rom Suite MD – Utility" this allow several things, like split and join roms, and swaps bits and address line, in the "pins -> Address Pins (8bits)" is possible to configure the changes to modify the ROM, you can even save the configuration for later use.

I just attach the config I use for the CST.

I have re-flowed all socket pins , took a fresh eprom , and voila IT works !!

so , my 1.19 dump can be used by anyone interested in the most recent version .

Hi,

Would the v1.19 dump rom work on earlier CST boards?