Too many problems with WHDLoad

[ReadOnlyCat]

Originally Posted by Akira

About virii, I have no idea, I had checked it before, but I have nothing that could have potentially infected it unless one of these WHDLoad packs has a virus in it. As I said, I wiped the compactflash clean. This is a fresh install.
What is the CRC of WHDLoad supposed to be? How can I check these tings?

I cannot see how one could guarantee a virus free system when the games images are downloaded from non official sources which might have not have prepared the images with a clean room procedure. Unless WHDLoad would cryptographically sign the images and their patches in a way which can certify that un-modified originals where used to apply patches in the first place.

Absent that, you can never be certain.

Which is why we need the equivalent of GOG on the Amiga.

[Retro-Nerd]

The preinstalled games are provided by the thrustworty members Killergorilla and Retroplay. Many people downloaded the packs or single installs and nobody complaind about possible virus infections afaik. Could be one of the known hardware/software related problems with specific turbo cards/WHDLoad.

[Amiga1992]

Originally Posted by ReadOnlyCat

I cannot see how one could guarantee a virus free system when the games images are downloaded from non official sources which might have not have prepared the images with a clean room procedure.

Because I trust this community and I am sure the images are totally fine.
If a virus got in my system (HIGHLY doubt it), it came in somehow else. Which is again highly unlikely because, as I said, this is a clean install. But I'll virus check again I guess.

[edit] Virus Checker II found nothing in memory or my disks.
I keep getting these stinking errors and they always see mto be the same or related.
I disabled the MMU as suggested by Stingray and same thing.

Some more errors I found:

Ballistix:
- Exception "line 111 Emulator" ($2C) at $4
BAT2:
- Exception "Access fault" ($B008) / PC=$BFEE99E (Resload $299E) / Instruction stream fault on $CCCCCCCC
BC Kid:
- After Hudson/F5 logos, Exception "illegal instruction" ($10) at $BFFE234 (Slave $234)
- When skipping logos, Exception "Access fault" ($B008) / PC=$BFECCCA (Resload $2CCA) / Instruction stream fault on $CCCCCCCC
- Now it is also giving me "Line 1111 Emulator" ($2C) at $CCCCCCCC
Blastar:
- On intro, "Line 1111 Emulator" ($2C) at $CCCCCCCC
As you can see they are all almost the same or exactly the same many times. I have no idea what is going on. BC Kid for instance is a solid crash at the same point all the time. I disconencted my sampler, and my PCMCIA reader. I booted onto a clean, no s-s setup. Same shit. Only thing left for me to do is remove teh accelerator, but then i won't be able to load many things.

[Amiga1992]

Well look at that, sorry for the double post...

I removed the accelerator and games previously giving problems are working fine now. BC Kid which was a solid failure now works.

Now I wonder, first time I notice, if my CPU has anything to do with it.

The accelerator is a Microbotics 1230XA and the CPU on it is a Motorola SC414075RC50 . Never paid attention to the fact that it doesn't say "68030".

Next up: remove the memory and see if it's that, otherwise, the reason why WHDLoad never worked in my machine is that it doesn't work with my accelerator. And that would be a shitty state of affairs, really.

[edit] confirmed, it doesn't like my accelerator Now I wonder if my accelerator is broken or if WHDLoad is just not working with it? I can't see anything wrong with the accelerator by eye inspection, and nothing else at all gives me trouble but WHDLoad.

[TjLaZer]

Yeah has to be your CPU card. I have ran many WHDLoad games on my A500, A1000, A600, A1200, and A4000 with no issues, except on the 040/060 where I have to use NOCACHE and also PAL to get some of those lame installs working right with PAL, even though it uses NTSC screens! Try to get a real MC68030 chip or an ACA1233.

[Zack]

Since the errors often seems to point to the memory address $CCCCCCCC, it could be faulty memory on your accelerator. How much memory do you have on the board?

One thing to test could be this WHDLoad option:
http://www.whdload.de/docs/en/opt.html#NoMemReverse
That option should allocate memory differently. If this options results in other errors that before, I think it would indicate problems with the memory on the board.

Please check this thread with links to a few memory test tools:
http://eab.abime.net/showthread.php?...hlight=memutil
Can see that you have already posted in that thread

