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

Tursi

Members
 View Profile  See their activity

  • Content Count

    7,205

  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Tursi

  2. Posted · Edited by Tursi

    16 hours ago, retroclouds said:

    tursi, out of curiosity: are you using the elego mars or elego mars 2 pro for printing? Looking at the photos, the quality looks great.

    It's the original Mars - https://smile.amazon.com/gp/product/B07K2ZHMRF#ace-6796040015

     

    The quality is GOOD, but I wouldn't go to GREAT. My photos don't show the visible drip residue on the vertical surfaces (since they were horizontal when printed, the resin couldn't run off), nor the slight deformation in the vertical tabs at the front of the cartridge (they were ALSO horizontal when printed). I could probably have solved both issues with some extra scaffolds to give the liquid somewhere to go.

     

    (Edit: Actually, looking at it, the residue is on the INSIDE of the cart, so that's actually resin that was trapped inside. A slight slope on the inside might solve that...)

     

    But, none of this impacted putting the shell together nor the fit of the PCB, and it does have a very pleasing texture. I'm pretty pleased with this printer, especially for as cheap as it is.

     

    • Like 3

  5. Posted

    18 hours ago, wierd_w said:

    I don't know how big your resin printer is, (and if the cartridge case is too large to be flat... meh..)  but I have slowly been working on the "Flip-n-File" 5.25" diskette holder models. Those would make a good addition for here I think.  The patent expired, so as long as I make no mention at all about the trademark, it should be fully legit to duplicate.

     

    As for "mass produced cartridge shells"--- I think you would be better off getting creative--

    I think it should be possible to abuse an old washing machine to function as a suitably large centrifuge (rinse cycle FTW!) to do spin-casting with automotive resin.

     

    The internal capacity of such an old washing machine should be sufficient to spincast more than a dozen shells at a time.  I am imagining a rigid, "Does not come out" support frame to accept rectangular silicone molds with a pour reservoir in them, and a simple clamp-latch on each. (say, some carr-lane clamp latches?) Then you just spray your silicone molds with release, load them into the old washer, pour in your automotive resin into the fill cavities, close the lid, and spin that thing up for a few minutes.  Finished cartridge shells should come out after demolding and minimal cleanup.

    That would be hilarious to watch run - whether it worked or not! ;)

     

    You can see in the first picture how big the resin tank is - not all that much larger than the cartridge. The cart WILL actually lay down in it, JUST, but the screen that does the exposure is smaller than the tank. :)

     

  6. Posted

    1 hour ago, Kchula-Rrit said:

    Oops.  Just looked at the Web-site.  It's been a while since I downloaded Classic99, and I could have sworn that the Web-site said Win2000.  Apologies for the mix-up.  I can try it in my XP machine and see how it goes.

     

    Also, I said VDM99, but I think I meant Thierry Nouspikel's Bug99.  The description looked intriguing, but it communicates with the TI through a parallel port.  That rules out my NanoPEB, so I would have to unlimber my "real" TI PE-Box.  My desk does not have the room to set it up at the moment, and the Bug99 Web-site said that Classic99 has the 'hooks' necessary to communicate with Bug99.

     

    On VDM99...

    Someone gave me a Win7 system a few years ago, that has a real serial port(!).  I got VDM99 to run in this system, and to communicate with my TI with a NanoPeB.  The whole thing proved unstable and I quit trying once I found TI99Dir to copy files into the NanoPEB's Compact Flash with a USB-to-CF converter.  I wonder if it has to do with the NanoPEB DSR turning off the serial port while the port is not actually in use.

     

    Anyway, I ramble...  Right now I'm using Fred Kaal's TI99w while my TI console is in pieces.  It works well, but I thought I would try the Classic99/Bug99 combination for debugging.

     

    Apologies for the mix-up.

     

    K-R.

     

    There was no mix up, I understood both "Bug99" and "VDM99" as "Theirry Nouspikel's debugger tools". ;) Yes, the hooks are implemented in Classic99, but they have not been activated by me in probably 10 years, and I don't believe they were ever activated by anyone else. ISTR that there were some limitations in it, cause I started writing my own external debug layer as well. Anyway, that's all I had in mind with my warning. If it doesn't work, I'm not sure I will care very much. ;)

     

    Classic99 has its own integrated debugger which is adequate for my own work.

     

    • Like 1

  8. Posted

    I haven't tested on older than XP for a long time. In fact XP support is going to be dropped soon according to Visual Studio, so I can't promise how long that will last.

     

    Little of the webpage has been updated for quite a while. There's a note on the root page that I'm (not really) working on it. ;)

     

    Where does it say that it will run on 2000? http://harmlesslion.com/cgi-bin/selectsoft.cgi says XP through 10, and the Classic99 page itself, I don't see any version mentioned.

     

    I should further note that nobody actually used VDM99, and I haven't touched it again since first implementing it, so no promises at all. ;)

     

    • Like 3

  9. Posted

    Necro-posting, muhaha! For want of something to print, I downloaded the STL and tried this shell out on my resin printer (Elegoo Mars). My first disappointment was that it did not fit in the bed flat, which would have made a nice fast print, but had to be fully vertical. So, 8.5 hrs later...

     

    The scaffolding that the software suggested mostly worked... a little bit of it gave out, but it was mostly solid.

     

    image.thumb.png.396a8ead8724070e9cde3ea89f18b119.png

     

    It also popped out very easily - in fact most of it stayed on the platter when I took the shell off (it's not strictly internal, though I guess it could have been). 

     

    The result was decent, solid, and though the top flat edges show a little bit of drippy resin on them, it's sturdy, holds a PCB, and seems to fit together. I even got a neat texture on the top where the software decided to hollow that tiny rise, then put fill patterns in it. A fun project. ;)

    image.thumb.png.c27d46eabade2e7a7301c5e431df9cd0.png

     

    image.thumb.png.61e76e78cd46845dce4b2e904fff277a.png

     

    image.thumb.png.99f20fef5b9b5ffedbe4dd981be66689.png

     

    Besides the build speed, with the cost of the resin I bought it cost roughly $3 to print, which is more than I'd like for more than a one-off. Though I suspect I could have got away with less scaffolding.

     

    Did anyone ever decide on screws? :)

     

    • Like 7
    • Thanks 2

  10. Posted

    16 hours ago, alekmaul said:

    you're right and I don't think I credit you about that, my mistake :/.

    I updated readme.md with a link to your website :)

    It's quite all right! I'm happy to have made an impact, however small. :)

     

    My lib is released public domain, so you have no obligation with respect to it whatsoever. I did that on purpose, feel free! :)

     

  12. Posted · Edited by Tursi

    1 hour ago, tmop69 said:

     

    Thanks for the feedbacks. An updated version in attachment, that should be fast and playable.

    [GAME] Hero V1.1 (1988)(Mike Brent aka Tursi)[Compiled by TMOP].zip 8.32 kB · 3 downloads

    Thanks... I played all the way through this time. I noticed that the death sound and game over sounds are missing their delays and end up basically being a "boop" instead of a falling sound. And the win routine is full of similar tight loops, but it crashes after the very first one. (The character is supposed to run down the ladder, run left to the baddie, punch him, advance to the control board (it's a control board), be confused, punch that, and run back right and up the ladder to the girl). All those steps would also have delay loops. Can't say why it crashes.

     

    It's still a good effort, I wouldn't be too worried. 

     

    (Simple cheat code - just turn all the enemy sprites transparent. Will still die if you fall or walk off the screen. In the Classic99 debugger, enter "v62e=0000000000000000000000000000000000000000000000000000" (52 zeros)). Makes it easier to get through it all.)

  13. Posted

    Nah, the sprite engine isn't using the transparent color for the unset bits, so I think it's okay there. That's literally only there to support the video overlay function -- which is hard-wired out on the 4A console. So we certainly could have used it as an actual color.

     

     

    • Like 2

  14. Posted

    On 9/23/2020 at 8:06 AM, digress said:

    @tursi also added a nice fix to the previous coleco libraries that was causing video corruption to happen as there was a interupt still happening even if you had the nmi_diabled which caused me continual headaches. I really don't know what he did but I would like to make sure that it was addressed.

    While I made a lot of changes, mostly I was focused on reducing the assumption that it was safe to access the VDP outside of the NMI. I can't remember what state my own lib was in at the time but ISTR I mostly ported the NMI handling from there.

     

    10 minutes ago, alekmaul said:

    Yeah, I also manage some code about VDP corruption, and you have two functions you need to use to update VDP OUTSIDE of NMI routine :

     

    These look like they should do the trick to me! But I see you also have enablenmi and disablenmi, and that this is what the Diamond example uses. This seems to work via the BIOS functions. I didn't trace into what they do since I don't use the BIOS.

     

    I think some influence must have come from my lib, since I appear to have a comment in crtcol.s! 😎

     

     

  16. Posted

    13 hours ago, Lee Stewart said:

    The maximum square takes 4 seconds!

    This kind of got me wondering... if doing it mathematically takes 4 seconds, would a dumb binary search be faster? In theory it should be able to get down to the answer within 33 iterations. It'd be straight-forward... square the current number, and depending on whether the result is bigger or smaller than the target, step the appropriate direction. I might be missing something - code I get, math theory not so much. ;)

     

    • Like 1

  18. Posted

    On 9/22/2020 at 3:07 AM, tmop69 said:

    Thanks for the clarification. I've updated it on my copy to have the correct date when I'll release the .zip with all the files. 🙂 

     

    Have you tried it? Is the speed I've set on the compiled game reasonable for the intended gameplay?

    The jumps are way too fast, it's a bit unplayable as a result. I thought maybe you practiced till you liked that speed. ;)

     

    Jumps are done in a tight loop, so that's just one place to slow it down.

     

    • Like 1

  19. Posted

    3 hours ago, wierd_w said:

    kinda sorta.  It would probably take a long time to burn up.

     

    IIRC, the M68000 lacked a heat sink, or fan. If it was running balls-to-the-walls in a cycle counter, with no heat dumping, in a cramped pizza box (like a period mac, such as a IIci or a Macintosh(lc)...) it is conceivable that it would eventually overheat enough to damage it.

    The 6800 is a different processor than the 68000. It's the 68 hundred that has the issue. :)

     

  21. Posted

    On 9/17/2020 at 9:06 PM, TheBF said:

    Code failed on real hardware. Worked on Classic99.

    Also check the debug log for warnings if you're writing DSR code. Classic99's DSR is more forgiving than the TI one but most common cases are trapped and reported. Once you have it working with no warnings, you can switch to the TI controller inside Classic99 and verify it. "Worked on Classic99 but not on hardware" has no excuses anymore. ;)

     

  23. Posted

    The issue is likely the spinner hits, you want to try and figure out why those are happening. While Phoenix seems more sensitive there than a real CV, since you have a reproducible case with two controllers - one that works as expected and one that doesn't - any data specific to differences there would be helpful.

     

    The reason it's a problem is that the spinner causes interrupts to the CPU. If the cartridge doesn't define a valid vector to handle that interrupt, and interrupts are enabled (a combination of cases that is true on a lot of titles), then on an input pulse the software will jump to a (pseudo-) random vector, and more often than not crash. With a real spinner this can happen even if you don't spin the wheel, depending on the position it's in (the interrupt can be triggered by switching to keypad in that case). On some titles simply having the spinner in the right place will cause the software to think a key is held down and leave you stuck on the title page. This /is/ visible on a real Coleco with the Super Action Controller (I think it was Centipede we reproduced it on).

     

    What shouldn't happen are SAC pulses when nothing is wired up to those pins, so it'd be interesting to see whether your "wonky" joystick is doing something interesting there. We're looking at pins 7 and 9, with particular interest to anything on pin 9, which triggers the interrupt. For data's sake, anything from "is it connected in the cable?", which would suggest an antenna-like run, to "is it shorting to something in the controller?" (Though I'd expect a short to affect the real Coleco too...). If your test software there shows the 8 bits back from the controller, you want to be watching the bits for 0x80 (which is the opposite end of the byte from stick UP), and 0x20. (All based on my notes anyway...)

     

    If you have a real SAC, you can also try Space Invaders on real hardware with that, and give the spinner a spin to see if it's tolerant. I don't have that software to test. ;)

     

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...