Sporny Kun

Hello, I wish you all a nice end of the year. I did another alpha version for this time : https://github.com/sporniket/sporny-wrecking-ball/releases/tag/1.0.0-alpha-5. All the game mechanics are implemented, so I started to do some levels. The game is not finished though, but if bugs and rage do not kill you, you have around 14 levels to play with. And a little preview video : https://www.youtube.com/watch?v=NlGdVeBq0Ow

Super

Tu as essayé le truc de "bien réenficher les puces" ? (pour les puces qui ne sont pas directement soudées sur la carte-mère). Moi sur mon STE récemment trouvé sur la baie, un problème avec les barrettes SIMM de RAM faisait planter les logiciels de ma cartouche de diagnostique (c'était le seul truc amovible). En les enlevant et en les remettant, le problème s'est résolu. Bref, une histoire de faux-contact.

Une photo de l'écran avec les fameuses bandes (horizontales ou verticales ?) pourrait parler à quelqu'un ? De ce que j'ai lu récemment, ça pourrait (gros conditionnel) être un problème de cable (blindage ou impédance), ou encore l'alimentation (condensateurs) qui commence à faire son age et fiche la pagaille. Et j'ai épuisé mon savoir en la matière...

The problem for going 68010/68020 is the incompatibility with 68000 related with the error management (different size of data structure for state reporting/restore if I recall correctly) and one instruction becoming privileged access (supervisor only) instead of normal access. They might fear too much incompatibilitiest problem (plus market segmentations plan, "casual" users targeted by STE as drop replacement of STF, "serious" users targeted by mega ste as drop replacement of Mega ST and then TT)

From what I see, one just need to write a program to list all folders for each partition, and extract title from up to 2 first lines of optionnal README.TXT, and save to a text file. No time for now, but I may do it later.

It look nice

Thank you. Indeed, reading joystick was piece of cake compared to mouse. I will study carefully.

I was pretty sure that the bugs comes from me, but didn't rule out something else without writing proper test. ==> «I hereby deeply apologize to Atari» The handler for joystick is in «_master.s» file, label "OnJoystickSysEvent" I'm using vasm, with devpac-ish syntax and behaviour activated. I recently activated branch optimisation. Thanks for the tip with short address form, it is supported on vasm too.

I finaly did my homework and found the bug in my code : when blitting my lines, I used a full ($ffff) end mask 3 value with the right amount for xcount register (80 words), it turns out I should use an empty ($0) endmask3 value with a supplemental word (81 word) for xcount.

Hello, thanks for the feedback. I accept help for a mouse handler and ikbd command setup with pleasure. I worked around 2 glitches with the blitter : I cannot move more than 320 words (4 full lines). Each 320 words, I get a the source address and destination address miss an increment step. I have to write a test case to either illustrate the problem or find the flaw in my code. Postponed because workaround is splitting the blitting in two and wanted to advance. (I do not happen to move more than 8 full lines for now) I have tested in hog mode in case of some interruption causing the problem, but no effect. When blitting the full lines in my transition effects, there is a column of pixels that are not fully overwritten. workaround is to clear the screen first. For both I need little time to write test case (direct addressing of blitter vs my blitter routine) and look for possible root cause. After doing my homework I will ask for help if needed. Compounded with the fact that I use emulator only, but I'm working on getting a real STe.

Alpha-4 is available, the variable-length bricks are managed (erased) correctly. The demo level show that a brick may occupy a whole line.

It is possible to keep the mouse in the emulator windows. If Hatari is already started, AltGr+m. To start Hatari in this mode, use the "-grab" switch (i learned this last one recently, very convenient).

Well, high level languages favor "speed of reuse", avoiding globals speeds mix-n-match. They like to use the metaphor of L'ego bricks to play with (and I totally profit from this in my daily job with Java) To me the strong point of asm is to be able to micro-manage the scarce ressources we have for better efficiency .

I got enough modularity using includes in my first asm project. However I doubt to get reusability like this, beyond trivial things. To me linker is your friend as soon as you have libraries (especially 3rd parties libraries). And then I believe that most of the time it means high-level languages, with C calling conventions its heavy use of the stack. I see that in asm, I tend to favor meta-programming using macros and trying to avoid using the stack and subroutine. I mean I have key sections that are subroutines, but then each are a big chunks of code, contrary to what I do in C/Java where one try to have short function, extracting parts when it's getting too big.