Jump to content

starfighter

Members
  • Posts

    42
  • Joined

  • Last visited

Everything posted by starfighter

  1. Hi Rybags, thanks for your reply. So I assume you are referring to this part of code in the Rastaconverter exe: /-------------------- // EXIT //-------------------- lda trig0 ; FIRE #0 beq stop lda trig1 ; FIRE #1 beq stop lda consol ; START and #1 beq stop lda skctl ; ANY KEY and #$04 bne skp stop mva #$00 pmcntl ;PMG disabled tax sta:rne hposp0,x+ mva #$ff portb ;ROM switch on mva #$40 nmien ;only NMI interrupts, DLI disabled cli ;IRQ enabled rts ;return to ... DOS skp So your suggestion would be to modify this code and rebuild the exe in order to trigger the loading of my main program in the exit routine above? To be honest, I am a rather Assembly/MADS noob. Would that be possible by using the INS pseudo command of MADS? INS 'filename'["filename"][*][+-value][,+-ofset[,length]] Alternatively, as i am mainly programming in MadPascal, is it possible to define in MadPascal a container file that sequentielly loads the rastaconverter exe and then my main exe into memory?
  2. Hello, I just created my first ever Rastaconverter image. It really is an amazing tool which enables non-artistic people like me to create images that I could not have dreamed to create before. Now, my plan is to use this image as a title screen for my little MadPascal game that I am working on. I was thinking of daisychaining the rastaconverter exe with my main program as the rastacoverter file is aready 22k in size alone, but I am not sure how to do this. Could anyone please give me some hints or are there any tutorials or documentation where I can check this out? Many thanks and kind regards
  3. The running animation looks very good and fluent. Reminds me of the game „Impossible Mission“. The jumping animation is in contrast very static. I feel like a similar fluent animation would greatly improve the visual impression. Overall, the graphics style so far sets the right mood for a zombie game ?
  4. That‘s great news, thank you all for your effort! I also like the enhanced sprite set very much which will give the game another fresh touch. I remember from previous discussions that also samples of a new title screen were created. Would be great if a new title screen could also make it into the new game. I played the original game with my 9 years old son the other day and he liked it a lot. The game is still fun also for the younger generations. A true classic.
  5. My first Computer was an Atari 800XL. I still have it and it is still functional. I also want to keep this machine in its original state for nostalgic reasons. For everyday use I have an 130XE. It is definitely not as robust as the 800XL and of lower build quality. It also had some issues with failing RAMs and logic chips that needed to be fixed. But I like the ergonomics of the XE-line. The keyboard is very flat and good to use in my opinion. Also, I am not scared to upgrade it internally as it is not as precious to me as my 800XL. Design-wise I like both series. The XL-line is classy and the XE-line is still modern looking imho.
  6. Haha, alright,that‘s what I thought ? Thanks for the information!
  7. Great looking demo, awesome work so far! ? I would love to play this on real hardware but I am currently on vacation, so I can‘t check it out. However, since the Demo is distributed as a cart image, I assume I won‘t be able to anyways. I have recently installed an Ultimate 1MB. I understand that you can reflash the Basic Roms and the Missile Command ROM of the XEGS into the Ultimate Firmware. I haven’t played with this functionality (yet), but I assume that there are some restrictions like image size, etc, that would need to match.
  8. Looking best on old school monitors from the 80s anyways Still my original one from 86....
  9. Looks great! The one in the middle reminds me of Elvis (The King ) somehow...
  10. I rarely ever post at forums, but this effort really got my attention! What I have seen so far, this is going to be one of the best Prince of Persia versions available. I am really looking forward to playing the final version on a real machine. Kudos to the ppl who are responsible for this great port! It would also be fantastic if the source code code could be released, hopefully with documentation :), so ppl can learn from it and create their own versions or additional levels, etc...like they were doing for bruce lee and montezuma's revenge... This kind of creativity compared with nostalgia always reminds me why retro computing is such a great hobby and fun.
  11. Hi Tebe, thanks, updating the array after initialisation is is exactly what I did as a workaround. So I assume, there is no other way than doing this. Thank you for the clarification!
  12. Ah, okay, thanks for checking! I know about Graph2Font! it is also an awesome tool, but I haven't used it yet. But I have put it on my list of cool Atari stuff to check out If anyone is interested, I have compiled the latest versions of Mad Pascal and MADS for Mac OS: Mad Pascal 1.5.8: https://github.com/starfighter06/Mad-Pascal-for-Mac-OS MADS 2.0.8: https://github.com/starfighter06/MADS-for-Mac-OS I did it for my own purposes as I am a Mac OS user, but maybe it is useful to other people as well.
  13. Hello Tebe, awesome! That solved both problems at once, thank you very much! Sometimes the solution is so simple If I remember correctly I had the DL arrays once defined as constants, but then moved them to var, bc I thought about changing them on the fly. I don't know what other developers think, but generally being able to specify certain memory locations or border alignments for arrays, variables, procedures, might be a useful native feature for Mad Pascal or what do you think? By the way, do you know, why the other issue occured when the array was defined as variable (i.e. that the pointer after the JVB command was not stored during array initialisation): PlayfieldDisplayList: array [0..98] of byte = ( ... ... $41, lo(word(@PlayfieldDisplayList)), hi (word(@PlayfieldDisplayList)) //JVB: Wait for vertical blank + jump to Display List Memory Location ); How should this be handled properly other than just overwriting it afterwards? Many thanks and kind regards, starfighter
  14. Thank you for your answers! It would be good if I could reserve a specific memory area for the array, but how can I achive this in Mad Pascal? The array and its content is defined in the var section of the code and I would like to leave it this way for code readibility reasons. Of course, I could define the DL and the memory location in assembler and include the code via the ASM tag. I have done this e.g. for including a character font file. But if there is a cleaner way to do all this in Mad Pascal directly, this would be my preferred choice.
  15. Hello, I am a long time Atari-User (my first computer was the 800XL back in 1985) and a retro computing fan. It is very fascinating to see that new technology and software is still being developed for these machines. I am especially impressed by tools like MADS/WUDSN IDE and Mad Pascal. Therefore I decided to start learning Mad Pascal (with a little bit of Assembler). I am not a very active forum writer in general, it is not my thing really, but I decided to write my very first post nevertheless. My question is related to memory management in MadPascal. I would like to understand if there is a smart or "clean" way to cover specific memory requirements of the Atari, such as 1K-Border restrictions for Display Lists or 4K-Border restrictions for screen memory? For example, I am thinking of something similar like the ".align" directive in MADS? Here is an example of my problem: Imagine a simple display list configured as an array: //Custom Display List for Playfield Screen PlayfieldDisplayList: array [0..98] of byte = ( $70, $70, $70, //3 x 8 blank lines (24 Scanlines) $42, lo(PlayfieldHeaderMem), hi(PlayfieldHeaderMem), //2 x Mode 2: Playfield Header (16 Scanlines) $02, $4D, lo(PlayfieldGraphicsMem), hi(PlayfieldGraphicsMem), //84 x Mode D: Playfield (168 Scanlines) $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $42, lo(PlayfieldFooterMem), hi(PlayfieldFooterMem), //1 x Mode 2: Playfield Footer (8 Scanlines) $41, lo(word(@PlayfieldDisplayList)), hi (word(@PlayfieldDisplayList)) //JVB: Wait for vertical blank + jump to Display List Memory Location ); I am facing in my program now two problems: 1. The array was placed into the memory at location $57DD, thus breaking the 1K-boundary at $5800. 2. The address for the JVB is not correctly set to the start address of the display list. Maybe due to a "chicken egg problem", that the array does not know its own location at initialization? For reference, see the memory dump of the array: I can surely find some workarounds for these issues, especially the second one, by just updating the last two array items with the correct memory location for the JVB AFTER the initialization of the whole array. I have to think about the first issue yet. Probably by just reorganizing or growing the code, the problem might get solved by itself. However, I am curious if there is a better way to manage the memory in MadPascal without "hacking" or hardcoding memory locations into the code? Many thanks in advance and kind regards, starfighter
×
×
  • Create New...