Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About TracMan

  • Rank
    Space Invader

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Wow amazing game. All sorts of possible game improvements I'm sure are possible. Like a gold DDT spray that stuns the wasps individually or together. A crawl option. Then a slow down potion for the beetles.. even better different type/colour of beetles on the same line a horizontal screen apart. More vertical climbing as well and areas with no gems but the platforms closer together so you can jump without ladders.
  2. I've looked at G&G sprites myself in the past and attached a SPM file of the original C64 sprites for G&G which can be loaded into http://spritemate.com. I modified it to prove most of them could use the Brown, Green and White of the background. Just P0+M0 would be needed as overlay to add the contrast needed for the 10 light blue pixels of the player and P1,P2,P3+(optionally) M1+M2+M3 for the zombies, birds and other creatures (I've used blue for the birds also like the arcade version). gang_tweaked_latest.spm
  3. This one by Gonzo AFAIK. Unfortunately, it will obviously be the case that a lot of 'tech demos' will be lacking a software sprites engine that the coder must add, this is often the best way for Atari 8 to preserve the amount of C64 colouring so that you can get a 5th colour, since the Atari player/missiles are limited. All the players are used up for the main sprite and they need a character graphics sprite engine.
  4. Fascinated reading about ZX Spectrum emulation and parsing code and building new source and appreciate that is what is needed to get really good conversions to the Atari. So here is my 10 cents and feel free to shoot me down in flames with this idea, but I wonder if anyone has ALSO considered or done any work previously with the idea of 'twinned' emulators? Basically, an Atari emulator eg. Altirra would have to support a new mechanism to simply also launch another emulator (ie. a specific preferred ZX Spectrum emulator as a background process) and set up a shared memory pipe which is used to share info between the two 'twinned' emulators. Signals and data can be sent both ways to and from the shared memory pipe between the two machines, and they are simply preceded and separated from the next command using the pipe symbol. The 2nd twinned emulator will have been selected as one with suitable source code available and will of course have been modified to be able to be launched in a special way in order to have no direct keyboard or joystick control from the Windows PC, nor will it even have a 'Windows' screen. It also plays no sound. It should appear almost like a background process in Windows, even though it is doing all the work running the Z80 program while all the input info is being received from the Primary Atari emulator. The Atari emulator will sit in a loop sending any keyboard or joystick information across the shared memory pipe. The twinned emulator basically also has a loop that sits reading the next command from the pipe and triggering an appropriate key or joystick press routine (that modifies the appropriate local addresses). Every screen refresh, the twinned emulator sends back the entire ZX spectrum screen map and color/attribute map data across the shared memory pipe. This is the only way the emulators are synchronised, since the ZX spectrum machine will run at 2MHz and the Atari at 1.79Mhz and there is not really much code running on the Atari. The Atari emulator code (not the code it is running) then has to copy the screen memory in the shared memory pipe DYNAMICALLY into the correct screen memory locations for the Atari and generate any DLI's for creation of the colour map on the fly (for efficiency, the twinned emulator could only send the lot if there is a change to the colour map, ie. don't send otherwise or include a seq no from which the primary can use to detect a change). It may not need much from the Atari emulator for screen memory handling but to simply copy the screen from the shared pipe to the screen memory inside the Atari emulator, if the Atari emulator itself is already setup running a simple program at launch of twinned emulator mode which puts it in 32 byte wide Mode F and with PMG DMA enabled and PMBASE pointing to the area that the Atari emulator is going to 'fill' to emulate the colour map. However, it will have to do it's best to generate the color map as PMG. This will be the trickier part, but there could be help using other mechanisms which we introduce below.. The Atari emulator should also use a config file that can be changed per app that maps the ZX colour map values to the Atari version, since sometimes the Atari version will look much better with a colour deviation from the ZX Spectrum. The program that the Atari emulator runs itself does not have to do much except for have setup the screen details and display the PMG. The key point though that although it is not running the ZX spectrum code, it's screen is still being 'driven' by the ZX Spectrum emulator running the code at 2Mhz ie. even any scrolling of the screen etc. The theory would be that you were able to play let's say 75-80% of the Spectrum software on the Atari emulator in this 'twinned' formation. As an example of the shared memory pipe being used, the emulators would send pure text for the commands/data: Control: |START| - An indication to the twinned emulator that it may now start reading the keys/joystick and start sending the screen back from the next screen refresh onwards. |STOP| - An indication to the twinnded emulator to terminate cleanly. Inputs: | KEYS: {<SHIFT>,A} | - Indications of keyboard activity on the Atari | JOY: {UP, RIGHT}| - Indications of joystick activity on the Atari Outputs: | SCREEN: {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ........................................................................................} | - Entire screen data sent from the ZX Spectrum emulator to the Atari. | ATTRIBUTEMAP: { 1,1,1,1,1...............................................................} | - Attribute/color map sent from the ZX Spectrum emulator to the Atari. The advantage of using a shared memory pipe, is that it's easier to modify an existing program to use such a mechanism and it's more portable, since the other emulator could even be written in Python or other language but still use the shared memory pipe. Later on, there is the possibility of expanding the pipe commands, so the ZX Spectrum could for example send back certain memory location addresses and values that the Primary emulator asks to 'watch'. This might be useful if on the Atari emulator when playing a game, we wanted to play sounds or run a RMT player playing music but we needed to know precisely when something had changed, ie. the player died, or the level had changed. To cater for this expansion, we should allow for a different program (other than the default) to be launched inside the Atari emulator on entering 'twinned' mode. It should also set some virtual 'hardware' register that the Atari code could see, so the music player could change music. As a purist, you may think that the twinned emulators in such a config are not really like an Atari running the code and are of limited value for real HW users, but when used virtually, they could be thought of like a dual processor machine which is nothing new, for example back in the 80's there was the C128 machine that had a Z80 processor that could run CP/M. Also, if an new up to date Atari HW (ie. video out of HDMI and USB Power supply) was launched like the new "The C64" machine, you can imagine such a 'virtual' mechanism that requires only a license of a 2nd emulator as well as the primary is remarkably cheap and would bring in a much greater audience with so many more titles available.
  5. Thanks, very playable. Is it possible to fix the last line in the scrolling window, as it flickers a lot?
  6. I found this article interesting for a theoretical useful example where this might be useful. If there were multiple 6502 cores on an Atari 8 and Antic pulled down the ROY line on each so that they all got interrupted at the same time, you could have each execute a horizontal interrupt/ kernel on the same scan line. This might be very useful for changing hardware registers on the same line, since normally you can't get very precise timing, nor can you afford to lock the main CPU into the screen drawing for very long. In it's most basic use, each additional CPU kernel would do their own timing of various lengths and change the hardware registers they needed to, before exiting the DLI. The 1st core could simply exit the interrupt straight away to carry on with the main code. When you additionally need to execute a STA WSYNC to control multiple lines for the kernel, only one CPU core would be able to do this (ie. either the one that does the last changes on the scanline nearest the right hand side or just one with a long dummy timing loop) so this can be programatically done. The only issue would be there is only one vector pair for the horizontal interrupt. I can only think that there would have to be a change to the O/S to jump through each vector and this would use some extra RAM. For horizontal aligned games ie. where you have many sprites per line, you could have multiple kernels that just stuff the sprite details into the hardware register (avoiding DMA) and then just manipulate the vectors for each based on the scanlines. Not saying this is not just rambling nonsense but this may certainly enhance the Atari's longevity into the future and allow more games to be converted.
  7. Yeah that's looking so much better now without the green face, from the title screen I can see the character was meant to be a young guy and not an alien 😄 I also like the grey border change as it takes away the fact that previously everything looked red or pink. On the title screen and inlay pic, the player guy actually has a red shirt and blue trousers, whereas the villain is correct in the game with a blue cape. Without seeing all the C64 screens but having watched the C16 version, an Antic Mode 4 Atari version might work something like this: BG: Black FG1: Brown FG2: Pink FG3: Red / Dark Grey for Rocks or Green for trees/bushes or Yellow for bottle or Blue for water (5th colour) Our guy = mainly Pink + Brown from the FG colours above, we can stick with the brown shirt for now but I think it could be Red, we could later decide to use something else for his trousers. M0 + M1 = Border colour of Grey where M0 = quad sized on the left border, M1 = quad sized on right border. As a result, without wanting to reuse the 5th color with the missiles, our player could have Grey trousers using one of P0 or P1 (who wears Green trousers?). However, we also still have P2 + M2 and P3 + M3 so we could use the players to also colour the purple question marks and the yellow scroll. A white PMG will also be needed for the glove, key, and maybe one or two Players for the white fence.
  8. Not having heard of the game before, I could only wonder if this was anything to do with Ricky Gervais, sadly it is not, it looks a fun enough puzzler though, sort of like a flatter looking version of Robin of the Wood without the animations. The C64 version definitely looks and sounds far better than the C16 version, the title screen is very good and the SID version of the music grows on you. Interestingly, it looks like on both versions you have more than 5 colours on screen even without hardware sprites, or this a trick of the eye? Like on the C16, the player's face looks Green whereas, it is Pink on the C64 (which seems to be one of the screen foreground colours), also on the C64 version, his trousers are always Green. Also, it looks like C16 uses Red only in the border and Brown and Pink on the screen, whereas the C64 uses Brown, Red and Pink all on one screen. If no hardware sprites are being used and there is only 5 colours per scanline then maybe you could use the Atari PMG to have a different colour player shirt to add some improvement, or even more daring, use two missiles as the left/right borders and have a completely different coloured border to the Red. I reckon Grey would be nice.
  9. I remember the C64 version from when it first came out as it used hardware sprite doubling which just about did the trick for the large enemies. My mate at the time (we were both about 12) had a C64 and pointed out the flaw when the guy walks up stairs, the players legs goes first behind the background and then in front, not that it detracts too much. Something I had forgot was the C64 was adept at mixing hi res and low res, so if you want a detailed background you might be better off using hires.
  10. Zone 2 is Antic Mode 2 and has a border colour (ie. Zone 0) whereas, Zone 1, depending on the mode you will use will have no distinct border, since the background colour register also changes the border. To fix this, you can set up PMG and quadruple size a couple of missiles, you can set their colour to the required zone 0 border colour and use them at positions 40 + 200. I believe you can even reuse the same missile as both borders using a simple DLI, as when called by the interrupt from Antic, the DLI could set the position of missile 0 to the right edge (200) and then pause for the hblank before setting the missile back to the left side of the screen ie. PHA; LDA #200; STA $D000; STA WSYNC, LDA #40; STA $D000; PLA; RTI; It is interesting because a graphics mode such as antic E using missile borders can in fact display 5 colours like this, 6 if it is Antic Mode 4. For the issue at the top at bottom, don't forget you can add DLIs (+128) to any entry in the display list, ie. even to the display list codes for blank lines eg. 112 + 128 = 240 so the change occurs on the next line. These would simply set the background color to the colour in Zone 2. I would do what Rybags says though and set the HW register in the Vblank. However, at the beginning of your code for your screen initialisation, if you set both the hardware register and the shadow register (something I used to forget), then the OS Vblank will change the hardware register to the colour in the shadow register automatically, so it may not be strictly necessary for quickly getting something working.
  11. Hi, I'm a newbie here (alhough I've been lurking for a while) and I found this topic very interesting especially with all the fairly recent conversions such as SkoolDaze and I wondered if people were also aware of a toolset called Skoolkit, https://skoolkit.ca/skoolkit/. The idea is that Skoolkit can take a ZX spectrum dump file and work it into a readable format using a file known as a skool file. The skool file can be edited as the code is better understood to create a better disassembly in HTML ( as a few are visible on their website). Apart from the fact that there are a few disassemblies there of some games we don't have for Atari 8, I was wondering as a theory if the skoolkit toolset (written in Python which is on their github link) could be worked on or added to, to provide an extra command line option to produce to 6502 ASM option given a z80 dump + a skool file (i.e. it would translate the z80 to a suitable 6502 assembly). Obviously, I've not tried it myself and there would still be the usual issues of self modifying code needing rewriting/ necessary relocation of code and hw specific translation (i.e. keyboard/ joystick), but I was wondering if it might make translation of new ZX spectrum games slightly easier (at least to a newbie like myself). I'm not sure whether this approach would be any better than Marius' existing tool apart from there are a few skool files already and perhaps you can work on disassembly of a game (as a group ?) before you try and convert it to 6502. Unfortunately, I don't have much provision to work on C stuff as I have only a work laptop and it's limited what I can install, although I do have Python. Let me know if anyone thinks this is an idea worth pursuing.
  12. I never owned a C64 but I've bought one (The C64) which arrived before Christmas. It seems quite expensive and a collector may rather pay less or the same price for an original but it has a full keyboard and can boot to good old C64 Basic (and can work as a Vic 20). It comes with some good games like Impossible Mission 1 + 2, Cybernoid 2, Street Sports Basketball i.e some of the games to envy we haven't yet got on Atari 8 bit and some titles that did appear on the Atari such as Hovver Bovver, Attack of the Mutant Camels (Atari's was better), Uridium (or at least various clones) and the C64's Pitstop 2 which always looked far better. With it hooked up to a HDMI monitor (it doesn't seem to scale at all unlike an emulator), you can see that even hi res doesn't look that great these days on this type of display as even the main sprites in Impossible Mission look blocky. There are a few games you start to see as being the sort of thing that would have been relatively easy to port to Atari 8 using a decent SW sprite engine like Gribbly's day out and Thing on a Spring. The games soon tire and you can put in a regular USB stick in the back and so you can play pretty much anything you can download. The joystick feels solid and is great (USB) but is irritatingly micro-switched and very loud, so much I'm sure my neighbour will complain eventually. Two things, it initially seems to be little use for dissassembling/ debugging / game conversion as far as I can tell, there's no cartridge port etc, ie. for a C64 Action Reset Cartridge or equivalent. I will be impressed if someone figures out it's possible to crash it to a Linux shell or something (I believe the C64 mini was Linux) as the presentation carousel seems robust.... At best, you can count the pixels of the C64 sprites, being as I say, rather large and it's OK for the kids. Secondly, it would at least be great if Altirra or other emulators could provide a driver for the joystick. I used to keep hold of the family Atari 8 bits but I no longer have them but would definitely buy an Atari version if it had an original cartridge port as well. If you think of the fascination for kids in just plugging in a cart for their friends and playing original Donkey Kong on new stable cheap HW (not an antique you need to protect) then that would be great with the option for the parents of downloading the newer Arcade releases or adding a 1Mb cartridge or a cart based accelerator would be awesome.
  • Create New...