Atari STe SD card reader on the Extended Joystick Port

[Orion_]

I disable int to speed up the reading, and also to get a stable clock signal, since the clock signal is generated by software bit banging.
I don't know if it is necessary to have a stable clock signal, but I guess it is at least at the init of the sd card

[atary]

I've done a little more experimentation.

I removed the disabling of the interrupts in the code. This has solved the keypress noises and associated phantom keypresses. So it appears that this happens if interrupts are disabled for too long (not sure how long too long is)) if the keyboard is sending data such as mouse packets.

However I can no longer write to the card. I have absolutely no idea why. I tried to fix the directory and FAT sectors using a tool on the PC, and this at least has fixed the "funny" numbers shown when doing "Show Info" on drive C: , but since I cannot copy to this drive or create a file I do not know if this is really fixed.

[atary]

I disable int to speed up the reading, and also to get a stable clock signal, since the clock signal is generated by software bit banging.
I don't know if it is necessary to have a stable clock signal, but I guess it is at least at the init of the sd card

OK. I saw that you had written the code to be as fast as possible (e.g. unrolling loops), but it never occurred to me that the disabling of interrupts was for the same reason.

[atary]

Just another update.

I can now write to the SD card again. Both drive C: and D: are working!

The solution came to me in a flash, so to speak. The old full-size SD card has a read-write protect switch on the side. Some days ago I was surprised to find it. I simply moved the switch position and the card is now working for writes. I must have left it in the read-only position.

Despite my version of the code removing the disabling of interrupts, I am still getting phantom key presses if I move the mouse during disk I/O, albeit far less frequently than with the original code. So once again I am scratching my head. At the least the SD card as a faster drive is now usable.

It's actually quite important that I can use it, as I am working on a hardware project to connect an Arduino to the ASCI port by means of DMA. It sometimes leaves the floppy (actually a Gotek) in a funny state.

BTW I'm aware of the other faster drive using SD card project, the one which uses a STM32 connected to the ACSI port. My project is somewhat similar.

[atary]

I wonder if anyone can give pointers as to how to put the driver code into (cartridge) ROM. I have a diagnostic ROM PCB, and it wouldn't be too difficult to replace the ROMs with custom EPROMs. I just want it to be quick and easy after reset to re-establish operation of the SD. Since my code locks-up and crashes, a re-boot is often necessary.

Possibly the driver could live in the ROM and during boot the initialisation could be called. I am not familiar with the Atari boot sequence, but somewhere along the line it must check for presence of a ROM cartridge. I am sure there will be threads elsewhere, I just haven't searched yet.

I would expect that there is some kind of ROM code framework out there somewhere. Please let me know if you have found any ROM code templates.

Additionally I wonder if it is possible to use all the extra space in the ROM as a ROM (not RAM) disk? I could store the DevpacST assembler PRG here. This is the tool I am using for my program development.

As I write this I am starting a new debug session. I have just run the driver software off floppy and I am now trying to run GENST2.PRG (DevpacST) from the C: drive. I get a "TOS Error #35". Oh dear, this doesn't feel good. At least "Show" of my assembler source code show it displayed correctly (it is not corrupted).

[MiggyMog]

You could possibly use a reset proof ramdisk in the meantime buthttps://www.exxoshost.co.uk/atari/store2/#0165 has a diag cart plus http://www.gossuin.be/index.php/shop have has nice diag carts and ROM programmer.

[AnthonyJ]

I wonder if anyone can give pointers as to how to put the driver code into (cartridge) ROM.

This thread looks to be what you're after: https://www.atari-forum.com/viewtopic.php?t=14086

[atary]

Many years ago I had a cartridge called "Backpack". It took some time to find it's name, as there isn't a lot of information about it online. It contained a number of utilities, one of which was a reset proof RAMdisk. It probably was included with my old 1040STF which I sold back in the late 80's?

@AnthonyJ - thanks for the pointer.

Now that I have read these postings, clearly I have been getting the ST ROM format confused with the Atari 400/800/XL/XE 8-bit cartridge which is "probed" during reset/boot and code executed if the necessary conditions are found.