Last thing to try for now: The manual for your board says that it should be possible to disable the memory with a jumper. Could be worth a quick test.
http://www.bigbookofamigahardware.co...ct.aspx?id=139

[DrBong]

Originally Posted by Zack

Since the errors often seems to point to the memory address $CCCCCCCC, it could be faulty memory on your accelerator. How much memory do you have on the board?

One thing to test could be this WHDLoad option:
http://www.whdload.de/docs/en/opt.html#NoMemReverse
That option should allocate memory differently. If this options results in other errors that before, I think it would indicate problems with the memory on the board.

Please check this thread with links to a few memory test tools:
http://eab.abime.net/showthread.php?...hlight=memutil
Can see that you have already posted in that thread

@Akira
Problems with WHDLoad using Microbotics 1230XA accelerator on the A1200 have been well-covered before:

http://eab.abime.net/showthread.php?t=50400

Faulty memory is something to check for. Trying a combination of tooltypes (nocache, nonmemreverse, noautovec and maybe nommu) is also another strategy.

Unfortunately, Microbotics boards along with M-Tec and some Apollo boards are the worst A1200 accelerators to use with WHDLoad from what I've gathered of the experiences of others (as well as my own). The various revisions of A1200 motherboards don't help either.

At the end of the day you might just need to bite the bullet and buy a decent accelerator like a Blizzard or DKB Cobra/Viper to solve the problems with WHDLoad. As you can perhaps appreciate, it can be very difficult sometimes for Bert to solve problems with certain accelerators without having the exact Amiga set-up causing the problems in front of him to run tests on.

[Amiga1992]

Originally Posted by Zack

Since the errors often seems to point to the memory address $CCCCCCCC, it could be faulty memory on your accelerator. How much memory do you have on the board?

Zack, I thought the same at first, if you read what I posted, I tested this with NO memory on it at all. So it isn't a memory problem., The card was tested unpopulated and same errors occurred. It's a card incompatibility.

Originally Posted by DrBong

@Akira
Problems with WHDLoad using Microbotics 1230XA accelerator on the A1200 have been well-covered before:
[...]
At the end of the day you might just need to bite the bullet and buy a decent accelerator like a Blizzard or DKB Cobra/Viper to solve the problems with WHDLoad.

Well I disagree that this is not a "decent" accelerator just because it doesn't run on WHDLoad. This thing works fine with everything else EXCEPT WHDLoad.

I understand that Bert can't test every setup and if it helps, because I feel there are many 1230XA users, I can lend my card for him to try to fix WHDLoad for it. Does anyone think this is worth a shot or do you think Bert wouldn't care?

I don't feel like spending any more money on this machine, especially at the price point of 030 cards nowadays, they are really way too fucking expensive. Might as well never play games on it and that's that. As a matter of fact maybe I should just sell my A1200 since I rarely use it.

As you say I have experimented with tooltypes yesterday. Disabling caching of Chip RAM has helped somehow, I will try the other options. Thanks for pointing me to that thread, i didn't know other people had problems with this card too!

Mystery solved but issue not solved

[Drag0nFly]

Originally Posted by Akira

Zack, I thought the same at first, if you read what I posted, I tested this with NO memory on it at all. So it isn't a memory problem., The card was tested unpopulated and same errors occurred. It's a card incompatibility.


Well I disagree that this is not a "decent" accelerator just because it doesn't run on WHDLoad. This thing works fine with everything else EXCEPT WHDLoad.

I understand that Bert can't test every setup and if it helps, because I feel there are many 1230XA users, I can lend my card for him to try to fix WHDLoad for it. Does anyone think this is worth a shot or do you think Bert wouldn't care?

I don't feel like spending any more money on this machine, especially at the price point of 030 cards nowadays, they are really way too fucking expensive. Might as well never play games on it and that's that. As a matter of fact maybe I should just sell my A1200 since I rarely use it.

As you say I have experimented with tooltypes yesterday. Disabling caching of Chip RAM has helped somehow, I will try the other options. Thanks for pointing me to that thread, i didn't know other people had problems with this card too!

Mystery solved but issue not solved

@Akira (& others)–

Wondering if you got your issues resolved (or if you decided it was not worth investing further time and money into)? I came across your thread when I was researching my own Whdload issues (17.x & 18.x revisions), as they've bitten into quite a chunk of time and money so far...

