Atariscne.org

... perhaps 10 years late but hey, it does. ;)
 
I don't remember how long it actually took me to convince / exhaust him, but one day in Spring 2019 PeP gave me access to his sv_drivers git repository. Naturally, I jumped right onto it let it sit on my disk for another seven years. :-)
 
A couple of months ago, while working on a totally unrelated project, I remembered about this repo and out of curiosity (the famous first words ;)) I tried to compile at least sv_xbios.prg (unfortunately, there was no history, just a random dump of its 2019 state). Of course there were a ton of errors, referencing an ancient mintlib, requiring native Atari tools and gcc etc. And most likely I would have given up if it weren't for Claude -- I let it fix them, one by one, every time with a careful code review.
 
It took Claude maybe 15 minutes to get me into a proper cross-compilation friendly state (of course, with my previous verification that I can produce 1:1 identical builds as the last official release). And after that... I was hooked. One bugfix after another, with Claude disassembling NVDI drivers, comparing code paths for different bit depths, relentlessly searching for stuff which would have taken me weeks to find and analyse. Then I could design a fix, verify it and move onto the next bug (yeah, there were quite a few!)
 
When I was done (after ~2 weeks) I got this crazy idea: how hard would it be to actually include SV_XBIOS.PRG into CT60 TOS itself? As it turned out, not very. Literally less than 100 lines of code.
 
Parallel to that (what are you supposed to do while waiting for Claude's responses, right?) I got an even crazier idea: first I let Claude design a SVEthLANa driver for Linux. I was blown away to see that the whole "driver" was basically just a few configuration settings because the OpenCore MAC unit, which Nature used in the FPGA, has Linux support already (which actually makes sense, how else would have the OpenCore authors tested it, right?)
 
Seeing that its transfer rate was much better than FreeMiNT's, what about porting the whole driver from Linux to FreeMiNT to see whether its (presumably) cleaner design wouldn't help here? At first, the numbers weren't very encouraging but it got better very quickly (upload = sending from Atari to PC, download = receiving from PC to Atari):
  1. Baseline (Linux-m68k current kernel's driver for FW010): upload 700 KB/s, download 1.4 MB/s
  2. FW009 driver: upload 3274 KB/s, download 710 KB/s (that 710 KB/s was actually a driver limit, due to a bug in its implementation)
  3. FW010 driver by Nature: upload 135 KB/s (!), download 1.6 MB/s (here we can see that download more or less matched but upload was totally broken)
  4. Ported driver: upload 42 KB/s (!!!), download 3 MB/s
  5. After discovering and working around four hardware issues with Svethlana's DMA: upload 4 MB/s, download 3 MB/s (huh!)
Yup, you read it correctly, FreeMiNT now beats Linux by a factor of 2-4 and surprisingly, it isn't because the Linux driver doesn't contain the workarounds (it uses a different way of preparing packets so the bugs are not so visible there).
 
An interesting fact: 32bpp resolutions, at least the 1920x1080 I have been using, seems to upset Svethlana's DMA in a much more visible way. My fixes are almost useless in 16bpp but in 32bpp I can see all of them working their ass off to keep the packets flowing (that also means that there is a slight performance decrease, about 200 KB/s in both directions due to retransmissions).
 
Where to get all this great stuff you ask?
  • grab Linux 7.3 when released, (almost) everything has been pushed upstream (yeah, I also added some framebuffer fixes; of course, with Linux being Linux and m68k being a totally obscure platform, you are most likely going to end up with compiling everything by yourself... not so hard with docker and debian's multiarch support but still, nothing for newbies)
  • SuperVidel Drivers 1.00 (unpack & replace your existing files)
  • CT60 TOS 3.00 (built-in SV XBIOS, with a few fixes/additions inherited from CT60 TOS 1.03f which has been released today, too)
  • New SVEthLANa driver is now part of FreeMiNT snapshots
Look at my hastily filled desktop with random utilities to see this in action! :-)
 

Comments

Cyprian
Sunday, 20 September 2026 10:02
well done Mikro
Quote
Tord
Sunday, 20 September 2026 11:22
Nice work!

I should actually have met Hencox and Instream from Nature this weekend at Hösthack (see www.sak.nu for more info in swedish) if it wasn't for a schedule confilict with my wife's 40th birthday. Some things are actually more important than Atari gettogethers! :)

I'm sure they are very happy to see your progress.
Quote
Cyprian
Monday, 21 September 2026 14:22
"After discovering and working around four hardware issues with Svethlana's" - this part is very interesting. Can you please elaborate more how these errors were discovered?
Quote
mikro
Monday, 21 September 2026 23:03
Quoting Cyprian:
"After discovering and working around four hardware issues with Svethlana's" - this part is very interesting. Can you please elaborate more how these errors were discovered?

Trial and error and most importantly: tens of iterations with Claude connected to my Falcon, listening via Linux's tcpdump on how many packets are corrupted and *where exactly*. So that lead to weird discoveries like "64 bytes of the last packet are repeated in the current packet if the packet lies on a 1 KB boundary" and similar perks.

FW010's driver, in contrast to FW009's one, uses DMA for sending packets over the wire and it seems that it isn't protected against other accesses (reading by the CPU but even the video chip, too).
Quote
earx
Tuesday, 22 September 2026 17:27
wonderful!! so the LAN add-on for the supervidel now runs at max speed? and the graphics side of things was already running well? guess that's mostly setting up the superblitter or?
Quote
mikro
Wednesday, 23 September 2026 00:19
Quoting earx:
wonderful!! so the LAN add-on for the supervidel now runs at max speed? and the graphics side of things was already running well? guess that's mostly setting up the superblitter or?


Hey Earx, nice to see you here!

The answers are yes, yes and yes. ;) (SuperBlitter is used for VDI blitting; there are some areas which could be translated into SB tasks but overall the performance is great).
Quote
earx
Wednesday, 23 September 2026 10:50
is proportional text rendering also done with bitblit? the charset is in video ram?
Quote
mikro
Wednesday, 23 September 2026 12:02
Not yet but it could. ;) (I mean I checked it against what NVDI calls when rendering text). However the interesting question is whether it's worth it: glyphs are small, SB setup isn't for free so it could backfire pretty easily.
Quote
earx
Wednesday, 23 September 2026 18:57
Interesting. If performance is already good as you say, that then means copying from TT RAM -> SV is still very fast? How many MB/s??

