ParanoidLittleMan

How long you work in vintage electronic ? 2 weeks, 3 weeks ? Seriously, you want to be smarter in this than someone who works with electronic for over 40 years. 'Almost never tubes' - yeah, that's why tube based computers prevailed on market 🙂 I must be reading very false info saying that tube computers needed repair (tube replacements) every couple hours. And sure, that matches my personal experience - with tube TVs ++ (still in use when I started with repairs) - big part of TV, amplifier and radio failures was broken, weakened tube. It is not heat what kills components - well, at least not directly. Moisture in air is what makes silicon based chips to break. That's the reason why industry, military grade chips must be in ceramic case instead plastic.

"RGBtoHDMI is now possible on the Atari ST" - interesting formulation. Like it is possible only because someone find a way, and not because it is physically possible. Yeah, I always hated posts/messages starting with: "is to possible to ...." - where 'is it possible' actually means: will you spend more-less time to solve some problem for free. It is not about is it possible. Playing with words. Maybe just say it polite: you can now do it without figuring, developing self the solution.

Angle - that's parameter what manufacturer of drive label gives. So, please bother him instead Aage forum people.

Looked TV specs (Philips 24pft4022/12) - it says only 50/60 Hz vertical . And yes, it can not Atari monochrome (71 Hz). No details is it staying for all inputs. And one of seller WEBpages says - only 60 Hz mentioned (in PAL/Secam land) , type: "LED television" , picture generation technology: "LED" . Now, that latest is pure lie (even if very maybe not intentional) . It is LCD. Real LED TVs, monitors are still much more expensive. Welcome to 21-first of 21-firsts 🙂 Wait, when this century actually started ? I mean not in some people heads, but really .

