Nojeee

I've changed the digit '5' in the game font and tweaked the display list to get rid of the zone 1 artifact. The latter fix did need a lot of additional adjustments to the PMG (and multiple other display lists used for the in-game 'message windows'). I've given it a good few hours testing on PAL and NTSC so fingers crossed it hasn't had any knock on effects that I haven't spotted. There are no other changes so the original notes are still valid. Timeslip_2020_V2.xex

Thanks for the link ... much appreciated

Hmm ... that's interesting. When I first got Timeslip compiling from my old source code I was missing the character sets. I grabbed the data from a version of Timeslip that I downloaded from Atarimania. I've just checked and that version does, indeed, have the odd digit 5 (I must admit I'd never noticed). I've just downloaded a copy from a different source and that version is fine. I've tweaked the character using your editor and it'll make it's way into any updated version. Thanks for the heads up. I've also risen to the the challenge of Mrs. Doyle @Wrathchild and taken another look at that scan line issue. I tried all sorts of rearrangements of the DLI but there was always a problem one way or another ... you don't notice it in the other Zones as the player doesn't go right to the top. I then had a thought (which only happens occasionally) and added a blank line to the display list (below the top text row). This cleared the glitch but did shift all of the PMG down by a line which I had to fix. I'll need to give it some heavy testing to make sure it doesn't have any knock on effect but if it's ok I'll post it here.

Once the Orbs have been destroyed in a Zone you need to keep going until the Zone clock wraps around - instead of going to 12:00 it will stop at 00:00. When you've traveled to 01:00 the Zone report row will change to -FREE- rather than LOCKED and it will automatically stop at Zero. You need to repeat that for all three Zones.

Hi Martin, I don't think the number '5' has changed from the original version - are you looking at the in-game font? There are so many DLI's firing up along with WSYNC's to change scroll values, colors, PMG positions etc that I've left it all well alone for this update. The artifact is a result of the PMG also being used on the top score line to give additional colors. To be honest, I didn't want to play around with that only to break something else. Jon

I hope you like the updates and don’t think it’s too easy now. I feel the changes make it easier to complete (after practice) but with more reason to replay.

I've recently been converting some of my old A8 games to the 5200 and have just finished Timeslip. I made so many changes and improvements to the game that I thought a new A8 version would be good too. The game first came out on the Commodore C16 in 1985 followed by the Atari 8-bit version in 1986. I had no way of testing the game on NTSC, so when I started the 5200 conversion it soon became obvious that it was even more difficult to play on NTSC! This version has numerous changes although I've kept the original feel ... and programmer art! The key changes are listed in the document along with some tips. The restricted area for gameplay does make it tricky so I've added a Practice Mode that allows continuous play to get used to the controls. I hope you enjoy the updates. Jon Timeslip_2020.xex Timeslip_2020_A8_Notes.doc

Whoops! Posted this A8 version to the 5200 forum by mistake .. copied to the correct place

I've recently been converting some of my old A8 games to the 5200 and have just finished Timeslip. I made so many changes and improvements to the game that I thought a new A8 version would be good too. The game first came out on the Commodore C16 in 1985 followed by the Atari 8-bit version in 1986. I had no way of testing the game on NTSC, so when I started the 5200 conversion it soon became obvious that it was even more difficult to play on NTSC! This version has numerous changes although I've kept the original feel ... and programmer art! The key changes are listed in the document along with some tips. The restricted area for gameplay does make it tricky so I've added a Practice Mode that allows continuous play to get used to the controls. I hope you enjoy the updates. Jon Timeslip_2020.xex Timeslip_2020_A8_Notes.doc

Following on from my recent conversions of Berks 4 and Major Blink I've just completed Timeslip for the 5200. The game originally came out for the Commodore C16 in 1985 followed by the Atari 8-bit version in 1986. I've made lots of changes to the original A8 code and some of these are listed in the document along with some tips. One point to stress is that gameplay on the 5200 will be difficult with the standard analog controllers and a self-centering, digital solution is recommended. Many thanks to @playsoft for checking the game on real hardware and advising re the controllers. There were so many changes to the original 8-bit version that I'll also be uploading an updated Timeslip 2020 to the A8 forum later. I hope you enjoy the game. Jon Timeslip_5200.bin Timeslip_5200_Notes.doc

Modifying the recent 5200 version so it runs on the A8 should only take a day or two so I'll gladly take a look at it as soon as Timeslip is out of the way. I'll post the updated version on this thread.

Most of the changes were cosmetic ... such as reworking the title page and adding music etc. There were a few improvements to the balancing of the game as it was fairly easy to get through lots of screens before it became difficult. I didn't think that the changes warranted updating the A8 version - it might have confused things. I'm actually just finishing converting my old Timeslip game to the 5200. This has had lots of changes to the game play so I do intend to release an updated A8 '2020' version.

The A8 to 5200 conversions I'm doing are possible as I've still got my original source code. It's fairly straightforward to modify memory usage, change any self modifying code and shift data that needs altering into RAM. I would guess it's not as easy to modify an existing program to run as a ROM image. I've converted a few arcade games in the past but I much prefer to write something original.

Thanks for letting me know. One thing I'm not able to test using Altirra is how the 5200 controller 'feels' when playing - for example, is the fire button easy to press while using the joystick to move the player up & down? I'm using an Xbox controller on the PC and the layout works well. I was hoping it would be fairly easy to get through a few screens without too much practice - certainly on the lowest skill level. Things become much more hectic when you get to the later skill levels ?

Thanks for the message. I'm hoping to do an enhanced version of Baby Berks for the 5200 but it may take a while. In the meantime, I've started to convert another of my old A8 games ... hopefully, that'll be ready in a week or two.

Oops! I could say I left it there as an advert for Berks Four ... but the truth is I didn't spot it even after testing the game for ages (that's what comes of looking at the same screen for hours, and hours on end ... and copy/pasting chunks of code) Here's a fixed version ... everything else remains the same. MajorBlink_5200_V2.bin

