20241022 : 'dlog' as on the middlersted pages has not been implemented here. The site is unpaid, unsponsored, uncensored, pegi99 and mostly there to keep us from brainrot as we have always kinda liked desteren on een site. It also says somewhere on the frontpage : "it will fall in place" ... design leads to rigidity and we got nothing to prove. As to the whythis wythat ... You wont do NFS7 on an STE (and its not our genre anyway), we personally think doing 3d games on an 8 or 16 bit-gen computer is never the best idea, its good for hashtabled scene prods but i cant really think of any 3d game that worked out on a c64 or ST (or probably amiga unless you count "A1200 but you need a 68060" as amiga and then still ...). Supermeatboy ... someone who know their motorola might pull it off in 16 colours only BUT
When the boy first got hands on that 100 turn civ-demo (cant remember but probably a magazine disk that got handed around in the booniesticks where software was not weirken and maybe still could get you burned at the stake.) it was like a dark souls-level revelation. Not the same b/c it was the 90s but dark souls kinda got us back into gaming after a period of meh. Civ was "WTF IS THIS? can they even do this as a game" yes they could. Then the game itself (acquired via HTL mail order catalogue - your 1990s amazos equiv !) is probably the only one the boy would cut class for. Then some years later a pc was bought for 110% of the then monthly income after playing warlords2 and (SSI!) panzer general at a friends house on his fathers machine, a 486 superpowerhouse, and us, the guy bought a p60 with a 14 inch screen and OMFG never seen anything like it (lol) so you could say doing a TBS (or later c/j RPG) is the obvious choice since we can put more of our soul into a game like that. Not because "its easier to prgram" b/c design-wise , and i dont mean the program logic. Doing a decent SSI-like game might take a lot more than the 20 levels of spelunky so to speak (we heart spelunky64!!! and sincerely hope the engine wont go to waste and spawn 20 more platformers with versatile controls and pixelperfect smooth movement, only this time plz with some "designed level campaign" befoer the procedural replayabillity starts) .. SO IN CASE OF WHY ... that would be why ... Middlersted on the c64 wont be a platformer or a racer either.
20241022 : from the looks of it we would be starting out with STOS ... if H.E.R.O. - Human Extraction and Rescue Operation (4mb re-release) is one representative game of "this is what you can do with STOS" , misterFPGA tested (STE tos 1.62 4MB sampled DMA track et al scrolling ...) then it looks like STOS would be plenty to do a type of game we want, be it SSI-like or c/jRPG, and since the standing ST machine ended up an STE TOS1.62 4MB its kinda perfect comparison (we kept the TOS2.06 machine but havent figured out where on the mobo the issue with the DMA sound lies) so "tested on real hw (a must!) is a total option. The one thing i havent seen is "using 32 colors" or like Mslug "52 colours on screen (at fullscreen scrolling action) but im sure it can do the 512 overscan stills. The thing is you see, having done the groundwork for Oggy'24 on the Jag, seeing how a resolution of only 320x240 turns into something else if you have "4bpp"(16colors) PER SPRITE (or bob or image whatever, the jag is basically one single hardware sprite machine with the OP doing all the work) then i think 32 colors constant (as an SSI-like or c/j rpg doesntneed 50fps sync scrolling really, but 1stlove (overlanders) shows off you CAN , even on a base ST as long as you have enough memory (which i assume is used to cache the screenbuffer in combination with split-cycle timing) like
Fairlight will use in 78 rastersplits but in the demo you see how a shmup could actually look , EVEN on a non STE (but with 4mb or i bet at least 2 if you want some sound and more than 2 sprites to go with it) .. THAT said we havent gone beyond hello world in GFA for now so its too early to say but maybe we try for a christmas card in STOS this year, as good practice for the future, otherwise i dont think we'll get to a "how many machines we havent touched can we do in 7 days" or else at best something in GBstudio (out of sheer curiosity for what it is to do something gameboy - after all we never grew up so we're still curious and not afraid to make mistakes) ... and SO ..
in general we still think its the better idea to start with something like STOS or GFA instead of deep-diving into motorola asm right away. We havent really mastered the c64, another 40 years on scene to get to FLT or Censor level i suppose, but the kid DID with the KCS cartridge mess around in that 40 years ago ... somewhat around ... 35+ something i dunno time is not something we do very well. So doing the c64 game in a ACMEsyntax / TRSE combo smacking it together via imHEX into an easyflash image (actually writing JoGcartconv.sh was the easy part there) we can always try to add inline ASM routines later, i assume any decent basic will have "SYS" call commands .. as for Omikron ? no clue but it doesnt seem to be the most popular
This is not about playing games
since we have a real Atari again after more than 30 years it seems inevitable some programming will happen ... a bit like a vacuum to the universe . There's probably two options and we probably go for compiled basic unless theres enough time and the brainfog lifts before dead or demented b/c atm motorola68k on top of the rest seems like a tall order ...
20240927 : finally the drives are in place (partitions ... and after 200000+ copies moves and deletes it doesnt seem like the DMA sound = DMA file corruption cuz we cant find any) Got GFA basic 3.6 which runs fine and WE HAVE HELLO WORLD ! ... now i still dont know which compiled basic would be best to do an SSI-like or a j/c rpg type game since we wont be going for hard motorola straight away while still learning half of the c64 ... got no answer on the forum (again) when asking suggestions as to which language compiled basic would be best so we'll just go over them .. what would we need ? no 50fps 8way scrolling obviously ... but sprites / bobs yes, more than 16 colours OBVIOUSLY and well ITS AN STE, I NEED THAT GOD DAM FUCKING DMA STEREO SOUND TO WORK AS GOOD AS IT RUNS CODERS GUIDE TO THE SCENE ON FUCKING HATARI ... for that "Atari CD32" feeling ... i guess we got time until dead or demented, buying a second one would bring the price to "about an untested Falcon" which is a bit crazy considering the day and age budget we have here ... the quest continues but at least we can write hello world and display a gem window (if you look at mac+ civ it actuallly PLAY in OS windows (and imo it plays just fine)
1) an SSI-like
the would be "queen under the mountain" which was already a part of the Tyrnannoght game that will never happen due to the americans murdering crypto and our last chance out of here
2) a c/j-rpg
both should be equally fine using something like GFA but frankly
we seriously dont know enough about it to talk about it yet
since contrary to the c64 with its native basic and KCS power cartridge
the ST and STE came with a little green desktop and nothing else
so the boy never got to programming on it b/c soon after he discovered girls had tits and the attention got divided (there was probably some beer too)
https://docs.dev-docs.org/htm/search.php?find=gfa
site subject to W.I.P.ping
stos sprites - still no real idea but still under the impression GFA might be the best choice of the 3
https://forum.vcfed.org/index.php?threads/game-oriented-programming-for-atari-st-e-atari-game-tools.1238178/ - a bit more advanced i still think we should start with GFA or STOS for the first one
puzzle allright not only have we zero on 16bit opcodes we seem to get fresh jargon (from the 1980-90s) and a guy who definitely knows what hes doing claiming "Finding usable information about programming the timer chip was a challenge. I ultimately ended up relying on the Hatari emulator source code, and a 1986 Usenet post from someone named Jwahar R. Bammi that provided some excellent sample code in C-with-inline-assembly to configure, run, and tear down a 48Hz clock callback. With that as a base I was able to create a working vasm-compatible program of my own with similar behavior, and poke around some of its weirder edges as well."
"Cycle counting isn’t a great plan on the Atari ST; the hardware is noticably interrupt-driven and you will not have strong guarantees on the amount of time passing between each instruction in your code."
and other summer hits ...
"spinlocking" .. USER and SUPERVISOR mode (on TOS ??? usermode in asm on a 16 bit machine ... wel see ... this is how we started the c64 as well but euhm)
"elevated function" .. to show that we have "no strong opinions ... opinions huh
"Finding usable information about programming the timer chip was a challenge. I ultimately ended up relying on the Hatari emulator source code, and a 1986 Usenet post from someone named Jwahar R. Bammi that provided some excellent sample code in C-with-inline-assembly to configure, run, and tear down a 48Hz clock callback. With that as a base I was able to create a working vasm-compatible program of my own with similar behavior, and poke around some of its weirder edges as well.
tahts from a guy who definitely knows what hes doing
addq.l (l stands for long ???), bclr.b .. i see move.w so thats why and i bet that bis byte and w for word ... andthen "trap" ... never heard about
the motorola trap instruction ... "It's the TRAP instruction itself that will force the CPU to supervisor mode, and then depending of the #xx number you used will jump to any of the 16 possible callbacks from the memory area $80 to $BC.
TRAP also pushes to the stack the PC and SR values, so when the last function call returns it goes back to whatever mode was setup before you called TRAP."
tbh we wus just looking for some kind of zone split like a c64 has with raster interrupts so you can run a program on top of the interrupt chain ... in this case to get more colors so if we could find that and have it run as some kind of inline ASM call at the start of gfa or stos we could write the program over it while it handles switching in the background ... the whole thing is different since the screen and memory is one and the same i think here, i dont know how many cyclesyou have per line compared to the 63 on a 64 ,and if it says cycle counting is unreliable then we should scrap that idea anyway PLUS : no hardware sprites so the moving blocks or bobs will adjust to the color palette in the specific zone its mving in unless you do some kind of 25frame/25frame in a 50PAL interlace flicker thing for advanced scenoids above our current braingrade ... perhaps
but so TRAP seems to point at some kind of interrupt system ? with a LUT somewhere that jumps to certain (why do they call that vectors ???) addresses in memory ...
its not like it doesnt look like STOS or GFA isnt capable of a TBS or j/cRPG - like game its like having more colors would just be nice but the only extensions i found so far are for displaying fullcolour 512 still pictures which i bet means you cant have moving bobs on that and if you did theyd look like shyte constantlyu flipping color to the current space they're in b/c ... "no hardware sprites" ... i think we understand the traume that had them turn the jaguar into one big hardware sprite machine now ... well ... i think even if it came with a CD it would have been outdone by the playstation anyway - + too weird to code, i dont even get half of the explanations on forced waitstates and all that but SO HERE WE HAVE USER AND SUPERVISOR MODE AT MACHINE LEVEL ???????????
lets put the E.TA. for the Atari game in 2051 then for now , some reading seems to be in order