Tursi

Shifty eyes

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.

The comment says this is meant to center the sprite, so probably the "1,28" was meant to be "128" (with no comma). The velocity part of CALL SPRITE is optional, but if one is there, they both need to be - thus the SYNTAX ERROR. But I think you'll find with that one edit it will work as intended.

I am not held to your archaic notions of grammar and universally agreed upon words with known definitions! <.< >.>

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.

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.

Yeah, that one I deprecated on purpose because some of the 98 APIs were holding me back.

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.

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. 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. 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?

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!

Haha, looks like it! Thanks

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.)

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.

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. 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! 😎

Was that one used as an aquarium pump for a while?? I'd be wary of that transformer... are the coils rusted as well, or just the iron?

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.

I think that's a plastic TI logo attached to the case, I didn't see any sharpie... Heck of a machine though, would love to play with it.

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.

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

You have to create your own user XB cartridge and select that, don't use the built-in one.

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.

Hehe.. I just noticed my old Hero game was in there... that's from 1988, not 2016. In 2016 I released HeroX - the 4k assembly port.

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.

The scratchpad loader is the only one I was involved in, though I did use an adaptation of the E/A one in many places.

Technically. XB is faster, but over an entire game loop you really barely notice.