Nojeee

I never spotted that glitch during testing so I think it’s a rare thing, I probably wouldn’t be able to reproduce it. It’ll be down to the way an enemy is cleared before redrawing after a move. I don’t remember there ever being a manual for the C16 game. All of the marketing was done by CRL who also did the cassette inlay picture ... which was then replicated for the C64 loading screen. I did write the C64 version but didn’t really know where to release it. The C64 scene seems to be quite different from Atari with a focus on cracking and releasing versions with cheats menus. I was invited to join a group who then took my main code and added the loading screen done by one of their members - they then uploaded it for me (hence the credit to Digital Monastery). I remember back in the 1980’s how frustrating it was developing games. When I was asked to go a C64 game I just worked out a way of using the Atari 800 to assemble the code and send it to the C64’s user port. It sped things up greatly because if the C64 crashed I could simply update the code, reassemble and re-download. By the time I move onto the ST there were systems available to do the same to a slave ST or Amiga.

I've spent ages playing the game and can't get anywhere nearing exceeding the score counter (I'll put it down to old age!). However, I've created an updated version that works exactly as before with the 6 digit score but bumps to 7 digits when the score goes over a million. I've done it this way to preserve the original layout which is tidier when showing the high scores on the title page. I haven't been able to do the amount of testing I'd normally do with this new version so I'd still advise sticking with the original unless you really want to try and break it . Let me know if there are any problems. Major_Blink_2020_V2.xex

I'm glad you enjoyed the game ... it was written in assembler. The original Commodore C16 version was written using Synassembler and the later Atari ports used MADS via WUDSN.

Thanks for letting me know ... it just goes to show how bad I am at playing my own games! I’ve had an idea which would cover the problem without making any changes to the in-game scoring and balancing. I’ll upload a version here once I’ve had a chance to do some testing .. I’ll need to add some cheats to enable me to get such a high score

If you do manage to max out the score I’ll have to come up with a tweak to allow it to count higher ... I’ll need to keep the actual score values and skill settings the same though. I claim the high score at 69 and counting ...

That might explain it. The original version was a fairly faithful port of the C16 release and I made no changes to the scoring or skill levels. I had noticed that an experienced player could accumulate lots of lives by starting at a lower skill setting so there were lots in reserve when things got harder. Extra lives were also given quite frequently so it was easy to keep to keep them topped up. When I started on the 5200 conversion I decided to spend some time balancing the game better and the new 2020 A8 version carries that over. The frequency of extra lives, along with the bonus scores generated for completing a box, is now governed by the entry skill setting. Additionally, the number and speed of enemies have been adjusted to (hopefully) make the difficulty ramp better. Finally, when you start reaching skill levels around 20 speeds increase even more. These changes should make it far more difficult to lock out at 999999 (I’d better not say impossible). it would be really interesting to hear if you think the 2020 version makes things harder.

I honestly never thought anybody would be able to reach that score As a matter of interest, are you playing the original version or the newer one based on the 5200 conversion? If it plays music on the title screen then it's the later version (Major_Blink_2020.xex).

It’s great to see the Updated games being played competitively - the scores show that I need more practice! The 2020 versions came about after a request to convert Berks Four to the Atari 5200 console. I followed that with Major Blink and included some improvements that had been made for the recent C64 version. I then converted Baby Berks and Timeslip and thought I’d provide the 2020 updates as this allowed me to keep common source code for the two machines. Baby Berks didn’t have too many changes, mainly balancing and bug fixing. The changes to the Timeslip movement came as an attempt to improve things for the 5200’s analog controllers. I felt it improved things for the A8 too in the restricted play zones. However, I appreciate that it takes a bit of getting used to. The main feedback I got from the original was that it was too hard to complete - it didn’t really lend itself to replaying. Looking at the scores, there’s a possibility I’ve made it too easy

Thanks for the kind words ... I see we're both fans of traditional Atari rainbows on our front ends PS. I've been having fun playing Sector Wars - I just have to get better at it.

I tried using the Atari Assembler but got frustrated by its limitations. I got hold of a copy of Synassembler on disk which made things much quicker .. but there were still major limitations down to the amount of source code you could fit on a floppy. I always split the assembly into main sections - for example the main game and the title routines would be assembled separately and linked by vectors at the base of each 'chunk'. When I took the plunge and started programming full time I invested in additional floppy drives to speed things up - the main file would include the other sources and data files then output an object file to disk. I'd then have to enter the Synassembler monitor to load and run the binary file. The biggest frustration was when things locked up and I'd have to reboot the system from scratch. When I moved on to doing some C64 and C16 games I decided to stick with my 800 and Synassembler but output the code via joystick ports 3 & 4 to the target machine. This really sped up development - if the target machine locked up I could just reset it while the 800 stayed working. I used the same system when I wrote Timeslip on the Atari, I purchased an 800XL as a target machine. I kept all of my old floppies and finally got around to transferring them to the PC a few years ago (fortunately, the majority were rescued although a few were past saving). I've now got most of my old source files converted into projects in WUDSN and assemble directly to Altirra. The speed of assembly and range of debugging features is light years ahead of the 80's ... but still as much fun Jon

Very strange ... I'll send you a PM for some more information.

@TGB1718 You can try this version to see if it solves your problem. Thanks to @Faicuai for the information on the A800 + Incognito issue with XL/XE OS and help testing this version. I've adjusted the initialization code to get around the compatibility quirk. Thanks, Jon Baby_Berks_2020_V2.xex

Thanks for the feedback on this - it's good to know it's working. I always check that my code works in Altirra and on my real PAL 800 and 1300XE - is there a checklist of popular hardware / emulator setups that I could be checking against?

That's strange ... I've tested it in the latest version of Altirra on PAL and NTSC and it works fine here. I've also checked it on my 130XE via SIO2PC and 'Boot Executable' ... again, it works fine. I'd be interested to hear if anybody else is having a problem running it.

I converted Baby Berks to the A8 a couple of years ago and have just finished a 5200 version. I made a few improvements so thought I'd also upload an updated A8 version here. The first A8 version may have been missed as it was uploaded in the middle of a thread about the original release. The game first appeared as a magazine type-in for the Commodore C16 and then came out on a budget label. It's a very basic game with simple graphics and limited sound effects... I had to keep the size down as much as possible so the enemy movements etc are a little clunky! This version has improvements to the missile firing; the weapon now fires double missiles so it's less frustrating trying to line up enemies. There are tweaks to the NTSC/PAL balancing, extra lives are now based on skill level and high scores are kept for each starting skill setting. The game now continues to get harder after Master level. Jon Baby_Berks_2020.xex

Baby Berks started life as magazine type in program for the Commodore C16 in 1986. It was later improved slightly and released as a budget title. I converted the game to the A8 a few years ago .. here's a 5200 version. The movement of enemies is rather clunky compared to Berks Four ... that's because everything was simplified to reduce the size of the original type-in program. I often wonder if anybody actually bothered to type it in (and if it worked!). The original did suffer by the way the main player fired missiles. The 5200 version uses the Berks Four method of firing 'double' missiles so it's less frustrating trying to line up an enemy. There have been some balancing changes for NTSC, the high score is now kept for each skill level and extra lives are based on current skill level. Jon Baby_Berks_5200.bin

Thanks for the information, I've downloaded the examples ... I think I'm a bit lazy and do everything within the IDE. I've resurrected lots of my old projects and it's really easy just to open one up in the Project Explorer, load any source and hit Compile and Run. I've been working on a few conversions of my A8 games to the 5200 and then decided the changes warranted new A8 versions ... hence the reason the 5200 is currently the 'default'. I'm glad I haven't missed anything with forcing the output filename. Everything works fine at the moment - if I start from my A8 file it sets MACHINE_TYPE = ATARI_A8 and then includes the 'real' main file. This checks if MACHINE_TYPE has been defined, if not it sets it to ATARI_5200. The output filename is set correctly having been set to an .exe if started by the A8 main file (the .bin annotation in the 'real' main file is ignored). I hope that makes sense? Thanks for producing such an invaluable tool ... this, coupled with Altirra, makes life so much easier.

I'm using the following annotation to set the required output filename: ; @com.wudsn.ide.asm.outputfile=Timeslip_5200.bin I've updated the project so it can now use the same source files to create the A8 version, with certain code conditionally assembled using: .IF MACHINE_TYPE = ATARI_5200 Ideally, I would like to set a flag at the top of the first file that dictates the build type (MACHINE_TYPE = ATARI_5200 or ATARI_A8) and have that determine the output filename. There doesn't seem to be any way of doing this as it always uses the first annotation found. I've worked around the problem by creating an additional 'first' file that has the annotation for the A8 output filename and then includes the 'first' file for the 5200 project. This works as it ignores the annotation in the 5200 file. The problem with this method is that if I press Compile and Run from one of the include files it always creates the 5200 project. Is there a way to selectively set the output filename that I'm missing? Thanks Jon

One of the features I use a lot is CTRL + mouse pointer Hyperlink Navigation to other routines, labels etc. When I first split a project into multiple include files I noticed that the feature would only work from the first file. I thought this might be a problem with one of my Eclipse settings but nothing fixed it. Purely by chance, I added a line in the include file to include the main file within an .IF and things worked. I now list all project files at the bottom of each source and can navigate around the whole project - for example: .IF 0 ICL "Major_Blink_Master.asm" ICL "Major_Blink_5200_Init.asm" ICL "Major_Blink_5200_Main.asm" ICL "Major_Blink_5200_Extras.asm" ICL "Major_Blink_5200_Titles.asm" ICL "Major_Blink_5200_VBI.asm" ICL "Major_Blink_5200_Music.asm" ICL "Major_Blink_5200_Data.asm" .ENDIF Whenever I add a file to a project I also add it to the 'includes' list at the bottom of each file. NB: The hyperlink navigation did stop working one day and I spent ages trying to work out why labels wouldn't highlight as required. It turned out that I'd closed the Outline view in order to see more of the Project Explorer. Simply opening up the Outline view made the hyperlinks work again. I'm not sure if that's something obvious that I should have realised?

That's how I had to get the original transfer code running on the C64 - by entering it by hand into the monitor and saving it to disk. Once I had a simple version running I could transfer updated versions from the Atari. It reminded me that my very first assembler code was on the Commodore PET - I wrote the code on an A4 pad, manually converted it into hex using opcodes from my 6502 reference book (including working out branches) and typed it into the monitor. (This does sound more and more like the 4 Yorkshire Men sketch from Monty Python! )

I always used De Re Atari and Mapping the Atari for reference when I was writing for the Atari. The machines are similar enough to make conversions fairly straightforward ... once you've got your head around the Atari's graphics modes and display lists. When I converted the Berks games from Commodore to the Atari the majority of the game code worked without major changes (generally just working around the lack of a separate color memory. It's still on the cards ... I don't think it would be a straight conversion but something along the same lines.

I don't still have the cable but I do have some of the original source. The two machines had to handshake which took a couple of the data lines - each byte was therefore sent in nibbles by the master and combined by the slave. This source is really old, clunky and has minimal comments ... excuse the formatting as I have to convert from the tokenised Synassembler files to a standard text file. Ports_12.asm is the only file I can find that relates to the master - this isn't the version I was using but gives you the idea. I created an Autorun.sys file so the handler was automatically loaded when Syanassembler was booted up. My code would then output using .TF"Z:" rather than .TF"D:FILENAME.O". PS. My source code is much tidier nowadays ... honest! Ports_12.asm Atari_Atari.asm CBM_50000.asm

Jet Boot Jack was written on my 800 - initially using a 410 tape deck before moving up to a single 810 drive. I used disk based Synassembler with the object files written to disk ... which then had to be loaded and run. If there were any major problems I'd have to reboot everything. It was a very slow way of working. My first computer was the original Commodore PET and I'd experimented with the bi-directional User Port. When I was asked to write for the C64, I realised I could stay using the 800 and transfer the code via Joystick ports 3 & 4. I cobbled together a link using two joystick cables and a connector for the C64 User Port. I wrote a system that allowed Synassembler to output the code to a Z: handler with some code on the C64 that did the handshaking and sent the code to the target address. This was later updated so I could also transfer data from the C64 to the 800 (I wrote a few editors that ran on the C64 and sent packed data for inclusion into the assembly). I used the same system for my C16 / Plus 4 games and when it came to doing Timeslip on the Atari bought an 800XL as a target machine. It certainly made it much quicker to develop ... and by then I had to use two floppy drives. I used the system for many years until PC cross development was more common. Happy days

I usually spend a lot of my time programming over the winter ... then get around to the ever growing list of things to do around the house and garden! Multi boot was initially written for my personal use to save having too many floppies around (plus the fact it made it easier to swap titles with friends). I don't think there was anything major that was missing. Maybe I should have made it more difficult for people to change the title with a sector editor and pass it off as something different It's eerily quiet where we are at the moment ... strange times.

Here's an updated version of Major Blink as requested. I'm using the same code as that released for the 5200 ... the changes are mainly to the front end which is more like that of Berks Four. There are a few cosmetic changes to the game itself along with some adjustments to the way the game ramps up difficulty with each completed screen. Extra lives are now based on your starting skill level - this stops you banking lives by starting at the lower skill levels. I also had to reintroduce some PAL/NTSC adjustments. I've given this a day's testing on Altirra and it seems fine ... fingers crossed. Major_Blink_2020.xex