Nearly - guess again. :)

Put it this way - it takes a looooong time to compile, and is too slow to be of use on anything less than an X1000, really. But I've never let a little thing like that stop me. Wish I had an X1000 though.

Of course if anyone wants to test it on their hardware, whatever it is, let me know.

Oh, it works, too. :)

Sorry to reply to my own thread, but in case it's of use:

I think I've got it working. The program that uses it runs correctly anyway!

I did it by just making the data array in the code the prototype - then in the init function I AllocVec()'ed the array as a MEMF_EXECUTABLE chunk and copied it in, and used that as the pointer instead. It worked!

With a bit of luck I'll be uploading the program that uses it soon (see if you can work out what it is :P ).

Hi everybody,

Does anybody know of a working build of the co_thread library (http://byuu.org/articles/optimization) for AmigaOS? The version I have doesn't work because it causes an ISI in Grim Reaper - it has an array in which it stores compiled machine code, and tries to execute this. For some reason this work under OSX and Linux (it would appear) but causes an ISI on AmigaOS.
There's apparently a source code file for an assembly version but I can't find it - it appears to be missing,

Does anyone have any pointers they could give? Thanks to anyone who can!

Posting this from TW beta 3 on my Sam 440ep@600MHz.
It's still not exactly fast but then as I said - it's on my Sam440ep, so I wouldn't expect it to be! Works very well though so far.

BTW, I didn't see anything in the readme in the archive about opening it on a custom screen. Tried adding a screen called "Timberwolf" but that didn't do anything. Am I missing something obvious?

Keep up the excellent work!

If it worked before with my drivers then it should still work... can you send me a sashimi debug log?
The old drivers are still on my website.... look at the Change Log for the dates they were uploaded and put that date in the URL of the archive instead of the current build's date.

Not a massive change this update, just another format added and a few other internal bits probably... the change log is on the website.

OK, thanks - I've just emailed Hans-Joerg again just in case he picks up the mail this time (he probably has a fairly aggressive spam filter!). If he doesn't reply though I'll try and get a modified version of E-UAE done.

@ChrisH

I'm still trying to get the AmigaInput developer files, but in the meantime I can hack the Catweasel joysticks inputs into E-UAE. Who should I ask for the source so I can put the code in - i.e. who's the current maintainer?

Thanks!

Thank you - I want to get it working with AmigaInput but I never quite got all the files I needed. I've raised another query at Hyperion's forum - maybe I can get the needed files. It should be an easy job once I have them all.

Hi people,

A quick heads-up: at my Catweasel page (http://www.retroreview.com/iang/Catweasel/) I've just put up the latest version of my Catweasel drivers for AmigaOS 4. I've also included the source, and I've already done MOS and AROS in the past, so it wouldn't be too much work to port it to work on those systems either, probably.

Currently supports the following disk formats:
Amiga Double Density 880KB
Amiga High Density 1.76MB
MS-DOS Double Density 720KB
MS-DOS High Density 1.44MB
Apple Macintosh DS varispeed 800KB
Apple Macintosh DS varispeed 400KB
MS-DOS 40 Track DSDD 8 Sectors 320KB
Commodore 1541 (PET/C64/VIC-20/+4 etc.) 35 Track 190KB
MS-DOS 80 Track DSDD 1.2MB
MS-DOS 40 Track DSDD 9 Sectors 360KB
Amiga Double Density 880K 5.25" 880KB
MGT Sam Coupé 800KB
Texas Instruments TI-99/4(a) 90KB
Atari 810 SSSD 90KB
Acorn BBC Micro 40 Track SSSD 100KB
Acorn BBC Micro 80 Track SSSD 200KB
Acorn BBC Micro 40 Track SSSD 100KB 3.5"
Acorn BBC Micro 80 Track SSSD 200KB 3.5"
Sinclair Spectrum MGT +D 800KB
Amstrad CPC / Sinclair Spectrum +3 180KB
Tatung Einstein TC-01/TC-256 200KB
Amstrad PCW 8256/8512 180KB
Atari ST DSDD 720KB
Atari ST SSDD 360KB
Triumph-Adler Alphatronic PC
MS-DOS Double Density 640KB (8 sector)

Instructions for using this with WHDLoad to allow installation of copy-protected disks is all on the webpage.

Any feedback gratefully appreciated. Donations also very warmly welcomed. :)

As usual: any questions, just ask. Also, if you have a weird disk format I've not supported, it's because I don't have an example of that format. If you can send a disk to me I can probably add support to the next version.

Thanks for reading!

It seems like it's initialised ok, it just can't see past it....

All the Win/TV cards I've tried have worked so far. In fact I only have one TV card that doesn't work, and that's because it uses a PCI bridge which AmigaOS 4 doesn't seem to cross - it just doesn't see anything past the bridge (including the Conexant chipset). I think I've tried about 5 Win/TV cards so far - I use them as my reference platforms.
I've also heard that the ATI All-In-Wonder cards (I think it was) worked too, but I think they'll be 5V so no good in a Sam. It's the 3.3V specification you need to be careful of.

I personally don't understand this fixation with processor speed.
I have a Sam which runs at 600Mhz and works fine. My A1 is still easily fast enough. If you're not running games, there are other things more important, and power consumption and passive cooling is one of them, as is general efficiency of the system.

Just PPC is slower than x86 doesn't make it dead any more than it makes ARM dead - and nobody in their right mind would claim that ARM was dead.

I would add:

The bad:
- Seriously angering the few hardware developers left who've piled thousands into r+d and making new hardware
- Basically confining us always to use Powermacs forever as nobody will get enough return on a new design to survive.

For me the bad outweighs the good so far the scales hit the floor on one side.

I know we need more users, but advancement in niche computing will never be cheap. Only staying in the past is cheap.

Quote:

True - and believe me when I say I mean no disrespect to the MOS team at all - but every hour spent on someone's demand for support for whatever Mac they have, is another hour that could have been spent on improving what is already there.

Working only on dead-end technology (i.e. PowerMacs) is just that - a dead end.

It's been noted several times on A.org and places about how whenever the MOS people release a build that works on a "new" machine, there's a spike in the number of registrations. But what will they do when they've already supported all the platforms they can?

Secondly, while they (the MOS guys) are busy playing catch-up with all the Mac platforms, it's taking time away from developing the OS. With AOS we've seen a lot of advances in the core of the OS, because the Friedens have worked on that rather than trying to support 100 platforms.

Definitely, 100%, glad there's no PowerMac support. It'd be a big mistake. Sure, it'd attract more users in the short-term, but in the long term....?

Which is a good thing because releasing os4 for old macs would in one stroke destroy the entire market for new os4 machines which by their nature have to be expensive.

We would have no Sam, no netbook and definitely no x1000. No thankyou. We need to encourage people like Trevor and Acube, not stab them in the back.

Excellent work on this port!

It's terribly slow on my Sam 440ep, but then it's got no hw acceleration, it's a beta, and my Sam is only 600Mhz, so that's not terribly surprising!

Was really nice to see YouTube working (albeit slowly) on my AOS 4 machine at last!

Looking forward to the next updates!

I'm afraid that datasheet doesn't help.... or at least, it does, but it's for the Cx2388x chip (which I've already got working, with a lot of help from that very datasheet).
It's the Cx22702 DVB-T chip I need the datasheet for... but thanks for looking!