I have a somewhat different card than yours, an Individual Computers ACA 1233n (the 42Mhz 030 model w/128Mb RAM). As you, I've never encountered issues outside of Whdload (some AGA demos which run directly from a minimal-boot, etc.) And no hard-freezes when things do crash.

I have shuffled around with many Whdload options -

- MMU / NoMMU
- NoAutoVec
- NoMemReverse
- NoVBRMove

etc. But none provide a stable setup - i.e, there's always a game that bombs out, even simple ones by just running it long enough (I had Bubble Bobble crap out on one of the final levels, for instance). Also Bloodnet AGA crashed while nothing at all was happening (I left it paused over a few hours)

I first replaced a previous (Typhoon 1230 Mk2 w/SCSI & 32Mb RAM) accelerator, thinking new hardware would solve this. The ACA line had also been reported as more compatible (at least the ones _prior_ to the 1233n)

Thinking it was the mainboard, I got it fully recapped and had both CIAs + Paula & LISA replaced and socketed. Also had the timing fixes done, i.e, the E123c & E125c removed. The mainboard is a rev. 1d4 btw.

The guy (a well-known and very knowledgeable recapper on Amibay) told me it was a very clean board and also did extensive testing, but found everything to be 100% functional.

I love my Amigas, but I am at a loss of how to correctly remedy this. I mostly get the Acccess Faults - which seemingly occur at random. I've never gotten any autovec-related ones, but that option 'seemed' to improve things slightly.

I don't think it is a heat-related issue, as many gfx-intensive demos (e.g, The Black Lotus' Tint, Captured Dreams, Goa, etc.) run properly every time.

I thought about the Kickstarts, and might try to replace those (after I determine which ones are 'good' by comparing the hashes). And also which ones to tinker with, as there are several other files despite the 512kb 'actual' kickstart ROMs.

But obviously, sinking an indefinite amount of time and resources into it is not feasible - and it would be better to get my kicks from my A500s (although I really like Whdload for its ease-of-use and not having to hassle with floppy/adf swaps)

Anyway, sorry to resurrect an old thread. But I thought as a final measure I'd see if you finally came to the bottom of your mystery and solved/worked around the issue.

Or if you eventually gave up. Either outcome would be of interest.

[Amiga1992]

Originally Posted by Drag0nFly

i.e, there's always a game that bombs out, even simple ones by just running it long enough (I had Bubble Bobble crap out on one of the final levels, for instance). Also Bloodnet AGA crashed while nothing at all was happening (I left it paused over a few hours)

Poste the exact errors WHDLoad spews out, for reference.

You could be dealing with a corrupted drive (by way of wrong maxtransfer values set up). Since you have the same issues with both accelerators, I would not be looking at the accelerators at first. I don't know exactly what "access errors" you mean but I have a feeling this could be your culprit.

Could also be related to capacitor death or timing fixes needed (what revision motherboard do you have?). Too many factors, you need to be more specific.


The problems described in this thread are more than probably the fault of incompatibilities with the particular turbocard we have. I offered to send it to Wepl but he never wrote back, so I guess he didn't want it. So far, then, all these issues remain as long as I use that turbocard.

[Drag0nFly]

Originally Posted by Akira

Poste the exact errors WHDLoad spews out, for reference.

You could be dealing with a corrupted drive (by way of wrong maxtransfer values set up). Since you have the same issues with both accelerators, I would not be looking at the accelerators at first. I don't know exactly what "access errors" you mean but I have a feeling this could be your culprit.

Could also be related to capacitor death or timing fixes needed (what revision motherboard do you have?). Too many factors, you need to be more specific.

Unfortunately I do not have the Whdload errors memorized, but will make a note when it reoccurs (and create a separate thread for it). I know I also got the 'Line 1111 Emulator Error' a few times previously.

All the caps are as previously mentioned replaced, and the timing fixes on the 1D4 board were done. Lisa, Paula & both CIAs were also replaced (although nothing was wrong with them, done as part of putting them into sockets). I changed the maxtransfer values for all partitions to 0x0001FE00 as recommended quite some time ago but didn't have any impact.

