Device programming references

[BlueAchenar]

Hi,

could someone point me to a few good references on programming devices?

[davideo]

Originally Posted by BlueAchenar

Hi,

could someone point me to a few good references on programming devices?

Have a look in the Zone - Hardware reference manual in there at the moment.

Dave G

[BlueAchenar]

Thanks! I had downloaded it a few days ago.

Even references to printed books would be great. I'd try to find them 2nd hand.

[xaind]

The ROM Kernel Reference Manuals are the best source I am aware of. There were three editions. In the 3rd edition, there was a whole manual devoted to devices.

The first and second editions had a combined "Libraries and Devices" manual.

If older material (i.e. Kickstart 1.3 era) is ok, then you might also look at the Amiga System Programmer's Guide and the Advanced System Programmer's Guide for the Amiga, both from Abacus. (The latter book especially, for material on devices.) The quality of writing isn't the best in those books, but I thought they were reasonably good.

Hope that helps.

[BlueAchenar]

I have the Amiga System Programmer's Guide. I'll Try to find the Advanced System Programmer's Guide at a reasonable price.
Well, on to reading the book...

Edit: The first book wasn't much help. I've bought the second one. I'll read it when it gets here.

[BlueAchenar]

I've almost finished disassembling the 'compactflash.device' driver, but there's a word value at the very end that I don't know what its purpose is

EndCode: dc.w $9EC8

Is it a magic cookie? A checksum? An op-code?

Could someone enlighten me? I'll send the disassembled source if needed.

[Leffmann]

It translates to SUB.W A0, A7 which makes little sense, even more so being at the very end of a program with no further instructions. If those 2 bytes are not referenced anywhere in the disassembled code then they're most likely nothing but leftovers.

[BlueAchenar]

I'll try to reassemble the device without that word when I'm done cleaning the code and see if it works.

[BlueAchenar]

I've successfully reassembled the device finally.

Now the hard stuff. Making the cards that work when I take my blizzard out, work with it plugged in.

[BlueAchenar]

I still can't figure out what the accelerator is interfering with... anyone knows the best way to debug a device?

Can a interrupt driven device attempt to write a log to a file?

[hitchhikr]

Maybe you could use Sushi ?

Talking about debugging: i think WinUAE should have any option to reserve an address (maybe an unused custom register) in the emulated Amiga memory to send datas to a port of the Windows loopback address via tcp/ip, that would immensely help Amiga programs debugging (also maybe a windows remote debugger could be made that way), or if the emulator could send it's execution state and be interfaced with a debugger via tcp/ip a la gdb that would be even better.

[BlueAchenar]

Hum, Sushi appear to be only for monitoring serial ports.

Debugging in WinUAE wouldn't really help me because I need a real Amiga's PCMCIA port to use the device in the first place.

This device uses some opcode based timing techniques and that might be my problem. I just don't understand why I have to remove my accelerator to make some flash cards work if that's the case. Disabling it by pressing '2' should be enough.

[BlueAchenar]

Could a Blizzard 1230-MkIV interfere with the hardware register $DA8000 (credit card config register)?

This driver has some hard to decipher protocols.

It only uses these 6-byte ATAPI commands:

21h - Read sectors without retry (obsolete)
31h - Write sectors without retry (obsolete)
C4h - Read multiple
C5h - Write multiple
C6h - Set multiple mode
ECh - Recover

It tries to detect which read/write commands are supported and use them. I think commands 20h and 30h (Read sectors and Write sectors) could be easily implemented.
I think I've also found the infinite loop that makes some cards freeze the system, but I can't patch it until I understand the card's IO memory mapping and protocol.

[BlueAchenar]

Debugging devices is damn hard.

Anyone else interessed in dissecting 'compactflash.device'? I could use the help, as I do not have much time.

[BlueAchenar]

Ok. I've ruled out the Blizzard 1230 IV being interfering with the CC registers and with the timing loops.
What else about the blizzard could interfere with the PCMCIA port, even when I press "2" to disable it and take out the RAM?

[coze]

do your blizzard IV disable the pcmcia port ? mine didn't AFAIR ?

[BlueAchenar]

It doesn't disable the PCMCIA port.
Sandisk, Toshiba based CF cards and SD/SDHC cards work fine. But some other brands only work if I take the Blizzard out. Pressing "2" doesn't work and changing or removing SIMMs doesn't work either. That's why I've disassembled the compactflash.device, to see if I can find out what's going on, but I've tried some modifications and the cards still don't work.
I just hope this happens with all Blizzards and not only with mine. Someone who could confirm that would be great.

[coze]

when you disable the board they don't work, but when you take it out they work ?
it is very strange indeed. but I don't think it's a software related problem. can it be power related ?

[BlueAchenar]

I use a A500 power supply in my A1200. My hard drive is a CF card, so it shouldn't draw much power. I'm not using any other peripherals, except an RGB -> S-Video converter which is powered externally.
So I don't think it's a power supply problem, but who knows...

[BlueAchenar]

Today I made a few progresses mapping the driver. You wouldn't believe the conflicting documentation about this subject and the inumerous flags the driver writes and reads from (and tests them) which are supposed to be non-existant or always 0/1.

Anyway, I think I've found a bug which might make a lot of cards not work:

The driver assumes the I/O ports are mapped contiguosly in IO memory. The specification I have says that after a card reset we should assume the registers are memory mapped in common memory.
Maybe the AmigaOS is configuring things the right way before the driver takes over, but I'll try to force the registers to be in the right place and see if it makes a difference... but only tomorrow, I must get some sleep now.