Gemintronic

Oops.. I guess I did misspell fuschia in that. fuschia is, like, a more intense salmon pink to me. Teal seems to be a darker sea green (to me). I forgot how obsessive I was about having the biggest crayon set as a kid

I guess I was one of those who mentioned Contiki recently. Didn't mean to annoy. If this is posix compatible that should make porting existing applications smoother.

I made a list of constants you can use instead of raw color values. You can cut-and-paste one or the other for NTSC or PAL60. Of course, this doesn't make the resulting ROM both NTSC and PAL60. But, at least makes compiling either one easy. rem //** NTSC Colors **// const _aqua = $B8 const _black = $00 const _blue = $86 const _dkgray = $06 const _fuchsia = $58 const _gray = $08 const _green = $D8 const _lime = $DE const _ltgray = $0A const _maroon = $52 const _navy = $A4 const _olive = $E8 const _purple = $6C const _red = $44 const _silver = $0C const _teal = $AA const _white = $0E const _yellow = $1E const _brown = $E6 const _dkblue = $70 const _pink = $5E const _skyblue = $AE rem //** PAL Colors **// const _aqua = $78 const _black = $00 const _blue = $D6 const _dkgray = $06 const _fuchsia = $88 const _gray = $08 const _green = $38 const _lime = $3E const _ltgray = $0A const _maroon = $82 const _navy = $94 const _olive = $28 const _purple = $AC const _red = $64 const _silver = $0C const _teal = $9A const _white = $0E const _yellow = $2E const _brown = $26 const _dkblue = $C0 const _pink = $8E const _skyblue = $9E

Sounds like it would need porting to the TI. Would it make more sense to use that energy towards porting Contiki? http://www.contiki-os.org/index.html

If it's not something answered in the documentation or search it probably means you're going to have to access it from assembly. Did a search myself and did not find a clear answer.

As penance you must swear to use the proceeds only for expanding your collection. Never to tell how you bought and sold your booty afterwards ~_^

No one needed proof. Or even hints you were willing to sell. If you're intentions were genuine you could just mention you picked it up. Everyone would be happy even without "proof".

Actually, I thought the previous topic enticing people to bid started tactfully. I missed its true intention until a response or two later. Pictures of cash in this topic was a little much. But, I am a lesser man. Never sold anything like that in my life.

I think these ROMz sites have already found a way. Either through more obscure web sites or other means. Nintendo just made their witch hunt harder.

I'm in the office without popcorn. Could you have started this topic a little later?

Us consumers continuing to pay companies with bad corporate behavior ruins video games. If any company can get away with draconian DRM and suing customers they will.

If you haven't got an answer since June I suspect there's not enough Android developers with the specific skills you need here in the retro gaming community. Have you tried a more general Android developer forum? https://stackoverflow.com/questions/9324103/download-and-extract-zip-file-in-android

Drat! I was hoping that it used some combination of ball/missile0/missile1 to fake 1 pixel per scroll.

I've seen some Sonic the Hedgehog scrolling demos that at least simulate a smooth scrolling playfield since then as well. I'm glad people are still figuring out viable techniques - with or without hardware assist!

I've been trying to word this correctly for some time now. All the systems covered by AtariAge are new and relevant to me. I don't consider recent indie titles any different than old corporate brands. I don't collect: I play. No programming language is new wave or old school: they are all wonderful tools. Same thing with 256k SuperShip capable Atari 2600 carts or Amigas with Vampire 600 boards. It's all amazing, wonderful and imminently useful! UPDATE: Yes, I am a little cracked UPDATE II: I guess I should explain more than my everlasting excitement. Yes, there are people who greatly diverge from my viewpoint. But, over time I've found common ground and respect. It makes me want to involve myself more.

I didn't, but, best to make sure we're cool I'm honestly jealous of how much feedback Jefferey has had.

I've had varying success with Tototek adapters. I love that they exist but they can't test it against every make and model of console. So, it should work. But, us Tototek adapter owners will have to see

Gemintronic, on 27 Aug 2018 - 11:12 AM, said: For the record, I never held back. I gave constant and very critical feedback and stated it was absolutely not ready multiple times. I'm not sure what anyone else could have said to have made this magically better. A tester (myself) cannot be held accountable if the practice is to follow suit of 90's Atari in pushing something out the door in similar fashion regardless of the state it is in and completely avoiding to address any and all concerns constantly raised throughout the testing process. Carry on... Whoa buddy! Not an indirect slight on you or your feedback to the original poster. Just thought if Jeffrey needed someone totally unrelated to his current peeps I would try and help. I genuinely did not mean to disrespect you. UPDATE: Maybe "current peeps" is not the right description. I don't know who the heck he works with or listens to. Just thought he might be less reactionary to someone unknown to him.

You need a Video Game Collector themed "Spiritual Warfare" type game for the Genesis I'm your man! ~_^

I think buying an FPGA based system with only one officially supported console type is.. awkward at best. Their existing systems could do it but it's still unofficial and they'd have to tweak the core for each model.. not gonna happen.

The problem before AtariAge efforts is the cost of making a mold. Also, mass producing carts for a niche system. You need to buy in bulk yet sales can be slow (meaning even breaking even is slow.) 3D printing doesn't deliver "enthusiast" grade shiny smoothness. Heck, my two last 3D printers couldn't make carts that stay in one piece. The NES scene has Asian made repro carts (thus shells) because the market is big enough. The Asian Amazon sells tons of Little Samson and 38723789357539-in-1 carts.

Not so sure how well the Genesis scene would take another option. There are open / free options for x86 + FreeDOS and MSX + C-BIOs. Also, readily available FPGA cores exist for MSX and x86. MSX still has a nice scene with many classic games. An MS-DOS machine with PikoCARTs would leverage some of your existing DOS based library.

The problem lies in how well the signal is processed from analogue to digital. Activisions no flicker rule is great, but, some Atari 2600 effects rely on the weirdness of analogue TV. That's why some homebrew that flicker/swap playfields and sprites look OK in Stella but utterly fail as a physical cart on a real TV. I still think a VCR as a cheap demodulator or a used trinitron TV is a good way to go. This is coming from a guy who has tried most of the options including LCD, plasma, C64 monitors and even USB capture devices

Not sure if it'll help. AND it uses a variable for each sound effect. But, I'll just leave this here http://atariage.com/forums/topic/260179-very-simple-sound-engine-with-example/

I self publish my own titles and have been a software tester (and beta tester for game making products). If you need pre release feedback with impartiality just give me a hollar Jeffrey Bones.