Could probably do some kind of disk-check to make sure the partitions on the CF card are okay and/or copy the files to it again. But the curious thing is that it happens when there is no disk-activity (for games which solely are loaded into RAM, like Bubble Bobble, which only takes a few hundred kilobytes)

Originally Posted by Akira

The problems described in this thread are more than probably the fault of incompatibilities with the particular turbocard we have. I offered to send it to Wepl but he never wrote back, so I guess he didn't want it. So far, then, all these issues remain as long as I use that turbocard.

I see, too bad. Yes, I agree that your issues do sound like they are specific to that accelerator. I guess I was hoping that some as-yet-unknown combination of Whdload options would have cured it.

Thanks for replying.

[jotd]

I suggest that you try your .slaves using the latest JST with whdload emulation and see what happens. It may work differently.

[Amiga1992]

Originally Posted by Drag0nFly

I changed the maxtransfer values for all partitions to 0x0001FE00 as recommended quite some time ago but didn't have any impact.

Oh so you DID have the wrong value?
If you had the wrong value then changed maxtransfer, it's possible data got corrupted while the value was wrong.

Unless you reformat and copy again everything after you change maxtransfer to the proper value, you cannot discard data corruption.

I had that issue and errors diminished greatly after I re-did my drive again. I never had a "Line 1111" error again after redoing my CF card.

