Atari ST core

Quote from Tobias

and indeed, the stepping time should be enough to read it from sd card.

OK, if an SD-card in SPI mode can serve random data in under 5ms (shortest head settle time I've seen on any drive), this may work. We should maybe cross-check with the machine-specific times, as I know that Amiga documentation also gives recommendations for step and head settle times that are *very* conservative. My expectation would be that most programmers go with conservative timings, because they want their software to work on most (if not all) machines out there. So the 5ms timing may even be stretched.

A single cylinder (both sides) would be 28k if you agree with my 445-snippets-per-track suggestion. This would exceed the available Blockram of the Chameleon FPGA, so we're back in SD-Ram.

Just tested and Logitech PS/2 mouse didn't respond. OSD counted from 9 Mouse Debug: to 4 Mouse Debug and probably then froze, since there's not much happening in the last 30 minutes When it counted to 4 and froze there appeared letters TTT to second row of OSC-screen.

Quote from gyurco

That's 56 SD Card sectors/rotation = 280 sectors/second.

CDDA is about 172 sectors/seconds if I calculated right.

Strange the floppy (MFM data) requires higher bitrate than CDDA (already decoded). But as CDDA already succeeded, floppy might fit also, as it's not _that_ faster.

Remember I'm still thinking of keeping some data in memory, and with side-select being much faster than head movement/settle, I wanted to load both sides into the buffer. If you really want to stream from SD card, then the data rate will be cut in half, as you will of course look at the side-select signal before calculating the file offset. This brings the data rate requirement below CDDA.

However, I don't think that this compares to CDDA in any way. Remember that you don't only have a random-access-penalty for every head movement and side-select change, but you have that same random-access penalty when the (emulated) rotation wraps around. For proper emulation of sector alignment against Index and neighbouring tracks, you want wrap-around to work 100% seamless. I don't see a way around keeping at least a track (14kBytes) in memory.

I don't see this causing a huge impact on emulation speed, as copy-protection will mostly run on an un-accelerated machine, where you have plenty of SD-Ram cycles free anyway. With a little bit of Fifo buffer, you might even be able to hide this access in the slots that the ST reserves for memory refresh. And even if it has an impact on an accelerated machine - who cares? The impact will be zero when the emulated motor does not spin.

Quote from el_pasi

Just tested and Logitech PS/2 mouse didn't respond.

Do you have a Micromys adapter to try this mouse with? I only remember one detail about Logitech, and that was the transfer speed: It was a good 30% faster than most other PS2 devices I've seen before (roughly 19kHz compared to 14kHz that I've seen on most other mice), but this should not cause any trouble for an FPGA implementation, which will only top out at speeds that are several orders of magnitude above that.

Quote from Jens

Do you have a Micromys adapter to try this mouse with? I only remember one detail about Logitech, and that was the transfer speed: It was a good 30% faster than most other PS2 devices I've seen before (roughly 19kHz compared to 14kHz that I've seen on most other mice), but this should not cause any trouble for an FPGA implementation, which will only top out at speeds that are several orders of magnitude above that.

Yes, I tried same Logitech-mouse with Micromys V3 and Micromys V4 and works well with towered Amiga 1200.

Quote from robinsonb5

Thanks, that's really useful. If you're not seeing any numbers (other than the countdown) before the "TTT" appears on screen, then the mouse isn't responding to the reset command - so Jens's first hint about the communication-inhibit time is probably the key.

Indeed, there was no other numbers than countdown. On second attempt it stopped to countdown 6 and TTT appeared.

Quote from el_pasi

Yes, I tried same Logitech-mouse with Micromys V3 and Micromys V4 and works well

Good, so the startup code that I described is OK. Alastair, my "wait for BAT" routine will always time out at 3.5secs, and I am calling that same wait-for-BAT after sending a reset. If it times out, I just send reset again in an endless loop.

I have a few more delays in the "send byte" routine, which were necessary to get a few mice to work where some of them don't even work on a modern PC (only up to Win95, but not Win2000, XP or higher). I got a huge box of mice (about 50 pcs.) from Vesalia back in the days when they heard that I'm working on Micromys. After I worked through all them (and sent them back), he told me that these were all mice that didn't work with any other adapter. By the time I found out that I had a perfect set of test material, it was already too late and they were all sold - in a bundle with Micromys

Anyway, let me know if I should check the send byte routine for these delays.

Quote from robinsonb5

If the countdown's stopping, then the mouse isn't even allowing the host to talk. That suggests that my attempted initialisation is crashing the mouse!

I've reworked the init routine completely, and fixed at least one mistake in the process, so I'm hopeful that this version will behave somewhat better. If not, could you repeat the Ctrl-Esc test, please?

Good work, Alastair, with this mouse3-core Logitech-mouse responds and works normally

So I noticed people having midi ports on the docking station for TC64 V2. I bought the first batch of TC64 V2 docking station. Mine came without midi ports. So the second batch and onwards came with midi ports?

Not that I would ever use the midi ports

Edit: I see that the current docking station in the shop is for both TC64 V1 and V2. The one I bought shortly after TC64 V2 released I believe was only for the TC64 V2. And it came without the midi ports.

Quote from turrican9

I see that the current docking station in the shop is for both TC64 V1 and V2.

All Docking Stations are for all versions of the Chameleon - they can be mixed and matched however you like. When the new version of the Docking Station came out, the price was increased due to the new feature.

Quote from el_pasi

Good work, Alastair, with this mouse3-core Logitech-mouse responds and works normally

Thanks Alastair, my Fujitsu PS/2 mouse also now works with this patch.

Your idea of being able to save the settings makes a lot of sense, because in the long run it is annoying to reconfigure every time.

The white borders also seem too large to me. Is there a way to reduce them or switch them off completely?

It is encouraging that HDD support is planned.

Otherwise, the AtariST Core is doing very well for me, even the in 2021
published "Lotus Esprit Turbo Challenge Enhanced for Atari STE".
http://www.indieretronews.com/…-challenge-ste-retro.html

Thanks for your good work, Alastair.

Quote from robinsonb5

I don't think so - but I'm not entirely sure. Remember that I didn't write this core, I merely ported it to TC64, and while I don't know much about the Atari ST, I think the border sizes are accurate. (Or at least would be if the scandoubler's disabled and its displayed on a CRT using SCART.)

Sounds good. You can change the border size and, as far as I know, switch them off ... at least on the Mister.

In this video at 9:14 you can see that the menu has a "border setting".

https://www.youtube.com/watch?v=NLU9d1WQOWE

Quote from gyurco

The ST has a higher pixel clock then Amiga for example (8 MHz vs 7 MHz), but still 320 pixels in the active area. That means more pixels in the border/blank area. With a little hacking, it's possible to blank the border (using the hde signal), but it's up to the scaler in the display what size the picture will be.

To help Alastair, it would be useful if you describe the "little hacking" in more detail.