@Hans
The TV cards will always be very slow on RadeonHD machines because there's no way of directly displaying a YUV422 format bitmap (like overlay does). At least until there is a way. :) I can actually do it with RGB565 but that sucks up a lot of PCI bus bandwidth.

Incidentally, the reason I gave up on AmiTV originally was because my machines had problems with the overlay mode. On the Sam440ep, for instance, it picks up noise in the graphics when using a buffer in system RAM, and using the overlay directly only works for a short period and is likely to crash the machine. I suspect the Sam may be getting confused as it uses DMA in other places too. My Peg II has no such problems and it works just fine! Which is nice.. but also disappointing! I always thought the Sam trouble was to do with the endianness of P96 drivers, but for some reason the similarly clocked PegII just doesn't have a problem. IIRC my Peg2 has a Radeon 7000 in, the Sam has the onboard (obviously, else there'd be no room for the TV card :) )

No help really, I'm afraid, but thanks for the effort!

The problem isn't how DVB works, as that's covered by the chips on the TV card. What I need to know is how to program the Conexant chip in question... I.e. what registers do what and where are they, that sort of thing.

Thanks again for trying, though, but it has to be the proper Conexant datasheet for the chip.

Incredibly, another version appears to have materialised on my hard disk.

http://www.mutant-caterpillar.co.uk/i ... f/AmiTV_20120209_NTSC.lha

As the more perceptive among you may notice, this is an NTSC build! As before, it supports all bt848/bt878/cx2388x chipsets.

Please send feedback to me... not had any so far on the PAL build at all, so seems like not many people have the cards needed...