Following on from my recent release of Berks 4, I've now ported Major Blink to the 5200. The game has numerous improvements over the A8 version which was converted just over a year ago. Major Blink was the 2nd game in the Berks Trilogy - even though it doesn't contain any Berks! It's a simple, old school game where you need to fill boxes to complete a screen. I haven't tried this on real hardware but it works fine on Altirra so fingers crossed - please let me know if there are any problems. I've also uploaded some simple notes and hints. Jon MajorBlink_5200.bin Major_Blink_5200_Notes.doc

I've just started work on Major Blink, that shouldn't take too long. I'll take a look at the original Berks later but may just convert the A8 Baby Berks which was effectively the same game. The system can only address one 32KB bank at any time. As far as Berks 4 goes, the game code itself uses more than that so I ended up having to switch banks when the music & sound effects was called. The second bank also contains the title routines and lots of data that gets copied to RAM before playing the game. I found that Altirra automatically recognised the type of cartridge I was writing for so debugging was straightforward. You certainly get some interesting bugs when working with multiple banks ?.

The original Berks game for the Commodore C16 was a single screen shoot em up inspired by the likes of Robotron and Berzerk. That was followed by Major Blink, which was completely different but marketed as Berks 2 (for some reason I'm still not sure of). Berks 3 expanded on Berks by linking screens together, I guess it was inspired by Shamus as that's certainly a game I played a lot on my Atari 800. All 3 games were released later as the Berks Trilogy and I followed that up with Baby Berks - a simple magazine type in version that was later released as a budget title. Berks 4 came about after I'd ported Baby Berks and Major Blink to the A8. When I started converting Berks 3 it grew so much I changed the title to Berks 4. The 3rd World in Berks 4 is effectively the content of Berks 3. NB: Let me know if there's any interest in Baby Berks and Major Blink on the 5200 they should be much easier than Berks 4 to get working.

I was recently asked by @sramirez2008 if I could convert the A8 version of Berks 4 to run on the 5200. With some useful information and controller code from @Wrathchild I've managed to get the game running in a 64KB cartridge image. Thanks go to @playsoft who checked that the game ran on real hardware and also played through the game, pointing out some issues that needed fixing. The game is an expanded version of Berks 3 which was released in 1985 for the Commodore C16. I've tried to retain the old school feel where possible. There are 4 'Worlds' available - the first is the smallest and enemies move relatively slowly. World 4 is larger and much more hectic! I've put some basic notes together in the Berks_4_5200_Notes.doc file and this contains a few hints to help along the way. I hope you enjoy the game. Jon PS: This is my first experience on the 5200 so let me know if you spot any problems. Berks4_5200.bin Berks_4_5200_Notes.doc

Any pointers would be much appreciated. The main game would definitely run with 16KB RAM - it’s just the location map that might complicate things. I doubt if compression would allow it to fit into 32KB as the main data area is ‘hand compressed’ already. I quickly tested zipping the final .exe and it’s still greater than 32KB. I’ve written games with cartridge banking before so as long as MADS handles it then there shouldn’t be a problem with the code - it’s just any hardware quirks that I’m unsure about. I look forward to your PM as you’ll probably be able to let me know about any pitfalls. Jon

I have to admit I've never programmed anything on the Atari 5200 so I'm not sure whether the code could be easily adapted to suit the system. The final A8 version only had a few bytes free and there was a lot of swapping stuff around in RAM to make things fit. The code and data ended up around 48KB so it wouldn't squeeze into a 32KB cartridge ... but might work with some sort of bank switching? I'd certainly be willing to look into it. Jon

Same for me ... I don't remember anything available when I started programming on the A8. My graphics editor for Jet-Boot Jack was graph paper and an assortment of coloured pencils ?. When I moved on to some C64 programming I kept my trusty 800 to do the coding and sent the assembled data to the Commodore via the joystick ports. That evolved into writing some editors that ran on the C64 but transferred the data back to the 800 for inclusion in the assembly (this also worked for editing Atari data too). That certainly sped up development. When I returned to the A8 I was amazed by the quality of development tools available. Having said that .... I've just been colouring in some squares on graph paper - old habits die hard!

The Clone Generation of 73 was higher than I expected but 105 is mad! ? I checked my original source code and it reminded me that the value is only bumped for a new Master Multi-Boot - the disk that creates the new master retains its original value. This means that it would take a lot of new masters creating more masters for it to get that high ... if you see what I mean. The image also shows another feature I'd forgotten about; 'Updated Multi-Boot' means that at some stage one of the older style Multi-Boot disks was updated to an XL version. I'm not sure if it's widely known but you can use CTRL and cursor Left or Right to adjust the chroma of the text and CTRL Up or Down to adjust the luma. If you then create a new master it will retain these settings.

It's really interesting to hear how Multiboot made it's way out from the south coast of England - it was long before the days of the Internet so it could only have traveled via physical media. When I got back into the 8-bit scene last year I was really surprised to find out how many people had used it over the years. If anybody is interested, if you go to the Sector Copy Menu ('X' for Utilities, then 'X' for Additional Utilities and '1' for Sector Copy) ... entering NOJ and Return shows values for Clone Originator and Clone Generation. Note - this was added for the XL version of Multiboot and there are lots of the original Multiboot disks out there. If I remember correctly, I only handed out a few copies of Multiboot to friends and each would have a different Clone Originator number (my master being zero). The Clone Generation value would then be bumped for each new master generated from that copy. I haven't kept the record of who had the original copies but I don't think it was more than a handful? I wonder what the highest Clone Generation value is ?