For whatever reason both my C: and D: drives are corrupted. At least one assembly source file is corrupted. I cannot delete or rename files. I have no idea how this has happened, but of course I have tinkered with the original driver code (including changing interrupt behaviour).

I'm getting frustrated. In theory this is a neat solution and exactly what I need, hard disk type behaviour, faster than floppy, and NOT using the ASCI/DMA port. It just feels like the Atari ST file I/O is very fragile. Possibly disk structures in memory got corrupted? Clearly it can't be that bad since many people use some kind of hard disk (SCSI or more modern) without any problems whatsoever. However when a disk does get corrupted in some way the ST doesn't appear to have any way to detect this and flag to the user. On a PC there is CHKDSK, but I am not aware of a similar tool for the ST. I don't even have a tool to re-format the C: and D: partitions. I could write my own, but this is just distracting me from the main project.

[Orion_]

I wonder if anyone can give pointers as to how to put the driver code into (cartridge) ROM.

the best solution I had in mind was to make a cartridge with driver included in ROM and the SD card port on the cartridge itself, to get even faster speed.
but I'm not an electronic engineer so I can't do it

Also, I won't go further on my SD card project via the Atari STe/Falcon joystick port because it's too slow, and even with an arduino to speed up the sd card read and transfer data via 8 bits, it won't be as nice as the "acsi2stm" project is much better and faster.
And for the Falcon I just recommend to use a netusbee/hydra cartridge with the awesome UIP tool to easily transfer data via ethernet very fast.

[Vaskar]

is there a link to download the latest driver ?

[ragnar76]

So, i've tried it on my suska, either, my suska does not support the extended ste joystick ports or my card is faulty but the driver says: "SD Card on Extended Joystick Port A". Does it mean the driver detects the reader?

2c5d914f7cd1b802.jpg

[Vaskar]

So I found tha last version of driver. I made 4 fat 16 partitions. I have only the first recognized, and one only new drive C. Fdd is working but the filenames are corrupted . When I run a program from drive C the mouse gets grazy with a lot of beeps.

[umatthe]

Hi,

I think I found the bug in the last driver Version 1.2b. Probably all SDHC-Cards with a FAT using Clustersize 2 or bigger do not work.
In SD_ReadData and SD_WriteData I replaced the:

addi.l #512,d6
by

addi.l #1,d6
move.b sd_type,d2
cmpi.b #3,d2 ; SD_CARD_TYPE_SDHC
beq.s .SDHC1
addi.l #511,d6
.SDHC1


With this change I could read and write big Files with serval SD-Cards.

ciao ciao
Udo

[atary]

So I found tha last version of driver. I made 4 fat 16 partitions. I have only the first recognized, and one only new drive C. Fdd is working but the filenames are corrupted . When I run a program from drive C the mouse gets grazy with a lot of beeps.

Hello Vaskar, look back a page or two at my earlier posts.

I have suffered exactly the same problems.

The problem with the mouse is caused by the driver software disabling interrupts during SD card I/O, which blocks the interrupts caused by the 6850 UART receiving data bytes from the keyboard (which includes mouse movement information). I experimented with disabling the interrupts, but had other problems, such as SD card corruption. The author explained that interrupts were disabled so that the SPI protocol (which is how the STe speaks to the card) ran with no pauses. It might be the pauses introduced by re-enabling interrupts, result in the SD card not being happy with the resulting SPI waveform. This is only a guess.

[Orion_]

I updated the driver with umatthe patch (not tested)
http://onorisoft.free.fr/atari/sdextjoy.zip

[Badwolf]

Hi Orion_, I've been watching this project for a while but only today decided to give this a try. First on my STE then on my Falcon.

Writing is bit unreliable on the Falcon, but as a way to get software onto the system in an easily accessible Windows/Mac compatible media format, it's excellent.

With an accelerated Falcon I was able to read at about 700kbps. More than adequate!

Cheers,

BW.

[Vaskar]

I can't believe so many months passed without testing again
So I tried the new driver
SD card recognized from the driver
FDD A saw contents only the first time I opened it . All other times I have no contents
FDD B saw contents of FDD A
SD works fine running programs but is read only
The SD card has only one partition 32MB and is an old one 2GB
STE with 4MB