I see the blitmodes in the Supervidel, but they seem somewhat weird for sprites. Still happy it supports chunky sprites, but RLE would have much better. However, if it is an absolute internal bandwidth monster, who cares. :)

I see you are doing loads of driver related work. Impressive!
Quote
mikro
Thursday, 24 September 2026 00:17
Yes, SB's blitting capabilities are rather limited: especially that you can't set the transparent chunky byte manually, it has to be always 0.

TT RAM -> SV RAM takes almost no toll, similar to TT RAM destination it is about 30 MB/s with move16 (in both directions!) Only VRAM VRAM is "slow", around 20 MB/s but you should use the SB for it.

CTPCI's numbers for TTRAM -> VRAM are similar (~30 MB/s) but the other way around it is much worse, around 9 MB/s, btw.

In any case, move16 is key here. movem.l and friends will get you at 50% of that usually.
Quote
insane
Thursday, 24 September 2026 22:32
CT60 TOS 1.05 rebase coming soon(ish).
gotta handle the oldsk00l part of the deadline demoparty first :)
I'm also planning (together with mikro) to merge 1.05 with 3.00 in the future
Quote
earx
Friday, 25 September 2026 09:01
movem vs move16 must be a nice boundary overlap case. well at least 060 doesn't crash like ARM on such instructions. :D

just basic vramvram blit is awesome tho. i read that the first blitter version of the ET4000 blasted something like 56MB/s. is SV similar?
Quote
mikro
Monday, 28 September 2026 01:00
I'm pretty sure that it is way, way more. I can't find an exact number anywhere now but SuperBlitter's numbers should be around 1 GB/s.
Quote
earx
Tuesday, 29 September 2026 20:34
1GB/s on a custom Atari design. that's nuts :D
Quote

Add comment

Submit

© 2025-2026 The Atariscne Collective | info@atariscne.org