tschak909 Posted May 12, 2018 Share Posted May 12, 2018 I will say it right now... GEM's API makes me want to drill another fucking hole in my cock, before I blow my brains out. It is some of the sloppiest shit I've ever seen in my three decades of programming professionally... With that said, I need to write a PLATO terminal emulator for the ST, so that ST users can access IRATA.ONLINE. The code that I have so far, is here: http://github.com/tschak909/platotermst I want to do everything onto a buffer which I can then subsequently blit onto the target window. The buffer is initially 1 bit monochrome, but may eventually be color. do I use vro_cpyfm() or vrt_cpyfm() ? <-- at the end of my rope. -Thom Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted May 12, 2018 Share Posted May 12, 2018 Atari with GEM is made for amateurs, not professionals, that's your problem. And maybe something else, considering extremely dramatic post ... Sorry, I can't help, I'm just dumb ASM coder. Maybe docs for it are biggest problem. In old, Internet less times, when I was in dilemma, I tried all ways, and used what worked best. I had some literature, but that was almost never enough, not to mention some errors, originating from Atari doc. writers. Still, it was good fun to code for Atari ST, and even today it is. So, please change that shirt to some 16-bit one, and everything will be fine Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted May 12, 2018 Share Posted May 12, 2018 http://toshyp.atari.org/en/00700b.html Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 13, 2018 Author Share Posted May 13, 2018 Yeah, have been reading this, as well as the atari compendium. This whole API really...really..._really_ sucks. Like it was written by adhd crack addicted monkeys. Lots of different ideas...nothing really fleshed out. It's a bad sign, when you have approximately 200 code examples from different authors, and all 200 of them have different ways of managing their drawable content. -Thom Quote Link to comment Share on other sites More sharing options...
ParanoidLittleMan Posted May 13, 2018 Share Posted May 13, 2018 (edited) API is not perfect, but what you do here is total wrong - asking for help, while spitting on Atari ST feature, in front of Atari fan people. Very stupid. The truth is that you are who sucks, since most of people were able to do their SW with that API, 30 years ago, with much less available docs, help. Without Internet, experienced people who could help. If you want this seriously, stop writing bullshit here, sit down and work on it. Your first sentences in thread are something stupidest I seen in forums overall. Edited May 13, 2018 by ParanoidLittleMan Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted May 13, 2018 Share Posted May 13, 2018 Download this book and spend time reading it /Atari-ST-Internals.pdf Look for this book too: Atari ST GEM Programmer’s Reference eBay Auction -- Item Number: 123061660920 These were my GoTo books when learning how to program the ST Quote Link to comment Share on other sites More sharing options...
Goochman Posted May 14, 2018 Share Posted May 14, 2018 One right here for a good price: http://atariage.com/forums/topic/278443-for-sale-atari-st-manuals/ Quote Link to comment Share on other sites More sharing options...
madaxe Posted June 11, 2019 Share Posted June 11, 2019 I want to do everything onto a buffer which I can then subsequently blit onto the target window. The buffer is initially 1 bit monochrome, but may eventually be color. do I use vro_cpyfm() or vrt_cpyfm() ? For a monochromatic bitmap use should use vrt_cpyfm() and for a colour bitmap the right choice is vro_cpyfm(). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.