ParanoidLittleMan
-
Content Count
2,635 -
Joined
-
Last visited
Posts posted by ParanoidLittleMan
-
-
There were much more variations. Even listing them all is long thing.
Just this: I bought 520 STM in 1987, April, in Germany. It was with 6 ROM chips, TOS 1.00 De, and very similar layout as is shown on photo in previous post.
But there is modulator, PAL encoder, and PCB part where they go is different. Even under TOS ROMs are some added resistor packs. As I see, most diff. is at mouse and keyboard connectors. REV H.
Then, when TOS 1.02 and blitter came in game - poor 520 ST was still without blitter, but there was added 74LS11 under ROMs - that's needed for 2 chip TOS ROM variant. That would be REV I - you see ? Many letters later in ALPHB compared to 2🙂 And I have 2 of them, with pretty different modulator and PAL encoder placement.
They should do as it is by street addresses: Bond street, rev I/A, and for other Bond street, rev I/B . Sorry, not possible - no more free space on PCB 😄
-
On 4/25/2021 at 5:32 AM, SoulBuster said:...
For me, I like to keep to the original TOS for the most compatibility ...
Original TOS is for sure most compatible with old, classic Atari SW. But as we know that's still not enough for all SW, some just don't like newer TOS versions, for instance.
However, what about compatibility of original TOS with modern computer components, file sizes, and 'modern' years ?
Yes, people who still using old Ataris with original TOS versions have pretty good chances to experience:
No Y2K compatibility.
Crash when it is set to textual mode in Desktop, with file sizes at 10 MB and more.
Limited compatibility with wide spread and still supported on modern computers FAT16 partitions.
Limited count and size of partitions. Better said, those limits are now too bad, when like 32 GB SD cards are really cheap, and it is hard to find lower capacity ones.
All those flaws can be fixed without losing compatibility.
Fixing Y2K, large file sizes displaying was simple. Fixing FAT16 was very hard. Yes, I say fixing - because it was just not done properly. Atari and DRI decided to make compatible FAT12 for floppies, and compatible FAT16 for hard disks. Clear indicator of it is using low Endian byte order in that. And yes, hard disk partitions are compatible until size of 32 MB. Floppies are compatible, better said were, MS is who limited floppy support somewhere around 2000, so can not read usual Atari formatted floppies.
Why partitions above 32 MB size are not compatible with wide spread DOS FAT16 ? I say, after years of examination, reading diverse articles, some C source comments - the main culprit is used Alcyon C Compiler . It was just not grown up to task - and programmers needed to avoid 32-bit unsigned integers. Which are well supported by 68000 CPU. And here is the core of problem: at 32 MB size sector count goes over 2 POW 16 = 65536, and then need to use 32-bit variable for that.
But no, TOS programmers kept it on 16 bits. And I'm pretty much sure that it was because had no other choice with that compiler - well there was one - doing all it in ASM 🙂 No way then, especially not in limited time. + DRI programmers attitude was: C is king, ASM is for amateurs. And they solved it with so called large logical sectors. And it looks like: partition size: 260 MB - sector count must be less than 65536, so logical sector size is (and it must be power of 2): 8 KB, or 16 normal sector size. That self means not so efficient work, especially with shorter files, need for larger buffers, etc.
I was aware above it long time ago. And without C sources, proper compiler for it only solution was accurate disassembling, and correcting all it in ASM.
The good thing is that despite new FAT16 code is little longer, all it was shorter for some 3 KB because optimizations used - another flaw of old compiler - lack of optimizations (like using short address when it is possible).
And nicest thing is that so improved FAT16 in TOS is fully compatible with usual hard disk drivers, disks which use them. So, it is not mod, but as I call it: improving - making it more flexible, without losing ability to work with old formats. Plus, it does not need extra RAM for buffers when works with DOS or TOS/DOS compatible partitions.
Then, there is no more 32K cluster limit, it is 64 K, as should be in FAT16 - btw. it was 16K with TOS 1.00-1.02 .
And I did not change RAM layout at all, all original variables are on same place, no extra RAM needed, SW will start on same addresses as with regular 1.04 or 1.62. Pardon, if using mass storage, will start on lower addresses because of smaller buffers - ergo more free RAM for it.
-
Lot of talk about 'spurious' files in last time. But thing is not new at all. Windows 95 introduced long file names (LFN in further text), so it is far from new thing. But with today spread of cheap Flash cards and file transfers on them from some modern computer, OS problem is more spread, so it's time to perform little education, and explain why and how .
Here is how it looks with some Hex editor, disk viewer:
ACSI view:
B .I.n.f.o...rr.
m.a.t.i.o...n...
.S.y.s.t.e...rm.
.V.o.l.u...m.e.
SYSTEM~1 ..&,B
›R›R..-B›Rü7....Hex view of same:
42 20 00 49 00 6E 00 66 00 6F 00 0F 00 72 72 00
6D 00 61 00 74 00 69 00 6F 00 00 00 6E 00 00 00
01 53 00 79 00 73 00 74 00 65 00 0F 00 72 6D 00
20 00 56 00 6F 00 6C 00 75 00 00 00 6D 00 65 00
53 59 53 54 45 4D 7E 31 20 20 20 16 00 26 2C 42
9B 52 9B 52 00 00 2D 42 9B 52 FC 37 00 00 00 00There are 3 32 byte long directory records for only 1 file visible above. Why 3 ? Because compatibility with classic DOS 8.3 filename DIR record standard, what is 32 long.
For file name self there are only 11 bytes, rest holds diverse data about file pos in partition, file size, date, time stamp, and attributes. Latest is most interesting . And it is on pos 11 (starting with 0, as it goes in comp. world) . It's hex $16 in lowest field, what is actually only one holding above mentioned file data. There are bits in that attribute byte, here set on, for: hidden file, system file, directory (3 bits set) . In 2 records above it, attribute value is $0F - and that's the key here. It is value what never appears in normal usage, so they used that as flag that it is extra DIR record field, and that's basically for storing long file name self - can be only 1 of such, or more than 2 if name is longer. Will not go here in more details, there are online pages where can read more (as usual).
And now we can see why it is problem for TOS: simply because they did not have time machine (what a lamers 😁 ), so they did not implement support for LFN in TOS.
Well, TOS just threats those extra DIR fields as regular ones, and in unlucky case those, mostly name related bytes will be seen as file length, position on partition data.
And file position data can be such, what is occupied with some regular file - ergo, potential data damage. If user tries to delete that messy filename one, will delete part of regular file actually. So, better don't even try it on Atari.
To add, that here can well see that regular DOS filename is with all capital letters, that ~1 at end is because there might be multiple long file names starting with same first 8 characters.
How to avoid LFN on Atari media ? I use Total Commander when copy files to Atari Flash cards, floppies. There is possible to uncheck 'Use Long Filenames' option, and then it will copy only 8.3 field. But that means not that user should not correct manually long filenames, if they are there. And they are there often, unfortunately today too, because some are still not aware of this problem. If it is just papan.tos instead PAPAN.TOS it will be capitalized by Total Commander. But papanetina.tos will become PAPAN~E.TOS .
If doing usual copy, without forcing 8.3 filenames (by disabling Use Long Filenames) even papan.tos copy will create those unhealthy extra fields.
That would be all here (for now). Hope that helps.
-
1
-
1
-
-
I made test about what happens when delete extra (and for TOS dangerous) fields of LFN for System Volume Information folder - and as expected, all it was created again, same as when 8.3 DIR record is deleted too . So, deleting it is good, but not permanent solution - like with many of people - you fix their errors, and they will do it or similar over and over again 🙂
So, for those doing frequently connection of their Atari Flash cards to PC (MAC) delete is not really good solution - mold will grow again.
Solution: use Linux - at least I hope that new versions did not start with similar index or whatever DIR adding.
LFN filtering at Atari.
I will start thread in programming section about LFN, so who wants to see it in detail can look there .
-
Calm down folks, please. You blaming Apple for not taking care about how their OS does something not good for 30+ years old computer and it's OS.
But whole thing started in 1995, so 26 years ago, with introducing long file names. The real problem is not that they add some shorter files on removable storage, but that it causing some bad things - like bad disk usage data, unable to delete those strange name files on Atari ...
And even without that modern OS-es like Win and Mac OS write some index and like files on media, long file names can be problem when user does not care while copies files to Atari media - must take care that all what copies has 8.3 filename - like all letters capital. If not, same problem mentioned above appears, and that's worse than seeing some unwanted short files there.
This problem exists for long time as said, but it is now much more spread because cheap Flash cards and massive usage of them, easy file transfers. Still, users need to take care.
I will make Atari program what will remove all those extra LFN fields, and then users can delete this unwanted files without problems. But I'm curious how Win will act when there is only 8.3 filename left. So, need to make some test about it. I guess that will generate all it again ..
-
Blitter field below Print Screen will appear only when there is blitter in machine, or it is activated in emulator.
And min TOS 1.02 .
-
1
-
-
iTOS filters LFN problematic parts out (as well my hard disk driver SW) . Deleting it is not hard to solve, but then, Windows will write it again, so not really much helping.
And problem is not that there are few short files with strange names, long file names are real problem - TOS will handle extra records in directory - which are used for longer file names, since they fit not in usual 32 byte space , like regular files, because is not ready to attribute combination what means: extra dir record, not another file. And depending on content of those extra records diverse problems happen: TOS will see it as some very long file, so will give false info about logical drive.
Attempt of deleting such 'file' may result in diverse bad things, and that can be even damaging of data structure, data loss. Therefore those extra records need to be ignored by TOS. And that's what I solved in 2014, and added to my driver SW. Even better space for it is TOS self, so LFN filtering is in iTOS.
As said it does not delete those SystemVolume and like files - no use, they will coma back, just makes TOS not accessing extra record fields. What filename is visible is 8.3 type file name, usually with number at end.
All above does not mean that people should not care about LFN when copy files under Win to Atari storage. Avoid long file names. If some PRG is named like:
MeBest.prg - wrong. That will have extra field, so problems. Must rename it to MEBEST.PRG, before copy . Or use Total Commander, what can automatizing that process.
Configuration, Options, Display, then do unrecommended thing - uncheck 'Use long names' . And don't forget to check on back, when done with Atari file transfer.
-
I got practically same results with Mega STE as moulinaie .
Considering file sizes, it is coded in ASM, I guess.
And couple suggestions: should not do any screen write, that can make little difference between blitter off and blitter on - and text print on screen goes via blitter if it is activated in Desktop Options.
There should be stop before exit, so can read result of test. I needed to look in code to realize that it at all self measures time, because it just immediately returns to Desktop and deletes screen. Sorry, not everyone using MagiC or some TOS/Desktop extension. And maybe add new line before time show, "seconds" after it 🙂
-
1
-
-
I don't think that this SW uses FPU. It is math calculation in purpose to test raw CPU speed - and I saw diverse benchmarks done in same fashion for diverse computers.
Looking those results from first post they look realistic when it is done with real HW. Falcon and TT, and Mega STE at 16 MHz are not emulated so accurately with Hatari, and not emulated at all by other SW, as I know. So, we need tests on real HW - I will do it on Mega STE soon.
Diff between ST and Amiga 500 is pretty realistic considering that ST runs at 8 MHz, Amiga at 7.09 MHz, if I remember well. But maybe is worth to run test in different screen resolutions on Amiga - in higher video modes, not from Fast RAM it should be significantly slower. And if want, can do same on ST - although, as said all video modes work without CPU slowdown on ST, STE . But I did it on Falcon, not with this program, in past, and it was slower, especially in so called true color mode.
-
1
-
-
And something bad happened again - this time not with Atari . So, I used 64 GB micro SD card for about half year with my couple years old TV, mostly to watch movies, TV serials, some sport events I recorded from TV. It was formatted with NTFS - that's needed for files larger than 4 GB, and TV played practically everything, except some very old AVI files.
And couple days ago I added something new, usual MP4 file, and turned off computer (saving on electricity), and inserted SD card in USB adapter in TV - nothing. Repeated insert - nothing. Checked with Pen drive - works. OK, let's sleep. Next day more checks, and no, it's not card or adapter dead - works with PC, everything is there. Hmm - connector on USB adapter no good ? Cleaned - nothing better. Then inserted micro SD card via USB reader - still nothing. Some checks more, and I came to conclusion that only explanation is that Win 10 wrote something somewhere, and that's why TV don't accept it. OK, let's format it. Kept all same, quick format, and yes - TV accepted it, and played that video what I just copied there.
Well, I don't think that there was some error in filesystem - that would be indicated by Windows. Most likely, again some crap is written in MBR or in system area of single partition. So, I will now save first like 20 MBs of it, to have with what to compare if problem appears again . Too much updates, made in rush, bugs ?
-
I don't think that Atari stopped production of ST machines when STE was launched - which in 1989 already were not same as in 1985-87 - it was rather STFM, with built in floppy drive. Well, I say it because I saw even in 1991 STs in German shops. Was it because they sold slowly, so remained in stocks, or Atari still made them - really don't know.
And in same time I saw C64 machines for sale, for about 200 DEM. So, some kind of retro buying existed even then. Surely motivated by plenty of SW available and attractive prices.
Falcon has no any same custom component as ST. All needed to be redesign, and integrated in less chips. And it has no ACSI port.
Actually, there is something what was probably present in all them - but I never looked about - PSG (or Yamaha) sound chip - not manufactured by Atari, was very spread, so cheap - not worth to integrate in custom chips.
-
Mega ST has no stereo audio at all.
-
Indeed, Hatari results should be taken with reserve. And I can add that so far nobody emulated Mega STE with it's cache accurately. Actually, it might never happen - because it is not something really important - there is no SW which needs exact timing of Mega STE at 16 MHz. Furthermore, that's probably hardly possible, without knowing exact way how that cache works, then be able to reset it somehow to empty begin condition, etc .
Then, no, Mega STE at 16 MHz is not 2x faster than at 8 MHz - because CPU runs at 16 MHz only when accessing cache - if no that address in cache, it must access slower main RAM, so 8 MHz effectively. So, it is averagely about 60% faster, and that depends from running SW.
One of best things by Atari ST is that it does not need to slowdown CPU (better said to insert wait states) when video accessing RAM - because RAM is fast enough to serve both. There are 4 74LSxxx chips between RAM and main bus, which do sync when both try accessing RAM at once - then data is kept in them for 250 nS.
Yeah - RAM cycle time is 250 nS, while CPU and video cycle time is 500 nS - for 16 bits - just to check my memory, and show that it gives proper scanline times let's see: one line in color modes is 64 microS = 128x500nS x2 (as it is 16 bit bus) = 512 bytes transfer time. Now, in medium res we have 640 px, 2 bits/px , so 1 line is 160 bytes - so video needs less than half of RAM bandwidth, and that's exactly same in color mode. Little more in monochrome, because smaller borders.
Of course, you can inc. CPU performance in different ways, but CPU clock must then be more than 8 MHz.
Falcon and TT are different story, despite faster RAM - higher video modes need much bigger bandwidth for video generations, so there is slowdown of CPU by them and that's why SW runs faster from so called fast RAM - but in lower screen modes it's not case - no wait states. (I guess there is something like that by Amiga too).
Yes, in case of Falcon it matters in which video mode you run tests like this.
-
1
-
-
Well, problem of how to use space above 7 GB (as TOS limit of max 14 parts. of max half GB capacity) was already present many years ago - then with larger capacity drives, not Flash cards which had max capacity under 1 GB around 2006-8. And solution was to create FAT32 or Lunux type partitions on extra space. That was usable with Mint for instance.
Or there was BigDOS - program for STs, Falcon, what supports DOS FAT16 partitions up to 2 GB size. And maybe more than 14 partitions, don't remember exactly. It is well made SW, but eats some RAM (of course) and compatibility with diverse SW might be problem.
Then, there are IDE drives, which are supported by factory Atari Falcon and ST Book. TOS 2.06, TOS 4.xx . And they were always cheaper than SCSI, IDE adapter was cheaper too, only that needs some soldering work, as it must go inside computer - except if goes on cartridge port. And there were diverse capacity limits with IDE drives, called in begin AT-Bus disks. Like max 512 MB capacity, the reason was CHS addressing of sectors, what originates from MFM drives with which early IDE was driver SW compatible. Around 1990 was time to introduce new, LBA addressing mode (what was present by SCSI at beginning). LBA used 28 bits for sector addressing, what means max 128 GB capacity - was fine for some 15 years. And around 2005 LBA 48 was introduced - I let you, reader to calculate how big hard disk capacity can be addresses with 48 bits 🙂
I mention this, because I had some 160-200 GB IDE drives, and that needed adding LBA 48 mode into driver, so can access area over 128 GB . Well , then appeared that Mint versions of that time couldn't handle very large FAT32 partitions. Damn HW manufacturers, always step ahead ! 😁
OK, back to our good old TOS, and good new Flash and cheap cards: 32 GB SD cards were mentioned, and yes, they can be now bought for about 10 bucks. We have now diverse adapters (or combination of 2 adapters in row) with which can use such cards, so not only those with evil name. But what about OS for Atari ST(E), so we can access more than 7 GB area on modern storage media ?
Yeah, that was why I went in hard work of improving TOS 1.04, 1.62 (pretty much the same, 1.06 is from same year as 1.04, and 1.62 did not change anything in disk code) - 3 years ago, knowing that it will be very hard. The result is visible here:
https://www.youtube.com/watch?v=9RCAt_2B5s8
Same thing can be achieved with IDE adapters, drives, CF cards, SCSI hard disk drives ...
And if you look better can see that driver uses only 2506 bytes - not only max sector sizes, count is better, but logical sector sizes too, what makes possible work with smaller buffers (which eat most space when hard disk driver is activated under regular TOS) .
Couple more interesting things: 29520 MB is capacity detected for 32 GB SD card - bug in driver SW ? Of course not, that's exact capacity, because real capacity is always less - that makes possible so low prices. Yes, storage (Flash EPROM chip(s) have capacity of that 32 GB when manufacturing (so 32 G x 8 cells), but plenty of it appears unreliable, not working, so they are excluded when it is tested. It is possible to make it with all cells OK, but then manufacturing would cost like 100x more . And don't forget, it will not last forever - every write is a bit destructive.
This reminds me about Simbo - he claimed that I talk stupidity, and when it says 1 GB that's whole 1 GB . Should stick to soldering iron only 😁 Btw. someone sent me some 10 years ago SD card marked as 2 GB because worked unreliable and strange, to examine.
On my surprise, capacity detection shown exact 2 GB capacity. Then, it appeared that when accessing area above 1GB it starts to write to begin of card . Yes, clear case of forged capacity - it was actually 1 GB card, sold as 2. And nicest thing is that it died by me after only few hours of usage - end of story and time wasting because thieves.
Supporting more than max 14 partitions is welcome too in case of attached multiple drives, media - because TOS limit stays for total count of partitions, on all attached medias. So, if on first there is for instance 12 of them on first, only first 2 from second can be handled by TOS, and that's not really practical when want to do some file transfers between cards, disks .
-
9 hours ago, SoulBuster said:You mention ADIPLUS, do you mean AdSCSI plus? So I should be able to put on a drive over 1gig on my AdSCSi devices? Does that also work for Link II devices?
That could be correct name, I just saw that ADIPLUS somewhere recently. I had it, but not anymore. Probably that plus in name means exactly that is capable over 1 GB - with their driver, for instance. Can't say for Link II, but I'm sure that google is smarter in it than me 🙂
-
Yeah, that works. But it's faster and easier with Total Commander (Win) - and it has built in ZIP handling. Or Winzip.
-
1
-
-
If I get it correct, you want to connect ST audio output to speakers. That will work only if those speakers have amplifier.
Then just need to 'steal' audio from monitor cable, or connector at Atari - audio is pin 1 on 13 pin Atari video connector. GND is pin 13 (that solo one down) .
-
There are other devices what can over 1 GB - Gigafile, original ICD ADIplus adapters for SCSI disks - they established so called ICD ACSI protocol, and modern devices use it too. Or Mega STE internal ACSI-SCSI adapter modded by me, and others after:
http://atari.8bitchip.info/modmste1.html
I mentioned UltraSatan simply because it is most spread. Blame Jookie for name.
-
Well, considering sizes of old and today 'in' mass storage, it is really not problem to place some modern adapter and media (in most cases SD card) in case of old hard drive case. For me biggest question is noise - how to achieve that it produce similar one as old hard disks + maybe cooling fan ? Well, if old disk still spins, PSU is operational, that's solved pretty well.
"The external limit per drive on the ACSI port is 1 gig," - that's just not correct. It is actually SW, original ACSI protocol limit. And ICD overrode it some 25 years ago, by solving sending 8 byte SCSI commands instead by ACSI protocol used 5 byte (SASI) commands.
Funny thing to read such thing when plenty of people using UltraSatan attached to ACSI port, with SD cards of 4-16 GB typically now. And that 16 GB stays for 1 drive only (1 target #) . I tested UltraSatan with 32 and 64 GB SD cards, and 30x 1 GB partitions (iTOS) ant it works fine - single target. And 30 GB fills well 32 GB SD card, as real capacity is always less.
The real limit is TOS, Basic ACSI protocol. But that was made more than 30 years ago. And it is possible to modernize both, while keeping original TOS, Desktop look 🙂
-
10 hours ago, vol said:Sorry I missed "The address range from 0 to $800 (2048) can be accessed only in the supervisor mode".
But is there a way to get a timer value from an application program?
It was unknown to me that the ST actually has an MMU which can protect some memory areas. The Amiga doesn't have any such things despite having a multitasking OS. It is an interesting discovery for me.
Sure, there is a way, supported by TOS. XBIOS function # 38 - subroutine execution in supervisor mode.
-
1
-
-
Yes, and someone said same to me in e-mail. Still, I say that it is bad name, especially for Atari people who associate STM with - we know what Atari model . Then, most of users don't care what components are involved in device, but care about with what can use it.
Then, saying to STM - component what is not final or starting one in data transfer chain is just wrong. SD card is that, with what ACSI port communicates, transfer data. Plus, people selects usually storage adapter by criteria what storage media it uses, supports.
ACSI2STM could be with CF card socket, with SCSI connector , etc. I don't like Satanistic names, but even they are better than this.
-
16 hours ago, Randy said:Thanks. First, I get a folder called "Walls", that opens to the files "WALLS (text doc), WALLSI.PRG, WP0.DAT, WP1.DAT, XSOUND.PRG" and finally a folder called "ART" with a bunch of files in it. I copy the wallsi.prg, wp0.dat, wp1.dat and xsound to the root of drive D and the folder ART to the root as well as the text doc. Hope this helps!
Jesus Christos ... When is told to unpack DIR WALLS to root of some partition you do that, and nothing more. It was done so, that people can place it with couple mouse clicks. Nobody said that files inside that DIR need to go in root . How it would look if every SW should place lot of files in root ? Total mess.
So, again, last time: unpack DIR WALLS to root of some partition. That does not mean to move it's content from it - what idiot would put them in folder WALLS, when they should be placed out of it ? Unpack stays for extracting it from ZIP (RAR, or whatever archiver, packer).
I composed that ZIP in way so it will be easiest for people to place content in proper structure on disk - open ZIP with your file manager, archiver. Select DIR WALLS and use copy to dest. - then it will be unpacked there with it's complete content, structure intact. That's default setting by usual SW used for this.
-
1
-
-
People use to call 'bug' almost every problematic situation when is talk about computers, SW for them, but I must say that those who design HW, write SW simply can not to think (ahead) on every possible scenario, way of usage and like. What does not mean that should not care about it, yes should as much as possible, and one thing is sure: long term experience helps a lot in it.
So, is it bug when some game from 1986 works not well with TOS 1.04 ? Not really. They just could not know that Atari will change some variable addresses - like joystick read.
But it is for sure bug what I saw in game Grand Monster Slam (and similar one in another game ... hmm.. can not recall title at moment) - so it fails on STE machines with corrupted screen. And the reason is real bug in code - overshot in part what writes colors in palette - it goes over couple bytes, where is nothing by ST machines, but by STE there is HW register for scroll, and it gets some bad value, what corrupts screen. Seemingly another case of not seeing future, but no, it is just plain error to write above specific area. Very similar error causes crash with 4 MB RAM - and again, plain bug, what activated not during tests just because they did not have 4 MB RAM in their test Ataris (like in 1988) .
In other words - accuracy is essential, and being not accurate is like timed bomb - OK, big words, but dramatic effect matters 🙂
Case of Atari STE: should be released earlier - like min 1 year, and it had actually 3 bugs (at least that's what I know) when first versions were released.
Well known bad DMA chip problem. Medium resolution desktop.inf bug. And less known one, what I discovered some 12 years ago: Microwire mixer bug - DMA sound volume much lower than PSG sound volume, and impossible to set properly, despite should be possible to change ratio by DOCs...
All 3 cases say to me that testing failed, especially in first 2 cases. As there was no SW what used DMA and PSG sound at once mixer bug just did not show - although, they could make some test SW for that ... DMA and med. res. bug were fixed - with new DMA chip version and new TOS version. Mixer bug went into TT and Mega STE. And if you ask: it was just wrong resistor value calculation. Falcon is first where DMA and PSG volume ratio is correct.
But we may ask how many customers were lost because ... ?
And I did not mention some bad solutions in TOS, which were never corrected - bad year 2K code for IKBD and crash in text mode when should display very large file sizes (10 MB or more) - well, it was just not time of that year, not time of so large files .
Such and similar details can make difference between good SW and great SW.
-
2
-
-
Well, I think that I need to add here some comments, which some may consider angry, but all I want is to be accurate. I mean, not only myself, but others too 🙂
So, first problem - the name. Why ACSI2STM - that does not make sense. Every STM has ACSI port, so it is actually something like ACSI2ACSI . It has SD card socket, uses SD cards, so that should be in name. Suggestion: something like ASTtoSD (since ACSI2SD is used already) .
Quote from it's Github page:
" Maximum partition sizes are the following:
- 32MB for TOS 1.04 (ST and STF series)
- 64MB for modern Linux kernels
- 512MB for TOS 1.62 and 2.06 (STE series)
Other TOS versions were not tested.
With different drivers, you may have different limits. This bridge supports 32 bits access for disks bigger than 8GB."
No way. TOS 1.04 and 1.62 are totally same considering FAT16 filesystem code - I know it for sure, because I disassembled both, and yes, it is same. And both were released in 1989. So, if some SW gives limit of 32 MB for partition - and what the hell, not only first one for TOS 1.04 it is serious mistake, flaw. At least what says for 1.62 and 2.06 is correct.
"32 bits access for disks bigger than 8 GB" - huh . Actually, 32 bit access (SCSI 8 byte commands) is needed for disks bigger than 1 GB.
Basic ACSI uses 5 byte SCSI commands, where sector address is sent in 3 bytes instead 4, and from those 24 bits 3 are ACSI target #, so it is effectively 21 bit addressing > 2 POW 21 = 2 Mega sectors = 1 GB . 32 bits can go up to 2048x more = 2 TB .
Is that 8 GB result of using 8 ACSI targets of 1GB each, when not 32 bit access (should say addressing) is used ? Why it is used at all, when it supports 32 bit addressing ? I guess because some ancient drivers.
I need to mail author (will not write on Github) - anyone know his e-mail address (PM me) .
I had some longer mailing in last week with couple people using this and other, similar adapter called ACSI2SD . There is pretty much confusion about what and how ... Still not finished with it.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Benchmarking...
in Atari ST/TT/Falcon Computers
Posted
Maybe that - in name is problem ?