I think that here are some serious misunderstandings, maybe 'helped' with intentional confusion made by sellers (yes, myself heard plenty of false claims by many of them, just to sell something what is not really needed for potential buyer's case). First inaccuracy in this thread: "One of the reasons to put it on the back burners was it’s inability to output to a modern LCD tv. " . It looks that I have some very special Atari STs, STE, because they are 'able to output' to modern LCD TV . And with very good quality - because using RGB lines, not composite. And passive cable - no any conversion. Then, this forum is full with threads about LCD monitors capable of displaying Atari ST color mode - via VGA input and proper cable - where only problematic part is 13 pin Atari video connector. Everyone with little skill can make proper cable in half hour. Multisync monitors generally. "sync down to 15khz" - nobody uses 'sync down' term. Video can be converted to different scan frequency, and that's the part what costs more, and where quality may be not so good. And actually, Atari color modes need that scan freq. be converted to higher, 'upper' - so how word 'down' came here at all ? Prices of quality converters, which produce regular VGA freq. video from PAL or NTSC scan freq. RGB (or just composite) are higher, in range of new smaller size TV - like 100 or little more bucks. Or today PAL/NTSC RGB or composite to HDMI ... What is important is that horizontal scan freq is what needs to be much higher - like 30 KHz instead about 15 Khz. And btw. Atari ST monochrome has about 31 KHz hor. freq - that's why it works with most of VGA monitors. This cheap (20 bucks) VGA to HDMI converters - why they are needed at all if they don't convert scan freq. ? Are now monitors, TVs without VGA input on market ? I did not follow it, but would be no surprise to dismiss it in last few years by many of them . "Not all of the VGA to HDMI adapters will sync to 15khz. I was lucky and someone had posted in the questions area that they had tried it with an Atari and it worked." - no need for "sync to 15KHz" (never use lower case k for Kilo) . Atari color mode is already 15 KHz. Maybe some seller told it, just to present it as something very powerful 🙂 As I see, VGA to HDMI, at least cheaper ones just convert analog VGA signal to HDMI . Keeping scan frequencies. That's OK if no VGA connector on TV, Monitor. But talking about 1080p and other blah is just to fool some naive people that will get some very sharp pic from not so sharp source. The real question here is, I think - how certain converter works with Atari's not interlaced video - that can cause shaking on some TVs - even on some older CRT ones. To get proper grayscale may need to add serial resistors in RGB lines. I need to check what scan freqs my TV supports on it's VGA and HDMI inputs. TV has Scart input, so I never thought about using other input for Atari. Funny thing would be if VGA work too (like by those NEC, Dell monitors capable of 15 KHz) .

I meant this thread https://atariage.com/forums/topic/318393-was-the-power-pack-a-bad-idea/ It deals with those 'packs' - what is in some way publishing of games, isn't ? Then, publishing doesn't mean developing a game. Even those published with name Atari on them were mostly developed by some 'hired' companies - like Andromeda in Eastern Eu. Earlier Atari hits like Battle Zone, Moon Patrol, Crystal Castles. And I don't care is it Atari, Atari UK or whatever. Atari was multinational company. I just looked at atarimania, adv. search, publisher Atari (USA) - 13 games. Isn't Atari (USA) part of Atari company ? Btw. by your logic Atari made in Taiwan is not real Atari 🙂

You should use search - there was thread about this couple months ago, here in this forum.

OK, this AL v. posted here works. So, according to what is told here, STX dump at AM is faulty (now I will be some very bad persona saying something bad about STX ) . I don't think that this v. is much worse than previous ones. Intro looks pretty good. Yes, faces in game self are pretty much red - maybe just too much drink in those times, space 😃 Slowness is biggest problem, and that happens when it is large and coded in C . " Would love to see some of the dedicated coders/teams that are re--doing so many games these days (Lotus, for example) and give this game the justice it deserves." I don't think that it will happen ever. And mentioned 'coded in C' self is probably enough to stop people from that idea. It is long, extremely hard to follow. And basically, to make it significantly faster should rewrite complete thing. Example of Lotus is not good here - coded in ASM, and what is changed is code for screen draw - using blitter. By some arcade game, with fast movement, where abbr. 'fps' - frames per second is important value it can really make it better playable, smoother ... Games like this have much less CPU time spent for screen draw, so making draw faster will not make it run much faster. Examples of what is improved: Giana - ASM, scroll done with STE HW scroll or blitter . Pacmania - STE HW scroll, ASM Uridium - ASM, blitter, some control improvement Prince of Persia - STE DMA audio - what makes it smoother (less slowdown by sample playback) - coded in ASM, and even disassembled complete code. Dungeon Master - this was coded mostly in C, but was not too hard finding audio sample playback code and mod. it to STE DMA . Plus same mod was 100% good for Chaos Strikes Back

I don't think that I talked about speed of code self. I talked about what has influence on running speed of code being executed. That's not exactly the same thing.

Questions would be by that gypsy women with flasks ?

I DL-ed STX images at atarimania. It has install to HD option, and I did it on Steem. But when gameplay should start it crashes. There is no sign of any floppy access, so does not look that it checks floppy for copy protection when running from HD. Question: anyone had success with those STX images ? It is http://www.atarimania.com/game-atari-st-ultima-vi-the-false-prophet_10736.html French, German, English lang. version.

Yes, org. CPU in Mega STE tends to get hot. But at 8 MHz it produces not more heat than DIL version of CPU - only because smaller size it is getting warmer. Mine worked a lot, over hours at 16 MHz, so I don't see reason to worry. CPU is designed to work well at higher temperatures. Surely CMOS version is colder, but I don't see reason to spend money just because it 'almost' burned your finger 😃

I don't think that some 20 years from now there will be more than couple thousands, or maybe couple hundreds of still working Atari STs and compatible - World wide. Here mean those with original components (well except PSU, floppy drive - they are already replaced by big %) . There will be no more available (from not working machines) working custom chips, and even those 74LSxxx can be problem at that age. RAM too. Will suitable EPROMs still will be available ? Surely, some may producing replacement chips - as it already happens. Clones will be used by most, that's what can say with confidence. Or do you see on streets 70-100 years old cars regularly ? In electronic life time is shorter than it. Ataris are like wine 😁 If it is old, still works or drinkable - high price.😁

So, what everything has influence on how fast some SW executes on computers - or running time of specific code ? 1. CPU type 2. CPU clock 3. How much % of time it spends in waiting - usually it is wait to RAM access, HW register access 4. How much of task is given to special chips - which can do it faster than CPU. It would be DMA, blitter in case of ST(E) . First 2 are easy case. 3-rd is actually complicated, especially since there is cache in all it . 4-th is not hard to get, so I start with it. I said in 'Benchmarking' thread started by vol, who works on arithmetical benchmarking SW for Atari ST range, that blitter on or off will have influence on test result, just because printing lot of numbers on screen. So, here is how it is with Mega STE at 8 MHz : Tests are with 1000 digits. Low res: blitter on: 16.06 , blitter off 16.15 . Little scrolling near end Med res: blitter on 15.87, blitter off 15.90 . Here to add that was no scrolling at all. That's why diff is much less here. (+ less bit planes, of course) No sense to do it at 16 MHz, because blitter works then at 8 MHz too. (And why - because it works with slow RAM, not cache). So, some may say very small diff, maybe in range of test inaccuracy. Nope. Repeat them on your STE, Mega ST, ST with blitter ... Differences are small simply because relative time for screen output compared to calculation time is very small. And it is worse if set larger digit count - then rarer (in time) prints on screen. And why is med res faster ? Because less RAM access - 2 bit planes instead 4 . So, I still say that print on screen during test is not good idea. Especially because, as may see results differ depending on used screen res. And yes, difference will be much bigger in case of TT and Falcon - just try in their higher screen modes - partially because screen operations involving more RAM, partially because more slowdown of CPU caused by limited RAM bandwith. Case of Stacy with 40 MHz 68030: as I see, DarkLord thinks that program gives false results, since his CPU runs faster than TT CPU (same one, just at 32 MHz). Well, I'm pretty sure that results are OK, and actually TT is still much faster. Why ? Faster RAM, 32-bit bus instead 16 . Because that PAK68/3 uses only ST RAM and not fast (if there is such at all with it ?) it has plenty of waitings. Something like very simple ST acceleration by using 16 MHz 68000 at 16 MHz whenever possible - and that's not possible during RAM access, so then must switch to 8 MHz. Effective speed up is max some 30 % . 68030 has some cache, so it can be more, depending on running SW. And now we are at cache: why it is practically (and unusually) approx 2x faster on Mega STE with 16 MHz CPU clock ? Because vol's program is short, and all it fits in 16 KB cache of Mega STE. To add here that 68030 internal cache is only 512 bytes. That's why some complex game like Microprose F1 is nothing faster on Falcon than on Mega STE at 16 MHz . Despite CPU executes many operations in less cycles (shifts especially) - that's compensated with larger cache of MSTE. I can't blame vol for some things, caused by being not much familiar with Atari ST family, TOS . But there are people, active with Atari STs over decade, who did not get how to do benchmark properly. Like exxos, who claimed that Mega STE is faster at 16 MHz only some 10-20 % . Should apologize for that shallowness (I apologize if it already happened). What was mistake ? Did test with GEMBENCH, and with blitter on - and as is said blitter stays at 8 MHz. GEMBENCH tests are rather for graphic operations, not bare CPU speed. So, I think that vol's program pi-st is already good and fairly accurate. What to improve: off topic: use 8.3 filenames, pls. Randy will have heart attack if copies it on his disks with this lower case names 😃 Maybe it's harder thing, but programming it so that it uses much more RAM, and cycling thru it will give better info about cache influence. If test uses like 100 KB RAM, and not only once uses almost all of it, but goes thru it over and over again, in cycle, then cache will have lot of misses, so more slower RAM access must happen. Of course, ideal case is when even instructions are located on different RAM area - because opcode fetch time affects speed too. Actually, should be not so damn hard. Copy core part, what is surely not more than 512 bytes to let's say 512 copies over 256 KB RAM, then calling all them in cycle, in row. Well, during copying code should do address corrections too - for workspace, so that changes too. PC relative is not good because can go max 32 KB farther.

I was about to add here text about what everything has influence on benchmark results, and not only that - overall speed of running SW. But, it will be long, so better start new thread - will appear soon in programming section.

Yeah, recommended to take out HD and save what is on it, ASAP .

It's not RF modulator what is really different, but Secam color encoder. While NTSC and PAL are similar - that's why 1377 supports both. SCART as protectionist measure ? What the H. ? Purpose of SCART is better picture and sound quality. And is actually universal. Has place for practically all possible signals existing in analog TV/video era. Then, it was not mandatory to have Scart on TV-s sold in Eu. Video input was mandatory. Btw. I saw interesting thing in one C64 what came to my service from France originally - it had RGB out. And internal by TV used PAL decoder circuit for getting RGB from composite. That was only way in C64, because no RGB signals accessible - video chip generates only composite output. And yes, no sense to add RF modulator and PAL or NTSC encoder in Secam country. Although, later, in nineties multi standard TVs were more spread, so for sure many sold in France supported PAL. Even better if RGB too .

Typical problem with old electronic not turned on over years are weakened electrolyte capacitors. They go little better after some work, but will be never really good, so - replacement strongly advised. Stacy - so SCSI drive. You can attach it on PCI SCSI card - if have such beauty 😁 Actually, there are some PC motherboards with SCSI controller, that would be very rare beauty 😃 Otherwise, hmm ... And of course will need SW what can deal with TOS type partitioned disk (I guess it is such) - like mine Drive Image.

Yep, if it should create different file names for output, then use extension TTP (TOS takes parameters) - what will open text input before start - so like command line. Input appears in base page of running APP .

I checked in Atari ST ProfiBuch. Bconout has no option for output to file. Available: Parallel port. Serial port. Console. MIDI, IKBD chip. And actually, for me would be surprise if it would redirect to file, because that's different story than sending single byte . And Atari ST people just don't use console, what is not part of TOS too. There are such programs, and not popular. And since you want to output whole text to file, I think that best solution is to simply use file write function of memory segment. So, usual Open File - trap #1 $3D, Write file - trap #1 $40, Close file. By write you need to give memory address of start and length. Just 3 calls instead 1, still peace of cake. And if it is of use can add at start selection - to screen or to file ? Output to file has benefit of avoiding screen operations during CPU performance test. Here mean those calculation related tons of zyphers. I would make it so: output to both - of used setting(s), final result.

I think that real (well, most important one) reason for prices getting higher is that 30++ years old computers, electronic just tend to work bad, unreliable, stops working completely and like. And repair is more and more hard, combined with hard to find components. As may see, it's not only rarer computers which price seem way too high. Like little upper shown "NEW" original mouse . Well, if it was "unused" that would even sound as "maybe true" - but 'new' for something old about 33 years 😁 . I can guarantee that it will be pain to use it - ball surface is for sure like glass. Similar is with Atari compatible floppy drives. More than UltraSatan or some HW floppy emulator. I can say: buy only for demonstration purposes. Surely will not last ..

First I need to say that VFAT is very misleading name. Long file names have nothing with FAT. And I don't believe that MS needed to steal it from anyone. The whole thing is pretty simple, and some better programmer can solve whole thing in max 1 week. Actually, hardest part is keeping compatibility, and that's not done too good. It should be compatible with older SW. Maybe is compatible with MS DOS, because it already did not handle that mentioned 'impossible' attribute combination . But most likely it is not only TOS where it causes problems. Although, that's good for MS - more reasons that people buy their SW instead other. Btw. MS recently started to use extended FAT32 in Win 10, and some Flash cards what I bought recently were formatted with it - while is not supported by others. And what is extended FAT32 - only thing is that it allows files longer than 4 GB . Again, something very simple . And all that DRI, CP/M talk - look recent threads about TOS history here, it's clear that CP/M was not up to some serious home/business computer designed for hard disk usage. That's why Atari needed several months to put together FAT16 support, with subdirectories etc. DRI should work on better 68000 compiler, and maybe then even Atari sales would be better. What's the point to make FAT16 with Intel byte order, and then being not compatible with DOS FAT16 partititions ? And DOS FAT16 means not MS DOS - there was DRI DOS for PC too - remember ? It's always easier to blame some other for failure. I don't think that Bill and MS are saints but lot of accusements are plain stupid. Actually, I will say again: PC prevailed because HW and SW manufacturers were forced to keep to standards. Atari was not, unfortunately - otherwise we wouldn't need now TOS/DOS compatible partitioner and driver SW . And some related things: World is not going in right direction - example of HDMI connectors - now every manufacturer using it must pay some larger amount to HDMI consortium of whatever it is called. I'm sorry ? For connector ? Yes, it is well designed, robust, but still, it is not Wankel motor. Or in last about 10 years all DOCs for Compact Flash cards are not DL-able for free, as before, because CF Consortium wants money. What's next ? Total stoopid, because surely HDMI connector manufacturers are those who should pay to inventors, and that is the case, I'm sure. No, that's not enough for some. Like previous year it was not enough for banks to raise diverse fees, they added extra fee for paying with debit card - while everyone talked that should rather pay that way instead not sanitary cache. Or it was right because that ? Mad world. And greed is not new thing, of course. In 19-th Century someone patented crankshaft. That forced inventors to use some complicated ways, just to avoid paying to ... Eventually, patent offices added rule that very simple things can not be patented. Well, it looks that about 200 years later some don't like it, and who cares about what was in those fossil years. Time for new signo ..

It is known Win behavior (to say so) that mounts only first partition on removable. First time corrected about 1 year ago in Win10 current update/release. There are diverse driver fixes to override that problem, and I used them in last 10 years. Like: http://atari.8bitchip.info/profb/cfadisk_x86_x64.zip Now, I have second PC with Win XP, mostly because video capturing and old Pinnacle TV card what has no driver for later Win versions. So, I will just check does it write some index crap on attached media. Probably it started with Win 7 or 8 . Surely, it's not retro computer users about who MS cares most. Although, I really can't get that only first partition restriction. Was it because some safety, or just lazy solution. They got probably during years over million complains, so finally gave task to some talented new programmer (which are those who get hard work in 'normal' company) - so it is done, maybe not 100% yet .

I will check Robocop. But still don't know about game what needs exact 2 MB RAM for good work. To add that I fixed number of games with this memory problem - it's usually overshot in screen draw, so runs out from screen address space, even RAM address space, and if accessing area right above 4 MB it causes bus error - ergo bombs, crash.

Possible to make such prg. I will do it if you tell me what is that what requires 2 MB min - when run from floppy, and crashes or works bad with 4 MB .