Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ParanoidLittleMan

Members
 View Profile  See their activity

  • Content Count

    2,635

  • Joined

  • Last visited

Posts posted by ParanoidLittleMan

  1. Posted

    What I did  for TT with Hard'n Heavy is not actually blitter emulation, but doing required background and object draw using only CPU. There is lot of shift OP involved, and that's slow with 68000, as we know, especially if shift is more bits (steps) - in that 68030 is much faster. And blitter too, + it can do multiple OPs at once in some cases. This was experiment by me too, to see how faster it can be with 68030. Pretty good, and it is enough fast even with slower Falcon.  Possible that in case of Lotus, if there is not so much shift it will be not that good ?

    Not sure that I'm so good with blitter coding as some others. At least there is mentioning of some tricky, dirty blitter coding way, what is faster than regular. I used regular blitter coding based on what is in ProfiBuch, some online articles. I can publish sources in near future - will need some time to make them better followable.

  2. Posted

    9 hours ago, chicane said:

    Thanks!

    Now that I think about it, our Lotus STE code writes to the Microwire registers, so the game wouldn't work on the Falcon even with the stackframe fixes I believe you applied to your original Lotus 1 hard disk adaptation.

    We'll add some code in for the next version that detects the Falcon and avoids writing to the Microwire if it is a Falcon - then we can pass it back to you for fixing of the stackframe :)

    The game will never be TT compatible due to our heavy reliance on the Blitter.

    I did not say that org. Lotus needed stackframe fix - really can not remember this for all games, but it is easy to check in my S files.

    Yeah, microwire code needs to be disabled in case of  Falcon, and TT has no blitter - that's chance to do all it with CPU, what is much faster 😄

    Of course after deserved very long rest (what might be up to many years 😅 ) .

    Myself actually did it with http://atari.8bitchip.info/TestMe/HNH/HnH.html

    All this reminded me on one James Bond movie title 😄

     

  3. Posted

    Virtual Floppy is something I working on for some 3 years, or more if counting Floppy Image Runner, what is it too. The reason is more and more troubles with floppy drives and disks - because of age mostly. And this release is ideal for VF - regular floppy format, file access via TOS.

    Hard disk adaptation has some general Falcon and TT support, but sometimes it needs changes in code. Most common problem is stackframe - if game code is for usual 6 byte stackframe only, it will fail, because on 68030 it is 8 bytes (traps, interrupts ...) . There might be other things. Anyway, for start it will be 68000 compatible, and will see how works with Falcon, TT - if not that will need more time .

  4. Posted

    9 hours ago, TGB1718 said:

    Does this help ?

     

    https://www.exxoshost.co.uk/atari/last/tos/index.htm#TOS6CHIP

    Should inform him that there is no L3 ROM chip , pardon, maybe on cartridge 🙂 Hmm, same error on both photos .

    And this is strange, because on my C070243 REV I. Hi-2 is at cart port, while on those what exxos photographed is opposite ???

    Google in hands ...

    https://temlib.org/AtariForumWiki/images/e/e9/ST_Motherboard_C070243_Rev_C_Factor6.jpg

    No printings.

    One thing is sure: those with 0 go lowest in their section of 3 (L or H), so there are only 2 possible ways:  as in my previous post (middle is Lo-1, my mistype), or: Lo-2, Lo-1, Lo-0, Hi-2, Hi-1, Hi-0 . There will be no damage if chips are in wrong socket - machine just will not work, then just change Lo and Hi order.

     

  5. Posted · Edited by ParanoidLittleMan
    mistype

    9 hours ago, Davero said:

    Could you tell me how to put chips ? i have 6,  hi 0 1 2 and low 0 1 2. where to put low and hi ?

    Nothing printed at left side of sockets ?

    On my REV I. (1987), with  same layout there are, from top (closest to cartridge socket) to down it is: Hi-2, Hi-1, Hi-0, Lo-2, Lo-1, Lo-0.

    Most important is to put chips properly in sockets, reversing them by 180 degrees is certain death.

  6. Posted

    Hard disk adapt. with HAGA system is under work - actually it works already, but need more time for Desktop exit implementation because used packing. Not sure that some cheat is welcome in this ?

    And those who have my driver with Virtual Floppy feature may already to play this from Flash card/hard drive. Need to activate both High RAM  and A: as active when driver counts down after reset. It is because AUTO run and game's RAM usage. Min RAM for is 2 MB.

    And it can work with even 1 MB and from mass storage - with my iTOS Virtual Floppy - then no RAM 'spent' for driver, since it is in TOS ROM .

    • Like 1
    • Thanks 1

  8. Posted

    I have Mega STE, what is not listed here, and therefore yesterday he gave me hard time 😄

     

    Seriously: categorizations should be different. From SW side all STs have only 2 relevant differences: RAM size (and that's not always what is written on case) and blitter presence. Is it Mega ST or just ST(F,M) is not relevant for running SW.

    Some may say that then no diff between STE and Mega STE, but that's different - Mega STE can 16 MHz and has some extra HW in compare to STE, and it has TOS 2.06 by default, what is known as not so game friendly.

    So, I think that, considering purpose of this poll - writing a game for ST family, it would be better like:

    1. ST with 512 KB

    2. ST with 512 KB and blitter

    3. ST with 1 MB or more

    4. ST with 1 MB or more, and blitter

    5. STE with 512 KB
    6. STE with 1 MB or more

    7. Mega STE - I guess it was with min 1 MB RAM

    8. TT

    9. Falcon

    10. I use emulator

    Multiple selections allowed

     

    Yeah, lot of people like old games, but prefers running them on emulators, from different reasons. Like someone's ST(E) just broke, and fixing, getting another takes time and money.

    Now, why blitter is interesting ? Because it can make screen operations (in first place) much faster. Look new Lotus version. Myself made some blitter using game improvements (Giana, Uridium ..), so know what talking about. STE gives beside blitter more color nuances, HW scroll (little limited in some things) and probably best one: DMA audio. So, it's all depend from game (project) self - is it worth to force STE if it's extra features will not make game significantly better ?

    And something more: compatibility:  game can be coded to work well on complete listed range of machines.

     

    • Like 3

  9. Posted

    Bombs are more for programmers, users - indicate that CPU reached specific bad code, or attempt to access invalid memory loc. (that would be bus error for instance).  If they appear randomly, even if no program is started that's just  unreliable work.

    Well, best what can do in this case is to replace components - and may start with those quad socketed chips - Glue, MMU ... Yes, I know, don't have replacement chips, but ... That's practically only way - in theory could deduct some things with logic analyzer but that's very slow and complicated - in time spent with it could earn money to buy couple working Ataris.

    My worse repair was, and it was when machines were under 10 years age - when 1 74LSXXX chip worked unreliable - they cause problems very rare, and I replaced before going to it almost all larger chips, RAM ...  Just an extreme example.

    And  since it is not really stable even without floppy, it can be RAM. No diagnostic cartridge - get 16 RAM chips - you anyway plan to expand it. That will be plenty of soldering, but must not to replace all them at once.

  10. Posted

    22 hours ago, chicane said:

    I'm afraid the version 1.0 of this game is an old fashioned "bare metal" game like the boxed games you'd have bought in the 80's and early 90's - it's intended to be played on an autobooting floppy with no hardware present. Any additional hardware or drivers in memory are likely to cause you pain.

     

    We could look at fixing this for future releases but it wasn't a priority for us in the initial release.

    Well done Mr. Chicane ! Fresh blood to old game 🙂

    Considering playing from mass storage - I have solution for it, so can make hard disk adaptation in usual way - if you agree. That will make it to run as from AUTO folder of floppy. Min RAM will be 2 MB, as is usual for 1 MB games.

    Question: how STE detection is done ? HW test (like ADMA presence), cookies, TOS header ?

     

     

  11. Posted

    Desk ACCessory - it must be in root of boot disk, so in case of mass storage root of  C :   Extension is ACC, of course.  Will load after reset or when changing screen resolution . There is lot of them . If remember correct max 6 can be active at once. And better keep that number lower, because they eat RAM, so will be less free for regular programs.

  13. Posted

    21 hours ago, Moe said:

    I tried re-seated the socketed chips, but I'm getting similar results.

     

    When I was re-seating the chips I took a few pictures of the board.  It looks like my 520STfm has a 1040ST board with only 512k dram installed. I guess Atari just used whatever parts they had available at the time ...

     

    If we thought it might be a dram issue I'd remove the existing 16 dram chips, socket the board and install some new 41256.  If I did this could I just add 16 more dram chips into the existing spots and get a full 1MB of ram?

     

    I do find it odd that when I do boot into TOS that the mouse is really slow and sluggish. The same mouse on my 520 ST moves fast and smooth ...

     

     

     

    Any ideas?

    RAM expansion is easy when there is space for chips, so yes adding 16 chips, and 3 resistors - just look some schematic of 1040 and will see which go to second bank.

    That mouse issue indicates problem with some line, most likely. Should check and by need resolder 9-pin connector for it - soldering often cracks because lot of attaching, detaching. How about keyboard click ? It should happen after shorter key holding down, and then repeat frequently.

    If that's not case need to check IKBD chip, keyboard connector to mainboard ...

    If Desktop appears after some delay (caused by not working floppy/circuit/cable) is it stable, no crash (bombs), reset by self ?

    If it is stable, RAM is most likely OK, so better check other things for start. And if possible should check power voltages with oscilloscope.

  14. Posted

    1.04 can not work as ROM TOS in STE but can work from RAM. Btw. 1.04 and 1.62 are very similar. After all HW is initialized (so extra STE HW too) it can work with 1.04.  Plenty of my game HD adaptations use TOS 1.04 GEMDOS part, and lately complete 1.04 with AES too works with STE, Mega STE and even TT, Falcon (then need some corrections like stackframe), in high RAM.

    Indeed TOS 2.06 is worst for menu disks (OK, there is worse - EmuTOS, but let's stay at regular Atari TOS versions) . Switch and 1.62 opt. is best simple solution for STE.

    While TOS 1.04 is usually recommended for ST - and it is surely best TOS for, it will not solve running of all games, not even on ST. Actually 1.02 could be better, especially if playing older games from period 1985-1989 . Because game coders could not see the future, and worse, could not see some relevant DOCs (mosty Atari's fault), so for instance joystick will not work in 1.04 . But there are games which work only with 1.00 (Tracker) .

    I did lot of game fixes to make them run on later TOS versions.   http://atari.8bitchip.info/ASTGA/T/tracker.php

    But there are games which need other fixes too - like those not running with 1 MB RAM (only with half) or 4 MB RAM - yes, this sounds stupid, but is true. There are fixes for such errors too. But not on menu disks, which are made in less RAM times than now.

    In any case, Floppy Image Runner is not recommended for menu disks, especially if have HxC - more of it will work via it (direct FDC code using games will not work with Image Runner or Virtual Floppy).

    TOS 1.04 in high RAM can make it little better.  http://atari.8bitchip.info/tosload.htm

    That should work with STE too.

    And there are few games which fail on STE regardless from TOS version, runs it from ROM or RAM -because bug in code, what screws video only on STE-s, on STs it does not harm (overshot in color palette write cycle), so only fixing them helps.

    Example: http://atari.8bitchip.info/ASTGA/G/grandms.php

     

     

  15. Posted

    12 hours ago, Calab said:

    The wireless dongle uses less power than a corded mouse. You can try to use a corded mouse, but if it draws too much power it won't work.

    I don't think that any mouse will draw too much power (at least not working mouse) . I read somewhere that solution where taking +5V power from joystick port is not good for Flash card adapters - not enough power there.  Well, there is no power limit on those connectors.  Most likely problem is soldering of port connector self - because of plenty connecting and disconnectings soldering cracks, and that can result in big resistance. I needed to resolder those 9 pin connectors in my Ataris . No problems even with high speed CF cards getting power via .

  16. Posted

    12 hours ago, Calab said:

    I would still need a converter for a serial mouse, wouldn't I? I could find one if it would be a simpler process to get it working on my Mega.

    No converter, but driver SW is needed for - can attach it to ST serial port. But, as said it will not work with some SW (mostly games) . And those mouses are very old, so I would not go that way ..

  17. Posted

    I don't think that using original mouse will be easier. Need to design converter of it's signals to PS2 or rather to USB.  Maybe if find specific mouse where X-Y signals are present and go to converter chip.  Still, it will be very old Atari mouse, with hardened ball for instance, not promising long life.

    I think that putting modern mouse sensor, electronic in Atari mouse case will be simpler (not very simple) and will last.

  19. Posted

    NetUSB has another flaw: SW (mostly games) which has own mouse reading code will not see mouse attached via it. Because it is coded for mouse via IKBD chip of ST.

    I suggest that search little online. There are converters for about 20 $ (PS2 or USB) . Buying original Atari mouse for even 10-20 bucks (+shipping) may result in problems appearing soon - it's 30++ years old now.

  20. Posted

    We can blame SW authors that they did not think enough ahead, and wrote code what was limited only up to end of 1999.

    But why they should do it better, when OS - TOS was nothing better.

    Here is example:

    TOSno2Kc.thumb.png.dd39c73f5c85e9c4b3332f06614dc015.png

    This screenshot was made with Steem 3.2 and H: as so called GEMDOS emulated logical drive - what means that filesystem functions are emulated by emulator, and some DIR on host OS (Windows here) is assigned as logical drive H: here. And of course it handles well years at 2000 - host OS and emulator.  I just created 2 directories NEWFOLD  - in A: , and in shown subdir on  H:  . Date stamp is OK in H: . Not OK on A: , since it was created  fully via TOS. And may guess which TOS version is it by date shown - yes, it is 1.04 , and when TOS reads for him invalid date from RTC (Ricoh) and KBD chip will just set TOS creation date as current time. Invalid is above year 1999, under 1980 . So, only 20 years span. Even they did not expect that some people will use it in 21st C. Probably thought that will use  some 64-bit super Atari with GB of RAM, CD recorder, 800 MHz CPU and even 4 ciphers assigned for current year !

  21. Posted

    I tried UltraSatan with my Mega STE and TOS 2.06 and 1.62 (fixed for MSTE) - really never used it for clock setting before. And it works fine, without control panel. Once set time it was correct in file stamps, which I created.  I turned it for  couple minutes (while changed TOS ROMs) and it kept time - despite no battery for Ricoh chip. And I did not run US_GETCL.PRG . Maybe some capacitor kept power for that short time for Ricoh chip.

    Next test should be with machine without Ricoh chip, since then time goes to IKBD chip, and there is not smart code for that in TOS (as explained) . But I have only  Mega ST alive now.

     

    Anyway, diverse SW is main problem here, and that's old problem, now over 2 decades.

  23. Posted

    Yeah, this is T-Board. But what I said, that in case of STE no need for board stays. No need for GAL - address space for ROM TOS in STE is same as in Mega STE.

    If want  TOS switch simplest and cheapest is to use larger capacity EPROMs - like 27C020 for 2 TOS versions, 27C040 for 4 TOS versions. Not theory - I did it all.

    Just sad example of overcomplicating and take more space than needed in computer.

    Instead manual get above mentioned EPROMs and switch .

  25. Posted

    Hardly TOS 2.06 upgrade board in case of STE . By STE need only to replace ROM chips, and maybe set soldering pads if chips are not with same pin count as what was in .  GAL is needed in case of ST, Mega ST, but they are all with DIL CPU .

    For me it looks like accelerator board - therefore is 64 pin DIL socket - I guess that they had such chips (for better price ?)  . And ROM sockets are for modded TOS, may be even 2.06 if CPU is 68010 . And then should be connection to higher CPU clock, like 16 MHz, what should go to logic (GAL), so can use it or org. 8 Mhz for CPU. There are 3 lines at left which seem as points where to solder wires ..

    Since can not find info about online, I guess this was manufactured in small quantity.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...