But the curious thing is that it happens when there is no disk-activity (for games which solely are loaded into RAM

But where did the game get loaded from? From the drive of course. The computer does not know if the data is bad. Even if it's one byte of difference, WHDLoad seems very sensitive to this.

It's a pain, but redo your drives and see what happens. And get pen and paper ready to write down any error that pops up.

[Drag0nFly]

Originally Posted by jotd

I suggest that you try your .slaves using the latest JST with whdload emulation and see what happens. It may work differently.

It would be interesting to test that. But where is the latest version? I Googled around for it, but only found references to the 'original' JST which was long-abandoned (http://jffabre.free.fr/amiga/bintools/LATEST/jst.lha), with the latest news entry from 2001. But then again I see it mentioned in a recent thread that development is still active and I guess you are the right person to ask as you're maintaining it.

Originally Posted by Akira

Oh so you DID have the wrong value?
If you had the wrong value then changed maxtransfer, it's possible data got corrupted while the value was wrong.

I guess I should have written that I verified the value. I can't say for sure if it actually had a different value (this was a little over two years ago, when I first got the WB3.1 CF)

Unless you reformat and copy again everything after you change maxtransfer to the proper value, you cannot discard data corruption.

Originally Posted by Akira

I had that issue and errors diminished greatly after I re-did my drive again. I never had a "Line 1111" error again after redoing my CF card.

But where did the game get loaded from? From the drive of course. The computer does not know if the data is bad. Even if it's one byte of difference, WHDLoad seems very sensitive to this.

Well, yes. My point was simply that if it crashed at different parts after successfully loading - and sometimes working fine - it would sound odd if it was disk-corruption. I therefore assumed it was Whdload or an incorrect option.

For instance the intro sequence for Shadow of the Beast II would crash right before the winged creature landed on the roof to take the baby, and it was 'fixed' by adding the 'NoMemReverse' option.

But you mentioning that it significantly reduced your amount of errors does sound promising obviously.

Originally Posted by Akira

It's a pain, but redo your drives and see what happens. And get pen and paper ready to write down any error that pops up.

I'll grab a picture off the screen next time. Not sure if I have time to fully redo the drive this year even, so I'm not currently counting that as an option.
Wish someone would have made a .hdf distribution so it could be dd-ed to disk and be done with it. I did buy the drive from a licensed seller (with the WB key) so he should have known to set it up correctly...

[jotd]

Newest version of JST here: http://jotd.pagesperso-orange.fr/amiga.html
(another version is in the works, with even increased whdload compatibility)

[Drag0nFly]

Back from hibernation.

I did some more testing - although much remains. Basically, after @Akira's suggestions I;

- re-did the WHDLoad install, replaced every slave, did sfs-checks on all volumes - without errors.

- verified with an original disk-image that the red-herring 'MaxTransfer' value was set correctly from the start, so that is not the culprit. (Sorry for any confusion earlier.)

- compared the same setup on FS-UAE (identical disk image, created with dd) and none of the crashes appear. I.e, the disk is not at fault as the exact same files are being used to launch via the UAE emulator. Then again, all the relevant files which could potentially have been corrupted were replaced with new slaves & old slaves overwritten (and crc-checked with lha when unpacking)

- Tried a few slaves with the v5.0 beta rc6 version of JST (thanks @jotd). Seems to behave similarly to whdload 18.3/.2.1 + the 17.x versions I tried earlier - but too early to tell. Also notice there is a v6.0 version from Dec 27th which I am eager to try also.
btw @jotd - is there a quitkey that can be used with JST? I normally use the middle mousebutton in WHDLoad for this as the keyboard is not nearby

- Grabbed a few pictures of (some) of the crashes which are occurring, if they are of any help. Again, I've yet to see one happening in FS-UAE, but will supply that as well if it occurs. I even got a yellow guru meditiation / recoverable alert (first I've seen of those) which occurred after exiting whdload and clicking on a folder in Workbench (solved via reboot)

Bottom line is that I think this is either the ACA1233n 030/40 128mb accelerator, either the card itself or an incompatibilty with my rev. 1d4 mainboard (which was thoroughly checked, recapped, cia/lisa/paula chips replaced and timing fixes performed, et al. by a knowlegeable person on Amibay)

However, due to this I am now looking for a second A1200 motherboard, revision 1a or 1d1 (based on feedback from others). I'll also do some tests with a Typhoon 1230 MkII 42Mhz/32Mb/scsi card (which I did not use due to non-disableable scsi causing timeouts on boot)

[Drag0nFly]

Apparently, the –

Exception "Line 1111 Emulator" ($2c) at $7A008 occurred'

is an FPU access - according to information from Jens Schoenfeld(!). Which I find curious, as the system has never had an FPU on it. He suggested to clean the system of FPU-requiring software (whatever that means) and to check datatypes.

Nevertheless, that is just one of the errors, and more frequent ones have been popping up when for example doing a memory check with Keir Fraser's SysTest (which only occurs when the ACA accelerator is plugged in). I'm thinking the errors from whdload are *not entirerly accurate* due to the system instabilities.

There was also a suggestion that this was PSU-related (which could potentially be the case), but apart from the two 4.5A A500 PSUs I've been using I don't have another third one to test with.

But it lends the question, have anyone here experienced system instabilities which were caused by a bad PSU? (and which only occurred when having an accelerator card fitted?)

[jotd]

> For instance the intro sequence for Shadow of the Beast II would crash right before the winged creature landed on the roof to take the baby, and it was 'fixed' by adding the 'NoMemReverse' option.

Dead giveway for "your RAM is faulty".

Whdload allocates memory using MEMF_REVERSE by default (top of memlist), JST does the same but doesn't have NoMemReverse switch (yet ).

By changing the flag, you're using low addresses. It doesn't matter anyway since you've got fastmem. It's only useful when you have chipmem only.

So your memory is probably at fault. Can't you test the memory using a memory test program (aminet)

I wasn't aware that whdload had an "middle mouse" exit button. I'll check that (still have to figure out how to read the middle mouse button, and I don't have a 3 mouse button to test, well on WinUAE it should be ok). Noting down the features to add to JST

JST quitkey is being discussed in another thread. I've added an environment variable (QUITKEY) to all slaves can read the setting (there's no s:JSTprefs file). Only in 6.1 beta.

Be patient, I've planned to work on JST mid-february. New version out in march.

[meynaf]

Originally Posted by Drag0nFly

Apparently, the –

Exception "Line 1111 Emulator" ($2c) at $7A008 occurred'

is an FPU access - according to information from Jens Schoenfeld(!). Which I find curious, as the system has never had an FPU on it. He suggested to clean the system of FPU-requiring software (whatever that means) and to check datatypes.

This error can also indicate code going haywire. Can be FPU access, but can be something else as well.

[Drag0nFly]

@jotd – as I wrote earlier I did memory checks with SysTest, which reported issues when the ACA card was plugged in (*both* for fastmem and chipmem)

When SysTest was run without the ACA card, the chipmem test ran for around 600 passes without any faults.

I also experienced a hard freeze when the system was just sitting idle (w/ the ACA card plugged in), which is not very reassuring, and was the reason the PSU was being pointed at.